はじめに
ローコード開発は、現在注目されています。今後数年間でさらに急速に成長すると予測されています。 フォレスターリサーチは、ローコードおよびノーコード開発プラットフォームの市場が、2017年の38億ドルから2022年には212億ドルに成長すると予測しています。新しい企業が市場に参入し、今後数年間で大きな収益を得るために大きな資金がこの分野に投資されています。
 |
 |
他の人気のある技術分野と同様に、やや大げさな理想が語られていることは、想像に難くありません。では、現実はどうでしょうか？収益は実際には予測どおりに大きくなるでしょうか？技術は期待通りの成果を上げられるでしょうか？そしてこの分野のベンダーは成功するのでしょうか？それとも失敗するのでしょうか？
もちろん、ベンダーが成功するか失敗するかを決定する要素はたくさんあります。ほんの数例を挙げれば、人、製品、顧客、マーケティング、実行能力などです。この冊子では、最も重要な技術要素について紹介しています。
ローコードに関して取り上げられている重要な要素と問題は何でしょうか？
- コーディングが不要
- 迅速な新しいアプリケーションの導入
- シームレスな他システムとの連携
- アプリの保守のしやすさ
- 特定技術に依存しない
- 優れたUI/UXエクスペリエンス
- 簡単な企業レベルのアプリケーション構築
これらを順番に取り上げて行きましょう。
コーディングが不要
理想
ローコード（またはノーコード）は、従来のソフトウェア開発方法のほんのわずかの労力と時間で、アプリケーションを提供することを約束します。コーディングが不要であることを約束し、単に画面上にグラフィック要素をドラッグ&ドロップするだけでアプリケーションに必要なすべての機能を構築できることを保証します。
現実
部門規模のシンプルなアプリケーションの場合、複雑さのレベルは、理想を実現できるレベルのものである可能性があります。しかし残念ながら、実際のビジネス要件のほとんどは、それほど単純ではありません。必要とされる機能や論理的な処理が複雑になり、複数のバックエンドとの連携が必要になると、理想は崩壊し始めます。顧客の信用調査を行うビジネスプロセスを想像してみてください。考えられるビジネスルールは次のようになります。
顧客の居住地によっては、複数のクレジットスコアプロバイダー（CSP）のサービスを利用する必要があるかもしれません。利用に当たって、 CSPごとにプライベートアカウントの詳細、関連する承認レベル、パスワードを提供する必要があります。また一部のCSPでは、パスワードを定期的な変更をうながすため、「ハードコーディング」することはできず、暗号化されたデータソースに保存する必要があります。与信スコアのチェックを許可されているユーザーは一部で、プライバシー侵害を防ぐためにユーザーIDと権限をチェックする必要があります。各CSPは異なるタイプの与信スコアを生成する可能性があり、それらを単純なA、B、C、Dの与信レベルに調整する必要があります。調整ロジックは、必要に応じて調整できるように、データベースにある必要があります。
このレベルの複雑な処理を、グラフィカルなローコードプログラミングツールで扱うためには、以下の結果を返すブラックボックスとして「簡単に扱える」Webサービスを、IT部門が個別に実装しなければならない可能性が高くなります。
- 成功/失敗識別
- エラー/完了メッセージ
- 認定与信スコア – A, B, C, D レベル
このようなビジネスプロセスを含む、定義済みの機能ブロック群をまとめるのに、ローコードのドラッグ＆ドロップツールは最適です。ただし、このようなWebサービス内で動作するブラックボックスの開発は、依然として「相当に優秀な」IT担当者の領域であり、従来のプログラミングツールを使用して開発される可能性があります。
これが、Webサービスがローコードのソリューションで非常に人気がある理由です。これらの機能ブロックをまとめることができる一貫した方法を提供しているからです。
残念ながら、一部のローコードツールでは、追加の複雑なWebサービスをブロックとして開発するために、ローコードソリューションから抜け出し従来のコーディング方法に戻らなければならない場合があります。これは、ローコードへの期待に反し、追加のソフトウェアを必要としてアプリケーションの保守を非常に困難にします。
まとめ
シンプルな機能要件を持つアプリケーションは、グラフィカルなモデルベースの開発環境を使用して完成させることができます。しかし、構築する機能の複雑さにより、制約を受ける場合があります。これらの制約を超えると、開発者はローコードの開発環境から抜け出して、外部で複雑な機能を構築する必要が出てきます。プラットフォームから抜け出して、スナップインできる複雑な機能を外部のソリューションで構築する必要があるか? それとも外部でコーディングせずに、プラットフォーム内で複雑なプログラミングとロジックを扱うことができるか？ローコードソリューションを評価するときに、複雑な要件にどのように対処するかを調査すべきです。
迅速な新しいアプリケーションの導入
理想
ローコード(またはノーコード)ソリューションは、数週間、数ヶ月単位ではなく、数日でアプリケーションを構築できることを約束します。ソフトウェア開発はいつも長期にわたる複雑な仕事でしたが、書くコードを減らすことでそのプロセスをはるかに単純にして短縮します。新しいアプリケーションをより早く市場に投入することで、ビジネスの俊敏性が高まり、ITのバックログが削減されます。
現実
より少ないコード(ローコード)でアプリケーションを構築し、モデル駆動型のアプローチを採用すると、ソフトウェア開発プロセスを確実にスピードアップすることができます。ただし、アプリケーションのコーディングは、開発プロセスの重要な要素ですがそれだけではありません。従来のアプローチを使用するかローコードアプローチを使用するかにかかわらず、アプリケーションの要件を定義するのには同じ時間がかかります。ビジネス要件とアプリケーションの仕様が明確に定義されていないと、開発プロセス全体が「無駄になる」ことがあります。
ここでローコードのソリューションが役立つ分野は、プロトタイピングプロセスと、ビジネスチームとの共同作業を改善することです。
前章で、コーディングの制約により、開発者がローコードプラットフォームから抜け出して従来の方法に戻る必要があることについて述べました。外部で開発されたコードをアプリケーションに連携するのに追加の時間が必要になり、開発期間に大きな影響を及ぼします。
外部で開発されたコードモジュールもアプリケーション保守の負担を大幅に増やします。これは開発するアプリケーションの将来のすべてのバージョンに影響を与えるため、必要な時間と労力を過小評価すべきではありません。
まとめ
多くのローコードソリューションは、アプリケーションをより速く開発し、市場投入までの時間とIT部門のアプリケーションバックログの削減に能力を発揮します。ただし、プロトタイプ作成、連携、保守の分野でソリューションがどの程度うまく機能するかと、ローコードプラットフォームでは実現できない機能を、ローコード環境から抜け出して別の環境で開発するために失われる時間を考慮して、時間短縮への期待を小さく見積もる必要があります。
ローコードプラットフォームの制約の程度により、多くの開発時間が追加で必要になる可能性があります。
シームレスな他システムとの連携
理想
ローコードソリューションは、既存のシステムとの容易な連携を約束します。独自の「サイロ」で動作する単純なアプリケーションでは、考慮は不要かもしれません。しかし、企業環境においては、既存のシステムと接続して連携運用できなければ意味がありません。連携は、状況によって異なる意味を持ちます。アプリケーションによっては、APIを呼び出して情報を取得するのと同じくらい簡単な場合もあります。別のケースでは、最新のインターフェースが提供されないレガシーシステムからデータを抽出し変換することかもしれません。ローコードソリューションは実用的です。
現実
長期間にわたって変更されない可能性がある、重要な機能が組み込まれたレガシーシステムに接続する場合は、連携は特に複雑です。連携がこのような複雑な挑戦であることから、ローコードソリューションには期待を半減させる危険性がかなりの確率で存在します。多くの製品は、最新で広く使用されているシステムやデータソース(データベース)とのみ連携できる傾向があります。そうすることで、市場の要求の大部分に対応できます。しかし、残された古いシステムについてはどうでしょうか。
Webサービスは、現代のアプリケーション連携の基本になっています。標準のAPIメカニズムを介して既存のアプリケーションを呼び出すことができれば、比較的簡単な連携のための選択肢を提供することになります。
これは既存のシステムとの連携にとって何を意味するのでしょうか。一から設計された最新のAPI連携を使用して構築されていない限り、既存の機能を呼び出し可能なAPIとしてラップしてローコードのシステムと連携することになります。そのためには、開発が必要ですが、必要な連携ポイントが多数ある場合は、その開発がかなりのものになる可能性があります。追加の開発がローコードプラットフォームの外にある場合、それもやはり期待を裏切ることになり、開発するコードが増え、保守するものが増えることを意味します。もちろん、レガシーシステムと連携するためのWebサービス以外のメカニズムもあります。
Webサービスに加えて、データフォーマット（XML、JSON、XLS、CSV、PDF、TXTなど）、リレーショナルおよび非リレーショナルデータベースへの直接的なアクセス、.EXEファイル、.DLLファイル、.NETコンポーネントの直接的な呼び出し、トランスポートプロトコルやメッセージングプロトコルの使用による連携をローコードプラットフォームがサポートしていれば、連携ははるかに簡単になります。これらの直接的なメカニズムは追加の開発を必要としないため、理想的にはローコードの開発環境内から制御できるべきです。
まとめ
多くのローコードソリューションでは、連携はWebサービスを介してのみ行われます。既存のシステムの多くはWebサービスインタフェースを持っていないことから、ローコードプラットフォーム以外での追加の開発が必要になるため、連携はより困難になり、潜在的にコストが増加します。Webサービスの連携だけでは不十分な場合があります。一部のローコードソリューションのみがWebサービス以外のことに対応できるのが実態なので、利用可能な連携オプションの柔軟性を考慮すべきです。
≪後編へ続く≫
