2002年04月28日
σ(^^)がフリーランスになって以降よく請け負う仕事に、製品のインスペクション評価と並んで、ユーザテストの司会進行役があります。直接的なコンサル系の仕事よりは、業務として評価がしやすく、外注に出しやすいというのもあるでしょう。ですが、やはりユーザテストの進行役という役割にそれなりにスキルが必要なんじゃないかと思われてたり、初対面のモニタさんに応対するのに気を遣うなどといった理由で敬遠されがちなところが大きい気がします。
σ(^^)にしても、正式にインタビューイングの教育を受けたワケでもなく、現場実践の積み重ねによる我流なんですが、その分、ユーザテストに特化したノウハウは書けるかなぁ、と思い今回のテーマに取り上げてみることにしました。社内でユーザテストを実施してみようと思った時の障壁のひとつを少しでも下げられれば幸いです。
■事前説明とラポール形成
インタビューやカウンセリングなど対面で行う調査で重要なのは、相手を過度に緊張させず、自然な発言を促すよう、リラックスしてタスクに臨めるような雰囲気、進行役との関係を形成することが重要です。このような雰囲気、関係のことをラポール（rapport：フランス語）と呼んだりします。ユーザテストでも忌憚のないコメントを得るにはラポール形成がポイントになってきます。
ラポールの形成には最初の導入時の配慮が大きく影響します。σ(^^)は大抵、実際の説明やタスクに入る前に、以下のような会話をするようにしています。
・テスト参加への労（ねぎら）い
特に社外から被験者を呼んだ場合、彼らも見知らぬ場所に来て不安を抱いているところなので、とにかくまずホスピタリティを示すことは大事だと思います。「今日はお休みの日にご足労ありがとうございます」とか「雨なのにすみません」など。σ(^^)がもっとも一緒に仕事することが多い会社のテスト・ラボは坂の上にあるので、「駅からここまで坂が大変でしたでしょう？」とか「お送りした地図ですぐおわかりになりましたか？」などと聞いたりもします。
・ユーザテストの意義の説明
「ユーザテスト」という言葉はなにやら「ユーザ」を「テスト」するような語感をもっていて、実はあまり聞こえが良くありません。σ(^^)はまずそういった誤解を解く説明をします。
- テストの目的はあくまで製品の側の問題点を発見することです
- 何か○○さんの成績をつけたり、比較したりする類のものではないです
- 逆に失敗したり迷ったりしていただく事が問題点を見つけるきっかけになります
などということを説明します。
・被験者をリラックスさせる
ユーザテストで得るべきデータは、実際にユーザが商品を購入して、使用現場で使うことができるかどうかの判断材料です。実験室の中で最大限に集中したり、ガチガチに緊張して真剣にタスクに取り組んだ場合の達成率ではありません。むしろ、できるだけ普段通りの気持ちで取り組んでもらうことを促すようにします。
特に機械操作の苦手な方や高齢な被験者さんの中には、言われたタスクを達成することが必要条件であるかと思い、間違えたり、タスクを最後まで完遂できなかった場合に謝ったり恐縮してしまったりすることが少なくありません。以前、言われたことができなかったので申し訳ないからと、なかなか謝礼を受け取ってくれない方もいらっしゃいました。これはよろしくありません。普段通りの感覚で望んでもらうことを繰り返しお願いします。「実際に自分で買って、ウキウキして帰宅したつもりになって」とか具体的な場面をイメージしやすい説明も有効です。
初対面でなおかつ開発者やデザイナー本人に対する批判への心理的抵抗を慮って、「私はこの製品を作った人間ではないので、何を言われてもへっちゃらですよ(^_-)。」などと言ったりもします。
・内省報告のお願い
以前のコラムでも触れましたが、プロトコル発話を過度に強要することは、タスク遂行そのものに様々な影響を与えてしまうリスクがあります。ですが、やはりせっかくのユーザの生の声を聞くチャンスを逃す手はありません。「何か気づいたことがあれば、いつでもおっしゃって下さい。あるいはブツブツと独り言をつぶやくヒトのようになってもらっても構いません。」などというに留めています。
・その他の手続き的なこと
タスクに入る前の最後に、撮影、録音の了承を録ったり、見聞内容に関する守秘次項の確認をしたりします。
撮影、録音、あるいは隣室の観察者の存在は、被験者に意識させないようにむしろ隠す考え方もありますが、やはり社会的、倫理的に隠し撮（録）りはマズいので事前に了承を取ります。ただし「後の分析のための記録であり、他に転用はしませんので」と断りを入れることは忘れずに。
開発中の未発表製品などをテストする時は、見聞きした事柄を他言しないよう誓約書に署名、捺印してもらったりします。これもあまり緊張の原因とならないように、呼び方を「覚え書き」としたり、口頭での事情説明を柔らかい言葉にしたりしています。
＃極度に守秘性の高い製品の場合はむしろ抑止力としてキツ目の表現をしたりしたくなりますが、そもそもそういう製品に社外の被験者を用いること自体が問題にになっているはずである気がします。
■タスク教示
心理学などの実験では、条件統制のために、教示の微妙な表現などを全被験者間で完全に統一するよう配慮したりします。そのために教示者は教示文を完全暗記したり、紙に書いたものを読み上げるようにしたりします。ユーザテストにおいても、パフォーマンス測定が主目的のものであれば、ある程度はそういった配慮も必要になりますが、問題発見型のテストでは、あまり気にする必要はないと思います。極端な話、σ(^^)は被験者毎に敢えて微妙に言葉を変えたりもします。例えば一人目がタスクをうまくこなせなくて、他の被験者でも同じ結果になりそうな時なんかは、二人目から少し言い回しを変えたり、微妙にヒントになるような言い方をしたりします。それで成績があがれば、それは実際の製品のマニュアルなどのインストラクションにおける表現に取り込める可能性だってあるのです。問題発見型のテストでは、同一条件で何人中何人が課題を達成したかよりも大事なことがたくさんありますよね。「観察者は別にいるから、進行役はひたすら機械的に指示を出すことに徹していれば良い」なんて考えないで、（カメラのアングルにしばられず自由に生で観られる）観察の特等席に座りつつ、同時に製品の改善アイデアにつながる試みもその場でやれてしまうオイシイ立場を是非活用してください。
■課題遂行中のアスキング
集中して課題に取り組んでいる時に、「今何を考えていますか？」などと思考内容を発話するよう促すのは問題であると繰り返し述べてきましたが、時には意図的に尋ねる場合もあります。主には被験者が完全にハマって考え込んでしまっているような時です。単に直接ヒントを出すよりも、被験者の内省のきっかけになったりして、解決の糸口につながる場合もあります。こういう時の聞き方は、抽象的に「今何を考えていますか？」と聞くよりも、「今何をお探しですか？」とか「何にお困りですか？」といった具体的な聞き方をした方が、被験者も答えやすく、思考への影響も抑えられるでしょう。
■話したことと結果の因果関係を意識すべし
ざっとこのような気遣いだけ忘れなければ、ユーザテストの進行役というのはできてしまうものです。別に原稿を澱みなく読み上げられるとかいう技能は必須ではありません。むしろ少し天然ボケ入った進行で、被験者さんを上手にリラックスさせる人だっています（天然なので、ねらってはないんですが(^^;)）。
ただし、ただ適当な言葉遣いで教示すれば良いということではないので注意は必要です。日常的なコンテクストから切り離されたテスト環境下では、相対的に教示者の言葉の重みが大きくなってきます。些細な表現の違いで、被験者のタスクへのモチベーションや周辺状況の想定や背景知識に差がでてきてしまいます。被験者間に差があること自体は構いませんが、その差を把握して、結果への影響を常に意識する必要があります。
また言うまでもありませんが、そのまま答えになってしまうような指示はタブーです。たとえば、「決定」ボタンを押して確定するようなタスクで、「はい、じゃぁ選んだ内容で決定してください」などと言ってはマズいワケです。慣れないうちはつい言葉に出してしまってからハッっと気づいたりもします。ヒントを言うだけのつもりが、実質答えを言ってしまったり。
こればっかりは時間をかけて慣れていくしかないですが、やっちゃった場合のデータも失敗としてただ棄却するのではなくて、それによって結果にどう影響したかを検討すれば、まったくの無駄にはなりません。