prd-writing

ドキュメントの構成

すべての PRD を、以下の主要セクションを中心に構成します。取り組みの複雑さに応じて、各セクションの詳しさを調整してください。

問題の整理

明確に言語化した問題を、ドキュメント全体の基盤とします。

• 具体的で観察可能な形で、ユーザーが抱える個別の課題を特定します
• この問題に悩まされているユーザーの数と、その発生頻度を定量化します
• 対応しない場合の影響を明確にします。売上の損失、ユーザー離れ、運用負荷、競争上の不利などが考えられます
• サポートチケット、ユーザーインタビュー、行動データ、市場の動向などから得られた根拠に基づいて主張します

目指す成果

問題を、測定可能な 3～5 件の目標に置き換えます。

• 行動の変化、効率の向上、エラーの削減など、観察可能な変化を基準に各成果を設定します
• ユーザー向けの成果（顧客にとって何が改善するか）と、組織向けの成果（ビジネスが何を得るか）を区別します
• 成果物ではなく結果として表現します。「オンボーディングの期間を半分にする」は適切ですが、「オンボーディングのフローを再設計する」は成果物の表現です
• すべての成果について、「達成を裏付ける証拠は何か」に答えられるようにします

範囲と対象外

意図的に対象外とする項目を 3～5 件記載し、スコープの際限ない拡大を防ぎます。

• 今回のイテレーションでは対応しない、関連する機能を挙げます
• データ不足、効果が小さい、後続フェーズに適している、別のワークストリームに属するなど、各項目を除外する理由を簡潔に示します
• 明示的な対象外の項目は、実装時にチームを守り、ステークホルダーに誠実な期待値を設定するのに役立ちます

ユーザーナラティブ

「[特定のペルソナ]として、[根本的な動機]のために[機能]が必要です」というパターンで、ユーザーのニーズをまとめます。

効果的なナラティブを作成するためのガイダンス：

• ペルソナは、設計上のトレードオフを判断できるほど具体的にします（「ユーザー」ではなく「請求管理者」など）
• インターフェースの仕組みではなく、望ましい結果を記述します
• 動機の部分では、ユーザーが得る価値を説明します
• エラーが発生する状況、空の状態、境界条件も考慮します
• この機能が関係するすべての異なるペルソナを取り上げます
• 優先度の高い順にナラティブを並べます

ナラティブの例：

• 「請求管理者として、財務チームが四半期ごとの照合レポートを必要としているため、期間を指定して請求書の履歴をエクスポートしたいです」
• 「新しいチームメンバーとして、プロジェクトの途中から参加すると自分の貢献が遅れるため、最近のプロジェクト活動の概要を確認したいです」

優れたユーザーナラティブの特徴

INVEST チェックリストを適用します。

• 独立性（Independent）：他のナラティブと結び付けずに実現できます
• 交渉可能性（Negotiable）：実装の詳細に柔軟性があります
• 価値（Valuable）：エンドユーザーに具体的なメリットをもたらします
• 見積もり可能性（Estimable）：エンジニアリングチームが、おおよその工数を見積もれます
• 小ささ（Small）：1 回のイテレーションで完了できます
• 検証可能性（Testable）：検証基準が曖昧ではありません

ユーザーナラティブで避けるべき落とし穴

• 曖昧さ：「ユーザーとして、パフォーマンスを向上させたいです」ではなく、どの操作を、どのしきい値まで改善するのかを指定します
• 実装方法の指定：「ユーザーとして、モーダルダイアログがほしいです」ではなく、ウィジェットではなくニーズを説明します
• 動機の欠如：「ユーザーとして、保存をクリックしたいです」ではなく、その操作の目的を説明します
• 過大なスコープ：「ユーザーとして、チーム管理全般を行いたいです」ではなく、個別の機能に分解します
• 内部向けの視点：「バックエンドチームとして、データベースを移行したいです」は技術的なタスクであり、ユーザーナラティブではありません

要件の優先度

階層分類

クリティカル（P0）：これらがなければ、取り組みは不完全です。提示された問題を解決するための最低限の基準となります。判断基準：「これを取り除いた場合、根本的な問題は未解決のままですか？」答えが「はい」なら、P0のままにします。

重要（P1）：体験を大幅に向上させますが、基本的なユースケースはこれらがなくても機能します。初回リリース後、迅速に対応する有力候補です。

延期（P2）：初回バージョンでは意図的に対象外としますが、アーキテクチャでは対応できるようにしておくべきです。これらを記録しておくことで、将来の障害となる設計上の選択を防げます。

優先順位付けの原則

• P0は厳格に守ります。クリティカルな項目を絞ることで、学習と提供を加速できます。
• すべての項目がクリティカルと分類されているなら、本当にクリティカルな項目はありません。各P0について、「これがなければ、実際にリリースを延期しますか？」と問い直してください。
• P1には、推測に基づく要望ではなく、ほぼ確実に後続対応する項目を指定します。
• P2はアーキテクチャ上のガードレールとなり、実装の労力を消費せずに設計の方向性を定めます。

