仕様書／要件定義の書き方（現場テンプレ）｜“速さ×納得”を両立するPRDの作り方

「仕様書って、結局どこまで書くんでしたっけ？」
夕方の会議室。時間だけが過ぎ、決まったのは「次回までに詰める」という言葉だけ。——あるあるです。私も初期は、分厚いドキュメントで安心しようとして、結果的に開発は迷い、CSは不安になり、ステークホルダーは“今どこ？”が分からなくなる循環にはまりました。
転機は、PRD（Product Requirement Document）＝意思決定ログ＋受入基準と割り切ったこと。つまり“書くことを減らし、決めることを増やす”。この記事は、未経験〜ジュニアPdMが今日から使える1枚PRDの型・チェックリスト・コピペ素材をまとめたものです。

結論：PRDは「意思決定ログ」と「受入基準」だけで回る

意思決定ログ：狙い／やらないこと／優先順位／依存関係。議事録ではなく“なぜこう決めたか”が残るメモ。
受入基準：Given-When-Thenや定量しやすいKPIで、できた判定を明確にする。

あとは、使う場面で足す。要件は「全部先に書く」ではなく、「検証・実装の直前に必要分だけ最短で足す」が原則です。

1. スコープ定義（目的・非目的・背景）

リストの前に一言。スコープは“やること”より“やらないこと”を先に固めると、会議が一気に進みます。

ねらい：議論を一点に集中させ、手戻りを減らす。
やり方：目的は先行指標（Aha/TTV/翌日活性等）で定義。非目的を3つに絞って明記。
失敗と直し方：抽象表現（“UX向上”）→観察可能な表現（“初回TTVの中央値を30％短縮”）へ。

◆ コピペ：目的・非目的テンプレ

【目的】初回Aha到達までの時間を短縮し、翌日活性率を底上げする
【非目的】(1) 既存会員向けの深い分析機能 (2) 全画面のUI刷新 (3) 課金導線の最適化
【背景】新規の◯◯%が住所入力で離脱。Ahaまで遠く、初回体験が弱い

2. シナリオで書く（ユースケース台本）

仕様は“画面の並び”ではなく、“利用の台本”で書くとズレません。登場人物・状況・トリガー・期待結果・障害・代替を1本のストーリーに。

ねらい：設計者と実装者、CSが同じ場面を思い浮かべられるようにする。
やり方：モバイル／デスクトップ、広告流入／自然流入など主要コンテキスト別に1本ずつ。

◆ コピペ：ユースケース台本

登場人物：新規ユーザー（スマホ・通勤中）
状況：LP→登録→初回セットアップ
トリガー：住所入力ステップに到達
期待結果：3分以内にAha画面（◯◯の即時プレビュー）へ
障害：郵便番号が分からず離脱
代替：住所検索を先頭に/数字キーボード/サンプル自動表示

3. 要件の粒度（機能・非機能・データ）

「機能だけ」では必ず詰みます。非機能（NFR）とデータ契約まで落とし込むのが“現場仕様”。

◆ 機能要件（抜粋）

郵便番号入力→住所自動補完（モバイルは数字キーボード、自動フォーカス）
空状態に完成イメージ（ダミーデータ）と“次の一歩”ボタンを表示
エラー時は入力欄直下に1行表示（画面上部のまとめエラー禁止）

◆ 非機能要件（NFRチェック）

性能：モバイル3G相当でもAha画面表示 < 2.5s / 99p < 4s
可用性：計測イベントのロス < 0.1%
セキュリティ：住所は送信前にマスキング/SSL強制
アクセシビリティ：フォームにlabel/aria、フォーカスリング可視
ログ：start_onboarding / friction_zip / reach_aha / next_action を必須

◆ データ契約（API/イベント）

POST /api/v1/address/resolve
req: { "zip": "1234567" }
res: { "pref": "◯◯", "city": "△△", "line1": "□□", "cache": true }

event.reach_aha
{ "uid": "...", "ts": "...", "platform": "iOS|Android|Web", "ttv_ms": 123456 }

4. 受入基準（Acceptance Criteria）

ここが“できた判定”。曖昧だと終わりません。Given-When-Thenと数値を併用します。

◆ コピペ：受入基準

Given 新規ユーザー/モバイル/広告流入
When 住所入力ステップに到達
Then 郵便番号入力で住所が自動補完される（99p < 600ms）

Given Aha画面の初回表示
When プレビューが描画される
Then 次の一歩（◯◯）のクリック率が対照比 +Xpt 以上

KPI：Aha到達率 +Xpt、TTV中央値 -Y%、翌日活性 +Zpt（悪化なし）

5. 依存関係・リスク・ロール

依存：住所APIのスロットリング／計測SDKのバージョン／CSの案内文更新
リスク：補完ミスによる返品/誤配送→手入力に強制切替の退避動作を用意
ロール（DACI）：Driver=PdM / Approver=◯◯ / Contributor=Eng/Design/CS / Informed=Biz/Ops

6. スプリント0：最短で決めるための準備

ねらい：実装前に“不確実性”だけを潰す。
やり方：クリックダミーでユーザーテスト→MVP検証の型でYes/Noを即決。
補足：オンボーディング/TTV短縮の観点で、ゴールデンパスを5〜7手に削る。

7. よくある失敗と直し方（現場あるある）

画面単位で合意してしまう：実装が近づくと破綻。→ユースケース台本で合意し直す。
非機能が“空欄”：性能・計測・セキュリティ抜け。→NFRチェックをテンプレ化。
“できた”の定義が人によって違う：→受入基準をGiven-When-Then＋数値で。
議事録ばかり増える：→意思決定ログだけ残す（却下理由も書く）。

8. 1枚PRD（貼って使う）

# タイトル：住所入力オンボーディング最適化
目的：Aha到達率 +Xpt / TTV -Y%
非目的：深い分析機能/全画面刷新/課金導線最適化
背景：モバイル新規の◯◯%が住所入力で離脱
ユースケース：新規/通勤中/スマホ→3分でAha
機能：郵便番号→自動補完/空状態のプレビュー
非機能：3G相当2.5s/計測ロス<0.1%/SSL/アクセシビリティ
データ契約：/api/v1/address/resolve, event.reach_aha
受入基準：Given-When-Then + KPI（Aha/TTV/翌日活性）
依存：住所API/SDK/CS案内
ロール：DACI（PdM/承認/貢献/通知）

9. チーム運用のスニペット集（コピペOK）

◆ Slack合意テンプレ

#prd-aha-address
目的：Aha/TTVの改善で初回体験を底上げ
決定：郵便番号検索を先頭/空状態プレビュー/数字キーボード
受入基準：reach_aha +Xpt、time_to_aha -Y%
Next：クリックダミー→5人テスト→実装スコープFIX（金）

◆ CS向け案内文（エラー時）

「郵便番号7桁で住所が自動入力されます。合わない場合は“手入力に切り替え”を押してください。」

10. 関連コンテンツ（内部リンク）

まとめ：仕様は「薄く、鋭く」

分厚い仕様は安心をくれるけれど、速さはくれません。意思決定ログ＋受入基準の1枚を核に、使う場面で必要分だけ足す。ユースケース台本で合意し、NFRとデータ契約で穴を塞ぎ、先行指標で“できた”を切る。これだけで、会議は短く、実装は速く、品質は安定します。まずは、あなたのチームで“1枚PRD”を導入してみてください。

有料noteでもっと深く学ぶ：
PdM初心者のための仕事大全【保存版】／
PdM転職・年収戦略の実践ノート
特典：PdMスキルテンプレート集（PDF）／キャリア戦略シート（PDF）