continuous-discovery

継続的なディスカバリーの習慣フレームワーク

プロダクトチームが望ましい成果に向けて進み続けられるよう、持続可能な顧客ディスカバリーの週次プラクティスを構築するためのフレームワークです。ディスカバリーは開発前の一段階ではありません。プロダクトワークの日々のリズムに組み込まれ、すべての意思決定が新しいエビデンスに基づくようにします。

中核となる原則

優れたプロダクトディスカバリーには、一度きりのイベントではなく、継続的なペースが必要です。 毎週顧客と話し、機会を視覚的にマッピングし、構築前に仮説を検証するチームは、直感やステークホルダーの意見、四半期ごとの調査サイクルに頼るチームを一貫して上回ります。目安は、プロダクトトリオ（プロダクトマネージャー、デザイナー、エンジニア）が毎週少なくとも1回、顧客と接点を持つことです。

スコアリング

目標：10/10。 以下の「クイック診断」の7項目でディスカバリープラクティスを評価します。3点から始め、「はい」と答えた項目ごとに1点を加算します（最大10点）。評価基準：9〜10＝週次のペースがあり、オポチュニティ・ソリューション・ツリーが常に更新され、仮説が体系的に検証され、リリースしたすべての機能が顧客の機会に結び付いている状態。5〜6＝ディスカバリーは行われているものの、場当たり的、PMのみ、またはデリバリーから切り離されている状態。≤3＝定期的な顧客との接点がなく、直感やステークホルダーの意見に左右されている状態。現在のスコア、不合格の項目、それぞれに対する具体的な改善策を報告してください。

フレームワーク

1. オポチュニティ・ソリューション・ツリー

中核となるコンセプト： オポチュニティ・ソリューション・ツリー（OST）は、望ましい成果（最上部）から、顧客の機会（中央）、潜在的なソリューションや実験（最下部）へと視覚的につなげ、暗黙のプロダクト思考を明示して共有できるようにします。

効果がある理由： 多くのチームは、顧客ニーズを完全に飛ばして、事業成果からソリューションへ直行します。OSTは、まず機会の領域を理解するよう促し、誰も求めていない機能を防ぎます。

主なポイント：

• 4つのレイヤー：成果 > 機会 > ソリューション > 実験
• 機会とは、顧客の視点から捉えた顧客のニーズ、悩み、要望です
• ツリーは常に更新される成果物であり、チームの学びに応じて毎週更新します
• 大きな機会は、実行可能な単位にするため、より小さな下位機会に分解します
• 複数の機会を同時に追求し、ひとつだけにすべてを賭けないようにします

プロダクトでの活用例：

コンテキスト	活用方法	例
四半期計画	機能を決定する前に機会の領域をマッピングします	「トライアルから有料へのコンバージョン率を高める」→ ユーザーがコンバージョンしない理由を探る
機能の優先順位付け	機会の間でソリューションを比較し、最も効果の高い選択肢を見極めます	「コンテンツを見つけられない」に対する3つのソリューションと、「オンボーディングが分かりにくい」に対する2つのソリューション
ステークホルダーとの認識合わせ	ツリーを戦略共有のビジュアルとして使います	機会Yではなく機会Xを選んだ理由を、リーダーに説明する

倫理上の境界： あらかじめ決めたソリューションを正当化するために、都合のよい機会を選んではいけません。ツリーには、調査を通じて発見したニーズを反映させる必要があります。

ツリーの作成や監査を行う際は、references/opportunity-trees.mdを参照してください。4レイヤーの図、望ましい成果と望ましくない成果の比較表、ソリューション生成の手法、週次更新のリズム、健全なツリーと衰退するツリーの兆候、2つの具体例、4つのアンチパターンが追加されています。

2. エクスペリエンスマッピング

中核となる考え方： 現状のエクスペリエンスマップでは、顧客が現在どのように目標を達成しているかを段階ごとに記録し、ツリー上の機会につながるペインポイントを明らかにします。

