製品要件のプレゼンは、PRDをそのまま貼り付ける資料ではありません。レビューで必要な課題、対象範囲、対象外、受け入れ条件、未決の判断を先に示します。確認済みの構成からテキストからプレゼンテーションの初稿を作れますが、要件と制約は必ず自分のPRDに基づけてください。
レビューで決めることを書く
「共有受信箱の初回リリース範囲を承認する」のように、最初に決定を一文で示します。決裁者、確認日、ユーザーまたは事業の課題も添えます。プロジェクト名だけでは、正しい問いに答えているか判断できません。
観察した根拠と境界を使って課題を説明します。「会話がキューを移るとサポート担当者が文脈を失う」は課題、「新しいルーティングサービスを作る」は実装仮説です。遅れて参加した人にも、決定、提案、範囲、未解決のリスクが伝わる一枚目にします。ユーザー調査結果のプレゼンガイドでは、少人数の定性調査を利用者全体の結果として扱わずに、観察から製品の判断につなげる方法を紹介しています。
範囲を三つに分ける
リリースを、対象、対象外、後回しに分けて示します。対象はユーザーの行動や観察可能な結果で書きます。共有受信箱なら、一つのキューへの割り当て、担当者の表示、引き継ぎの記録が対象になり得ます。感情による自動振り分けやモバイル版は対象外の例です。これは説明用であり、約束した機能ではありません。
二つの要件が衝突したらトレードオフを示します。早い初回リリースでは一つの認証プロバイダーだけを支援し、他は次の段階にする場合があります。影響と、この妥協を受け入れる担当者を明記します。
最小の利用フローを説明する
トリガー、ユーザーの重要な選択、期待する結果を含む主なフローを一つ選びます。主経路を理解するまで例外は別に扱います。各ステップに必要な情報、操作、受け取るフィードバックを記載し、ポリシーや外部サービスへの依存を示します。画面を埋めるために存在しない操作を作らないでください。
要件に影響するアクセシビリティとエラーも示します。要求が拒否された、接続できない、権限がない場合に何が起きるかを確認します。成功時だけを描くフローは完全な要件ではありません。
受け入れ条件を検証可能にする
「条件があるとき、操作が起きたら、結果が見える」の形で書きます。機能、品質、運用準備の条件を分けます。リスクの高い条件には、自動テスト、ユーザビリティセッション、セキュリティレビュー、負荷テスト、手動確認などの方法を付けます。方法は成功の保証ではなく、リリース前に合意した確認手段です。
AtlassianのPRDガイドは仮定と対象外の範囲を明記しています。未決の動作も、決まった仕様と区別して示します。
共有受信箱の例では、会話はすでにキューQにあり、初回リリースで権限のある担当者が自分に割り当てられるとします。以下は架空の製品に対する受け入れ条件案であり、Presentiの機能や実施済みのテストではありません。範囲のスライドに示した感情による自動振り分けとモバイル版は対象外のままです。
| 条件と操作 | 確認する結果または未決事項 | 方法と責任者 |
|---|---|---|
| Q内の会話が未割り当てで、Qを扱う権限のある担当者が自分に割り当てる | その担当者が表示され、開き直しても割り当てが維持される。引き継ぎ記録には操作した人と会話が残る | QAが権限のあるアカウントで操作し、保存された割り当てと引き継ぎ記録を確認して製品責任者に結果を渡す |
| Qの権限がない担当者が、通常の画面外からの直接リクエストも含め、同じ割り当てを試みる | 割り当てが拒否され、担当者と引き継ぎ記録は変わらない。応答に保護された会話内容が含まれない | セキュリティ責任者が拒否のテストを定義し、QAが画面とリクエスト経路で実施して状態が変わらないことを確かめる |
| 権限のある2人が同じ未割り当ての会話を見て、ほぼ同時に自分への割り当てを試みる | 競合時の方針は未決。更新を促して後続の割り当てを拒否するのか、別の合意済みルールを使うのかを決める。最後の書き込みを自動的に承認済みの動作としない | 製品責任者と開発責任者がルールと表示内容を決めてから、QAが再現可能な同時実行テストを作る |
同時割り当ては、期待する結果が未決のままでは受け入れ完了にできません。方針、決裁者、レビュー日を判断ログに記録し、PRDとスライドを同時に更新します。操作を非表示にするだけでは権限の強制を確認できないため、権限のない直接リクエストも試します。各条件にテスト結果を付け、条件案の表を実施結果として扱わないでください。
各要件に優先度と既知の依存関係を付け、仕様の記述、ユーザー観察、法務確認、技術的制約を区別して参照します。高リスクの条件は担当チーム、確認時期、方法を明記し、未定なら決裁者と期限を置きます。
別の受け入れ条件の例として、「権限がない人は送信できない」「接続が戻ったときに未送信内容を失わない」のように、確認する状態を具体的に示します。対象フローと制約に照らして採用する条件を選び、確認方法も決めます。
依存関係と選択肢を示す
認証プロバイダー、データ移行、法務確認、デザインシステムの部品、別チームのAPIを、担当者と状態付きで並べます。タイムラインはレビューに必要な連携、テスト、判断の地点に絞り、確度の低い見積もりを納期として扱いません。選択肢は学習までの時間、戻しやすさ、ユーザーリスク、保守負担で比較し、なぜ優先するかの基準を明記します。
依存関係があるだけで作業が止まるとは限りません。状態、担当者、次の行動を記録します。担当者がいない依存関係は、リスクまたは判断事項として扱います。
記録できる承認で終える
範囲を承認、条件付き承認、具体的な修正のための差し戻しのいずれかを依頼します。承認、対象外、次の担当者、見直し日を判断ログに残します。根拠が弱い場合は、学習目標を持つ調査やプロトタイプを提案します。PRDとバージョン日付も一緒に送り、当時の既知、選択、未解決を後から確認できるようにします。
PRDとプレゼンは同じバージョン日付で保存し、要件の変更理由、確認した人と日付を残します。原資料が変わったら、影響する判断と再検討条件を短い差分で示します。 スライドは完全な仕様書や実装の代わりにはなりません。レビューで確認された内容と、まだ提案段階の要件を判断ログで区別します。
