会話自体は手応えがあるように思えても、チームにとってはほとんど学びがないことがあります。創業者がアイデアを話し、相手が「便利そうですね」と相槌を打ち、双方が有意義なミーティングだったと感じて終わる。しかし、既存のやり方を変えてまで解決したいほどその課題が重要なのかは、依然として分からないままです。

顧客開発（カスタマーディスカバリー）は、その不確実性を掘り下げるアプローチです。スティーブ・ブランクの顧客開発モデルに端を発し、顧客や課題、ビジネスに関する仮説を実際のファクトと照らし合わせます。狙いは、ソリューションへの熱意が計画として固まってしまう前に、プロダクトが成功するための条件を見極めることです。

実際の意思決定プロセスをたどる

効果的なインタビューは、相手がその課題に直面した「直近の体験」を聞くことから始まります。何がきっかけで、誰が関わり、どう解決したのか。差し支えなければ許可を得たうえで、スプレッドシートやメッセージのスレッドなど、実物を見せてもらいましょう。そうした細部を見ることで、「我慢できる程度の不便」なのか、「すでに時間やコストをかけて対処している課題」なのかを見極めることができます。

例えば、フリーランスへの請求書の承認を効率化するソフトウェアを作ろうとしているとします。インタビューを通じて、管理作業自体は問題ないものの、「誰が支払いを承認できるか分からないこと」が遅延の原因だと判明するかもしれません。入力画面を使いやすくしても、目に見える作業が速くなるだけで、根本的なボトルネックは解消しません。人々が本当に成し遂げたいこと（Jobs to Be Done）を掘り下げることで、提供価値の再検討につながります。

また、実際に作業を行う担当者と、購入者、予算管理者、セキュリティ責任者は異なる場合があります。導入の障壁になり得るなら、ディスカバリーの対象をそうした関係者にも広げる必要があります。現場のエンドユーザーが使いたがっていても、企業としての購入が決まるわけではありません。

仮説をあえて覆せる状態にしておく

ユーザーを集める前に、アイデアが成立するために「何が事実である必要があるか」を書き出しておきます。例えば、課題の発生頻度、既存の代替手段への不満、確立されたフローを変える意思などです。どのような事実があれば仮説が立証されるかだけでなく、何があれば仮説が覆るのかも決めておきましょう。そうでなければ、どのような会話でも都合よく肯定的なサインに見えてしまいます。

インタビューガイドを活用して、本筋を見失わずに想定外の気づきも拾えるようにします。また、すべてのセッションをデモの場にしてしまうのは避けましょう。参加者は提案されたソリューションを見てしまうと、その内容に引きずられた回答をしがちです。後半でコンセプトを見せるのは有効ですが、「コンセプトへのフィードバック」と「現在の行動に関する事実」は明確に切り分ける必要があります。

ディスカバリーはインタビューだけで終わるものではありません。トライアル、購買交渉、実際の業務フローの観察などを通じて、会話だけでは見落としていた制約が浮き彫りになることもあります。単一の手法で確証は得られませんが、組み合わせることで、特定の顧客層に絞る、提供価値を見直す、購買の前提条件をテストする、あるいは課題が存在しなかったアイデアへの投資を止めるといった、明確な意思決定が下せるようになります。学びの真の価値は、チームの次の一手を変えられるかどうかにあります。