2001年04月04日
今回はユーザテストとインスペクション法のメリット／デメリットを項目毎に比較してみましょう。
・実施コスト
基本的にユーザテストの方がコストがかかります。被験者をリクルートしたり、ビデオ機材を準備したりといった必要があります。本格的なテストでは、マジックミラー越しに分析者や開発者自身が実験の様子をリアルタイムで眺められるような設備を利用したりもします。
一方、インスペクション法では上記のようなことは必要ではなく、極端な話、評価対象の製品と筆記具で足りる場合もあり、設備面ではコストパフォーマンスが高いと言えます。ただし、専門家評価については、特に日本では専門家の数自体が多くないため、そういった人材に委託するのはそれなりにお金がかかってしまいます（道具眼プロジェクトではまさにここをなんとかしたいと考えています）。
・分析の労力
ユーザテストでは、単に人を大勢集めることの金銭的コスト以外にも無視できないコストがあります。それは分析のためのコストです。認知科学などの分野で観察ビデオを分析する場合、詳細に発話内容を書き起こした上で詳細に見ていくので、テープの記録時間の10倍の時間がかかると言われています。開発の現場ではそこまで詳細に分析を行うことがまずありませんが、テスト結果を開発にフィードバックするにはやはりテープの記録時間の何倍もかかることが普通です。なぜならユーザテストで得られる被験者の発話というのは単に「わからない」、「難しい」などとかなり抽象的なもので、具体的に「何がわからないから先へ進めないのか？」、「どこが難しいと思わせる原因になっているのか」を突き詰めたり、それを改善するためのアイデアを考えたりするには莫大な労力が必要となります。
一方、インスペクション法、とりわけ専門家評価の場合は、具体的にどこが原因でユーザの混乱を引き起こす可能性があるかを指摘されるので、分析の手間は省くことができます。また一般的なユーザが自然だと感じるちょっとしたデザイン上の工夫などについてもノウハウを持っているので、簡単なものであれば改善アイデアも同時に引き出すことができるでしょう。
・開発プロセスへの導入
仮にユーザテストをするだけの予算が確保できたとしても、実施にはもうひとつ大事な条件があります。当たり前のことですが、テストに使える製品が必要なのです。動く製品もなく、仕様書を被験者に見せて「これはわかりやすいですか？」と尋ねることを想像してみてください。これは開発プロセスの比較的早期の段階ではユーザテストの実施が難しいことを意味しています。
ここに大きなジレンマがあります。ユーザテストが実施できるくらい製品レベルに近い試作機ができあがるような時点では、すでに大きな問題点が見つかっても変更が間に合わないのが普通なのです。
ここで今回紹介する２つの手法をうまく使い分ける必要が出てきます。インスペクションはユーザテストに比べて”大雑把”な問題点の発見しかできませんが、実際に動作する試作機がなくても評価ができます。なぜなら開発者自身は仕様書を読むことには長けていますし、ユーザビリティの専門家も必要上ある程度は慣れていることが多いからです。開発の早期段階ではインスペクション法による評価を導入し、大きな流れとして間違いがないことを確認し、試作が動き出す段階でより精度のあるデータが得られるユーザテストを実施して詳細に渡って検証するというステップが理想の使いやすい製品の開発工程であると考えられています。
・説得性
一方で、コストのかかるユーザテストにもメリットはあります。それは開発者への説得力です。通常、ユーザビリティ評価を受けた経験のない開発者は、自分の手塩にかけて開発してきたものに対しての批判はそう気分良く受け入れてくれません。このような場合、専門家評価でユーザビリティに関する様々な理論を盾に展開してもなかなか効果がなく、やはりユーザが使っているところ（使えないでいるところ）をマジックミラー越しに目の当たりにしてもらう事のインパクトにはかないません。
ユーザテストはコストも時間をかかるのですが、どうしても頭の固い開発者がいた時に、ガツーンとショックを与えて「今の製品はこんなに改善の余地があるんだ！」という意識をもってもらうには効果的だと言えます。逆に最初から問題意識の高い開発者の間では、効率良く要改善点を発見できるインスペクション法の方が適していると言えるでしょう。
・問題発見力
評価の専門家は一般的なユーザの振る舞いについての知識があるとは言え、ユーザは常に開発者の予想をあっさり覆すことをしてくれます。電子レンジで猫を乾かすとまでは行かなくても、それぐらいビックリすることがユーザテストでは起きることもあります。インスペクション法はその名の通り予測でしかない訳で、つまり最後の最後では実際に起きた事象にかなうデータではありません。また、インスペクションでは予想しようがないようなこと、例えばボタンの文言は「訂正」と「修正」のどちらが自然に感じるかみたいな微妙な点は、やはり実際にユーザを導入して試してもらうしかないでしょう（個人的にはそこまでしなきゃ差異がわからないような問題なら、手間隙かけてユーザテストをする価値も危ういことがほとんどだと思いますが）。
つまりインスペクション法は、実際のユーザテストほどの精度はないけれど、（ちゃんとしたスキルの人が実施すれば）重大な問題点についてはほとんど洗い出せる非常に効率の良い手法。ユーザテストは非常に多くの情報が得られますが、それが偶然の産物であるエッジ・ケースなのか、頻繁に起きうることで重要な要改善項目を示唆しているのかをしっかりと見極める必要があると言えます。
全体を見返して見るとインスペクション法、とりわけ専門家評価の法が優れた手法であるかのような物言いになってしまっています。当然、実際には目的や開発フェイズに応じて適切に使い分けることが大事という話なんですが、我々の基本スタンスはまずインスペクション法でいいんじゃない？って感じです。自然とそれが文章ににじみ出てしまった気がします。取り組みの姿勢のＰＲとしては、「ユーザさんに実際に使ってもらって意見を取り入れました」というのと「我々（開発チーム）自身で評価／改善しました」というのではなんとなく前者の方が良いものになっている印象を受けますが、実際勝負すべきは過程ではなく、結果出来上がった製品の使いやすさなのです。もちろん大きな組織になるとそういうＰＲこそが大事だという場合もあるでしょう。でもそういう状況はじきに解消されるんじゃないでしょうか？今はまだユーザテストに対して盲信のようなものが蔓延していますが、モノを作るにおいてコスト効率が良いことは絶対的に重要だからです。いずれ「ただユーザビリティへの取り組み姿勢のＰＲ」そのものは価値を失う（当たり前になる）ことでしょう。
確かに開発者自身がただひたすら考えても限界はあると思います。前回にも書いたように、人間が独力で客観的な他者の視点を持つことに限界があるからです。しかしそれを補助するためのツールとして様々なインスペクション評価手法がある訳です。大規模なユーザテストばかりがユーザビリティ評価ではないということを、お知りおきいただければ、とりあえず今回のコラムの役割は果たせたかと思います。