「ユーザーの声を聞く」について同期の仲間と考えてみた
はじめに
入社2年目、メディア事業本部 サービス開発部の鍛冶です。
（本稿は朝日新聞社の2024年のQiitaアドベントカレンダーの投稿です）
昨年9月に現在所属しているチームに配属されました。所属チームでは様々なサイトの構築、保守・運用を行っております。その中で、自身が深く携わったユーザーテストについて書いてみようと思います。
さらに飲み会時、他部署に所属している技術部門の同期も似た業務を担当していることが発覚！せっかくなので、ユーザーテストを担当する中で自分なりに学んだノウハウを使って、インタビューをしてみました。
ということで、構築するサイトや体制・目的の違いによって、異なる点・共通している点はどこなのか、実際の経験から感じたことや学んだことも含めてお話できればと思います。
私が学んだユーザビリティ
ユーザビリティ≠使いやすさ
配属されて間もない昨冬のある日、先輩から「サイト開発を進めていく上で、想定されるターゲット層の方に実際にサイトを触ってもらって意見を聞きたい。ユーザーテストをやってみてほしい。」という一言が。
ド新人鍛冶、お恥ずかしながらユーザーテストという言葉自体は聞いたことがあったものの、一体何から始めればいいの…というレベルから始まりました。先輩からユーザビリティエンジニアリングの本を貸していただき、勉強開始です。
そもそもユーザビリティという言葉もまた、「ユーザーの人が使いやすいかどうか」となんとなくで捉えていました。しかし「ユーザビリティ＝使いやすさ」という考え方では、「ユーザーフレンドリー」"ユーザーに対する思いやり"と混同してしまうと、この時初めて知りました。"あれば嬉しいけどなくても困らないもの"と認識してしまうと、優先順位を下げてしまい、後々大きな問題を引き起こしかねません。本の言葉を借りるのであれば、ユーザビリティは「使いやすさ」ではなく、「使用可能性」と捉えるべき大切なことなのです。
いざテスト実施
ユーザーテストとひとくくりで言っても、サイトを開発していく上でプロトタイプテストとユーザビリティテストの最低2回は行う必要があります。プロトタイプテストは早い段階で、紙芝居形式でもいいのでデザインをつなげて、開発を進める前に大きな問題がないか確認します。ユーザビリティテストは、ある程度出来上がってきている段階で、プロトタイプテストで出た問題点が改善されているか、総合的に操作やデザインに問題がないかなどを確認します。
テストの実施の流れは次の通りです。
評価ポイント・ヒアリングの観点の設定
「何を知りたいのか」「どういった観点でインタビューするのか」を考えます。概要設定
人数・場所・実施時間などを考え、準備を開始します。テスト範囲や伝えるタスクの設定
サイト全体を見てもらうのか、それともページを絞るのか、絞るならどのページでどんな操作をお願いするのかなどを考えます。例えば、"会員登録作業を完了してみてください"と、タスクを絞ってお願いすることもあります。テストの実施
結果の共有
インパクト分析と呼ばれる発生頻度と重要度の軸で課題を整理する方法を使用しました。
案外難しい…ユーザーテストのポイント
ユーザーテストにも様々な方法がありますので、サイトの内容やテスターの方の言動・行動に合わせて観点にとらわれすぎず、柔軟に対応する必要があります。その上で私が大切だと思ったポイントをお話します。
思考発話法
後で確認しようと思っていると小さな気づきを見逃してしまうことがあるため、思ったことは何でもその都度独り言のように発話してもらいます。操作中は口を出さない
テスターの横で操作に詰まっていた部分はどこかなどを見ておきます。「ユーザー自身で操作を達成できなかった」ということがあった場合にはそれも立派なテスト結果となるからです。あくまでもテスト対象はサイトであることを伝える
操作している時に横でジーッと見られていると自分がテストされているように感じてしまうので、テスト前にきちんと伝えておく必要があります。あえてざっくり質問する
初めは「実際に触ってみてどうでしたか？」くらいの粒度で聞くと、サイトに対してプラスかマイナス、どちらの印象が強かったかなども引き出すことができます。
同期が登場！頼れる存在、Yさん。
同期の仲間にインタビュー!?
前述のようなことを意識しながら、何度かテストを担当して現在に至ります。そんなある時、同期入社の仲間たちと久々の飲み会。それぞれが最近担当している業務の話題に…。私は担当業務のひとつとして、ユーザーテストを挙げたのですが「私も！」と、ある同期からの声が。
朝デジ事業センター開発部のYさんです。同じく入社2年目、技術部門の同期の中で姉貴的頼れる存在です。案外それぞれの業務内容は知らないもので、近い業務をしていたことに大盛り上がりでした。「気になることが沢山あるから後日インタビューさせてほしい。」とお願いすると、快く了承してくれました。さぁ今まで学んできたインタビューのノウハウを使って知りたい情報を聞き出すことはできるのか！
ついにインタビュー。そもそもユーザーテストなの？
ついにインタビュー当日。同期の仲間にインタビューをするのは初めての経験でなんだか緊張しました。まず私の経験を話しつつ、Yさんがどんなユーザーテストをおこなっているのか教えてもらおうと考えていました。しかし、ここで大きな落とし穴！飲み会では具体的な話はせずでしたので、ほぼ同じような方法で「ユーザーの声」と向き合っているとばかり思っていたのですが、お互い話すうちに2人の中にこんな疑問が生まれました。
「これ、そもそもユーザーテストなの？」
最終的なゴールは「実際に使用してくれるユーザーの声を聞くこと」で、サービス向上に繋げるという点では非常に似ています。しかし根本的に私は開発段階でのテスト、Yさんは既に完成しているサービスにおけるインタビューであり、取り組んでいた内容がかなり異なっていました。あくまでも感覚ですが、私は「テスト」、Yさんは「ヒアリング」に近い気がしました。早速大きな違いを見つけました。当たり前かもしれませんが、ゴールは同じでも、対象サイトやフェーズの違いにより、こんなにも違うのかと驚きました。
それぞれの取り組みと違い
課題の明確化とタイミング
Yさんが行っているユーザーヒアリングにも様々な種類があるようですが基本的には以下のように進めていきます。
社内での現状の課題を整理
課題について仮説を立てる
インタビュー
仮説が正しかったのか・課題の根源はどこにあるのかの検証
だからこそ最初にできる限り絞った状態で課題を見つけ出し、それに沿ったインタビューをおこなう必要があります。
ここが一番の大きな違いだと感じました。
私は開発途中でのテストのため、現状の課題が基本的にはありません。どちらかというとユーザーテスト自体が課題を見つける作業だからです。
課題をどれだけ明確化するのかと、明確化するタイミングがそれぞれ違うので、内容によって対応していくことが大切です。
目撃者の増やし方（対面 vs オンライン）
私が先輩に貸していただいた本には「目撃者を増やす」ことの大切さが書かれていました。実際に見学すると、どんなに衝撃的な結果であっても受け入れざる得ないものになるため、目撃者が多ければ多いほど重大な意思決定が迅速に可能になります。
ただ、私には実際に何度かテストを行なってみて感じることがありました。それは大人数の目撃者による「視線」と「圧」です。ひとりのインタビュアーが横で見てメモを取っているだけでもテスターの方からしたら気になるはずなのに、それに加えて大人数に見られるとなると、目撃者側はプレッシャーをかけているつもりなど一切なくても、かなりの緊張感のある空間になってしまいます。ですので、実際にテスターの椅子に座ってみて視線を感じづらい配置を考える、テストに立ち会う方には最初に自己紹介をしてもらう、テスト中は口を出さずに見ておくなどの対策を行なっています。Yさんにどのような対策しているのかを尋ねたところ、基本インタビューはオンラインで行うとのことでした。
オンラインにすることで、顔を見せる人間はインタビュアーひとり、それ以外の目撃者は静かに見ておくことができ「視線」や「圧」を感じずにテスターの方が話しやすい環境を作ることができます。オンラインだとテスターの方とのコミュニケーションが取りづらいかと考えていましたが、オンラインだからこそのメリットもあると学びました。しかし一方で、やはり実際に操作をお願いすることは難しい場合も多く、Yさんが画面を共有し「この操作の場合はどのボタンを押しますか？」と質問をしながら進めていくこともあるそうです。一長一短だなと感じました。一つ前でお話した「課題の明確化」がされているのかどうかによって考えていくのがいいのかもしれません。
共通点が見つかった！
話していくうちに異なる点が多くあることに気づきましたが、共通点もありました。
誘導と具体例の難しさ
インタビューをする際に難しいと感じる点について共通している部分がありました。テスターの方はただでさえ、慣れない環境で見られながら操作することに緊張や戸惑いを感じていることが多いです。その上、私は特に開発途中の場合が多いので、サイトに触れたことがないテスターの方の不安を少しでも取り除いて操作をお願いすることが大切です。そこで心がけているのは具体例を挙げるということです。具体例と言うと聞こえがいいですが、ちょっとした演技を入れます。
例えば、思考発話法でテストを行うという話をしましたが「思ったことは何でも声に出してください」と言うだけだと、「わかりました」と言っていても大半の方が結局感じたことを口に出してくれません。ですが不思議と「"このボタンわかりにくいなぁ"とか"ここ面白い"とか、なんでも構いません！」と少し具体的な例を出すだけで、その後のテスターの動きが大きく変わります。Yさんも同じように、具体例を入れることを心がけていました。しかし、一歩間違うとテスターの意見を誘導する行為になりかねません。そのバランスに注意しながら取り組んでいました。
小さな気づきを見落とさないために
「ユーザーの声」を聞くことの大切さを2人とも共通して感じていました。気づきさえすれば簡単に修正できるような課題であっても、開発側では当たり前になってしまっていてなかなか気付けないことが多いです。
過去のインタビューで、多くのサイトにある利用規約などの同意チェックボタンで、必ずチェックを忘れてしまうという意見がありました。一つ前の画面に戻され「入力項目にエラーがあります」といった旨の表示が出るため、何度も入力した内容に誤りかないか見返すが、結局同意チェックができていないだけだったということが多いそうです。少しチェック欄や文字を大きくするだけで改善できるかもしれないことですが、開発側は気づきにくいと感じました。サイトをより良いものしていくために、ユーザーだからこその気づきを見落とさないことが大切です。
全てを改善しようとしないこと
一方で、インタビューで出た意見を全て反映することが正解でもないという認識も2人とも共通していました。テスターの方は意見を言った方がいいと、絞り出して悪い点を挙げてくださっている場合もあります。Yさんも「こういった機能があればいいなぁ」と言われることがよくあるそうです。貴重な意見であることには変わりありませんが、本当に必要な機能や修正なのか、注目すべきポイントとずれていないかを確認すべきです。新たな機能だけでなく、課題の本質を深く見ることも大切です。
おわりに
「ユーザーの声を聞く」について感じたこと
ファクトを集めてからインタビューに入るYさんに比べて、私はファクト集めを目的としたインタビューを行っていると感じました。ユーザーの声を聞くことで見落としがちな課題に気づくことができる一方で、インタビューで出た意見を全て反映させることが正解ではなく、本当に必要な修正・追加機能なのかなどを一度立ち止まって考えることも忘れてはいけないと学びました。
同期にインタビューしてみて
普段、互いの業務内容について具体的に話すことは案外少なく、大変勉強になりました。同期の仲間がどのように仕事に向き合っているのか知ることは自身のモチベーションにも繋がり、大変有意義な時間だったと感じます。定期的に学んだことを共有する時間を作りたいね！という会話もYさんと交わしました。こうして、快く協力してくれたYさんに感謝です。
今後もユーザーテストに関わらず様々な業務を経験し、多くのことを吸収していきたいです！