効果がある理由： チームは顧客の現在のエクスペリエンスを理解していると思いがちですが、インタビューデータをもとにマッピングすると、組織の内側からは見えないギャップ、回避策、感情が明らかになります。

主なインサイト：

• 将来の理想ではなく現状をマッピングし、まず実態を理解します
• 各ステップでの行動、思考、感情を含めます
• 推測ではなくインタビューデータをもとに、トリオ全員で協力して作成します
• エクスペリエンスマップは顧客のエクスペリエンス全体を対象とし、ジャーニーマップは自社製品のタッチポイントのみを対象とします
• ペインポイントと感情が大きく動く場面は、OST の機会になります

製品への応用：

コンテキスト	応用方法	例
新しい問題領域	設計を始める前にエンドツーエンドでマッピングする	小規模事業者が請求書の作成から入金の催促まで、請求業務にどう対応するか
解約分析	解約したユーザーのエクスペリエンスをマッピングし、問題が起きた箇所を特定する	ユーザーはオンボーディングのステップ 4 で離脱する。必要なデータを手元に用意できないため
部門横断の連携	マップを共同で作成する	3 時間の共同セッションで、全員が共有できる参照資料が 1 つできる

新しい問題領域や解約フローをマッピングする場合は、references/experience-mapping.md を参照してください。現状マップのテンプレート、エクスペリエンスマップとジャーニーマップの違い、共同マッピングの演習が追加されています。

3. インタビューのスナップショット

中核となる考え方： ストーリー形式のインタビューでは、意見や予測ではなく、具体的な過去の体験を聞き出します。各インタビューの内容を 1 ページのスナップショットにまとめることで、チーム全員が内容を把握し、参照できます。

効果がある理由： 顧客は自分自身の将来の行動を予測するのが苦手です。実際に起きた過去の出来事をもとにインサイトを導き出すと、顧客が実際に何をし、どう感じたかが明らかになり、スナップショットを通じて各インタビューが成長し続けるエビデンスのライブラリになります。

主なインサイト：

• 「使ってみたいと思いますか？」ではなく、「前回○○したときのことを教えてください」のように、具体的な過去の行動について尋ねます
• 各スナップショットには、ストーリー、重要な引用、特定された機会、識別子を記録します
• インサイトが伝達の過程で失われないよう、トリオで一緒にインタビューを行います
• 多大な労力をかけずに毎週インタビューを実施できるよう、参加者募集を自動化します
• スナップショットを横断してパターンを見つけると機会が明らかになります。単独のインタビューからわかるのは個々のストーリーだけです

製品への応用：

コンテキスト	応用方法	例
週次の実施	30 分のインタビュー枠を定期的に設ける	アプリ内のプロンプトで参加者を募集し、進行役を交代する
機会の発見	ストーリーからニーズを抽出し、OST に記載する	データをエクスポートする回避策が機会ノードになる
チームの連携	スナップショットを見える場所で共有する	スナップショットが蓄積され、パターンが浮かび上がるボードを設ける

倫理的な境界線： 参加者を特定の結論へ誘導してはいけません。過去の行動について自由回答形式の質問をし、何が重要かはストーリーから明らかになるようにします。

インタビューを実施する場合や参加者募集を設定する場合は、references/interview-snapshots.md を参照してください。ストーリー形式のインタビュー構成、1 ページのスナップショット形式、複数のスナップショットを横断した統合、毎週の参加者募集を自動化する方法が追加されています。

4. 仮説の検証

中核となる考え方: 構築する前に、ソリューションが依存する仮説を特定し、重要度とエビデンスによってマッピングし、最もリスクの高いものから小さく迅速な検証を実行します。

うまく機能する理由: あらゆるソリューションは、望ましさ、実現可能性(事業性)、技術的な実現可能性、使いやすさという仮説の積み重ねの上に成り立っています。ほとんどのチームはそのどれも検証しません — あるいは簡単なものだけを検証し — 誤った前提の上に構築されたソリューションに何か月も投資してしまいます。

重要な洞察:

