なぜ失敗するのか?

今日のウェブでは、私たちは先人たちの肩の上に立ち、彼らが築いてきたものの上に構築しています。

失敗はそれを認識しないことから生じます。

会社の IT 部門に入ることがあれば、DevOps フロアに行ってください。人員不足の開発者チームがヘッドフォンを着け、画面を見つめて目が赤くなっている状態で迎えてくれるでしょう。彼らは集中しすぎていて、質問されても答えない可能性が高いです。

なぜ彼らはそんなに熱心で、目がかすんでいるのでしょうか? 従来の開発者が、アプリをゼロから構築し、それを自分たちだけで行うことに誇りを感じているのを私は見てきました。自分でゼロから構築することを好むのは、十分な時間とリソースがあれば素晴らしいことですが、資金が限られている小規模プロジェクトでは、それがプロジェクトの失敗につながることがよくあります。ローコードのようなツールが登場すると、従来の開発者はそれを鼻であしらう傾向があります。どこに挑戦があるのでしょうか!

ゼロから構築されたアプリは、永遠にかかるように感じられます。他の人の作業に頼ることができないため、単純な構築が不必要に複雑になる可能性があります。皮肉なことに、Node.js または Java で事前に構築されたライブラリに依存しない実際のアプリケーションは現在存在しません。

ローコードプラットフォームを使用する Mendix、市場から調達することができます Mendix- コミュニティによって構築されたモジュールは、ビルド済みの Node.js ライブラリと同じ概念です。ビルドから不要な複雑さを取り除き、最終結果を簡単に提供できるようにします。

時には、活用できるものが何もないこともあります。その場合は、広範囲で複雑なコーディングを行う必要があり、その場合、会社の他の部門で再利用できるようにする必要があります。このシナリオでは、ほとんどの企業は、再利用可能なコンポーネントの作成に時間を投資し、 Mendix は、このプロセスをさらに効率化しようと努めましたが、社内マーケットプレイスを作成して、あらゆるカスタム拡張機能をホストし、自社の Web サイトとアプリ間で機能を作成し、共有できるようにすることで、知的財産が保護されていることを安全に認識できるようになりました。

従来型コードとローコード: 実例

デジタル顧客オンボーディング プロセスを作成するというアイデアを取り上げ、その違いを説明しましょう。

ある企業が、開発チームに顧客オンボーディングに使用するアプリの開発を依頼します。

アプリには以下の機能が必要です。

• 顧客のデータと文書を保存するためのDropboxとの統合
• 顧客の住所の検索
• 重要な文書をスキャンし、そこから情報を抽出する機能
• ドキュメントにデジタル署名し、レビューする機能。

これらを参考にして、同社のビジネスアナリストは DevOps チームが実行するための 4 つのユーザー ストーリーを作成します。

1) ユーザーとして、顧客の文書をクラウドに保存できるように Dropbox との統合を希望します。

2) ユーザーとしては、顧客の住所を簡単に見つけられるように、自動住所検索機能が欲しいです。

3) ユーザーとしては、デバイスのカメラを使用して重要な文書をスキャンする機能が欲しいです。

4) ユーザーとしては、文書をデジタルで確認し、署名する機能が欲しいです。

部門内に 2 つのチームがあり、他に進行中の新しいプロジェクトがないため、会社は両方のチームにアプリの作成を許可し、社内ハッカソンで対決させることにしました。

チーム1は主にローコードを使用するチームです Mendix アプリを構築してホストするチームです。チームは、高度なスキルを持つ開発者 1 名、空き時間にコーディングを学んでいる財務部門の会計士 1 名、Web サイトやアプリのスタイリングに優れたマーケティング部門のデザイナー 1 名で構成されています。

チーム 2 は、Java 開発者、C# 開発者、Node.js 開発者の XNUMX 人の従来型開発者で構成されています。どちらのシナリオでも、チームは QA やビジネス アナリストなどの従来のスクラムのより大規模な関係者にもアクセスできます。

1 週間後、両チームは関係者にアプリを発表し、各自が順番に、チャレンジで提示されたユーザー ストーリーをアプリがどのように満たしているかを実演しました。そして、明らかな勝者はチーム XNUMX でした。

応募作品を検討し、審査員は各ユーザー ストーリーに基づいて評価しました。審査員が評価した点を詳しく見ていきましょう。

