Product Design Doc

アイデアの叩き台を、プロダクト設計書として具体化する。

入出力

| 種別 | パス | |------|------| | 入力 | docs/ideas/initial-requirements.md（壁打ちメモ） | | 入力 | docs/ideas/nitial-requirements.md（入力が無い場合の代替） | | 入力 | docs/product-design.md（既存あれば優先） | | 出力 | docs/product-design.md |

参照ファイル

| ファイル | 読むタイミング | |----------|----------------| | ./assets/template.md | 新規作成時のベース | | ./references/checklist.md | 品質チェック・レビュー観点 |

手順

1. 壁打ちメモ読解

docs/ideas/initial-requirements.md を読み、以下を抽出する。無い場合は docs/ideas/nitial-requirements.md を読む。

• 解決したい課題
• 対象ユーザーの文脈（役割/環境/頻度）
• 価値提案と差別化のヒント
• 想定ユースケース/利用シーン
• 制約や前提（期間、予算、規制、既存資産）
• 成功条件の兆し（指標や期待）

不足情報は「未確定/要確認」に集約し、仮説が立てられるものは「仮説」として明記する。

2. 既存設計書の確認

• docs/product-design.md が存在する？
  • Yes → 構造を維持して差分更新
  • No → ./assets/template.md をコピーして新規作成

3. 設計セクションの作成

./assets/template.md の構造に従い、以下を埋める。

| セクション | 内容 | 必須 | |-----------|------|------| | サマリ | 一文概要 + ゴール + 成果の方向性 | ✅ | | 背景/課題 | 現状の痛み/機会 | ✅ | | 対象ユーザー | ペルソナ + 1日の流れ | ✅ | | 価値提案/差別化 | 価値の核/代替比較 | ✅ | | 主要ユースケース/JTBD | 主要ジョブ + トリガー | ✅ | | 体験設計 | ジャーニー + 主要フロー | ✅ | | 情報設計 | IA/ナビ/主要画面 | ✅ | | 機能構成 | MVPをP0/P1/P2で整理 | ✅ | | データ/権限設計 | 主要エンティティ/権限 | ✅ | | リスク/依存関係 | 技術/運用/法務の懸念 | ✅ | | 検証計画 | 仮説 + 検証方法 + 指標 | ✅ | | スコープ外 | やらないこと | ✅ | | 未確定/要確認 | 不足情報の列挙 | ✅ |

4. 品質チェック

./references/checklist.md のチェックリストで確認する。

5. ユーザー承認

設計書作成後は必ずユーザーに承認を求める。

• サマリと主要決定事項を提示
• 修正希望があれば対応
• 承認されるまで次フェーズ（PRD/機能設計）に進まない

境界（やらないこと）

• PRDの詳細化（受入条件/要件粒度の確定） → prd-writing スキル
• 機能設計（実装方式の詳細） → functional-design スキル
• 技術選定 → architecture-design スキル