【2025年版】【図解】仕様書／要件定義の書き方｜“一枚PRD”と受入条件テンプレで差し戻しをゼロにする
結論：差し戻しは「完了の姿」が曖昧だから起きます。 私は、Aha/TTVなど先行指標から逆算した一枚PRD＋受入条件（GWT）で、合意形成と実装を一気に前に進めています。この記事は、現場で使う文章・雛形・会話台本までをまとめた「読む→そのまま使える」ガイドです。
「また戻ってきた…」
深夜のSlackでレビューが返ってきた瞬間、私はリビングの照明を少し落としました。チームは頑張っている。なのに、出来上がるものは狙いから半歩ズレる。翌朝の朝会、私は冒頭でこう言いました。
私「今日から仕様は一枚だけにします。完了の姿はGWTで3行。非機能・計測・リスクは脚注。理由は単純、『読まれること』が正義だから。」
エンジニア「長いPRD、正直読み切れないんですよね…」
デザイナー「完了の姿が先にあるの、助かる」
CS「合意が1枚に収まっていれば、リリース後の案内も早いです」
その四半期、差し戻しはほぼゼロになり、開発速度は静かに上がりました。鍵は、言葉の設計と完了の定義です。
私の考えるPdM（マネージャーとして）
「PdMはミニCEO」——私は少し言い換えます。“価値の番人であり、学習装置の設計者”。数字に責任を持ちながら、現場の学びが最短距離で意思決定に合流する仕組みをつくる役割です。朝のダッシュボードで私が最初に見るのはAha到達率とTTV。ここが2ポイントでも動けば、その日の会議は早く終わる。動かなければ、やることを増やすのではなく仮説を削る。合意文書は人を動かす文章であり、やる理由／やらない理由を同じ温度で書くのが流儀です。UIの外側（CSの文面、営業資料、オンボーディング）も広義のプロダクト。だから仕様書は短く、強く、実務に“効く”形で。
1. 仕様書／要件定義のゴール（ねらい／やり方／失敗と直し方）
ねらい：「やること」ではなく価値の変化を合意する。
やり方：一枚PRDに、O/KR（先行指標）、完了の姿（GWT）、非機能、計測、リスクを凝縮。
失敗と直し方：長文PRDで迷子 → 一枚＋脚注へ。レビューの順序はO/KR→GWT→非機能→計測→リスク。
先行指標の設計は、オンボーディング設計とTTV短縮の完全ガイドに具体例をまとめています。Ahaの定義に迷う場合は、ユーザーインタビュー完全ガイド｜質問例＆失敗回避で軽量定性の回し方をどうぞ。
2. “一枚PRD”のテンプレ（コピペOK）
背景→仮説→完了の姿→非機能→計測→リスク。Slackで貼る前提の長さに抑えます。
[One-Page PRD]
タイトル：＿＿＿＿（誰の／どのジョブ）
O（価値の変化※一文）：新規Aha到達率 20%→35%（四半期）
KR：TTV 6→4分｜翌日活性 18%→25%
背景：＿＿＿＿（観察/定性インサイト）※リンク
仮説：＿＿＿＿（文面/導線/CSでAhaが早まる）
完了の姿（GWT）：
Given：新規ユーザーが初回起動後
When：レコメンド導線を辿り、サンプル適用→保存
Then：アプリ内で「はじめての○○」完了トーストを表示し、Aha計測イベントを送る
非機能（SLO）：p95応答 < 300ms／可用性 99.9%／アクセシビリティ AA
計測（イベント名）：aha_viewed / aha_completed / next_day_return
リスク：＿＿＿＿（既存導線／既存KPIへ影響）
備考：CSスクリプト・メール文面の更新をセットで
ロードマップへの落とし込みは、ロードマップ作成｜基礎から実践までの型がそのまま使えます。
3. 受入条件（GWT）の書き方──差し戻しを消す“3行”
ねらい：「完了の姿」を合意し、齟齬を潰す。
やり方：Given/When/Thenの3行で、誰が・どの状態で・何をしたら・何が起きるかを書くだけ。
失敗と直し方：UIの見た目だけを書く → 状態と計測を必ず入れる。
[GWTスニペット（雛形）]
Given：＿＿＿なユーザーが＿＿＿の状態で
When：＿＿＿を行うと
Then：＿＿＿が表示され、イベント＿＿＿が送信される（p95<300ms）
4. 非機能要件の“最低限”チェックリスト
非機能は後回しにされがちですが、実は一番揉めます。最低限、以下をPRD脚注に固定します。
- 性能：p95応答時間／同時接続数／バッチ完了時間
- 可用性：SLO／フェイルセーフ／サーキットブレーカー
- セキュリティ：認証／権限／監査ログ／個人情報の扱い
- アクセシビリティ：コントラスト、フォーカス、代替テキスト
- 互換性：対応OS/ブラウザ／後方互換ポリシー
- 運用：監視項目／アラート閾値／ロールバック手順
5. 計測設計：Aha/TTV/翌日活性を“先頭に”
ねらい：価値の変化を短サイクルで検証する。
やり方：イベント命名、パラメータ、トリガーをPRDに記載。
失敗と直し方：PV/セッションだけ → Aha到達率／TTV（分）／翌日活性（%）を先頭に。
計測の置き方は、PdMスキルマップ完全ガイドの「定量」セクションが復習に向いています。ミニMVPの切り方は、MVP検証設計（BtoBtoC向け）が近道です。
6. レビュー運用：台本とSlack文面（コピペOK）
台本（30分）：
1) O/KR（先行指標）→ 2) GWT（3行）→ 3) 非機能→ 4) 計測→ 5) リスク→ 6) 反対意見
[Slack：レビュー依頼テンプレ]
#prd-review / タイトル＿＿＿＿
狙い：Aha到達率 20%→35%
GWT：Given＿＿ When＿＿ Then＿＿（イベント＿＿）
非機能：p95<300ms／AA準拠
計測：aha_completed / next_day_return
期限：＿＿/＿＿（差し戻しはGWTにコメント）
7. よくある失敗と直し方（現場の実例）
- 失敗：「やること」の羅列でPRDが長文化。
直し方：O/KR→GWT→非機能→計測の順に一枚へ集約。 - 失敗：“体験の外側”が未整備（CS文面・メール未更新）。
直し方：PRD備考に広義のプロダクト（文面・導線・CS）を必須化。 - 失敗：差し戻し理由が毎回バラバラ。
直し方：レビュー順序を固定し、反対意見はGWT/非機能/計測の3軸に限定。
8. すぐ使える“配布物”セット
以下は、そのままチームに配れる雛形です。
[1-Page PRD 見出し]
タイトル／O／KR／背景／仮説／GWT／非機能／計測／リスク／備考
[受入条件（GWT）3連]
G：＿＿／W：＿＿／T：＿＿
G：＿＿／W：＿＿／T：＿＿
G：＿＿／W：＿＿／T：＿＿
[レビュー台本（司会用）]
O/KR→GWT→非機能→計測→リスク→反対意見→結論（DECIDE-LOG）
関連記事（内部リンク）
有料noteのご案内（特典つき）
この記事が役に立ったら、下記の有料noteもどうぞ。特典：PdMスキルテンプレート集（PDF）／キャリア戦略シート（PDF）
コメント