Continuous Discovery Habitsとは、顧客との対話と小さな検証を継続しながら、製品やサービスの前提を見直し、次に何を造るべきかを考え続けるフレームワークです。
一度だけ市場調査を行い、要件を決め、その後は計画どおりに開発する。従来型の製品開発では、この流れになりがちです。しかし、最初の前提が外れていれば、どれだけ真面目に開発しても、売り上げにはいっこうにつながらない製品になってしまうことがあります。
Continuous Discoveryは、そうした失敗を避けるために、開発と並行して、顧客が達成したいこと、困っていること、望んでいること、それを十全に満たすための条件を継続的に確か続けるための方法論です。単なるアジャイル開発ではもちろんなく、単なる市場調査でも、単なるユーザーインタビューでもありません。
この記事では、Continuous Discovery Habitsの基本、従来型の開発との違い、Opportunity Solution Tree（OST）との関係、継続的インタビューの進め方、導入時につまずきやすい点を整理します。
Continuous Discovery Habits／継続的市場探索の習慣とは何か
Continuous Discovery Habitsとは、プロダクトチームが顧客と継続的に接点を持ち、インタビューや検証を繰り返しながら、何を造るべきかを見極めていくアプローチです。要点は、
点に、大きな特徴があります。
多くの組織では、市場調査、企画、開発、営業が分かれており、顧客の声が、開発や事業判断に十分届かないことがあります。Continuous Discovery Habitsは、いきなり組織図を変えるのではなく、まずは、自分たち開発チームの手が届く範囲で、顧客との接点を少しずつ増やし、そこで得た顧客の行動／代替手段／制約などの本音を、日々の開発チームの判断にリアルタイムで反映していくための、一群（１３個）の習慣です。
なぜ今、Continuous Discovery が世界の注目を集めているのか？
たとえアジャイル開発によって造る速度が上がっても、「何を造るべきか」を見誤っていれば、間違ったものを速く予算内に造るだけになります。
という事故は、日本は愚か世界各国で現在進行形で、水面下で多々起こっています。これは、ソフトウェア業界のみならず、製造業にもそのまま言えます。
顧客の行動、制約、欲求、解決したい課題の中から、どの市場機会を追うべきかを見極められているのか。そして、その市場機会に対して、自社が造ろうとしているものが、顧客価値と事業価値の両方につながるとエビデンスを持って証明できるのか。
Continuous Discovery Habitsは、この問いに答えるためのフレームワークです。一言で簡単にいうなら、収益に結びつかないカイゼンはカイゼンの名に値しない、という当たり前のことを指摘しているのです。
それを、時間をかけてきちんと改善できていると、どうすれば確実に言えるようになるのでしょうか。
そして、あなたのチームが、顧客にとっての価値を生み出しながら、同時に自社の事業価値にもつながる形で仕事ができていると、どうすれば（他者に対して）証明できるのでしょうか。
――Teresa Torres『Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value』Product Talk LLCより、拙訳
従来型の開発の進め方との違い
| 比較項目 | 従来型の進め方 （アジャイル含む） |
Continuous Discovery |
|---|---|---|
| 志向 | アウトプット志向 | アウトカム（最終目標）志向 |
| 目的 | 稟議を通った事業企画やバックログ通りに開発を進めること | 市場価値と事業価値の両方につながる成果を上げ続けること |
| 顧客
調査 |
開発前の単発イベントになりやすい | 事業開発チームが、開発と並行してリアルタイムに、継続的に実行する |
| 初期
仮説 |
有力案を一つに絞って進みがち | 複数の市場機会を並べて比較し、最も有効と思えるものから着手 |
| リスク | 決めたものは造れたが、それが売上や継続利用につながらない | 収益に結びつかないリスクを早めに検出し、造る前に事業企画レベルで方向修正できる |
Opportunity Solution Tree（OST）の基本構造
Continuous Discovery／継続的市場探索を実務で回すときに役立つのが、Opportunity Solution Tree（OST）／オポチュニティ（事業機会）・ソリューション・ツリーです。OSTは、事業機会（必ずしも顧客の課題とは限らない）、解決策、検証項目を、デシジョンツリー構造でリアルタイムに整理していくツールです。自分たちで、あるいは上層部の意向でこれを造ると決めてまっしぐらにその開発に勤しみがちなチームにとって、非常に有効です。
OSTの詳しい考え方や作り方、運用の方法については、別記事の Opportunity Solution Tree（OST）の解説 をご覧ください。ここでは Continuous Discovery との関係に絞って要点を整理します。
| 階層 | 意味 |
|---|---|
| Outcome／最終目標 | 達成したい最終目標です。売上、継続率、利用率など、顧客行動の変化を定義します。 |
| Opportunity／事業機会 | 顧客が抱える欲望、解決したい課題、不満、ペインポイント、意識せずにとっている非効率的な行動など、未解消のモヤモヤです。必ず複数案、並べておくことが肝要です。 |
| Solution／ソリューション | 課題に対する解決策の案です。最初から一案に絞らず、複数考えます。 |
| Assumption Test/Experiment／想定テスト | 解決策そのものではなく、その案が成り立つ前提仮説を確かめる小さなテストです。 |
明確なアウトカムを置く
OSTの出発点は、機能ではなくアウトカムです。何を造るかではなく、どんな変化を起こしたいのかを先に定義します。
実務では、事業アウトカムとプロダクトアウトカムを分けると整理しやすくなります。たとえば、「継続率を上げる」は事業アウトカムです。一方で、「顧客が初回利用で価値を実感できるようにする」はプロダクトアウトカムです。この二つを混ぜると、議論がすぐに「なにがなんでも、造ってしまったこの製品をたくさん売ること」に戻ってしまいます。
事業機会、顧客のモヤモヤを見つける
Opportunity／事業機会は、会議室で思いつくものではありません。顧客インタビュー、観察、営業への同行、展示会、問い合わせ分析、解約理由の確認などを通じて見つけます。
ここで大事なのは、以下です：
- ニーズを探そうとしない
理由1：ニーズという言葉を万人に通用する形で一意に定義することは不可能です理由2：「ニーズ」という言葉はあまりにもしばしば「シーズ」「ソリューション」という言葉の反対語であり、従って、「ソリューションから遡ってオポチュニティを定義する」という逆立ちした構造になりやすく、そうなったら最後、確実に確証バイアスによる必敗パターンにハマります。 - ペインポイント、課題を探そうとしない
理由1：テスラは「社会課題を解決したから」売れたわけではありません。単にカッコ良いから、モデルSはかつてあれほど売れたのです。そこにあったのは顧客の課題意識でなく、単なる欲望です。テスラが米国で売れなくなったのも、もはや顧客の課題を解決できなくなったからではありませんよね？理由2：スラックが世に出た当時売れたのは、「さまざまなツール類を別のアカウント、別のURLで使用するのが本当に面倒だ」とエンジニアたちが苦悩していたからではありません。単にスラックが現れたとき、「確かにそれもありだ」と気づいたに過ぎません。従って、当時のスラックユーザがスラックに出会う前には「どこにもペインなどない」とあっさり答えたでしょう。
解決策は複数出し、前提仮説を検証する
課題が見えてきたら、ようやく解決策を考えます。ただし、一案だけで進めるのは危険です。複数案を並べて比べながら、どれが最も筋がよいかを見極めます。
また、最初から完成品を造る必要はありません。重要なのは、その解決策が成り立つ前提仮説を小さく確かめることです。顧客は本当に困っているのか、その価値は伝わるのか、導入するだけの意味があるのか。こうした前提を一つずつ検証していきます。
【関連記事】Opportunity Solution Treeとは？基本的な考え方、描き方、事例多数を解説（アメリカの最新プロダクトマネジメントの手法）
継続的インタビューを成功させるポイント
Continuous Discovery Habitsでは、顧客インタビューを続けられるかどうかが大きな分かれ目になります。単発で終わらせず、日常的に回す仕組みが必要です。
| 項目 | 失敗しやすい進め方 | 望ましい進め方 |
|---|---|---|
| 対象者集め | 毎回手作業で募集する | 継続的に声をかけられる仕組みを造る |
| 質問内容 | ニーズやペインポイント、顧客の意見を収集する | 過去の具体的な行動を聞く |
| 結果の扱い | 議事録だけ残して終わる | OSTや仮説に反映する |
顧客との接点を日常化する
継続的インタビューの障害になりやすいのが、対象者集めと日程調整です。これを毎回ゼロからやっていると、すぐに止まります。したがって、顧客に声をかけやすい導線をあらかじめ造っておくことが重要です。
たとえば、既存顧客との定例接点、問い合わせ対応後のフォロー、営業同行、イベント参加者への打診など、自然に対話できる場を増やしておくと、継続しやすくなります。
過去の行動を引き出す
インタビューで重要なのは、顧客の意見を訊くことではありません。「この機能があったら使いますか」と質問しても、顧客はインタビューアであるあなたのメンツを潰さないために「いいですね」と答える可能性が高いのは明白です。報酬を支払ってインタビューをしているのなら、尚更です。
それよりも、「最近その業務をやったとき、最初に何をしましたか」「次に何をしましたか？」と、淡々と行動を確認していきます。これを Jobs-to-be-done インタビューと言います。
【関連記事】 ビジネスにおける「顧客の声」をどう聞くべきか？エキスパートインタビューの功罪
プロダクトトリオによる協働体制の構築
Continuous Discovery Habitsは、一人で回すものではありません。プロダクトマネージャー、デザイナー、エンジニアが一緒に顧客理解を深め、仮説を検証する体制が望まれます。いわゆるプロダクトトリオです。
この三者が初期段階から同じ顧客理解を共有していれば、「なぜこれを造るのか」がぶれにくくなります。逆に、企画、設計、開発が分断されていると、情報の伝達ロスが起こりやすくなります。
| 役割 | 主な視点 | ディスカバリーでの役割 |
|---|---|---|
| プロダクトマネージャー | 事業性、市場性 | アウトカムの設定と優先順位づけを担います。 |
| デザイナー | 顧客体験、使いやすさ | 顧客の困りごとを体験設計に落とし込みます。 |
| エンジニア | 実現可能性、技術制約 | 技術的な制約を踏まえて、検証しやすい形を考えます。 |
プロダクトマネージャーの役割
プロダクトマネージャーは、何を目指すのかを明確にし、チームが事業アウトカムに向かって動けるようにする役割を担います。ただし、正解を一人で決める存在ではありません。顧客理解を深めるための対話と検証を回しやすくすることが重要です。
デザイナーとエンジニアを早く巻き込む
デザイナーとエンジニアを後工程で呼ぶのではなく、最初から巻き込むことで、顧客の課題をより立体的に捉えやすくなります。体験設計と技術制約の視点が早い段階で入るため、無理のある案に時間を使いすぎずに済みます。
Continuous Discovery Habits導入の課題と対策
考え方自体は理解できても、実際に導入すると壁にぶつかることがあります。典型的なのは、時間が取れない、意思決定が上意下達になっている、顧客理解が一部の人だけの仕事になっている、といった問題です。
| 課題 | 起こりやすい背景 | 対策 |
|---|---|---|
| 時間が取れない | 開発タスクや資料作成が優先され、顧客との対話や小さな検証が「余裕があればやること」になってしまう。 | 週ごとの探索時間を先に確保し、まずは小さなテーマで、短いインタビューや小さな検証から始める。 |
| 意思決定が上意下達になっている | 企画書や仕様が先に決まり、現場チームが「何を確かめるべきか」を考える余地がない。 | 最初から組織全体を変えようとせず、まずは小さな範囲で検証の裁量を確保し、学習結果を示しながら理解を広げる。 |
| 顧客理解が一部の人だけの仕事になっている | 市場調査はマーケティング、顧客接点は営業、開発は仕様を造るだけ、という分断が起きている。 | 事業開発、技術企画、開発チームが、自分たちの判断に必要な範囲で顧客との接点を持ち、学びを日々の意思決定に反映する。 |
| ソリューションから逆算してオポチュニティを定義してしまう | OSTを描く際に、オポチュニティの箱へソリューションをそのまま書き込んでしまう。 | オポチュニティが、顧客が抱える未解消のモヤモヤを代弁しているかを、常に確認し続ける。 |
| OSTを一枚描いて満足してしまう | OSTを一度きれいに描き上げ、それを固定された設計図として扱ってしまう。 | OSTを、「アウトカムベースの進捗管理表」として、「どのオポチュニティを追い、どのソリューションを試し、どの想定を潰すか」の判断に応じて更新し続ける。 |
| 想定テストとMVPを混同してしまう | 「小さくテストする」という言葉を、すぐにプロトタイプやMVPを造ることだと誤解してしまう。 | 想定テストは、ソリューションを事業として成り立たせるための前提条件を一つずつ検証する行為だと切り分ける。 |
小さく始める
最初から全社導入を狙うより、まずは小さなテーマで始めるほうが現実的です。少人数のチームで顧客との対話と検証を回し、成果を見せながら社内理解を広げていくほうが定着しやすくなります。テレサ・トーレスは「組織を最初から変えようとしてはいけない」と警告しています。だから彼女の著書のタイトルは、Continuous Discovery HABITSなのです。
重い調査にしない
継続的探索は、重厚なレポート作成を毎回行うことではありません。短いインタビュー、小さな検証、素早い振り返りを回すことがポイントです。完璧さより、学習の回転数を重視したほうが成果につながりやすくなります。
ソリューションから溯ってオポチュニティを定義／探索しようとしない
テレサ・トーレス氏自身が嘆いていることの一つです、曰く、
これでは、Continuous Discovery/OSTを導入した意味が全くありません。全てのオポチュニティが、顧客が主語の行動からくる、顧客自身のモヤモヤになっているか、厳重にチェックし続けましょう。
OSTを一枚描いて、それを壁に貼って満足してしまう
ビジネスモデルキャンバスも然りですが、OSTも、リアルタイムで移ろいゆく事業の設計図です。特にOSTは、ガントチャートやバックログに代わる「アウトカムベースの進捗管理表」ともいうべきものです。一旦OSTを美しく書き上げて、それを正として、そこに書かれている通り、ひたすらソリューションを造り込んでいくのでは、これもContinuous Discovery/OSTを導入した意味が無くなってしまいます。
想定テストとMVPをごちゃごちゃに考える
テレサ・トーレス自身曰く、「小さくテストする」というのを勘違いして想定テストとプロトタイピングをごちゃごちゃにしているチームが世界に数多あるようなのですが、両者は全く違います。想定テストは、上段のソリューションを事業として成り立たせるためにあらかじめ押さえておくべき前提条件を一つずつ検証する行為です。
Continuous Discovery 導入事例
大手SIerが未経験分野での事業立案に成功した秘訣とは？Continuous Discovery 継続的市場探索 導入事例公開中！
Continuous Discovery Habitsのまとめ
- Continuous Discovery Habitsは、市場機会を捉え、価値へと転換する方法論、習慣です。
- 開発の進捗ではなく、市場価値創出の進捗を見る視点が重要です。
- Opportunity Solution Tree（OST）を使うと、事業機会、解決策、想定テスト項目を整理しやすくなり、市場価値創出の進捗が計れます。
- 顧客インタビューでは、意見、ニーズやペインポイントよりも、過去の具体的行動を聞き出す聞くことが有効です。
- ソリューションから遡って考えないことが最も大切です。
Continuous Discovery Habitsは、単なるインタビューのやり方ではありません。顧客理解を起点に、何を造るべきかを見極め続けるための仕事の進め方です。本質は、顧客の未充足ニーズ、痛み、欲求を継続的に捉えながら、自社が追うべきオポチュニティ、検討すべきソリューション、検証すべき想定を更新し続けることにあります。
ただし、この記事を読んだだけで、Continuous Discoveryをすぐに自社で実行できるわけではないと正直、思います。このフレームワークを、より具体的に「新市場での売上づくり」に落とし込む無料ウェビナーが、enFactory主催の「プロダクト市場価値再発見」入門です。
本ウェビナーでは、株式会社StartupScaleup.jp 代表取締役の富岡 功が、既存製品・既存技術を新しい市場価値へ結びつけるための Continuous Discovery 実践方法を解説します。
「Continuous Discoveryの考え方は分かった。では、自社の技術や製品ではどう使えばよいのか？」と感じた方は、ぜひご参加ください。
8つの新規事業を開発した、元デロイトトーマツコンサルティングに学ぶ 新市場で売上を立てる「プロダクト市場価値再発見」入門
イントラプレナーとして、合計８つの新規事業開発を経験。1,300回に及ぶ顧客インタビューの実施経験を持つ。生成AIによるアイディエーションの世界初のサービスである、「AIディアソン」を、2023年の1月に上梓。それ以降も次々とAIサービスをローンチしている。
翻訳書の発行される前の版の、The Four Steps to the Epiphany （邦訳「アントラプレナーの教科書」、リーンスタートアップの下敷きになった本）を所持するほど、古くから事業開発の方法論を考究。最近はアメリカで最新とされるプロダクト開発のメソッドである、継続的発見(Continous Discovery)手法を取り入れ、エフェクチュエーションと組み合わせて事業開発に応用。