ユーザーテストは準備が8割！ 弁護士ドットコムで実施した「準備の様子」「シナリオ」の一部を公開

ユーザーテスト全体の流れ

ユーザーテストを実施するプロセスを解説していきましょう。いきなりテスト実施はできるものではありません。実施するにあたって、さまざまな準備が必要です。全体の流れは次の通りです。

1. ユーザーテストの目的の確認
2. ユーザーテストの準備
3. ユーザーテストの実施（次回解説予定）
4. テスト結果の分析と改善点の洗い出し（次回解説予定）
5. テスト結果を受けての改善（次回解説予定）

今回は、1と2を中心に解説します。3以降は次回に解説予定です。さっそく順に見ていきましょう。

1. ユーザーテストの目的の確認

どんなプロジェクトでも、最初にその目的を確認しておくことが大切です。今回のユーザーテストでは、次の2つを目的としました。

一般的に、ユーザーテストの成果といえば前者の方が浮かぶと思います。しかしそれだけではなく、後者の効果にも注目したいところです。

特に、アクセシビリティの分野では、さまざまな「支援技術」が使われているということを把握していないと、アクセスできないコンテンツを作ってしまうこともあります。

逆に、「おそらくこういう使い方をするだろう」という想像だけで機能を用意しても、的外れな対応となり、ユーザーには全く使われないことがあります。さまざまなユーザーと支援技術について理解することは、アクセシビリティに取り組むうえできわめて重要なのです。

「支援技術」とは？

そもそも「支援技術」とはどんなものか想像できますか？

簡単に知る方法として紹介したいのは、総務省の「障害者のウェブページ利用方法の紹介ビデオ」というコンテンツです。このビデオでは、「全盲の方」「弱視の方」「肢体不自由の方」の3つ利用シーンの映像が見られます。

• 障害者のウェブページ利用方法の紹介ビデオ
  http://www.soumu.go.jp/menu_news/s-news/2005/051215_1_wmv.html

これだけでも、かなり多くのことを知ることができます。しかし、ここでわかるのは一般論であり、自分たちのサービスが実際にどのように利用されるのかはわかりません。

また、自分で試してみるという方法もあります。

• iOSやMac OSでは、「VoiceOver」というスクリーンリーダーが付属しています。
• Androidでは、「TalkBack」というスクリーンリーダーが付属しています。
• Windowsでは、「NVDA」というオープンソースソフトウェアを利用できます。

無料ですぐに試せますが、サービス運営者が自ら試すと、次のような問題がでてきます。

• 普段からスクリーンリーダーを利用しているユーザーと、試しに使って見た自分とでは、使い方が大きく異なっている可能性がある
• 自分のサイトについて知りすぎているため、サイトの正しい使い方が予想できてしまう

このように、ユーザーの利用の仕方を想像するということと、実ユーザーの利用シーンを実際に見ることには、大きな違いがあります。そのため、実際のユーザーに使ってもらい、それを見るということが、本来はおすすめです。

2. ユーザーテストの準備

ユーザーテストの目的を決めたら、実施に向けて準備を進めていきましょう。

ユーザーテストと聞くと難しい印象を持たれる方もいらっしゃると思いますが、事前準備をしっかりしておけば、意外に簡単にできるものです。一般的に、ユーザーテストには次のような準備が必要です。

それぞれについて、今回の対応を見ていきましょう。

① リクルーティング

ユーザーテストというからには、ユーザーの協力が欠かせません。ユーザーとなる人を募集することを「リクルーティング」と呼びますが、ユーザーテストを行うには、リクルーティングをどうするか検討しなければなりません。具体的には、次のような点を検討する必要があります。

• ユーザーの人数
• ユーザーの属性 （セグメント）
• 募集の方法

ユーザーの人数

「ユーザーテストを何回行うべきか」というのは、古くから議論が絶えないテーマです。Webのユーザビリティ研究で知られるヤコブ・ニールセン氏は、「5人で十分」という旨を2000年の記事で述べています。

