bmad-prfaq

BMAD PRFAQ

役割： フェーズ前分析 — Working-Backwards のストレステスト

機能： Amazon の Working-Backwards メソッドに沿ってユーザーを導き、製品ビジョンを明確にし、コンセプトを検証し、PRD、アーキテクチャ、またはコードを1行でも書く前に、難しい質問を明らかにする PRFAQ ドキュメント（prfaq.md）を作成します。

このスキルを使う場面

次のような場合に使用します。

• PRD やスプリント計画に着手する前に、製品コンセプトを検証する
• 顧客価値を明確にするためのプレスリリースを未来の視点で書く
• 構成された社内 FAQ を使って前提をストレステストする
• 発売前に顧客向けの回答を準備する
• 既存の PRFAQ ドキュメントを更新または検証する
• BMAD の計画トラックを選ぶ（Working-Backwards を採用するチームでは、PRFAQ が製品ブリーフに先行する、または製品ブリーフの代わりになることがよくあります）

Working-Backwards メソッド

Working-Backwards は、望ましい顧客の成果から出発し、製品に向かって逆算します。PRFAQ は次の2つのパートで構成されます。

パート	目的
プレスリリース	製品がすでに発売されたかのように、顧客価値を明確に伝えます
社内 FAQ	チームが答えるべき、難しいビジネス上および技術上の質問を明らかにします
社外 FAQ	関心を持った顧客や報道関係者から寄せられそうな質問を予測します

このプロセスでは、何か月も開発した後ではなく、今すぐ難しい質問に具体的に答える必要があります。

3つの意図

このスキルは3つのモードに対応しています。文脈から意図を特定してください。

意図	トリガー	出力
作成	既存の PRFAQ がない、新しいコンセプト	prfaq.md を一から作成
更新	既存の PRFAQ があり、要件が変更された	意思決定ログのエントリーを含む、改訂版の prfaq.md
検証	PRFAQ のドラフトがあり、批評が必要	批評レポート、注釈付きチェックリスト

コアワークフロー

1. 状況を把握する（すべての意図）

• 出力フォルダーに既存の prfaq.md、project-context.md、decision-log.md があるか確認します。
• ユーザーに意図（作成／更新／検証）を確認します。
• 作成の場合：ステップ2に進みます。
• 更新の場合：既存のドキュメントを読み、変更されたセクションを特定して、ステップ4に進みます。
• 検証の場合：既存のドキュメントを読み、検証チェックリスト（下記参照）を実行して批評を作成します。ここで終了し、ユーザーから依頼されない限り書き直しません。

2. 情報を集める（作成／更新）

テンプレートを埋めるために必要な最小限の質問をします。質問の各まとまりの後にいったん止め、次に進む前に確認します。質問のまとまりの例：

まとまり A — 顧客と課題

• 対象顧客は誰ですか（役割、セグメント、状況）？
• 具体的な課題、または満たされていないニーズは何ですか？
• この製品がない状態で、現在どのように対処していますか？

まとまり B — 製品と価値

• この製品は一文で言うと何をしますか？
• 顧客にとって最も重要なメリットは何ですか？
• 顧客はどのような測定可能な成果を得られますか？

まとまり C — 差別化と提供時期

• 既存のソリューションとどう違いますか？
• 顧客はいつ、どのように利用できるようになりますか？
• 発売時の行動喚起は何ですか？

まとまり D — 難しい質問（社内向け）

• 主なリスクや未知の要素は何ですか（上位3つ）？
• これを実現するために、技術面で何が成り立っている必要がありますか？
• 6か月後、12か月後にどのような状態になっていれば成功ですか？

まとまり E — 顧客からの質問（社外向け）

• 顧客はまず何を尋ねますか？
• 顧客がためらう理由は何でしょうか？
• どのような証拠や裏付けが必要ですか？

3. プレスリリースの草案を作成する

${CLAUDE_PLUGIN_ROOT}/skills/bmad-prfaq/templates/prfaq.template.md のテンプレートを使用します。

次の順序で記入します。

1. 見出し — 製品名と、顧客にとっての主なメリットを1行で示します
2. サブ見出し — 対象ユーザーと主な成果を示します
3. 冒頭の段落 — 問題の背景を説明します（2～3文）
4. 問題の段落 — 解決策には触れず、問題による苦痛を描写します
5. 解決策の段落 — 製品とその中核機能を紹介します
6. メリットの段落 — それぞれ1つの主なメリットを取り上げ、2～3段落にまとめます
7. 顧客のコメント — 名前付きのペルソナによる、現実味のあるコメント
8. 行動喚起 — 入手方法、時期、次にすべきことを示します
9. 会社のコメント — 戦略的な意図を示す社内リーダーのコメント

プレスリリースは600語未満に収めてください。短くまとめられない場合は、 コンセプトが十分明確ではありません。質問を追加してください。

4. 社内向けFAQの草案を作成する

経営陣、投資家、懐疑的なエンジニアが尋ねるであろう質問を10～15件用意します。必須の質問カテゴリは次のとおりです。

• 市場：なぜ今なのか。市場機会の規模はどれくらいか。
• 顧客：これが実際の問題だと、どうすれば分かるのか。
• ビジネスモデル：どのように収益を上げるのか、またはコストを削減するのか。
• 技術：最も難しいエンジニアリング上の課題は何か。
• リスク：失敗につながる主な要因を3つ挙げると何か。
• 指標：30日、90日、180日時点での成功とはどのような状態か。
• 検討した代替案：ほかに何を検討し、なぜ採用しなかったのか。
• 依存関係：リリース前に何が必要か。

回答は具体的でなければなりません。「これから考えます」は認められません。

5. 外部向けFAQの草案を作成する

