ノーコードが遅れて連れてくる責任──便利さの裏にある大切なこと

ノーコード／ローコードツールは、現場に近いところで小さな不便を解いてくれる道具です。けれども、作れてしまうからこそ、あとから見えてくる問いがあります。

※執筆にあたり生成AIとの対話を活用しています。

小さな改善が、業務システムになるとき

ノーコード／ローコードツールというものがあります。

プログラムを一から書かなくても、画面や入力フォームを作り、データを保存し、承認フローを回し、通知を飛ばすことができる。業務改善や内製化の文脈で、こうした道具が使われることも増えました。

たしかに、便利な道具です。

紙、Excel、メールで回していた小さな業務を、入力フォームやワークフローに置き換える力があります。現場の困りごとを、現場に近いところですばやく解くことができる。

だから私は、ノーコード／ローコードツールそのものが悪いとは思っていません。むしろ、現場改善の道具としては、かなり強いものだと思っています。

ただ、ここで少し立ち止まりたくなります。

現場の小さな改善として作られたものが、いつの間にか部門の業務を支える仕組みになることがあります。さらに、便利だからという理由で、部門を越えて使われ始めることもあります。

そのとき、それはもう単なる改善ツールではありません。

業務の一部を支える、システムです。

だとすれば、問うべきことは「作れるかどうか」だけではありません。

なぜそう作ったのか。
どこまで使ってよいのか。
止まったときにどうするのか。
作った人がいなくなったときに、誰が面倒を見るのか。

速く作れる道具ほど、こうした問いを後回しにしやすい。
そこに、ノーコード／ローコードの静かな怖さがあるように思います。

なぜ、それは魔法のように見えるのか

ノーコード／ローコードツールが魅力的に見える背景には、従来型の業務システムへの不満があります。

高い。
時間がかかる。
自分たちの思った通りのものにならない。
完成するころには、もう業務の事情が変わっている。

こうした不満は、現場の実感としてよくわかります。

その点、ノーコード／ローコードは魅力的です。

内製だから安く見える。
自分たちで作るから、思った通りに作れる。
作ったら、すぐに使える。

まるで、従来の業務システム開発に対する不満を、一気に解消してくれる魔法の道具のように見えます。

しかし、ここに一つ落とし穴があります。

「高い」には、高いなりの理由がある。
「遅い」には、遅いなりの理由がある。
「思った通りにならない」には、思った通りに作ってはいけない理由が含まれていることもある。

業務システムをきちんと作るということは、単に画面を作ることではありません。

業務を整理し、例外を洗い出し、異常時の振る舞いや権限、データ、監査性を設計する。そうした見えにくい作り込みに、費用と時間がかかっています。

もちろん、すべてのシステムに重厚な作り込みが必要なわけではありません。小さな業務改善に、過剰な手続きを持ち込む必要はないでしょう。

けれども、安く早く作れたように見えるものが、本当に必要な品質まで作り込まれているとは限りません。

「思った通り」の危うさ

もう一つ気になるのは、「自分たちの思った通りに作れる」という言葉です。

これは、ノーコード／ローコードの大きな魅力です。現場の人が、自分たちの困りごとを、自分たちの手で形にできる。それはとても良いことです。

ただし、「思った通りに作れる」ことと、「業務の本質を解いている」ことは、同じではありません。

使いにくいExcelを入力フォームにする。
メールで回っていた申請を承認フローにする。
確認漏れを防ぐために通知を飛ばす。

これらは、たしかに改善です。
痒いところに手が届く感じがあります。

けれども、その痒みはどこから来ているのでしょうか。

そもそも、その入力項目は必要なのか。
その承認は本当に必要なのか。
その転記作業は残すべきなのか。
その業務フロー自体を見直すべきではないのか。

そこを問わないまま、目の前の不便をそのままデジタル化すると、業務改革ではなく、既存業務の写し絵になります。

もちろん、作っては直し、作っては直しを繰り返すこと自体は悪くありません。その反復を通じて、業務への理解が深まり、よりよい形に近づいていくなら、それはよいイテレーションです。

けれども、ただ目の前の不便に反応しているだけなら、それは高みに向かう改善ではなく、せっかちな手直しになってしまう。

