prd-writing

PRD の作成

明確で実行可能なプロダクト要件定義書（PRD）を作成するための、ステップごとのワークフローです。以下の6つのステップに従い、7つのカテゴリにわたる25のルールを補足知識として活用してください。

メタデータ

• バージョン： 1.0.0
• ルール数： 7つのカテゴリにわたる25のルール
• ライセンス： MIT

ワークフロー

以下のステップを順番に実行してください。ユーザーがすでに情報を提供している場合に限り、そのステップを省略できます。情報収集を完了する前に、ドラフトの作成を始めてはいけません。

ステップ 1：プロジェクトの状況を確認する

取り組む対象を確認します。

• 既存のプロジェクト — コードが存在する → まずコードベースを調査します（モデル、ルート、コントローラー、認証、パターン）。disc-codebase-exploration を参照してください。
• 空のプロジェクト／新規プロジェクト — まだコードがない → まずユーザーに何を作りたいか尋ねます。プロダクトのアイデアと主要な機能が明確になるまで一緒にブレインストーミングし、その後、予定しているスタック、アーキテクチャ上の決定事項、制約について尋ねます。

ステップ 2：明確化のための質問をする

知識の不足を補うため、的を絞った質問を3～5個します。明確な選択肢がある場合はアルファベット付きの選択肢（A/B/C）を使い、自由記述の回答が必要な場合は自由回答式の質問をします。次の点に焦点を当てます。

1. 課題 — どのような問題を解決しますか？なぜ今なのでしょうか？
2. ユーザー — 対象ユーザーは誰ですか？
3. スコープ — 何をしてはいけませんか？
4. 成功 — 完了したことをどのように判断しますか？
5. 制約 — スケジュール、予算、チームの規模は？

不明な点は推測せず、TBD として記載します。disc-clarifying-questions を参照してください。

ステップ 3：PRD のドラフトを作成する

struct-prd-template のテンプレートを使い、12のセクションすべてを埋めます。

1. エグゼクティブサマリー — 1段落で、課題、解決策、効果を記述
2. 課題の説明 — 何が課題か、対象者、根拠、なぜ今なのか
3. 目標と成功指標 — 測定可能な KPI を3～5個
4. ユーザーペルソナ — 役割／目標／課題を含む主要ユーザーと副次ユーザー
5. ユーザーストーリーと受け入れ条件 — チェックボックス付きの「～として／～したい／そうすることで～」
6. 機能要件 — FR-1、FR-2 などの番号を付ける
7. 非機能要件 — パフォーマンス、セキュリティ、アクセシビリティを具体的な数値とともに記述
8. 技術仕様 — データモデル、認証、ルート、インテグレーション
9. 対象範囲外 — 構築しないものとその理由
10. 非目標 — 最適化の対象としないもの
11. 依存関係とリスク — ブロッカー、担当者、軽減策
12. 未解決の質問 — 未解決の項目、担当者、期限

ドラフト作成時に従うべき主なルール：

• 解決策ではなく課題から始めます（disc-problem-first）
• 曖昧な表現を数値に置き換えます（metric-no-vague-language）
• すべての要件をテスト可能にします（quality-acceptance-criteria）
• 複雑な受け入れ条件には Given/When/Then を使います

ステップ 4：レビューのために提示する

ドラフトをユーザーに見せます。具体的に次の点を尋ねます。

• 課題の説明は、あなたの理解と一致していますか？
• ユーザーストーリーに不足しているワークフローはありますか？
• スコープの境界は適切ですか？
• 解決すべき未解決の質問はありますか？

ステップ 5：フィードバックに基づいて修正する

フィードバックを反映し、未解決の質問に対応して、PRD を更新します。PRD をチームで共有する場合は、レビュー履歴の項目を追加します。

ステップ 6：PRD を保存する

kebab-case のファイル名を使用して、docs/prd/{feature-name}.md に保存します。次のフロントマターを含めます。

---
title: Feature Name
status: draft
author: Author Name
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

ルールのリファレンス

以下の25のルールでは、各ステップの詳細な指針を示します。さらに詳しい情報が必要な場合に参照してください。

1. 情報収集（重要）

• disc-problem-first - 解決策ではなく課題から始める
• disc-clarifying-questions - 作成前に明確化のための質問をする
• disc-codebase-exploration - ドラフト作成前にコードベースを調査する
• disc-stakeholder-alignment - 目標と制約についてステークホルダー間で認識を合わせる

2. 構成（重要）

• struct-standard-sections - 標準化された PRD のセクションを使う
• struct-executive-summary - 簡潔なエグゼクティブサマリーを作成する
• struct-prd-template - すぐに使える PRD テンプレートを提供する
• struct-output-location - PRD を一貫したファイルの場所に保存する
• struct-single-source-of-truth - PRD を機能の決定版リファレンスとする

3. 要件（高）

• req-user-personas - 対象ユーザーのペルソナを定義する
• req-user-stories - 受け入れ基準を含むユーザーストーリーを作成する
• req-functional - 具体的な機能要件を定義する
• req-non-functional - 非機能要件を定義する

4. スコープ（高）

• scope-out-of-scope - 対象外の範囲を明確に定義する
• scope-non-goals - スケジュールを守るため、目標としない項目を列挙する
• scope-dependencies - 依存関係とブロッカーを特定する

5. 指標（高）

• metric-measurable-success - 測定可能な成功基準を定義する
• metric-no-vague-language - 曖昧な表現を定量化可能なベンチマークに置き換える
• metric-kpis - 主要業績評価指標を3〜5個定義する

6. 技術（中）

• tech-data-model - データモデルと関係性を文書化する
• tech-auth-model - 認証と認可を定義する
• tech-api-routes - APIとルートの構成を文書化する
• tech-integration-points - サードパーティとの連携を特定する

7. 品質（中）

• quality-acceptance-criteria - テスト可能な受け入れ基準を作成する
• quality-iterative-review - 最終確定前にフィードバックを受けて反復する

参考資料

• Lenny's Newsletter - 優れたPRDの書き方
• Silicon Valley Product Group - プロダクトディスカバリー
• Shape Up - Basecamp
• 優れた仕様書の書き方 - Kamil Nicieja
• Atlassian - プロダクト要件定義書

完全版ドキュメント

すべてのルールを詳しく説明した完全版ガイドは、AGENTS.md を参照してください。