2001年03月06日
道具の使いやすさを検証するテストのことを総称してユーザビリティ・テストと呼びます。ユーザビリティ・テストは大きく２つのアプローチに分類できます。
ひとつはいわゆるユーザ・テストと呼ばれるもので、実際に製品を利用することになる属性（性別、年齢、知識レベル、etc. ）の被験者に、検証対象となる製品（あるいは開発中の試作品）を使ってもらい、その様子を観察するという形式です。たいていは、特に検証したい機能を利用するような課題（タスク）を設定して、それを被験者に遂行してもらいます。例えば携帯電話なら「メモリダイヤルから○○さんを呼び出して電話をかけてみて下さい」というようなものです。観察者はその過程で被験者がどのようなポイントで迷ったり間違えたりするのか注意深く目を光らせます。ある２つの仕様のどちらを採用しようか迷っている場合などは、両方やらせて達成率（何割の人がそのタスクをやり遂げるか）や遂行時間を計測することもあります。詳細なメリット／デメリットについては後で触れますが、ひとつ重要な点は、対象となるユーザ層の被験者を多く集めることは非常に大変だということです。一人一人に拘束時間に見合った謝礼金を支払わなければならない点も勿論ですが、ユーザ層によってはそもそも集めることが難しい場合もあります。例えば「60歳以上の高齢者で日常的に車を運転し、なおかつカーナビの使用経験がある人」といった具合です。バリアフリー／ユニヴァーサル・デザインの製品を評価する場合も、車椅子利用者、視覚障害者など実際の被験者をまとまった人数集めるのは大変困難な時もあります。
実際のユーザ層にマッチする被験者に集まってもらうことが困難な場合には、もうひとつの分類であるインスペクション法と呼ばれる手法群が有効です。では被験者の代わりに誰が評価をするかというと、それはユーザビリティ評価の専門家や開発者自身です。
ユーザビリティ評価の専門家は、一般的なユーザが典型的にどう振舞うかに関して知識や経験を持っており、いわば擬似ユーザ・テストをそれなりの精度で実施することができます。実際に被験者を集めるのに比べてコスト面、時間面で有利なのですが、日本ではまだこれができる専門家の数が不足しています（ただ、いるとこにはいますよ。例えばこの道具眼プロジェクトとか;-)
ユーザビリティ評価の専門家も雇えない。たくさんの被験者を集める時間もない。そんな時は開発者達自身で評価することもあります。ただし開発者は自分達が作った製品についてとても良くわかっているので、なかなか客観的な視点からその製品の難しさを指摘することができません。自分達にとって当たり前の事が、一般ユーザにとってもそうであるかのように感じられてしまうものです。そこで、開発者自身の手でユーザビリティ評価を行うために、いくつかの具体的な手法が提案されています。『Webユーザビリティ』という本で有名なNielsenという人が考案したHeuristic Evaluationや、Polsonらの考案したCognitive Workthroughなどが代表的なものです。前者は開発者が忘れがちなチェック項目（Heuristics）を設定し、逐一それに照らして評価する形式で、後者は一定の書式のシートに質問に答える形で検証対象の製品について記述していく間に、やはり忘れがちな点について客観的な再吟味を促すというものです。現在では他にも多くの手法が考案されていますが、その多くはこの２つの手法の派生や組み合わせによるものです。
またユーザ・テストやインスペクション法の他にも、ユーザの利用実態や潜在ニーズを調査するのに、アンケートやインタビューといった手法を利用する場合などもありますが、これらは具体的な製品の検証方法という観点からはやや外れますので、また別の機会に触れたいと思います。
次回はこれらの手法について、それぞれのメリットとデメリットをもう少し詳しく説明したいと思います。