いま、システム開発の世界では、表面的な改善では説明できない大きな地殻変動が起きている。しかもそれは、まだ「これから起きる変化」ではない。すでに起きていて、すでに先に進んでいる企業がある一方で、多くの企業はその本質に気づかないまま、従来の延長線上で意思決定を続けている。ここに、今後数年で取り返しのつかない差が生まれる。
従来、システム開発というものは「工程を積み上げて完成に近づける営み」だった。要件定義を行い、基本設計、詳細設計、実装、テスト、移行、運用へと進む。この流れは一見合理的であり、特に大規模開発においては長らく正攻法とされてきた。関係者が多いほど、影響範囲が広いほど、最初にきっちり決め、工程を分け、責任を分散し、変更を抑制するほうが安全だと考えられてきたのである。
しかし、その前提そのものが揺らいでいる。
なぜなら、生成AI、とりわけバイブコーディング的な開発スタイルが普及し始めたことで、「最初に固めること」よりも「まず作って確かめること」の価値が急激に高まったからだ。もっと言えば、従来のようにドキュメントで未来の完成形を先回りして固定することよりも、AIと対話しながら即時に試作し、修正し、再構成しながら本質を見つけていくほうが、圧倒的に合理的な場面が増えている。
ここでよくある誤解がある。AI活用と聞くと、多くの人は「既存開発の中にAIを組み込むこと」だと考える。たとえば、設計書作成を効率化する、テストコードを自動生成する、チャットボットで一部の問い合わせ対応を自動化する、といった発想である。もちろん、それらにも一定の価値はある。だが、それは本質ではない。本質は、開発のプロセスそのものが別物になるという点にある。
つまり、これはツールの追加導入ではない。生産ラインの一部を改善する話でもない。工場の作り方そのものを変える話なのだ。
それにもかかわらず、いまだに去年の常識で開発提案をしてくる企業やSIerは多い。DifyやMCPサーバーのような概念や仕組みを前提に、いかにもAI時代に対応しているような顔をしながら、実際には従来型の要件定義文化の中でしか発想していない提案も少なくない。ここで誤解してはならないのは、DifyやMCPが悪いと言いたいわけではないということだ。問題は、それらを「いまの最先端の開発思想そのもの」と勘違いし、それに合わせて重たい設計や長い検討期間を前提とした提案をしてしまうことにある。
それはすでに、時代の転換点に対して半歩どころか一歩以上遅れている。
去年の常識で「AI対応」を語ることは、ある意味で一番危険だ。なぜなら、本人たちは新しいことをやっているつもりだからである。完全に古い考えに固執している人よりも、自分はアップデートしていると思い込んでいる人のほうが変化に気づきにくい。そして企業は、そうした“わかったつもりの更新”に騙されやすい。
本当の変化とは何か。
それは、開発において「人間がすべてを先に定義し、機械はそれを忠実に実行する」という構造が崩れ始めていることだ。これからは、人が意図や方向性を持ち、AIが具体化を支援し、試作を高速化し、その結果を人が見て判断し、また修正する。このループが高速で回ることが競争力の源泉になる。ここで重要なのは、最初の設計書の完成度ではなく、試行錯誤の回転数である。
この変化に対応できない企業は、今後ますます苦しくなる。特に危険なのは、「すでに大きなプロジェクトが動いているから、今さらやり方を変えられない」と考える企業だ。だが、その判断は冷静に見れば、安定志向ではなく単なる損失の先送りである。プロジェクトの進行を理由に古い作り方を温存することは、将来の競争力を切り売りしているのと同じだ。
歴史を振り返れば、こうした転換は何度も起きてきた。活版印刷は、技術として見れば非常に高度で、職人の技術が詰まった世界だった。活字を組み、美しく整え、紙面を作り上げる仕事には誇りがあり、品質の高さもあった。しかし、印刷技術が変わり、デジタル化が進む中で、産業全体としてはそちらに留まることはできなかった。活版印刷の価値がゼロになったのではない。だが、主流であり続けることはできなかったのである。
いまのシステム開発も、それに近い。従来型の開発には価値がある。要件を丁寧に詰めること、設計を精緻に行うこと、レビューを重ねて品質を高めること、そのすべてに意味はある。だが、企業経営として考えたとき、それが主流の開発思想として今後も維持できるかといえば、答えはかなり厳しい。
市場は待ってくれない。競合は止まってくれない。顧客の期待は毎月変わる。社内業務も制度も商流も、変化の前提で動いていく。その中で、半年かけて要件定義し、一年かけてリリースし、出してみたら現場が求めるものとズレていた、という世界は、ますます成立しにくくなる。
しかも皮肉なことに、開発が遅く重い企業ほど、「失敗しないために慎重になる」という理屈で、さらに遅く重くなる。要件をもっと詰めよう、レビューを増やそう、管理を厳密にしよう、ベンダーを増やして牽制しよう、といった発想が、さらに機動力を奪っていく。こうして、変化に弱い組織が完成する。
バイブコーディングは、そうした悪循環を断ち切る可能性を持っている。ここで言うバイブコーディングとは、単にAIにコードを書かせることではない。構想、試作、実装、修正、再設計のサイクルを、従来とは比較にならない速度で回しながら、本当に必要なものへ近づいていく開発思想である。従来の工程分割ではなく、対話的・探索的・仮説検証型の開発を前提とする。つまり、完成形を先に決めて進むのではなく、進みながら完成形を見つけるのである。
この発想転換を受け入れられない企業は、近い将来、二重の苦しみを背負うことになる。ひとつは、開発コストが相対的に高くなり続けること。もうひとつは、意思決定が遅く、市場への適応が遅れることだ。前者は利益を圧迫し、後者は機会損失を生む。この二つが同時に起きれば、企業体力は一気に削られていく。
重要なのは、いま起きていることを「開発現場の話」として矮小化しないことだ。これは経営課題であり、組織設計の課題であり、企業の競争戦略そのものに関わる問題である。どれだけ優秀な人材を採っても、どれだけ予算を投じても、前提となる開発思想が古ければ、成果は頭打ちになる。
企業がいま問うべきなのは、「従来の開発をどううまく回すか」ではない。
問うべきは、その前提自体を続ける合理性がまだあるのかである。
もしそこに真正面から向き合わないなら、変化は外からやってくる。より軽く、より速く、より柔軟なプレイヤーに、市場も人材も案件も奪われていく。そして後になって、「あの時変えておけばよかった」と振り返ることになる。
だが、経営は後悔のためにあるのではない。
いま必要なのは、既存システム開発の延長線上を磨くことではない。
開発の常識そのものを疑い、別の前提へ踏み出す意思決定である。
その一歩を踏み出せるかどうかが、これからの企業の明暗を分ける。