10. PRD — コードを一行書く前に決まっていなければならないもの

このシリーズの最初の9編は Alice が何であるか についての記事だった。ペルソナ・メモリ・Skill・Hook・Multi-Agent・検証・トークン経済・セッションプロトコル。すべてシステムの内側に住むものたちだ。

続く3編は Alice を通して流れる仕事そのもの についての記事だ。コードが始まる前の意図の形、コードが終わったかを判定するゲート、そして運営者がキーボードに手を置かなくてもその二つが回り続けるようにするループ。

その最初の一編がこれだ。PRD。

0. 出発前提 — コードは最後に書くものだ

ほとんどの運営者はコードから始める。エディタを開き、関数を書き、動くかを試す。

このパターンは仕事が一日の枠を超えた瞬間に崩れる。昨日書いたコードはなぜ自分が存在するのかを覚えていない。明日のセッションは何が「完了」としてカウントされるかを知らない。チームリードが一切れを承認し、数週間後にはその一切れはもう全体に合わなくなっている。

問題はコードではない。問題は 意図がどこにも永続的に書き留められていない ことだ。運営者は自分の頭の中に、AI は context window の断片に意図を抱えていた — 両方の表面は揮発する。

PRD — Product Requirement Document — がその答えだ。単なる企画ドキュメントではない。運営者の意図がセッションの外に住む表面、次のセッションと次の協働者が再質問せずに読める表面だ。

1. PRD がないとき何が崩れるか

運営者自身の作業で、あるいは引き継ぎを受けながら見たパターンをいくつか。

• 決定の腐敗。ある選択がチャットセッションで下される。3週間後 — 運営者本人を含め — 誰も なぜ その選択をしたのか覚えていない。コードは元に戻り、漂流し、毎セッション同じ議論をやり直す。
• スコープドリフト。「ついでに」がそっと混じり込む。一切れが出荷される頃には、一つではなく四つのことをしていて、その四つのどれもまともにレビューされていない。
• 完了定義の崩壊。誰かが「機能が入りました」と報告する。チームリードが問う — 「どういう意味で？」ビルド？テスト？ライブ？レビュー通過？すべての答えが半分くらい yes で、会話はぐるぐる回る。
• オンボーディングの崩壊。新しい協働者 — 別のエージェント、別のチームメイト、新しい context の未来の Alice — が入る入口がない。彼らはコードから意図を逆工学で取り出すことになり、それは運営者がコストを払って避けようとしたまさにそのループだ。

共通の糸は 第1回 — Why Alice が投げかけた文と同じだ。運営者の 意図 — コードの背後の目的 — がセッション境界を越えられていない、ということ。

2. PRD は意図を永続化した表面だ

PRD の役割は狭く明確だ。作業を計画しない。担当者を割り当てない。進捗を追跡しない。それらは別のドキュメントがやる。

PRD は一つの問いに答える。何を作っているのか、そして何が作られたとカウントされるのか。

このリストに ない ものを見よ。作業リストはなく、日次ログはなく、誰が何をしたかもない。それらは毎セッション変わる。PRD は 意図 が変わったときだけ変わり、それははるかに遅い。

PRD は到達点を記述する。それ以外のすべては道のりを記述する。

3. 何を入れ、何を外すか

40 ページにまで膨らんだ PRD と、ハガキ一枚に収まる PRD の両方を書いた末に運営者が収束した規則:

PRD に入れる: その行を変えるとシステムが 何であるか 自体が変わる場合。例 — 「i18n 必須、6 locale」「ダウンロードは SHA-256 を表記しなければならない」「運営者の実名はどこにも露出しない」。

PRD に入れない: その行を変えてもシステムが どう作られるか だけが変わる場合。例 — 「ビルドは pnpm」「UI primitive は shadcn」「コミットメッセージに [devAlice] prefix」。

二つ目のリストは CLAUDE.md か README、または工具関連ドキュメントに住む。PRD ではない。

この分離の理由は美学ではない。寿命 だ。PRD の行は1年を越えるべきだ。ビルドシステム関連の行は二四半期も持たないかもしれない。別のドキュメントに置けば、それぞれが自分のペースで腐っても他方を引きずり下ろさない。

4. 累積ゲートのパターン

運営者が PRD で最も役立てて使ってきたパターンが 累積型 release gate セクション だ。

形:

Gate 0: M0 ローンチ (一時ドメイン)
  - ビルド通過
  - カテゴリ4ルートのレンダリング
  - カテゴリごとのシード1編
  - ESLint clean

Gate 1: コンプライアンス (公開前必須)
  - Privacy Policy (ko + en)
  - コンテンツライセンス (CC BY)
  - コードライセンス (MIT)
  - About ページ存在
  - ...

Gate 2: インフラ
  - 独自ドメイン接続
  - SSL 有効 (自動)
  - プロダクション env 設定
  - ...

Gate 3: セキュリティ
  - シークレットのハードコード無し
  - .env.example にすべてのキー
  - ユーザーテーブルに RLS 有効
  - ...

... Gate 10

