「仕様書って、どこまで書けばOKですか？」——ジュニアPdMが最初にぶつかる壁です。結論はシンプルで、“意思決定が止まらないだけの必要十分”を書けば勝ち。この記事では、現場でそのまま使えるPRD（Product Requirements Document）テンプレと、受け入れ基準／非機能要件／API最小セットのまとめ方を紹介します（企業名・実数は非公開）。
関連の基礎は次の記事も参考に：PdMのための「要件定義」完全ガイド ／ KPI設計は成果を出すKPI設計と運用 ／ 優先順位の考え方は優先順位判断フレームワーク。技術リテラシの足場づくりには非エンジニアPdMのための開発知識入門。
- 1. まず“何を決める文書か”を1行で宣言する
- 2. 現場テンプレ：この順で書けば止まらない
- 3. 物語：会議室で止まらなくなった日
- 4. 成功基準は“先行指標”で書く
- 5. スコープ定義：迷いを消す3行テンプレ
- 6. ユーザーストーリー＆受け入れ基準（実例）
- 7. 画面・フロー・権限：図は“分かりやすさ優先”でOK
- 8. データとAPI：最小の“契約”を書き切る
- 9. 非機能要件：SLOから逆算する
- 10. 合意形成の運び方（DACI）
- 11. 失敗あるある＆回避策
- 12. そのまま使えるPRD雛形（コピー用）
- 受け入れ基準の書き方（Gherkin雛形10）
- 13. 関連記事（内部リンク）
- 14. 有料note＆特典テンプレ
- 15. まとめ：仕様書は“前に進めるための最小単位”
1. まず“何を決める文書か”を1行で宣言する
PRDの冒頭に、Decision Statementを1行で。例：「本PRDは、〇〇機能のスコープ/品質/計測を合意し、2スプリントでリリースするための意思決定材料である」。これだけで、読み手が「今なぜこれを読むか」を迷いません。
2. 現場テンプレ：この順で書けば止まらない
1. 背景と狙い（Why）
2. 成功基準（KGI/KPI・先行指標）
3. スコープ定義（IN/OUT・非目標）
4. ユーザーとシナリオ（As-is/To-be）
5. ユーザーストーリー（エピック→ストーリー）
6. 受け入れ基準（Acceptance Criteria）
7. 画面・フロー（ワイヤ・業務フロー・権限）
8. データとAPI（契約・永続化・バリデーション）
9. 非機能要件（SLO/セキュリティ/監視/運用）
10. 依存関係・リスク・決め待ち
11. 追跡（イベント計測・実験計画）
12. DACI（役割と最終承認）3. 物語：会議室で止まらなくなった日
私：「今回の成功は“初回価値到達率+10pt”。売上は追いません」
エンジニア：「なら、作る優先はAha到達までのフローですね」
CS：「問い合わせ削減の観点も。文言は私たちで叩きます」
私：「よし、DACIは私がD、最終承認はPdMリード。今からPRD更新します」
決める順番をPRDが導いてくれると、会議は自然と前に進みます。
4. 成功基準は“先行指標”で書く
PRDでは、遅行指標（売上）ではなく先行指標（Aha到達率/TTV/翌日活性）を書くのがコツ。詳しい指標設計はこちらを参照。
5. スコープ定義：迷いを消す3行テンプレ
【IN】初回価値に直結するUI変更、文言、状態保持
【OUT】推薦アルゴリズム刷新、通知の最適化、管理画面の高度化
【非目標】売上の短期増、全機能の説明この3行があるだけで、仕様相談の無駄な往復が激減します。
6. ユーザーストーリー＆受け入れ基準（実例）
■エピック
- E1：ユーザーが“保存”まで迷わず到達できる
■ユーザーストーリー
- S1：ユーザーとして、候補リストから「保存」を1タップで完了したい。
■受け入れ基準（S1）
- AC1：候補カードのどこをタップしても保存が1秒以内に反映される
- AC2：保存後はスナックバーで「保存しました」を2秒表示し、Undoが可能
- AC3：戻る操作をしても直前の選択状態が保持されている
- AC4：イベント「save_click」「save_success」が送信され、ダッシュボードに反映ポイントは、観測可能な事実で書くこと（「使いやすい」はNG）。
7. 画面・フロー・権限：図は“分かりやすさ優先”でOK
- 画面遷移：Ahaまでの最短3〜5手に限定（その他は付録）。
- 業務フロー：BtoBtoCなら社内Opsやパートナーの動きも1枚に。
- 権限：誰が編集/閲覧できるか、ロールごとに明記。
8. データとAPI：最小の“契約”を書き切る
■データ保存
- Entity：SavedItem { id, userId, itemId, createdAt }
- Uniqueness： (userId, itemId) はユニーク
■API契約（最小）
POST /v1/saved-items
- Request：{ itemId: string }
- Response：201 Created / { id, itemId, createdAt }
- エラー：409（重複保存）, 401（認証エラー）
- バリデーション：itemId は必須、存在チェック細部の設計はエンジニアに委ねつつ、破れない契約（I/O・エラー・バリデーション）だけはPRD側で押さえます。
9. 非機能要件：SLOから逆算する
- 可用性：99.9%（Aha到達パスに限る）
- 性能：保存の平均応答 < 1s／p95 < 2s
- セキュリティ：保存操作は認証必須、権限外は403
- 監視：エラー率>1%でPager通知、save_success 0件/1hで警報
- 運用：ロールバック手順、Feature Flagで段階展開
10. 合意形成の運び方（DACI）
D（Driver）：PdM（本ドキュメントのオーナー）
A（Approver）：プロダクト責任者
C（Contributor）：Eng/Design/CS/法務/分析
I（Informed）：営業/経営企画 など承認までの期限と、議論の落としどころ（譲れない条件／柔軟に動かせる条件）を先に明記します。
11. 失敗あるある＆回避策
- 詳細を書き込みすぎ：ドキュメントが古くなる → 契約と意思決定の材料だけ残す。
- 目標が売上一本：議論が発散 → 先行指標はPRDに固定（Aha/TTV/翌日活性）。
- スコープの穴：後追いでINが増える → OUTと非目標を最初に宣言。
- 技術の前提ズレ：工期崩壊 → 非エンジニアPdMは基礎を補強（開発知識入門）。
12. そのまま使えるPRD雛形（コピー用）
# タイトル
## Decision Statement
本PRDは ________ のスコープ/品質/計測を合意し、____ までにリリースするための意思決定材料である。
## 背景と狙い（Why）
課題・ユーザーの行動・事業上の機会を1ページで。
## 成功基準（KGI/KPI）
- KGI：____
- 先行KPI：Aha到達率 ____%、TTV中央値 ____ 分、翌日活性 ____ %
## スコープ（IN/OUT/非目標）
- IN：____
- OUT：____
- 非目標：____
## ユーザーストーリー
E1：____
S1：____
## 受け入れ基準（S1）
- AC1：____
- AC2：____
- AC3：____
## 画面・フロー・権限
ワイヤ・業務・ロール。
## データとAPI（契約）
I/O、エラー、バリデーション。
## 非機能要件（SLO/セキュリティ/監視/運用）
____
## 依存関係・リスク・決め待ち
____
## 追跡（イベント計測・実験計画）
イベント名、ダッシュボード、AB計画。
## DACI
D：____ / A：____ / C：____ / I：____受け入れ基準の書き方（Gherkin雛形10）
1) Given 新規ユーザー When 住所1文字→候補選択→保存 Then 成功トースト＋次導線表示
2) Given 成功直後 When 10秒滞在 Then 非モーダルヒント表示（入力保持）
3) Given 初回画面 When 主ボタン押下 Then 最近の作業3件が最上段
4) Given 成功直後 When 24±6h経過 Then 通知1回（直行リンク・解除導線）
…（以下略、合計10本）KPIの並べ方はKPI設計と運用ガイドに揃えます。
13. 関連記事（内部リンク）
14. 有料note＆特典テンプレ
この記事のPRDテンプレ（Google Docs）、受け入れ基準の言い換え辞書、非機能チェックリストは、有料noteで配布しています。購入者特典：PdMスキルテンプレート集（PDF）／キャリア戦略シート（PDF）。
15. まとめ：仕様書は“前に進めるための最小単位”
PRDは芸術作品ではありません。合意を速める骨だけを書いて、ドキュメントに意思決定を蓄える。今日のアクションは1つ、IN/OUT/非目標の3行を現場の案件に追記すること。そこから、会議は動き出します。
コメント