本記事は「今こそ、ローコードを考える 第3回 ローコードの理想と現実 前編」からの続きとなっております。
前回記事はこちら
アプリケーションの保守のしやすさ
理想
アプリケーションの寿命は、そのシステムの投資対効果を判断するための一つの指標です。アプリケーションを長期にわたって使用するには、修正や新機能で定期的にアップデートする必要があるため、ソフトウェアの保守が非常に重要です。ソフトウェア保守は、ライフサイクル全体を通したアプリケーションの総所有コスト（TCO）の80％を占めます。そのため、ローコードプラットフォームでは、最初のバージョンのアプリケーションを簡単に開発できるだけでなく、それ以降の新しいバージョンの開発も簡単にできるようにすることが非常に重要です。
現実
ローコードプラットフォームを使用してアプリケーションの構築にかかる時間が短縮できる場合は、新しいバージョンの構築にかかる時間も短縮されると考えがちです。多くのローコードソリューションの前提としてソフトウェア保守の容易さがあります。ローコード開発環境から抜け出して複雑なロジックをコード化するため、または連携の困難な問題を処理するために、従来の方法を使用するたびに、保守の負担とコストが大幅に増加することを前章で述べました。これにより、ローコードプラットフォーム環境でアプリケーションを更新すると同時に、外部で構築された「拡張機能」を他のツールを使用して2重保守する問題が発生します。これらの外部開発コンポーネントは、開発と保守が困難でコストがかかるため、注意が必要な重要な問題です。
コード拡張のためにローコードプラットフォームから抜け出ることにより引き起こされる問題に加えて、以下の他の要素によっても保守は重大な影響を受けます：
- グローバルなビジネスルールやプロセスに合わせた変更
- テストおよびデバッグツール
- 変更とバージョン管理
- 配布
テーブルの定義、接続、ビジネスルールを保守することは特に困難です。多くのローコードプラットフォームでは、それらを使用するすべてのプログラムやデータベースに「ハードコーディング」する必要があります。これは保守の負担を増やすだけでなく、これらのルールを複数の場所にコピーすることで矛盾が発生する可能性があり、データベースのロックインにつながる可能性もあります。ルールが定義が一度で、どのプログラムに適用される仕掛けがあれば保守が容易になります。
エンタープライズローコードプラットフォームは、これらすべての問題に対処できる必要があります。また、DevOpsのソフトウェアの開発から配布までのより広範囲な問題に対応できるものもあります。これらは、組織全体に複数のアプリケーションを構築して展開するときの重要な考慮事項です。
まとめ
保守がアプリケーションのTCOの80％を占めているため、正しい選択をすることは非常に重要です。ローコードプラットフォームを検討するときは、次の点に注意すべきです:
- プラットフォーム内で処理できないコード拡張のために、プラットフォームを抜け出なければならない頻度
- ソフトウェア保守の負担を軽減することができる、プラットフォームが提供するDevOps の機能
特定技術に依存しない
理想
ローコードプラットフォームでは、そのプラットフォームから将来移行することになった場合でも、投資は保護され、そのプラットフォームに縛られることはありません。アプリケーションは以前と同じように動き続けます。 何か新しいことを試みるリスクを減らし、最終的に「よりよい」解決策に移行する選択肢を提供します。
現実
約束は魅力的なものですが、現実は多少異なり、それはローコードソリューションに限られたことではありません。ローコードソリューションは、アプリケーションを構築するために、JavaScriptのような「標準」の技術でコードを生成するかもしれませんが、人間の開発者がこの機械が生成したコードを理解し保守することは非常に難しい可能性があります。ローコードソリューションを使用することの魅力は、従来のツールでの複雑で労力がかかるコーディングを避けられることです。また、ローコードプラットフォームで対処できない際に、ローコードが生成したコードが保守可能であるという考えは、現実的ではありません。
ビジネス要件が変化し、アプリケーションを取り巻くテクノロジー環境が変化しても、アプリケーションは保守が必要です。バグ修正、新機能、セキュリティアップデートが必要とされるかにかかわらず、アプリケーションは保守可能である必要があります。これらから、実際にはアプリケーションは最初に構築したツールに縛られていることを意味します。
クラウドのサブスクリプションを終了すると、クラウドでホストされているアプリケーションが利用できなくなることも事実です。アプリを別のクラウドインスタンスに移動したり、ローカルで実行したりすることを保証できるものではなく、非常に困難な作業です。
ただし、これらは、ローコードソリューションのみの問題ではありません。ソフトウェアアプリケーションを構築しホストするために使用されているあらゆる技術に当てはまります。多くの会社は主要なメーカーによって提供された開発ツールの初期のバージョンでアプリケーションを構築していて、ツールと技術の進化に伴い、それらのアプリケーションを書き直す必要に迫られています。
現実的には、テクノロジーの選択で、デバイス、オペレーティングシステム、アプリケーション開発ツールなど、ロックインの問題が内在しています。ローコードツールが優れているのは、基盤となる技術を進化させ、抽象化することによって、変更が発生してもローコードソリューションによって変更からユーザーを隔離し、投資を保護することです。
まとめ
すべてのテクノロジーの選択にはある程度のロックインの問題が内在しており、ローコードでも例外ではありません。ただし、ローコードソリューションでは、基盤となる技術が変化したときにそれを抽象化することができるため、これらのアプリケーションの寿命を延ばすことができます。これは、企業において重要な考慮事項です。
デザイナーを必要としない優れたUI/UX
理想
アプリケーションをユーザーに気に入ってもらえることは、あらゆるアプリケーションの成功にとって重要な要素です。そのため、優れたUIとUXでアプリケーションを構築することの重要性が説かれています。製品のデモは常に見栄えがよく、ローコードプラットフォームを使用するだけで、同様に魅力的で使いやすいアプリケーションを構築できることを保証します。
現実
ローコードソリューションを使用すると、魅力的で最新の使いやすいアプリケーションを構築できます。残念ながら、UIとUXのスキルはデザイナーにかかっているため、使い難いアプリも構築できてしまいます。2017年の米ガートナーの報告によると、企業内のUXデザイナーの平均比率は開発者17人に対して1人です。推奨は、4.2人に1人です(注2)。では、どうしてこのようにデザイナーの割合が低いのでしょうか。理由は、設計ではなく、アプリケーションの機能に焦点が当てられていることが多いからです。ユーザーエクスペリエンスが十分に検討されておらず、ユーザーの選択やアプリの使用を促進するために必要なことに重点が置かれていないため、エンタープライズアプリケーションの多くが課題を残しています。
開発チームにおけるデザイナーの役割は過小評価されるべきではなく、なくてはならない存在です。しかし、利用可能な設計スキルが十分でない環境で、ローコードのソリューションで解決できる場合があります。
ローコードソリューションは、Googleや他の企業がマテリアルデザインなどのデザイン方法論を具現化する機能で、エンタープライズアプリケーションに標準的で最新のモバイル優先のデザインの採用を促進することができます。開発者に利用可能な標準コントロールとUI要素を提供することにより、一貫性があり、最新の魅力的で使いやすいアプリケーションの構築を簡単にします。
設計スキルがほとんどまたは皆無の開発者でも、標準的な設計ガイドラインに従い、判り易い方法で情報を表示するため、ユーザーが理解しやすいアプリケーションを構築できます。デザイナーの必要性を排除するわけではありませんが、ユーザーにとって魅力的なアプリケーションを開発しようとしている開発者を支援することができます。
まとめ
優れたUI / UXは偶然に生まれるものではなく、デザイナーが開発プロセスに参加する必要があります。ローコードソリューションでは、そのままでは優れたデザインを実現できませんが、マテリアルデザインなどの標準デザインの要素を提供することで、開発者にとってそのプロセスを簡単にすることができます。簡単な企業レベルのアプリケーション構築
理想
ローコード(またはノーコード)ソリューションは、企業のニーズに合わせた規模のアプリケーションを構築することができます。つまり、ビジネスの現場と協力してソリューションを提供するのと同時に、ユーザー、データの量、アプリの機能、連携、展開、セキュリティに対する企業のニーズを満たすための柔軟性に、ローコードソリューションはとても優れています。
現実
実際にローコードのマーケットは、部門クラスのソリューション用と、企業クラスのソリューション用に別れています。企業クラスのローコードソリューションのみが、企業クラスのアプリケーションを提供できます。多くのローコードプラットの焦点は、Webアプリケーションの構築と、それらをクラウドへ展開することであるため、単純に考えれば、もっと多くのサーバーリソースを投入することで拡張の問題には対応することができます。これは間違いなく救いになりますが、インフラストラクチャーのコストは指数関数的に増加することになります。これに対して、アーキテクチャレベルで技術的な課題を解決することで、純粋に追加のサーバー容量に依存することなく、より優れた規模とパフォーマンスを実現することができます。
企業クラスのローコードプラットフォームの要件：
| ビジネスを巻き込む | ローコードソリューションは、開発者がビジネスアナリストと供にプロセスをモデル化し、プロトタイプを構築し、それらのプロトタイプを実用のシステムに切り替えることができるか？ |
|---|---|
| ビジネスルール | ローコードソリューションは、ビジネスルールをアプリケーションから中央リポジトリに切り離して、必要に応じてそれらをすべてのアプリケーションで再利用できるか？ このアプローチでは、ビジネスルールに対する変更を1回で一元的に行うことができ、関係するすべてのアプリケーションは自動的に更新されたのと同じ状態に保つことができます。このようなアプローチは、スケーラビリティとアプリケーションの保守のしやすさに大きなプラスになります。 |
| アプリケーションの機能 | ローコードプラットフォームの機能制約はどんなものか？ (「コーディングが不要」の項を参照) |
| データ量/連携 | ローコードプラットフォームはデータベース連携をどのように処理するか？ローコードプラットフォームの連携の自由度はどうか？ （「シームレスな他のシステムとの連携」を参照） |
| セキュリティ | データが確実に正しい方法で使用、処理されるようにするために、プラットフォームにはどのようなセキュリティ機能が組み込まれているか？ サイバー攻撃が増加しているため、ユーザーによるデータの使用が危険にさらされないようにするために、慎重な保護対策が必要です。 |
まとめ
拡張性は、追加のリソースを要求だけの単純な挑戦ではありません。ローコードソリューションを評価するとき、それがどのようにビジネス全般での稼働をサポートするか、複雑な機能、連携と保守の課題の解決に役立つかを判断すべきです。継続的なビジネスプロセス改善の観点から、技術的に複雑な問題に解決策を導き出せるかが重要です。
まとめ
現在ローコード開発が極めて重要なテクノロジーであることを考えると、それが提供する可能性についていくつかの誇張があることは理解できます。ローコードプラットフォームは、多くの場合に、ビジネスアプリケーションを構築するためにより簡単な方法を提供します。私たちが述べた7つの重要な分野のそれぞれにおいて、1つのことが明らかになります:- 一部のローコードソリューションには制約がある。検討中のローコードプラットフォームが意図した目的に適するかどうかを判断するには、これらの制約を十分に理解する必要がある。
ローコードソリューションへの期待は、単一のソリューション内でアプリケーションの設計、開発、テスト、連携、配布まですべてを提供するということです。特定のソリューションの制約により、ローコードプラットフォーム内では実現できない作業を、従来の方法に頼らなければならない場合、ローコードへの期待と利点は損なわれます。ローコードプラットフォームから離れることが多い場合には、アプリケーションの構築と保守のコストが増加します。
今回は、「ローコードの理想と現実」についてお話しして参りました。
次回はいよいよLANSAの取り組みについてお話しさせていただきます。
