2002年10月17日
最近、母校の学生にユーザビリティ・テストの指導をする機会があって（といっても正規の講師とかじゃないですけど）、表題のようなことについて改めて考えてみるきっかけになりました。せっかくですのでご報告してみようかと思います。
■検証したい対象をはっきりさせる
まず最初に、テストで検証したい対象をハッキリさせておくことが肝心です。これは以下の事項のほとんどに関わってきます。
「対象」というのは、単に「開発中の試作品３号を評価するぞ!」というレベルではなくて、より具体的に、
- 基本機能の操作部分か、やや複雑な操作か
- 「初めての時にどれくらい苦労するか」的なことか、「習熟後にいかにスムーズに使えるか」的なことか
- メイン・ターゲットのユーザ層に対してか、身障者など特定な層への対応度調査の類か
といったように、知りたいことを事前に絞り込んでおく方が、観察記録、後の分析、考察など様々な面で効率的になります。逆に事前に対象がボンヤリしたままでは、得られる結果もやはりボンヤリしたものになってしまう恐れがあります。
■事前教示の程度は？練習はアリ？取説を見せる？
これもやはりテストの目的次第でしょう。ただ、基本的な考え方としては、「実際のユーザが現実場面で得られる程度のサポートは与えて良い」と思います。
例えば、純正のカーステレオの基本的な操作方法って、新車購入時にディーラーで簡単に説明を受けたりしますよね？そう考えると、ユーザがまったく予備知識無しに自力で基本操作をしなければならないことって考えにくくて、そういう状況をシミュレートしてもあまり意味がないことになります。一般的なユーザが自分で購入して触り出す前に、販売員やカタログなどから仕入れると思われる情報と同等な教示は与えてしまっても良いでしょう。
もう一例。最近のカーステレオにはCD-ROMに焼いたMP3ファイルの再生機能が備わ ってきています。カーステレオのテストで、このフォルダ移動操作のタスクを組み込む とするとして、「そもそもMP3とは何か」とか「フォルダとは何か」について事前に教示しても良いか、って話になったとします。そういう場合、σ(^^)なら「MP3入りのCD-ROM自体はユーザが自分で作るしかない現状では、そういった概念をなんとなく理解しているPCユーザが対象になる。従って、被験者の中にノンPCユーザがいた場合、フォルダ移動タスクの前にそれらを教えておいても良い」と答えます。「ノンPCユーザはそもそもMP3なんて知らないし使わないから」と除外するより、「一般的なMP3ユーザが知ってそうなことは教えた上で使ってみてもらう」方が何かしら得るものはあると思います。
練習や取説についても同じように考えられます。現実場面で取説が参照できるものを、敢えて取説を遠ざけることでタスクの難易度を上げて得られたデータに、果たしてどのような意義を見いだせるでしょう？現実には「本人が見たいと思ったら見られる」のが一般的なので、テストの時も脇に置いておいて被験者が希望すれば見られるようにしておくのが自然じゃないでしょうか。ただ被験者が取説を読み出すと時間が多めにかかってしまったり、取説の出来も影響してきますので、やはり最後には「テストの目的と制約によって臨機応変に」ということになります。
■どこまで頑張ってもらうのか？
被験者がタスクをスンナリ遂行できなかった場合、どのタイミングでどの程度の助け船を出すのかについても予め考えておきましょう。
「完全にノーヒントで何割の被験者が何分で達成できるか」という数値を得ることは、定量的なデータとしては客観性が高く価値があるように感じられますが、実はたいした情報ではありません。現実場面のユーザは、わからないことがあれば説明書を読んだりサポートに電話したりと外部情報を参照します。そして現実のユーザには「ギブアップする権利」すらあるのです。「３時間頑張ってもらったら８割の被験者が達成できました」なんてデータが何の役に立つでしょう？たいていのユーザは30分もしたら放り出してます。
そして何より、多くのユーザ・テストの目的は「どれだけのユーザが達成できるか」を知ることより、「どこを直したら製品がより良くなるか」を知ることにあるはずです。前者は後者達成の手がかりのひとつでしかないのです。むやみに情報制限をして定量データに固執するのではなく、むしろ積極的にヒントを小出しにして、「できないユーザにとって足りない情報はなんなのか？」といったことを検証していった方がずっと有益でしょう。
■被験者間でのタスクの統制
被験者間で完全に統一された条件下での工学的データを得ることを諦め、柔軟にタスクを調整することで、実際に発見できる問題点はずっと増えてきます。
例えばタスクを被験者ごとに変えるなんて、「実験」としてもってのほかに聞こえるかも知れませんが、ユーザ・テストでは頻繁に行われます。比較的偏りのない被験者群で、３人も続けて遂行に重大な困難が生じれば、それは既に「問題」なのです。それ以上「問題である」ことの証明を続けたって得ることはありません。それよりはタスクの与え方（教示内での言葉遣いなど）を少しかえてみて結果の変化を探ってみた方が賢明です。Webの評価など、対象品を簡単に変更できるものなら、その場でいじって新しい改善アイデアを試してみることも可能でしょう。
どうせ人間は工学的な存在ではないのですし、実利を取りましょう。そんな贅沢にユーザビリティ検証のバジェットが確保できる開発組織なんて、そうないはずです。
■最初は簡単なタスクを設定して、テスト自体に慣れさせる
テストで検証したい内容が複雑な機能ばかりでも、最初に比較的簡単なタスクを入れておきましょう。被験者がテストの進み方自体に慣れてくれることが期待できるからです。特に、ユーザ・テストに参加するのが初めて、という被験者の場合は必須です。1,2点簡単なタスクを成功させて雰囲気に慣れてもらいましょう。
■１時間程度が被験者の集中力の限界
一度のテストに、どれくらいのタスクを詰め込んでも良いものでしょう？これはσ(^^)の経験則から言えば１時間くらいが限界だと思います。大抵のユーザ・テストのタスクは、被験者にとって凄く楽しいという類のものではありません。思い通りに使えない製品をあれこれ試行錯誤しつつ与えられたタスクを遂行するのですから、コンピューター・ゲームにいそしむ１時間とは質が異なります。特に、操作が上手くいっていない被験者の１時間は苦痛に満ちたものになります。そういう被験者の多くは、与えられた課題をこなせなくて実験者に申し訳なく思うなど精神的ストレスもかかるからです。
そんなこともあって、σ(^^)達は通常１時間程度の拘束で被験者を呼んだ場合、普通にこなして長くて40分程度のタスクを組みます。その他、事前／事後のアンケートや謝金の支払い、覚え書きの記入など事務的処理をしていれば結構一杯一杯になります。
どうしてもそれより多くの課題を被験者に課さなければならない場合は、適宜休憩をはさんだり、ドリンクや世間話で被験者をリラックスさせることに普段以上に努める必要があるかと思います。
また話はそれますが、よく忘れがちなのは進行役の疲労度です。被験者と被験者の間に30分は休憩をはさむようスケジューリングしましょう（お願い(^^;)！大変なのよ）。その間、観察者は今見た内容について議論したり、少しテスト内容を替えてみるといった準備ができます。また被験者が遅れて来て時間が押している場合などにもこういったマージンがあると次の方に迷惑がかかりにくくなります。
例によってσ(^^)のコラムは長文になってしまいがちですが、まとめると、
- テストの目的をしっかり定義し、どうすればそのための情報が取れるか考える
- 定量的データは手段であって目的ではない
- 原則として、実際のユーザが置かれる状況に近づける方向で設定する
- 進行役もいたわりましょう（笑）
といったことでしょうか。