序章

昨今、システムの開発手法としてローコード開発という言葉がよく聞かれます。ノーコード開発とともに使われる言葉ですが、両者には微妙な違いがあったり、製品によって対象とする開発者も異なることはあまり知られていないのではないでしょうか。ローコードを使ってシステムを開発したことのある人でも、明確に違いを把握している人は少ないかもしれません。

本記事では、ローコードにはどんな製品があって、どんな世界観で作られているか、ご紹介します。現在は、ローコード製品を実際に使っている企業も多く、中には期待外れとなってしまった事例もあるかもしれません。良いシステムを作るには、まず始めに、思い描いている開発イメージにあった世界観のローコード製品を選ぶことが重要です。そのための検討軸もご紹介します。

ローコードの歴史

ローコード製品の世界観をイメージできるよう、まず歴史を紹介します。ソフトウェア開発の歴史の中で、ローコード開発という言葉は最近のものですが、開発効率を高める取り組みはそれ以前から行われてきました。例えば、プログラミング言語の統合開発環境であるNetBeansでは、表やボタンなどGUI部品をドラッグ＆ドロップすることで画面レイアウトを開発することができます。ソースコード生成ツールとして開発されたGeneXusでは、設計情報を入力するだけで各種プログラミング言語のソースコードや各種RDB製品のテーブル等、アプリケーションに必要な要素を自動生成できます。ただし、こういったツールで生成されたアプリケーションの実行環境は利用者自身で用意する必要がありました。ソフトウェア開発だけでなく実行環境も用意できる組織向けのツールだったと言えるでしょう。

その後、2010年代になると、Salesforceを中心に、様々な製品が現れます。これらの製品では開発環境だけでなくその実行環境も提供するため、ローコードプラットフォームと呼ばれるようになりました。いいことずくめに思えたローコードプラットフォームですが、複雑なシステムの要件を満たすためには、従来型でプロの開発者がソースコードを自由に記述するスタイルも必要なことが分かってきました。

一方で、プログラム言語にまったく詳しくない人（市民開発者と呼ばれます）がノーコードで開発するニーズも増えていきます。こういった流れで、ノーコードに強みを持つ製品やプロコードが得意な製品など、様々な製品が普及しました。

今のトレンドはローコード＋プロコード

その後一度、ローコード製品の市場は幻滅期に入ります。結局、市場を席巻する製品を利用してもライセンスの値上げが発生して思ったようなコストにならなかったり、製品の仕様上の制約で思ったようにシステム要件を実現できないことが分かってきたためです。2010年代に成功したのは、シンプルなシステム（Excelプラスα程度の複雑さ）だったと言えるでしょう。大規模・複雑なシステムをローコードで作ろうとして、仕様上の制約から要件を実現できず失敗した事例も多かったのではないでしょうか。

そのため、柔軟性の高いスクラッチ開発に回帰する企業も出てきました。しかし、ローコードに比べると開発効率に劣るスクラッチ開発は、今の時代にそぐわなくなってきます。現在有効な開発手法は、ローコードと開発フレームワークの併用です。大規模なシステムを作る場合、市民開発者によるノーコード開発だけでは難しく、プロの開発者が作っていくことが必要です。２つの開発手法を併用することで、ローコードの手早さを活かしつつスクラッチ開発の柔軟性を確保できます。

また、ローコード製品の機能も向上し、市民開発者だけでなくプロ開発者の要求にも十分に応えられる製品が出てきました。現在、2010年代当時よりも高速かつ複雑なシステム開発へと適用範囲が広がっているのです。

ローコード開発の成功事例

ここからは成功事例をご紹介します。コンテンツ事業を営むC社の法人向けWebサイト構築プロジェクトです。

このプロジェクトで最重要課題とされていたのは、認証・認可ロジックの実現でした。Webサイトを利用する様々な法人ユーザーのニーズに応える必要があったためです。プロジェクト成功の要因は、開発予算を認証・認可ロジックに集中したことです。採用したローコード製品の認証機能をベースとしつつも、そのままでは対応できない要件はプロコード開発（技術者がプログラム言語を用いて開発する手法）によるカスタマイズで実現しました。一方で、Webサイトの画面については、ローコード開発プラットフォームの標準画面で多くを実現しました。

