1. ホーム
  2. 黒須教授のユーザ工学講義

ユーザビリティテストでは分からない実利用状況

  • 黒須教授
  • 2007年4月3日

ユーザビリティの評価手法としてユーザビリティテストは頻繁に利用されている。ただ、この手法も万全とはいえない。その限界を知った上で利用し、不足分については他の手法を併用することが必要だ。今回は、そうした限界の一つである「実利用状況との違い」について述べたい。ユーザビリティテストは実験状況であって、決してそこに実利用状況が完璧に再現されうるわけではないのだ。

二つの例をあげたい。一つはソフトウェアのアップデート、もう一つはハードウェアの具合が悪くなったとき。

A社の文書フォーマットはいまでは世界標準の一つとなっている。その文書フォーマットはとても便利に使えるのだが、それを利用するためのソフトは起動が遅く、イザという時に待たされるので不満を感じてはいた。しかし、その不満が決定的になる時がきた。

ある時、ワードで文書を作成していたら、そのソフトの自動更新の連絡をするポップアップが開かれた。まあ並行してやってもらえばいいかとOKをクリックした。すると動いているアプリケーションを閉じろと言われた。仕方なく作成中の文書を保存して終了した。これだけでも不愉快になる。こうした不愉快さはテスト状況では作成しにくい。仮にテストで似たような状況を設定したとしても、テスト参加者は、その文書作成に真剣に取り組んではいないだろうからだ。真剣に取り組んでいればいるほど、それが中断される不愉快さは強くなる。

さて、ソフトのバージョンアップ、これがこのソフトの場合は時間がかかる。差分インストールをしているにしては時間がかかりすぎるのだ。こんなに時間がかかるなら、いったん削除して再インストールをしても同じではないかと思うほどに長い。そして終わると再起動を要求してきた。ソフト開発者はインストール後の再起動をさほど大変なことと考えていないのかも知れない。しかし再起動にかかる時間、そしてその時の私のように何か作業をしていてそれが中断させられている状況での心理的不愉快さ、そのことを理解していない作り方に感じられた。

さらに悪いことには、そのソフトを最新版にするには3つのアップデートをしなければならず、結果的に三回のインストールと三回の再起動をさせられてしまった。そのトータルの時間の長かったことといったら・・。なぜ一回で、しかも再起動なしにアップデートできるように作っておかないのか、実に不愉快だった。

ユーザは様々な状況でパソコンを利用している。開発者が自分たちのやり方にしたがってインストールをしてくれ、と要求する場合、それにかかるコスト、つまりどのくらい時間がかかるのか、どれだけの作業が必要で、どのくらい再起動が必要なのか、などの情報を、少なくともあらかじめユーザに知らせるべきだ。強引に自分たちのロジックだけで突っ走ってしまうのは危険なことだ。時間的に余裕のあるユーザもいるだろうが、仕事をしているユーザもいる。そうした実利用状況で生じる可能性のある問題をユーザビリティテストで予測することは困難だ。幾らユーザビリティテストを実施して、そしてほとんどすべてのユーザがバージョンアップに成功した、という結果を得たとしても、それで問題がなくなったわけではないのだ。

二番目の例は、LBPの具合が悪くなったときのこと。メーカーのサポート窓口に連絡をしたところ、機種番号を伝えるように言われた。どこに載っているのかと聞くと、プリンタの底の部分にシールが貼ってあるという。ちょっと常識を疑った。せめて裏側だろう。底に貼ってあるとしたら、それを見るためにはプリンタをひっくり返さなければならない。しかも多くのユーザは、いろいろな機器を狭いデスクに収めてしまっている。だから裏側を見るだけでも結構手間がかかる。ましてや裏返すためには相当面倒な手間が必要になる。そのことを考えて底に機種番号を貼ったのだろうか。さらにそのLBPは上部に多少のフラットな場所がある。だから僕はそこにいろいろなものを乗せておいた。それが僕の場合の実利用状況だった。

このメーカーは、こうしたメンテナンス関係のユーザビリティテストを実施したのだろうか。いや、仮にしていたとしても、このような利用状況まで含めてユーザビリティテストを実施することは困難だ。

いいかえれば、こうしたことはテストしなくてもちょっと考えれば分かるはずのこと。型番や機種番号は前面にシールで貼っておくようにするのが一番簡単だろう。その情報はお飾りではない。それが必要になる状況があるのだ。そのことを知っているのはメーカーの人たちのはずだ。

ユーザビリティテストを否定的に言っているわけではない。テストは問題発見の場でもあるし、時には問題確認の場でもある。ただ、そこに設定された状況はあくまでも実験的なものであることを忘れてはならない。そこに実際の利用状況を再現することは困難だ。となれば、あとは想像力を駆使するしかない。いろいろな場合を想定し、それらの事態への対処法を考える。それはインスペクションに近いが、通常のインスペクションでは多様な利用状況を考えるところまではやらない。

その意味で、一番有用なのは、実際に利用しているユーザのところで、そのソフトウェアやハードウェアがどのように利用されているかを観察し、面接することだ。もちろんそれとて万全の方策とはいえないが、そうした現場調査をすることが第一歩である。

ただ、もう一言書いておかねばならない。現場調査をやっているメーカー関係者は結構多い。現場の写真を撮ってきて、ユーザはこういう風に使っています、と言う。しかし、そこで止まってはいけないのだ。そうしたそれぞれの使い方の場合、「これこれ」のことをするとしたらそこにどのような問題が発生しうるか、その「これこれ」について多様な想像を巡らす必要がある。ユーザビリティテストを含め、評価の手法は万全ではない。その限界を知った上で、それを補う努力をする必要がある。

キーワード