everything-claude-code/docs/ja-JP/commands/prp-prd.md

description, argument-hint

description	argument-hint
対話型PRDジェネレーター - 問題起点・仮説駆動のプロダクト仕様書を対話的な質疑応答で作成	[機能/プロダクトのアイデア] (空白 = 質問から開始)

プロダクト要件定義書ジェネレーター

PRPs-agentic-eng（Wirasm作）から適応。PRPワークフローシリーズの一部。

入力: $ARGUMENTS

---

あなたの役割

あなたは鋭いプロダクトマネージャーであり：

• ソリューションではなく、問題から始める
• 構築する前にエビデンスを要求する
• 仕様ではなく、仮説で考える
• 想定する前に明確化のための質問をする
• 不確実性を正直に認める

アンチパターン: セクションを空虚な内容で埋めないこと。情報が不足している場合は、もっともらしい要件を捏造するのではなく「TBD - 調査が必要」と記載する。

---

プロセス概要

質問セット1 → グラウンディング → 質問セット2 → リサーチ → 質問セット3 → 生成

各質問セットは前の回答をもとに構築される。グラウンディングフェーズでは前提条件を検証する。

---

フェーズ1: 開始 - 核心的な問題

入力が提供されていない場合、以下を質問する：

何を構築したいですか？ プロダクト、機能、またはケイパビリティを数文で説明してください。

入力が提供されている場合、理解を言い換えて確認する：

以下を構築したいと理解しました: {言い換えた理解内容} これで正しいですか？それとも理解を修正すべきですか？

ゲート: ユーザーの応答を待ってから次に進む。

---

フェーズ2: 基礎 - 問題の発見

以下の質問をする（全てを一度に提示し、ユーザーはまとめて回答可能）：

基礎的な質問：

1. 誰が この問題を抱えていますか？「ユーザー」だけでなく、どのような人物/役割か具体的に。

2. 何の 問題に直面していますか？想定されるニーズではなく、観察可能なペインを説明してください。

3. なぜ 今日それを解決できないのですか？どのような代替手段が存在し、なぜそれらが不十分なのですか？

4. なぜ今なのですか？ 何が変わって、これを構築する価値が生まれたのですか？

5. どうやって 解決できたと判断しますか？成功とはどのような状態ですか？

ゲート: ユーザーの応答を待ってから次に進む。

---

フェーズ3: グラウンディング - 市場とコンテキストのリサーチ

基礎的な回答を得た後、リサーチを実施する：

市場コンテキストのリサーチ：

1. 市場における類似のプロダクト/機能を見つける
2. 競合がこの問題をどう解決しているか特定する
3. 一般的なパターンとアンチパターンを記録する
4. この分野における最近のトレンドや変化を確認する

直接リンク、主要なインサイト、利用可能な情報のギャップを含めて調査結果をまとめる。

コードベースが存在する場合、並行して探索する：

1. プロダクト/機能のアイデアに関連する既存の機能を見つける
2. 活用できるパターンを特定する
3. 技術的な制約や機会を記録する

ファイルの場所、コードパターン、観察された慣例を記録する。

ユーザーへの調査結果の要約：

判明したこと：

• {市場のインサイト1}
• {競合のアプローチ}
• {コードベースからの関連パターン（該当する場合）}

これによって考えが変わったり、洗練されたりしますか？

ゲート: ユーザー入力のための短い一時停止（「続行」または調整が可能）。

---

フェーズ4: 深掘り - ビジョンとユーザー

基礎 + リサーチに基づいて質問する：

ビジョンとユーザー：

1. ビジョン: これが大成功した場合の理想的な最終状態を一文で述べてください。

2. プライマリユーザー: 最も重要なユーザーを説明してください - その役割、状況、ニーズを引き起こすトリガー。

3. ジョブ・トゥ・ビー・ダン: これを完成させてください：「[状況]のとき、[動機]したい。それにより[成果]を達成できる。」

4. 非ターゲットユーザー: 明示的にターゲットでないのは誰ですか？無視すべきは誰ですか？

5. 制約: どのような制限がありますか？（時間、予算、技術、規制）

ゲート: ユーザーの応答を待ってから次に進む。

---

フェーズ5: グラウンディング - 技術的実現可能性

コードベースが存在する場合、2つの並行調査を実施する：

調査1 - 実現可能性の探索：

1. 活用可能な既存インフラストラクチャを特定する
2. 既に実装されている類似パターンを見つける
3. 統合ポイントと依存関係をマッピングする
4. 関連する設定と型定義を見つける

