こんにちは、HOME'Sでマークアップをメインに最近は担当サービス全体の改善などいろいろやっている、オガワです。
突然ですが、みなさんは「テスト」って言葉にどのような印象を持っていますか？
私はこの言葉を聞いただけで気分が沈みます。学生時代の苦手な教科の問題用紙を思い出します。そのせいなのか「ユーザビリティテスト」という言葉があまり好きではありません。
「ユーザビリティテストのテスト対象はサービスだ」ということがわかっていても、「テスト」という言葉をきくと、なんとなくテストしている人の能力を試されているような気分になってしまうのです。
なので、自分がユーザビリティテストを行うときはなるべくこの言葉を使わないようにしています。
さて、どういう言葉を使うようにしているか？とのまえに、私が行っている業務についてお伝えしたいと思います。
ユーザビリティテストを行う事になった経緯
私はクライアント向けのサービスを開発しており、開発したサービスの利用者はクライアントになります。
開発したサービスは直接クライアントにご利用いただいていますが、そのサービスをクライアントに説明したりサポートをしている営業メンバーやカスタマーサポートのメンバーがいます。
「提供するサービスは利用者に優しいことはもちろん、関わる社内メンバーにも優しいサービスにしたい。そのためにメンバーの業務を知ろう。（あわよくば営業メンバーとクライアントの橋渡しとなるようなサービスにしよう）」と思い、営業メンバーへのヒアリングを行ったことがあります。
なぜヒアリングを行おうと思ったかというと、私が所属している部署はものづくり職種で構成されており、営業職種は異なる部署なので、お互いの業務のことを理解しあっているとは言いがたい状況です。
私は特に、、、ということかもしれませんが、今まで営業職を経験したことがないので、営業メンバーがどうクライアントと関わっているか、どういった思いで営業をしているのかを想像してもよくわからないというのが本音でした。
幸い開発中のサービスがプロトタイプとして動かせるような状況になったこともあり、利用者のことをよく知る営業メンバーへヒアリングを行いがてら、開発中サービスのユーザビリティテストを行うことにしました。
期間中の全体的なスケジュール
当初からできるだけ多くの営業メンバーに参加してもらおうと思っていたので、継続的に行えるスケジュールをたてる必要がありました。
そのため、営業メンバーの通常業務サイクルになるべく影響が出ないようにヒアリングする日程を決め、その日に2~3名のメンバー個別にヒアリング＆ユーザビリティテストを行うことにしました。
そのとき計画したユーザビリティテストのざっくりした流れはこちらになります。
テスト設計をし、2~3名のメンバーにその内容をテスト、そのテスト結果を分析、の流れを一週間とし、このパターンを数ヶ月続ける計画をたてました。
実際、数回テストを続けると、次のような流れができてきました。
テスト設計からテストを行い、その結果をうけ、改善が必要な箇所に改善案を仮実装、次週に同じ内容でもう一度テストを行う。そして改善されたか確認し、改善された内容を本実装していく流れです。
実際には継続的にテストを続けていったので、このような流れになりました。
仮実装したものを本実装する期間と、次のテストの設計期間を同時並行ですすめ、その週はテストを行わない。次の週に設計したテストを行い、、、、というサイクルです。
テストを行わない週をつくった理由は、次のテスト設計をするためでもありますが、仮実装で結果が良かったものを本実装する際にリファクタリングする期間を設けたかったからです。
仮実装したものをそのまま本実装していくと、バグが発生しやすかったり理解や修正が難しいものになってしまうことは今までマークアップをやってきた経験上明らかでした。
あとでリファクタリングできる期間があるとわかっていれば、仮実装の段階ではスピードを優先して開発ができます。
次のユーザビリティテストへ向けた結果分析と改善案仮実装の時期と重なった期間ですが、本実装へのリファクタリング期間を設けたことは、仮実装のスピードを速める結果となりました。
このようなパターンで数ヶ月、途中スケジュール的にきつめな時もありましたが、できる限りこのスケジュールを続けていきました。
継続的にユーザビリティテストを続けてみてよかったところはかなり多くありましたが、今回の本題からは外れてしまうので、またの機会があれば紹介したいと思います。
ユーザビリティテストの内容
今回の目的が「営業メンバーへヒアリングを行いがてら、開発中サービスのユーザビリティテストを行う」といったものだったので、営業メンバー1人1人別々に時間を用意し、じっくりとお話をうかがうことにしました。
1人に対して60分。内訳は業務のヒアリングを20分、開発途中のプロトタイプを触ってもらうのに15分、プロトタイプの感想とともにヒアリングを20分というのが主な流れでした。
15分のユーザビリティテストでは行えることがかなり限られてきます。
そのため、テストをする機能をひとつに絞り、その機能を使う利用者の状況をシナリオに起こすといったテスト設計を行っていました。範囲を小さいテストに設計したことが、何度もテストを行うことを可能にしていたと思います。
また、時間の比重をご覧いただくとわかる通り、ユーザビリティテストというよりも、業務内容のヒアリング中心の時間配分になっています。
ということもあり（やっとタイトルに関係した内容になってくるのですが）「ユーザビリティテスト」という言葉を営業メンバーに伝えることに非常に抵抗を覚えました。かといって「ヒアリング」という言葉では営業メンバーに『何のためのミーティングなのか』が伝わらないなと思い、なんとか一言で簡潔に伝わる言葉はないかと考えました。
「ユーザビリティテスト」のかわりに使った言葉
前にも書いたように、今回の目的は「営業メンバーへヒアリングを行いがてら、ついでに開発中サービスのユーザビリティテストを行う」ことでした。
もう少し詳しく営業メンバーに開発中サービスをつかってもらう目的を整理すると
- 開発中サービスを肴にしてクライアントや営業メンバーの業務について気軽に話してもらいたい
- 開発中サービスの基本的なユーザビリティーの問題点もみつけたい
です。
ユーザビリティテストではない、単なるヒアリングでもない、どういう言葉がしっくりくるだろう？と考えた結果、この時は「開発中サービスのトライアル」という言葉を使うことにしました。
さいごに
様々な目的で様々な手法が紹介され、社内でも多くの手法が広く使われるようになってきたなと感じています。手法のやり方を知ると、その手法を行う目的が曖昧になったり、その手法を使う目的を共有できているつもりになってしまうことがあると思います。
「ユーザビリティテスト」という言葉ひとつとっても目的は多種多様です。
今回紹介したプロジェクトではかなり大掛かりに社内ヒアリングを行いましたが、この案件以降もプロトタイプを使っての社内ヒアリングを気軽に行うことは多くあります。
その際も「ユーザビリティテスト」という言葉は使わず、「こういう目的（課題）のためにプロトタイプを使ってみてほしい」と目的を伝えるようにしています。
「何のためにこの手法を使うのか」、それを自覚し、チームメンバーに共有する意味でも、あえてその手法名を使わず『目的にふさわしい言葉を使ってみる』というのも良いのではないのかな、と思っています。
