ユーザーインタビューは、回数を重ねればある程度できるようになります。相手の話を引き出し、深掘りの質問を返し、1時間ぶんの録音とメモが手元に残る。ここまではたどり着けるようになった、という方は多いはずです。
つまずくのは、その次です。何本かインタビューを終えて、録音の文字起こしとメモがたまっているのに、「で、結局どう作ればいいのか」がまとまらない。印象に残った発言はいくつか思い出せるけれど、それが全体の傾向なのか、その人だけの話なのか、判断がつかない。気づけばインタビューから2週間が経ち、記憶が薄れ、開発は止まったまま——。
プロダクトマネジメントを兼務している経営者の場合、この分析工程に丸1日を空けることは難しく、「やった気はするが意思決定は動かない」インタビューを繰り返しがちです。本記事では、インタビューで得た発言を どう整理し、どうやって意思決定に使える示唆(インサイト)に落とすか を、限られた時間でも回せる5つのステップに整理します。
インタビューの設計・実施そのものについては、別の記事で詳しく扱っています。本記事は「実施したあと」に焦点を当てます。
なぜインタビューの「分析」でつまずくのか
手を動かす前に、分析が止まる理由を3つ押さえておきます。ここに手を打たないと、手順だけ知っても続きません。
理由1：分析の前提として「記録」が荒い
インタビュー中に「これは重要だ」と思った発言だけをメモしていると、あとから分析しようとしても材料が足りません。その場では重要に見えなかった発言が、他の人の話と並べて初めて意味を持つことは珍しくありません。分析の質は、記録の粒度で上限が決まります。
理由2：事実と自分の解釈が混ざっている
「この機能が使いにくいと言っていた」というメモは、すでに解釈が入っています。相手が実際に言ったのは「毎朝この画面を開いて、まず前日の数字を電卓で足している」かもしれません。事実と解釈を分けずにまとめると、都合よく解釈した結論に流れやすくなります。
理由3：まとめるゴールが「報告」になっている
きれいな報告資料を作ることがゴールになると、分析は「体裁を整える作業」に変わります。本来のゴールは「次に何を作るか・作らないかを決められる状態にする」ことです。報告のための分析は、時間をかけたわりに意思決定を動かしません。
分析を始める前に決めておく2つのこと
ステップに入る前に、2点だけ先に決めます。ここが曖昧なまま分析を始めると、途中で「何を探しているんだったか」を見失います。
| 決めること | 具体例 |
|---|---|
| この分析で答えを出したい問い | 「新規ユーザーが最初の1週間で離脱する理由は何か」「有料プランに上げる人と上げない人の違いは何か」 |
| 分析の締め切りと使える時間 | 「木曜の夕方までに、開発チームに共有できる状態にする。使えるのは合計3時間」 |
問いを1つに絞ることが重要です。「ユーザーの声を幅広く拾う」という目的だと、発言のすべてが等しく重要に見えてしまい、分析が終わりません。今回のインタビューで何に答えを出すのかを、1文で書けるようにしておきます。
発言を「使える示唆」に変える5ステップ
ここからが本題です。1本あたり30〜45分、インタビュー5本で合計3時間程度を想定した進め方です。
ステップ1：発言を、記録のまま短く切り出す
文字起こし(または詳細メモ)を上から読み、気になった発言を 相手が言ったそのままの言葉で 短く切り出します。1発言=1枚(付箋、スプレッドシートの1行、カードツールの1枚——形式は問いません)。
このとき、自分の言葉に要約しないことが肝心です。「操作に手間取っていた」ではなく「どのボタンを押せばいいか分からなくて、3回くらい行ったり来たりした」と、発言そのものを残します。誰の発言かも記録しておきます(後でその人の属性と照らし合わせるため)。
目安は、インタビュー1本あたり15〜30枚。多すぎる場合は「今回の問いに関係しそうか」で軽くふるいにかけます。
ステップ2：各発言を「事実」「感情」「解釈・要望」に仕分ける
切り出した発言を、3種類にラベル分けします。
- 事実：実際にやっている行動、起きた出来事(「毎朝スプレッドシートに手で転記している」)
- 感情：そのときの気持ち、ストレスや満足(「この作業のとき、いつも憂うつになる」)
- 解釈・要望：相手なりの原因分析や、こうしてほしいという要望(「ボタンが分かりにくいからだと思う」「一括登録できるようにしてほしい」)
最も重視するのは 事実 です。感情は「どこに強い痛みがあるか」の目印になります。解釈・要望は参考程度に扱います。ユーザーは課題の当事者ではあっても、解決策の設計者ではないため、要望をそのまま作ると的を外すことがあります。この考え方は、たった一人を深く掘るN1分析とも共通します。
ステップ3：似た発言をグルーピングして、見出しをつける
全インタビューぶんの「事実」カードを机(または画面)に広げ、内容が近いものを寄せていきます。KJ法の要領ですが、厳密なルールは不要です。「なんとなく同じことを言っている」でまとめて構いません。
グループができたら、それぞれに 短い見出し をつけます。見出しは体言止めの分類名(「初期設定のつまずき」)ではなく、発見が伝わる1文にします。
- 悪い例：「オンボーディングについて」
- 良い例：「新規ユーザーは、最初の数字が表示されるまで自分の設定が正しいか確信が持てない」
見出しが1文で書けないグループは、まだ発言の寄せ方が粗い可能性があります。分け直すか、いったん保留にします。
ステップ4：グループを「示唆」に言い換え、確からしさを添える
各グループの見出しを、プロダクトの意思決定に使える形に言い換えます。ここで加えるのは次の3点です。
- 何人中何人の発言か：「5人中4人」。全員か、一部か、たった1人かで扱いは変わります
- どんな人に多いか：「特に、他ツールから乗り換えてきた人」。属性と紐づくと打ち手が具体化します
- 今回の問いへの答えになっているか：問いから外れた発見は「今回は扱わない」と明記して脇に置きます
たとえばこうなります。「新規ユーザーの離脱理由(問い)について——5人中4人が、初期設定の直後に『自分の設定が合っているか分からない』状態で手が止まっていた。特に他ツールからの乗り換え組に顕著。設定完了時に、正しく動いていることが分かる確認画面がない、という共通の穴がある」
たった1人の発言でも、その1人が狙っている顧客像そのものであれば、重要な示唆になります。人数の多さだけで切り捨てないようにします。
ステップ5：示唆を「打ち手の候補」と「保留」に振り分ける
最後に、示唆をアクションにつなげます。示唆1つずつに対して、次のどれかを決めます。
- すぐ着手する打ち手：課題が明確で、対応の見当がつくもの。バックログに具体的な項目として登録する
- もう少し調べる：課題は見えたが、原因や打ち手が定まらないもの。追加インタビューや行動ログの確認など、次のリサーチの計画にする
- 保留：重要度が低い、または今回の問いから外れるもの。消さずに「保留リスト」に理由付きで残す
ここまで来て初めて、インタビューが「次に何を作るか」に接続されます。打ち手をバックログに入れたあとの優先順位づけは、別の記事で扱っています。
まとめ方：共有する相手に合わせて1枚にする
分析が終わったら、共有用に短くまとめます。長い報告書は読まれません。次の構成の1枚(A4またはスライド1枚)で十分です。
| 項目 | 書くこと |
|---|---|
| 問い | 今回のインタビューで答えを出したかったこと(1文) |
| 対象 | 誰に何人聞いたか(属性の内訳) |
| 分かったこと | 示唆を3〜5個。それぞれ「何人中何人」「どんな人」を添える |
| やること | すぐ着手する打ち手、追加で調べること |
| 生の声 | 特に象徴的な発言を2〜3個、そのまま引用 |
「生の声」の欄を必ず入れます。要約された示唆だけだと、聞いていなかったメンバーには他人事に響きます。実際の発言が1つ添えてあるだけで、チームの受け止め方が変わります。
具体例：従業員10名、BtoB SaaSスタートアップのケース
従業員10名、創業2年目のBtoB SaaS(経費精算ツール)の例です。経営者がプロダクトマネジメントを兼務しており、無料トライアルからの有料転換率が想定より低いことに悩んでいました。「有料に上げる人と上げない人の違いは何か」を問いに設定し、直近1か月にトライアル登録した6社に30分ずつインタビューしました。
分析は木曜の午後、3時間で行いました。文字起こしから発言を切り出すと、6本で約120枚。事実・感情・解釈に仕分け、事実カードだけを広げてグルーピングしたところ、4つのグループにまとまりました。そのうち最も人数が多かったのが「経理担当1人では、社内に展開する自信が持てない」という主旨で、6社中5社。特に、他部署を巻き込む必要がある20名以上の会社に集中していました。
これを示唆に言い換えると、「有料転換の壁は機能ではなく『社内展開の不安』。トライアル中に、他メンバーを招待して一緒に試すところまで行けた会社は転換していた」となりました。打ち手としては、トライアル開始時に「まず経理チーム全員を招待する」導線を作ることをバックログの最優先に。あわせて「導入事例(同規模の会社が社内展開した流れ)を1本作る」を追加調査ではなくコンテンツ施策として登録しました。
共有は1枚にまとめ、営業定例で10分だけ説明しました。「6社中5社が同じことを言っている」という数字と、実際の発言の引用があったことで、営業チームからも「トライアル中のフォロー文面を変えたい」という具体的な動きが出ました。分析に丸1日ではなく半日を確保し、問いを1つに絞ったことで、意思決定まで到達できたケースです。
よくある失敗パターン
失敗1：印象に残った発言だけで結論を出す
強く記憶に残る発言は、たいてい「表現が刺激的だっただけ」のことが多く、全体の傾向とは限りません。必ず全発言を切り出し、グルーピングしたうえで、人数と属性を確認します。
失敗2：要望をそのまま機能リストにする
「〇〇できるようにしてほしい」を集めて開発リストにすると、課題の本質を外します。要望の裏にある「どんな場面で、何に困っているか(事実)」まで戻ってから、打ち手を考えます。
失敗3：分析を先延ばしにして記憶が薄れる
インタビューから時間が空くほど、文字起こしを読んでも「そのとき何が引っかかったか」が思い出せなくなります。実施から3日以内に分析の時間を確保します。難しければ、インタビュー直後の10分で「今日の気づき3つ」だけメモしておきます。
失敗4：1回のインタビューで全部を分かろうとする
5〜6本聞いて傾向が見えたら、いったんそこで打ち手に移します。「もっと聞けば確実になる」と追加を重ねるより、小さく作って反応を見るほうが速く学べます。
失敗5：分析結果を自分の中だけに置く
まとめた1枚を共有しないと、次に同じ議論が起きたときに「そういえば前に聞いたような」で終わります。1枚は必ずドキュメントとして残し、関係者がいつでも見られる場所に置きます。
よくある質問（FAQ）
Q1. 文字起こしは必須ですか。メモではだめですか。
慣れないうちは文字起こしを推奨します。メモは書いた時点で要約が入り、事実と解釈が混ざるためです。録音を自動文字起こしにかければ、コストは大きくありません。慣れてきたら、発言をそのまま書き取る詳細メモでも代替できます。
Q2. 何本インタビューすれば「分かった」と言えますか。
問いによりますが、同じ属性の相手なら5〜6本で主要な傾向は見えてきます。7本目以降で新しい発見がほとんど出なくなったら、その回はいったん打ち止めにして打ち手に移ります。
Q3. 分析ツールは何を使えばよいですか。
スプレッドシート1枚で十分です。列を「発言/種類(事実・感情・解釈)/話者/グループ/メモ」にしておけば、並べ替えとグルーピングができます。付箋やオンラインホワイトボードでも構いません。ツールより、事実と解釈を分ける習慣のほうが効きます。
Q4. 発言が人によってバラバラで、グループにまとまりません。
問いが広すぎる可能性があります。「使い勝手について」ではなく「新規ユーザーが最初の1週間で離脱する理由」まで問いを絞ると、関係する発言が減り、まとまりやすくなります。それでもまとまらない場合は、対象者の属性が混ざりすぎていないか確認します。
Q5. インタビュー結果と、アクセス解析などの定量データが食い違うときはどうしますか。
どちらかが間違いというより、見ている層が違うことが多いです。定量データは「何が起きているか(離脱率が高い)」を、インタビューは「なぜ起きているか」を教えてくれます。定量で異常値の出ている画面や導線を特定し、その部分についてインタビューで理由を掘る、という順番で併用すると噛み合います。
まとめ
ユーザーインタビューの価値は、実施の回数ではなく、分析で発言を意思決定に接続できたかで決まります。分析を始める前に「答えを出したい問い」を1つに絞り、締め切りと使える時間を決めます。
進め方は5ステップです。発言を記録のまま短く切り出し、事実・感情・解釈に仕分け、似た事実をグルーピングして1文の見出しをつけ、人数と属性を添えて示唆に言い換え、最後に「打ち手」「追加調査」「保留」に振り分けます。まとめは共有相手に合わせた1枚にし、象徴的な生の声を必ず添えます。
まずは、手元にたまっているインタビューの録音を1本、文字起こしにかけて発言を切り出すところから始めてみてください。1本ぶんを事実・感情・解釈に仕分けるだけでも、「何が分かっていて、何がまだ分かっていないか」の輪郭がはっきりします。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「経営者が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
