「準備不足」による課題対応に向けた7つの最適解

　DXでの現場によるアプリ整備の策として、ローコード開発に対する関心が一層の高まりを見せている。アプリの高速開発を狙いとしたツールは従来から存在したが、それらの大半は設計情報からのコード生成など、技術者によるウォーターフォール型開発の効率化を狙いにしたものだった。

　対して、ローコード・アプリケーション・プラットフォーム（LCAP）は、コード記述などの専門知識を要する作業を、ソフトウェア部品のGUIによる組み合わせなどで極力省き、開発の知見が乏しい現場社員でもアプリ開発に乗り出せるようにした。

　ガートナーではLCAPを、「ローコード型の宣言記述やビジュアルなプログラミングの抽象化表現をサポートする、データベースを含めたアプリケーション・プラットフォーム」と定義している。ガートナー シニア ディレクター,アナリストの飯島公彦氏は、「今年2月の調査時点ですでに企業の4割がLCAPの利用に乗り出し、その7割でデリバリスピードの向上という明確な成果が上がっています」と、そのメリットを解説する。

　ただし、LCAPの裾野の広がりに伴い、課題も顕在化し始めているという。

「現場の知見不足やフォロー不足に起因するLCAPの誤用／過剰使用と、それに起因するセキュリティ・リスクの増大のほか、アプリケーションの無秩序な増加による統制の欠如、現場のスキル不足など、課題は多岐にわたります」（飯島氏）

　根本的な問題として挙げるのが「準備不足」であり、それらの課題対応に向け飯島氏が必要性を訴えたのが次の7つのベストプラクティスの実践だ。

なぜ失敗する？誤ったローコード戦略が多発するワケ

1．自社に適したローコード戦略の策定
「LCAPは何でも開発できる魔法の杖ではありません」と飯島氏は強調する。開発のハードルを格段に引き下げたのは確かだが、デメリットとして開発の自由度は逆に失われてしまう。アプリの機能はプラットフォームに大きく依存するため、開発規模にも限界がある。

　それらへの認識が不十分なまま利用に乗り出し、誤ったツール選定を行っているケースが現状少なくないという。SalesforceなどSaaSに付随する機能でもあり、それらの意図しない利用の広がりが各種の誤用、ひいてはインシデントをも招いている。

「回避に向け、LCAPの利用戦略の策定が重要です。IT部門の主導により、目的やユースケースを明確化する。そのうえで、画面やプロセス、データ、アプリのスタイルなどを基に、自社に適したツールを選択します」（飯島氏）


　主要な検討項目が「用途」「技術」「ユースケース」「現状とのギャップ」などだ。このうち、自社の状況を鑑み、上段からブレイクダウンするかたちで個々の項目について決定する。

「LCAPには開発やシステム連携、RPAなどカテゴリがいくつかあります。ビジネス目標と整合性を取るかたちで検討項目を埋めていくことで、自社に適した製品が自然に絞られます」（飯島氏）

2．PoCを通じて観点ごとにLCAPをチェック
　飯島氏によると、ツール選定にあたっては開発機能を入念に調べる一方で、テストやデプロイ、統合などの機能や、操作に必要なスキル、成果物の管理／流通などの観点でのチェックは極めて軽視されているという。

　結果、開発フェーズこそ円滑に遂行できたものの、開発／運用中に想定外の局面が多発し、そのことが開発と運用の溝を埋めるための追加の作業／コストの一因になっている。

「アプリ利用は開発を終えてからが本番です。そのことを肝に銘じて、現場での運用までを視野にツールをチェックすべきであり、開発生産性／セキュリティ向上のためのテンプレート開発の可否や、テストやデプロイの自動化、APIの対応度などが特に重要です。また、新たな開発のテーマの設定都度、PoCを実施することで、ニーズと機能の乖離をいち早く察知し、無理な開発によるトラブルを回避できます」（飯島氏）

　PoCを通じ、開発者のペルソナやユースケースへのLCAPの適合度、ガバナンス、搭載機能の有効性なども確認できる。 【次ページ】IT部門に頼らない、市民開発で成果を上げる秘訣とは