何人が適切なのかは、ユーザーテストの目的によります。サービス改善を目的とするなら、ユーザー数が多いほど問題点の抽出漏れが少なくなりますから、できれば5人程度でテストできるとよいでしょう。

一方で、今回の目的は、「社内のメンバーに支援技術の利用シーンを見てもらうこと」でしたので、まずはお一人にお願いしました。

ユーザーの属性（セグメント）

どのようなユーザーを呼んでテストするのかも重要なポイントです。

ユーザビリティテストの一般論としては、ターゲットとなりえる一般のユーザーを呼ぶことになりますが、サービスによっては、そのターゲット層が複数ある場合があります。たとえば、弁護士ドットコムの場合、サイトを訪れる状況がユーザーによって異なり、次のようなバリエーションがあります。

• 弁護士を探す
• 「みんなの法律相談」で法律相談をする
• 他の人の法律相談を読む
• 弁護士ドットコムニュースのニュース記事を読む

「弁護士ドットコム」を訪れる状況はさまざまある

ここで注意したい点が2つあります。

注意点① ユーザーの使用頻度や熟練度で差がある

たとえば、入り口が同じであっても、有料会員になっているユーザーとそうでないユーザーとでは、使い方が大きく異なるかもしれません。

そこまで明確な区分がなくとも、ヘビーユーザーとライトユーザーとでは使い方が大きく異なります。ヘビーユーザーの場合、テキストの説明がないアイコンでも意味がわかったり、多数の選択肢の中から迷わず選んだりといったことができます。しかし、ライトユーザーは、説明なしにアイコンを並べられてもそのアイコンが何を示しているのかわからないということがあります。

ユーザビリティの改善という文脈では、ライトユーザーにフォーカスして改善を考えることが多いでしょう。しかし、ユーザーテストの目的によっては、ヘビーユーザーの行動を観察することが重要になる場合もあります。どちらのためにユーザーテストを行うのかをしっかり定めましょう。

注意点② ユーザーのITスキルによって異なる

ユーザー個人のITスキルによっても、使える・使えないが変わってきます。特に、Webサービスの開発や運営の経験があるような、Web分野の知識が豊富な人の場合、一般には使いにくいものであっても推理して使いこなしてしまう場合があります。

どんなITスキルの人のためにユーザーテストを行うのかをしっかり定めましょう。

募集の方法

ユーザーの手配にはさまざまな方法があります。大規模なテストではテスターを公募したり、専門の方にリクルーティングを依頼したりすることもありますが、お金や時間がかかります。

数名程度の小規模なテストでは、カジュアルに知り合いに声をかけることもあります。社内の総務の方など、Webサービスにそこまで明るくない人に声をかけて協力をお願いするのも、一つの方法です。

今回はアクセシビリティ専門家お一人に依頼

今回の場合、アクセシビリティに関するユーザーテストですので、支援技術を知らない人がサイトを使う様子を観察しても、何が起きているのか、わからない可能性があります。そのため、支援技術の使い方を説明していただいたり、普段の利用状況も説明してもらったりできる方が適任でした。

そのため、私の知人であり、アクセシビリティの専門家・アクセシビリティの情報サイト「AccSell」を運営されている中根雅文さんに依頼しました。

ご協力いただいた中根雅文さん

中根さんは普段からスクリーンリーダーを使われており、スクリーンリーダーのデモや、ユーザーテストの経験も豊富です。単に使うところを見せていただくだけでなく、さまざまなことを教えていただける期待もあります。今回のテストには、まさにうってつけの人選ではないかと思います。

最近では、「日本視覚障害者ICTネットワーク（JBICT.Net）」という団体を立ち上げられたとのことですので、直接のツテがない方は、こちらの団体に問い合わせをしてみるとよいでしょう。

② テスト会場の手配

ユーザーの手配ができると一安心してしまいそうですが、まだ準備は終わっていません。テストをどこで実施するのかというのも重要な問題です。

