仕様書／要件定義の書き方｜現場で通るテンプレと“受入条件”の作り方

「きれいな仕様書を書いたのに、なぜ進まない？」——転職直後の私もここで転びました。原因はシンプルで、“受入条件（DoD）”が曖昧だったから。この記事では、ジュニアPdMでも今日から使える課題→要件→受入条件の最小テンプレと、会議が短く終わる合意形成のコツをまとめます。

1. 現場で通る“最小”PRDの骨格

前置き：分厚い仕様書はゴールではありません。目指すのは実装の迷いゼロとテストの迷いゼロ。下の型をそのまま使ってください。

# 背景（1行）
誰の・どの行動にどんな摩擦があり、なぜ今やるのか。

# 目的（O）と先行指標（KR）
O：初回価値（Aha）到達を最短にする
KR1：Aha到達率 +Xpt / KR2：TTV -Y% / KR3：翌日活性 +Zpt

# 要件（機能/文面/導線/運用）※広義のプロダクト
- UI：◯◯画面のCTA文言を「はじめる」に変更し、上段へ移設
- 文面：初回ガイドを質問→選択型に
- 導線：登録完了→Aha画面へ自動遷移
- CS：初回問合せの台本をAha到達支援に寄せる

# 受入条件（DoD）
- 3ステップ以内でAhaに到達できる
- ファーストビューでCTAが視認できる
- 完了後に“次の一手”が1つだけ提示される
- ログに「途中離脱理由」が1行で残る

# 非機能（抜けがちな必須）
- パフォーマンス：初回表示 2.5s以下
- 計測：Aha/TTV/翌日活性のイベント設計
- アクセシビリティ：キーボード操作で完了可能

2. 失敗パターンと直し方

背景：未経験PdMは仕様＝UIだと誤解しがち。狙い：広義のプロダクト（文面・導線・CS）まで要件化。分かること：チーム全員が同じゴールを見るための具体。

• 失敗：機能だけ決めて“文面・導線・CS”が空欄 → 直す：上の要件4点を全部埋める
• 失敗：受入条件がない → 直す：テスト観点（3クリック/視認性/次の一手/ログ）を書く
• 失敗：非機能を後追い → 直す：2.5s/イベント/アクセシビリティを最初に明記

3. 合意形成：Slackは“一行テンプレ”で短く終わらせる

件名：要件定義（Aha到達の摩擦解消）Driver: PdM / Approver: EM
目的：TTV -30% / Aha +10pt
要件：UI/文面/導線/CS（上記）
受入：3クリック以内、CTA視認、次の一手提示、離脱理由ログ
期限：本日17:00までに Approve/Comment で返信ください

4. ねらい／やり方／よくある失敗と直し方（要点まとめ）

• ねらい：DoDを先に決め、実装とQAを一直線に。
• やり方：課題→要件→受入条件の順で記述。非機能は冒頭に置く。
• 失敗：「出した」で終わるKPI → 直す：Aha/TTV/翌日活性に落とす。

5. 参考と内部リンク

• オンボーディング設計とTTV短縮の完全ガイド
• MVP検証設計（BtoBtoC向け）完全ガイド
• ユーザーインタビュー完全ガイド｜質問例＆失敗回避
• RICEで迷わない優先順位付け
• 要件定義の壁：未経験でも乗り越える実践ガイド

有料note：テンプレ全種と実例はここに集約しています。
PdMドキュメント術（PDFテンプレ付） ／
ジュニアPdMの成長戦略
特典：PdMスキルテンプレート集（PDF）／キャリア戦略シート（PDF）