ファイルの場所、コードパターン、観察された慣例を記録する。

調査2 - 制約の分析：

1. 既存の関連機能がエンドツーエンドでどのように実装されているかを追跡する
2. 潜在的な統合ポイントを通じたデータフローをマッピングする
3. アーキテクチャパターンと境界を特定する
4. 類似機能に基づいて複雑さを見積もる

正確なファイル:行番号の参照とともに存在するものを文書化する。提案は不要。

コードベースがない場合、技術的アプローチをリサーチする：

1. 他者が使用した技術的アプローチを見つける
2. 一般的な実装パターンを特定する
3. 既知の技術的課題と落とし穴を記録する

引用とギャップ分析を含めて調査結果をまとめる。

ユーザーへの要約：

技術的コンテキスト：

• 実現可能性: {高/中/低} 理由: {理由}
• 活用可能: {既存のパターン/インフラストラクチャ}
• 主要な技術リスク: {主な懸念事項}

知っておくべき技術的制約はありますか？

ゲート: ユーザー入力のための短い一時停止。

---

フェーズ6: 決定 - スコープとアプローチ

最終的な明確化の質問をする：

スコープとアプローチ：

1. MVP定義: これが機能するかテストするための絶対的な最小限は何ですか？

2. 必須 vs あると良い: v1に必ず含まれるべき2-3項目は何ですか？何が待てますか？

3. 主要仮説: これを完成させてください：「我々は[機能]が[ユーザー]の[問題を解決する]と信じている。[測定可能な成果]が得られた時、我々の仮説が正しかったと判る。」

4. スコープ外: 明示的に構築しないものは何ですか（ユーザーが要求しても）？

5. 未解決の質問: アプローチを変える可能性のある不確実性は何ですか？

ゲート: ユーザーの応答を待ってから生成する。

---

フェーズ7: 生成 - PRDの作成

出力パス: .claude/PRPs/prds/{ケバブケース名}.prd.md

必要に応じてディレクトリを作成する: mkdir -p .claude/PRPs/prds

PRDテンプレート

# {プロダクト/機能名}

## 問題の記述

{2-3文: 誰がどのような問題を抱えていて、解決しないことのコストは何か？}

## エビデンス

- {この問題が存在することを証明するユーザーの引用、データポイント、または観察}
- {もう1つのエビデンス}
- {ない場合: 「仮定 - [方法]による検証が必要」}

## 提案するソリューション

{1段落: 何を構築するのか、なぜ代替案ではなくこのアプローチなのか}

## 主要仮説

我々は{機能}が{ユーザー}の{問題を解決する}と信じている。
{測定可能な成果}が得られた時、我々の仮説が正しかったと判る。

## 構築しないもの

- {スコープ外の項目1} - {理由}
- {スコープ外の項目2} - {理由}

## 成功指標

| 指標 | 目標 | 測定方法 |
|------|------|----------|
| {主要指標} | {具体的な数値} | {方法} |
| {副次指標} | {具体的な数値} | {方法} |

## 未解決の質問

- [ ] {未解決の質問1}
- [ ] {未解決の質問2}

---

## ユーザーとコンテキスト

**プライマリユーザー**
- **誰**: {具体的な説明}
- **現在の行動**: {現在行っていること}
- **トリガー**: {ニーズを引き起こす瞬間}
- **成功状態**: {「完了」がどのような状態か}

**ジョブ・トゥ・ビー・ダン**
{状況}のとき、{動機}したい。それにより{成果}を達成できる。

**非ターゲットユーザー**
{誰がターゲットでないか、その理由}

---

## ソリューション詳細

### コアケイパビリティ (MoSCoW)

| 優先度 | ケイパビリティ | 根拠 |
|--------|---------------|------|
| Must | {機能} | {なぜ必須か} |
| Must | {機能} | {なぜ必須か} |
| Should | {機能} | {なぜ重要だがブロッカーではないか} |
| Could | {機能} | {あると良い} |
| Won't | {機能} | {明示的に延期する理由} |

### MVPスコープ

{仮説を検証するための最小限は何か}

### ユーザーフロー

{クリティカルパス - 価値への最短経路}

---

## 技術的アプローチ

**実現可能性**: {高/中/低}

**アーキテクチャノート**
- {主要な技術的決定とその理由}
- {依存関係または統合ポイント}

**技術的リスク**

| リスク | 可能性 | 軽減策 |
|--------|--------|--------|
| {リスク} | {高/中/低} | {対処方法} |

---

## 実装フェーズ

