pdm-design-doc

PdM Design Doc 作成スキル

アイデア・ユーザーの声・問題の断片から出発し、Design Doc → 仕様書 まで一貫して作るワークフロー。

ユーザーがどこから始めるかは毎回異なる。状況を見て適切なフェーズに飛び込む：

ユーザーの状態	始めるフェーズ
「〇〇を作りたい」「ユーザーが困っている」などアイデア段階	Phase 1（ディスカッション）
問題はある程度整理されている	Phase 2（Design Docドラフト）
Design Docはある、仕様書が欲しい	Phase 3（仕様書変換）

---

Phase 1: ディスカッションで問題を掘り下げる

まず何でもいいので話してもらう。粗くて大丈夫。以下の3ステップで整理していく。

Step 1-A: アイデアを出し切る

「どんなことを解決したいですか？」と聞いて、頭の中にあるものをすべて吐き出してもらう。完璧な説明は不要。

Step 1-B: 問いで深掘りする

以下の問いを状況に応じて使い、曖昧な部分を明確にしていく。全部聞く必要はない。核心に近い問いを選ぶ。

ユーザーを具体化する問い

• 「そのユーザーは具体的にどんな職種・役割の人ですか？」
• 「そのユーザーが問題にぶつかるのはどんな場面ですか？」
• 「今、そのユーザーはこの問題をどうやって回避していますか？（Workaround）」
• 「この問題を週に何回くらい経験していると思いますか？」

問題を掘り下げる問い

• 「その不便さによって、ユーザーは何ができなくなっていますか？」
• 「その問題が解決されないまま放置されると、どうなりますか？」
• 「速度の問題ですか？それとも操作・情報・信頼の問題ですか？」

解決策と問題を分離する問い

• 「その機能を使って、ユーザーは何を達成したいですか？」
• 「その機能がなくても、同じ目的を達成できる方法はありますか？」

ゴールを明確にする問い

• 「この施策がうまくいったとき、何が変わっていますか？」
• 「3ヶ月後に振り返ったとき、どんな数字や状態を見て『成功した』と言いますか？」

スコープを絞る問い

• 「今回のリリースで解決しなければならないことは何ですか？」
• 「やれると嬉しいが、なくても困らないものはどれですか？」

Step 1-C: 構造にまとめる

ディスカッションで出てきた内容を整理し、Design Docのドラフトに移る。

---

Phase 2: Design Docドラフトを生成する

以下のテンプレートに沿って生成する。空欄・不明点は [要確認] とマークして残す。推測で埋めない。

# Design Doc｜[機能・施策名]

## Background
なぜ今これに取り組むのか。経緯・背景・前提。

## Problem
解決する問題を定義する（定性・定量の両面）。
「誰が」「どんな状況で」「何に困っているか」を明確に。

## Goals
施策で達成したいことを箇条書きで。
成功指標（KPI/OKR）を含める。

## Non-Goals
今回スコープに含めないことを明示する。
「やらないことを決める」はGoalと同じくらい重要。

## User Story
形式: 「[ユーザー] は [したいこと] したい。なぜなら [理由] だから。」

## UX Flow
ユーザーの行動フローを順番に記述。
分岐・エラー状態・エッジケースも含める。

## Technical Notes
実装上の制約・考慮事項・依存関係。
不明点は [要確認] とマーク。

## Metrics
リリース後に何を計測するか。
Before/Afterの比較ができる指標を設定。

ドラフト生成後のレビュー

生成したら必ず以下を確認してユーザーに問い返す：

1. 空欄・[要確認] を列挙し、何が必要かを伝える
2. 問題とゴールの整合性 — 「このGoalはこのProblemを解いていますか？」
3. Non-Goalsの有無 — 書かれていなければ「今回やらないことは何ですか？」と聞く
4. Metricsの具体性 — 「それは何を計測すれば確認できますか？」

よくある失敗パターン（これが出たら止めて問い直す）

失敗パターン	対処
最初から「この画面を作りたい」と解決策の話になる	「その画面を使って、ユーザーは何を達成したいですか？」
問題が「UX全体を改善したい」など広すぎる	「今最もユーザーが困っている場面を一つ選ぶとしたら？」
GoalSが「〇〇機能をリリースする」になっている	「リリースした結果、何が変わっていれば成功ですか？」
Non-Goalsがない	「今回やらないことを明示してください」
Metricsが「ユーザーが満足する」など定性的	「それは何の数字で確認できますか？」

---

Phase 3: 仕様書に変換する

Design Docの「What & Why」を、エンジニアが実装に使える「How」の文書に変換する。

# 仕様書｜[機能・施策名]

## 概要
Design DocのProblem + Goalsを1段落で圧縮。
「何のために・何を・誰向けに作るか」が3秒でわかること。

形式: 〇〇という課題を抱える[ユーザー]向けに、〇〇を実現する機能を実装する。
     これにより〇〇が改善される。

## 対象ユーザー
- ロール・権限（「ログイン済みユーザー」はNG。具体的に）
- 利用シーン
- 技術リテラシー

## 機能要件

### [機能名]
- **概要**: 「ユーザーが〇〇する → システムが〇〇する」を一文で
- **ハッピーパス**: 正常系の操作フローを順番に（ユーザーの操作とシステムの反応を交互に）
- **エッジケース・例外処理**:
  - 入力が空のとき
  - 上限を超えたとき
  - 権限がないユーザーがアクセスしたとき
  - ネットワークが切れたとき
- **バリデーション**: 必須/任意・型・文字数制限・重複チェックの有無

## 非機能要件
- **パフォーマンス**: 応答時間の目標・想定負荷
- **セキュリティ**: 認証・認可・データの機密性
- **アクセシビリティ**: 準拠レベル・キーボード操作
- **対応環境**: ブラウザ・デバイス・OS

## やらないこと（スコープ外）
Design DocのNon-Goalsから引用し、理由を必ず添える。

## UI/UX仕様
- **表示状態**: デフォルト・ローディング・エラー・空状態・成功状態
- **画面遷移**: 遷移元・完了後の遷移先・キャンセル時の挙動

## データ仕様
| フィールド名 | 型 | 制約 | 備考 |
|---|---|---|---|

## 計測・ログ

| 指標 | 問い | イベント例 |
|---|---|---|
| 採用率 | 機能を使っているか | `feature_opened` |
| 継続率 | 使い続けているか | 7日後・28日後の再利用 |
| 完了率 | 目的を達成できているか | フロー最終ステップ到達 |
| エラー率 | どこで詰まっているか | `error_shown` |

## Open Questions
| # | 問い | 担当 | 期限 |
|---|---|---|---|

仕様書の穴チェックリスト

• エッジケースが網羅されているか
• 表示状態（ローディング・エラー・空状態）が定義されているか
• やらないことが明示されているか
• Open Questionsに確認が必要なことが入っているか
• 計測設計が入っているか

よくある漏れ

• エラー状態のUI定義がない
• 権限・ロールによる出し分けの考慮がない
• 既存機能との影響範囲が未定義

---

重要な原則

PdMが判断・責任を持つべきこと（AIには任せない）

• 問題定義の正確さ — AIは現場の文脈を知らない
• 優先順位の妥当性 — AIには組織の事情がわからない
• ステークホルダーへの説明責任

AIが知らない情報（ユーザーが持ち込む必要がある）

• 市場・競合の現状
• 自社の戦略・OKR
• 組織内の関係者の温度感
• ユーザーの現場で見た文脈
• 過去の意思決定の経緯

AIとのディスカッションが盛り上がっても「検証完了」ではない。内部ロジックの整合性を整えるのが役割。