ノーコード／ローコードとその限界〜現場主導型DXの現在地と要件定義・開発体制の本質〜

2025.08.28

ノーコード／ローコードの普及と活用シーン

近年、中小企業から大企業まで、「DXの第一歩」としてノーコード／ローコードツール(※)の導入が急速に進んでいます。
代表的なツールにはサイボウズ社の「kintone」や、Salesforce, Inc. の「Salesforce」などがあり、弊社がご支援する企業でも導入事例が増えてきました。
これらのツールは、営業支援、業務フローの可視化、顧客対応の記録、報告書の作成など、さまざまな業務改善・効率化の実践フィールドで活用されています。

※「ノーコードツール」はコードを書かずに、ドラッグ＆ドロップや画面操作でアプリケーションを作成できるツール、「ローコードツール」は一部コードを使いながら、通常のシステム開発よりも少ない工数で開発できるツールのこと

現場で進められるDX、その魅力と限界

ノーコード／ローコードの一番の魅力は、現場主導で業務改善を進められることです。すなわち、プログラミングの知識がなくとも、現場の担当者が自らアプリを構築・修正できるため、改善のスピードが飛躍的に上がります。
特にIT人材が不足している企業にとって、この「内製化のしやすさ」は極めて大きな価値があるといえるでしょう。

さらに、kintoneやSalesforce といった主要プラットフォームはセキュリティやガバナンス面でも高水準で、例えば以下のような認証を取得しています。

kintone：SOC(※1) 2 Type II、ISMAPクラウドサービスリスト (※2)
Salesforce ：ISO 27001 (※3) 、SOC 1 Type II、SOC2 Type II、SOC 3、FedRAMP (※4)

そのため、金融・医療・公共分野など、厳しいセキュリティ要件が求められる領域でも比較的安心して導入できます。

※1 外部委託先やクラウドサービス提供者などが、情報セキュリティや業務プロセスをどのように管理・運営しているかを第三者が監査・検証した報告書のこと。SOC 1は財務報告に直結する内部統制、SOC 2は ITサービス全般のセキュリティや信頼性を評価
※2 政府情報システムのためのセキュリティ評価制度（ISMAP）に基づいて、安全性が評価されたクラウドサービスのこと
※3 情報セキュリティマネジメントシステム（ISMS）に関する国際規格
※4 クラウドサービスを対象とする米国連邦政府の調達要件に関する認証制度

「ノーコードだから要件定義は不要」は大きな誤解

しかしながら、こうした手軽さゆえに、「ノーコードだから要件定義 (※)は必要ない」という誤解が生まれがちなことも事実で、ここが極めて危険な落とし穴です。
実際、世界中のITプロジェクトの失敗のうち、70％以上が要件定義の不備に起因しているという調査データもあります（Info Tech Research Group; Boardroom Metrics 2013）。
つまり、どれだけ簡単にアプリを作れても「何を実現するのか、それがなぜ必要か」が明確でなければ、失敗に終わるということです。

ノーコードはあくまで作るハードルを下げたツールであり、「何を作るべきか」を決める重要性は、従来の開発と変わりません。

※システム開発や業務プロジェクトにおいて「何を実現するか」を明確にする工程

業務が整理されていない現場で起きていること

弊社の支援現場でもよく見られるのが、そもそも業務フローやルールが可視化されておらず、改善すべき業務の全体像が分からない、というケースです。
この状態でノーコードツールを導入してしまうと、「上手く使いこなせない」や「使われないアプリが量産される」といった事態に陥ってしまいます。
さらに、ノーコードでは対応しきれない処理（条件分岐、複雑な演算など）や、他システムとの連携が発生すると、コーディングやAPI連携(※)のための開発が必要になってきますが、ここで新たな課題が浮上します。

※あるソフトウェアの機能を別のソフトウェアから呼び出す仕組みを表します。Application Programing Interfaceの頭文字をとったもので、「インターフェース」という言葉が意味するように「境界線」「接点」を用いてアプリケーションをつなぐ機能を提供します。使用すれば、異なるソフトウェアやプログラムを連携させられるようになります。

「API連携だけやってほしい」は誰がやる？

よくあるのが、「ノーコードツールで作ったアプリケーションと他のクラウドサービスのAPI連携だけ外注したい」というニーズです。
しかし、この「部分的な開発」は誰に頼めばいいのでしょうか？
実際には、こうした中途半端な開発依頼を柔軟に引き受けてくれるベンダーは非常に少ないのが現実です。
多くの開発会社は基本的に要件定義から運用までの一括受託が前提であり、API連携のみの開発のようなスポット開発は、収益性やリスクの面から断られるケースが多いです。
その結果、せっかく業務部門がノーコードツールでアプリの土台を作っても、あと少しの技術支援が足りずに止まってしまうケースが後を絶ちません。
これは、システムの開発現場で部分的な技術支援を柔軟に提供できる体制が不足していることの表れでもあります。

GAが考える、ノーコード／ローコードツール導入の成功条件

弊社のDXアドバイザリーでは、ノーコード／ローコードツールを「アプリをすぐ作れる便利なツール」ではなく、「業務を見える化し、整理していくプロセスの起点」として位置づけています。
確かにノーコード／ローコードツールは便利な道具ですが、文字通り「道具」である以上、明確な目的と設計思想がなければ成果にはつながりません。

私たちは、以下の3つがポイントになると考えています。

① 業務フローの整理と要件定義の徹底
現行の業務フロー（As-Is業務）の整理と、あるべき姿の業務フロー（To-Be業務）の構築を行い、改善対象となる業務の目的や構造、期待する成果を明確にする。

② 部分的な開発に柔軟に対応できる技術支援体制の確保
ノーコードで補えない部分（API連携やコーディングを伴うカスタマイズなど）を担える外部パートナーの確保や内部人材の育成を行う。

③ セキュリティとIT内部統制の設計
ノーコードツール（それによって作成されたアプリを含む）の管理体制、アクセス制御、情報統制ルールなどを明文化・整備する。

まとめ：道具に振り回されるのではなく、使いこなす設計を

ノーコード／ローコードツールは、やりたいことを素早く形にできる有力な選択肢で、DX推進の端緒とすることを考えておられる方も多いと思います。
しかし、そこに明確な業務理解と設計思想、そして技術支援の仕組みがなければ決して DX は起こりません。
またそれを真に使いこなすには、準備・設計・支援体制の整備が不可欠です。
道具に振り回されるのではなく、道具を使いこなすための準備と設計こそが、次のDXフェーズを成功に導く鍵になると考えています。

お問い合わせはこちら