はじめまして、KINTOテクノロジーズでUIデザイナーをしている青嶋と申します。
普段は業務用アプリケーションのUI周りを担当をしております。
少し前になりますが、弊社サイト改修の参考にしてもらうべく、サイトでお客様がどの様に振る舞っているのかを調べるため、ユーザビリティテストを実施しました。
テストのテストといった意味合いもあったので被験者を社内で募り小規模に行ったところ、きちんと考察に値するデータを得ることができましたので今回はテストの概要と実施時の工夫について書きたいと思います。

ユーザビリティテストとは

まずユーザビリティテストとはテストと言っても合格や不合格を判定するためのものではなく、ユーザビリティという概念に欠かせない3つのポイントを見定めるためのテストです。
ですのでまずユーザビリティという概念について説明します。

ユーザビリティの定義

ユーザビリティという言葉自体は使い勝手とか使いやすさなど漠然とした意味合いで使われることが多いと思いますが、実は国際規格 ISO 9241によって、次のように定義されています。
「ある製品が、特定のコンテキスト（利用状況）において、特定のユーザーによって、特定の目的を達成するために用いられる際の、効果、効率及びユーザーの満足度の度合い」
そして効果、効率及びユーザーの満足度という3つの項目は以下のように説明可能です。

1. 効果（effectiveness） : ユーザーが目標を達成できるかどうか。（例：ECサイトならちゃんと買い物ができるかどうか）
2. 効率（efficiency） : ユーザーが目標を達成できる場合に、無駄な手順を踏まずなるべく最短経路で目標を達成できるかどうか。
3. ユーザーの満足度（satisfaction） : 効果や効率に大きな問題がなかったとしても、ユーザーがどのくらい不愉快に思わずに操作できたかの度合い。
   例えばECサイトならばそもそも買い物という目的が達成できなければ、ユーザビリティが低いもしくは無いことになります。そしてもし目的が達成できたとしても、なかなかお目当てのものにたどり着けないなど無駄な手順が多ければ、同じくユーザビリティが低いということになりますし、その他の原因でイライラしてしまうなど不快な思いをすればその分ユーザーの満足度は低くなり、同じくユーザビリティが低いということになります。
   その様な状態のまま放置しておけば、いずれライバル企業やライバル製品に大切なお客様が流れてしまうという自体を招きかねません。
   そうならないためにも製品の取り扱い時やサイト上でお客様がどう振る舞っているのかを知り、ユーザビリティを考えることはとても大切なことではないかと思います。

ユーザビリティテストにできること / 目的

お客様が不快な気持ちにならず、むしろ喜んで製品やサービスを利用していただくことが会社の営利活動の礎となるので、製品やサービスに問題点があったらそこを改善していくべきです。なのでまずは問題点を明らかにするべきところから始めていくわけですが、幸いにもすでに分析グループによるお客様アンケートが存在しており、サイトのどこが分かりづらかったのかというピンポイントの設問がありましたのでそれを参考にさせていただきました。

そしてその問題となっているポイントでお客様がどの様に振る舞っているのかを知ることができれば、なぜそこが問題点となっているのか？のヒントに繋がっていくと考えられます。そのヒント集めがユーザビリティテストにできることだと言えます。
例えれば、アンケートは学生時代の英語のテストと同じようなもので、リスニングがだめだった、文法がだめだったなどどこが悪かったのかを導き出すことを得意としているのに対して、ユーザビリティテストはではなぜそこが悪かったのか？という理由やどうすればよくなるのか？のヒントを導き出すことを得意としていると言い換えることが出来ます。

テストを行う前の準備

タスクや条件を設定

まず最初の準備としては、アンケートによると年齢層に関係なくサイト上で分かりづらいと感じる箇所があるようでしたので、そこを中心に「効果」、「効率」の2つのポイントをテストするためにタスクや条件を設定しました。
このタスクや条件の設定は2つの点で大事だと言えます。まず一つは、被験者に自由に操作してもらっても問題点にふれることなく終わってしまうかもしれないというので、それを防ぐという点。2つ目は様々なリテラシーの方々に同じ条件の下で考えて操作してもらうという点です。

台本・質問・アンケートを用意

次なる準備として、テスト内容を被験者に説明するための台本と彼ら/彼女らのバックグラウンドやリテラシーを知るための質問表、さらにテストが終わった時に行ってもらうアンケートを2種類用意しました。
被験者の方達に安心して参加していただくためにも、テストの前に内容や流れをきちんと説明してあげる必要があります。さらに被験者のバックグラウンドやリテラシーに迫るための質問も行いますので、漏れなく速やかに説明・進行するためにも台本は必要です。アイスブレイクやらなんやかんやで割と時間がかかってしまう場合もありますので、できれば進行の時間割もしておくほうが良いと思います。
テスト終了後に行うアンケートというのは先述の3つのポイントの最後の項目である「ユーザーの満足度の度合い」を図るためのもので、CSAT（CUSTOMER SATISFACTION SCORE）とSUS（SYSTEM USABILITY SCALE）という指標を用いました。CSATは顧客満足度と呼ばれる調査で使われることが多く、満足の度合いを5段階で評価するものです。一方のSUSはわかりやすさや難しさなどの受け止められ方を指標化したもので、いわゆるUXの評価指標としてひろく使われているものです。ちなみにSUSでは導き出される点数が68点以下の場合ユーザビリティを見直す必要があるという基準があるところが分かりやすくて重宝されている理由ではないかと思います。

