ユーザーテストの効果を最大化するための課題解決ガイド 後編です。

「ユーザーテストの効果を最大化するための課題解決ガイド（ゲーム業界の場合） 前編　中編」も是非あわせてお読みください。

KLabのユーザーテスト改革：課題と解決策

今回は具体的にKLabでのユーザーテストの導入について触れていきたいと思います。

ユーザーテストを開発プロセスの中に効果的に導入するには、まずはテストを社内でできる受け皿を作る必要があります。ノウハウを持っている外部に発注して、言う通りにすればそれで良いというわけではありません。テスト会社はテストによる効果までを保証していないので、テストの効果を十分に発揮させ、意味のあるものにするのは、こちら側の責任になります。このことは多くの会社で見落とされがちです。必要なのは、テストを実施する前に、テストにどのような効果があり、何をするべきかを初めに明確にすることです。

私がKLabに入社した際、すでに品質管理グループがテストに関する実施サポートの知見を持ち、窓口対応の実績もありました。しかし、UI/UXグループとしては関与できておらず、テストをどう活かすか、またはテストの中身の品質については案件任せの部分が多く、その上、案件とテスト会社で調整するため、そのノウハウが会社として溜まりにくい構造になっていました。

そこで、テスト自体の品質を上げ、その知見を会社に蓄積していくことを目的として、横断部署として関わることにしました。とはいえ、経験が十分にあるわけではなかったので、これまでのテスト実施のデータと、その後のアクションについて調査するところから始めました。幸い、過去データは豊富にありました。

ユーザーテストについて知ったふりをして最初から大上段に構えて「本当のユーザーテストとはこういうものだ！」と介入することも想像しましたが、それでは失敗することが目に見えていました。理想と実態のギャップが大きければ大きいほど、ハレーションが起こるということをこれまでも多く経験してきました。そのため、まずやるべきだと考えたのは、理想と実態のギャップの把握と、そこから現れる問題点の洗い出しでした。

そこからわかった問題点は大きく3つありました。

まず一つ目は、現状のテストがプロセスに組み込まれており、プロジェクトにとってテストを実施しないとその先のプロセスに進めない仕組みになっていた点です。そのため、案件にとってテストが品質を上げるための手法ではなく、超えるべきハードルであると感じられていたこと。

二つ目は、プロジェクトにとってスケジュールは最優先事項であり、テストでのフィードバックがそのスケジュールを遅延させる要因であったこと。多くの場合、最小限の対応に止められるか、あるいは対応しないという判断になってしまいます。

そして最後は、テストそのものに対する誤解です。これは人によって差が大きく、それまでの経験のバラツキが原因だと思われます。なによりユーザーテストに対する捉え方が個々に大きく異なることに驚きました。

テストの価値を最大化する挑戦

3つの問題を解決するために、まずはUI/UXグループとして社内のユーザーテストに積極的に関わることにしました。それまでKLabでは、ユーザーテストは品質管理グループがプロジェクトと連携し、外部のテスト会社の窓口となることで実施していました。しかし、品質管理グループの役割はテストの実施サポートであり、テストを効果的に利用するのは案件に任されていました。

この体制では、先述したようにテストのノウハウが会社に蓄積されにくいという問題があります。そこで我々は、テストの知見を横断組織に蓄積するという名目でテストに参加し、品質管理グループと共同でユーザーテストの知識や正しいテストのあり方について、テストメニューという形で資料化を行っていきました。

資料作成の後は、テストへの誤解を是正するために、テストメニューの内容や正しいテストのあり方について、勉強会やプレゼンを通して全社に周知していきました。しかし、個々の記憶の中には、過去の経験による蓄積したテストの知識がノウハウとして定着しています。それに、強い確証バイアスがかかるため、進め方を間違えると反発が生まれることもあります。これに対しては、テストの歴史を踏まえた知識量と実績で徐々に信頼を獲得していくしかないと考えています。

次に取り組んだのは、プロセスの変更です。テストを実施しないと次のプロセスに進めないという縛りが、プロジェクトにとってテストが邪魔者であると感じさせていました。そこで、テストはブロック要素ではなく、次のプロセスに進んで良いことを証明するためのアイテムとして機能するように変更しようとしました。

しかし、これには時間がかかりました。プロセスを変更するには、経営会議での承認を得る必要があったためです。それに、テストを重要視するという考えは、プロジェクトの責任者からはテストを増やすという間違ったメッセージとして受け取られ、反発を呼びました。

そこで、テストを必須事項から外し、効果が見込めない目的のないテストは実施しなくて良いというメッセージをプロセスに組み入れてもらいました。そして、テストとして効果が見込めない場合は費用の無駄になるため、テスト内容によっては、テストの中止を提案できるような抑止力を手に入れました。本当の狙いは、テストの品質をチェックし、変更を加える権利を手に入れることでした。

