2022年7月25日に開催したCREATORs meetupは、ユーザビリティテスト（UT）の現状と必然性について、3名の登壇者の方々にディスカッションしていただきました。
何となく必要だとは感じているけれど、費用や工数の問題で実施できない。実施してもいまいち効果や価値がわからないまま終わってしまう。そんな悩みを持っている方々に向けて、ユーザビリティテストに対する考え方をたっぷり議論していただいています。
後半は、UX DAYS TOKYOのオーガナイザーである大本あかねさんによるLTも実施。ユーザビリティテストで陥りやすい罠ワースト10を発表いただいたので、ぜひチェックしてみてください。

＜パネラー＞
●生谷侑太郎氏
●北村竜也氏

＜モデレータ＞
●大本あかね氏

人それぞれで考えているユーザビリティテストってなんだろう？

仮説を持った上で「ユーザーがプロダクトを使えているかどうか」を確認する

大本：事前の打ち合わせで「ユーザビリティテストってふわっとしているよね」という話が出たため、最初のトークテーマを設定させていただきました。生谷さんからお話しいただけますでしょうか？

生谷：ユーザビリティテストは「このプロダクトが良いものかどうか、テストや検証をしたほうがいい」というざっくりしたものではあるのですが、人によってさまざまな話が入り混じります。
ユーザーリサーチの話を中心にする人もいれば、MVPの仮説検証をメインで考えている人もいれば、ある程度運用が回っているプロダクトをきちんとユーザーが使えているのか、ネガティブ面をチェックするために実施する人もいます。
私がフリーランスとしてお客様とお話をするときは、上記のうちどこが足りないと思っているのか、範囲を上手く擦り合わせています。

大本：ユーザビリティテストがある種のリサーチになったりもしますよね。北村さんはいかがですか？

北村：そもそも仮説があるかどうかが非常に大事です。仮説を持ちたい段階であれば、必要なのはユーザビリティテストよりもエスノグラフィーなどの観察フェーズです。仮説をきちんと持った状態で特定のタスクをこなせるかを確かめるのであれば、ユーザビリティテストをすることになります。
何を検証したいのか、入り口から入ると今自分たちが何をすべきなのか、クリアになりそうですね。

ユーザビリティテストに何より必要なのは検証の目的

大本：今回事前に参加者50名弱にアンケートをさせていただいたのですが、結果を見て「ユーザビリティテストはあまりやっていない」という肌感覚がありました。私自身、プロダクト開発に入っても必要そうなタイミングでユーザビリティテストをやらない、あるいは最後に取って付けたようにやってしまうことが多いと感じるのですが、そのあたりはいかがでしょうか？

北村：ユーザビリティテストでそもそも何を検証したいのか、目的がはっきりしていないと、取って付けた感じになってしまうのだと思います。
「やらないよりはやったほうが絶対に良い」という立場でプロジェクト全体の計画の中にユーザビリティテストを組み込んでもらうのが一番いいのですが、そのときにリクルーティングや費用がネックになり、「やり方がわからないから後でやろう」になってしまうのかなと。

ユーザビリティテストを実施した結果得られる効果

100点満点のプロダクトではないならユーザビリティテストは必須

大本：アンケートの中では、「ユーザビリティテストに効果がある」と回答した方はたった2名だけでした。ユーザビリティテストに対する価値がまだ世の中には浸透していないと強く感じたのですが、お二人はユーザビリティテストの価値をどのように伝えていますか？

生谷：私が毎回言うのは、「ユーザビリティテストをしないのは、お客様がプロダクトの機能や使い勝手を存分に享受していて、すでに100点満点だからである」という前提の話です。それは過信に満ちていますし、非合理的ですよね。私たちはどこまでいってもサプライヤーなので、見落としは100％あります。
にもかかわらず、リリース前にテストをしない、リリース後に定期チェックもかけない、「なぜ100点だと思っているのか」という問いに回答も返ってこない。これはビジネスを行う姿勢としては正しくないと伝えます。

大本：北村さんはいかがですか？

北村：価値を誰が判断するのかというポイントが一つありますね。開発やデザイン部署なのか、あるいは経営陣なのかによって多少違いが生まれます。
特にトップが判断する場合は、成果物がリリースされた後の数字で評価されます。数字が低いと「ユーザビリティテストをやっていないからだ」「開発が甘かったからだ」といった話につながる。ただ、ユーザビリティテストは実際にはリリース後にやるものではありません。私はもっと荒い、ワイヤーの状態でもいいから、最初にやるべきだと考えています。早めに気付けば余計な工数がかからず、ユーザビリティテストの価値も生まれてくるでしょう。

ユーザビリティテスト実施のために重要なチームビルディングとアジャイルマインド

大本：特に日本では、ユーザビリティテストがきちんと行われていない現状をよく目の当たりにすると思うのですが、そういうときは皆さんどうされますか？
「やりたいけどできない」理由として工数や費用の話が出てきますが、実際のところプロダクト開発に関わっていない人であれば、そのへんにいる人をつかまえてゲリラ的に行ってもわかることはあると思うんですよ。結局ユーザビリティテストの価値がわからないし面倒だから、やらない理由としてコストや費用が持ち上がるのかなと。このあたりの突破口はありますか？