1) ユーザーとして、顧客の文書をクラウドに保存できるように Dropbox との統合を希望します。

チーム1は、すぐにビルド済みのモジュールが利用可能であることを認識しました。 Mendix  マーケットプレイス。彼らはこれを作業のベースとしてすぐにセットアップに成功し、ビデオで行ったように、ユーザー インターフェイスとコードのドキュメント化に時間を費やしました。

チーム 2 はほとんどの時間を Dropbox のドキュメント ページを理解するのに費やしましたが、実際に機能する統合は実現したものの、ユーザー インターフェイスは粗雑で使いにくいものでした。

2) ユーザーとしては、顧客の住所を簡単に見つけられるように、自動住所検索機能が欲しいです。

今回も、チーム 1 はダウンロード可能なモジュールを用意し、機能とドキュメントの完成に重点を置きながら、すぐに接続できました。

チーム 2 は、どの住所検索サービスを使用するか決めるのに苦労しました。全員がどれが最適かについて好みを持っており、決めるのに時間がかかりました。最終的には、Google を使用してなんとか機能させることができましたが、ここでもチーム 1 にはかないませんでした。

3) ユーザーとしては、デバイスのカメラを使用して重要な文書をスキャンする機能が欲しいです。

この時点でチーム 2 は遅れていることに気づき、その分野の専門家に助けを求めました。ソフトウェア プロジェクト管理に携わったことがある人なら、ここで問題が何なのかがわかるでしょう。ソフトウェア開発の有名な法則に、ブルックスの法則があります。「遅れているソフトウェア プロジェクトに人員を追加すると、プロジェクトはさらに遅れる」というものです。OCR 機能を構築するために新しいチーム メンバーを参加させると、新しいメンバーはプロジェクトに追いつくのに時間がかかり、現在のコードベースを理解するのにも時間がかかります。いつものように、これは真実であることが証明され、プロジェクトはさらに遅れてしまいました。

チーム1は開発のペースを維持することができました。彼らは、そうです、ご想像のとおり、利用可能なモジュールを使用しました。 Mendix画像認識の経験がないローコーディング担当者は、最も技術力の高いメンバーの力を借りて、すぐにそれを実現しました。

4) ユーザーとして、文書をデジタルで確認し、署名する機能が欲しいです。

どちらのチームもこのユーザー ストーリーで同様の結果を生み出しましたが、ローコード チームは秘密兵器 (現在のシステムで正しいプロセスを知っている会計士) を活用できたため、複雑なユーザー フローでのミスを回避することができました。チームは十分な時間があったため、これに関するビデオも作成できました。チーム B はそうしませんでした。

Mendix チームAは、既存のスプレッドシートをアップロードすることで、アプリのドメインモデルを自動的にモデル化するオプションを提供しました。スプレッドシートは自動的に読み込まれ、アプリのドメインモデルで再作成されます。最終的に、チームAは Mendixは、必要なすべてのデータの一般的な概要を生成できるため、アプリの重要な統合すべてに集中することができました。

意思決定時間

審査員は簡単にチーム 1 を優勝者に選びましたが、なぜでしょうか?

基本的に、両チームは同じ要件をすべて満たしていました。これは同じテクノロジーであり、同じプロバイダーによって処理されていますが、チーム 1 は半分の時間で完了し、残りの時間を製品の反復と改良に費やしました。彼らが作成できたものは次のとおりです。

チームは、使用していたモジュールの将来の変更に対するやり直しも軽減しました。たとえば、DocuSign ライブラリに変更が必要になった場合、その変更はモジュールのマーケットプレイス作成者が処理し、モジュールの更新後に重大な変更があった場合にのみ、アジャイル チームがコードをリファクタリングする必要があります。これは、コネクタの作成者が処理する必要がありました。

他の人の作業に頼るのは問題ありません。それは進歩なのです。これらのモジュールやコード ライブラリを作成した人々や組織は、あなたにそれらを使用してほしいと思っています。彼らは、自分たちが経験したような頭痛の種をあなたに与えたくないのです。そうすれば、あなたはより大きな問題の解決に集中できるのです。素晴らしいのは、これらを使用して顧客体験を刷新し、デジタル カスタマー オンボーディング プロセスを構築できるということです。あるいは、これらを活用して、これまでにないペースで、任意の数のシステムやアプリを革新し、最新化することもできます。