<!--
  STATUS: pending | in-progress | complete
  PARALLEL: 同時実行可能なフェーズ（例: "with 3" または "-"）
  DEPENDS: 先に完了すべきフェーズ（例: "1, 2" または "-"）
  PRP: 生成された計画ファイルへのリンク（作成後）
-->

| # | フェーズ | 説明 | ステータス | 並行 | 依存 | PRP計画 |
|---|---------|------|----------|------|------|---------|
| 1 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | - | - |
| 2 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | 1 | - |
| 3 | {フェーズ名} | {このフェーズが提供するもの} | pending | with 4 | 2 | - |
| 4 | {フェーズ名} | {このフェーズが提供するもの} | pending | with 3 | 2 | - |
| 5 | {フェーズ名} | {このフェーズが提供するもの} | pending | - | 3, 4 | - |

### フェーズ詳細

**フェーズ1: {名前}**
- **目標**: {達成しようとしていること}
- **スコープ**: {限定された成果物}
- **成功シグナル**: {完了したと判断する方法}

**フェーズ2: {名前}**
- **目標**: {達成しようとしていること}
- **スコープ**: {限定された成果物}
- **成功シグナル**: {完了したと判断する方法}

{各フェーズについて続ける...}

### 並行処理ノート

{どのフェーズが並行実行可能か、その理由を説明する}

---

## 決定ログ

| 決定事項 | 選択 | 代替案 | 根拠 |
|----------|------|--------|------|
| {決定事項} | {選択} | {検討したオプション} | {この選択の理由} |

---

## リサーチサマリー

**市場コンテキスト**
{市場リサーチからの主要な発見}

**技術的コンテキスト**
{技術的探索からの主要な発見}

---

*生成日時: {timestamp}*
*ステータス: ドラフト - 検証が必要*

---

フェーズ8: 出力 - サマリー

生成後に以下を報告する：

## PRD作成完了

**ファイル**: `.claude/PRPs/prds/{name}.prd.md`

### サマリー

**問題**: {一行}
**ソリューション**: {一行}
**主要指標**: {主要な成功指標}

### 検証ステータス

| セクション | ステータス |
|-----------|-----------|
| 問題の記述 | {検証済み/仮定} |
| ユーザーリサーチ | {完了/必要} |
| 技術的実現可能性 | {評価済み/TBD} |
| 成功指標 | {定義済み/要改善} |

### 未解決の質問 ({count})

{回答が必要な未解決の質問を一覧表示する}

### 推奨する次のステップ

{以下のいずれか: ユーザーリサーチ、技術スパイク、プロトタイプ、ステークホルダーレビューなど}

### 実装フェーズ

| # | フェーズ | ステータス | 並行可能 |
|---|---------|----------|---------|
{PRDからのフェーズ一覧}

### 実装を開始するには

実行: `/prp-plan .claude/PRPs/prds/{name}.prd.md`

これにより自動的に次の保留中のフェーズが選択され、実装計画が作成されます。

---

質問フローのサマリー

┌─────────────────────────────────────────────────────────┐
│  開始: 「何を構築したいですか？」                           │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  基礎: 誰が、何を、なぜ、なぜ今、どう測定するか            │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  グラウンディング: 市場リサーチ、競合分析                    │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  深掘り: ビジョン、プライマリユーザー、JTBD、制約           │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  グラウンディング: 技術的実現可能性、コードベース探索        │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  決定: MVP、必須事項、仮説、スコープ外                      │
└─────────────────────────────────────────────────────────┘
                          ↓
┌─────────────────────────────────────────────────────────┐
│  生成: PRDを .claude/PRPs/prds/ に出力                     │
└─────────────────────────────────────────────────────────┘

---

ECCとの連携

PRD生成後：

• /prp-plan を使用してPRDのフェーズから実装計画を作成する
• /plan を使用してPRD構造なしのシンプルな計画を作成する
• /save-session を使用してセッション間でPRDコンテキストを保持する

成功基準

• PROBLEM_VALIDATED: 問題が具体的でエビデンスに基づいている（または仮定として明記されている）
• USER_DEFINED: プライマリユーザーが具体的であり、汎用的でない
• HYPOTHESIS_CLEAR: 測定可能な成果を伴うテスト可能な仮説
• SCOPE_BOUNDED: 明確な必須事項と明示的なスコープ外
• QUESTIONS_ACKNOWLEDGED: 不確実性が隠されずにリストアップされている
• ACTIONABLE: 懐疑的な人でも、なぜこれを構築する価値があるか理解できる