開発者がユーザーインタビューを学んでみた：Whyを深掘りすると解決策は変わる
はじめに
価値あるプロダクトを作るには、Howより先にWhyを深掘りすることが大事だということはわかっていました。
が、自分はユーザーインタビューの経験などもなく「Whyを深掘りするって具体的にどうやるといいんだろう？」という思いを抱えていました。
そんな中で、社内でユーザーインタビューを実践する活動に参加することができ、多くの学びや気づきを得ることができました。また、その学びがあったことで、実際の案件でもよりよい解決策に辿り着くことができました。
この記事では、社内でのユーザーインタビュー実践から得た学びと、それが実案件でどう効いたのかについてお話しします。
1. きっかけ：Whyを深掘りしたいのに、やり方が分からない
「Whyが大事」という話はよく聞きますし、自分もそう思っていました。
ただ、実務の場面でそれを具体的にやるとなると、どうしても自信がありませんでした。
たとえば、こんな状態です。
- 質問は作れるが、相手の深い動機まで辿り着ける感覚がない
- 相手の話を聞いているうちに、頭がすぐに「解決」へ寄ってしまう
- 「じゃあどう実装する？」
- 「じゃあどの方式にする？」
- 「じゃあ案を出そう」
結果として、前提（背景・制約・本当の困りごと）が十分に言語化されないまま、解決策の議論に入ってしまうことがありました。
そして後から、そもそもそこが問題じゃなかったことが判明したりする。
だからこそ、社内でユーザーインタビューを実践する活動が立ち上がったときに、「これは自分に必要な経験だ」と感じて参加しました。
2. 実際にやってみての気づき
私は当初、インタビューは質問をとにかく準備することが大事だと思っていました。でも実際にやってみて、インタビューの主軸（仮説）を決めないと深掘りできない、ということがわかりました。
2-1. 今わかっていることから仮説と主軸を立てる
まずやるのは、一次情報を受け取ることです。
現場の状況、悩み、目的。断片でもいいので、材料を集めます。
そのうえで、「今回、何を明らかにしたいか（主軸）」を定めます。
ここで大事なのは、主軸は正解である必要がないことです。
この時点では仮説でOK。むしろ、仮説だからこそインタビューで検証できます。
自分にとっては、「主軸を立てる＝当てにいく」ではなく、インタビュー中に迷子にならないためのコンパスを持つ という感覚でした。
2-2. 主軸を深掘りする質問を列挙して、分類する
主軸が決まったら、次はそこを深掘りするための質問を出します。
ここでは、思いつくままに大量に書き出します。
ただし、列挙したままだと本番でうまく扱えないので、カテゴリで束ねて、インタビュー中にすぐ選べる状態にしました。
- 深める（Why方向）：一段奥の理由・背景に潜る
- 広げる（別角度）：違う切り口から状況を捉え直す
ここまでできていると、本番で「次何を聞くべきだろうか？」ということに頭のリソース取られずに済みます。
結果として、今までよりも相手の話をちゃんと聞けている感覚がありました。
2-3. 「気持ち」に触れると、Whyに繋がる話が出てくる
事実だけを追っていると、話が表層で止まることがありました。そういう時、相手の気持ちを聞いてみると、話を深掘りできている感覚がありました。
- 大事にしたいもの
- 避けたい体験
こういったものが出てくると、主軸に対する深掘りが一気に進みます。
「何が起きたか」だけでなく、「それをどう感じたか」を聞く意味が、ようやく分かりました。
2-4. 仮説は当てにいかない：相手と一緒に探る前提を持つ
もう一つ大きかったのは、1回のインタビューで「分かった」と思うのは早合点になりやすいということです。最初に立てた仮説が、そのまま当たっていることはほとんどありませんでした。
さらに厄介なのは、インタビュー中に相手自身が、話しながら「自分は何をしたいのか」「何が一番つらいのか」に気づくことがある点です。だから大事なのは、仮説にしがみつくことではなく、相手と一緒に探る姿勢でした。
この“更新”を起こすのが、想定外の問いです。こちらが想定していた筋書きに相手の話を寄せてしまうと、予定調和の質問と答えで終わってしまいます。一方で想定外の問いが入ると、相手が立ち止まって考え直す瞬間が生まれ、そこから課題の定義そのものが更新されることがあります。
だから初回は、仮説を当てにいく場ではなく、仮説を育てるための場。そう捉えるようになってから、インタビューの見え方が変わりました。
3. 学びが案件でも活きた話
この学びが、実際の案件でも活きたことがありました。
3-1. 状況：要求がぶつかる典型パターン
私が参画している案件で、メンバー間の意見がぶつかる場面がありました。
- PO側：現場の制約を踏まえた「運用しやすさ」を重視したい
- 開発側：リスク・原則・品質（セキュリティ等）を重視したい
どちらもメリット・デメリットがある話で、その場で「両方を満たす落とし所」はすぐには思いつけませんでした。
3-2. AIに壁打ちして、解決策の候補を用意したが
打ち合わせに向けて、AIと壁打ちしながら複数案を用意しました。
ただ、どれも決定打に欠ける感覚がありました。
今ふりかえると、この時点ではまだ、POが持っている情報──
- なぜそれを望むのか
- 具体的に何に困っているのか
への解像度が足りていなかったのだと思います。
3-3. 分岐点：提案の前に「背景の語り直し」をお願いした
会議の冒頭、用意した案を説明し始める直前に違和感がありました。
要望の理由を、まだ「現場の言葉」で聞けていないのでは？
このまま提案に入ると、議論が「どの案が良いか」に固定されてしまいます。
そこで、提案の前にPOに背景の語り直しをお願いしました。
やったことはシンプルに3つです。
- 要望の背景をストーリーとして語ってもらう
- 「何が／どの部分が一番つらいのか」を聞く（事実＋気持ち）
- 理解を言い換えて確認する
3-4. 結果：課題定義が更新され、解決策も変わった
背景を深く聞いていく中で、こちらが想定していた「解決すべき対象」がズレていたことに気づきました。
これは開発側だけでなく、PO側でも最初はうまく言語化できていなかった部分でした。
結果として、事前に用意していた案の「どれかを選ぶ」のではなく、別の解決案に辿り着きました。
運用上の負担も下げつつ、開発側の懸念にも応えられる形です。
3-5. WSの学びがどう効いたか
振り返ると、この場でできた判断はユーザーインタビューの学びに支えられていました。
- Whyは1回で掘れない
→ 早合点せず背景に戻れた／会議の目的を「決める」より「探索」に寄せられた - 気持ちに触れる
→ “痛みの正体”が更新された - 深める→広げる
→ 対立の外側に選択肢を作れた
提案・解決を急ぐと認知が縛られて、前提が更新されないまま進んでしまう。今回の経験は、そのことをはっきり体感した出来事でした。
4. まとめ
私は当初、ユーザーインタビューは「うまい質問を投げる技術」だと思っていました。
でも実際は、仮説を立てて主軸を持ちつつ、当てにいかずに相手と一緒に探索する設計が要でした。今はそう感じています。
今回の学びを、最後に3つに絞ってまとめます。
- 主軸（仮説）を立てるのが準備の本丸
何を明らかにしたいのかを決めてから質問を作る。これだけで深掘りの質が変わりました。 - 事実＋気持ちをセットで拾う
“避けたい体験”や“守りたいもの”が出てくると、Whyの解像度が一気に上がります。 - 1回で答えを出そうとしない
仮説は当てにいくものではなく更新するもの。想定外の問いで相手の自己理解が更新されることもあります。
この学びは案件でも効きました。提案の前に背景に戻って対話したことで、課題の定義が更新され、結果として解決策も更新されました。
そして今回一番の収穫は、開発者であってもWhyを深掘りするスキルが必要だと腹落ちしたことです。Howを考える前に前提を更新できるかどうかで、チームの意思決定の質が変わると感じました。
