ステップ4: 軽量なPRDを起草する

PRD(Product Requirements Document、プロダクト要求仕様書)とは、あなたの決定事項を一か所にまとめたものにすぎません。そこには予測可能な骨組みがあります — 毎回同じ、ひとにぎりのセクションです。

PRD
├─ 問題          なぜ存在するか
├─ ユーザー      誰のためか
├─ ゴール        何をするか、一行で
├─ スコープ内    v1に含むもの
├─ 非目標        v1で省くもの
├─ ユーザーストーリー  ~として、~したい、~のために
├─ データモデル  保存するフィールド
└─ 完了条件      受け入れテスト

ごく小さく保ちましょう。次に、AIに渡せる完成形のスターターPRDを示します。

# Book Tracker — Mini PRD

## Problem
I read a lot but lose track of what I've finished and what I thought of it.

## User
Me (a single user). No accounts needed for v1.

## Goal
A simple web app to add books, track reading status, and rate finished ones.

## In Scope (v1)
- Add a book (title, author)
- Set status: To Read / Reading / Finished
- List all books, filterable by status
- Rate finished books 1–5 stars

## Non-Goals (v1)
- User accounts / login
- Social features, sharing, recommendations
- Importing from other services
- Mobile / native apps

## Tech (keep it simple)
- Single-page web app
- Local browser storage (no backend for v1)

## Done When
I can add a book, change its status, rate it, and see my list
persist after a page refresh.

**「Done When(完了条件)」**の行に注目してください。これがあなたの受け入れテストであり、v1を出荷できたかどうかを判断する具体的な手段です。必ず一つ含めましょう。よい「Done When」は、実際に自分の手で実行できるものです。ここをクリックし、これを入力し、リロードし、あれが見える、というように。完了条件が感覚のように読めてしまうなら(「磨き上がったら」「いい感じになったら」)、それは決して完了しません。照らし合わせるものが何もないからです。見知らぬ人に渡せる手順書になるようにしましょう。

PRDを手で書く必要はありません。便利なやり方は、前のステップで出した答えをAIに戻し、AIにドラフトを組み立てさせて、それをあなたが編集することです。丸ごと受け入れるのではなく編集する意味は、あなたが一行一行を理解し、納得しなければならない点にあります。このドキュメントは、あなたが繰り返し貼り付けることになる信頼の源(source of truth)であり、ここに誤りがあれば、それ以降のすべてのセッションにコピーされてしまうからです。