ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム

本記事では、ユーザーインタビュー前に「筋の良い仮説をチームで設定する」ことの重要性と、具体的な仮説の設計方法を解説します。
仮説が緩い、ぶれぶれだと、「インタビューしたはいいが、で、どうする？」状態になりがち。ここでは、私が培ってきた経験と多くの先行研究・書籍を引用しながら、仮説設定のプロセスを分かりやすくまとめています。

「明日からチームで実践できる具体的方法」にも触れますので、ぜひ最後までご覧ください。また、ユーザーインタビューの目的・設計・やり方・分析まで完全ガイドの記事もあわせて参考にしてみてください。

【私について】

HRテック企業のプロダクトマネージャー
マーケ出身で元々博報堂に在籍し、これまで累計600名以上のユーザーインタビューを実施

なぜ「筋の良い仮説」がユーザーインタビューを左右する？
1. 仮説設定の重要性
2. 「筋の良い仮説」とは何か
チームで仮説を立てるメリットと進め方
1. 個人ではなく「チーム」で考える理由
2. 仮説ブレストのステップ例
「筋の良い仮説」を作るために使えるフレームワーク
1. JOB理論による仮説設計
2. ICEスコアを使った優先度づけ
インタビューで仮説を検証する際の注意点
よくある失敗パターンと改善策
今日から実践できるアクション
Q&A
8. 参考文献・引用一覧

なぜ「筋の良い仮説」がユーザーインタビューを左右する？

仮説設定の重要性

インタビューで得られる情報の質は、事前の「問いと仮説」の明確さに左右されます。問いで言えば、例えば「競合サービスへの不満点を詳しく知りたい」のか、「新規機能の利用意欲を測りたい」のか、あるいは「ユーザーが今どんな課題感を抱えているか」を探りたいのか。目的やフォーカスがあやふやだと、インタビューの質問設計が散漫になりがち。

FoundXのスタートアップ失敗原因のトップは「ニーズがないものを作った」ことで、これは仮説がずれたまま開発を続けた典型例。したがって、インタビュー前にはまず「何を検証するための仮説なのか」をチームで共有しましょう。

「筋の良い仮説」とは何か

次に問いに対する仮説設計ですが、「筋の良い仮説」は下記の3つを満たします。
（詳しくは『イシューからはじめよ』など参照）

具体的：主語・動詞や比較表現が明確で、曖昧じゃない
検証可能：実際のユーザー行動や数字、事実ベースでの検証が行える
検証結果が意思決定に大きな影響を与える：仮説が正しい／誤りかで、製品方向性や優先順位が変わる

たとえば社内決定プロセスの自動化SaaSの場合、「A社（競合）の決済承認機能のわかりにくさに強い不満を抱くユーザーは、実際に決裁権限がある上長と頻繁に相談しているため導入を渋っているのではないか？」という仮説は、非常に具体度が高いです。もし仮説が正しければ、UI改善や承認プロセスのサポート機能が必須となるはず。

チームで仮説を立てるメリットと進め方

個人ではなく「チーム」で考える理由

複数の視点を取り入れると、思い込みや認知バイアスを排除しやすくなります。PMだけが感じている課題が、実はエンジニア視点ではそこまで重要度が高くないかもしれないし、セールス視点ではまったく別のボトルネックが見えているかもしれません。

『起業の科学』（田所雅之）やRunning Lean（Ash Maurya）でも、「仮説の偏りを減らすには、できるだけ異なる立場のメンバーを巻き込むべき」と強調されています。

仮説ブレストのステップ例

私がよく実施する、チームで仮説を立てる流れの例です。

目的を共有：インタビューで何を検証するか（課題/ソリューション/使い勝手など）
既存情報の整理：既存ユーザーからの問い合わせログ、データ分析結果、社内の営業・CSメンバーの声など（ここまでは1人で）
仮説アイデアを出す：ポストイットやオンラインホワイトボードを使い、各自が思いつく仮説をできるだけ書き出す（ここをみんなと一緒に）
優先度をつける：ビジネスインパクト、ユーザーの深刻度、検証の難易度などの軸で評価し、まず検証したい仮説を絞る
仮説を言語化：具体的な形（「◯◯の属性のユーザーは◯◯の理由で現在△△を使っている」「その結果××な不満がある」など）に落とし込む

