prd-writing

PRD の作成

使用するタイミング

創業者や PM が、製品アイデア、機能リクエスト、または戦略的な取り組みを、構成の整った製品要件定義書にまとめる必要がある場合に有効化します。ユーザーが「PRD を書いて」「この機能の仕様をまとめて」「X の要件を定義して」「開発する内容を文書化したい」などと述べた場合が該当します。

必要なコンテキスト

• startup-context から： 会社の段階、ターゲット顧客セグメント、現在の製品の状態、チームの規模、技術的な制約。
• ユーザーから： 仕様をまとめる機能または取り組み、解決する既知のユーザー課題、これまでの調査や顧客からのフィードバック、希望するスケジュール、スコープの希望（簡易版か完全版か）。

ワークフロー

1. スコープのレベルを確認する -- 簡易版 PRD（初期段階の検討向け、2～3 ページ）と完全版 PRD（実施が決定した取り組み向け、5～8 ページ）のどちらが必要かを尋ねます。プロダクト・マーケット・フィット前の企業では、デフォルトで簡易版を選びます。
2. 入力情報を集める -- 課題の説明、ターゲットユーザー、既存の調査、成功基準、既知の制約を集めます。主要な関係者とその役割を特定します。
3. 8 セクションの PRD を作成する -- 以下のテンプレートを使い、各セクションを順番に作成します。エンジニアリング、デザイン、リーダーシップを含む幅広い読者に適した、わかりやすい言葉を使います。
4. 前提を明示する -- 各セクションの根拠となる主要な前提を明記します。それぞれについて、裏付けとなる証拠と、前提を覆す要因を示します。
5. レビューして改善する -- ドラフトを提示し、フィードバックを募り、特定のセクションを反復して改善します。PRD のバージョンと最終更新日を記載します。

出力形式

8 セクションで構成された PRD 文書：

セクションのテンプレート

1. 概要 -- 開発するものと、それが重要である理由を 2～3 文で説明します。幅広い読者に向けて書きます。
2. 関係者 -- 主要なステークホルダーとその役割、および関与に関する関連情報。
3. 背景 -- 課題領域に関する背景情報：なぜ今なのか、何が変わったのか、この取り組みを可能にするものは何か。同じ課題に他社がどう対処しているかという競合状況も含めます。
4. 目標 -- 目標、ビジネス上および顧客にとってのメリット、戦略との整合性。OKR に結び付けた SMART な成功指標を定義します。次の形式を使います：「[ユーザーセグメント] が [行動] できるようにし、その結果 [測定可能な成果] を実現する。」
5. 市場セグメント -- デモグラフィックではなく、課題やニーズに基づいてターゲットユーザーを定義します。規模の推定値とともに、主要セグメントと副次セグメントを説明します。
6. 価値提案 -- 対応する顧客のジョブ、提供するゲイン、解消するペインポイントを整理します。バリューカーブ分析などのフレームワークを使って、競合との差別化を示します。
7. ソリューション -- 必要に応じて、機能の説明、UX／プロトタイプ、ワイヤーフレーム、ユーザーフロー、技術的な詳細を記載します。スコープ外の項目を明示します。前提を文書化します。少なくとも 5 つのエッジケースを列挙します。
8. リリース -- 相対的な期間（正確な日付ではなく）を使った段階的な展開計画を示します。MVP と将来のイテレーション、フィーチャーフラグ、ロールバックの基準、レビューのチェックポイントを定義します。

簡易版 PRD では、セクション 2、3、8 をそれぞれ 2～3 文に短縮できます。

フレームワークとベストプラクティス

