ローコード開発導入の前に検討すべき課題

iStock.com/aurielaki

　ローコード開発は新しい現象ではない。多くの点において、これは1980年代に登場したラピッドアプリケーション開発（RAD）ツールを表す用語の現代版と言える。こうしたツールは元々、プログラミング技術の代替として導入された。初期のRADツールは手早い反復的な開発手法に重点を置き、ユーザーエクスペリエンスや全体的なパフォーマンスを優先していた。

　現代では、ローコード開発を使った従業員支援はデジタルワークフォース特権の一部となり、部門および作業グループの大規模なアプリケーション開発を支えている。従来のような開発のプロフェッショナルを必要とし、ローコード開発ツールで対応できないアプリケーションは、極端にスケールの大きいアプリケーション（例えばカスタム版のマイクロサービスに依存するものなど）や斬新な機能を搭載したアプリケーションに限られる。

　ワークグループでは、常にスプレッドシートのようなシチズンデベロッパー（訳注）用ツールが利用されてきた。開発者が事業部門に関連付けて構築する部門業務用のアプリケーションは、人気の高いSaaS製品と並んでローコード開発ツールにとっての成長分野だった。

訳注：IT部門の専門技術者ではなく、事業部門で通常業務をしつつシステムを開発する人。

　ローコード開発の主なメリットとしては、生産性の向上、製品化の時間短縮、専門スキルの必要性の低下、（ローコード開発ツールの外で）必要とされるツールのシンプル化などが挙げられる。

　ローコード開発ツールを導入する場合、時間の短縮とリソースの削減は依然として最大のメリットだが、多くの場合コストが懸念材料となる。サブスクリプションモデルを最初に契約する際は細心の注意と慎重さが求められるということを理解していない顧客は、高い割合で存在する。

　「ユーザー当たり」あるいは「アプリケーション当たり」のコストは使用ボリュームに伴って低下する。勧告されている通りに小さく始めれば、必要に応じて拡張するための条項をローコード開発ツール契約に確実に盛り込めるはずだ。組織の各チームが、毎月あるいは2カ月ごとに新しいアプリケーションを構築できれば、アプリケーションは瞬く間に数十本に増え、その全てが比較的短期間でビジネスクリティカルと見なされるようになる。

　一部のIT組織は、一般的にはAPIを通じて解決する既存のITシステムとの統合に関する疑念から、ローコード開発ツールの採用に二の足を踏む。だが現代のローコード開発ツールサプライヤーの大多数は、APIを通じた既存のサービスの呼び出しに対応している。顧客のデータまたはサービスにアクセスするための独自のAPIも提供している。

　Gartnerは現代の企業向けツールの条件として、API対応を必須としている。だからといって、ローコード開発の重点が単純にAPIからヘッドレスサービスへのアプリケーション構築に置かれているわけではない。多くのローコード開発ツールはまた、マルチエクスペリエンス開発機能を搭載し、極めて使いやすく、顧客に優しいユーザーエクスペリエンスをWebおよびモバイル端末で提供している。