Webディレクター解体アドベントカレンダー8日目の記事です。定性調査にもいろんな種類がありますが、一番代表的なのはユーザーインタビューだと思います。ユーザーさんに直接向き合う機会で得られるものも多いですが、きちんと意識してやらないと有効な情報が得られません。今日はユーザーインタビューのやり方や、気を付けるべきポイントについて書きます。
目的を明確にする
ユーザーインタビューを設計するにはまず、その目的をはっきりさせる必要があります。何のためにやるのか、どういう情報を得たいのか、その目的にとにかく自覚的になることが最初のステップです。私がこれまでにやってたインタビューを例にすると、以下のような目的がありました。
- ターゲットユーザーの課題を探る
- サービスを立ち上げる前の調査フェーズで、ターゲットになるユーザーの現在行なっている代替手段が何で、そこにどういう課題があるかを掘り下げていった
- サービスのコアバリューを確認する
- サービス開始からしばらく経ったサービスで、実際にサービスを利用しているユーザーが何を理由に自分たちのサービスを選び、なぜ使い続けてくれいるのか、その最もコアになる価値の確認を目的とした
- 導入を考えている大きな企画を開発前に検証する
- お金の絡む機能など開発に大きなコストがかかる場合に、開発を始める前に企画をパッケージデザインにまとめて直接見てもらい、その反応をうかがったり感想を聞いたりして実際に受け入れられそうかどうかを検証した
- すでに提供している機能の利用シーンや課題の洗い出し
- 既に提供しているがあまり有効に活用されていない機能に対して、普段使っている時の様子を普段使っている端末から再現してもらったり代替手段を教えてもらったりして、どこに問題があるのか（UIの問題なのかそもそもの課題設定が間違っているのか）確認した
目的によってインタビューのやり方も、誰を何人呼んで何を聞くかも、全てが変わってきます。1回のインタビューで2つ以上の目的を持つこともありますが、その場合は優先順位を付けるなど、目的をより明確にする必要があります。
グループインタビューと個別インタビュー
目的が明確になったら、実際にインタビューを設計していきます。インタビューは複数人一緒に話を聞くグループインタビューと、1人ずつ話を聞く個別インタビューがあります。
インタビューというのは聞き手（インタビュアー）が質問して、受け手（インタビュイー）が答えるというのが基本のやりとりですが、そうするとインタビュアーが質問したことしか聞き出すことができません。つまり、聞けることがインタビュアーが知っている範囲に留まります。例えばおじさんのインタビュアーが学生にインタビューしているところを想像してみてください。学校で何が流行っているのか、学生たちの間で起きている独自の文化をその外側から、外側の社会の言葉を駆使して聞き出すのは困難です。
そういう時にはグループインタビューが役立ちます。インタビュアーが「最近何が学校で流行ってますか？」とグループに向かって一石を投じると、参加者の間で「あれが流行ってるよね」とか「あれまじ楽しいよな」とか、自由に話し始めることがあるのです。参加者同士で通じる世界観の中で自由に会話してもらい、その様子を観察させてもらうという方法が有効に働くことがあります。
一方、グループインタビューでは同調圧力が強く働きます。みんなが良いと言っているものに対して、1人だけ異を唱えるのは勇気がいります。そしてインタビューの場でそんな勇気を発揮できる人は少数です。何となくインタビュアーが振った話題に同意してみたり、グループのみんなの意見に賛成してしまうことがよく起こります。そういう場合は1人ずつ個別に話を聞く方が良い。
グループインタビューも個別インタビューも一長一短があるので、私は可能なら両方一緒にやっています。例えばユーザーさん5人に集まってもらって、最初にグループインタビューをしてから、個別に1人ずつインタビューをする。個別インタビューでは「さっきこう仰ってましたけどどうですか、自分が実際に使っているところのイメージ湧きますか」という感じで、深堀していきます。これを人数分繰り返していくわけです。
この方法には個別インタビューを待っている残りのメンバー間で雑談が発生しやすいという利点もあります。インタビューですから緊張してなかなかスムーズに話せない方も多い。そういう方でも、一旦インタビューはここで終わりです、個別にお話を聞かせていただくまで自由時間ですと言って、みんなでお茶を飲んだりお菓子を食べたりしていると、自然とさっきはこうだったよねとか話し始めてくれることがあります。個別インタビューを行うインタビュアーとは別の担当者を待合室に配置して、それとなく話を振ってみるのも効果的です。
リクルーティング
インタビューの方法が決まったら、参加してくれる方を探して参加を依頼します。いわゆるリクルーティングです。既存サービスの課題を洗い出すのが目的ならサービスの利用者から、新サービス立ち上げ時のニーズの調査ならユーザーになってもらえそうな属性の人から参加してくれる人を探します。
サービスの利用者を対象したケースの方がアプローチが楽です。よくやるのは、まず最初にアンケートをとる方法。サービスの利用者にインタビューする場合、特にこういう属性の人に聞きたいという指定があることが多いです。例えば週N回以上投稿しているヘビーユーザーとか、一度も投稿したことがないけど毎日訪問している閲覧者とか。そうした属性の指定がある場合に、まず最初にユーザーアンケートを行なって普段の利用状況を質問して、最後にインタビューに参加してもらえるかどうかを聞きます。あとはアンケート結果の中から、該当する条件を満たしていてインタビュー参加OKの方に直接メール等で連絡をして日程の調整をしていきます。
サービス立ち上げ前や、サービスを使ったことがない人を対象にしたインタビューではリクルーティングに苦労すると思います。お金をかけられるならリサーチ会社に希望する属性の人を集めてもらうといいのでしょうが、立ち上げ前だと予算がついてないことも多く、何より気軽に行うことができません。そもそもターゲットユーザーが探せないとなると、実際にサービスを立ち上げた時にどうやってアーリーアダプターを獲得したらいいかわからなくて困ります。だから苦労してでも、なるべく自分の足で探すのが良いでしょう。
これは昔、スターバックスで学生さんに声をかけてインタビューした時の写真です。さすがにいきなり知らない人に声をかけるのは恥ずかしくてもうやりたくないけど、この頃はまだ若くて度胸がありました。他にはユーザーさんにお願いして、まだサービスを使っていないご家族の方を連れてきていただいたこともありました。いろんな工夫をしながらユーザーさんを探すその経験自体が、後の獲得フェーズでも活きてくると思います。
質問表を作っておく
インタビューの形式や参加者が決まったら、あとは実際にインタビューといきたいところですが、事前に準備しておくことはまだまだあります。1つは質問表を作っておくことです。
インタビューは個別の場合、インタビュアーと書記の2名でやることが多いです。インタビュイーの方にご同意いただければ、会話を録音しておいて後から書き起こしても良いのですが、例えばその場で見せた表情や仕草など、録音データに残らない情報もあります。そうした言語外の情報も書き残しておけるように、インタビュアーとは別に書記を用意してインタビュー中にリアルタイムで記入していってもらいます。
その記入用のシートが質問表です。いつもGoogleスプレッドシートで作っています。あらかじめ聞きたいことを洗い出しておいて、書記の人にはインタビューを聞きながら該当する項目にメモをとっていってもらいます。もちろん質問表にないことも聞きます。インタビューで盛り上がって脇道に逸れることも結構あるので、その場合は欄外にメモしていってもらえば良いです。
インタビュー中はインタビュアーも書記も、同じシートを見ながら進めます。そうするとインタビュアーがこの辺りは情報が薄いから掘り下げようとか、インタビュー中に軌道修正しやすいのです。そうして質問表を書記がリアルタイムで埋めていき、インタビュアーも後から補足があったら追記します。
インタビュー中に気を付けること
インタビュー中、質問するときに気を付けるべきこともあります。それはあんまり直接的な質問に頼りすぎないということです。
直接的な質問とは、例えばとある企画へのユーザさんの反応が知りたい時にする「これ使ってみたいですか」という質問です。聞いてもいいんですけど、その質問に頼りすぎると思わぬ落とし穴にハマることがあります。それはインタビュアーをがっかりさせたくない、相手に直接ネガティブなことを言いにくいというバイアスです。それほど使ってみたいと思ってなくても、開発者でもあるインタビュアーを喜ばせようと、使ってみたいと答える人も多いのです。
そういう場合には「実際に使うとしたらいつどんな時に使いますか」というような、具体的な利用シーンを聞くような質問をするといいです。自分だったら生活の中のこういう場面でこんなふうに使うと、具体的にイメージできていたら実際に使ってもらえる可能性が高いでしょう。逆に何となく具体性のない回答が帰ってくる場合は、相手に価値が伝わっていないか、価値を感じてもらえていないかのどちらかだと思います。
インタビューの後にやること
インタビューが終わったら、インタビューに参加したスタッフ全員で感想戦を行います。インタビューを行った直後というのは、一番ホットな感覚が残っている時です。その記憶が薄れる前に、1人ずつインタビューの感想を言葉にして他人と共有しましょう。言語化しておくというのがポイントです。自分が得た大量の情報の中からエッセンスを抽出して他の人でも理解可能な状態にするその工程が、ユーザー理解そのものだからです。
感想戦が終わったら、最後に主な質問を縦軸に、インタビュイーを横軸にしたマトリックス状の一覧表を作ります。インタビュー中はふとした仕草さ表情など得られた情報は何でもメモしていきますが、最終的にはある程度言語化した回答のまとめを作っておかないと、後から参照したときに大変です。インタビューに参加していない開発メンバーにもわかりやすいように情報をまとめておけば、開発チームの共通言語として使えるようになります。インタビューの時にあのユーザーさんがこんなことを言ってたよね。そういう会話がチームの中で共有できる状態になっていることが理想です。
ユーザーインタビュー、実際にやろうとするとコストもかかるし大変です。私は何度やっても終わった後に全身の活力を全て使い切って抜け殻みたいになります。それでもユーザーさんの直接の声を定期的に受け取りながら、定性と定量の両輪でサービスの企画を進めていくべきだと思い、歯を食いしばってやっています。
