WEBディレクターズガイド#12「ユーザーテスト･調整」
はじめに
このディレクターズガイド記事としては11回目になりますが、途中工程を合体させたりしているので、工程としては12番目になります。（ややこしいですね。。。）バックナンバーは下記リンクから見て頂ければと思います。
残りあと4回になりますが、
・12回目/13：本アップ…本番公開時に焦った事&気を付けるべきポイント
・13回目/14＆15：請求＆運用…WEBディレクターが知っておくべきお金の話、生まれたてのWEBサイトを育てていくために
・14回目/番外編：用語集…最低限WEBディレクターが知っておくべき用語集
・15回目/最終回：あとがき…全15回を終えた所感と感想、そして自己紹介
を予定しています。
年内を目標に書き終えるスケジュール感で進めていきます。
さて本題です。
ユーザテストとありますが、今回は読んで字の如く「WEBサイト公開前に仕上がったサイトを操作してもらい、違和感などがないかどうかをユーザ（またはユーザに近い立ち位置の方々）にチェック＆フィードバックを頂く工程です。これは主に定性的な意見を集めることが目的になります。
「ユーザテストと書いているが、具体的にどれくらいの人にやってもらえばいいのか。」と思われるかもしれません。諸説ありますが、人数の目安としては基本的には5人のユーザに操作をしてもらえば課題点の85％は網羅できると言われています。
「とはいっても多い方がいいのでは？」と言う意見もありそうですが、例えば10人、20人に触ってもらったとして基本的には上がってくるフィードバックに大きな差異が見いだせなくなってくると言われています。もちろん人を集めるのにもコストはかかりますし、その辺りのROIと照らし合わせると最適な人数は5名と言われています。
なので分かりやすく「5名のユーザに操作してもらえれば85％の課題は網羅できる」と記憶しておけばよいと思います。
詳しい内容は下記に記載されていますのでご参照ください。
ここでは主な形式、やり方を順に解説します。
主な形式①：第3者に触ってもらう。
外部からリクルーティングし、本当のユーザになりえる人に操作をしてもらうという手法になります。この場合、あらかじめ場のセッティングやスケジュール、そして何を評価してもらうか？頂いたフィードバックをどう活用するか？などを設計した上で段取りを行います。予算と期間もそれなりにかかります。（目安：50万円～）自社でテスターを抱えているケースであれば自社リソースを活用すればよいと思いますが、そんなことは稀でこういった場合、外部の委託することが多いかと思います。
近年ではUIUXの概念も広まり、ここに力を入れたいというお客様も多いので予算と期間などの諸条件を満たせそうであればなるべく本当のユーザに触って頂くに越したことはありません。
主な形式②：内部に協力者を見つける
さすがに①はハードルが高いといったケースもあるかと思います。その場合、自社内にいる方に協力してもらうという手を採用するのもありだと思います。上記で最適な人数は5名と言いましたが、5名見つけられない場合もあると思います。その場合例えば3名でも2名でも構わないと思います。なぜなら絶対にやった方がいい工程だからです。
予めユーザのフィードバックを受けることにより、お客様が指定した箇所にペインポイントが発見されるかもしれませんし、公開後の提案に活用できるヒントが必ず見つかるからです。
後はどういった方を選定して協力してもらうか？についてですがこれはサイトにより様々なので一概に断言することは難しいですが、なるべく該当するWEBサイトとは無関係で、進行しているプロジェクトの対象ユーザに近い方を選ぶことかと思います。（例：新卒採用サイトであれば、入社1年～3年くらいの方にアプローチするなど、です。）
イントラで募集しても良いと思いますし、実際に声をかけてやってもらうというのもありだと思います。ちなみに私はこのやり方で見てもらう事が多かったです。
主な形式③：専門家による評価
ヒューリスティック評価やエキスパートレビューと呼ばれる手法です。プロジェクトに関係のない内部の専門家達に実際に見てもらうという形になると思いますが、実際にはチームメイトや同部署のデザイナーやコーダー、プランナーなどに触ってもらうような格好になることが多いかと思います。
もちろん上記以外にお客様に協力してもらう、などもあるかと思いますが、このユーザテストについては客観的な立ち位置が重要なので、可能であれば制作者サイドを行った客観的な結果をお客様に出すようにした方がいいです。なぜならばお客様に協力して頂いた場合、中身やデザインなど、本来の趣旨とは異なる部分への指摘が入ったりするので、ユーザテストとして成立しづらい側面があるからです。それでは次に、やり方について触れたいと思います。組み合わせに関しては、適宜変えて頂ければと思います。
手法①：思考発話法＋インタビュー
色々なやり方がありますが、例えば目の前（リモート）でユーザが操作しているところを見ながらテストがやれるのであれば、思考発話法（ユーザにタスク（課題）を提示し、その実行過程において考えていることを話しながら操作してもらう手法です。ユーザの行動と発話から、インターフェース上のどの部分に問題があるのか、なぜその問題が起きたのかを詳細に把握できます。）が良いと思います。
事前に許可を頂いた上で操作している様子を記録させてもらい、問題点を抽出します。そして実際に触ってもらった後に、所感をインタビューしペインポイントを深堀るような流れになるかと思います。
定性的な情報を収集するのに適しているのではないかと思います。上記の形式①、形式②と相性が良いです。
手法②：採点式
予めアンケートなどを準備し、操作をしてもらったユーザに点数をつけてもらうやり方です。一口にアンケートと言っても、このアンケートの取り方が難しいので突き詰めると十分な設計を行った上で行う必要もあるのですが、このユーザテストはどちらかと言うとその場で触ってどうか？という短期的な評価になるので、以前このガイドでも触れたSUS（System Usability Scale)などの手法を活用すると良いと思います。
アンケートを作ると言っても、そこには必ず設問作成者の意図、仮設、バイアスが含まれるので、ユーザの回答を誘導しないよう注意しつつ、汎用的な指標を使う方がより客観的な目線で見ることが出来ると思います。
ユーザの回答を誘導する設問のアンケートですと仮に1万通集まったとしても、あまり意味をなさなくなってしまう恐れがあるからです。
上記のすべての形式において活用できます。
手法③：チェックリスト
これはどちらかと言うとエキスパートレビューでしか活用しづらい手法かもしれませんが、JIS-Z8521やJIS-X8341-3の項目に沿ってチェックしていくやり方です。この場合予めテスト用にチェックリストを準備しておくことをお勧めします。私の場合はJIS-X8341-3に沿ったチェックリストを用意し、チェックを行っていました。ユーザビリティやアクセシビリティを客観的な指標で見ることができるのでよいと思います。
テスト実施後の調整
程度はさておき、ユーザよりフィードバックを頂いた後は、フィードバック内容を取りまとめます。この場合落とし穴になりがちなのが「もらった指摘をすべて反映させようとする事」です。
気持ちは分からなくもないですが、これは考えることを放棄しているのとほぼ同義です。分析を行い、取捨選択を行う事でより効果的な改善が見込めます。
具体的にはもらった課題を分類し、優先度付けを行い、客観的な視点のレポートとしてお客様と共有し、どうするかを話し合い、時間や仕様などの諸条件と照らし合わせながら対応可否を決めていきます。ここでなんでも受け入れてしまうのは、やはり難しいのかなと思います。
もう一つ付け加えると、よくあるフィードバックですが、取り入れるべきでない意見としては「表現に関する意見」です。これは以前下記の記事でも書いたのですが、この記事の中の美的ユーザビリティ効果にテスターがはまってしまっていたりすることも考えられますし、そもそも十分な設計と協議を経た上でこのデザインになっているので、「色がどうとか」「かわいいデザインがどうとか」そう言った意見は取り入れる必要はないという事になります。
最後に
いかがでしたでしょうか。ユーザの定性調査は奥が深いですが、やり方自体にそれほどパターンがあるわけではないので、肝心なのは洞察力と審美眼になってくるかと思います。
諸々の条件においては、もしかしたら削らざるを得ない工程になってしまうかもしれませんが、削ると公開後に怒涛の修正対応がやってきたりすることもあったりするので公開前にお客様と仕上がっているWEBサイトに関する懸念などを共有しておくのはとても大切だと思います。
この工程を踏んでおくことで、お客様に防御力（社内関連部署からやってくる有象無象の指摘）を与えることにもなりますし、しいては円滑なプロジェクトの進行にも一役買う事になります。
次回は、エピソード的な回になりますが「Webディレクターズガイド#13：本公開～最後の落とし穴にハマらないために～」を書きたいと思います。
ありがとうございました！