ノーコード製品の功罪ーー「今の業務を変えたくない」がDXを失速させる

エンジニアが持つ特別な技術力がなくても、というキャッチコピーとともに世に送り出されたツールは、いままでたくさんありました。

生成AIは言うに及ばず、古くはSQLなどもそうでしたし、RPAも該当するかも知れません。

そんなラインナップの1つに並ぶのが「ノーコード/ローコード製品」です。
プログラムコードを書かずに、GUI(画面操作 = ノーコード)や、Excelの関数程度のコーディング(ローコード)でシステム構築を行うことを目的とした製品群です。

SalesforceやKintoneなど「非エンジニアでも業務改善に資する製品」として一定の成長を見せてきたこの分野ですが、一方で、導入企業は本当にそのメリットを適切に享受してきたのか、という疑問も感じます。

今回は、ノーコード・ローコード製品の「功罪」、特に私たちがついハマってしまう「妥協できない罠」について深掘りしてみたいと思います。

1. 爆速開発は、なぜ失速するのか

ローコード/ノーコード製品の魅力は、言うまでもなくスピードです。
製品側で用意されている標準機能群を活用しながら、「まず動くもの」を爆速で作れるのがメリットです。
だからこそ、

• 小さく始める

• 素早く試す

• 現場で改善する

というアジャイル的な進め方と、とても相性が良い。
「80点のものを早く出し、残り20点は運用しながら育てる」という思想の上に成り立っているプラットフォームだと、私は捉えています。

ところが、実際の現場では、強烈な“抵抗”が発生します。

「今の業務フローは変えられない」
「このボタンはこの位置でないと困る」
「例外処理も全部対応してほしい」

こうした要望が次々と積み上がっていくのです。

もちろん、現場にも理由があります。

長年運用されてきた業務には、それぞれ「その形になった理由」があります。過去の障害対応、運用事故、属人化の反省...そうした積み重ねの上で、現在の業務フローは成立しています。

だから、現場の細かな要望は、単なるワガママではありません。
むしろ、「業務を止めたくない」という極めて真っ当な危機感だったりします。(一方で、変えるのであればそれなりの説明が必要だから、という理由で、それを回避するために頑なに現行踏襲を譲らない勢力も一定数います)

ですが、その要望をすべて取り込もうとした瞬間、ローコード/ノーコード製品は、現場に対して牙を剥き始めるのです。

2. 「既製品のスーツ」を、フルオーダーに作り替えるという不条理

ローコード/ノーコード製品は、「既製品のスーツ」に似ていると思います。完璧なフィットではなくても、比較的安く、早く、そこそこ見栄えの良いものを手に入れられる。それが最大のメリットだと思います。

にも関わらず、時としてこんなことが起きます。

「袖の形を変えてほしい」
「ポケットを5つ追加してほしい」
「裏地も全部変更したい」

つまり、“既製品”に対して、フルオーダー並みの要求が始まるのです。

結果として、プロジェクトは次のような流れに陥ります。

1. 導入側は、標準機能で素早く構築したい

2. 業務側は「今の業務を1ミリも変えたくない」という要望が積み上がる

3. 無理なカスタマイズが決まる

4. 1.～3.が繰り返され、大量の独自開発が必要になる

5. コストも期間も、フルスクラッチ並みに膨れ上がる

そして最後には、「これ、最初からスクラッチで作ったほうが早かったのでは……？」という空気が漂い始めます。

ですが、一度走り出したプロジェクトでは、その“不条理”にブレーキをかけることは簡単ではありません。

3. 損益分岐点を無視した「UXの追求」は正義か

もちろん、ユーザー体験(UX)を最優先して細部までこだわり抜く姿勢は、プロとしての矜持かもしれません。「使う人のことを考えたら、妥協なんてできない！」という想い。よく分かります。

ですが、そこには必ず「損益分岐点」が存在します。

繰り返しになりますが、ノーコード/ローコード製品の本質的な価値は、「80点のものをクイックに世に送り出し、素早く改善を回せること」にあるはず。

「100点満点のシステムをX年かけて作る」のか。それとも「80点のシステムをXヶ月でリリースし、残りの20点は運用でカバーしながら改善する」のか。

この「割り切り」ができない組織には、ノーコード/ローコード製品は単なる「制約の多い、使いにくい道具」にしかなりません。(ただし、どういう制約があるか、とか、得意分野、不得意分野をユーザー企業側に対して一定程度あらかじめ啓蒙する努力を、導入側としても忘れてはならないと思います)

そもそも「100点」の定義さえ、これだけ変化の激しい時代であれば一瞬で変わってしまいます。
本来、道具に合わせて業務をシンプル/柔軟にする勇気こそ、大切な要素なのではないでしょうか。

4. DXとは、「今の業務をそのままIT化すること」ではない

2018年、経済産業省は「2025年の壁」という言葉で、日本企業のIT構造に警鐘を鳴らしました。そこから一気に広がったのが、「DX(デジタルトランスフォーメーション)」の概念です。

DXの意味を一般的なサイトで調べてみると、以下のように説明されています。

引用：
https://monstar-lab.com/dx/about/digital_transformation/

このDXという言葉、いつしか、

のように扱われてしまっている場面も多い気がしています。
本来DXとは、単なるIT化ではなく、

• 業務プロセス

• 組織構造

• 価値提供のあり方

そのものを見直していく取り組みだったはず。

つまり、「今の業務を完璧に再現すること」が目的ではなく、「業務そのものを変えることを受け入れる」という視点が本質なのです。

ローコード/ノーコード製品が苦しくなる組織というのは、実はこの「変わる覚悟」を持てていないケースが多いように思います。

5. まとめ：まずは80点を受け入れる覚悟が、最大の武器になる

最近ではAIの進化によって、こうした「標準機能とこだわり」の隙間を埋めるコストも、少しずつ下がってきています。将来的には、AIが裏側でいい感じにカスタマイズを肩代わりしてくれる日が来るのかも知れません。

ですが、仮にそうだとしても、変化を受け入れる覚悟が必要である事実は変わりません。

「今の業務をそのままシステム化すること」が目的なのか。
それとも「ITを使って、より早く価値を届けること」が目的なのか。

「そのこだわり、80点ではダメですか？」

導入する方も受け入れる方も、常にこの問いに向き合い続ける必要があるのだと思います。