create-prd

PRD 作成のエキスパート

概要

実績のある8セクションのフレームワークを使って、構造化された製品要件定義書を作成します。このスキルでは、何を作るのか、なぜ重要なのか、成功をどのように測定するのかを伝える、明快で専門用語を避けたPRDを作成します。生成されるすべてのPRDは一貫した構成に従い、エンジニアリング、デザイン、ビジネスの関係者の認識を揃えます。

主な機能

• PRD作成前の枠組みづくり — 問題フレーミングキャンバス（ユーザー視点のナラティブ）とワーキング・バックワーズ方式のプレスリリースで、解決策を考える前に問題を明確にします。
• 8セクションのPRDフレームワーク — 概要、連絡先、背景、目標（SMART KR）、市場セグメント（JTBD）、価値提案（バリューカーブ）、解決策（P0/P1/P2）、リリース。
• 平易な言葉を徹底 — 1つの文に1つのアイデア、抽象性より具体性を重視し、10秒で伝わるかを確認します。
• ひな形の自動生成 — prd_scaffolder.py が、入力を促すプレースホルダーを含む骨組みを生成します。

使用するタイミング

• 新製品の取り組み -- 製品をゼロから立ち上げ、開発開始前に包括的な仕様書が必要な場合。
• 機能の拡張 -- 既存製品に、チーム横断の認識合わせが必要となる大規模な機能を追加する場合。
• 関係者間の認識合わせ -- 関係者全員に「何を作り、なぜ作るのか」を伝える単一の文書が必要な場合。

まず確認すること

PRDを作成する前に、次の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

• 中心となる問題 — 誰がどのような問題に困っているのかを、ユーザー自身の言葉で1文にまとめたもの（背景と目標を決めます）
• 対象読者 — 経営層、エンジニアリング担当者、または混成（説明の詳しさと、8つのセクションのうちどれを重視するかを決めます）
• 成功指標 — 「うまくいった」と判断するためのSMART KR（目標を決めます）
• スコープの境界 — 今回のリリースに明確に含めないもの（解決策のP0/P1/P2とリリースを決めます）

停止ルール：出力に最も大きな影響を与える2〜3項目だけを尋ねてください。ユーザーが「とにかく下書きを作って」と言った場合は、作成を進め、PRDの冒頭に前提を列挙してください。

クイックスタート

python scripts/prd_scaffolder.py --product-name "MyProduct" \
  --objective "Short description of the outcome" \
  --segments "Segment A, Segment B"

1. 背景情報を集めます：製品名、対象セグメント、中心となる問題。
2. （任意）Problem Framing CanvasまたはWorking Backwards PRで、まず問題を整理します（references/prd-framework.md を参照）。
3. スキャフォルダーを実行して骨組みを生成し、8つのセクションをそれぞれ埋めます。
4. references/prd-writing-guide.md のチェックリストに沿って確認し、フィードバックを求めて共有します。

プロトタイプを先に作る進め方

AI アプリビルダー、AI デザインツール、AI コーディングアシスタントを使えば、一部の作業では、長い仕様書を書くよりも、クリック可能または動作するプロトタイプを低コストで作成できます。学びを得るためにプロトタイプを活用し、意思決定には PRD を使いましょう。

次の場合は、プロトタイプを先に（または仕様書と並行して）作成します：

• 中核となるリスクが実現可能性やポリシーではなく、ユーザビリティや望ましさ（「ユーザーは理解できるか、使いたいと思うか」）である。
• インタラクションを文章で説明するのが難しい（新しいワークフロー、情報量の多い UI、会話形式のフロー）。
• 20 分のユーザーセッションで決着する意見について、ステークホルダーの間で議論が続いている。

次の場合は、先に仕様書を書きます： リスクが規制、データ、セキュリティ、価格設定、またはチーム間の依存関係に関わる場合、あるいは変更が既存のフローを十分に理解された形で拡張する場合。

プロトタイプをユーザーとテストする場合：