北村：インタビューをするにしても、想定するペルソナにハマる人がいないケースは多いです。ただ、意外と近しい属性の人ならペルソナに「なりきれる」ので、気軽に人を集めるところからチャレンジしてほしいですね。

生谷：外から人を呼べないなら、メンバー内でやってしまうのが一番簡単なやり方かなと。私が以前手掛けていたサービスはリリースサイクルが週2回で、リリース前日や前々日に30～40分程度、全員参加のユーザビリティテストをしていました。メンバーがユーザーになりきって10分間ロールプレイングを行い、終わったらSlackに思ったことを書き溜めて、そもそもリリースをするかどうか、あるいはどこまで修正するかを判断します。全員参加はコストが高いかもしれませんが、やれなくはないですよね。
企業様から「こういう形式はメンバーの仕事を否定するようで、やりづらい空気がある」という相談を受けたこともありますが、そこは経営者や開発責任者の腕の見せ所です。チームビルディングが課題になっている企業もありますね。

大本：チームがアジャイルマインドに変わっていかないといけないんですね。自分自身が非難されていると認識しないようにしないと、進んでいきませんから。

生谷：飲み会の中で愉快に実施するところもあれば、「不具合」「使いにくい」という言葉を全て「伸びしろ」に言い換える工夫をしているところもあります。

企業文化としてユーザビリティテストを根付かせたい

大本：トークセッションは以上です。お二人からユーザビリティテストに対する思いや難しさなどについて、一言ずついただけますでしょうか。

生谷：やらないよりはやったほうがいいので、さっき言ったようなやり方で簡単にでもやってほしいですね。
一方、規模感のある会社で組織的にユーザビリティテストのサイクルを回している実例は、あまり世の中に多くありません。まだまだユーザビリティテストは発展途上、試行錯誤のフェーズにあると思います。私自身、ここはどうしていけばいいのか悩みどころです。

北村：やはりユーザビリティテストは気軽に実施してもらいたいですね。この時代人を探すのは簡単ですし、意外と身近にターゲットはいるものです。
またUX人材がPMやPOへと成長していけば、文化としてユーザビリティテストが自然に根付いていくのではないでしょうか。

LT：ユーザビリティテストで陥りがちな罠、ワースト10

大本：ここからは、よくある質問や疑問、間違ってしまう行動や解釈のワースト10を解説していこうと思います。

1．ユーザビリティテストを上手にやるには？どういう質問がいいですか？

大本：私はUX DAYS TOKYOの中でセルフユーザビリティテスト検定講座を実施させていただいていますが、一番多いのが「どういう質問をしたらいいですか？」という質問です。
仮に質問の内容が下手だったとしても、後から気付いてユーザーのリアクションをカウントしなければいいだけなので、それよりも「何を聞けたか」を重視しましょう。ユーザビリティテストはプロダクトの問題点を発見するものですから、そこがわかればユーザビリティテスト自体があまり上手くできていなくても、気にしなくて大丈夫です。

2．作ったように動いてもらうために机を叩く・目や雰囲気で誘導する

大本：開発者が目の前でファシリテーションをすると、自分ではそんなつもりはなくても、目で誘導してしまうことがあります。UIをわかってほしくて、ユーザビリティテストが終わった後に「実はこうなんですよ」とプロダクトを説明してしまう場合もありますね。そこはユーザーに気付いてもらえなかった事実を謙虚に受け止めましょう。

3．ユーザビリティテストの課題が作れない

大本：これは目的がないユーザビリティテストに近しい罠ですね。世界的なベストセラー『Don’t Make Me Think』には、ユーザビリティテストでは「わかるかテスト」「できるかテスト」の2つをやってくださいと書かれています。パッと見たときに何のサイトかわかるか、「○○してください」と言われたときにできるか。チケット購入サイトなら「○人分のチケットを購入してください」といったことです。
そこでスムーズにできたか、タップが多くなかったか、面倒ではなかったかなどを見落とさないようにしましょう。

参考書籍：超明快 Webユーザビリティ ―ユーザーに「考えさせない」デザインの法則（『Don’t Make Me Think』の日本語版）

4．やりたいテストだけを実施してしまう

大本：例えばUIの一部分を改善してそこだけをテストしようとすると、誘導的なタスクを出してしまいます。その場合、前後に問題があることに気付けないケースがあるので注意しましょう。

5．被験者の個人的意見を鵜呑みにしすぎる

大本：被験者の個人的意見を鵜呑みにしすぎるケースはかなり多いです。「こんな機能があるといいと思う」と言われて、その通りに受け取りいろいろな機能を追加した結果、破綻して炎上した開発会社さんもあります。
キラークエスチョンとしては、「その機能はお金や時間を費やしてまで使いたいか」と聞く方法があります。こういった形でニーズを読み解いていけるといいですね。

6．間違った分析結果で、改善されない

大本：これも5番目の罠に近いものです。実例として、プロトタイプ段階のユーザビリティテストで、画面に「ゴミ箱が突然出てきた」とユーザーに言われたことがありました。

