ノーコード礼賛社会へのディスリスペクト宣言
- 奧村 哲次
- 7月21日
- 読了時間: 5分
更新日：8月28日
"ノーコードが民主化？ いいえ、それは“技術の思考停止”です。"
第一章：ノーコード信者たちの幻想
ここ数年で「ノーコード万歳！」という声があちこちから聞こえるようになった。
kintone、justDB、Airtable、Bubble...
技術のない人でもアプリが作れる！ 業務改善がすぐできる！ とにかく早い！
──確かに、耳障りはいい。
でも、その実態はどうか？
「誰でも作れる」は、誰も責任を取れない世界を生んでいないか？
そのアプリ、止まったとき誰が直す？ そのロジック、誰が読める？
属人化を解消するためのDXが、逆に“ノーコード職人の神格化”を生み出している。
そして彼らが退職した瞬間、会社の業務も吹き飛ぶ。笑えないホラーだ。
さらに深刻なのは、「止まったらベンダーに頼めばいい」という勘違いがまかり通っている点だ。
例えば、サーバーやアプリが停止した場合、開発ベンダーに丸投げすればいいと安易に考えるが、
現実はそんなに甘くない。業務が止められない状況では、自社内でも復旧の見通しや判断が必要になる。
しかし、ノーコードで作られたアプリは、どこが悪いのか分からない、そもそも“どこを触れば良いのかも不明”というブラックボックス。
それを解析するには、一からモノづくりをするレベルで調査・学習をし直さなければならず、
対応できるSEが社内に存在しない──というケースが大多数。
結局、「便利だから」という理由で導入したツールが、最大のリスク要因になっていることに、気づけない企業が多すぎる。
なお、ここで強調しておきたいのは、ノーコード自体を“全否定”するものではないという点だ。
ノーコードを支持する人々の意見にも、一理ある。
技術者不足の現場で即応できる
小さく始めて、現場が業務改善を回せる
コストを抑えながらスピード感を持って導入できる
これは確かに重要な視点だ。
ノーコードは「現場が動く」ための武器になる。
だが、その“武器”を「無法地帯」にするか、「戦略の一環」として使うか。
──ここに、経営の成熟度と未来への責任が問われている。
第二章：ノーコードが生む、デジタル無能者たち
ノーコードを使っていた人が転職するとする。
次の職場にkintoneもjustDBも無い。
──何もできない。
if文もfor文も知らない。SQLも書けない。データベースの正規化も知らない。
でも前職では「DX推進担当」として重宝されていた。
これは本人が悪いのではなく、“ツールに甘えた会社の責任”だ。
「覚えやすさ」と「思考停止の許可」は違う。ノーコードは後者を助長している。
だからこそ必要なのは、ノーコードの利用と並行して、“技術の基礎体力”を社内に育てることだ。
現場主導の改善を進めるならこそ、再現性のあるスキルセットが必要なのだ。
第三章：クラウドSaaSはOK、なぜなら思想が違う
Google Apps Script や Microsoft Power Platform は一定の評価に値する。
なぜなら、これらは“自動化”や“補助レイヤー”でのノーコードだから。
GASはコードを書ける
Power AutomateもバックでAPIを使える
ユーザーが "何をしているか" を理解しながら操作できる
つまり、透明性と拡張性がある。
でもkintoneやjustDBのような“業務の心臓部に侵食するノーコード”は違う。
作った人以外読めない。止まったらおしまい。しかもコードに変換もできない。
それはブラックボックスで作った家に、住民票を移すようなものだ。
第四章：実例で見るノーコードの末路
事例1：前任者が辞めた瞬間、kintoneが操作不能に
説明書もなく、ロジックも読めず、ベンダーも連絡つかず。
「業務止まりました」と現場は阿鼻叫喚。
事例2：justDBで営業日報を全て管理 → データ全損
バックアップ設計がそもそも無い
exportすら手動で誰もやっていなかった
事例3：ノーコード職人が神のような扱い → 結果、技術継承ゼロ
属人化の極み。ドキュメントも仕様書も無い。
ローカル英雄の退職でシステムもろとも終了。
事例4：開発ベンダーに丸投げして「納品されたノーコードアプリ」
中身が分からず、トラブル発生時に「再開発のほうが早い」と言われる
業務部門はベンダー依存、情報システム部門は沈黙──まさに組織崩壊の序章
これが現実。美談ではない。
第五章：ビジネス観点での致命的リスク
ノーコードを採用した時点で、技術的な持続可能性を放棄している
継続性が担保できない（ツールに依存）
採用が難しくなる（エンジニアが敬遠）
外部連携や高度な処理に対応できない（限界が来る）
DXではなく「目先の楽さDXごっこ」になっている企業が、山ほどある。
さらに深刻なのは、この“ノーコード的発想”が別の領域に拡大していることだ。
開発ベンダー任せの丸投げ発注
コンサルが作る「見栄えの良いだけ」の要件資料
──これらはすべて「中身のないDX」だ。
“絵に描いた餅”が、現場に無理やり押し込まれていく構造そのものである。
最終章：ラフティとして、あなたに伝えたいこと
ノーコードは「使うな」と言いたいのではない。
