UI/UXグループの里宗です。
以前、コンテンツのローカライズについて連載させていただきましたが、今回はゲーム業界におけるユーザーテストについて3回に渡り執筆します。
今回、第1回目として開発者とユーザーの間に存在する壁、その壁を超える手法としてのユーザテストについてお話していきます。
近年、サービス開発においてユーザーテストの重要性がますます高まっています。ユーザー体験(UX)の向上がサービス成功の鍵と認識されるようになったことが大きな要因です。もともとユーザーテストを行う文化がなかった業界でも、ユーザーテストがプロセスに組み込まれるケースが増えています。ゲーム業界もその一つです。
アプリ開発以前、まだweb開発の時には、ユーザーテストを実施することは稀でした。企画から開発、リリースまでの期間が非常に短く、テストを行わないことはもちろん、リリースを優先しユーザーに遊んでもらってデバッグするというとんでもない発想すら存在していました。しかし、スマホアプリの台頭と共に状況は一変しました。開発期間が長期化し、リリース後の失敗リスクが大きくなったため、UX向上の手法としてのユーザーテストが重要視されるようになりました。
それでも、ユーザーテストの活用方法に明確なビジョンを持つ会社は少なく、単にユーザーの意見を聞くだけの対処療法的な利用が多かったように思います。例えば、プレイテストで高評価が得られたということで安心して開発を進めたり、逆に評価が低いためにアンケートの要望をそのまま採用するケースがありました。しかし、それは間違った手法であり、ユーザーテストの本来の目的とは異なります。
私がこの記事で共有したいことは、ユーザーテストを導入する際に犯した間違いや、直面した問題や失敗、そしてそれをどう乗り越えてきたかという体験談です。これは自分自身が当時、最も欲しかった情報でもあります。この体験談が、これからユーザーテストを導入しようと考えている組織や関係者に対して、ユーザーテストについてより深く考えるきっかけになれば幸いです。
私自身、これまで数社にわたりUXの導入に取り組んできました。前職では「UXが大事だ」というトップの号令のもとにUXグループが作られましたが、実際にはUIグループにUXという名前がついただけで、変化も方針もありませんでした。本来UXとセットであるべきユーザーテストの実施に関しても蚊帳の外。「やっておいたから」という事後報告のみでした。会社としては名前をつけてテストを実施しただけで、なんとなくUXにリーチしている気になっていたのかもしれません。
ユーザーテストとUXを一体化させるべきだと提案するにしても、巨大な組織のフローやプロセスを変えるには数年かかることもあります。会社として「UXが大事だ」と理解していても、具体的にどうアプローチするべきか分からない状態が続いていました。書籍を読み漁ったり、多くのセミナーに参加し、各社の取り組みについて学ぼうとしましたが、当時は抽象的でスタイリッシュな思想ばかりが目立ち、生きた体験を教えてくれるチャンスはほとんどありませんでした。
正しいUXの知識がまだ醸成されていない導入期、多くの会社では「UX論争」が巻き起こりました。俄かUXデザイナーが暗躍し、むしろ現場に混乱をもたらしていました。本来、正しい意思決定に導くはずのユーザー中心の考え方が、これまでの技術的な品質重視の考え方とぶつかり、度重なる仕様変更と複雑でわかりにくいプロセスの荒波の中で、UIデザイナーは翻弄されることになりました。
当時のUXデザイナーを責めるつもりはありません。UXに取り組む文化が醸成していない状態の組織に、いきなりトップギアでUXのプロセスを導入しようとしてもハレーションが起こります。現場での反発をよそに、経営層の中では「UX」という言葉がサービスを良くするための魔法の言葉のように取り扱われ、過剰な信頼をされていたのではないかと思います。その中で、悲劇的または喜劇的な混乱が起こっていたというわけです。
当時の混乱を経験したデザイナーの中には、UXに対するアレルギーを持っている人も少なくありません。本当の意味でUXの品質向上に体系的に取り組めるUXデザイナーも不足していました。UXを改善するために何をどうすれば良いかも、誰がUXの責任を持つのかも不明瞭なまま、ユーザーからの評価が悪いと、とにかく「UXが悪かったね」と誰もが振り返るようになります。そうした中、UXの責任は最終的なアウトプットを受け持つインターフェイスデザイナーの元に回ってきたのでした。
UXはよくUIとセットで考えられ、多くの会社にはUI/UXグループが存在します。ただ、本当の意味でUIデザイナーがUXにコミットしている会社は多くはないようです。なぜなら、UIデザイナーは単にUXが可視化された最終的なアウトプットを担当しているだけであり、UXに対する権限を与えられているわけではないからです。UXの権限とは、全体の品質を統合してサービスの根幹を握ることを意味します。UXの課題は企画やマーケティング、サウンド、開発など幅広いセクションにまたがっており、UIデザイナーがどうこうできるものではありません。
UXデザインの責任がUIデザイナーにないという話をしたいわけではありませんが、UXに関わる決定権を持っていなければ、UXの責任を取ることはできません。ならば、率先してその責任を取りに行くべきという考え方もありますが、フロー的に下流工程に位置するUIデザイナーの評価基準は、期限内にUIの合意を取り付け着地させることです。品質が不十分でプロセスを止める役割が期待されているわけではありません。もしUXの改善を機能させ、本当の意味で判断に影響を与えるには、忖度なくサービスを体験できるユーザーからのフィードバックが必要です。それを実現する手法こそが、今回のテーマであるユーザーテストです。
もしUXが良くない時、誰が責任を取るべきなのでしょう?
サービスをリリースして、ユーザーから酷評された場合、UIデザイナーやプランナー、それぞれのセクションの責任者のスキル不足を問うべきでしょうか。ただし、そもそもリリースを承認したのであれば、評価者がUXに対して一定の評価をしているはずです。そういう時、課題の特定とどう修正するべきかは、誰がどう決めて、責任が配分されているのでしょうか。
プロジェクト開発では、通常、いくつかのプロセスが設けられており、それぞれのステップで品質の基準を満たしているかセクションごとにレビューが行われます。大きな問題がなければ次のプロセスに進んでいきます。そこではプロセスごとに重要な項目がリストとして存在しており、レビュアーが専門の分野に対して基準を満たしているか確認していきます。さまざまな観点での評価が行われるのですが、誰もUXの評価がそこからこぼれ落ちているとは考えていません。
評価にはそれぞれのセクションごとの評価軸が存在し、項目に従って評価が行われます。プロデューサーは会社からプロダクトが承認されるか、プランナーは収益性があるか、PMはスケジュール通り進行しているか、管理方法が正しいか、制作は版元やプランナーからOKをもらえるか、開発は要件通り実装できているか、皆がそれぞれの評価軸で力を尽くしています。しかし、ここに全体としてUXの品質を評価する項目が存在しない場合、どうなるでしょう?
UXとはセクションごとに評価できるものではなく、サービスとしての総体の味わいです。本当のところはセクションごとに評価することはできません。しかし、多くの現場では、企画は企画の評価、制作は制作の評価をしており、他セクションが踏み込んで評価をすることを潜在的に嫌います。各セクションは無意識に自らのスキーマに立って評価を与えているので、実際のところ、会話が完全に噛み合っているわけではありません。その中で、個別でUX品質を評価するセクションがない場合、UXの評価はするすると掌からこぼれ落ちてしまうのです。
しかし、最も大きな問題は、例えUXデザイナーがいたとしても、評価が評価者によって行われるという点です。それはヒューリスティック評価、つまり経験則や先入観による直感での評価であるということを意味します。それではどこまでいっても技術評価であり、ユーザーの評価に代えることができません。そもそも見ているものが違うのです。開発者にとって作っているものは情報の集まりを意味するコンテンツですが、ユーザーからはサービスでしかありません。ユーザーは物語や体験というナラティブを全体としての印象で評価します。開発者の評価がユーザーの評価とイコールになりえないのです。
技術評価は、サービスというUXが入る容器の品質を問うことはできますが、容器の中に入っているUXを評価することはできません。UXはユーザーに体験され、作用することで初めて発生する気体のようなものです。そういうわけで開発者とユーザーの間には超えられない壁が存在しています。評価者の評価はどうやっても容器の品質を問う開発者中心の視点であって、どれだけユーザーを慮ったとしても、ユーザー中心開発にはなりえないのです。
それは会社側が従業員を、サービスの良し悪しの尺度ではなく、彼らのスキルを測る尺度である評価軸で評価している以上、超えることができない壁です。善悪の問題ではなく、個人は個人の利益を無意識に追求してしまいます。技術評価によって生産された成果物が企業を成功へと導く戦略とズレてしまうのは当然のことです。開発者がユーザーのために作ったサービスを、ユーザー視点で捉えることができないという現象は、まるでパラドックスのようです。
では、UXを評価するとはどういうことなのでしょうか?社内でサービスを評価するレビューシートには、「ゲームが楽しいか」「課金はされるか」のような抽象的な項目が含まれています。しかし、ただ楽しんでもらえれば良いというわけではありません。サービス側が、ユーザーにどのような体験を提供し、どう感じてもらいたいか、それが実現しているかどうかが重要です。例えば、楽しんでいるが、課金をしないという状況では困ります。また、売上が良ければUXが良いというのも間違っています。
その一例として、現在は規制されているコンプリートガチャがわかりやすいです。ガチャでカードをコンプリートすれば特別なカードがもらえるという仕組みですが、これは全ての目が出るまでサイコロを振ることと同じです。サイコロは確実に何らかのあたりが出ますが、ガチャの場合、カードごとに出現確率が変動します。結果として、多くの人が確率の罠にハマり、最後の一枚を求めて狂気じみた課金を行いました。これが購入されているからと言って、果たしてユーザーが心からサービスを楽しんでいたと言えるでしょうか。
ある調査では、企業の80%が自社サービスにおいてユーザーに良いサービスを提供できていると信じているのに対し、顧客側が同意したのはたったの8%でした。これはほとんどのUXがサービス側の独りよがりであることを示しています。なぜそうなるかというと、企業の「良かれ」がユーザーの「良かれ」と異なり、企業側がUXを計測する物差しを持っていないからです。
ここで言う物差しとは、ターゲットが誰であり、その人に何をどう提供し、どう行動してどう感じてもらいたいかの計画、つまりUX計画です。この物差しを使って、ユーザーは結果としてどう行動したのか、どう感じたのかを評価し、意図通りになっているかどうかなどを確認します。そこで必要なのは専門家の知見による答えではありません。
サービスの品質がどうではなく、生活や価値観、その人がどうサービスと出会い、何を求めるのか、ユーザーのサービスを取り巻く環境を含めた観点での深い理解が必要になります。そのためにはユーザーの行動を観察し、「何が何を何故引き起こすのか」という仮説に基づいた検証を行う必要があります。まさにそれがユーザーテストであり、課題に対して何をするべきかは、適切な物差しと問いから導き出されていきます。
里宗 巧麻
UI・UXグループマネージャー
次回は「ユーザーテストの重要性」についてより詳しくお話ししようと思います。
デザインを科学する「ニューロデザインラボ」で記事を掲載中です。
KLabのクリエイターがゲームを制作・運営で培った技術やノウハウを発信します。
合わせて読みたい
KLabのクリエイターがゲームを制作・運営で培った技術やノウハウを発信します。