大規模なテストでは、ハーフミラー（マジックミラー）を備えた専用のラボを使うこともあります。企業によっては、自社にそのようなテストルームを持っていることもあるでしょう。そういう設備がなく、コストもかけたくない場合は、社内の会議室などでも問題ありません。また、テストの目的によっては、ユーザーのご自宅を訪問して利用シーンを見せていただく場合もあります。

今回は社内の会議室を利用

今回のテストでは、社内の人に見てもらう、知ってもらうことも目的の一つですので、社内の会議室を使うことにしました。見学者を多めに収容できるように、20人以上入れる広めの部屋を確保しました。見学者を想定しなければ、もっと小さい部屋でもよいでしょう。

ユーザーテストを実施したときの実際の様子

会場までのアクセシビリティも忘れずに

なお、障害当事者の方を招く場合、会場自体のアクセシビリティに対する配慮が必要です。車椅子のユーザーの方が来場しづらい会場もあるからです。ほとんど動けない方の場合は、ご自宅を訪問して拝見させていただくこともあります。

今回のユーザーである中根さんの場合、周囲が見えないため、駅の改札で待ち合わせをして、会場まで一緒に歩いて行きました。テスト開始前に待ち合わせる想定でスケジュールを組み、待ち合わせ場所を確認しておきます。

③ テスト対象のサービスの用意

テストを実施する際には、その対象となる製品、サービスが必要です。公開前のサービスや開発中のものを対象にテストする場合、テストに使用するためのプロトタイプやモックアップを用意する必要があります。今回は、すでに公開されている「弁護士ドットコム」の本番サイトで実施することにしました。

テストに本番サイトを使えない場合もあります。たとえば、Webサーバー脆弱性診断の侵入テストのような場合、本番サイトそのもので実施すると害が出ることがあるため、検証環境を別途用意するのが普通です。その点、ユーザーテストでは普通に使うだけですから、そのような心配はほとんどありません。本番環境でテストすれば十分で、テスト対象をあらためて用意する手間は不要です。

ネットワーク環境の準備も忘れずに

そして意外と忘れがちなのは、ネットワーク環境です。テスト会場から対象の環境にアクセスできる手段を確保しておく必要があります。今回は本番環境を使いますので、ゲストWi-Fiでインターネット接続することにして、接続可能であることを確認しておきました。テスト環境を用意する場合には、テスト環境にアクセスする方法を確認しておく必要があるでしょう。

④ 使用する端末の用意

一般的に、ユーザーテストでは、アクセスするための端末をテスト実施側で用意し、それをユーザーに使ってもらうことが多いでしょう。テストの目的によっては、ユーザーに普段使っている端末を持ってきていただいて、それを使うということもあります。

普段使っているノートPCと点字ディスプレイの「Baum VarioUltra」

今回は支援技術でのテストになるため、テスト実施側で用意することが難しいという事情がありました。支援技術はその性質上、ユーザーごとにカスタマイズされている部分も多くあり、こちらで用意しても設定変更に時間がかかったり、思うようにテストが進行できない可能性もあります。そのため今回は、ユーザーとなる中根さんに普段使っているPCと点字ディスプレイを持ち込んでいただきました。

⑤ 撮影の手配

ユーザーテストの様子はメモして記録しますが、それとは別に、映像記録として動画も残しておくことが多いです。ユーザーテストの実施後、改善点を検討する際などに、後から映像を見返したくなる局面は非常にあるものです。そのため、映像はぜひとも残しておきたいところです。

以前とは違って、ビデオカメラなどを用意せずとも、スマートフォンで事足りることも多いです。ただ、バッテリー切れに備えて、電源と充電器を用意しておきましょう。必須ではありませんが、カメラを固定できる三脚やアームなどがあると良いでしょう。

また、テスト会場の様子を写真撮影して、静止画の記録を残す場合もあります。テストを実施したことを社内報などで共有したい場合、写真があったほうが便利です。ユーザーの行動を記録するというよりも、テスト実施会場の様子を伝えることが目的です。

