2026年3月15日時点で、Xでは「仕様駆動開発の是非でエンジニア議論白熱」が話題でした。 発端は2026年3月11日に公開された「仕様駆動開発はやめた方がええ」という問題提起です。 私はこの議論を見て、争点が少しズレていると感じました。 減らすべきは、手で厚く保守する「詳細仕様書」です。 逆に、今まで以上に重くなるのは「要件定義書」です。 現在94名がお申し込み済です。
「仕様書は要らない。コードが真実だ」という主張は、詳細設計レベルならかなり正しいです。 AIがここまで実装を速くした今、画面項目一覧や関数単位の説明を人が延々と写経する価値は確かに落ちました。 ただし、その勢いで要件定義書まで軽く扱うと、別の地獄が始まります。誰の課題を解くのか。何を成功とみなすのか。どこまでが制約なのか。ここが曖昧なまま、AIとチームが別々の正解を作り始めるからです。
AIは実装を安くしました。でも、要件の解釈違いを安くはしてくれません。 むしろ逆です。 要件が曖昧でも実装だけはどんどん進むので、それっぽく動くけれど現場では使えないものが最速で量産されます。 だから今、最も価値があるのは「どう作るか」を細かく固定する文書ではありません。「何を守るか」を定義する文書です。
私は仕様書を全部肯定したいわけではありません。 不要な写経は減らすべきです。詳細仕様の多くは、AI生成、テスト、実装コード、差分レビューに寄せていいと思っています。 ただ、要件定義書だけは別です。 これは単なる資料ではありません。発注側、事業側、開発側、デザイナー、QA、そしてAIエージェントが同じ方向を向くための地図です。 人間が責任を持って残すべき順番は、私はこう考えています。
「仕様駆動開発は要るか、要らないか」という問いは少し雑です。 本当に問うべきは、どの文書を人間の責任で持ち、どこから先をAIに任せるかです。 私の答えは明確です。詳細仕様は薄くしていい。実装はAIに大きく任せていい。でも要件定義書だけは、今まで以上に重く扱うべきです。 コードを書くコストが下がるほど、最初の1枚の精度がプロジェクトの成否を決めます。 だから私は、要件定義書こそ全てだと思っています。 現在94名がお申し込み済です。