品質管理グループは実行管理、UI/UXグループはテストの品質管理という役割分担を行い、効果的なテストを実施するために、テストごとにどのようなテストを実施するか、綿密なテスト計画をルール化しました。

最後の問題は、スケジュール優先でテストの結果がうまくコンテンツに反映されないという点。テストの結果に対して何をやるかは、プロジェクトの責任範囲のため、横断組織には決定権がありません。課題はあっても、スケジュールに対する責任もあるため、対応するかどうかが天秤にかけられます。

UXデザインが機能しているフローでは、本来、プロジェクト外のUXの専門組織が抱えている問題を提示し、一定の責任を持って権限を行使する必要があります。しかし、権限のある専門組織がないと「テスト結果からこんなことが言えますよ」というインサイトの提示にとどまることになります。

それに対してできることとしては、テストの信頼性を高めること。そして、テストの目的について認識してもらうことです。そのために、事前のテスト計画を綿密に行うフローが必要だったのです。

テスト計画では、テストによって何が知りたいか、現状の課題認識をあらかじめ設定し、問題があった場合、どのような条件の時にどのような修正を行うのかまでを事前にコミットしてもらいます。これは、テストは実施すればOKではなく、何を証明し、それが証明できない場合はどんな修正をするかまでがセットであることを認識してもらうことが狙いでした。

活きたノウハウを手に入れるために

ユーザーテストのノウハウを手に入れる際に最も困難なのは、活きたノウハウを手に入れることではないかと思います。だからこそ、通常はテストを外部に発注するのが通例になっているのではないかと思います。専門知識については同じことが言えるのかもしれませんが、書籍やネットで得られる知識には、重要な部分が抜け落ちているように感じられます。

私たちはテストのノウハウを蓄積するために、テスト会社からの提案やテスト内容を鵜呑みにするのではなく、こちらからテスト設計を提案し、実施するアンケートの中身へのフィードバックや、分析のチェックなどを行い、積極的にテストの中身に関わっていきました。これは、もしかするとテスト会社としては迷惑だったかもしれませんが、彼らがやろうとしているいちいちを真似てやろうと考えていました。

一方、テストに深く関わり、テスト会社の作業を追跡することで、テスト会社ではどうしても見えてこない課題があることも見えてきました。結果的に感じたことは、テストを意味あるものにするには、積極的に社内側でテストの全体に関わる必要があるということです。

​​

テスト会社からの集計や分析とは別に、独自の分析結果とそこから得られたインサイトの提示なども行いました。ただし、同じ分析をするのであれば、現場を混乱させる可能性もあるので、テスト会社がしないような複数のデータを使ったクロス分析や、できるだけ一回のテストから多くを得られるように、違った切り口のインサイトを出すように心がけました。むしろ、そのことがプロジェクトの信頼を得るキッカケになるのではないかと思います。

テストサポートや啓蒙活動の結果、ユーザーテストに関する相談が多く持ち込まれるようになってきました。そこで、ついに念願であった社内テストの実施に乗り出すことにしました。

社内テスト環境の構築と発見

社内テストの構築に関して、まずは社員全員の属性情報の取得をしようとしました。しかし、情報は個人のプライバシーに関わるので、まずは情報の取り扱い環境を構築する必要がありました。匿名性を担保し、属性選択だけで、テストの発注ができる仕組みを構築しました。そうして、社内アンケートの承認を取りつけました。

社内テストの実施には、観察テストに関する活きたノウハウが必要でした。幸い、社外サポートで経験のあった品質管理グループから情報を得ることができました。セミナーに参加して他社の事例も集めました。

インタビューや発話テストなどについては未経験でしたが、社内テストというクローズドな環境もあったので、ぶっつけ本番で乗り切るつもりでいました。しかし、問題は社内テストへの経験もなく信頼もないため、プロジェクトからテストの依頼がこないことでした。そこで、テストのテストという名目で、プロジェクトのコストではなく、横断コストでの実施ができる承認を取り付け、なんとかテストに強引に漕ぎ着けました。

今から考えると、初回のテストはお世辞にも良いとは言えない内容だったと思います。分析の質も低く、集計の域を出ていませんでした。我々がするべきはどのようなインサイトをテストによって導き出せるかであり、コンテンツの評価をすることではないのですが、批判的な評価をしてしまっていました。

本来、UXの評価はUXデザイナーの意見であってはならないと考えています。やるべきことは、ユーザーの感じたことを行動から仮説を立て、コンテンツが狙っているユーザーのアクションとの乖離を見つけ、インサイトとして提示することです。

