「せっかく作ったサービスを暗黒面に落とさないためにも、ユーザビリティテストは必須のものである。」
アジャイルUCD研究会の樽本さんの呼びかけに応じ、ユーザビリティテストマニュアルの実証実験に参加した今では、心の底からそう思います。2011年10月9日と10日の2日間を通して樽本さんのオフィスにて実証実験に参加しましたが、非常に刺激的でした。フィードバックを兼ねてブログに書いてみます。
目次
ユーザビリティテストとは？
「製品やWebサイトの使いやすさ(ユーザビリティ)を、実際にユーザに使ってもらうことで確認するテスト。」（IT用語辞典 ユーザビリティテスト）
「使いやすさを確認する」と言うのは少し曖昧な感じがしますね。樽本さんの言うユーザビリティテストの基本は、以下の2点です。
- ユーザにタスク（作業課題）を実行するように依頼する。
- ユーザがタスクを実行する過程を観察、記録する。
「使いやすさを確認する」と言うと、適当に使ってもらって、その感想を言ってもらう程度のものを想像してしまいがちですが、ユーザにタスクを与えてそれを実行してしまうことで、ユーザから非常に具体的なフィードバックを得ることができます。思ったことを声に出しながらタスクを実行してもらうことを 思考発話法 と言うらしいですが、「何かをしようとしているが、できなくて迷っている姿」を実際に声に出してもらうのは強烈なフィードバックです。
ユーザビリティテストを実際にやってみて分かったこと
テスト設計は詳細すぎるほど詳細にやるべし！
ユーザビリティテストはもちろんテストの一種ですので、しっかりと設計をするべきものです。ただ、その単純さから、「単に質問内容を伝えられれば良いや」程度にしか思われないかもしれません。
やってみて分かったところで、特に重要だと感じたのは次の3点です。
- テスト毎の環境初期化手順（＋仕込み）
- インタビュースクリプト（「ここで見聞きした内容を他言しない」等の導入の言葉から、実際に話す内容を一言一句設定しておく）
- ユーザに実行してもらうタスクの吟味
テスト毎の環境初期化手順は、できればスクリプトなどで自動実行できるようにしておくことが望ましいです。また、新規登録の必要なシステムを対象とするならば、そのためのメールアドレスの準備をしておく必要もあります。稼働中のシステムで、できるだけテストデータを残しておきたくない場合は、テストデータを削除するところまで手順化しておくべきでしょう。
手順化されない手順は、どんなに当たり前の手順でも、必ず現場で混乱を巻き起こすということを肝に銘じるべきです。
次に、インタビュースクリプトについても同様に、話す内容の一言一句をあらかじめ考えておくべきです。「話すべきポイントさえおさえておけばアドリブでかまわないでしょ？」と思われがちだと思うのですが、そのアドリブ部分が、もしかしたらテスト中のユーザの行動に影響を与えてしまうかも知れません。それに、きちんとした台本が用意されていると言うことはインタビューアの心の支えになります。
最後にタスクの吟味ですが、ユーザにしてもらう内容というよりは、それをどんな形で伝えるか、がキーポイントです。特に意識したいのは製品（またはサービス）のコンセプト。自然と製品のコンセプトが伝わるようなUIになっているかどうか、それによって狙い通りに使われる製品になっているかどうか、そういった要素を確認できるようなタスクにしなければなりません。
たとえばyouRoomというサービスでしたら、 「今あなたは新製品開発に関するディスカッションをするために、様々なロケーションからでも意見交換ができるサービスとしてyouRoomを使用しようと考えています。」と状況を設定した後に、「ディスカッションをするための場所を作成し、プロジェクトメンバーをその場所に招待してください。」といったタスクを提示します。できるだけその製品の用語を使わずに、一般的な単語でタスクを説明して、ユーザが目的を達成できるかを見ます。
タスクはアジャイルで言うユーザーストーリーのレベルではなく、さらに上のエピックの単位で作成するのが秘訣だと樽本さんに教わりました。
全て考え抜いた後には、いきなり本番を迎えるのではなく、パイロットテストを入念に行います。人間を相手にするので、あらぬところで落とし穴があります。最低でも2〜3回は行うべきとのことです。
インタビュー中は絶対に誘導しない
- ユーザの行動に対してうなづく等の反応をしてはいけない。
- インタビュー中は、ユーザを除いてインタビューア以外喋ってはいけない。
インタビュー中に守るべき鉄則です。私はインタビュー中に無意識にうなづいてしまったりして大変怒られました。。無意識に相づちを打つ癖のある人は気をつけてください。
インタビューア以外喋ってはいけない理由は、ユーザに対して誘導を与えてしまう危険性があるのもそうですが、ユーザが他の実験者にも話しかけるようになってしまい、インタビューアが場のコントロールを失ってしまうのが一番の理由だそうです。
ユーザビリティテストはどんなタイミングでもできる
ユーザビリティのテストというと、製品の最終段階に狙った効果が出ているかの確認のために行うイメージが自分にはあったのですが、実際にやってみた感覚で言うと、できるだけ早期に、何回も繰り返して行うべきだという確信を得ています。
完成品がなくともペーパープロトタイプでテストは実施できます。ペーパープロトタイプの時点でユーザのフィードバックを得られると言うことは、その後の開発においても大きなアドバンテージになると考えられます。
「いや、最初のリリースにそんな手間をかけていられないよ。そんなスピード感じゃライバルを出し抜けないよ。」と言うのは当然の意見です。その場合は、何も大々的に被験者を集めてユーザビリティテストをしなくとも、友人が想定されるユーザ像に合っていれば協力してもらえば良いと思います。ライトウェイトなテストだけで十分なフィードバックを得られます。
フィードバックを得ると言っても、「ユーザの声を聞く」訳ではありません。「ユーザの体験を見る」と言うことが重要です。製品のユーザビリティから、ユーザがどのような体験を得ているのかを観察し、分析します。狙った体験を得ているかどうか、テストを実行しながら先に進めていくこの姿は、まさにアジャイルプラクティスのTDD（Test Driven Development：テスト駆動開発）だと言えます。UXにもTDDは有効なプラクティスだと言うことです。
また、各スプリント（イテレーション）の最後に、スプリントレビューとしてユーザビリティテストを実施するのも有効なのではないかと言う意見も出ました。実装したエピックのUXを確認すると言う趣旨のものです。ただ、ここで得られたフィードバックによって、リリースは難しいという判断になる危険性もあるので、逆にイテレーションの最初にペーパープロトタイプで確認するという形でも良いかも知れません。
まとめ：樽本さんの次回作は必ず買うべし
2日間で多くのことを学びましたが、改めてフィードバックの大切さを実感したと思います。特に体験のフィードバックを念頭に置いたことがなかったので、この点で非常に刺激になりました。
今回の実証実験では樽本さんのマニュアルを手本に行われたのですが、そこに書かれているインタビュー例などに沿ってインタビューを行うことで、とてもスムーズにテストを行うことができました。次回作は手放せない名著となる予感がします。
最後にユーザビリティテストで使用したツールなどをご紹介して終わりたいと思います。
Silverback
実際に操作している画面を、操作している被験者の顔と合わせてリアルタイムに録画できるツールがSilverbackです。有料（79$ほど）のツールですがとても優秀です。Mac専用という部分が、使う人を選ぶ形になってしまいますが、ブラウザベースの製品をテストするならMacでテストしても大丈夫かなと思います。
（私は普段Mac使いですが、世の中一般の人はやっぱりWindows使いの人が多い訳で、Macのキーボードに慣れない人もいるわけです。。）
画面共有
Macならシステム環境設定＞共有＞画面共有にチェックを入力することで簡単に画面共有ができます。インタビューアは被験者の右手に座りますが、その他のテストする側の人間は直接被験者の画面を覗けない場所にいることも多いと思いますので、画面共有の環境整備は必須です。
iPad
iPadはとても便利な道具です。インタビューアが台本を読むのにも使えますし、被験者が適時参照するインタビューカードの代わりとすることもできます。
LifeCam
スマートフォンで動くアプリケーションのユーザビリティをテストする場合は、Silverbackのようなソフトをバックグラウンドで動かすことはできないため、スマートフォンを台座で固定して、上から三脚か何かで固定したカメラで撮影する必要が出てきます。
PCに接続する一般的なライブカメラは三脚に固定できないものが多いのですが、LifeCamなら固定できるので、撮影時に便利です。Silverbackとは逆に、こちらはWindows専用なのが残念なところです。
