2026-06-05

vibe codingは死んだ、仕様書を書けばいい？プロダクトマネージャーの第三の道は言出法随

最近、方法論界隈で論争が起きている。タイトルはどれも刺激的だ：「vibe codingは死んだ、今すぐspec-driven development（仕様駆動開発）へ転換せよ。」

風向きは確かに変わっている。GitHubのSpec Kitはすでに九万スター超、AWSは「先に仕様、後にコード」を中心に据えたKiroをリリースし、Thoughtworksは仕様駆動をテクノロジーレーダーに掲載した。主流の主張はこうだ：仕様こそが唯一の真実の源泉であり、コードはその産物に過ぎない。両者が食い違えば、コードを直せ、仕様は変えるな。

もっともらしく聞こえる。だがPMなら、慌てて「仕様書の書き方」を学び直す前に、少し立ち止まってほしい。

振り子が振れすぎた

物語の筋書きはこうだ：

まずvibe codingが流行った——一言AIに投げれば、ざっと大量のコードを吐き出してくれる。爽快だが、すぐに破綻した。構造がなく、直せず、自分でも何を作ったか説明できない。そこで反動が起き、反対の極端へと振れた：ならば全部を事前に仕様書に書き起こして、できるだけ細かく書いて、AIにその通りやらせればいい。

問題は、PMにとって「詳細な前置き仕様書を書く」という行為は見慣れたものだということだ——それはPRDそのものだ。 数十ページに及び、書き終わった瞬間に陳腐化し、誰も最後まで読まないあのPRD。AI時代の最大の解放のひとつは、こうした文書苦役からあなたを救い出すことだったはずだ。それなのにspec-drivenはそれをそっくり呼び戻し、今風の新しい名前をつけただけだ。

「なんとなく書く」から「仕様書を書く」への揺り戻しは、一つの極端からもう一つの極端への移動に過ぎない。どちらもPMが立つべき場所ではない。

第三の道：仕様書は書くものではなく、言葉にして走らせるものだ

vibe codingは脆すぎ、仕様書は重すぎる。その間にもう一つの道がある——doaimpmがずっと歩んできた道だ——言出法随。

その核心はこうだ：文書に書かれた仕様書は必要ない。必要なのは、作りたいものを言葉にすることだ。 そして「言葉にすること」は、PMが本来持っている最も基本的なスキルであり、新しい技術ではない。

具体的には二つのことに分解できる：

第一に、仕様は対話の中に生きる——文書の中ではなく。 完全なspecを書き上げてから着手する必要はない。意図を言葉にすればいい——誰のどんな問題を解くのか、主要な制約は何か、何ができれば正解か——そしてAIにその場で動くものを作らせる。言葉にしきれない部分は、AIが聞き返してくれる（優れたagentなら動き出す前に3〜5つの鋭い質問をするはずだ）。対話の中で明確にしていく。明確化は会話の中で起き、誰も読まない文書の中では起きない。

第二に、動くハイフィデリティプロトタイプは、それ自体が最良の仕様書だ。 文字で書かれた仕様書は、十人が読めば十通りに解釈される。クリックでき、動き、本物の状態（ローディング/空/エラー/成功）を持つプロトタイプは、誰が見ても一目で正しいかどうかわかる。ハイフィデリティプロトタイプは自分で語る仕様書だ——解釈される必要はなく、直接体験される。 これがdoaimpmが低保真ワイヤーフレームに反対する理由でもある。AI時代においては、本物を直接作る方が、偽物を描くより速く、誤解も少ない。

では「構造」はどこから来るのか——小さく、安全網を張って

仕様書を書かなければ、vibe codingの轍を踏まないか、制御を失わないか、と問う人がいるだろう。

厚い文書ではなく、二つのものに頼る：

小さく速く進む。 一度に一つだけ変え、実行して確認し、また次へ進む。構造は一連の検証可能な小さなステップの中から育ってくる——着手前に全部を計画し切るものではない。
安全網。 プロトタイプには本物のキーや本物のデータを入れない。不可逆なボタン（公開、削除、決済）は常に人間が押す。本番環境には触れない。迷ったら聞く。判断権は常にあなたの手元にある——これこそがPMが代替不可能な部分だ。

仕様書が唯一の真実の源泉だというなら、実は一言抜けている：AI時代において、最もハイフィデリティな「真実の源泉」は文書ではなく、今まさに目の前で動いているプロダクトだ。

では、今日は何を信じるべきか

「vibe coding」と「spec-driven」のどちらかを選ぶ必要はない。それは偽の二択だ。

vibe codingのように、何も考えずに脳をAIに丸投げしてはいけない。
重い仕様書のように、AI時代がせっかく下ろしてくれた文書の重荷をまた背負ってもいけない。
真ん中の道を行け：言葉にすること（あなたには最初からできる）、ハイフィデリティプロトタイプに語らせること（AIが実現してくれる）、小さく進み、安全網を守ること。

これはまた新しく学ぶべきフレームワークではない——フレームワークはもう十分だ。これはPMの最も素朴な動作に立ち返ることだ：何が欲しいかを考え、言葉にし、走らせる。

言出，法随。

延伸閲覧