PRDを書く前・途中・書き上げた後に参照するガイド。
「エンジニア・デザイナーが方向性に迷わず、着手判断できるPRD」を書くための考え方と基準をまとめている。
注：PRDはチームの合意形成ツールであり、実装の全情報を網羅する文書ではない。UX 詳細やエッジケース、実装制約の詳細はPBIで定義する。PRDの目的は「何を、なぜ作るか」についてチームが迷わないことである。
このガイドの前提
不確実性そのものは問題ではない。不確実性が見えないことが問題。
良いPRDは完全な立証文書ではなく、「何を知っていて、何を知らなくて、だから今回何を決めたか」を透明にする文書である。
明確な基準がないと不確実性を曖昧な表現で隠してしまう傾向がある。
「〜と思われる」「〜になるはず」「〜な体験を作りたい」——こうした表現の問題は感覚であることではなく、根拠なのか仮説なのかが区別できなくなること。
このガイドは、知っていることと知らないことを分離し、知らないことは知らないと書くための基準を定める。
- 根拠が強いなら、大きく作ればいい
- 根拠が弱いなら、小さく試せばいい
- 根拠が弱いこと自体は問題ではない。根拠が弱いのに大きく作ることが問題
また、PRDの判断基準を定義するものであり、PRD自体がすべての項目を網羅すべきという意味ではない。
なぜこのガイドが必要か
感覚ベースの根拠で施策を進めると以下のような問題が繰り返し発生する。
- 施策 A：「ユーザーは〇〇を求めているはず」という前提でフル実装したが、リリース後に成功指標が動かなかった。前提としたユーザー行動がそもそも発生していなかった
- 施策 B：相関データ（「XをするユーザーはYが高い」）を因果として扱い、X を促進する機能を作ったが効果がなかった。自己選択バイアスを見落としていた
共通原因は「根拠が弱い段階で大きく作った」こと。このガイドはその再発防止を目的としている。
適用範囲
既存プロダクトの改善・拡張を伴うユーザー向け施策のPRDに適用する。規模（Umbrella / Feature）は問わない。
対象外：0→1 の探索的な取り組み（新規プロダクト、新規事業領域への参入等）はこのガイドの対象外。探索段階ではビジョン文書・プロトタイプ・PoC が適切であり、本ガイドの基準を機械的に適用すると検証以前にアイデアを潰すリスクがある。
適用が難しいケース（規制対応、セキュリティ、技術的負債解消など）は「適用しにくいケース」で読み替え方法を示す。
PRDの種類を見極める
PRDを書き始める前に、どちらのタイプかを判断する。
Umbrella PRD
- 役割：施策全体の方向性と段階計画を定める
- 例：「レコメンド機能によるユーザー継続率向上」
Feature PRD
- 役割：特定の機能・変更の方針と範囲を定める
- 例：「新規ユーザーのホームにレコメンド導線を追加」
迷ったときの判断基準：「このPRD単体で "なぜやるのか" を初めて読む人に説明する必要があるか？」→ Yes なら Umbrella、No（上位PRDを読めば分かる）なら Feature。
項目ごとの必須度
Whyの書き方
自分に問う
- 誰が、どんな場面で、何に困っているのか？——「ユーザー」ではなく、具体的なセグメントと行動パターン。「UX が悪い」ではなく、どの画面で何をしようとして何が起きるのか
- なぜそう言えるのか？——根拠はあるか？ないなら、何を調べれば根拠を得られるか分かっているか？
- この施策の対象は実際にどれくらいいるのか？——母数 × 条件該当率 = 対象規模の推定をしているか？ 推定した規模は施策の開発コストに見合うか？
落とし穴：課題を語っているつもりが、ソリューションの不在を語っている。「フィルターがないことが課題」→ ソリューションの不在。「大量の候補から自分に合うものを見つけられない」→ 課題。
構成
以下の順で書く。
1. 背景・現状：読み手が持っていない前提知識を共有する
2. 課題：ユーザーが具体的にどんな場面で何に困っているか
3. 根拠：データと事実による裏付け
4. 仮説：この施策で何が変わると考えるか。仮説として明示する
根拠の書き方
根拠には強さの階層がある。レベル別に扱いが異なる。
事実と推測の判別基準：数字の出所がログデータ・集計結果・テスト記録であれば事実。数字の出所が推論・仮定・類推であれば推測。表現ではなく出所で判断する。
定性的事実と観察の境界：再現可能な方法（テストプロトコル、ログ検索条件、件数集計）で確認されたものは事実。印象レベル（「最近多い気がする」）は観察。
定性根拠だけで始める場合：スコープは最小検証単位に限定する。定量による裏付けは Phase 1 の検証で得る。
原因分析を怠らない
表面的な数値を提示するだけでは不十分。「なぜその数値なのか」を掘り下げる。
悪い例：
新機能の利用率は 12%。導線が分かりにくいことが原因と考えられる。
問題：「導線が分かりにくい」は検証されていない推測。原因は他にもあり得る。
良い例：
新機能の利用率は 12%（類似機能 18%、-6pt）。考えられる原因：
- 仮説 A：導線が目立たず、機能に気づいていない
- 仮説 B：機能の価値が伝わっていない
- 仮説 C：使い勝手に問題があり、試した後に離脱
ファネル分析で導線クリック率が 1.2% と低いことから、まず仮説 A を優先検証する。
「相関 ≠ 因果」チェック
PRDにデータを書くとき、以下を自問する。
- 「Xをする人はYも多い」を示しているだけではないか？
- 逆因果（Yだから X をしている）の可能性は？
- 自己選択バイアス（もともとYになりやすい人がXを選んでいる）は？
- データを生み出した母集団自体に偏りがないか？（例：ある機能を設定した企業が、そもそも採用に積極的な企業に偏っている場合、その機能の効果は過大評価される）
相関を因果として扱う場合、A/B テスト等の因果検証計画がセットで必要。
悪い例（相関を因果として扱う）：
機能 X を利用したユーザーは継続率が高い（+20pp）。→ X をもっと見せれば継続率が上がる。
問題：継続するユーザーが X を利用している（逆因果）可能性を無視している。
良い例：
機能 X の利用と継続率の間に明確な相関が確認された（利用者 60% vs 未利用 35%）。ただしこれは相関ベースの理論値であり、因果は A/B テストで検証が必要。→ Phase 1 で A/B テストを行い、X への誘導が実際に継続率を高めるか検証する。→ 逆因果の可能性：「X を使ったから継続する」ではなく「継続するユーザーが X を使う」——この区別は A/B テストでのみ検証可能。
ユーザーセグメントを分ける
「ユーザー」を一括りにしない。セグメントごとに次を整理する。
- 現状の行動
- 課題
- 施策の効果見込み（高 / 中 / 低）
Whatの書き方
自分に問う
根拠の確信度に対して、施策の規模は適切か？ →「Whatの大きさは根拠の確信度に比例させる」で判断
Whatは「作りたいもの」ではなく「作ると決めたもの」
旅行に例えると、
- Why：「海が見える場所で休みたい」
- 期待する体験：「テラスでコーヒーを飲みたい」
- What：「7/15〜17、沖縄、海沿いの宿を予約」
PRDに置き換えると、
- Why：「ユーザーが〇〇を発見できない」
- 期待する体験：「〇〇を見ながら気づける体験を作りたい」
- What：「メンバータブのカードにタグを追加。ホームタブは今回やらない」
期待する体験はWhyを補強する材料。What（何をすると決めたか）ではない。
Whatに書く表現 / 書かない表現
NG表現とその理由・代替：
- 「〜したい」「〜な体験を作りたい」
- 理由：希望であり仕様ではない
- 代替：「〜を表示する」「〜に遷移する」
- 「〜と考えられる」
- 理由：推測であり確定していない
- 代替：確定なら断定。未確定なら「仕様が確定できない場合の書き方」に従う
- 「〜になるはず」
- 理由：効果の仮説であり仕様ではない
- 代替：仮説セクションに移動する
確定か未確定かの判別方法：文中の「〜と考えられる」「〜はず」「〜したい」を削除しても文が成立するか？ → 成立するなら確定仕様として書き直す。成立しないなら未確定事項として下記の形式で書く。
仕様が確定できない場合の書き方
Whatに書くべき仕様が確定できない場合がある。「確定できないから」と曖昧な表現（〜したい、〜と考えられる）で逃げず、以下の形式で書く。
### 未決定事項
#### [未決定の項目名]
**状態**：未確定（[理由：デザイン検証前 / 技術検証前 / データ不足]）
**選択肢**：
- A案：[具体的な内容] — メリット：... / デメリット：...
- B案：[具体的な内容] — メリット：... / デメリット：...
**推奨**：[A案 / B案]。理由：...
**確定方法**：[プロトタイプテスト / 技術スパイク / データ分析]
**確定時期**：[PBI 着手前 / Phase 1 中]未確定事項がWhatの中核（施策の成否を左右する部分）を占める場合、PRDのスコープを「検証」に縮小することを検討する。
Whatに必要な要素
1. 解決方針：複数の手段の中からなぜこのアプローチを選んだか
2. やること：具体的な機能・変更内容。確定した仕様を書く
3. やらないこと：スコープの境界。何を意図的に含めないか
4. ユーザーフロー：ユーザーが課題解決に至る経路の骨格
5. 前提条件・制約：技術的・事業的な制約
6. 未決定事項：決まっていないことを、上記の形式で明示する
Whatの大きさは根拠の確信度に比例させる
- 仮説段階（データなし）
- Whatの適切な大きさ：最小検証単位のみ
- 具体例：1 つのタブのみ。他画面はPhase 2以降
- 初期検証済み（相関あり）
- Whatの適切な大きさ：検証範囲を広げる。Phase 分割必須
- 具体例：主要画面に展開。ただし A/B テストで因果検証
- 因果検証済み（A/B テスト通過）
- Whatの適切な大きさ：本格実装
- 具体例：複数画面、複数プラットフォーム対応
判断の目安：「この根拠が間違っていた場合、Whatのうちどれだけが無駄になるか？」——無駄になる範囲が大きいなら、Whatを縮小するかPhaseを分ける。
指標の設定
自分に問う
- この施策が成功したとき、何がどう変わるのか？——「利用が増える」ではなく、どの指標が、いくつからいくつに変わるのか
- その指標は「機能が動いていること」ではなく「ユーザーの行動が変わったこと」を測っているか？
- 変わらなかった場合、どうするのか（中止基準、ピボット基準）は決まっているか？
2層構造
成功指標
- 役割：ユーザーの行動変化。施策の成否を判断する
- PRDに書くか：書く
- 数：2〜3 個
ガードレール指標
- 役割：既存の価値を毀損していないか監視する
- PRDに書くか：書く
- 数：1〜3 個
指標の数は施策の複雑さによって調整する。
診断指標（表示回数、クリック率等）はPBIの計測設計で定義する。
成功指標と診断指標の判別基準：その数値が動いてもユーザーの行動や状況が変わらないなら、それは診断指標である。
成功指標の条件
以下をすべて満たすこと。
- Whyの課題と直結しているか？
- アウトプット（機能の産出物）ではなく、ユーザー行動の変化を測っているか？
- この数値で「続ける / 止める / 方向を変える」を判断できるか？
- その数が適切なのか？
- 目標値に根拠があるか？
- この施策が直接生み出す変化を測っているか？ 既存の運営指標をそのまま流用していないか？
新規施策の場合：目標値の代わりに「意味のある変化の下限値」を定義し、その算出根拠を記載する。
例：「現状 0 の導線なので目標値の根拠はない。ただし開発コスト回収には月間 N 件の転換が必要であり、これを下限とする」
成功指標のよくある間違い
既存の運営指標（全体閲覧数、DAU 等）をそのまま施策の成果指標にする
- なぜ問題か：施策以外の要因で変動するため、施策の効果を判定できない
- 修正：施策が直接生み出す行動変化を測る指標を定義する（例：「全体閲覧数」ではなく「新導線経由の閲覧→応募転換率」）
数多い指標をPRDに定義する
- なぜ問題か：「何が成功か」のフォーカスが失われる
- 修正：成功指標 2〜3 個 + ガードレールに絞る
診断指標をPRDに書く
- なぜ問題か：表示回数やクリック率は原因分析用
- 修正：PBIで定義する
ガードレール指標の選び方
以下の問いで選定する。
1. この施策によって、ユーザーの既存行動が阻害される可能性はないか？
2. 隣接する機能の利用率に影響しないか？
3. ユーザーの不満や離脱を増加させないか？
仮説と検証設計
仮説の書き方
仮説 1：[対象ユーザー] に対して [施策の内容] を行うと、[測定可能な行動変化] が起きる検証設計の必須要素
- 検証方法：A/B テスト / 前後比較 / グループ間比較
- 期間：必要サンプルサイズから逆算。期間を先に固定してはならない
- 判定基準：どの数値がどうなれば「成功」か
- 中止基準：どの数値がどうなれば「この施策は効かない」と判断するか
中止基準の書き方
悪い例：
効果がなかったら中止する。
良い例：
4 週間の A/B テスト終了時点で、施策群の応募率が対照群に対して +2pp 以上の改善を示さない場合、中止する（根拠：類似導線施策の平均効果が +1.5〜3pp であり、+2pp を下限とした）。ガードレール：既存の求人閲覧率が対照群比 -5pp 以上低下した場合、期間途中でも中止する。
Phase 分割
注：Phase分割はUmbrella PRDで必要。Feature PRDは上位で既に定義されているため不要。独立小規模施策も、十分に小さければ不要。
Phase 設計の構造
Phase 1（検証）：最小単位で仮説を検証する
→ 移行基準：[具体的な数値条件]
→ 中止基準：[具体的な数値条件]
Phase 2（拡大）：Phase1の結果を元に範囲を広げる
→ 移行基準：[具体的な数値条件]
Phase 3（定着）：本格実装・全プラットフォーム展開Phase 1は仮説の因果を検証できる最小単位にする。検証に必要ない要素はすべてPhase 2以降に回す。
PRDとPBIの境界
項目ごとに、どちらに書くかを整理する。
判断基準：「方針の合意形成に必要か？」→ PRD。「実装着手に必要か？」→ PBI。
適用しにくいケース
以下の例外に該当する場合、PRDの検証設計セクションに (1) なぜ標準手法が使えないか と (2) 代替手段がなぜ妥当か を明記すること。例外の主張には根拠が必要であり、「該当するから省略する」は認められない。
A/B テストが困難な場合
対象ユーザーが少ない（2 週間で必要サンプルサイズを確保できない）、全ユーザーに即座に影響する変更等。
- 代替：前後比較、ログモニタリング、定性評価
- PRDに明記する：(1) A/B テストが困難な具体的理由（対象ユーザー数、影響範囲等）、(2) 代替手段で施策の効果をどう判定するか
ユーザー行動の変化が直接観測できない場合
バックエンド性能改善、データ基盤整備等。
- 代替指標を使う（レスポンスタイム → ページ離脱率 等）
- PRDに明記する：(1) なぜ成功指標を直接測定できないか、(2) なぜその代替指標が成功指標の代理として妥当か（相関の根拠等）
「やるべきことをやる」施策
規制対応、セキュリティ、技術的負債解消等。
- Why：「対応しないとどんなリスクがあるか」に置き換える
- 成功指標の代わりに完了条件を定義する（「脆弱性が解消されている」等）
セルフチェック
1. Whyに「〜と思われる」が根拠として使われていないか
- 不合格の場合：仮説セクションに移動し、検証方法とセットにする
2. Whatに「〜したい」が仕様として書かれていないか
- 不合格の場合：確定仕様に書き換える。確定できないなら未決定事項の形式で選択肢・推奨案・確定方法を書く
3. 主要指標は成功指標（ユーザー行動の変化）で、この施策が直接生み出す変化を測っているか
- 不合格の場合：既存運営指標の流用なら、施策固有の指標に置き換える
4. 成功指標の数が多すぎないか
- 不合格の場合：診断指標が混ざっていたらPBIに移動する
5. 課題の原因を 1 つに断定していないか
- 不合格の場合：複数の仮説を列挙し、この施策がどの仮説を検証するか明示する
6. 対象規模を推定しているか
- 不合格の場合：母数 × 条件該当率 = 実際に届くユーザー数
7. 根拠の確信度に対してWhatの大きさは適切か
- 不合格の場合：仮説段階なら最小検証単位に縮小する
8. 相関を因果として扱っていないか
- 不合格の場合：因果を主張するなら検証計画を書く
9. 提示したデータの中に、自分の論理と矛盾するものがないか
- 不合格の場合：(1) なぜその矛盾が生じるのか仮説を立てる → (2) その仮説を支持する根拠を示す → (3) 根拠がなければ、矛盾の解消を Phase 1 の検証に含める。3 ステップのいずれも満たせない場合、施策の前提を見直す
10. 目標値の算出過程に未検証の仮定が含まれていないか
- 不合格の場合：「訪問者の 10% が利用する想定」等の仮定に、類似実績・ベンチマーク等の裏付けがあるか確認する
11. 解決方針で代替案を比較検討しているか
- 不合格の場合：Whatの「解決方針」に、検討した他のアプローチとそれを採用しなかった理由を記載する
12. Phase の移行 / 中止基準が具体的な数値条件で定義されているか（Phase 分割が必要な場合）
- 不合格の場合：「効果がなければ中止」→ 数値条件に書き換える
推奨PRDセクション構成
## 組織目標との整合（Umbrella PRD / 独立小規模施策の場合）
## Why
### 背景・現状
### 課題
### 根拠
### ユーザーセグメント
### 仮説
## What
### 解決方針
### やること
### やらないこと
### ユーザーフロー
### 前提条件・制約
### 未決定事項
## 指標
### 成功指標
### ガードレール指標
## 検証設計
### Phase 計画（Umbrella PRDの場合）
## リスク
## Open Questions必須：Why / What / 指標
条件付き必須：組織目標との整合（Umbrella・独立小規模）、Phase 計画（Umbrella）
推奨：リスク / Open Questions
良いPRDの特徴
このガイドに沿って書かれたPRDは、以下の特徴を備えている。
- ユーザーセグメント別の行動データに基づく課題分析
- 相関データに対して「因果検証が必要」と明示し、検証設計がセットになっている
- Phase 分割と、具体的な数値条件による移行・中止基準
- 成功指標 2〜3 個 + ガードレール指標に絞った指標設定
- 「やること / やらないこと」が明確に分離され、解釈の余地がないWhat
