バイブコーディングや生成AI活用の話になると、多くの企業は最初に現場へ目を向ける。エンジニアがどう使うか、開発部門がどう変わるか、どんな生産性向上が見込めるか。もちろんそれも重要だ。しかし、本当に企業変革を止めている最大要因は、現場ではないことが多い。実は最も危ないのは、判断する立場にいるのに、自分では使いこなしていない管理職や責任者である。
これはかなり本質的な問題だ。
なぜなら、組織は“現場の理解”だけでは変わらないからである。
変革が本当に進むかどうかは、最終的には予算、評価、ルール、権限、責任分解、スケジュール、調達方針を誰が決めるかにかかっている。そしてそれを決めるのは、経営層や部門責任者、PM、情報システム責任者である。
ところが、ここに大きなねじれが生まれている。
企業の中では「AIを活用したい」「バイブコーディングを試したい」という声が現場から上がる。だが、それを承認する側の人間が、AIとの対話によってどこまで試作できるのか、どこまで判断速度が変わるのか、何が数時間で作れて何がまだ難しいのか、その感覚を持っていない。すると何が起きるか。旧来の発想で新しい手法を管理しようとする。
その結果、組織にはこんな言葉が増える。
「AIは使ってもいいが、本番は従来通りで」
「まずはPoCだけで様子を見よう」
「利用ルールを全部整備してからにしよう」
「承認フローは従来と同じにしよう」
「設計書と要件定義書は従来の形式で必須にしよう」
「品質担保のためレビューを増やそう」
一つひとつはもっともらしい。だが、それを重ねれば重ねるほど、バイブコーディングの本質は死ぬ。なぜなら、その価値は速度と試行回数にあるからだ。思いついたものを作り、見て、触って、壊して、直して、数時間から数日単位で方向修正できることに意味がある。それを旧来型の管理思想で囲い込んだ瞬間、新しいやり方はただの“AI風味の従来開発”に成り下がる。
ここで企業が直視すべき現実がある。
それは、理解していない人が管理すると、新しい手法は必ず旧来の都合で骨抜きにされるということだ。
現場のエンジニアがどれだけ可能性を感じていても、決裁者がそのインパクトを身体感覚で理解していなければ、意思決定は慎重になりすぎる。慎重であること自体が悪いのではない。しかし、変化速度が競争力そのものになっている局面では、慎重さがそのまま競争力低下に直結する。
たとえば、バイブコーディングで試作した画面や機能が一日で出てくる現場に対し、上司が「次回の定例会で確認しよう」「その前に要件整理をしよう」「品質部門と相談しよう」と言っていたらどうなるか。現場はすぐに学習する。この組織では速く動いても意味がない、と。すると誰も挑戦しなくなり、新しい開発思想は芽が出る前に枯れる。
しかも厄介なのは、こうした管理職が自分では変革を妨げている自覚を持ちにくいことである。本人はむしろ、責任ある立場として慎重に進めているつもりだろう。だが実際には、旧来の成功パターンを新しい時代に無理やり当てはめているだけだったりする。
ここで必要なのは、管理職への教育ではなく、管理職自身の体験である。
経営者、事業責任者、部門長、PM、情報システム責任者。少なくとも開発の方向性を決める人たちは、自分の手でAIに触れ、仮説を投げ、画面を作らせ、仕様を変え、再出力させ、そのスピード感を体験しなければならない。
これは単なる勉強ではない。
身体感覚を持たないままでは、判断基準が変わらないからだ。
たとえば、自分で触れば分かる。
「このレベルのプロトタイプなら、会議資料で議論するより先に作って見たほうが早い」
「このUIの修正は、見積もりを取るまでもなくすぐ試せる」
「この要件は言葉では曖昧だが、試作品を見ると一気に解像度が上がる」
こうした感覚は、資料を読んでも身につかない。触って初めて分かる。
逆に、この感覚がないと、管理職は必ず「従来の安全なやり方」に戻る。
その方が、自分の責任を説明しやすいからだ。
要件定義を固めました。
工程管理を行いました。
レビューを増やしました。
承認を取りました。
これらは失敗した時に言い訳しやすい。だが、それで勝てるとは限らない。
企業がいま直面しているのは、「失敗しないこと」が最優先だった時代から、「速く学ばなければ敗ける時代」への移行である。この時代に求められる管理職は、リスクをゼロにする人ではない。学習の速度を最大化しながら、致命傷だけは避ける人である。
ここでさらに問題になるのが、大規模案件を抱えている企業だ。
「すでにプロジェクトが動いているから変えられない」
「現行ベンダーとの契約がある」
「社内調整が大きすぎる」
こうした理由で、変革が後回しにされる。
しかし、これはかなり危険な考え方だ。
なぜなら、既存案件がある企業ほど、未来への切り替えを検証する必要が高いからである。現行案件を全部止めろという話ではない。だが、少なくとも別軸で、新しいやり方を本気で試す特別チームを作らなければならない。
その特別チームには、いくつかの条件がある。
まず、既存ルールをそのまま当てはめないこと。従来の承認フロー、ドキュメント文化、役割分断を前提にすると、検証そのものが歪む。次に、成功確率より学習速度を評価すること。小さな失敗を責めるのではなく、どれだけ速く仮説と修正を回せたかを見るべきだ。そして何より、管理職自身がそのチームに関わり、レビューアーではなく体験者として参加することが重要である。
このチームは、単に新しいツールを試す場ではない。
新しい組織運営と新しい意思決定の試験場である。
もしそこで、従来の十分の一の時間でプロトタイプが回せるならどうか。
もし少人数で機能追加がどんどん進むならどうか。
もし現場の要望が、会議ではなく画面ベースで即時に反映されるならどうか。
その事実を、管理職自身が見て体験した時、初めて組織は本当に変わり始める。
反対に、管理職が触らず、分からず、しかし管理だけする状態が続くなら、新しい開発手法は必ず失速する。現場は疲弊し、経営は「やはり時期尚早だった」と結論づけ、変化は数年遅れる。そしてその数年の遅れが、取り返しのつかない差になる。
結局のところ、変革を止めているのは技術の問題ではない。
人材不足の問題でもない。
最も大きいのは、判断する人が変わっていないことである。
だからこそ、最初に変わるべきは現場ではない。
まずは、判断する人が変わること。
自分で触ること。
自分で驚くこと。
自分の常識が古くなっていたと認めること。
そこからしか、本当の組織変革は始まらない。