第3章: プロダクトディスカバリー — 正しいものを作っているか

第2章で、ディスカバリーがPMの「本業（day job）」だと述べました。本章ではその中身に踏み込みます。プロダクトディスカバリーとは何か。なぜそれが、コードを1行も書く前に行われなければならないのか。 そして、顧客が本当に求めているものを、どうやって見つけ出すのか。 JTBD、The Mom Test、MVPといった現場の道具を、一つずつ手に取っていきましょう。

ディスカバリー vs デリバリー

プロダクト開発は、性格の異なる2つの活動から成ります。この区別が、本章の出発点です。

ディスカバリーが存在する理由は明快です。エンジニアの貴重な構築工数（デリバリーキャパシティ）を投じる前に、 第2章で見た4つのリスク（価値・ユーザビリティ・実現性・事業性）を安く・速く解消するためです。 間違ったものを丁寧に作っても意味がない——だからこそ「正しく作る」前に「正しいものを探す」のです。

ダブルダイヤモンド — 発散と収束のリズム

ディスカバリーとデリバリーの関係を可視化した古典的なフレームが、英国Design Councilが2005年に提唱したダブルダイヤモンド（Double Diamond）です。2つのダイヤモンドが、それぞれ「発散（広く探索）→収束（絞り込み）」のリズムを表します。

graph LR
  subgraph D1[問題空間 Problem Space]
    DISC[Discover\n広く調査] --> DEF[Define\n課題に収束]
  end
  subgraph D2[解決空間 Solution Space]
    DEV[Develop\n解決策を発散] --> DEL[Deliver\n最良案を出荷]
  end
  DEF --> DEV
  style D1 fill:#1e293b,stroke:#3b82f6,color:#fff
  style D2 fill:#1e293b,stroke:#14b8a6,color:#fff
  style DISC fill:#3b82f6,stroke:#2563eb,color:#fff
  style DEF fill:#3b82f6,stroke:#2563eb,color:#fff
  style DEV fill:#14b8a6,stroke:#0d9488,color:#fff
  style DEL fill:#14b8a6,stroke:#0d9488,color:#fff

最も重要な原則は、「課題を真に理解する前に、解決策へ飛びつくことを禁じる」という規律です。 第1ダイヤ（問題空間）で「Discover→Define」を経て課題を見極めてから、第2ダイヤ（解決空間）の「Develop→Deliver」に進む。 この順序を守ることが、一貫してより良い成果を生みます。

Jobs to Be Done — 顧客は製品を「雇用」する

「顧客が本当に求めているもの」を捉える最も影響力のある考え方がJobs to Be Done（JTBD）です。 中心にあるのは、Theodore Levittの有名な言葉——「人は4分の1インチのドリルが欲しいのではない。4分の1インチの穴が欲しいのだ」。顧客が雇うのは製品ではなく、それが片付けてくれる「ジョブ（用事）」なのです。

ミルクシェイク事例 — Christensenのジョブ理論

JTBDを語るうえで欠かせないのが、Christensenのミルクシェイク事例です。 あるファストフードチェーンがミルクシェイクの売上を伸ばそうとしていました。調査の結果、衝撃の事実が判明します——全販売の半分が午前9時前、単独の通勤客に売れていたのです。彼らはミルクシェイクを次の「ジョブ」のために雇っていました。

• 退屈な運転の暇つぶしになる
• 片手で運転しながら飲める
• 午前中の空腹を、昼まで防いでくれる

つまり競合は他社のミルクシェイクではなく、バナナ・ベーグル・そして退屈そのものでした。 「もっと美味しいミルクシェイク」を作ることが正解ではなかったのです。顧客が雇う「ジョブ」を理解することで、 まったく違う打ち手が見えてきます。

4つの力 — Moestaのスイッチング理論

Bob Moestaは、顧客が「乗り換える」瞬間に働く4つの力（Four Forces）を定式化しました。 あらゆる購買決定は、この綱引きで決まります。

graph LR
  PUSH[現状への不満\nPush] -->|変化を促す| C((顧客))
  PULL[新解決策の魅力\nPull] -->|変化を促す| C
  C -->|変化を妨げる| ANX[変化への不安\nAnxiety]
  C -->|変化を妨げる| HAB[現状の習慣・惰性\nHabit]
  style C fill:#3b82f6,stroke:#2563eb,color:#fff
  style PUSH fill:#14b8a6,stroke:#0d9488,color:#fff
  style PULL fill:#14b8a6,stroke:#0d9488,color:#fff
  style ANX fill:#f97316,stroke:#c2410c,color:#fff
  style HAB fill:#f97316,stroke:#c2410c,color:#fff

