製品要件のプレゼンは、PRDをそのまま貼り付ける資料ではありません。レビューで必要な課題、対象範囲、対象外、受け入れ条件、未決の判断を先に示します。確認済みの構成からテキストからプレゼンテーションの初稿を作れますが、要件と制約は必ず自分のPRDに基づけてください。
課題と目的を明確にする
ユーザーの課題と、レビューで決めることから始めます。利用状況の観察や問い合わせの傾向など、根拠を示しつつ、データが支える以上の確実性を付けないようにします。目的は望む変化を述べるもので、技術解決策そのものではありません。
対象範囲と対象外を分ける
含める利用ケースと、意図的に含めないケースを分けて書きます。対象外を明示すると、レビュー中に範囲が静かに広がるのを防げます。仮説や未回答の問いは、確定した要件として扱わずラベルを付けます。
確認できる受け入れ条件にする
誰が、どの条件で、何をできればよいのかを観察可能な結果として書きます。「簡単」「速い」など、基準がない言葉だけで終わらせません。各条件に優先度と既知の依存関係を付けます。
依存関係とリスクを示す
連携先、データソース、法務確認、他チームの判断を示します。依存関係は必ずしもブロッカーではないため、状態、担当者、次の行動を記録します。未確認の日付を納期として約束しないでください。
判断ログを入れる
最後に、判断、選択肢、提案、理由、担当者、期限を短い表にまとめます。決定済み、提案、要確認を分けることで、会議後に何が合意されたかが残ります。
レビュー用の基本構成
- 課題、目的、レビューの問い
- 対象ユーザーと根拠のある背景
- 対象範囲と対象外
- 要件と受け入れ条件
- 依存関係、リスク、仮説
- 未決事項と次の行動
各スライドは一つの判断または根拠を中心にします。プレゼンはレビューを短くするためのもので、完全なPRDの代わりではありません。
この形式の限界
プレゼンは判断のための入口です。完全な仕様書や実装を置き換えません。PRDへの参照を残し、変更点を示し、レビューで確認された内容だけを確定事項として扱います。
レビューで決めることを書く
「共有受信箱の初回リリース範囲を承認する」のように、最初に決定を一文で示します。決裁者、確認日、ユーザーまたは事業の課題も添えます。プロジェクト名だけでは、正しい問いに答えているか判断できません。
観察した根拠と境界を使って課題を説明します。「会話がキューを移るとサポート担当者が文脈を失う」は課題、「新しいルーティングサービスを作る」は実装仮説です。遅れて参加した人にも、決定、提案、範囲、未解決のリスクが伝わる一枚目にします。
範囲を三つに分ける
リリースを、対象、対象外、後回しに分けて示します。対象はユーザーの行動や観察可能な結果で書きます。共有受信箱なら、一つのキューへの割り当て、担当者の表示、引き継ぎの記録が対象になり得ます。感情による自動振り分けやモバイル版は対象外の例です。これは説明用であり、約束した機能ではありません。
二つの要件が衝突したらトレードオフを示します。早い初回リリースでは一つの認証プロバイダーだけを支援し、他は次の段階にする場合があります。影響と、この妥協を受け入れる担当者を明記します。
最小の利用フローを説明する
トリガー、ユーザーの重要な選択、期待する結果を含む主なフローを一つ選びます。主経路を理解するまで例外は別に扱います。各ステップに必要な情報、操作、受け取るフィードバックを記載し、ポリシーや外部サービスへの依存を示します。画面を埋めるために存在しない操作を作らないでください。
要件に影響するアクセシビリティとエラーも示します。要求が拒否された、接続できない、権限がない場合に何が起きるかを確認します。成功時だけを描くフローは完全な要件ではありません。
受け入れ条件を検証可能にする
「条件があるとき、操作が起きたら、結果が見える」の形で書きます。機能、品質、運用準備の条件を分けます。リスクの高い条件には、自動テスト、ユーザビリティセッション、セキュリティレビュー、負荷テスト、手動確認などの方法を付けます。方法は成功の保証ではなく、リリース前に合意した確認手段です。
依存関係と選択肢を示す
認証プロバイダー、データ移行、法務確認、デザインシステムの部品、別チームのAPIを、担当者と状態付きで並べます。タイムラインはレビューに必要な連携、テスト、判断の地点に絞り、確度の低い見積もりを納期として扱いません。選択肢は学習までの時間、戻しやすさ、ユーザーリスク、保守負担で比較し、なぜ優先するかの基準を明記します。
記録できる承認で終える
範囲を承認、条件付き承認、具体的な修正のための差し戻しのいずれかを依頼します。承認、対象外、次の担当者、見直し日を判断ログに残します。根拠が弱い場合は、学習目標を持つ調査やプロトタイプを提案します。PRDとバージョン日付も一緒に送り、当時の既知、選択、未解決を後から確認できるようにします。
レビューで使う証拠をそろえる
各要件には、どの資料や観察が根拠なのかを短く添えます。仕様の記述、利用者の観察、法務の確認、技術的な制約は別の種類の情報です。混ぜずにラベルを付けると、議論が「好み」ではなく確認できる事項に戻ります。
要件どうしが競合する場合は、一つのリストに詰め込まず、どの結果を優先したかを示します。優先順位の理由、受け入れるリスク、後で見直す条件を一行で記録してください。
受け入れ条件の例を作る
条件、操作、期待する結果の組み合わせを、レビュー参加者がその場で読める例にします。「権限がない人は送信できない」「接続が戻ったときに未送信内容を失わない」のように、確認する状態を具体的に示します。測定基準が決まっていない「速い」「直感的」は、そのまま受け入れ条件にしません。
高リスクの条件には、どのチームが、いつ、どの方法で確認するかを付けます。チェック方法がまだ決まっていなければ、未決事項として表に戻し、決める人と期限を置きます。
依存を追跡する
外部API、認証、データ移行、デザイン部品、法務判断など、別チームの状態に左右される要素を一覧にします。各項目に担当者、現在の状態、次の確認日を付けます。担当者のいない依存はリスクまたは判断事項として扱います。
判断ログを残す
会議の終わりには、承認した対象、除外した対象、条件、担当者、次回の見直し日を表にまとめます。「検討する」だけでは結果が曖昧になるため、承認、条件付き承認、差し戻しのどれかを選びます。
根拠が不足しているときは、調査やプロトタイプを次の作業として切り出し、何を学べば判断できるのかを明記します。不確かな納期や成功率を、決定済みの計画として書かないでください。
共有後も更新を追えるようにする
PRDとプレゼンを同じバージョン日付で保存し、変更した要件と変更理由を記録します。原資料が更新されたら、どの判断が影響を受けるかを再確認します。こうした履歴があると、後から読んだ人も当時の情報と判断の境界を理解できます。
各要件に優先度を付け、レビューで確認した人と日付も残します。仕様書の変更で判断をやり直すとき、何が変わったかを短い差分として説明できるようにします。
最終スライドには、決めたこと、決めなかったこと、次の問いを分けて置きます。これにより、参加者は合意の範囲を読み違えずに実装へ進めます。
判断の条件と期限を共有することで、レビュー後の作業も迷いません。
公開後も原資料との対応を維持できます。
関係者が同じ判断を再確認できます。
変更の理由も追跡できます。
合意の境界を保ったまま進められます。
実装前の確認が容易になります。
レビューの再現性を高めます。
関係者に共有します。