具体的な進め方として、最初に要件定義工程で、ローコード製品の標準機能からカスタマイズする部分と標準機能そのままで済ませる部分を明確に定義しました。標準機能で済ませる部分は、まずWebサイトの運営業務を整理して、実際に標準機能で済ませることができることを確認しながら進めました。進めていくと、C社としてはカスタマイズしたい部分も出てきましたが、運営業務を工夫することでカスタマイズを回避しました。その結果、認証・認可ロジックに開発リソースを集中することができ、スケジュール遅延もなく、プロジェクトを無事に完了させることができました。

開発イメージを持ってローコード製品を選ぼう

では、ローコードで作るとき、どんな視点をもって製品を選べばよいのでしょうか。まずはQCDの観点が挙げられると思います。

【QCDの観点】
・品質
システムの要件をしっかり実現できるか、セキュリティや性能など目に見えない品質も十分か
・コスト
長期間利用するシステムで機能拡張や性能拡張があっても、コストを抑えられるか
・開発期間
サービスインまでにシステムを完成させることができるか

システムの製品を評価するときは、目に見えやすいライセンス費用に意識が向きがちですがそれだけではありません。

第一に、品質をしっかり作るために、思ったように仕様をカスタマイズできる製品かどうか吟味する必要があります。ノーコードで簡単に作れるかよりもむしろ、ローコードで様々なカスタマイズポイントが用意されているか、プロ開発者向けの開発フレームワークが提供されているか、といった観点で評価するとよいでしょう。特にカスタマイズ性が高いのは開発フレームワークのある製品です。

次に、思い描いたような開発を行えるかという観点です。というのも、製品によって対象とする開発者は異なります。市民開発者向けの製品の場合、多くはインストール作業のないクラウドサービスとして提供されています。一方でプロ開発者向けの製品の場合、開発生産性を高めるためのツールが多く提供されています。製品によって、ノーコード主体の開発、ローコード＋プロコード主体の開発、と開発手法も違ってきます。自社だけでシンプルなシステムを作れるノーコード主体の製品、ベンダーとともに複雑高度な開発を行えるローコード＋プロコード製品といった具合です。

最後に、ライセンスの費用構造の観点です。サーバーCPU数ベースの製品や、システムのユーザー数ベースの製品、なかには画面やAPI数などシステムの規模に応じて費用が変わる製品もあります。開発しようとしているシステムは、どんな費用構造が適しているか、検討おくとよいでしょう。ユーザー数が少なければユーザー数ベースの製品が適していますし、多ければ他の製品に目を向けてみるとよいかもしれません。

まとめ

ローコード製品の歴史、トレンドをご紹介しました。市民開発者向けとプロ開発者向けという２つの世界観があることを押さえておきましょう。また、製品を選ぶ時の検討軸として、思い描いている開発イメージがどちらの世界観に近いかを確認するようにしましょう。読者の皆様の職場では、システムの内製が根付いているでしょうか。もし内製に少しでも不安がある場合は、ローコード製品を導入する前に、SIerや製品ベンダーに相談してみましょう。自社の要件に応じた製品の向き不向きが分かると思います。

一番もったいないのは、内製を志してローコード製品のライセンスを購入した後、内製せずにベンダーに任せにしてしまうことです。一方で、複雑・高度なシステム開発を外製しようとしたところ、そのローコード製品で開発できるSIerが日本に存在しなかった、という事例もあります。

iPLAssはSIerに外製できますし、ある程度の複雑性のシステムはローコードで構築することもできます。電通総研は、プロ目線で、システム要件に一番適した製品をご提案可能です。ローコード製品の選定の際は、検討候補に入れてみてはいかがでしょうか。

当サイトでは、ノーコード開発ツールやローコード開発プラットフォームを利用し、業務システムの開発を効率化したいエンジニアの方や、会員サイト構築などの新規事業の目的を達成したい方へ、ダウンロード資料をご用意しております。ぜひ資料をご覧いただき、ご活用ください。