product-discovery

プロダクトディスカバリー — ステークホルダーマップ

判断対象に応じて、入口を選んでください。既存のドラフトがある場合は、以下の成果物優先の入口を維持してください。外部需要や課題の不確実性については、アイデアを要件に変える前に 顧客／課題のディスカバリーを読み込みます。社内要件については、ステークホルダーのマッピングから始めてください。

リファレンス	読み込むタイミング	ファイル
ステークホルダーのマッピングと順序付け	誰に、どの順番でインタビューするかを決める必要がある場合	references/stakeholder-mapping.md
インタビュープロトコルの設計	特定のステークホルダータイプ向けに質問の組み立てを設計する場合	references/question-patterns.md
ギャップ検出の手法	ステークホルダーが口にしないことを見つける準備をする場合	references/gap-detection.md

パイプライン：フェーズ 0 — ディスカバリー

RAW NEED → [MAP] → [INTERVIEW] → [SYNTHESIZE] → [DISTILL] → [VALIDATE] → SPEC.md
              |           |              |            |            |
         Who to       What to        Resolve      Convert to   Stakeholder
         talk to      ask            conflicts    structured   review

これから着手するフェーズのリファレンスを読み込んでください。

基本原則

• クローズドクエスチョンは、すでに考えていることを確認します。オープンクエスチョンは、尋ねることさえ知らなかった情報を発見します。 答えが「はい」か「いいえ」になるなら、それは発見ではなく検証です。
• まず知識を持つ人に聞き、権限を持つ人には検証してもらいます。権限を持つ人が起点になるわけではありません。 課題を知る人と、予算を承認する人は同じとは限りません。
• 対立の原因が、表面に見えている事柄そのものということは、ほとんどありません。 表面上の意見の相違は、明示されていない前提、リスク許容度、インセンティブの違いを示す代理指標です。
• 曖昧な言葉はすべてギャップを示します。 「おそらく」「理想的には」「いずれ」などは、それぞれステークホルダーが対処すると決めていない既知の課題です。

クイックスタート — 入口の選び方

手元にあるもの	ここから始める
作成者に詳しく確認したい PRD、ブリーフ、仕様書	references/artifact-first-interview.md を読み込みます — 重要な質問を一度に一つだけ尋ね、影響を受ける箇所だけを修正します
未検証の外部顧客の課題または需要	references/customer-problem-discovery.md と templates/customer-evidence-ledger.md を読み込みます — 要件を検討する前に課題を評価します
漠然としたアイデアや課題領域	references/stakeholder-mapping.md を読み込みます — インタビュー対象者を特定します
プロトコルなしで予定されているインタビュー	references/question-patterns.md と references/gap-detection.md を読み込みます — 質問を組み立てます
1 回以上のセッションから得られた未整理のインタビューメモ	references/transcript-to-spec.md を読み込みます — 構造化された仕様書の構成要素に整理します
ステークホルダーによる検証が必要な仕様書のドラフト	references/transcript-to-spec.md（Interpretation Audit Trail セクション）を読み込みます — 検証ループを実施します
要件について意見が一致しないステークホルダー	references/conflict-resolution.md を読み込みます — 仕様書を作成する前に分類して解決します
ステークホルダーと話せる時間が限られている	references/time-constrained-discovery.md を読み込みます — 最小限の時間で最大限の有益な情報を得ます
インタビューを実施する AI エージェント	references/ai-conducted-discovery.md を読み込みます — 迎合性と信頼関係の力学を考慮します

ディスカバリーが終わったら？ product-methodology を使ってスコープを選び、次に product-design-and-ux を使ってユーザー向けの動作を定義してください。下部の ディスカバリーは完了していますか？ チェックリストに進んでください。

成果物優先のレビュー

ユーザーが確認したいドラフトを提示した場合は、成果物優先のインタビューを読み込んでください。質問する前に成果物を読み、判断に関わる質問を一つ選んで回答を待ってから、次の質問を調整します。前提や未解決の対立にはギャップ登録簿を、決定事項や修正の由来には解釈ログを再利用してください。ユーザーが終了したとき、合意した質問数の上限に達したとき、または重要で未解決の判断事項がなくなったときに終了します。対象を絞った修正案と、明示的に未検証のギャップを提示してください。この範囲を限定したレビューでは、以下の完全なディスカバリーチェックリストを満たしません。

顧客と課題の発見

社内からの要望と、社外の顧客から得たエビデンスは分けて扱います。表明された好み、過去の行動に関する報告、観察された行動、コストを伴うコミットメントは、それぞれ異なるエビデンスの分類として記録します。熱意は検証にはなりません。解決策を定義する前に、課題の深刻度、発生頻度、回避策、セグメント間の違い、矛盾を評価します。実際に課題があるからといって、解決策の価値、使いやすさ、実現可能性、事業としての成立性が証明されるわけではありません。実験の設計は product-experimentation、測定は product-analytics-and-measurement、プロダクトに関する選択は product-strategy、経済性は financial-modeling（AI ワークフローの経済性は ai-operating-economics）に引き継ぎます。次の範囲を限定した投資を正当化するエビデンスがない場合は、中止、延期、または範囲の縮小を行います。パイプラインを進めるために要件を作り出してはいけません。

