ガートナー、ローコード開発ツールの導入で実践すべき7つのベストプラクティス

今回は「ガートナー、ローコード開発ツールの導入で実践すべき7つのベストプラクティス」についてご紹介します。

関連ワード （ソフトウェア等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　ガートナージャパンは6月13日、ローコード開発ツール（ローコードアプリケーションプラットフォーム：LCAP）の採用を成功させるために実践すべき7つのベストプラクティスを発表した。

　米Gartnerは、同技術の世界支出が2026年までに445億ドルまで拡大すると予測している。これは市場全体の数字であり、ローコード開発ツールはその中で最も大きい割合を占めているという。

　シニア ディレクター アナリストの飯島公彦氏は、「ローコード開発ツールは、業務やIT上の課題を解決すべく多くの企業で検討され、導入が進んでいる一方で、ローコードツールの誤用／過剰使用の増大、セキュリティリスクの増大、アプリ開発のスキル不足の拡大、アプリケーションの無秩序な増加をはじめとした、さまざまな問題点が指摘されている」と指摘する。

　その上で同社は、アプリケーション／ソフトウェアエンジニアリングリーダーが、組織内でのローコード開発ツールの採用を成功させるために実践すべき7つのベストプラクティスを提言している。

　Gartnerに寄せられる問い合わせでは、LCAPを何でも開発できると捉えて手組み用の開発ツールや言語と同じように取り扱い、適用内容を明確に考えていないケースが散見される。その結果として、実現したい内容にマッチしていないツールを選択するケースが多く見られる。

　LCAPの活用に当たっては、利用戦略を策定することが重要。ローコードのユースケースとローコードテクノロジーを特定し、整合させて、どこで、どのように活用するか、どのような場合には使用すべきではないかを明確にすることで、ミスマッチを避けられるようになる。

　多くの企業がLCAPツールの開発機能に着目しているものの、テスト、デプロイ、統合などコーディング以外の機能をどのようなスキルレベルの人が使うのか、成果物をどのように共有・流通させ管理するか、また、何をどのようにガバナンスできるのか、といった観点での評価が不足しているように見受けられる。その結果、開発機能は要件に合致していたものの、運用の際にこんなはずではなかったという局面が多発し、それを埋めるために想定外の追加作業やそれに伴う費用が必要になるというケースが見られる。

　こうした事態を避けるために、試験運用やPOCの内容について慎重に検討し、確実に実施することが重要となる。組織で試験運用やPOCを実施し、LCAPが開発者のペルソナやユースケースに適合しているかを確認すると同時に、ガバナンス機能を判断したり、搭載機能の有効性を判断したりすることが可能になる。

　多くの企業では、LCAPを使えば簡単にアプリケーションが早く作れるようになると考え、実際、そうした成果が実証されつつある。一方、市民開発者は、LCAPを使う際に使い勝手や実現したいことに対する技術面の不足など、さまざまな障壁に遭遇する。そうした障壁は、市民開発者の意欲を削ぐだけでなく、適切なLCAPの利用の妨げになり、適用の拡大や浸透・定着の妨げにもつながる。

　LCAP支援チームを設置し、技術面でのサポートを提供することで、市民開発者がLCAP利用の早い段階から成功体験を積み重ねることが可能になる。その結果、市民開発者にとって使いやすいLCAPや開発・デリバリー環境に仕立て上げることができ、それがさらにLCAPの活発な利用促進につながる。

　多くの企業では、「ガバナンスは全体に対して均一に適用する」という発想が無意識のうちに定着してしまっているように見受けられる。適用対象、範囲、重要度、利用者、もしくは複雑度に応じて適用ゾーンを分割し、それぞれに最適なガバナンスを策定する必要がある。

　個人やグループレベルでの簡単なアプリケーションは、市民開発の主たる適用ゾーンとし、全社レベルのアプリケーション、複雑なアーキテクチャーやシステム連携、高度な非機能要件の設計やテクノロジー知見などが必要となるアプリケーションは、IT部門が主として担当するゾーンに設定する。この2つの中間に位置するようなアプリケーションは、IT部門とユーザー側がフュージョンチームとして密なコミュニケーションをとりながら構築を進めるゾーンに設定する。

　IT部門とユーザー部門の役割分担やガバナンスの在り方を最適化し、可視化するのが適応型ガバナンスフレームワークの考え方になる。これにより、アプリケーションを適切なゾーンに割り当てた上で、一貫性を保つべき事項や必ず守るべき事項を特定し、市民開発の意欲や適用の浸透・定着の阻害要因とならないよう、かつ企業にとってのリスクにならないよう、バランスをとることが可能になる。