1. セッションの前に仮説と合格基準を決めます（discovery/brainstorm-experiments/ を参照）。
2. 対象セグメントを対象に、タスクベースのセッションを 5～8 回実施します。実演するのではなく、観察してください。
3. 現実的ではあるものの合成されたデータを使います。承認なしに、顧客の PII をサードパーティのプロトタイピングツールに貼り付けてはいけません。
4. ユーザーの発言とは分けて、ユーザーが実際に行ったこと（タスクの成功、エラー、所要時間）を記録します。

PRD に引き続き必ず含める内容： 問題と、それを抱えている人（Background）、成功指標（Objective KRs）、制約（技術、法務、予算、スケジュール）、明示的な対象外事項、リスク／未解決の質問です。プロトタイプとテスト結果へのリンクをセクション 7（Solution）に記載します。プロトタイプはソリューションを例示するものであり、要件の代わりにはなりません。

エンジニアリングへの引き継ぎ： プロトタイプが使い捨てなのか、出発点なのかを明記します。どちらであるかも記載してください。生成されたプロトタイプコードは、デフォルトでは本番用コードではありません。エンジニアリングチームが実際の開発範囲を見積もれるよう、省略されている項目（認証、エラー状態、アクセシビリティ、パフォーマンス、セキュリティレビュー、データモデル）を列挙します。プロトタイプのリンク、テスト済みのフロー、調査結果、P0/P1/P2 の対象範囲をまとめて引き継ぎます。

参考資料

• references/prd-framework.md — 執筆時に参照してください。PRD 作成前に使う 2 つの手法、セクションごとのガイダンスを含む 8 セクションのフレームワーク、執筆の原則、スキャフォルダーのフラグに関するリファレンス、トラブルシューティング、成功基準を説明しています。
• references/prd-writing-guide.md — 草稿を仕上げる際に参照してください。セクションごとの執筆ガイドとレビュー用チェックリストが含まれています。
• references/red-flags.md — PRD を共有する前に参照してください。悪い例／良い例と修正方法を交えて、PRD でよくある問題を説明しています。
• assets/prd_template.md — 記入してすぐ使える、PRD テンプレート一式です。

対象範囲と制限事項

対象範囲： ガイド付きプレースホルダーを含む 8 セクションの PRD 骨子の生成、セクションごとの執筆ガイダンス（平易な表現、具体性）、Jobs-to-be-Done に基づく市場セグメントの定義、Value Curve を使った価値提案のマッピング、「Now／Next／Later」と明示的な延期によるリリース計画。

対象外： 技術アーキテクチャやシステム設計のドキュメント（engineering/）、ユーザーストーリーの作成やバックログの作成（execution/job-stories/、execution/wwas/）、詳細な UX リサーチやユーザビリティテスト計画（product-team/）、財務面のビジネスケースのモデリング（finance/）。

重要な注意事項： PRD はコミュニケーションツールであり、契約ではありません。常に更新されるドキュメントとして扱ってください。8 セクションのフレームワークは実績がありますが、軽量なアジャイルチームではセクション 1、3、4、7、8 だけで十分な場合があり、規制の厳しい環境ではさらに多くのセクションが必要な場合があります。不明確な要件や欠落した要件は、手戻りの原因としてよく知られています。そのため、開発開始前にエンジニアリングチームおよびデザインチームと PRD をレビューしてください。

統合ポイント

統合先	方向	説明
discovery/identify-assumptions/	受け取る	検証済みで「今すぐテスト」する前提事項が、エビデンスとともに PRD のセクション 7 に反映されます
discovery/brainstorm-experiments/	受け取る	実験結果によって、PRD の前提事項が検証または否定されます
discovery/pre-mortem/	受け取る	タイガーによる緩和策が PRD のリスクセクションになります
execution/brainstorm-okrs/	連携先	PRD の主要な成果指標（セクション 4）が四半期の OKR 目標に沿うようにします
execution/outcome-roadmap/	連携先	PRD のリリース計画（セクション 8）をロードマップの Now／Next／Later の各期間に対応付けます
execution/prioritization-frameworks/	受け取る	セクション 7 の機能優先度（P0／P1／P2）は、RICE／ICE のスコアリングを参考にします
senior-pm/	連携先	PRD のステークホルダーに関する情報を、ステークホルダーマッパーのエンゲージメント計画に活用します