• 4 つの仮説タイプ: 望ましさ(彼らはそれを望んでいるか?)、事業性(持続できるか?)、技術的な実現可能性(構築できるか?)、使いやすさ(彼らは使えるか?)
• 2x2 でマッピング: 重要度 vs. エビデンス。重要度が高くエビデンスが低い = 最初に検証すべき飛躍的仮説
• エビデンスを生み出す最小の検証を設計する: 1 問アンケート、ペイントドアテスト、プロトタイプ、データマイニング
• 検証を実行する前に成功基準を設定する: 「〜ならば検証済み」
• 1 つの仮説検証は数日で終わるべきで、数週間かけてはいけません

プロダクトへの応用:

状況	応用	例
構築前	上位候補の最もリスクの高い仮説を検証する	「ユーザーはレポートを上司と共有する」→ 共有機能を構築する前にペイントドアボタン
ソリューションの比較	各候補の最もリスクの高い仮説を検証し、弱い選択肢を素早く排除する	A の最もリスクの高い仮説が失敗し、B が成功 → B を追求する
ロードマップのリスク低減	コミット済みの機能に潜む未検証の仮説を見つける	Q3 の機能はユーザーがリアルタイム通知を望んでいると仮定 — まだエビデンスなし

倫理的な境界: 参加者を決して欺いてはいけません — ペイントドアテストでは、開示なしに偽の機能を提供するのではなく、その機能が近日公開予定であると伝えるべきです。

リスクの高い仮説の検証を設計する際は references/assumption-mapping.md を参照してください — 4 つの仮説タイプの詳細、重要度 vs. エビデンスの 2x2、検証設計のメニュー、飛躍的仮説の成功基準の設定方法を追加しています。

5. 機会の優先順位付け

中核となる考え方: 機会を単独ではなく相互に比較し、機会の規模、市場、企業、顧客の要因を用いて、最もレバレッジの高い賭けを見つけます。

うまく機能する理由: チームは最も声の大きいステークホルダー、直近性バイアス、または直感に頼りがちです。構造化された直接比較は、明示的なトレードオフの議論を促し、実装前に意見の相違を表面化させます。

重要な洞察:

• 相対的な比較は独立したスコアリングに勝る
• 何人の顧客が影響を受け、どのくらいの頻度で、どの程度深刻かに基づいて機会をサイズ評価する
• 戦略との整合性、チームの能力、既存のエビデンスを考慮する
• 十分に良い決定を素早く下し、それから素早く学ぶ — 分析麻痺を避ける
• 新しいエビデンスが得られたらランキングを見直す

プロダクトへの応用:

状況	応用	例
四半期計画	上位 5〜7 件の OST 機会をランク付けする	「コンテンツが見つからない」vs.「リアルタイムコラボレーションがない」を構造化された基準で比較
スプリント計画	現在のエビデンスが最も強い機会を選ぶ	インタビューデータが最も多く、テスト可能なソリューションがある場所を選ぶ
ポートフォリオの意思決定	リスクとインパクトに応じて労力を配分する	60% 高信頼度、30% 中信頼度、10% 探索的

上位の機会をランク付けする際は references/prioritization-methods.md を参照してください — 機会のサイズ評価方法、比較対照のテクニック、データの重み付け方法、分析麻痺を避ける方法を追加しています。

6. 習慣を築く

中核となる考え方： 継続的なディスカバリーをトリオにとって持続可能な週次の習慣にするには、採用を自動化し、手軽な儀式を作り、追加の仕事として扱うのではなく、既存のワークフローにディスカバリーを組み込むことが重要です。

効果がある理由： 「時間を見つける」ことに頼るディスカバリーは、毎週、デリバリーのプレッシャーに負けてしまいます。自動化された採用、定例の時間枠、共有アーティファクトといった構造的な支援によって、毎週判断する必要がなくなり、習慣を継続し、学びを積み重ねられます。

主な洞察：