UIデザイナーと議論して当初はアイコンの位置を再検討しようとしたのですが、実際に問題だったのはアイコンの下の文字の有無でした。ほかのアイコンには文字を入れていたのに、ゴミ箱アイコンだけ文字がなかったために統一感を欠いて、異常をきたしてしまったのです。

結局文字を入れて、動作はスムーズに進みました。必ずしもユーザーの言葉通りに直せば良いわけではないので、しっかりとした検討が必要です。

7．動画を編集してしまう

大本：こちらは先ほどの「目で誘導する」に近い罠です。自分が解釈したように開発を進めたい傾向が強い方は、ユーザビリティテストの動画を編集してしまうケースがあります。
編集された内容を鵜呑みにしてプロダクトを開発すると、あらぬ方向に進んでしまうことがあるので気を付けましょう。きちんと一次情報にあたるのがポイントですね。

8．テストの分析結果だけを鵜呑みにする

大本：テスト結果だけを鵜呑みにするのも、7番目と同じ危険があります。よくインタビューを文字起こして読むことがありますが、それだけではどうしても話者の感情が抜け落ちてしまいます。例えば「美味しい」という言葉も、言い方によってどの程度美味しいのかは変わりますよね。テキストだけで判断をするのは危険なので、気を付けましょう。

9．録画して見直ししない

大本：動画もきちんと見直しをしてほしいところです。人は自分が少し前に食べたものすら忘れてしまうものなので、全てを録画するのが非常に重要ですが、見直さないケースが山ほどあります。もちろん長い動画を見返すのは大変ですから、要所にはタイトルをつけるなど、ポイントを記録しておきましょう。

10．インタビュアーのことを理解していない。テストだということを忘れてしまう

大本：最後の罠は、インタビュアーのことを理解していない問題です。ユーザビリティテスト自体はプロダクトの悪いところを見つけるものですが、ユーザーは人が見ていると自分が下手な操作しかできない、リテラシーの低い人だと思われたくなくて、頑張りすぎてしまうケースがあります。自然体でいいし、わからないことがあれば言ってほしいという前提はきちんと伝えましょう。

質疑応答

既存のアプリと比較してユーザーが期待したUIを見極める

質問者：インサイトを判断するポイントはありますか？「本当はこうしたいんですか？」と尋ねるのはいけないと聞くため、難しいです。

生谷：「これってこういうことですか？」と聞きたくなる気持ちはわかりますし、実際に聞いてしまったこともあります。そういうときは、自分がそう思った背景に焦点を当てて、質問の仕方を変える工夫が必要ですね。
私の場合はユーザビリティテストが一通り終わるまで、こちらからは何も情報を言わないようにしています。聞きたいことがあればメモをしておいて、テストが終わった後に全部聞く。例えば「こうなったときに手が止まったように見えたけど、このときどこを見ていましたか？」などですね。あとはその人が普段使っているアプリを先に聞いておいて、そのUIをベースに「こんな感じを期待しましたか？」と聞いたりしています。

北村：カレンダーUIなんかだと、絶対にGoogleカレンダーが引き合いに出てきますしね。「Googleカレンダーにあるような、こういう挙動をすると思った」みたいなケースは結構あります。

プロダクトの情報設計の成否を示す「迷い」のアクション

質問者：「詰まった」「止まった」はわかりづらさ、使いづらさのアクションだと思いますが、それ以外に気にしているユーザーのアクションはありますか？

北村：ため息をついたとか、カーソルがあらぬほうに行ったりするようなことは結構ありますね。大本さんが言ったように録画を見返して、プロセスを見るのが大事です。

生谷：「詰まった」「止まった」以外なら、「行ったり来たりして迷う」は気にしますね。ユーザーはほとんどボタンの文字を読まないので、何となく押して違ったら戻って、虱潰しに触ってみて目的にたどり着くケースが多いです。あとは「間」なんかも見ています。

大本：アプリの情報設計が上手くいっていれば「行ったり来たり」はないはずですからね。ユーザビリティテストの精度が上がるほど、タスク自体もアプリでやるべき内容にフォーカスして、本当に最短でできるのかどうかを見られる気がします。

生谷：あとは良い椅子に座っていると余裕が出てきてしまうので、たまに立って操作してもらったりします。脳内メモリが下がって、めちゃくちゃ迷うんですよ（笑）。

大本：いいですね！操作は大体スマホですしね。いかにいつも通りに使ってもらうかも重要です。

北村：迷ったときほど着目すべきですよね。自分たちは「上手くいくだろう」と思って設計しているのに違うルートに行くのであれば、どういう思考だったのかを突き詰めるべきですし、意見も収集したくなります。

まとめ

ユーザビリティテストに対する考え方とその必要性について語っていただきました。
どんなプロダクトであっても必ず実施すべきユーザビリティテスト。どうやっていいかわからない、コスト面が気になるなど懸念されている方も、まずはこの記事に書かれている簡単なやり方を実践してみましょう。
「ユーザビリティテストで陥りがちな罠ワースト10」を事前に読んでおくのもおすすめです。