ユーザーリサーチとインタビュー

ユーザーインタビューとは何か。誰に何を聞き、発言をどう課題に変えるか

1対1で話を聞き、行動の理由を掘る定性調査です。人数の目安が記事ごとに違うのは、5人という数字がユーザビリティテスト、6件から12件がインタビューの飽和研究と、出どころが別だからです。逐語からコード化を経て課題文に落とすまでの手順も書いています。

話は聞いた。1人1時間、5人分の録音と文字起こしがある。それでも次の会議で出てくるのは「使いにくいという声がありました」の1行で、何を作るかは決まらない。

ユーザーインタビューは、1対1または少人数で話を聞き、行動の背景にある理由を掘る定性調査です。人数の目安を調べると、記事ごとに違う数字が並びます。5人、6人、12件、セグメントごとに5〜8人。

食い違うのは、根拠にしている研究が別物だからです。5人という数字と、6件から12件という数字は、それぞれ違うものを測っています。

ユーザーインタビューで確かめられること

確かめられるのは「何人がそう思っているか」ではなく「なぜそうしたか」です。大手調査会社のマクロミルは、デプスインタビューを1対1で時間をかけて深層心理やインサイトを引き出す定性調査と定義し、数値や統計を捉える定量調査との違いを、行動の背景にある感情や価値観に迫れる点に置いています。定性と定量を対比させるこの説明は、日本語の解説記事でほぼ共通しています。

使い分けは、知りたいものが割合なのか理由なのかで決まります。この機能を使っている人が全体の何割かは、アンケートで測るものです。なぜ使わなかったのか、代わりに何をしたのかは、聞かないと出てきません。

ここを取り違えると、インタビューの結果を「5人中3人が言っていました」と割合の形で報告することになります。母数5人の6割は、割合として使える数字ではありません。同じ発言が3人から出たことに意味があるとすれば、それは割合ではなく、その3人が似た状況に置かれていたという構造の方です。

「5人で足りる」の5人は、何を測った数字か

ユーザビリティテストの数字です。インタビューの飽和を測った数字ではありません。

Nielsen の5人はタスクのつまずきを数えている

起点は、Jakob Nielsen が2000年3月18日に公開した記事です。5人でテストすればユーザビリティ問題の約85%が見つかるという主張で、Nielsen が Tom Landauer と開発した数学モデルに基づいています。典型的な発見率を31%とする式です。

ここでのテストは、参加者に画面上のタスクをやってもらい、どこでつまずくかを観察する行為を指します。話を聞いて行動の背景を掘る行為とは、測っている対象が違います。

Nielsen Norman Group 自身が、後の記事で線を引いています。Raluca Budiu が2021年7月11日に、5人ルールは形成的なユーザビリティ評価に当てはまるもので、行動を予測する定量調査には当てはまらない、定量なら40人以上の参加者が要る、と書いています。

インタビュー自体の飽和は6件から12件

ユーザーインタビューそのものの飽和を測った研究は、別にあります。Guest、Bunce、Johnson が2006年に査読誌 Field Methods に発表した論文は、西アフリカ2か国の女性60人への詳細インタビューを分析し、テーマの基本要素は6件目までに出そろい、飽和は12件目までに生じたと報告しています。

NN/g は2021年10月31日の解説記事でこの結果を紹介しています。出現頻度の高いコードは全部で36個作られ、そのうち34個は6人分の発言録を分析した時点で追加されたもの、12人分の分析後で35個、という数え方です。日本語版は2022年5月11日に U-Site で公開されました。同じ記事は、万能の黄金率は無いこと、5〜6人程度の小さいサンプルから始めて分析しながら進めることも書いています。

なぜ記事ごとに数字が違うのか

同じ「5人」に出どころが2つあり、日本語記事では両方が同じ文脈に並ぶことがあるからです。

あるUI/UXデザイン会社の解説記事は、5〜6人にインタビューすればある程度の傾向が分かるとし、根拠として Nielsen のユーザビリティテスト研究と、樽本徹也『UXリサーチの道具箱』を挙げています。インタビュー施設を運営する会社の記事は、デプスインタビューで1セグメントあたり5〜8人、グループインタビューで4〜5人という目安を示し、Nielsen の研究引用と実務経験を組み合わせています。後者はセグメントの数だけ必要な件数が増えるという説明を加えていて、これは他の記事にあまり見当たらない視点です。

人数の目安を読むときは、数字より先に、それが何を測った研究から来ているかを見ることになります。組み立てるなら、セグメントごとに6件を最初の目標に置き、6件目でまだ新しい話が出続けているなら12件まで伸ばす。分析しながら進めて、新しいコードが出なくなったところで止める。

誰に聞くか

必要な件数はセグメントの数だけ積み上がるので、聞く相手の区切りを先に決めます。区切りを増やすほど総件数が増える。6件を目標に置くなら、区切りの方を絞ることになります。

Nue のプロダクト開発支援では、実際に使っている人と、使っていない人の両方に話を聞く設計にしています。やめた理由や、そもそも候補に入らなかった理由は、使っていない人の側からしか出てきません。インタビューは、この4週間のうち課題整理につながる工程の1つです。全体の進め方はプロダクトディスカバリーとは何かの記事に書きました。