• PM だけでなく、トリオ全員が参加します
• 採用を自動化します：アプリ内での声かけ、アドバイザリーパネル、枠を埋めるスケジュール管理ツールを活用します
• カレンダーに定期的な時間を確保します。「時間を見つける」ことに頼るディスカバリーは決して実施されません
• インタビューのスナップショットは、数日後ではなく、インタビュー直後に記入します
• まずは週に 1 回のインタビューから始め、洞察を OST に結び付け、そこからスプリント計画に反映します

プロダクトでの活用例：

コンテキスト	活用方法	例
チームのキックオフ	1 週目に実施のリズムを確立する	採用の自動化、木曜日の時間枠の確保、スナップショットのテンプレート
ディスカバリーの拡大	週 1 回から週 3 回のインタビューへ増やす	解約したユーザー向けの枠と見込み顧客向けの枠を追加する
マネージャーの支援	リーダーが時間を確保し、根拠を求める	毎回の 1:1 で「今週のインタビューから何を学びましたか？」と尋ねる

倫理的な境界： 参加者の時間を尊重します。インタビューは 30 分以内に収め、適正な謝礼を支払い、セールストークをディスカバリーと偽ることは決してしないでください。

この習慣を自分のコンテキストに合わせる際は、references/case-studies.md を参照してください。B2B SaaS、コンシューマー向けモバイル、プラットフォーム、グロースチームでの継続的なディスカバリーを、実例に沿って詳しく解説しています。

よくある間違い

間違い	失敗する理由	改善策
開発前のフェーズとしてディスカバリーを行う	洞察が古くなり、チームが古い前提に基づいて開発する	デリバリーと並行して、毎週の活動にディスカバリーを組み込む
顧客と話すのが PM だけ	デザイナーとエンジニアは、伝達の過程でコンテキストを失う	トリオ全員でインタビューする
成果から解決策に飛びつく	オポチュニティの領域を見落とす	OST を作成して、オポチュニティを明確にする
顧客に何が欲しいかを尋ねる	ニーズではなく、機能の要望が得られる	ストーリー形式のインタビューを行う：「最後に……したときのことを教えてください」
リスクの高い前提ではなく、簡単に確かめられる前提を検証する	誤った安心感が生まれ、致命的な前提が未検証のままになる	重要度と根拠に基づいて整理し、リスクの高いものから検証する
オポチュニティを個別に評価する	すべてが重要に見える	明確な基準を使って、直接比較する
集中的にインタビューした後、やめてしまう	学びが積み重ならない	採用を自動化し、定期的な時間を確保する

簡易診断

質問	「いいえ」の場合	対応
毎週最低 1 回、顧客と会話していますか？	判断に新しい根拠が欠けています	採用を自動化し、週次の時間枠を確保します
常に更新されている Opportunity Solution Tree がありますか？	戦略が暗黙的で、共有されていません	成果とインタビューデータをもとに OST を作成します
インタビューにトリオ全員が参加していますか？	洞察が 1 人を介して伝わります	次回のインタビューにデザイナーとエンジニアを招きます
開発前に前提を検証していますか？	未検証の前提に賭けています	次の機能に関する前提を整理し、最もリスクの高いものを検証します
リリースした機能を顧客のオポチュニティまでたどれますか？	デリバリーとディスカバリーが切り離されています	バックログ項目を OST のオポチュニティに関連付けます
インタビューのスナップショットをチーム全体が確認できますか？	知識が 1 人の頭の中に閉じ込められています	インタビュー後に記入する共有スナップショットボードを用意します
オポチュニティを並べるだけでなく、比較していますか？	意見に基づいて優先順位が決まっています	上位 5 件のオポチュニティを、明確な基準で比較します

さらに読む

Teresa Torres が開発した継続的ディスカバリーのフレームワークに基づいています。

• 「Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value」 Teresa Torres 著

著者について

Teresa Torres は著者、講演者、コーチとして、スタートアップから Capital One、Calendly まで、数百のプロダクトチームが継続的ディスカバリーを取り入れるのを支援してきました。Opportunity Solution Tree を考案し、多くの読者に読まれている Product Talk ブログを執筆しています。また、コーチングの実践を Continuous Discovery Habits にまとめました。