ユーザーインタビューを結論にまとめる方法

ユーザーインタビューを結論にまとめるには 4 つのステップを踏みます。発言の原文からコードを付ける、コードをテーマにまとめる、テーマから結論を導く、そして各結論にカバーする人数、代表的な発言、反例を明記する、の 4 つです。こうして得た結論はほかの人が確かめることができ、そのまま行動の提案につなげられます。この記事を読めば、一連のインタビュー記録を結論のリストにまとめ、優先順位を付けて提案を出せるようになります。

発言からコード、テーマ、結論へ

1. 発言：まずインタビューを文字に起こし、回答者番号ごとに発言の原文を残します。先に要約を書かないでください。要約にはすでに整理した人の理解が混ざっています。
2. コード：段落ごとに読み、意味のある内容それぞれに短いラベルを付けます。例：「エクスポートの入口が見つからない」「データを同僚に見られるのが心配」。ラベルは発言に近い言葉にし、細かすぎるくらいでかまいません。
3. テーマ：意味の近いコードをまとめ、問題がわかる名前を付けます。例：「共同作業の場面での権限への不安」。1 つのテーマは通常複数のコードから成り、複数の回答者にまたがります。
4. 結論：リサーチクエスチョンに照らして、このテーマが何を意味するのかを明確にし、人数、発言、反例を根拠として示します。

最初の 2 つのステップは、できればインタビューの進行中から始め、数回終えるごとに整理します。そうすれば深掘りの方向をすぐに調整でき、テーマが飽和したかどうかも判断できます。

親和図：コードをテーマにまとめる

親和図は最もよく使われる分類の方法です。コードを 1 つずつ回答者番号と一緒にカードに書き出します。付箋でもオンラインのホワイトボードでもかまいません。そのうえで数人で意味の近いカードを 1 つの山にまとめ、それぞれの山に名前を付けます。

• カードを先に並べ、名前はあとで付けます。最初から分類の枠組みを決めてしまうと、カードを無理に押し込みがちです。
• 1 つの山のカードが十数枚を超えたら、より具体的な 2 つのテーマに分けられないか検討します。
• カードが 1 枚しかない山はすぐに捨てないでください。まれだが重要な問題かもしれないので、別に印を付けておきます。
• 各山について、カードの枚数ではなく何人の回答者から出ているかを数えます。同じ人が繰り返し話した内容は 1 人として数えます。
• インタビューに参加していない同僚にも分類に加わってもらうと、インタビューした人の先入観を減らせます。

例：3 つの発言から 1 つの結論へ

以下の例は、あるチーム向けドキュメントツールのインタビューから取ったもので、回答者番号と人数はいずれも例です。3 人の回答者がそれぞれ次のように話しました。

整理の流れは次のとおりです。3 つの発言にそれぞれコードを付けます。「リンクを共有できず、スクリーンショットで代用」「共有前に内容を手動で削除」「権限の選択肢がわからず、共有をあきらめた」。3 つのコードはどれも同じことを指しています。ユーザーは共有したあと相手が何を見られて何ができるのかわからず、回避するかあきらめるかを選んでいるのです。これをテーマ「共有時に権限がどうなるか確信が持てない」にまとめます。ほかの記録も確認し、仮にさらに 4 人の回答者が似たことを話しており、同時に 2 人の回答者がチーム内でしか共有せず権限を気にしたことはないと話していたとすると、その 2 人を反例として記録します。

結論の例：例では 18 人の回答者のうち 7 人が、相手の権限がわからないために、スクリーンショットに切り替える、内容を手動で削除する、共有をあきらめる、のいずれかをしていました。チーム内でしか共有しない 2 人の回答者には、この不安はありませんでした。代表的な発言は回答者 07 によるものです。

結論の書き方

完全な結論は 4 つの要素で構成されます。一文の結論、カバーする人数、代表的な発言、反例です。結論の文は行動と場面まで具体的に書きます。人数は「多くのユーザー」ではなく、何人中何人と書きます。発言は最もよく問題を表す 1〜2 文を選び、回答者番号を明記します。反例には、その結論に当てはまらない人とその理由を書きます。反例が見つからなかった場合も、確認済みであることを明記します。

事実、解釈、提案を区別する

整理でいちばん間違えやすいのは、性質の異なる 3 種類の内容を 1 つの文にまとめてしまうことです。事実は回答者が何を言い、何をしたか。解釈は整理する人がそれをどういう意味だと考えるか。提案はチームが何をするつもりか。3 つを分けて書くことで、読む人はどの段階に問題がありそうかを判断できます。

行動の提案を書き、優先順位を付ける

提案はどれも、1 つまたはいくつかの結論にさかのぼれる必要があります。提案は、何を変えるか、誰のために変えるか、どんな行動の変化を期待するか、とチームがそのまま議論できるところまで書きます。優先順位を付けるときは、4 つの観点で点数を付けるとよいでしょう。影響範囲（何人の回答者が該当し、対応するユーザー層がどれくらいの規模か）、深刻度（利用の放棄や離脱につながるか）、エビデンスの強さ（人数、反例、行動データによる裏付け）、実施コストです。影響が大きく、エビデンスが強く、コストが低いものを上位に置きます。影響は大きいもののエビデンスが弱いものは、先に検証を行い、やるかどうかはそのあとで決めます。

過度の一般化と確証バイアスを避ける

過度の一般化とは少数の人の話を一般的な現象とみなすことで、確証バイアスとは自分の思い込みを支える内容しか目に入らないことです。どちらも結論を一見はっきりしたものに見せますが、実際には成り立ちません。

• 整理を始める前に、チームが持っていた仮説を書き出し、整理の際には仮説と反対の内容の発言を意識して探す。
• 各結論には人数と反例を書きます。1〜2 人の話は、どれほど生き生きしていても確信度「低」とします。
• 結論が特定のグループや特定の経路の回答者だけから出ていないかを確認する。
• インタビューに参加していない人に発言を読んでもらい、同じテーマにたどり着くかを確認する。
• 定性インタビューの人数はカバー範囲を示すものです。割合や規模に関わる判断は、アンケートや行動データで検証します。