顧客インタビューの結果をどう分析する？根拠と仮説のまとめ方
目次
顧客インタビューの分析では、記録を人ごとに短くまとめるだけでなく、同じ場面で何が共通し、どの条件で違うのかを比べます。発言や観察の根拠と、そこから考えた仮説を分けると、次に確かめることを選びやすくなります。
この記事では、複数人の聞き取りを一つの分析表へ整理する方法を紹介します。面談の進行や記録の取り方から確認したい場合は、ユーザーインタビューの進め方を先に参照してください。
- 原記録に戻れる形で、発言・観察・解釈を分けます。
- 共通点だけでなく、条件の違いと反例を残します。
- 分かった範囲と未確認点から、次の行動を決めます。
最初に、何の判断に使う分析かをそろえる
分析を始める前に、今回の調査で選びたい行動を読み直します。「初回設定を途中でやめる理由を知り、次に試す改善案を選ぶ」のように、対象の場面と判断をそろえます。
面談で印象的な話が出ても、今回の問いとは別の話題かもしれません。捨てるのではなく、別の検討事項として分けます。目的が曖昧なまま全部を一つにすると、「使いにくい」といった広すぎる結論になり、次の作業が決まりません。
参加者の条件と、各面談で実際に聞いた項目も確認してください。同じ質問をしていない人の沈黙を、その問題がなかった証拠にはできません。
元の記録に戻れる分析用の表を作る
GOV.UKの調査分析ガイドは、見聞きした内容を解釈と分け、関連する観察をまとめたうえで、分かったことと次の行動を整理しています。以下は、その区別を表計算で扱うための本記事の提案です。
| 項目 | 残す内容 |
|---|---|
| 記録ID・参加者ID | 元の面談と該当箇所へ戻るための番号 |
| 場面・条件 | 誰が、どの役割で、何をしようとしていたか |
| 発言・観察 | 「発言の要約」「観察した操作」など種類を明記。要約と原文も区別 |
| 原記録の参照 | メモの位置、閲覧権限のある録音の時刻など |
| 解釈・仮説 | 記録から考えられる理由。まだ確定しないこと |
| 次に確認する点 | 他の記録や追加の調査で確かめたいこと |
一つの行には、比較したい一つの出来事を入れます。同じ参加者の話を複数行に分けても、参加者数は増えません。共有用の表には不要な氏名や連絡先を載せず、原記録の閲覧範囲も別に管理します。
共通する言葉より、場面と条件を比べる
以下は、架空の予約管理ツールについて聞き取ったと仮定した説明用の例です。実在の顧客の発言、観察、調査結果ではありません。
| ID | 条件 | 発言の要約 | まだ分からないこと |
|---|---|---|---|
| P1 | 店舗の設定担当。初めて一人で設定 | 通知先の選択で止まり、上司に確認したと説明 | 表示の意味で迷ったのか、社内の担当決めで迷ったのか |
| P2 | 設定担当。社内の手順書を参照 | 通知先を手順書で確認し、設定を終えたと説明 | 手順書がなければ同じように進められるか |
| P3 | 日々予約を扱う担当。初回設定は未経験 | 通知は届いているが、設定は別の担当者が行ったと説明 | 設定した本人がどこで迷ったか |
P1とP2は、通知先を決める場面を比較できます。一方、P3は同じサービスを使っていても、初回設定を経験していません。P3が困りごとを挙げなかったことを、設定画面が分かりやすい証拠にはしません。
ここでのまとめは「通知設定が難しい」より、「通知先を決めるとき、社内で誰が受け取るかの情報が必要になる可能性がある」のほうが、次に確認する条件を含んでいます。ただし、P1が止まった原因は未確定です。
仮説に合わない記録も、同じ表へ残す
P2のように設定できた人の記録は、困った人と矛盾するから不要なのではありません。何があれば進めるかを考える材料になります。
分析の結論と根拠を、次の表で並べてみます。
| 分析で残す項目 | 上の例での記入内容 |
|---|---|
| 気づき・仮説 | 通知先を決めるための社内情報が、設定の進み方に関係している可能性がある |
| 支える記録 | P1は上司へ確認。P2は社内手順書を参照 |
| 別の説明の可能性 | 用語の意味や、選択肢の表示で迷った可能性も残る |
| 比較の限界 | 初回設定の経験があるのはP1・P2。P3から設定時の体験は得られていない |
| 次の確認 | P1に迷った表示と判断内容を確認。別の設定担当者にも同じ場面を聞く |
誰かが「結局、案内文を増やせばよいのでは」と提案しても、仮説と解決案は別の欄に置きます。案内文の追加は、これから試す候補であって、分析で効果が証明された施策ではありません。
件数で、顧客全体の割合を決めない
報告に件数を添えるなら、何を数えたかを書きます。たとえば「今回の面談で初回設定を経験していた2人のうち、1人が途中で他者へ確認したと説明した」と書けば、対象が分かります。
ただし、この少人数の聞き取りから「顧客の半数が設定できない」とは言えません。参加者の選び方も、経験した条件も異なるためです。人数を示すことと、顧客全体に一般化できることは別です。
また、一人が何度も同じ問題を話したからといって、複数人が困っていることにはなりません。人数、発言の回数、出来事の件数を混ぜずに記録します。対象者の偏りが気になる場合は、調査対象者の選び方へ戻って見直します。
最後は、次の行動と担当を決める
分析表の最後には、「確認できたこと」「未確認のこと」「次の行動」「担当」「確認する時点」を残します。
| 判断へつなぐ欄 | 記入欄 |
|---|---|
| 確認できた範囲 | ［対象者・条件・根拠ID］ |
| 未確認点・別の説明 | ［まだ言い切れないこと］ |
| 次の行動 | ［何を確認し、どの判断につなぐか］ |
| 担当・確認する時点 | ［担当者／日付や判断の機会］ |
結論を大きく言い切るより、次に何が分かれば判断が進むかを明確にします。
上の例なら、次の行動は「通知設定の画面を直す」ではなく、「P1が迷った表示を確かめ、説明案を試す必要があるか判断する」かもしれません。追加調査を行う担当と時点を決めれば、未確認のまま資料だけが増えるのを避けられます。
改善候補を継続して扱うときは、機能要望管理の基本に沿って元の記録とつなぎます。分析で見つけた仮説を要望として登録しても、開発が決まったことにはなりません。
全員が同じことを言わなければ、結論にできませんか？
同じ場面でも条件が違えば、話は異なります。人数をそろえるより、どの条件で何が起きたかを示しましょう。少数でも影響が大きい可能性がある記録は残し、確認する対象にできます。
AIに録音やメモをまとめさせてもよいですか？
利用できるツールとデータの扱いを、社内のルールや参加者への説明に照らして確認してください。要約を使う場合も、元の発言との対応、否定や条件の抜け、存在しない発言の追加は人が照合します。AIの要約自体を新しい調査結果として数えません。