プロダクトマネージャーとしては、個人の思い込みが入りすぎないように注意しながら、ビジネス視点・ユーザー視点・テクノロジー視点をバランスよく踏まえて検討を進めます。

「筋の良い仮説」を作るために使えるフレームワーク

JOB理論による仮説設計

私が頻繁に活用している「JOB理論（Jobs To Be Done理論）」では、ユーザーが本当に成し遂げたいタスクや状況、障壁、代替手段といった視点からインタビュー設計を行います。仮説立案時にも、以下のように分解して考えると筋の良いものが作りやすくなります。

Situation（状況）：どんなシチュエーションで課題が発生しているのか？
Motivation（動機）：なぜ解決しようとするのか？
Outcome（成果）：何を最終的に達成したいのか？
Struggle（もがき）：既に試した解決策やどんな行動を取ったのか？
Obstacles（障壁）：具体的にどこで詰まったのか？コストや権限などの問題は？
Alternatives（代替案）：競合サービスや自前でのやり方があるのでは？

「仮説：競合サービスでは解決できない◯◯の障壁がある → その障壁が、実は利用者自身の権限不足やコスト感に起因している」というように、仮説を状況〜障壁まで具体的に書き出すと、チームメンバー全体で問題の因果関係を理解しやすくなります。

ICEスコアを使った優先度づけ

仮説の数が多いとき、どれからインタビューで検証すべきか悩むことがあります。ICEスコア（Impact：インパクト、Confidence：確信度、Ease：実現容易性）は、施策評価だけでなく仮説の優先度づけにも応用可能です。

Impact：その仮説が当たっていた場合、事業全体に与える影響度は高いか？
Confidence：チームとして「これ、当たってそうだね」と思う確信度はどれくらいか？
- 満点を「不確実性が高い」ものにしましょう（不確実性が低いならそもそもとっとと実装するべき）
Ease：その仮説は短期で検証しやすいものか？データ取得が容易か？

これらを1〜10点などざっくりつけて掛け算すれば、優先的に検証したい仮説の順番が見えてきます。
「この仮説が当たっていたら大きく方向性が変わる。かつ検証コストもそこまで高くない」なら、迷わず最優先でインタビュー設計に組み込むべきでしょう。

インタビューで仮説を検証する際の注意点

ユーザーに「未来」を聞くな

これまで600名以上と会話してきましたが、「未来の想像」を尋ねると、ユーザーは「その機能あるといいですね」と答えてくれることがほとんどです（日本人親切）。これは「本当にニーズがあるか？」の検証には一切ならないので注意。

FoundXのリソースでも繰り返し言及されていますが、「直近の事実や行動」（いつ、どこで、何に困ったか、どんな解決策を試したか）を聞くほうが課題の深刻度を把握しやすいです。

ユーザーの発言をそのまま受け取らない

インタビュー中、ユーザーが「こういう機能が欲しい」と直接言ってくる場合があります。しかし、それは本質的な課題の表れというより、あくまで「顕在化している不満の解決策」をユーザーなりに考えた結果かもしれません。
聞き手は、「なぜそれが必要だと思うのか？その背景にはどんな課題があるのか？」をさらに深掘りする意識を持ちましょう。

チームでインタビュー内容を振り返る

仮説を共有したチームこそ、インタビュー後も一緒に振り返りを行います。1回のインタビューですぐに答えが出なくても、5人程度に聞くと共通項が見え始める、とNielsen Norman Groupの研究でも示唆されています（5人テスト理論）。
小規模で回しながら、仮説との矛盾点や追加ヒントを見つけ、その都度仮説をアップデートしていく流れが理想です。