ワークフローとエビデンスの限界については references/customer-problem-discovery.md を読み込みます。顧客の主張や、継続／範囲縮小／延期／中止の推奨を記録する際は templates/customer-evidence-ledger.md を使用します。このプロセスの成果は、エビデンスに基づく投資の推奨と残されたギャップであり、自動的に SPEC.md を作成することではありません。既存のドラフトのレビューは引き続き一度に一つの質問を扱い、社外での検証を証明するものではありません。

使用しない場合

個人の習慣や生活上の優先事項については daily-life-discovery、一般的な調査計画については research-methodology、確定済みの要件に基づく実行順序の計画については implementation-planning に引き継ぎます。プロダクトに関する一般的なステークホルダー調査では、このスキルに既存の MAP／INTERVIEW ワークフローを使用します。無理にドラフトレビューに当てはめないでください。

トリガー条件

次の場合にこのスキルを読み込みます：

• 社外の顧客が抱える課題への投資が妥当かどうかを判断する必要がある
• PRD を厳しく吟味したい、提案の欠点を指摘したい、またはドラフトについてインタビューを受けたい
• 新機能やプロジェクトのプロダクトディスカバリーを始める
• 構造化された仕様にまとめる必要がある漠然としたアイデアがある
• ステークホルダーにインタビューする必要があるが、プロトコルがない
• 生のインタビューメモを SPEC.md にまとめる必要がある
• SDD のフェーズ 1（SPECIFY）に進むにあたり、上流からのインプットが必要である
• ディスカバリー作業が十分に行われたかどうかを評価する

読み込みガイド

フェーズ	読み込むタイミング	ファイル
MAP	誰に、どの順番でインタビューするか、適切なステークホルダーをどう見つけるかを特定する必要がある	references/stakeholder-mapping.md
INTERVIEW	ステークホルダーへのインタビューを実施するにあたり、質問パターン、ギャップの検出、意見の相違への対処が必要である	references/question-patterns.md + references/gap-detection.md + references/conflict-resolution.md
SYNTHESIZE	生のインタビューメモがあり、要約する前に意見の相違、リスク、ギャップを特定する必要がある	references/conflict-resolution.md
DISTILL	インタビューメモを、AC、エッジケース、NFR を含む構造化された SPEC.md に変換する必要がある	references/transcript-to-spec.md
VALIDATE	ドラフト仕様があり、ステークホルダーと解釈を確認する必要がある	references/transcript-to-spec.md（Interpretation Audit Trail セクション）

横断的な考慮事項

以下の観点はすべてのフェーズに適用されます。該当する場合に読み込みます：

考慮事項	読み込むタイミング	ファイル
AI によるディスカバリー	AI エージェントがディスカバリーインタビューを実施する	references/ai-conducted-discovery.md
力関係	複数の組織階層にまたがるステークホルダーがいて、階層が回答をゆがめる可能性がある	references/power-dynamics.md
時間的制約	ステークホルダーが使える時間に限りがあり、最大限の情報を引き出す必要がある	references/time-constrained-discovery.md

テンプレート

テンプレート	パイプラインフェーズ	読み込むタイミング	ファイル
ディスカバリープラン	MAP	ステークホルダーマップ、インタビュー日程、タイムラインなど、ディスカバリー全体の取り組みを構成する必要がある場合	templates/discovery-plan.md
インタビューガイド	INTERVIEW	インタビューセッション用の体系的な質問項目が必要な場合	templates/interview-guide.md
抽出ワークシート	DISTILL	生のメモを構造化された仕様コンポーネントに変換する場合	templates/distillation-worksheet.md
ギャップ登録簿	SYNTHESIZE	インタビューを通じて未解決のギャップ、保留中の決定事項、未解決の質問を追跡する必要がある場合	templates/gap-register.md
解釈ログ	DISTILL → VALIDATE	ステークホルダーの言葉から仕様の言葉への変換をすべて追跡する必要がある場合	templates/interpretation-log.md

クイックリファレンス：ディスカバリーは完了していますか？

SDD フェーズ 1（SPECIFY）に引き継ぐ前に、すべてのステークホルダーを対象としたディスカバリーを完了するには、このチェックリストを使用してください。アーティファクトを先に確認して中断した場合は、完了を宣言するのではなく、残りのギャップを報告してください。

• すべてのステークホルダーの種類（知識を持つ人、決定権を持つ人、影響を受ける人、実装に詳しい人）にインタビューしましたか？
• すべての要件について、独立した情報源を少なくとも 3 つ確認しましたか？
• 抽象的な名詞を測定可能な閾値に分解しましたか？
• 対立を解決するか、意思決定者を特定して記録しましたか？
• ステークホルダーの逸話からエッジケースを抽出しましたか？
• すべての AC を SAID／IMPLIED／INTERPRETED／INFERRED に分類しましたか？
• リスクの高い解釈を特定し、検証対象として明示しましたか？
• ギャップ、保留中の決定事項、避けられた話題を記録しましたか？
• ステークホルダーによる検証ループを完了しましたか？
• 引き継ぎ用に解釈の監査証跡を保持しましたか？