# Product Design Doc

> プロダクト設計書を作成・更新する。「プロダクト設計書を作って」「設計に落として」「体験設計をまとめて」 「MVP設計を整理」「ユーザーフロー/情報設計を整理」「価値提案を設計書に落とす」などの依頼時に発火。 アイデアの叩き台から、価値提案・ユーザー体験・情報構造・機能構成・データ/権限・リスク・検証計画までを具体化する。

- Skill: `majiayu000/product-design-doc` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add majiayu000/product-design-doc`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/product-design-doc/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/product-design-doc

---


# 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` スキル