誰に何を聞くかは、人が設計します。ここを機械に任せると、答えやすい質問ばかりが並んで、聞くべきことが抜けるからです。

意見ではなく行動を聞く

感想しか集まらないインタビューは、質問が意見と未来を聞く形になっています。

この整理を広めたのは The Mom Test(Rob Fitzpatrick、2013年9月に自費出版)です。意見や未来の仮定を聞く質問を避け、過去の具体的な行動を聞く質問に置き換えることを提唱しています。

「この機能があったら使いますか」は、未来の仮定を聞いています。相手は善意で「使うと思います」と答えます。置き換えると、前回それをやったのはいつか、そのとき実際に何をしたか、を聞く形になります。答えが出てこなければ、その行動は起きていません。

誘導を避けるだけでは足りません。誘導していない意見も、やはり意見です。

発言を課題に変える3つの工程

録音から課題文までは、逐語で残す、コード化する、課題文に落とす、の順に進みます。

1. 逐語で残す

発言は要約せずに残します。要約した時点で聞き手の解釈が混ざり、あとから戻れなくなる。「操作が分かりにくいそうです」と書いた1行からは、その人がどの画面で何をしようとしていたかを復元できません。

書き起こしはAIで速くなる工程です。

2. コード化する

逐語のうち、行動と状況が書かれている部分を切り出し、短いラベルを付けます。このラベルがコードです。36個中34個が6人分で出そろった、という数え方は、発言の数ではなくコードの数を数えています。増え方が鈍ったかどうかを見るので、6件目で打ち切れるという意味ではありません。

飽和の判定も、この単位で行います。何人に聞いたかではなく、新しいコードが出なくなったかどうか。7人目でまだ5つ増えるなら、足りていません。

ラベルを束ねる手法として日本語記事に頻出するのがKJ法です。文化人類学者の川喜田二郎が考案し、1967年の著書『発想法』(中公新書)で広く知られるようになりました。手順はラベル集め、表札づくり、図解化、叙述化の4段階です。

止まりやすいのは図解化です。付箋が島に分かれた写真が成果物になって、そこで終わる。KJ法の手順は叙述化、つまり文章にするところまで含みます。分類の絵は、読める文章の代わりにはなりません。

一次分類はAIで速くなります。ただし機械が付けたラベルは、発言の表面の語に引きずられます。「使いにくい」と言った3人を1つの島にまとめても、つまずいた場所が3人とも別なら、その島は分けるべきものです。

3. 課題文に落とす

ここが山です。事実の羅列から「何が問題か」を立ち上げる工程で、Nue はここを人が担う範囲として切り分けています。

決まった書式があるわけではありません。ただ、次の5つが入っていると、あとから検証できる形になります。

  • 誰が。属性ではなく、その人が置かれていた立場で書く
  • どんな状況で。頻度と時間帯まで分かっているなら入れる
  • 何をしようとして
  • 何に阻まれたか
  • いまどう回避しているか

効いてくるのは最後の回避策です。手間を払ってでも回り道をしていたなら、その人には達成したい目的があったことになります。回避策が出てこない不満は、言っただけの可能性が残ります。

「操作が分かりにくい」という発言そのものは、課題ではありません。どの画面で、何をしようとして、代わりに何をしたか。行動の記述まで戻せた発言だけが、課題文の材料になります。

解決策は課題文に書きません。「〜する機能が必要」と書いた時点で、他の解き方が見えなくなります。

どこまで機械に渡せるか

Nue の プロダクト開発支援 では、書き起こしと一次分類をAIで圧縮し、誰に何を聞くかの設計と課題整理は人が担う、という切り分けにしています。境目にあるのは、材料が手元に揃っているかどうかです。

分類は、目の前にある発言を並べ替える作業なので機械が速い。課題文を書く方は、発言に書かれていないものを補って判断する工程です。足りない部分を機械に埋めさせると、それらしい課題文が出てきます。それらしいものは、外れていても気づけません。

短縮幅を主張するなら、着手前に現状を測っておく必要があります。何時間かかっているかを記録していないまま始めると、速くなった実感は残っても、何が効いたかは後から言えません。この話は生成AIのPoCが本番に行かない理由でも書きました。

向いていないとき

  • 割合を知りたいとき。何割の人がそう感じているかは、インタビューでは出ません。行動を予測する定量調査には40人以上の参加者が要る、というのが NN/g の線引きです
  • その行動がまだ存在しないとき。過去の行動を聞く形に置き換えられず、質問が未来の仮定に戻ります。いま代わりに何をしているかを聞く方に切り替えることになります
  • 画面のどこでつまずくかを知りたいとき。それはユーザビリティテストの仕事です。話を聞くのではなく、タスクをやってもらって観察する
  • 聞いたあとに誰が何を決めるかが決まっていないとき。決める予定のないインタビューからは、感想しか残りません

人数の目安を探しているなら、見る先は他社の記事ではなく、手元のコードの増え方です。6件目で新しいコードが出なくなっていれば、そこが飽和です。