調査
要点
この段階は、ユーザーの利用文脈を理解し、提供するユーザー体験の手がかりを見つける段階です。
エンジニアの仕事で言うと、ここの段階ってなんていうのかよく分かりません。強いて言うなら、「開発依頼」の段階です。社内外から企画が上がってきてその詳細を聞いたり、それに合ったライブラリーないかググって github の README かどこかの開発ブログを読んでる段階だと思います。
注意が必要なのが、この調査段階はとても重要で何度もやり直せる段階ではないということです。エンジニアにとって、 github の README や開発ブログを読むことは何度もできるし、詳しく知りたくなったら更に調べ直せます。
しかし、 UXD の調査はしっかり目的と準備を持ってやらないとほとんど意味ないデータが集まります。この調査の段階から失敗すると後のプロセスで正確な分析や設計ができなくなります。その上、調査には時間がかかるので「もう一回！」みたいな感じで簡単にやり直せないのも大変な要素です。
とは言いつつも、まあ、失敗したら戻ってくれば良いことです。 UXD はリーン開発のように間違ったところに立ち返ってやり直すアプローチです。失敗してもいいから、とりあえずやってみるのも大事だと思います。
この章の残りは下記の点を詳細に書きます。
- 対象者の選定
- 調査手法の選定
- リサーチガイドの設計
- インタビューログの作成
対象者の選定
調査の目的に合うように、調査対象の態度、行動、心情を考慮してして対象者を選定します。
ここで注意なのが、調査対象は性別、年齢、職業などの属性で選定しません。一番重要なのは、調査対象の定性的な内面です。いくら特定の属性を満たしていたからと言って、行動や調査対象への心情が違えば、おそらくデザインしようとしているサービスのユーザーではないです。対象者が限られているの場合や、ゼロベースから価値を発見したい場合は属性で判断しても良いと思います。しかし、調査の目的が決まっているのなら、安易で分かりやすい属性で選定するのは良い方法とは言えません。
まずは、目的に合った調査対象の条件を決めてから、調査対象をリクルーティングしていく必要があります。
また、ゼロベースでより多くのインサイトを得るために SEPIA 法で対象ユーザーを分類して、それぞれの分類から一人ずつ選定する方法があリます。これは予めアンケートに答えてもらい、その結果をもとにセグメント分けをして、各セグメントから１~２をインタビューするという方法です。この方法は、先述した方法とは違い、定量的調査対象を選定していく方法です。
この方法は、勉強しましたがやったことないので、詳しい説明は SEPIA 法の第一人者の方のスライドシェアに譲りたいと思います。
調査手法の選定
正確な調査方法の選定には、認知科学の知識が必要です。具体的に言うと、調査対象の認知の相互作用の必要有無が判断軸になります。
例えば、自転車の乗り方のように体で覚えてしまった行動というのは言葉で表現しにくいです。このような行動をボトムアップ処理と言います。逆に、頭のなかで情報処理した行動をトップダウン処理と言います。ボトムアップ処理を無理矢理言葉にしたり、思い出させようとすると調査対象の都合の良い解釈または想像で答えられてしまうことがあります。このようなことを認知的不協和といいます。この認知的不協和は調査結果のノイズになるのでできるだけ減らしたいです。
そのために、主な手法として特徴の異なった下記の3つ挙げられます。
- エスノグラフィ（行動観察）
- 実際にユーザーの行動を見て利用文脈やニーズを見つける手法
- 体で覚えた行動（ボトムアップ処理）と記憶（トップダウン処理）の相互作用が見れる
- 日記調査
- ユーザーに特定の状況の後で、1日10分〜15分ぐらいの日記を書いてもらう手法
- 特定の文脈の中で思い出す記憶を見つけることができる
- 主にデプスインタビューの補助にする狙い
- デプスインタビュー
- ユーザーにインタビューして利用文脈とニーズを見つける手法
- ボトムアップ処理ができない
- 記憶（トップダウン処理）に頼るため
トップダウン処理とボトムアップ処理の相互作用が必要な時は行動観察が必要になります。しかし、状況によってはエスノグラフィができない時もある。そこで、デプスインタビューに日記調査を組み合わせてボトムアップ処理の記憶を補う方法が使われることがあります。
また、それぞれの手法で調査設計の留意点が異なります。
- エスノグラフィ調査
- 何を観るかが重要になる
- 調査対象のボトムアップ処理を理解する観察力が必要になる
- その時の、観察ポイントだったり記録方法や役割分担を予めに設計しておく必要がある
- 日記調査
- 何を報告してもらうかが重要になる
- 基本的に毎日報告する日記を書いてもらう
- 難しいタスクだったり、冗長なタスクを課した場合に適当な日記を書かれてしまう
- 10分〜15分程度で飽きさせないようなものほ報告してもらう設計をする
- デプスインタビュー
- 何をきくかが重要になる
- インタビュー相手をコントロールできるインタビューガイド（チェックリスト）の設計
- インタビュー相手との場作りが早くできるように気を配る
- 自分の用意したインタビューガイドを満たせるようにタイムマネジメントをする
- オープンクエスチョンで問いかける
エンジニア的に言うと、コードをどうしたら良い分からなくて誰かに質問した時、「見せたほうが早いわ。モブプロで一緒にやろう。」って時がエスノグラフィです。見せて教えたり、理解してもらう時がエスノグラフィの使い所です。
ただ、ほとんどの場合は「github でコメントするよ。」とか、「あー、それは〇〇だよ。」みたいに説明できます。質問の仕方が正しかったらより多くの学びもあると思います。なので、ほとんどの場合はデプスインタビューで大丈夫だと思います。
仮に認知的不協和でノイズが入ったとしても、「これ、ノイズかも？」と分かるようにインタビューを訓練した方が最初は早いと思います。そのぐらい、エスノグラフィで対象のボトムアップ処理を理解するのは難しいです。
リサーチガイドの設計
最も基礎的なデプスインタビューのリサーチガイドを説明します。
僕の問の流れとしては下記の３つです。
- 背景情報を知るための問
- インタビュー相手の人となりを知り、生活をイメージする
- 今とそこに至るまでの来歴を知るための問
- 現在はどんな方法を取っているのかを知るのと同時に理由を確認する
- 以前はどんな方法をとっていたのかを知るのと同時に変遷の理由を確認する
- 未来へ向けたニーズを探る問
- 今感じている不満や物足りなさを探る
- インタビューアーの中の仮説を投げかけて反応をみる
1の問は主にインタビュー相手との場作りと、後の分析のペルソナ作成の時に役立ちます。2, 3の問は具体的に調査の中身を伺う問です。これは、後の分析の価値マップ作成の時に役立ちます。
インタビュー内では、主に「昔と比べて今はどうしているのか？」や「今はできてないけど本当はどうしたいのか？」などギャップを見つける作業になります。ここで重要なのは、このギャップを埋める行動は「本質的ニーズ」ではなく、「手段」であるということです。「本質的ニーズ」とは、「本当にやりたいこと」、「本当の目的」みたいなもの（意図）です。それを、達成するためにインタビュー相手は十人十色の「手段」を用いています。
インタビューとは、「手段」（行動）を発見してくるものだと勘違いされますが、これは大きな間違いです。本当のインタビューの目的は「本質的ニーズ」（意図）を発見してくるものです。
この目的を発見するためにインタビューアーは、下記の点に注意する必要があります。
- インタビュー相手の行動とその意図が分かるように質問を設計する
- 深掘りできるようにオープンクエスチョンで質問する
- インタビューアーの想像に誘導しないようにインタビュー相手の解答を待つ
- インタビューアーが想像もしない「手段」をインタビュー相手が実行している場合があるので、質問範囲をバイアスにとらわれないようにする
- インタビューアーがインタビュー相手の言葉を汲み取ろうとしすぎない
最後の項目だけ少し補足すると、この行為は本当のユーザーの声を潰してしまっていることに等しいです。
エンジニアをやっていると、すぐに話しの要点をまとめたくなってしまうと思います。（僕だけかもしれません。。。）
この性質はインタビューするに当たっては物凄く悪いです。必ずユーザーの声を最後まで聞くように心がけてください。
僕はインタビューガイドをスプレッドシートで管理しています。そのサンプルのキャプチャーを貼っておきます。これは、授業で会議についてのインタビューをした時のものです。（差し障りのない部分のキャプチャーなのであまり参考にならないかもしれないです。。。）
キャプチャーのインタビューガイドを作るにあたっての僕なりの簡単なテクニックは下記です。
- 全体通し番号を入れる
- インタビューの時間経過と自分のインタビューの進行速度を比較しやすい
- 必須質問に印をつけてフィルターできるようにする
- 時間がなくなった時に大事なことだけは聞き逃さないようにできる
- 質問したいことの目的を書く
- インタビュー相手が質問の目的と違う答えを返してきた時にすぐ気づける
- 質問例はインタビューの流れで臨機応変に聞き分けられるように複数用意しておく
- インタビューは会話なので、いきなり会話の流れから外れた質問を投げかけないで済む
インタビューログの作成
インタビューログとは、インタビュー結果の書き起こしです。これは、次の分析の際にとても重要になります。
インタビュー結果を書き起こしをしますがこれがめちゃめちゃ疲れます。基本的には会話をそのままログにおこします。言葉使いもそのまま、話しの中に矛盾があったとしても、語尾が消えてても、インタビュアーの質問もそのままです。
「書類」ではないので、読みやすさよりも、インタビュアーとインタビュー相手のキャラクターや、その場の雰囲気といった行間が伝わる「ログ」にすることを心がけてください。まとめる、省略するといった解釈を加えず、生々しいものを作ることができると成功です。その中で最低限、「えー」「あー」や「えーと」といった意味のないものはケバとしてとってしまって問題ないです。逆に、例えばインタビュー相手が悩んでいるときの「えーーー」とかは悩んでいる雰囲気が伝わるので、意味のある情報として残したりもします。
あわせて読みたい
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 導入編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 調査編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 分析編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 製作編
- エンジニアによるエンジニアのための UX デザイン開発実践ガイド 検証編
