企業の関心が高まる「ローコード開発ツール」のメリットとデメリット

「システム開発」の進め方を変えていかなければならない理由

デジタルトランスフォーメーション（DX）に取り組む企業では、常に「ITシステム」への新しいニーズが生まれます。その時々のビジネス要求やユーザーニーズに合ったシステムを迅速に作りあげ、改善できる体制があることが、システムのビジネス貢献を最大化するためには不可欠です。

しかし、多くの日本企業は、ここで大きな課題に直面します。これまでに行ってきた「システム開発」の進め方では、こうしたニーズに応えられないためです。

システム開発にあたり、一からプログラムコードを書いて作っていくやり方を「スクラッチ開発」と言います。かつて、多くの日本企業では、このスクラッチ開発を行い、自社の業務プロセスに合わせたシステムを一から作っていました。

スクラッチ開発は、「仕様づくり」から始まり、システムの「設計」、システムを動かす「プラットフォームの検討と選択」、開発時や本稼働時に必要な「ITインフラの検討と調達」、選択したプラットフォームのルールにのっとった「言語によるプログラミング」（コーディング）、作成したプログラムが仕様どおりに動くかどうかの「テスト」など、さまざまな工程を経て進められます。工程は、基本的に上流から下流へ、順番に進むことが前提となっており、こうした工程の進めかたは、水が上から下へ落ちていく「滝」になぞらえて「ウォーターフォール」と呼ばれます。

この方法でシステムを作るためには、システム設計やプログラミングの高いスキルを持ったエンジニアが必要です。また、短期間でのリリースを目指すほど、必要なエンジニアの数は増え、プロジェクト全体のコントロールも難しくなっていきます。結果的に、事業会社にとしては、システム開発とその運用管理について、外部のITパートナーやシステムインテグレーターに強く依存せざるを得ない状況になります。

この方法の問題点は、立案からリリースまでの時間が長くなりがちで、市場環境やユーザーニーズが変化するスピードへの追従が難しいことです。基本的に最初に決めた「仕様」は変化しない前提があるため、時間をかけて仕様どおりのシステムが作れたとしても、リリース時には、ニーズそのものが変わってしまっており、システムが価値のないものになっているという状況が起こります。

• 

  従来の開発方法によって、DXに取り組む企業が抱える課題（出典元 Ridgelinez）

DXに取り組む企業は、これまで以上に、さまざまなタイプのシステムを企画、開発、運用、改善していく必要があります。その際、旧来のようなシステム開発の進め方だけに頼っていては、ビジネスニーズに応えられません。そうした状況の中で、今、注目を集めているのが「ローコード開発ツール」によるシステム開発です。

同じ「ローコード」でも自由度・柔軟性・コストは千差万別

現在、市場には「ローコード」（あるいは「ノーコード」）をうたう多くの製品があります。それらに共通する特長のひとつは、名前で示されているとおり、システム開発にあたって「プログラミング言語によるコーディングがほとんど（あるいは全く）必要ない」点です。

一般的なローコード開発ツールでは、主にマウス操作を基本に、あらかじめ用意されている「部品化」されたさまざまな処理を、フローチャート作成ツールのようなグラフィカルな画面上でつなぎ合わせてシステムを作っていきます。そのため、特定のプログラミング言語に対する専門的なスキルは不要です。結果として、仕様の策定から実際に動くシステムができるまでの期間を短縮できます。また、そのツールが使える開発者の確保や育成も、スクラッチ開発の場合と比べて低コスト、短期間で行えます。

具体的な製品の比較検討において注意すべきなのは、それぞれのツールで作れるシステムの「自由度」や「規模」、セールスポイントとなる「特長」が千差万別である点です。背景には、このカテゴリに属する製品の「源流」が多様なことがあります。

例を挙げると、Webデータベースやグループウェアのパッケージ、あるいはSaaSに付属するカスタマイズ機能、ワークフロー作成機能を指して「ローコード」「ノーコード」と呼ぶケースがあります。一方、かつては「CASE」や「超高速開発」といったジャンルに分類され、主にスクラッチ開発の効率化や標準化を支援するような機能を提供していたツール群の発展型が、現在「ローコード開発ツール」と呼ばれている場合もあります。

