« プリンターを買いました (Canon PIXUS iP7500) | トップページ | 自己防衛 その2 -社会的自己防衛- »

2006/10/17

ユーザビリティ・テスト -その有効性と限界-

 ソフトウェア・テスティングについては、一通り言いたいことは書いたつもりなので、いったん終わり。
今回から数回に分けて “ユーザビリティ・テスト” について書いていく予定である。

 “ユーザビリティ” という言葉を聞いたことのない人も多いと思う。日本語に訳すと “使い勝手”、“使いやすさ” といったところか。より詳しい解説については、フリー百科事典『ウィキペディア(Wikipedia)』 を参照されたい。
その “ユーザビリティー” を評価するのが “ユーザビリティ・テスト” である。

 私は、数年間いくつかのパッケージ・ソフトウェアの仕様の策定を担当した。そして、仕様を策定するにあたり一番活用したのが “ユーザビリティ・テスト” である。
ユーザビリティ・テストでは、まず “検証したい目的” を定める。“入力のしやすさ” とか、“起動から文書作成完了までの時間”とか、“使おうとしているアイコンのわかりやすさ”など、目的は多岐にわたった。
次に、その目的を検証するための “課題” を設定する。ここで大事なのは、こちらの意図を、課題を実行する被験者に気づかれないようにすることである。こちらの意図を読まれてしまった場合、被験者は普段のやっている使い方でわなく、こちらの意図に沿った使い方をしようとしてしまうことがあるためである。課題は例えば“入力のしやすさ”では、入力する文字や文そして入力場所などを指定する。入力する文字には、わざと読めない漢字や入力が難しい記号などを織り交ぜておく。
課題が決まれば実際にテストを行う。テストは、課題をこなす被験者に来てもらう。テストを行う場所には被験者のみにいてもらう。テストを行う者は、被験者の行動をマジックミラー越しやテレビモニターを使い、別室で監視する。被験者への指示はマイクを通した音声のみで行い、行動を制限するような指示をしたり、テストの意図を気づかれるような受け答えは行わない。
被験者は3人いれば有意義な結果が出せるらしいが、私のいた会社のユーザビリティーチームでは、一つの課題に対して5~6人のテストを行った。
テストが終了したあとは、テスト担当者が得られたデータに基づいた“分析”、“問題点の指摘”、“問題点改善のための提案”をレポートにまとめて、開発チームへ報告する。開発チームはそのレポートを検討して、実際にできる範囲での改良を加える。
必要があれば、改良が加わった後の製品についても同様のテストを行って、改善の確認を行う。

 私は、ユーザビリティチームのテスト担当者ではなく、開発チーム内においてユーザビリティーチームと協力をして製品の改善を行っていく立場であった。よって、ここでの話も、ユーザビリティ・テストを製品改善のための手段の一つとして用いるための話となる。
ユーザビリティ・テストの技術的な話や、実際にユーザビリティ・テストを行いたいときは、別なサイトを参照されたい。何人もの優秀なユーザビリティ専門家がそれぞれに有用なサイトを立ち上げているので検索して探してみることをお勧めする。

 ユーザビリティ・テストを何回か経験すると、『すべての問題をユーザビリティ・テストで見つけて、それから仕様を決めて、ユーザビリティ・テストで確認すればいいじゃん』 と勘違いするときがある。げんに私がその一人であった。しかし、何事にも向き不向き、適正というものがある。例えば、F1レーシングカーはサーキットでは確かに市販の乗用車など及びもつかないほど速く走れる。しかし、市街地でF1レーシングカーが乗用車より速く目的地につけるとは思えない。
ユーザビリティ・テストではっきりとわかることは 『問題がある』 ことがわかることである。その製品を使う上で使いにくいところがあれば、ほとんどの被験者がその部分でつまづくため、すぐにそれとわかる。
逆に、ユーザビリティ・テストでは、『問題がない』 ことは証明できない。いくら被験者全員が問題なく課題をクリアしても、製品を購入したすべてのユーザーに問題なく使ってもらえるかといえば、それは定かではない。

 それではユーザビリティ・テストをやるのはムダなのか?といえば、もちろんそんなことはない。
「問題がありそうだ」 と 「問題があることがはっきりしている」 では、製品を改善する上でのモチベーションが違ってくる。また、問題を修正させるときのプログラマーへの説得力の強さが違ってくる。
また、ユーザビリティ・テストを行っていると、ときおり課題を作って検証しようとした以外の問題が見つかることがある。ただし、これはタナボタ的な効果であって、『なにか問題がないか?』 と未確認の問題を見つけるためにはユーザビリティ・テストは適さないので注意されたい。
以前のユーザビリティ・テストの結果と比較することで、問題が改善されたことの確認は取ることができる。例えば、同じシナリオの課題がより短い時間でクリアできるようになったとすれば、改善されたと見ていいだろう。

 私は現役のときに、ユーザビリティ・テストを活用することで、多くの問題を確認して、また改善してきた。時には自分達より大きなマーケットシェアを持つ競合他社が次バージョンでまねをするような仕様を、先駆けて世に送り出したりも出来た。
製品開発に携わっている人が問題解決に行き詰ったときなどには、ぜひユーザビリティ・テストを活用して、より使いやすい製品を世に送り出してもらいたいものであると願うものである。

|
|

« プリンターを買いました (Canon PIXUS iP7500) | トップページ | 自己防衛 その2 -社会的自己防衛- »

ユーザビリティ」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/61641/12044295

この記事へのトラックバック一覧です: ユーザビリティ・テスト -その有効性と限界-:

« プリンターを買いました (Canon PIXUS iP7500) | トップページ | 自己防衛 その2 -社会的自己防衛- »