デバイスのセッティング

最後の準備として、テスト時に被験者の表情や操作の様子を録画するためのスマホとノートPCを用意します。スマホでは手元の操作を、PCでは顔の表情を録画させてもらいますのでそれぞれセッティングを行います。テストが始まったら両方のデバイスでウェブ会議ツール（Microsoft Teams）にログインし録画機能を利用して録画を開始します。（この録画機能は撮影終了後クラウドに自動的に保存されて、しかも自動的に2画面になっているので非常に便利です。）
ちなみにスマホスタンドは100円ショップで購入したものを利用しました。
余談ですが一昔前は手元撮影用と表情撮影用でビデオカメラを2台使用し、撮影したデータをローカルに保存して、2画面同タイミングで見比べられるように編集して、、、など行っておりましたので、数年前に比べて遥かに簡単にテストが行えるようになったなぁと少々感動しました。

テスト実施

ここまで準備ができたらついにテスト実施となります。
アイスブレイクもそこそこに説明・質問とを行って、サイト操作によるタスクの実行に移っていきます。
テスト自体は思考発話法で行いました。この方法は被験者に操作を行っていただきながらその時思ったことを口に出してもらうという方法です。平面的な映像情報と、思ったことの発話という音声情報により、立体的に振る舞いを把握しようという方法です。

テスト時の注意点

この時に気をつけなければならないことが2つあります。
一つは、被験者は操作をしながら頭に浮かんだことを発話するということに慣れていないので、黙ってしまわないように常にどう思っているのかをインタビューアーが促し続けていく必要があります。
もう一つは被験者がインタビューアーに質問をすることがよくあるのですが、それはなるべくスルーしなければならないということです（無視ではないです）。
事前の説明では、「被験者が上手にサイトを使えるかどうかのテストではなく、サイトが分かりやすいか難しいかなどを判断するためのテスト」だということを必ず伝えるのですが、それでも被験者は自信のない場面では何気ない気持ちで質問してしまいたくなるものです。しかしそれに答えてしまうとバイアスがかかってしまうこともあるので、答えても差し支えのない質問なのかどうか判断して返答する必要があります。
そしてタスクを終えてアンケートも記入していただいたら、テスト終了となります。

考察に向けての準備

テストが終わったら、次に考察へ向けての準備が始まります。
テストが終わって一段落と行きたいところですが、ここからがむしろ時間がかかる工程となります。
まずやることとしては、文字の書き起こしです。

情報共有のために

テストの音声データは一人につき20分〜30分くらいなのですが、聞き取りにくい部分は何度も巻き戻したりすることで結構な時間がかかります。ここが一番骨の折れる作業と言えかもしれません。しかし時系列的な音声情報を平面的な文字情報に変換することで、情報共有が一気にやりやすくなるので、ここは未来のために我慢して黙々とやり続ける必要があります。（音声を自動でテロップ化してくれる機能はまだまだ使い物にならない印象でした。）
次にその発話内容をカテゴリ分けしたりタグ付けしていくなどして分類可能な状態にします。
最初にスプレッドシートなどでまず時系列的にまとめておいて、その後にmiroなどのツールにコピペしていくことで、複数人数の行動データを俯瞰的に眺めたり、様々な軸でまとめたりすることが可能になります。
さらに情報共有をするならば映像データを短く編集しテロップを付けておくことで、テストの様子も簡単に共有することが出来ます。時間的に余裕がある場合はそこまでやってもいいかもしれません。
この時のテストは被験者が5人というごく限られた人数だったこともありそこまで行いましたが、これも非常に骨の折れる作業でした。

考察から改修へ

本来であれば得られたデータを元に複数人数で考察を行い改修へとつなげていくのですが、この時はテストのテストというレベルでしたので、自分の考察をまとめレポート化し一旦ここで終了となりました。
議論のできる人数でステークホルダーを集めて、意見を交わし考察する。そういった工程を経ることで同じ目線で改修へと繋げていくことが可能になるかと思います。ここに書いてきた全てはその為の準備です。

最後に

今回はサービス全体の一部であるウェブサイトの更にその一部分をフィーチャーしてテストした時のことを例に書かせていただきました。そんな一部分のテストにもこうした時間のかかる準備が必要になるわけですが、こうした小さな積み重ねの集積がお客様のサービス体験につながっていくと考えております。
世の中の変化やお客様の要求にすこしでも応えるため、ウェブサイトの進化を支えていけるよう尽力できればと考えております。そしてこの内容がこれからテストを行いたいと考えている方の何かの参考になれば幸いです。