痒いところに手が届くことは大切です。
しかし、掻いているだけで体質が変わらないのであれば、それは業務革新というより、よく効く消炎剤に近いのかもしれません。

ノーコードというビュッフェ

ノーコード／ローコードツールは、少しビュッフェに似ています。

あらかじめ料理は並んでいる。
好きなものを選べる。
皿に盛れば、すぐに食べられる。

入力フォーム、データベース、承認フロー、通知、ダッシュボード、外部連携。いろいろな部品が用意されています。それらを選んで組み合わせれば、業務システムらしきものは、かなり早く作ることができます。

けれども、ビュッフェだからといって、何をどの順番で食べても、同じ満足になるわけではありません。

前菜があり、主菜があり、口直しがあり、最後にデザートがある。コース料理には、長い時間をかけて磨かれてきた順序と構成の知恵があります。

ビュッフェでも、その作法を知っている人は、満足度の高い食事ができます。逆に、目についたものを全部一皿に盛ってしまえば、お腹は膨れるかもしれませんが、食事としての体験は散らかってしまいます。

ノーコード／ローコードも、これに近いと思うのです。

内部構造を一から作らなくても済むように、部品は用意されている。
けれども、それらをどう組み合わせるかは、依然として設計です。

どのデータを正とするのか。
どの処理を自動化し、どこを人間判断に残すのか。
どの例外を扱い、どの例外を扱わないのか。
誰が入力でき、誰が承認でき、誰が見られるのか。
止まったときに、どう復旧するのか。
作った人がいなくなったときに、誰が面倒を見るのか。

こうした問いは、ノーコードになったからといって消えるわけではありません。

むしろ、コードが見えないぶん、設計の問いは見えにくくなります。
コース料理の作法を知らずにビュッフェを使うこと。それがそのまま、次の問いにつながります。

型破りと型無し

自由に作れることは、良いことです。

けれども、自由に作れることは、型が不要になることではありません。

型を知ったうえで崩すなら、それは型破りになります。
けれども、型を知らないまま、とりあえず動くからと業務に組み込むなら、それは型破りではなく、型無しに近い。

型無しのシステムは、最初は軽やかに動きます。

現場の反応も良く、面倒だった作業が楽になり、作った人も使う人も手応えを感じます。

しかし、しばらくすると別の顔が見えてきます。

なぜこの項目が必須なのか、誰も説明できない。
なぜこの承認経路なのか、わからない。
なぜこの例外は処理できないのか、わからない。
どの範囲まで使ってよいものなのか、判断できない。
作った人に聞かないと直せない。

そして、その作った人が異動する。
退職する。
別の仕事で忙しくなる。

そのとき、部門には「動いているもの」だけが残ります。

けれども、なぜそう作ったのか。
何を採用し、何を棄却したのか。
どこまでを許容し、どこから先は危険だと考えたのか。

そうした設計思想や意思決定の記録が残っていなければ、システムは急に信用できないものになります。

この劣化のパターン自体に、見覚えがあります。構造として、です。
EUC、Excelマクロ、VBA、RPA。
私たちは、これまでも似た道を何度か通ってきたのではないでしょうか。

最初は現場の小さな工夫だった。
便利だから使われた。
使われるから業務の中核に入り込んだ。
中核に入り込んだころには、作った人はいなくなっていた。
仕様書もない。
なぜそうなっているのかもわからない。
それでも、止められない。

ノーコード／ローコードが、必ず同じ道をたどると言いたいわけではありません。
ただ、同じ構造を持ちうることは、すでに見えているように思います。あとは、使う側がそれを知っているかどうかです。

※「型破り」と「型無し」については、別の記事でも考えています。守破離という言葉を手がかりに、型を知ることと、型を破ることの違いを、エンジニアの現場から眺めたものです。

ガバナンスは、規定があれば足りるのか

ここで、ガバナンスの問題が出てきます。

多くの会社では、ノーコード／ローコードツールを使うにあたって、IT部門や総務部門が社内規定を作っていると思います。利用できるツールや扱ってよいデータ、権限管理、セキュリティ上の注意点などを定めている会社も多いでしょう。

それは大切です。

しかし、問題は規定があるかどうかだけではありません。
その規定の意味を、利用部門が理解しているかどうかです。

便利なものは広がります。
広がること自体は悪いことではありません。

