継続的なディスカバリー（Continuous Discovery）を取り入れると、顧客からの学びが日々の仕事の一部になります。判断に迷うたびにわざわざリサーチプロジェクトを立ち上げるのではなく、プロダクト開発を進めながら、チーム自らがニーズを調べ、解決策を探り、仮説を検証していきます。

テリーサ・トーレス（Teresa Torres）が提唱する継続的ディスカバリーの定義では、プロダクトを作るチーム自身が、目指す成果（アウトカム）に向けて少なくとも週に1回は顧客と接点を持つリズムを推奨しています。頻度を保つことで習慣化しやすくなりますが、大切なのはその対話がチームが今直面している問いにしっかり活かされていることです。

ユーザーが実感できる「成果」から始める

「新しいオンボーディング用チェックリストを公開する」というのは単なる成果物（アウトプット）の指定にすぎません。「新しい管理者がサポートなしで最初のアカウント設定を完了できるようにする」と設定すれば、チームが向き合うべき変化が明確になります。チェックリストは、権限設定をわかりやすくする、デフォルト値を改善する、別のタイミングでサポートを提示する、といった多様なアプローチの中の選択肢の一つに変わります。

直近の体験について顧客と話すことで、どこでつまずいているかが見えてきます。たとえばオンボーディングの例なら、「同僚の承認が必要だったので設定を後回しにした」という管理者の声が聞けるかもしれません。この話からは、「『次へ』ボタンが見つからない」という不満とはまったく異なるアプローチが見えてくるはずです。

こうしたニーズや解決策の候補を整理するには、オポチュニティ・ソリューション・ツリーが役立ちます。図のブランチ（枝）がリサーチの裏付け以上に確実なものとして一人歩きしないよう、根拠となるデータやエビデンスは常に参照できるようにしておきましょう。

不確実性を解消できる、小さなアクションを選ぶ

問いの内容によって、ユーザーインタビューが適していることもあれば、プロトタイプ、利用データの分析、あるいは技術的な調査が必要な場合もあります。週に1回話を聞いているからといって、機能に関するすべての仮説が自然と検証できるわけではありません。

先ほどの承認プロセスの課題であれば、まずは「誰が判断を下し、どんな情報を必要としているのか」を調べることから始めるかもしれません。その上で、新しく考えた招待フローをBallparkのプロトタイプテストで検証してみることもできます。アクションごとに得られるエビデンスは異なるため、その結果が意思決定にどう影響するのかをチーム内で説明できるようにしておくことが重要です。

また、声をかけやすい顧客だけに頼らないようにしましょう。よく使ってくれているアクティブなユーザーばかりが参加してしまうと、本来救うべき「途中で設定を諦めてしまった人たち」の声が、リサーチからこぼれ落ちてしまいます。

習慣化が「視野の狭さ」につながらないようにする

日々の小さなリサーチは、より広いリサーチプログラムの一部として機能します。発生頻度の低い事象、長期的な行動、馴染みのないユーザー層、あるいは全体規模の推計などを把握したい場合は、より多くの時間と異なる設計が必要です。毎週顧客と接点を持っているからといって、そうしたリサーチが不要になるわけではありません。

どの機会（オポチュニティ）を検討し、どの仮説を検証し、その結果何が変わったのかを記録しておきましょう。そうすることで学びがチームに蓄積され、体験のごく一部ばかりを何度も調べ続けていないか気づけるようになります。持続可能なディスカバリーの実践とは、目の前の実用的な判断だけでなく、プロダクトの進むべき方向性そのものを問い直すようなエビデンスを受け入れる余地を残しておくことなのです。