まとめと実践

重要なポイント

• 仕様は、短く平易な言葉の作業メモだ — 何を作り、何を作らないか。凍結する契約ではなく、一ページで十分。
• 機能の前に問題と、その問題を抱える人を明確にし、ノンゴール(non-goals)を書き出そう。AI が「親切な」追加機能を入れてくるのに対する、最も鋭い防御だ。
• so that 節のあるユーザーストーリーと、具体的な「Done When」の一行を持つ小さな PRD は、意図をテスト可能で構築可能な振る舞いに変える。
• データモデルを早めに釘付けにしよう — フィールド名はあちこちに漏れ出す — そして仕様を、一度に一つずつ検証できる Vibe サイズのタスクに切り分けよう。
• 解ではなく問題を記述しよう。成果は仕様では変えるのが安く、コードでは高い。学びながら仕様を生かし続けよう。

やってみよう

温めてきたアイデアを一つ取り、単一の AI セッションの中で一ページの仕様に変えよう。まず AI に五つの鋭い質問であなたをインタビューさせ、それから — 自分の言葉で — 問題、ユーザー、三つのユーザーストーリー（各々に so that）、明示的なノンゴールのリスト、六行のデータモデル、そして物理的に実行できる「Done When」の一行を書こう。SPEC.md として保存しよう。よい仕様のテスト: 明日まっさらな会話に貼り付けても、AI が何を作るべきか正確に分かること。

この章のプロンプト

大まかなアイデアがある：<一行の説明>。

私のプロダクト思考パートナーとして振る舞って。まず、鋭い質問を
5つ、一度に一つずつ投げて、問題、ターゲットユーザー、「完了」が
どんな状態かを明確にして。まだ機能は提案しないで。

私が答えたら、次のセクションで一ページの仕様の下書きを作って：
- 問題  - ユーザー  - ゴール
- スコープ内 (v1)  - 非目標 (v1)
- ユーザーストーリー (各「~として、~したい、~のために」)
- データモデル (フィールドの短いリスト)
- 完了条件 (具体的で実際に実行できる受け入れテスト)

簡潔に——一ページ以内で。曖昧な点があれば、仮定する前に
聞いて。すべての行に同意するまで下書きを直すから。