ユーザーの発話を「そのまま」信じてはいけない。では、どうする?

はじめに

前回は「ただユーザーに話を聞くことではなく、心構えがある」という話でした。

今回は、少し予定を変更して、これまでの連載の補足をします。読者の方から「ユーザーの発言をそのまま信じてはいけないのに、ユーザーインタビューをするメリットを、もう少し詳しく説明してほしい」とご意見をいただきました。

このご意見に対する具体的なテクニックを、事例をとおして解説します。

ユーザーの発話を「そのまま」信じてはいけない。
ではどうする?

人と一緒に行くレストランをえらぶときのユーザー心理をインタビュー調査したところ、それぞれのユーザーから、次のような発話がありました。

• Aさん：「お店の料理が相手の好みか気にする」「相手の笑顔を思い浮かべる」
• Bさん：「相手にアレルギーがないか確認する」
• Cさん：「自分の好みより、相手の好みを優先する」
• Dさん：「イタリアンが相手の好物だった」「相手に感謝されて、自分も嬉しくなった」

これらの発話を、どのように受け取れば良いでしょうか。このままでは散漫な情報です。意味のベクトルが上下左右のあちこちを向いているような状態です。

ユーザーのさまざまな発話を、どのように受け取れば良いのか

ユーザーの発話を「抽象化」して
本質的なニーズを見つける

ユーザーの発話を「そのまま」信じてはいけない、という原則のポイントは、ユーザーの発話の「そのまま」でなければ信じられる、ということです。ユーザーの発話を聞くな、という意味ではなありません。

そのためには、ユーザーの発言を「抽象化」という作業をとおして、本質的なニーズへと掘り下げていきます。具体的には、それぞれの発話の背景にある心理に注目して、それぞれの言葉をグループ化し、グループ名をつけていきます。グループ名は、その中身をできるだけうまく表現している文章をえらびます。

コツは、グループ名を単語ではなく文章でつけることです。単語だと表現できる情報が薄すぎて、行き詰まりやすくなります。先ほどの、ユーザーの発話をもとに、実際にやってみましょう。

「お店の料理が相手の好みか気にする」「自分の好みより、相手の好みを優先する」「イタリアンが相手の好物だった」の3つは似た心理から発せられているので、ひとつのグループにまとめられそうです。グループ名は「相手の好みにあわせる」としましょう。

「相手の笑顔を思い浮かべる」「相手に感謝されて、自分も嬉しくなった」の2つも、近しい心理でまとめられそうですね。グループ名は「相手の笑顔にしあわせになる」としましょう。

「相手にアレルギーがないか確認する」は、ほかのものとはちょっと毛色が違いそうです。そのまま、独立したグループとしましょう。

ユーザーの発話をグループ化する(1段階)

さらにグループ化を進めます。「相手の好みにあわせる」と「相手にアレルギーがないか確認する」は心理として近しいものがありそうです。大きなグループにして「相手のしあわせを何より考える」というグループ名をつけましょう。

「相手のしあわせを何より考える」と「相手の笑顔にしあわせになる」も似た心理のようです。グループにまとめて「相手がしあわせだと自分もうれしくなる」というグループ名にしましょう。

ここまでを図にすると、次のようになります。

ユーザーの発話をグループ化する(2段階・3段階)

ここまで見ると、最初のユーザーの6つの発話は「相手がしあわせだと自分もうれしくなる」という根源的なニーズから派生してきたものであることがわかります。

このように、発言の背景にある心理を深掘りし、グループ化していく作業を「抽象化」と言います。抽象化をすることで、ユーザーの本質的なニーズがわかるのです。

「抽象化」することで、ユーザーの本質的なニーズがわかる

「抽象化」していないユーザーの生の言葉は
情報の断片にすぎない

言い換えると、抽象化していないユーザーの生の言葉は、まだ情報の断片にすぎないのです。

抽象化する前の発話をぼんやりと眺めて、たとえば「イタリアンが相手の好物だった」という発話だけを取りあげ、イタリアンだけを前面に押し出したグルメアプリをつくったとしたら、それはとても部分的なニーズにしか応えていないことに、今ならわかると思います。「イタリアンが相手の好物だった」というエピソードは「相手がしあわせだと自分もうれしくなる」という、根源的なニーズのひとつの表出にすぎないのです。

「ユーザーの発話をそのまま信じてはいけない」ことを、もう少し具体的に言うと「ユーザーの発言を抽象化せずに、そのまま受け取ると、それは表面的なニーズであるかもしれない」ということです。抽象化というプロセスをふむことで、信じるべき真のニーズにたどりつくことができるのです。

抽象化していないユーザーの生の言葉は、情報の断片にすぎない

定性分析の基本は抽象化です。親和図法(KJ法)を考案した川喜田二郎は、このプロセスを指して「統合」と呼びました。例を挙げると、定量分析が「りんご、りんご、みかん」を「りんごが2個、みかんが1個」と、同じ特徴があるものを「分類」する作業であるのに対し、定性分析は「りんご、きりん、サッカー」というような共通点がないものに「私が好きなもの」という柱をとおして、ひとつに「統合」する作業なのです。

ユーザーインタビューは、次の「定性分析」ステップへ
いかに豊かな材料をわたせるか、が目的

ユーザーインタビューは、インタビューして終わりではなく、次に「定性分析(＝抽象化)」というステップが待っています。

誤解されがちなのは、ユーザーインタビューしたらすぐに何らかのインサイトが得られる、ということです。インタビューしても、分析しなければインサイトは得られません。

ユーザーインタビューは、狭い意味では、次の「定性分析」ステップの「材料を集める」行為です。次のステップへ、いかに豊かな材料をわたせるか、がインタビューの成果であって、なにかを発見することが主目的ではないのです。

ユーザーインタビューから定性分析へ

抽象化の具体的な手法

抽象化の具体的な手法としては、前述した親和図法(KJ法)や本質的価値抽出法(KA法)、メンタルモデルダイアグラムといったものがあります。

道具は、複数人でやるときは、ふせん、太めのマーカー、ホワイトボードや模造紙を使います。Miroのようなオンラインツールを使う方法もあります。ひとりでやるときは、紙でも良いですし、PowerPointなどを使うこともあります。筆者は、シンプルにExcelを使っています。筆者の実務では膨大な発話データをあつかうことが多く、いわゆるスプレッドシート形式のほうが効率が良いためです。

ユーザーインタビューから価値を引き出す

今回は、読者の質問に答えるかたちで、そもそもユーザーインタビューから価値を引き出すためにはどうすれば良いか、というお話をしました。次回は本筋にもどって、インタビュー調査のはじめの一歩として「リサーチクエスチョン」を適切に立てる、という点について触れていきます。