ただし、部門内の小さな改善ツールとして作られたものが、いつの間にか部門を越えて使われ始めることがあります。さらに、複数の系統をまたぐ業務基盤のように扱われることもあります。

そのとき、そのシステムは本当にそこまでの利用に耐えるものなのでしょうか。

誰が品質を見ているのか。
誰が異常時の振る舞いを確認しているのか。
誰が権限と監査性を見ているのか。
誰が、これは全社展開してよいものではない、と止めるのか。

ここが曖昧なまま進むと、しばらくはうまく動きます。
むしろ、うまく動くから広がってしまいます。

けれども、作った人が異動する。業務を知っていた人が退職する。ツールの仕様が変わる。接続先のシステムが変わる。

そのとき、部門に残るのが「動いているもの」だけで、なぜそう作ったのか、どこまで使ってよいのか、何をしてはいけないのかが残っていなければ、そこから先は苦しくなります。

部門の中だけで済めば、まだよいかもしれません。
しかし、展開先の部門や系統にまで影響が広がっていれば、問題はその部門だけでは済まなくなります。

ノーコード／ローコードの怖さは、作れることではありません。
作れてしまうことです。

しかも、作れたものが、業務システムとしてどこまで耐えられるのかを判断する前に、便利さによって広がってしまうことです。

作れてしまうものを、誰が止めるのか

ここで問われるのは、利用者の操作スキルだけではありません。
むしろ問われるのは、組織としての判断リテラシーです。

これは部門内の小さな改善に留めるものなのか。
業務基盤として扱ってよいものなのか。
止まったときに誰が責任を持つのか。
キーマンが異動しても維持できるのか。
部門をまたいで使わせてよいのか。

こうした判断ができなければ、どれほど便利に動いていても危ういと思います。

特に、部門長や経営層には、この判断リテラシーが必要です。

作れるかどうかではなく、業務として持ち続けられるかどうか。
便利かどうかではなく、組織として責任を持てるかどうか。
安く早くできるかどうかではなく、あとから説明できるかどうか。

そこを見なければならない。

このリテラシーは、ユーザー部門だけで育つものではありません。現場の痛みを知る人と、長く持ち続ける作法を知る人が、同じ言葉で話せる場所。そこに、鍵があるように思います。

その関係性を育てるために、サプライヤーにもできることがあると思います。

ノーコード／ローコードは便利な道具です。だからこそ、その便利さだけでなく、設計やガバナンスの注意点もセットで伝えてほしいと思います。

ツールが魔法のように見えるからこそ、その裏に残っている設計や責任の問題に、利用者自身が気づくのは難しい。

この道具は、設計を不要にするものではありません。
設計の形を変えるものです。

コードの中にあった設計の痕跡が、画面やフローや設定の中に散らばる。だからこそ、別の形で設計思想を残さなければならない。

速く作れるものほど、あとから責任が来る

ノーコード／ローコードは、悪者ではありません。

現場の不便をすばやく解くことができる。
小さく作って試すことができる。
利用者に近いところで改善を回すことができる。

それは、間違いなく価値です。

ただし、速く作れることと、長く信頼できることは同じではありません。

早く皿に盛れることと、満足できる食事になることは違う。
痒いところに手が届くことと、体質が改善されることは違う。
思った通りに作れることと、業務の本質を解いていることは違う。

ノーコード／ローコードが広がるほど、この違いは大切になります。

コードを書かないから、設計が不要になるのではありません。
コードを書かないからこそ、設計の意思をどこに残すのかが問われます。

なぜそう作ったのか。
何を残し、何を残さないと決めたのか。
どこまで使ってよいのか。
誰が責任を持つのか。

それらが残っていなければ、速く作れたシステムは、遅れて責任を連れてきます。

便利な道具ほど、静かに問われているのだと思います。

それは、何を作れるかではありません。

何を作らないと決めるか。
どこまで使うと決めるか。
そして、その意思をどこに残すか。

ノーコードというビュッフェにも、やはり設計の作法は必要なのです。

※似た問いを、別の記事でも考えています。
AIで作った試作品が、そのまま業務システムとして使われかねない危うさについて書いた記事です。
動くものと、持ち続けられるもの。その間にある距離を、少し違う角度から眺めています。