各ゲートは 表 だ。各行は [項目 | 状態 | 備考]。状態は五つのうちの一つ — ✅ 通過 / ⏳ 進行中 / 🔒 運営者待ち / ❌ 未着手 / — 該当なし。

このパターンが機能する三つの理由。

累積。Gate 2 は Gate 1 が通過した状態を前提にする。Gate 9 は 0〜8 が通過した状態を前提にする。道の形がドキュメントに組み込まれている。「どの順序で？」を聞く人がいなくなる — ドキュメントが答える。

原子単位の行。一行は通過か非通過のいずれかだ。「だいたい動く」は状態ではない。この規律が運営者に曖昧な項目（「性能 OK」）をチェック可能な行（「Lighthouse Performance ≥ 90、基準5ページ」）に分割するよう強制する。

行単位の可視状態。運営者は散文を読まなくてもプロジェクトの位置を知る。列を眺めて — ✅ 数 vs 🔒 数 — 絵が即座に立ち上がる。

チームリードが毎セッション最初に読むセクションだ。そしてこのセクションが 第11回 — Release gates と 第12回 — Ralph loop を回す。

5. PRD と一度きりの plan は違う

運営者はしばしば PRD とセッション単位の plan を混同する。違う。生きる時間単位が違う。

意図の一行がこれらの間を漂うと — ある日は HANDOFF に、翌日は PLAN に、その翌日はチャットセッションに — 決して累積されない。同じ意図は一貫した一箇所で表現されなければならない。PRD がその場所だ。

セッションが始まると、Alice は PRD.md を最初に読み、次に HANDOFF.md、その次に PLAN.md を読む。読みが累積する。PRD は 何がカウントされるか を定め、HANDOFF は 運営者がどこまでやったか を語り、PLAN は 今回の一切れで何が起きているか を語る。

6. PRD を生かしておく方法

腐った PRD は PRD が無いより悪い。みなが読み続け、その古い意図に従って動くからだ。運営者が回している習慣三つ。

ファイル内バージョン管理。ファイル先頭: v1.0 → v1.1 → v1.2。各バージョンに変更を一行メモ。現在バージョンは最後の行に書かれているもの。別の changelog ファイルは置かない。

未解決質問セクションは必須。運営者が書くすべての PRD には「未解決質問」セクションがあり、アクティブ開発中は 決して空にならない。そのセクションが空になる日は、プロジェクトが終わったか、誰かが頭の中に決定を隠している日だ。

マイルストーンごとに状態レビュー。マイルストーンが閉じるとき、ゲート表全体を一度なぞる。マイルストーン中に ✅ に移った項目は昇格。手が付かなかった項目は未解決質問セクションへ移住。PRD は 現在の 意図のスナップショットであり、過去の意図のスナップショットではない。

7. 落とし穴

運営者が実戦で PRD が崩れるのを見たパターンたち。

7.1 マーケティング文句としての PRD

「楽しい UX」「世界最高水準の性能」のような行。その行の中でテスト可能なものはない。消す。「性能」が重要なら「Lighthouse Performance ≥ 90、モバイル、基準5ページ」と書く。

7.2 作業リストとしての PRD

すべての行が動詞で始まる。「X を実装。Y をビルド。Z を接続。」それは作業ボードであって PRD ではない。PRD の行は システム を記述する — それが何で、何をすべきか — それを作る作業ではない。

7.3 更新されない PRD

PRD の先頭に v1.0 が打たれているのにマイルストーンは M3 だ。決定がチャットセッションで起きてここに戻ってきていないか、プロジェクトが古い意図の上を漂流しているか、のどちらかだ。両方とも警告サイン。

7.4 PRD ではなくチャットに住む決定

チームリードが Slack メッセージかセッション返信で何かを承認する。2週間後に誰も理由を覚えていない。PRD を変える決定はセッションが終わる前に PRD に入る。 それが承認のコストだ。

7.5 PRD 二つ

誰かが「本物の PRD」と「要約 PRD」を別々に書く、あるいは「韓国語 PRD」と「英語 PRD」が漂流する。一つを選べ。多言語表面はユーザー向けで、PRD はチーム向けに一言語・一ファイルに住む。

ダウンロード — PRD テンプレート

すぐに使えるコピー済み PRD テンプレート。作業スコープ、グローバル制約、検証コマンド、決定権限マトリクス、各項目の完了基準を含む。この投稿で説明した構成を一ファイルにまとめたもの。

shasum -a 256 PRD-code.md
# expected: 1c41c0e61b3dd027fa261e10a8b1f06381e40ee3ce476c24a8df673acb310e7c

8. 一つの原則

運営者が PRD を扱う全体の形は一行に縮む。

「運営者の意図がセッションの間に失いそうなものはすべて PRD に書く。一四半期を生き残れないものはすべて PRD の外に置く。」

これがまた次の二編への橋でもある。PRD は 到達点はどこか に答える。第11回 — Release gates は 到達したかをどう知るか に答える。第12回 — Ralph loop は 運営者が手を置かなくてもシステムがその道の大半をどう歩くか に答える。

この三つが共に、運営者の意図 — 第1回の意図 — を、セッション・日・協働者の境界を越えてシステムが失わずに運べる何かに変える。