ローンチ時に顧客、ジャーナリスト、アナリストが尋ねるであろう質問を5～10件用意します。 価格と利用方法、プライバシーとセキュリティ、互換性、サポート、ロードマップを取り上げます。

6. まとめて作成する

3つのセクションをまとめ、出力フォルダー内に prfaq.md を作成します。

ファイルパス：{outputFolder}/prfaq.md

7. 決定事項を記録する（新規作成／更新）

{outputFolder}/decision-log.md に簡潔な記録を追記します。

• 日付
• 意図（作成／更新）
• PRFAQ に記録した主な決定事項
• PRD フェーズに持ち越す未解決の質問

8. 次のステップを提案する

適切な BMAD トラックと次のスキルを提案します。

• PRFAQ の内容が薄い場合（想定されるストーリーが少ない場合）：Quick Flow → product-manager に引き継いで技術仕様を作成します。
• PRFAQ の内容が充実している場合（複数のエピックからなる製品の場合）：BMAD Method → product-manager に引き継いで PRD を作成し、その後 system-architect に引き継ぎます。
• PRFAQ から戦略上の不確実性が明らかになった場合：先に進む前に、creative-intelligence による調査をもう一度行うことを提案します。

検証チェックリスト

意図が Validate の場合（または最終化前のセルフチェックとして）：

• 見出しで、機能ではなく具体的な顧客メリットを示している
• プレスリリースが600語未満である
• 顧客のコメントが宣伝文句ではなく、実在の人物のように聞こえる
• 社内向けFAQに、具体的な回答を伴う質問が少なくとも10件ある
• 社内向けFAQに、「どうすれば失敗するのか」という質問が少なくとも1件含まれている
• 社内向けFAQに、30日、90日、180日時点の成功指標が含まれている
• 外部向けFAQが、期待だけでなく懸念も想定している
• 未解決の質問がすべて、明示的に未解決として記載されている（曖昧にごまかしていない）
• プレスリリースのセクションに実装の詳細が含まれていない
• ドキュメントにベロシティ、ストーリーポイント、バーンダウンチャートが含まれていない

出力品質基準

完成した PRFAQ は次の条件を満たす必要があります。

• 技術に詳しくない経営幹部にも、懐疑的なエンジニアにも読みやすい
• 実質的な未解決の質問を少なくとも3つ提示している（修辞的な質問ではない）
• 内部用語ではなく、顧客の具体的な言葉に基づいている
• 特定の技術的アプローチを約束していない（それはアーキテクチャの役割です）
• 全体で1,000～2,500語である（プレスリリースと両方のFAQを含む）

サブエージェント戦略

パターン： 順次情報収集、並行ドラフト作成

複数の顧客セグメントが存在する大規模または複雑な製品では、FAQ のドラフト作成をセグメントごとに分担します。

エージェント	タスク	出力
Agent 1	内部 FAQ（ビジネス／市場／リスクに関する質問）のドラフトを作成	{outputFolder}/prfaq-internal-faq-draft.md
Agent 2	外部 FAQ（顧客／報道機関からの質問）のドラフトを作成	{outputFolder}/prfaq-external-faq-draft.md

連携：

1. クラスター A～E を対話形式で順番に完了します。
2. 収集したコンテキストを {outputFolder}/prfaq-inputs.md に書き込みます。
3. メインコンテキストでプレスリリースを作成します（短く、判断を要する内容）。
4. 共通の入力情報を渡して、Agent 1 と Agent 2 を並行して起動します。
5. メインコンテキストで両方の FAQ ドラフトをレビューして統合し、prfaq.md を作成します。

サブエージェントへのプロンプト例（内部 FAQ エージェント）：

Task: Draft the Internal FAQ section of a PRFAQ document.
Context: Read {outputFolder}/prfaq-inputs.md for the product concept, customer
         segments, risks, and success metrics gathered from the user.
Objective: Produce 10-15 internal FAQ questions and specific answers covering
           market opportunity, customer validation, business model, technical
           risk, success metrics, alternatives considered, and dependencies.
Output: Write draft to {outputFolder}/prfaq-internal-faq-draft.md.
Constraints:
- Answers must be specific, not aspirational placeholders.
- Include at least one "what are the top ways this fails?" question.
- Include success metrics at 30, 90, and 180 days.
- Do not include implementation code or technical architecture decisions.

連携

入力元：

• business-analyst（製品概要、ディスカバリーノート）
• creative-intelligence（調査、ブレインストーミングの成果物）
• ユーザー（コンセプトの直接的な説明）

出力先：

• product-manager（PRFAQ を PRD 作成に活用）
• system-architect（内部 FAQ で挙がった未解決の技術的な質問）
• decision-log.md（今後のスキルで参照できるように決定事項を記録）

LLM 向けのヒント

• TodoWrite を使って、クラスターごとの情報収集プロセスを追跡します。
• 質問は一度に 1 つのクラスターについて行い、すべての質問を一度に提示しないでください。
• ユーザーの説明が曖昧な場合は、ドラフト作成の前に WebSearch を使って実際の市場データを確認します（内部 FAQ に出典を記載します）。
• プレスリリースは、製品がすでに発売されたかのように書きます。将来の約束ではなく、過去形で実績を述べてください。
• 顧客の引用は人間らしいものにします。「実際の人がこれを言うだろうか？」という基準を満たすまで推敲してください。
• このスキルからアーキテクチャの設計やストーリー作成に進まないでください。引き継いでください。

---

BMAD Code Organization による BMAD Method 向けの Claude Code ハーネスである BMAD Planning & Orchestrator プラグインの一部です（https://github.com/bmad-code-org/BMAD-METHOD）。`bmad-prfaq` の理念を実装しています。方法論に関するすべての功績は BMAD Code Organization に帰属します。