仕様書／要件定義の書き方｜“一枚で通るPRD”現場テンプレ（受入条件・非機能・計測まで）

「PRDを書いたのですが、また差し戻されました……」。
夜、メンバーからメッセージ。添付されたドキュメントは丁寧なのに、どこか“ぼやけて”いる。私は返しました。
「一枚で通そう。目的→価値→振る舞い→受入条件→計測、ここだけ残して他は捨てる」。
翌週、同じチームのレビューは10分で終わりました。決まったのは仕様ではなく、“振る舞い”と“判定方法”。その瞬間から、開発もCSも前に進み出します。

この記事のねらい
1. “一枚PRD”の骨格（コピペOK）
2. Aha/TTVから逆引きするPRD
3. 受入条件の“粒度”を合わせる（例付き）
4. 非機能（NFR）は“宣言”で速くする
5. レビューの回し方（Slack文面・台本）
6. よくある失敗と直し方（現場で本当に多い3つ）
7. チェックリスト（提出前に3分で確認）
8. 物語：差し戻され続けたPRDが通った日
関連記事（内部リンク）
有料note（深掘りと特典）

この記事のねらい

未経験〜ジュニアPdM向けに、一枚で通るPRDを現場テンプレ込みで渡します。ポイントは「機能を書く」のではなく、ユーザーの行動と先行指標（Aha/TTV/翌日活性）を先に固定すること。これで議論は短く、実装は速くなります。

1. “一枚PRD”の骨格（コピペOK）

背景→狙い→仕様の順に書くと、ほぼ確実に迷子になります。先に価値の振る舞いを決めてから逆算します。

# 一枚PRD（Product Requirements Document）

■目的（1行）
誰の・どの行動を・なぜ今、変えたいのか

■価値の振る舞い（ユーザーストーリー）
As：＿＿＿（対象セグメント）
When：＿＿＿（状況/トリガー）
I want：＿＿＿（やりたいこと）
So that：＿＿＿（得られる便益）
制約：3クリック/1画面1目的/次の一歩が1つ

■受入条件（Acceptance Criteria / Given-When-Then）
- Given：＿＿＿の初期状態
- When：＿＿＿を行う
- Then：＿＿＿が保存/反映される（イベント名：aha_done）

■非機能（NFR）
性能：p95 ＿＿ms以内 / 可用性：＿＿% / 権限：＿＿
セキュリティ：PIIの扱い/ログのマスキング

■計測と判定（先行指標）
Aha定義：＿＿＿＿
TTV：aha_start→aha_done の中央値
翌日活性：D1での ＿＿ 行動の再開率
ロールバック条件：＿＿＿＿

■やらないこと（Non-Goals）
- ＿＿＿＿
- ＿＿＿＿

■影響範囲・リスク
CS/営業への影響、運用変更、データ移行

■付録（UI草案/文面）
空状態/完了モーダル/ナッジ台本（次の一歩を1つ）

ねらい：「仕様」ではなくユーザーの“振る舞い”を起点に合意する。
やり方：As-When-I want-So that を1行ずつ。受入条件はGiven-When-Thenの完了判定を書き切る。
よくある失敗：画面遷移やフィールドの列挙に終始→Thenの状態（何が保存/反映されたか）を最初に置く。

2. Aha/TTVから逆引きするPRD

会議が長くなる理由の9割は、判定日がないから。私はPRDの最上段に先行指標と判定日を置きます。

Aha：ユーザーが価値を感じた行動（例：初回○○の保存）
TTV：Aha到達までを3クリックで設計する
翌日活性：翌日に「次の一歩」を1つだけ提示し、再開を計測

設計の詳細は、オンボーディング設計とTTV短縮の完全ガイドが体系化されています。PRDに落とす際は、イベント名（aha_start/aha_done）まで先に書いておくと、計測のすり合わせが一発で終わります。

3. 受入条件の“粒度”を合わせる（例付き）

受入条件が「なんとなく」だと、工数も責任も漂流します。保存・反映・可視化のどこまで担保するかを書き切る。

Given：初回ユーザーでテンプレートが1つ設定済み
When：テンプレートを選び「保存」を押下
Then：カードが作成され、一覧先頭に表示。イベント「aha_done」が発火し、
      完了モーダルで「次の一歩（共有）」のボタンだけ表示される

ねらい：誰が読んでも同じ“完了”が浮かぶ。
やり方：UI名ではなく、状態変化で書く。
失敗例：「正しく表示される」→何がどこにどう見えるかを書く。

4. 非機能（NFR）は“宣言”で速くする

PRDにNFRがないと、あとから炎上します。私は毎回、p95応答時間・可用性・権限だけでも宣言させます。

性能：p95 200ms以内（リスト/保存時）
可用性：現行SLA準拠（99.9%）
権限：作成/編集は担当者のみ、閲覧はチーム
セキュリティ/ログ：個人情報のマスキング／監査ログを14ヶ月保持

NFRの視点は、要件定義の完全ガイドでも詳述。PRDの一等地に置くと、設計がブレません。

5. レビューの回し方（Slack文面・台本）

レビューは“会議”ではなく、宣言を確認する場にします。Slackはこの定型で。

件名：【PRDレビュー依頼】機能名／判定日◯/◯（Aha/TTV/D1で判定）

目的（1行）：＿＿＿
価値の振る舞い：As/When/I want/So that
受入条件（GWT）：＿＿＿＿
非機能：p95 ＿＿ms、可用性＿＿%、権限＿＿
計測：aha_start/aha_done、TTV中央値、D1再開率
やらないこと：＿＿＿＿
判定日：＿＿／ロールバック条件：＿＿

※10分ミーティングで「受入条件と判定方法」だけ合わせさせてください。

レビュー台本は、MVP検証設計（BtoBtoC向け）の“賭けの宣言”と同じ流儀。賭け→判定→次の賭けの順で淡々と進めます。

6. よくある失敗と直し方（現場で本当に多い3つ）

“画面の説明”になっている→ 行動の理由と状態変化で書く（保存/反映/可視化）。
受入条件が曖昧→ Given-When-Then を1行ずつ。Thenにイベント名を埋める。
計測が後回し→ PRDの先頭にAha/TTV/D1と判定日を書く。ロールバック条件も宣言。

7. チェックリスト（提出前に3分で確認）

目的は「誰の・どの行動を・なぜ今」になっているか
価値の振る舞い（As/When/I want/So that）が1スクリーン1目的になっているか
受入条件がGWTで状態変化として書かれているか
非機能をp95/可用性/権限/セキュリティで宣言したか
Aha/TTV/翌日活性の計測と判定日、ロールバック条件があるか

8. 物語：差し戻され続けたPRDが通った日

あの日、メンバーは“説明”をやめて、宣言を書きました。
「初回ユーザーがテンプレを1タップで保存。完了モーダルで“共有”だけを提示。aha_doneで計測」――会議室が静かになり、エンジニアが言いました。「それなら今日から作れます」。CSも続きます。「完了文面、私たちで書きます」。10分後、判定日が決まりました。
数字は翌週に動きました。TTVが短くなり、翌日活性が小さく跳ねました。PRDは仕様の書類ではない。チームの合意を短く作る、前進のスイッチです。

有料note（深掘りと特典）

さらに深くやりたい方へ、価値設計とAha/TTVの型（有料）／課題解決の現場運用（有料）もどうぞ。
特典：PdMスキルテンプレート集（PDF）／キャリア戦略シート（PDF）