コンテキストインタビュー：
ユーザーのコンテキストで彼らを観察・インタビューし、デザインのヒントを得よう
観察とその結果の解釈をユーザーと協力して行うことを通して、コンテキストインタビューは、顧客の作業に関して他の調査方法では得られない、隠れた知見を明らかにする。
我々が提供するUX調査手法のメニューに、コンテキストインタビューは欠かせない。
コンテキストインタビュー（contextual inquiry）は、民族誌学で行うフィールド調査の1つで、小サンプルのユーザーの徹底的な観察とインタビューにより、ユーザーの作業のやり方と行動をしっかり理解しようとするものだ。この名称は、コンテキストインタビューを価値のあるものにしている特徴、つまり、「コンテキスト（利用状況）の中での質問」を正確に説明したものである：
- コンテキスト（context）：調査は、ユーザーが通常どおりに作業しているときに彼らの普段の環境で行われる。そうしたコンテキストは、彼らの自宅のこともあれば、オフィス、またはまったくそれ以外の場所のこともある。
- 質問（inquiry）：リサーチャーは、ユーザーがタスクを実行しているところを観察し、どのように、そして、なぜユーザーがそういう行動を取るのかを理解するために情報を聞き出す。
コンテキストインタビューは多くの領域で有用だが、とりわけ、複雑なシステムや綿密なプロセスに対するユーザーのインタラクション、また、エキスパートユーザーの視点などを理解するのに適している。
コンテキストインタビューを行う理由
通常、コンテキストインタビューは、新しい機能や製品の初期の発見のステージで行う。なぜならば、この調査のデータは、要件やペルソナ、機能、アーキテクチャ、コンテンツ戦略などのデザインの選択肢を具体化するのに非常に重要だからだ。
コンテキストインタビュー法は、Hugh BeyerとKaren Holtzblattによって、アンケートや（訳注：従来型の）インタビューなどの他の定性調査の手法の欠点を解決する方法として開発された。これらの定性手法は、ユーザーが調査の瞬間には実行していないプロセスを再生して説明する能力に依存している。ユーザーは自分のプロセスを要約しようとするが、そうする根拠や動機、根底にあるメンタルモデルなどの重要な詳細情報はこの要約では省かれる。そのため、リサーチャーは、ユーザーのその作業への取り組み方を表面的にしか理解できない。
しかし、ユーザーはその作業を実行している「最中」であれば、自分が今、何をなぜ行っているのかを容易に話すことができる。このため、コンテキストインタビューは、ユーザーがどのようにプロセスを完了するかについて、自己報告やラボベースの調査方法よりも、豊富で関連性の高い情報を提供することが可能なのである。
この手法の最大の強みの1つは、予期していなかったことを確認したり、習慣化されて無視されるようになっていた下位レベルの詳細情報を明らかにできることだ。UXデザインの作業に直接影響を及ぼす中断や迷信的な行動、非論理的なプロセスを目の当たりにできることだろう。
私は、以前、自動車保険の契約書作成用のソフトウェアツールのデータ入力部分のデザイン変更をしたことがある。そのとき、私は、まず、複数の担当者に、商用車の全車両データをそのソフトウェアにどのように入力しているのかをインタビューした。私がインタビューした担当者全員が、車両データの大量のバッチをスプレッドシートからコピーし、ソフトウェアインタフェース内のデータテーブルに貼り付けていると説明してくれた。それから、私はこの担当者のうちの何人かのところに行って、彼らがこのプロセスを行っているところを観察し、インタビューをした。すると、彼らのプロセスには彼らが言及していなかったステップが他にもいくつかあることがわかった。また、彼らは別のソフトウェアツールの画面も相互参照して、車両ごとに入力しなければならない、いくつかの関連情報を取得していた。その上、彼らはデータを1つ1つ手動で入力するたびに、習慣的に「保存」ボタンを押していた。プログラムが進行状況を自動保存しているにもかかわらず、だ。データが自動保存されることを認識していなかった人もいれば、自動保存を信頼していない人もいた。この2つの知見はどちらも、新しいツールのデザインに影響を与える非常に重要なものだった。
コンテキストインタビューが有用でない場合とは
コンテキストインタビューは、ユーザーの詳細な思考プロセスと彼らの作業の基本構造を理解するのに役立つようにデザインされている。このため、eコマースの商品ページのデザイン変更やWebサイトのニュースレターの登録フォームのテストのような、対象が絞られたデザインタスクには特に有用というわけではない。こうしたインタフェースはかなり単純だからだ。つまり、一般に、この種のインタフェースでは、デザインのためにUXの専門家が理解しなければならないような詳細な思考プロセスや基礎知識は必要とされない。
そうはいっても、ユーザーの一般的な行動を理解するために、彼らが体験するところを観察するのが役に立つ場合もある。しかし、インタビューの要素を追加しなければならない可能性は低く、ほとんどの場合は直接観察に頼ることになるだろう。直接観察はコンテキストインタビューに似ている。だが、そこではリサーチャーはたいてい黙ってユーザーの行動を観察し、プロセスへの干渉は最小限にとどめる。また、直接観察は、医師や航空管制官など、参加者が作業を中断したり、作業中に気を散らしたりできない場合に最適なフィールド調査でもある。とはいえ、こうした場合には、後で明確化のためのフォローアップ質問をする必要があるかもしれない。
コンテキストインタビューの実施方法
コンテキストインタビュー法では、参加者とリサーチャーのやり取りのモデルとして、師匠と弟子の関係を用いる。現在では、徒弟制度は以前ほど一般的ではないが、この概念は今もそれなりに通用するし、イメージがわくからだ。やってみせることによって、師匠が弟子に教えるように、リサーチャー（“弟子”）は、ユーザー（“師匠”）を観察し、質問することによって、ユーザーのタスクについて学ぶということだ。
4つの基本原則
コンテキストインタビューは、師匠と弟子モデルを、リサーチャーが自分の製品や仕事のコンテキストに合わせて調整し適用するのに役立つ4つの原則に基づいている。
- コンテキスト。リサーチャーは、ユーザーの普段の環境で観察を行う必要がある。職人が教室で技術を教えるために話のポイントをまとめておいたりはしないのと同じように、リサーチャーは、ラボや会議室のような環境は避けて、ユーザーが通常、作業をしている場所で調査を実施すべきである。
- 協力関係。ユーザーとリサーチャーは、ユーザーの作業を理解するというプロセスにおけるパートナーだ。したがって、リサーチャーは、セッション全体や議論の内容をコントロールしてはならない。両者はともに、検討する必要のあるものに向けて自由に会話を進めることができるべきである。
- 解釈。リサーチャーは、ユーザーからのフィードバックを受けて、作業のすべての重要な側面について両者で共有できる包括的な解釈を作成する必要がある。
- 焦点。リサーチャーは、調査プロジェクトの目的とどのような情報を求めるべきかを理解しておく必要がある。この理解がセッション中の観察とインタビューの指針となる。
4つのパートからなるセッション
理解する必要がある分野においてその人にしかできないことがあり、知識の豊富な参加者を選び出そう。そして、以下の4つのパートからなる構成をテンプレートとし、コンテキストインタビューに取り組む際の指針としよう。
1. 下準備
下準備の意図は、参加者にセッションにスムーズに入ってもらうことにある。気楽な感じで始めることで、参加者はあなたに打ち解け、セッションでどんなことが行われるかを知ることができる。
- 自己紹介をしたら、最初に少し時間をとって、参加者と信頼関係を築こう。
- このインタビューに期待している成果と、セッションの中で自分が誤った解釈をしたら訂正してほしいということを言おう。
- 守秘義務について説明し、撮影や録音を行う場合は承認を得よう。
- 興味のあるテーマから話しはじめよう。決められた時間内に行う作業の概要を尋ね、関連するすべての意見を聞き出そう。しかし、記憶というのは完全に正確であるとは限らないので、そうした意見や説明が正確であるかどうかをリサーチャー自身の観察によって確認するようにしよう。
2. 移行
導入と一般的なインタビューが終わったら、セッションのコンテキストインタビュー部分に移行することを表明しよう。一旦中断して、この後、セッションはどうなるのかということと、リサーチャーがしなければならないことを説明しよう：
- 参加者がいつものように作業をしているところを見ること、そこで興味が湧いて聞きたいことが出てきたら声をかけることになることを伝えよう。
- 参加者が声をかけられたときのタイミングが作業を中断するには良くなかった場合は、それをリサーチャーに教えてもらえれば、切りが良いところまで作業を続けてもよい。
この重要な手順を飛ばしてはならない。このステップを飛ばすと、ユーザーがインタビューモードのまま、進んでしまうことになる。ユーザーには、この後、今までとは違う種類のやり取りに集中してもらう必要がある。
3. コンテキストインタビュー
このフェーズは、通常、以下の2ステップのパターンを何度も反復することになる：
- 見て、知る。
- すぐに理解できない操作をユーザーがした場合や、リサーチャーの解釈を確認したい場合は、ユーザーに作業を中断してもらって、議論を始める。
インタビューは、作業の時間と議論の時間を繰り返すことで自らリズムを取るようになる。ここでの基本となる以下のプロセスの理解に努めてほしい：
- 外部のリソースが使われていないかを確認しよう。
- プロセスの標準的なステップと、それ以外の一般的ではないバリエーション、および、その両者が存在する理由について尋ねよう。
- タスクとワークフローの解釈を説明して、ユーザーに確認または訂正してもらおう。
議論を切り出す必要があるのは、以下の2つの理由のときである：
- 観察していて理解できないことがあった場合。この場合には、自由回答式の質問をして、参加者にその行動をとった理由を詳しく説明してもらおう。
- ユーザーのメンタルモデルに対する自分の理解の正誤を参加者に確認してもらうために。コンテキストインタビューの目標の1つが、プロセスに関する参加者のメンタルモデルを明らかにすることだ。したがって、今回のプロセスのメンタルモデルに対してそれなりに強力な仮説を立てることができたと思ったら、参加者に自分の理解を確認または訂正するための意見をもらおう。
たとえば、あるユーザーが2つのモニターを使っていて、いくつかのウィンドウを片方のモニターから別のモニターに移していたとしたら、まずはその理由を説明してもらおう。すると、ユーザーの説明から、ある種のウィンドウは常に特定のモニターに表示される必要がある、といった、ユーザーの根拠の背後にある構造を無理なく示す仮説を立てることができる。そして、仮説を検証するために、「では、ノートブックのモニターはコミュニケーション専用で、大画面は作業用ですか」と質問してみよう。すると、ユーザーはあなたの仮説を支持したり、「むしろ、モニターする必要があるもの（Eメール、Slack、株価表示）はすべて、ノートブックの画面に表示し、作業中のタスクを大画面に表示したいと思っています」と言って、あなたの推測を訂正してくれたりするだろう。
このフェーズで参加者に解釈を検証してもらう頻度については、慎重に考慮する必要がある。参加者のこの後の行動にバイアスをかけてしまう可能性があるからだ。次のラップアップのフェーズには、すべての解釈について議論する時間が設けられている。
4. ラップアップ
最後に：
- インタビューの結果を明確にするための最終的な質問をしよう。
- メモを見直して、観察したプロセスに対するリサーチャー自身の解釈を説明することによって、インタビューから得たものを要約しよう。これは、ユーザーに作業の説明をしてもらう最後の機会でもあり、彼らにリサーチャーの理解を訂正してもらえる機会でもある。
コンテキストインタビューのセッションに必要な時間は、理解しようとしている作業の範囲によって異なる。観察とインタビューが1～2時間で終わる場合から、数日間にわたる場合まで、その期間は様々である。
リスクと欠点
どんな手法にも、注意すべき潜在的なリスクと欠点がある。コンテキストインタビューも例外ではない。コンテキストインタビューを実施する際に回避すべき一般的なリスクは以下である：
- インタビューモードが参加者のデフォルトになってしまう。自分のやっていることについてインタビューされながら、作業したり、実際にやってみせたりするというのは、ほとんどの人には馴染みのないことだ。しかし、プロセスを要約しようとしたり、セッションを詳しく話す場ととらえるのは参加者にとって容易なことだ。だが、これこそがコンテキストインタビューで回避すべきことである。この問題を防ぐためには、インタビューの移行フェーズを適切に実行する必要がある。参加者が引き続き（：従来型の）インタビューモードであろうとするなら、あなたの作業の細かい部分に興味があるので、自分はこの場にはいないものだと思って、普段のときと同じように仕事を仕上げてほしい、と念を押そう。
- セッションが苦情を言う場になってしまう。通常、ユーザーを観察するのは、デザイン変更のためにシステムの問題を理解しようとするためだ。ところが、システムのすべての問題に関するフィードバックを求められていると参加者が思い込んでしまい、セッションが現在のソリューションに対する不満を発表する場になることがある。しかしながら、コンテキストインタビューの目的は、ソリューションにこだわらずに、インタフェースの枠を超えて、ユーザーの考えや作業プロセスを真に理解することにある。苦情を言う場になってしまった場合は、通常と同じように作業をして、その行動の背後にある根拠を説明してほしい、とリサーチャーはユーザーに再度指示する必要がある。
- 自分自身のバイアス（先入観）をセッションに持ち込んでしまう。どんな種類のユーザー調査であっても、リサーチャー自身が調査の目的に関するバイアスや意見をセッションに持ち込んでしまう可能性はある。調査のセッションに自分の意見を持ち込むと、インタビューのやり方に偏りが生じ、その結果、観察対象についての理解も偏りかねない。（さらに、人というのは相手を喜ばせるために努力するものなので、あなたが特定の意見やある種の回答を好むと感じると、ユーザーがあなたのバイアスに沿ったコメントをしてしまう恐れもある）。コンテキストインタビューは客観的に取り組むことが重要だ。その作業に関するこれまでの理解をすべて捨てて、バイアスを持たずに調査に臨み、学んだことすべてを同じ重要度で扱うということに意図的に取り組まなければならない。
- ユーザーにバイアスをかけてしまう。コンテキストインタビューの際、参加者の作業に対する自分の解釈の正しさを証明しようとして彼らの反応を求めているうちに、参加者が議論やあなたの解釈に合わせて自分のプロセスを調節してしまう可能性がある。ユーザーには、常に通常どおりの作業を行ってほしいことを強調し、彼らが自分で結論を出してくれることを可能にする自由な会話を奨励しよう。
結論
コンテキストインタビューのセッションが終了したら、リサーチャーとデザイナーは集まって調査結果を共有し、インタビューの結果を解釈する必要がある。親和性マッピングなどの定性データからテーマを見出すためのワークショップは、チームがパターンやテーマについて意見のすり合わせをする役に立つ。コンテキストインタビューは、タスク分析と組み合わせて行われることが多いが、最終的にチームは、ユーザーの作業プロセスやメンタルモデル、よく行う行動についての共通の理解を得ることで、顧客向けのソリューションをデザインする準備が整ったということになるだろう。
参考文献
Contextual Design: Designing Customer-Centered Systems, Hugh Beyer and Karen Holtzblatt, 1990.