総じて、前者のような既存アプリケーションのカスタマイズに特化したツールは、開発できるシステムの自由度や柔軟性が低い代わりに、開発者に求められるスキルレベルも低く、ライセンスコストも安価な傾向があります。逆に、後者のような「超高速開発環境」の発展型にあたるツールは、開発者に業務プロセスやシステムについての一定レベルの知識が必要で、ライセンスコストも比較的高価になります。その代わり、開発できるシステムの自由度や柔軟性は高く、スクラッチ開発で作るのと遜色ない規模や機能を持つシステムを作ることもできます。

次項では、ローコード開発ツールのメリット・デメリットについて紹介しますが、本稿では主に、後者のような「超高速開発環境」の発展型としてのツールを念頭に置いて説明していきます。

「得意」と「不得意」の両方を知ることがローコード開発成功のカギ

• 

  「ローコード開発ツール」のメリット・デメリット（出典元 Ridgelinez）

企業が、ローコード開発ツールの活用から得られる最大のメリットは「システム開発の効率化と迅速化」です。

前述のように、ローコードツールには、業務システムに必要となる一般的な機能が、オブジェクト（部品）やテンプレートとしてあらかじめ用意されており、それらを組み合わせたり、一部を変更したりすることで実際に動くシステムが作れます。そのため、スクラッチ開発の場合と比べて、開発期間を大幅に短縮できます。

また、見落とされがちなポイントとして「運用負荷の低減」があります。システムを動かすためには、アプリケーション以外に、アプリケーションの実行に必要なOSやミドルウェアが必要です。これらは「実行環境」と呼ばれますが、特にオンプレミスやIaaSがインフラの場合、これらの脆弱性対応、バージョンアップ、メンテナンスなどは、すべてユーザー側で行う必要があります。ローコード開発ツールにおいては、こうした実行環境をツールベンダーが提供し、メンテナンスしているケースが多く、ユーザーの作業負荷を軽減できます。

ローコード開発ツールは、「システム内製化」との相性が良い点もメリットです。高いITスキルやコーディングスキルが必要となるシステム開発では、多くの場合、そうしたスキルを備えたグループの開発会社、社外のITパートナー、システムインテグレーターに開発を外注することになります。その際、ユーザーはITパートナーに要求を伝え、パートナー側のエンジニアがシステム化の要件を定義して、システムを作っていきます。

パートナーにシステム開発を任せることで、ユーザー企業は自分たちの本業に注力できますが、半面、実際にシステムを使うユーザーと作り手が異なるため、できあがったシステムに対してユーザーが「求めていたものではない」「何か違う」といった不満を感じるケースが多々あります。また、細かな改善や修正も簡単にはできないため、結果的に「ユーザーの満足度が低いシステム」になってしまうリスクが高くなります。加えて、パートナーへの依存が強くなりすぎることで、ユーザー側のITスキルが空洞化するという、DXを目指す企業にとっては避けたい弊害もあります。

ローコード開発ツールは、システム開発に必要なスキル習得の難易度を下げ、「動くシステム」ができるまでの時間を大幅に短縮します。この特性は、従来の「ウォーターフォール」型と異なり、要求が変化することを前提に短期間でのリリースと改善を繰り返しながらシステムの完成度を上げていく「アジャイル」型のプロセスとも相性が良いものです。

こうした特性により、自社内に新たに開発チームを組織したり、実際のユーザーにもシステム開発に参画してもらい、自分たちのニーズにより良く応えるシステムを作っていったりするような「システム内製化」を進めるためのきっかけにもなります。内製化の取り組みは、システムを「利用するだけ」、あるいは「企画するだけ」に留まっていた社内人材を、DXをけん引できる「デジタル人材」へと転換していくための一助にもなるはずです。

一方、デメリットとしては「適用するシステムの専門性や複雑さによっては、生産性向上が見込めないケースがある」ことが挙げられます。

先述したように、ローコード開発では部品やテンプレートを組み合わせてシステムを作ります。この時、既に部品が存在するような一般的な処理の組み合わせで完成するものであれば、高い開発効率が期待できますが、逆にシステム化したい業務の専門性が高く、複雑なルールやプロセスを必要とする場合には、既存部品による実現が難しいケースも出てきます。その場合は、自分たちで新たな部品を作りますが、その時に言語によるプログラミングが必要な場合があります。その際の生産性や難易度は、スクラッチ開発とあまり変わりません。