ともかく、社内テストの実績を作れたことはとても大きな一歩でした。社内テストの実績をテコにして、さまざまなプロジェクトに売り込みをかけました。フローと分析の品質にも改良を加えました。例えば、クロス分析の手法の構築や、AIによる分析、さまざまなデータの可視化などを行い、より多くのインサイトを得られるようにしました。フロー面では、テンプレート化できるところはテンプレートにして、準備に4週間かかっていたところを3週間、2週間と短縮し、コストも大幅に下げ、分析のノウハウも後付けで向上させていくことができました。

テストの実施で得られた発見は、並走することでプロジェクトの課題に密着することができ、より精度の高い分析が可能になるという点です。これはむしろ、今までのテストのレビューは単なる感想でしかなかったことを痛感させられました。テストの結果から導き出されるインサイトがあってこそ、はじめて発言に意味が出るのが本来のUXであると感じました。

最終的にフローの短縮に成功し、コストを外注の20分の1程度、期間も10分の1程度に抑えることができることが証明できました。それにより、機能単位でのテストや、通常の運用案件の新規機能の開発にもテストを組み込めるようになりました。これによって、会社としては社外よりも社内でテストをするべきという大義名分ができたことになります。

ユーザーテストの実施を促進するために：課題設定と効果予測の重要性

社内テストのフローを構築することはできましたが、まだ大きな課題が残っていました。コストは安くなったものの、基本は新規プロセスのためのテストであるため、既存案件でのテストや、もっとカジュアルなテストの利用に関しては、どんなに安くなってもコスト増や工期が伸びる要因になるため、実施には二の足を踏みがちです。

テストによって何がわかるかは理解してもらえたかもしれませんが、テストをやるメリットについて体感してもらえたわけではありません。テストをすることで、どのような具体的な利益を出せるのか明確にしなければ、プロジェクトはそれを採用するという判断をすることができません。「やったらきっといいよね」では承認は得られません。

結局、「ゲームが体験として良くなるよ」だけでは、その効果を可視化、数値化ができず「じゃあ、やりましょう」とはなりません。そこで重要なのは、課題が何で、その改善によって何が変わるかです。あるいは案件が課題と感じている部分を解決する方法を提示するのも良いでしょう。

UXをいくら改善しても、明確に売上という数値が変わるわけではありません。影響を与えたとしても、それがどの程度UX改善によるものなのかを明らかにするのは難しく、それを効果として主張するには無理があります。

必要なのは「UX改善によって、何が変化するのか」です。正確には「課題は何か？」という課題設定がプロジェクトにとって適切なのか、そしてそれを改善することで何が変化するのか、この数字に対しての仮説を立てる必要があります。闇雲に数字を取っても意味がありません。課題とその対策による変化を予測し、特定の変数の変化を観察する必要があります。

効果の予測までをセットで提案しなければ、会社に対してユーザーテストをやりましょうというのは難しいでしょう。ユーザーテストは正しいのでやりましょうというのは、正義の味方は正しいので、悪人をやっつける活動をしましょうというくらい無茶な話というわけです。

実はテストの価値を明確にするという課題はまだ解決には至っていません。ゲームの場合、コアの体験の楽しさを数値化することが困難であるということも大きな要因のひとつです。これに関しては、アイトラッキングや、発汗などの生体テストなど新しい手法の研究にも取り組み始めています。しかし、これに関しては、最新の論文などでも、まだ可能性が検討されている段階の話なので、残念ながらまだまだここでお話するレベルには達していません。

まとめ

これまで3回に渡り書いてきた内容は他社の事例を含め、ゲーム業界でのテストの取り組みについてです。事例に関しては、あくまでこれまで自分が経験してきた視界の範囲の内容なので、もしかしたら他の業界では随分様子が違うかもしれません。自社の取り組みについては、「ユーザーテストの取り組みが成功しましたよ」というものではありません。

今私が話すことができるのはここまでです。まだまだ確かではないこともたくさんあり、ここで話してきたことの中に間違っていることも多くあるかもしれません。それに対してもっとこうした方がいい等の意見もあると思います。それも含め、ひとつの実例として読んでいただければと思います。

内容に関してはできるだけひとつの考えに偏ることがないように、多くのUXの取り組みやユーザーテストについての情報は仕入れるように心がけたつもりです。

ユーザーテストを使った開発プロセスに対して何かひとつの完成形があると主張するつもりはありません。ユーザーテストと同様、人によって感じ方は様々です。UXデザインはそれに対して、どうやってより良くしていくかの営みであると考えています。フローに関しても完成はなく、おそらくプロジェクトごと、環境によっても最適なフローは変化していくものだと思います。これからもプロセスをより柔軟に、生きたものにするために取り組んでいければと考えています。

以上、長くなりましたが、この文章が少しでも参考になったり、ユーザーテストをやるための後押しになればいいなと願いながら、結びとします。

この方に記事を用意していただきました！