「Push（現状への不満）＋ Pull（新解決策の魅力）」が「Anxiety（変化への不安）＋ Habit（習慣・惰性）」を上回ったとき、人は乗り換えます。 ここで見落としがちなのが、新製品は「引き」を強めるだけでなく、「不安」と「惰性」を下げることが同じくらい重要だという点です。 どんなに魅力的でも、乗り換えが面倒で不安なら人は動きません。

The Mom Test — 「意見」ではなく「行動」を聞け

ジョブを見つけるには顧客に話を聞く必要があります。しかしここに罠があります。 Rob Fitzpatrickの『The Mom Test』が教えるのは、「母親に聞いても嘘をつかせない質問のルール」です。 なぜ母親か——母親はあなたのアイデアを愛情から褒めてしまうから。つまり、誰もがあなたのアイデアにお世辞を言うという前提に立つのです。

核心は「行動（behavior）」と「意見（opinion）」の区別です。 「人が何をしたか」は嘘をつきにくいが、「どう思うか／するつもりか」は容易に嘘になる。 特に危険なのがリーディングクエスチョン（誘導尋問）です。「これは良いアイデアだと思いますか？」と聞けば、 相手はお世辞で「いいね」と答え、あなたは間違った確信を持って帰ることになります。

❌ 悪い質問（意見・仮定・誘導）          ✅ 良い質問（過去の具体的行動）
─────────────────────────────────────────────────────────────
「これ買いますか?」              →   「最後にこの問題に直面したのは
                                     いつ? そのとき何をした?」

「いくらなら払いますか?」        →   「今どう解決してる?
                                     それにいくらかかってる?」

「この機能あったら便利?」        →   「直近でその作業をしたとき、
                                     どんな手順を踏んだ?」

ユーザー理解の3つの道具 — ペルソナ・共感マップ・ジャーニーマップ

インタビューで得た情報は、3つのツールで構造化されます。混同されやすいので、目的の違いを押さえましょう。

これらはバラバラに使うものではありません。複数のインタビューから共感マップを作るとパターンが浮かび、 それがペルソナの素材になる。そしてジャーニーマップが、そのペルソナが辿る感情と行動の推移を描く。 いずれも、後述するデザイン思考の「共感（Empathize）」段階の出力として位置づけられます。

MVP — 「2つの定義」が混乱を生んでいる

ディスカバリーの締めくくりに、最も誤解されている用語MVP（Minimum Viable Product）を扱います。 実はMVPには、起源の異なる2つの定義が併存しており、これが現場の議論をかみ合わなくさせています。

同じ「MVP」という語が、一方は「売れる最小の製品」を、もう一方は「学ぶための実験」を指している。 これでは議論が噛み合わないのも当然です。

思想的源流 — デザイン思考

ここまでの手法の多くは、デザイン思考（Design Thinking）を源流の一つとしています。 Stanford d.schoolが体系化した5段階は、Empathize（共感）→ Define（定義）→ Ideate（発想）→ Prototype（試作）→ Test（テスト）。 非線形で反復的なプロセスです。共感マップ・ジャーニーマップ・ペルソナはEmpathize段階の主要ツールであり、 これがデザイン思考とプロダクトディスカバリーの接続点になっています。

まとめ — 作る前に学ぶ

本章では、「正しいものを作っているか」を問うディスカバリーの道具を揃えました。ダブルダイヤモンドで課題と解決を分けて考え、JTBDで顧客が雇う「ジョブ」を捉え、The Mom Testで意見ではなく行動を引き出し、ペルソナ・共感マップ・ジャーニーマップで理解を構造化し、MVPで仮説を検証する。これらすべてが、第1章の縦串「作る前に学ぶ」を実践する技術です。

しかし、ディスカバリーで多くの「やるべきこと」が見つかったとき、次の問題が生まれます——どれから手をつけるべきか。限られたリソースで何を優先するか。 次章では、RICEやKanoをはじめとする8つの優先順位付けフレームワークを解剖します。