また、ローコードで開発したシステムは「ブラックボックス化」しやすい点にも注意すべきです。ローコード開発の「難易度の低さ」や「生産性の高さ」は、「1人（あるいは少人数）で、次々とシステムを開発できる」という利点である半面、「他の人が手を入れづらい複雑な処理や、機能の分割が適切でない巨大なシステムができあがってしまう」リスクも内包しています。

専門組織が開発をする場合、設計や開発にまつわるさまざまなルールを「標準化」し、運用開始後のメンテナンス性や改善性を高めたり、一度作成した部品の再利用によって生産性を上げたりといった取り組みを行います。ローコード開発においても、ある程度、こうしたルール決めをしておかなければ、せっかく作ったシステムが「ブラックボックス化」し、運用負荷や改修コストが増していく状況が生まれます。

ローコード開発の実践経験から得た「教訓」

Ridgelinezでは、実際に社内業務システムの一部をローコード開発環境で内製しています。

同社では、事業開始にあたって、必要な業務システムを限られた期間内で迅速に準備する必要がありました。そこで、スクラッチ開発を避け、クラウドサービスとローコード開発ツールを活用してシステム構築を行うことを基本方針とし、現在も実践しています。

新規システム開発においては、複雑な処理が要求されないユーザーインターフェース（UI）と、各種SaaS間の連携の領域でローコード開発を採用しています。また、ブラックボックス化を避けるため、開発時には複数の開発者が内容を相互に確認する「ペアプログラミング」の手法を採用しています。

• 

  Ridgelinezのローコード適用事例（出典元 Ridgelinez）

新規システムの開発自体は順調に進み、無事に初回リリースにこぎ着けました。しかし、その後の機能改修時に、毎回、テストに膨大な工数がかかってしまうという問題に直面します。

これは、先ほどデメリットに挙げた「開発ルールの標準化」が不十分だったための失敗です。ローコード開発の便利さに目を奪われ、「モジュールを適切に分割する」といったシステム上の設計検討やルール決めを事前に十分に行わなかったため、モノリシックで巨大なモジュールができあがってしまいました。その結果、改修時のテストにおいて、条件分岐や網羅のテスト工数が膨大になるという状況を招きました。

ローコード開発においても、マイクロサービス設計を意識した、初期段階での適切なモジュール分割が重要であることを痛感した事例であり、大切な教訓になっています。

IT戦略に「ローコード開発」をうまく取り入れてDXを加速する

今回は、近年企業の関心が高まっている「ローコード開発ツール」について説明しました。冒頭で「ローコード開発」と対になる旧来の開発手法として「スクラッチ開発」を引き合いに出しましたが、決して「スクラッチ開発」という手法自体が「悪」というわけではありません。

「一から作る」ということは、大部分を「思いどおりに作れる」ということでもあります。特に、専門性の高い用途において、高い信頼性や堅牢性、性能が求められるシステムを作りたい場合には、現在でもスクラッチ開発が必要になるケースが多くあります。

「ローコード開発」も、システム構築にまつわるすべての課題を解決できる、万能な手法ではありません。いずれも、メリットとデメリットを理解した上で適切に採用することで、その長所を最大限に引き出すことができます。

また、ローコード開発ツールは「簡単に作れる」という部分が注目されがちですが、特にクラウドと組み合わせて利用する場合には、インフラを含む実行環境の運用管理をアウトソースできるというメリットにも注目したいところです。従来のシステム開発で大きな負担になっていた、実行環境の構築運用にまつわるIT投資を、ビジネス価値創出のための投資に転換する契機になります。

ローコード開発とクラウドの組み合わせは、システム開発だけでなく、デリバリ（展開）のアジリティを高める上で、極めて効果的です。クラウドのアーキテクチャに対する理解も並行して進めれば、最新のクラウド技術を活用して、システム開発や運用を高度化し、システムの価値を最大化する「クラウドシフト」の実現に近づけます。

経営層は、このようなシステム開発のトレンドに着目し、積極的な導入検討を促すことで、効果的に自社のDXを進め、IT投資の効果を最大化することができるでしょう。