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