MoSCoWの視点

ステークホルダーとの交渉に自然に適用できる、別の分類方法です。

• 必須：これらがなければ、リリースに価値はありません。交渉の余地はありません。
• 望ましい：ユーザーから期待され、重要ですが、なくてもリリースは成立します。
• 可能であれば対応：余力があれば歓迎される追加項目です。除外してもスケジュールは遅れません。
• 今回は対応しない：明示的に延期します。記録することで曖昧さをなくせます。

成功の測定

初期の指標（リリース後数日～数週間）

すぐに変化し、初期の反応を明らかにする指標です。

• 利用率：新機能を利用する対象ユーザーの割合
• 有効化率：主要な想定アクションを完了したユーザーの割合
• 完了率：最初から最後までの目標を達成したユーザーの割合
• 所要時間：主要なワークフローにかかる時間
• 失敗率：エラー、行き止まり、または中断された試行の頻度
• 再訪頻度：ユーザーがその機能を再び利用する頻度

継続的な指標（リリース後数週間～数か月）

時間の経過とともに成熟し、持続的な影響を示す指標です。

• 継続率の向上：機能に起因する、測定可能なユーザー継続率の改善
• 収益への貢献：アップグレード、利用拡大、または新規契約の促進
• 満足度の変化：NPS、CSAT、または定性的な評価の変化
• サポート負荷の軽減：関連するサポートへの問い合わせの減少
• 受注率への影響：競合案件の成果の改善

目標の設定

• 目標は正確に設定します。「高い利用率」ではなく、「最初の14日間で利用率60％」とします。
• 類似するリリース、業界標準、または明示された仮説をもとに目標を導き出します。
• 基本的な期待値と、さらに高い目標の両方を定義します。
• 測定手段を指定します。どのツール、どのクエリ、どの期間を使うかを明確にします。
• 評価のチェックポイントを設定します。リリースから1週間後、1か月後、1四半期後などです。

検証基準

構造化された条件またはチェックリストを使って、受け入れ基準を表現します。

構造化された条件：

• Given [開始状態または前提条件]
• When [ユーザーの操作]
• Then [期待されるシステムの動作]

例：

• Given 組織がシングルサインオンを有効にしている
• When 従業員がログイン画面に移動する
• Then システムは組織のアイデンティティプロバイダーにリダイレクトする

チェックリスト方式：

• 管理者はワークスペースの設定でアイデンティティプロバイダーのURLを設定できる
• チームメンバーには、ログイン画面にブランドに合わせたサインオンオプションが表示される
• 初回のSSO認証時に、新しいアカウントが自動的に作成される
• メールアドレスが一致する場合、SSO認証によって既存のアカウントにリンクされる
• 認証に失敗した場合、説明的なエラーメッセージが表示される

効果的な検証基準の作成

• 主要な経路、エラー条件、境界シナリオを網羅します
• 内部実装ではなく、観察可能な動作を記述します
• 否定的なケースを含めます。明確に発生してはならないことを示します
• 各基準を個別に検証できるようにします
• 「応答性が高い」「直感的」「シームレス」などの主観的な表現を、具体的な閾値に置き換えます

スコープの管理

スコープ拡大の兆候

次の警告サインに注意してください。

• 仕様の確定後に要件が持ち上がる
• 段階的な追加によって、作業量が大幅に増える
• ユーザーが求めていない機能をチームが構築する（「せっかくなので、ここに追加しよう……」）
• 意図的にスコープを見直す話し合いを行わないまま、目標日が変更される
• ステークホルダーが、対応する要件の削除なしに要件を追加する

封じ込め策

• すべての仕様に明確な対象外項目を設けます
• トレードオフのルールを徹底します。スコープを新たに追加する場合は、対応する項目の削除またはスケジュールの調整が必要です
• 現在のイテレーションと後続フェーズの境界を明確に保ちます
• すべての要件が、明示された課題に結び付いていることを定期的に確認します
• 探索的な作業に時間制限を設けます。「2日以内に X を解決できなければ、先送りにします」
• 現在のスコープ外にある有益な提案を記録する「将来のアイデア」バックログを維持します

未解決の質問

すべての PRD で未解決の項目を管理してください。

• 実装前または実装中に解決が必要な質問を記録します
• 各質問の担当者を割り当てます。エンジニアリング、デザイン、法務、データサイエンス、または特定のステークホルダーから選びます
• 質問をブロッキング（作業開始前に解決が必須）またはノンブロッキング（実装と並行して解決可能）に分類します

タイミングと順序

• 厳守すべき期限を文書化します。契約上の義務、外部イベント、規制上の節目などです
• チーム間の依存関係と、それぞれの想定納期を特定します
• 取り組みが単一のリリースサイクルを超える場合は、段階的な実施を推奨します