prd-generation

PRD の作成

概要

ガイド付きのヒアリングを通じて、ハイレベルなアイデアを構造化された製品要件定義書に変換します。このスキルでは、課題・解決策・制約の洗い出しを進め、測定可能な目標とユーザーストーリーを含むプロフェッショナルな PRD を作成し、保存前にステークホルダーの承認を得ます。

開始時にアナウンスします：「Product Requirements Document を作成するため、prd-generation スキルを使用します。」

フェーズ 1：ヒアリング

以下の質問を一度に 1 つずつ尋ねます（可能な場合は選択式を優先します）。

**ヒアリングを省略しないでください。**ユーザーが詳細な概要を提示した場合でも、少なくとも 3 つの確認質問をして、理解が正しいか確認します。

ヒアリング後に停止します。収集した回答の要約を提示し、ドラフト作成前に確認を得ます。

課題領域に関する質問

#	質問	重要な理由
1	これはどのような課題を解決しますか？	PRD 全体の軸となるため
2	対象ユーザーは誰ですか？（ペルソナ、役割）	ユーザーストーリーの方向性を決めるため
3	ユーザーは現在、この課題をどのように解決していますか？	競争環境を把握するため
4	解決しない場合、どのような影響がありますか？	優先度を正当化するため

解決策領域に関する質問

#	質問	重要な理由
5	成功とはどのような状態ですか？（具体的な指標）	成功指標を定義するため
6	必須機能と、あると望ましい機能は何ですか？	優先度の階層を設定するため
7	明確な対象外は何ですか？	スコープの拡大を防ぐため
8	参考にできる既存の解決策はありますか？	設計上の判断に役立てるため

制約に関する質問

#	質問	重要な理由
9	スケジュールはどうなっていますか？厳守すべき期限はありますか？	リリース計画の範囲を決めるため
10	技術的な制約はありますか？	解決策の選択肢を絞るため
11	利用可能なリソースは何ですか？	現実的な見通しを立てるため
12	コンプライアンスや規制上の要件はありますか？	非機能要件を特定するため

フェーズ 2：PRD のドラフト作成

以下のテンプレートを使って PRD を作成します。作成に必要な回答を渡して、prd-writer エージェントを呼び出します。

ドラフト作成後に停止します。フェーズ 3 のレビューが完了するまでは、最終版として提示しないでください。

PRD テンプレート

# [Product/Feature Name] — Product Requirements Document

## 1. Overview
One paragraph summarizing what this is and why it matters.

## 2. Problem Statement
- Current situation
- Pain points
- Impact of not solving

## 3. Goals & Non-Goals
### Goals
- [ ] Goal 1 (measurable)
- [ ] Goal 2 (measurable)

### Non-Goals
- Explicitly NOT doing X
- Explicitly NOT doing Y

## 4. User Stories
As a [persona], I want to [action], so that [benefit].

## 5. Functional Requirements
### FR-1: [Requirement Name]
- Description
- Acceptance criteria
- Priority (P0/P1/P2)

## 6. Non-Functional Requirements
- Performance: [specific targets]
- Security: [requirements]
- Accessibility: [standards]
- Scalability: [expectations]

## 7. Technical Constraints
- Platform/stack requirements
- Integration dependencies
- Data requirements

## 8. Success Metrics
| Metric | Current | Target | How to Measure |
|--------|---------|--------|----------------|

## 9. Timeline & Milestones
| Phase | Description | Target Date |
|-------|-------------|-------------|

## 10. Open Questions
- [ ] Question 1
- [ ] Question 2

## 11. Appendix
References, mockups, related documents

優先度の分類

優先度	意味	判定基準
P0	リリースに必須	これがないと製品をリリースできません
P1	重要で、リリース後すぐに提供	大きな価値がありますが、リリースの妨げにはなりません
P2	あると望ましい	エクスペリエンスを向上させますが、後回しにできます

フェーズ 3：レビュー

PRD をセクションごとに提示します。

1. 各セクションの後に、次のように尋ねます：「意図を反映できていますか？変更点はありますか？」
2. 次のセクションに進む前に、フィードバックに基づいて修正します
3. 次の重要なセクションには特に注意を払います：
   • 目標と対象外（スコープの整合性）
   • ユーザーストーリー（ペルソナの正確性）
   • 成功指標（測定可能性）
   • 機能要件（受け入れ基準の網羅性）