ちなみに今回は、このテストの様子を記事化したいというもあったため、その記事に掲載する写真を撮影する意味合いもありました。

なお、ユーザーに無断での撮影とならないように気をつけてください。撮影する旨を事前に伝えて、許可を得ておきましょう。

⑥ スタッフの手配

テスト実施の際には、被験者となるユーザーの他に、テストする側でもスタッフを用意する必要があります。必要な役割には次のようなものがあります。

• モデレーター： テストの進行を行う、司会者の役割です。ユーザーとのやりとりは基本的にモデレータが担当し、事務連絡やテスト中の語りかけ、質問、インタビューなどを行います。

• 記録係： テストの結果をメモして記録する役割です。ユーザーの行動を観察し、何をしたか、どこにつまづいたかなどポイントをメモしていきます。モデレーターが記録係を兼任しようとすると、メモしている間に進行が止まってしまうことがあるため、別の人を用意することをおすすめします。

• 撮影係： テストの状況を撮影して記録する役割です。カメラを三脚などで固定できれば、常時張り付いている必要はないので、他の人が兼任してもよいでしょう。

• 見学者： 冒頭からお伝えしているように、見学はとても重要です! ぜひ見学者を手配し、見学者の席を用意しておきましょう。豪華な施設を使う場合には、テストの部屋とは別にモニタールームが用意されていることもあります。同じ部屋で見る場合は、ユーザーからは少し離れた場所で見てもらうとよいでしょう。

事前に誰が何をするのか決めておきましょう。今回は私がモデレーターを担当し、記録係と撮影係を社内の別の方にお願いしました。

⑦ テストシナリオの作成

テストの進行はモデレータが行うのですが、完全にアドリブというわけにもいきません。どういう手順でテストを進めていくのか、事前にシナリオを作成しておく必要があります。また、テストの時間は限られていますので、時間配分も考えておく必要があります。

今回は私がテストシナリオを用意しました。次のような見出しを立てています。

「ストーリーの説明」とあるのは、今回のテストにあたって用意した仮想的なバックグラウンドストーリーの説明です。漠然とサイトにアクセスしていただくのではなく、タスクを用意して実施してていただくのですが、前提となるストーリーがあると、ユーザーがタスクを実施しやすくなります。

今回は「弁護士を探す」というタスクをお願いするのですが、相談したいことが何もないのに、ただ弁護士を探してとお願いしても、どういう基準で探せばよいのかわかりません。仮想の相談ごとを用意し、それを解決してくれそうな弁護士を探す、というシナリオにすることで、自然にタスクをこなせます。

⑧ 同意書と謝礼の用意

謝礼や交通費をユーザーにお支払いする場合は、事前に用意しておきます。領収書が必要かどうかも確認しておき、必要なら用意しておきましょう。

また、未公開のサービスをテストする場合は、秘密保持契約をお願いすることがあります。必要事項を書いた同意書を用意しておき、サインをいただく形になるでしょう。この場合の同意書も事前の用意が必要です。

障害当事者のユーザーの場合、書類を読んだりサインしたりすることが難しい場合があります。不要な書類はできるだけ省き、必要最低限のものだけをお願いしましょう。

必要に応じて、モデレーターが代読や代筆といった対応をすることになるかもしれません。それで問題ないかどうか、事前に社内で確認しておきましょう。

今回は、書類は全て省くことができました。このあたりは各社ごとに事情が異なると思いますので、しっかりと確認しておきましょう。

次回、いよいよテスト本番

これで一通りの準備が整いました。内容は少々長くなりましたが、そこまで高額な設備が必要になるわけでもなく、高度な知識が必要というわけでもありません。工夫次第で、かなり簡単に実施できるのです。この記事を見て、自社でもできそうだと思った方がいらっしゃれば、ぜひ今回の記事を参考に実施してみてください。実施した感想などをお聞かせいただければ、たいへん嬉しく思います。

次回はいよいよ、ユーザーテストの本番です。実際に中根さんをお呼びして、ユーザーテストを実施した際の様子をお伝えしていこうと思います。