• 解決策より先に課題を示す。 セクション7（「何を」）に取りかかる前に、ドキュメントの40％をセクション1〜5（「なぜ」）に充てます。解決策にすぐ飛びつく PRD は、仕様書であって PRD ではありません。
• 目標は1つに絞ります。 複数の目標がある PRD は、複数の PRD に相当します。分割してください。各 PRD で動かす主要指標は1つにします。
• ニーズに基づいて市場セグメントを定義します。 人口統計や企業属性だけでなく、対象ユーザーが抱える課題や、製品に任せる仕事に基づいて、誰のためのものかを説明します。
• 価値提案を明確にします。 各セグメントについて、解決する顧客の仕事、もたらす利得、取り除く苦痛を明記します。バリューカーブを使って、競合との差別化ポイントを示します。
• データに基づいて具体化します。 曖昧な表現を具体的な数値に置き換えます。「リテンションを改善する」は指標ではありません。「リリースから8週間以内に、D7リテンションを25％から35％に引き上げる」が指標です。
• スコープの拡大を防ぎます。 対象外の項目を明記します。関係者から追加の提案があった場合は、対象外リストを見直します。
• 日付より相対的な期間を使います。 正確なカレンダーの日付ではなく、フェーズと相対的な期間を使います。これにより、見せかけの精度を避け、柔軟性を確保できます。
• 前提を記録します。 PRD の根拠となる重要な前提を3つ挙げます。それぞれについて、裏付けとなる証拠と、前提が覆される条件を示します。
• 読者を意識します。 エンジニアには技術的な制約とエッジケースが必要です。デザイナーにはユーザーフローとペルソナが必要です。経営陣には概要と指標が必要です。1つのドキュメントですべての読者に向けて書きます。
• 常に更新されるドキュメントにします。 PRD のバージョンと最終更新日を明記します。まったく変更されない PRD は、読まれていなかったということです。
• 軽量 PRD を使う場合： PMF 前の探索、ハッカソンプロジェクト、社内ツール、期間が2週間未満の実験。
• 完全版 PRD を使う場合： チーム横断の取り組み、外部依存関係のある機能、決済またはコンプライアンスに関わるもの。

関連スキル

• roadmap-planning -- PRD 作成後に続けて使い、依存関係とタイムラインを踏まえて、取り組みをより広範なロードマップに組み込みます。
• mvp-scoping -- PRD 作成前に続けて使い、v1 に含めるものと後続リリースに回すものを判断します。
• user-research-synthesis -- PRD 作成前に続けて使い、実際の顧客データに基づいて「背景」と「市場セグメント」のセクションを作成します。

例

例1：軽量 PRD のプロンプト

ユーザー： 「プロジェクト管理ツールに Slack 通知を追加するための PRD が必要です。」

良い出力の抜粋：

概要： 設定可能な Slack 通知を追加し、ProjectFlow を利用するチームが、主要なコミュニケーションツールを離れることなく、タスクの更新、メンション、期限の変更を把握できるようにします。これは、第3四半期の顧客アンケートで最も多く寄せられた機能リクエストです（回答者の38％）。

目標： 有料プランを利用するチームリードが Slack でプロジェクトの更新をリアルタイムに受け取れるようにし、リリースから6週間以内に、タスク割り当てへの平均応答時間を20％短縮します。

市場セグメント： 複数のツールをまたいで連携する10人以上のチームで、プロジェクト管理プラットフォームとコミュニケーションプラットフォームを切り替える負担を主な課題とするチーム。

対象外： Microsoft Teams 連携、カスタム通知テンプレート、Slack ボットコマンド。

例 2：完全版 PRD プロンプト

ユーザー：「新しいセルフサービス型オンボーディングフローの完全版 PRD を作成してください。セットアップを完了する前に、登録ユーザーの 60％が離脱しています。」

出力例：

**背景：**現在のオンボーディングは 7 ステップあり、完了まで平均 12 分かかります。Hotjar の録画によると、「データソースを接続」するステップでユーザーの 45％が離脱しています。競合 X は Q2 にオンボーディングを 3 ステップに短縮し、アクティベーションが 2 倍改善したと報告しています。サポートチームは週に 30 件以上のオンボーディングに関する問い合わせに対応しており、月額約 4,500 ドルのコストがかかっています。

**価値提案：**サンプルデータセットを提供し、ユーザーが連携を行う前に主要な価値を体験できるようにすることで、「データソースを接続」する際の障壁を取り除きます。すぐにデータを接続する必要がある競合 X との差別化を図ります。

リリース：

• フェーズ 1：チーム内でのドッグフーディング（2 週間）
• フェーズ 2：機能フラグを使い、新規登録の 10％に適用
• フェーズ 3：アクティベーション率が 45％を超えた場合、50％に展開
• フェーズ 4：P0 のバグがなく、サポートへの問い合わせ件数が減少した場合、GA
• ロールバックの条件：アクティベーション率が現在の 40％という基準値を下回る