レビュー後に停止します。保存前に、明示的な「承認しました」という確認を得ます。

フェーズ 4：保存と次のステップ

明示的な承認を得た後：

1. docs/prds/YYYY-MM-DD-<feature>.md に保存します
2. 次のメッセージで PRD をコミットします：docs(prd): add PRD for <feature>
3. 実装に進む場合は、brainstorming スキルを呼び出します
4. 仕様が必要な場合は、spec-writing スキルを呼び出します

次のステップの判断表

ユーザーの意図	次のスキル	理由
"これを作りましょう"	brainstorming → planning	アプローチを検討してから計画します
"仕様を書いてください"	spec-writing	PRD を JTBD 仕様に分割します
"保存だけしてください"	なし	PRD が成果物です
"見積もりを出してください"	task-decomposition	見積もり可能なタスクに分割します

アンチパターン／よくある間違い

間違い	問題である理由	代わりにすべきこと
ディスカバリーを省略して、いきなりドラフトに進む	仮定に基づく PRD になります	必ず最初にフェーズ 1 を完了してください
指標のない目標	成功を測定できません	すべての目標に数値を設定してください
非目標の記載漏れ	スコープクリープが避けられません	対象範囲外の事項を明示的に列挙してください
受け入れ条件のないユーザーストーリー	要件をテストできません	各ストーリーに Given／When／Then を追加してください
一般的な成功指標（「UX を改善する」など）	測定できません	「読み込み時間を 2 秒未満にする」のように、具体的な数値を使ってください
PRD 全体を一度に提示してレビューを求める	ユーザーが圧倒され、表面的な承認になりがちです	セクションごとに提示してください
競合の機能をそのままコピーする	実際のユーザーニーズを見落とします	解決策ではなく、ユーザーの課題に焦点を当ててください

自己正当化を防ぐためのガード

• 「ユーザーがすでに十分に説明しているから」という理由で、ディスカバリーを省略しないでください
• どのセクションにもプレースホルダーテキストを残さないでください。すべてのセクションを埋めるか、「TBD: [reason]」と記載してください
• 各セクションについてユーザーから明示的な承認を得る前に、保存に進まないでください
• 成功指標を勝手に作らないでください。必ずユーザーから得たものにしてください

統合ポイント

スキル	関係
brainstorming	上流：PRD の前にアイデアを検討します。下流：PRD の後に実装を検討します
spec-writing	下流：PRD がハイレベルな要件を提示し、仕様書で JTBD を使って詳細化します
planning	下流：計画で PRD の要件を参照し、タスクを分解します
task-decomposition	下流：PRD を見積もり可能な作業項目に分解します
tech-docs-generator	並行：PRD をもとに必要なドキュメントを判断します
acceptance-testing	下流：PRD の受け入れ条件をテスト定義に反映します

検証ゲート

PRD の完成を宣言する前に、以下を確認してください。

1. 11 個すべてのセクションが記入されていることを確認します（プレースホルダーテキストではないこと）
2. すべての目標に測定可能な指標があることを確認します
3. 非目標が明示され、意味のある内容であることを確認します
4. ユーザーストーリーに受け入れ条件があることを確認します
5. ユーザーが各セクションを個別に承認していることを確認します
6. ファイルが保存され、コミットされていることを確認します

具体例：ディスカバリーのまとめ

Problem: Users cannot find relevant search results in the dashboard.
Users: Data analysts (primary), team leads (secondary).
Current workaround: Export to Excel and use Ctrl+F.
Impact of not solving: 30min/day wasted per analyst (team of 12).
Success metric: Reduce average search time from 5min to <30s.
Must-have: Full-text search across all dashboard widgets.
Non-goal: Advanced boolean query syntax (P2, not launch).
Timeline: 6 weeks to MVP.
Constraint: Must work with existing Elasticsearch cluster.

このまとめは、フェーズ 2 を開始する前に確認のためユーザーに提示します。

スキルの種類

柔軟 — ディスカバリーを先に行う原則とセクションごとのレビュープロセスを維持しながら、プロジェクトの状況に応じてディスカバリーの深さと PRD の構成を調整します。