分析のプロが解説!継続率を上げるFTUE改善:ユーザーテスト編

スポンサーリンク

FTUE分析:ユーザーテスト編

前回の記事では、ファネル分析を用いてFTUEに問題のある場所の絞り込みを行った*1

今回はさらに分析を進め、継続率が低い原因を特定していく方法としてユーザーテストと呼ばれるものを解説していくことにしよう。

ユーザーテストとは何か?

ユーザーテストとはゲームをユーザーに実際にプレイしてもらい、ユーザー体験上の問題を発掘・検証する方法だ。端的に言えば、実際にゲームを遊んでもらってその様子を観察するということだ。

類似の言葉にユーザビリティテストというものがある。ここで言うユーザーテストはそれよりも広い概念で、ユーザビリティとゲームプレイによって生まれるプレイアビリティの両方のテストを含んでいる。ユーザーテストの仔細を説明する前に、まずはこれらの言葉について触れておこう。

ユーザビリティのテスト

UXデザイン研究者の安藤は、ユーザビリティテストを「ユーザーのタスクとそのゴールの達成に着目し、制作したプロトタイプが適切にタスクが達成できるかを実験的に行うユーザー参加による評価手法」と定義している*2。ユーザーを実験室的な環境に招き、所定のタスクを提示してそれが問題なく達成できるかどうかを確認するといったものだ。

例えばAmazonや楽天のようなECサイトがあったとしよう。それらのユーザビリティテストを行う際、ユーザーは「1,000円未満の赤色の靴下をカートに入れる」とか「誤送された商品についてカスタマーセンターに問い合わせる」といったタスクを提示され、そのタスクが遂行できるかどうか。どれくらいの時間がかかったかなどを調査される。

タスクの遂行中、モデレーターは基本的に介入をせずにその様子を観察するに徹する。全てのタスクが終わった後に軽くインタビューを行ってフィードバックを得たり、所定のフォーマットでアンケートに回答してもらい、定量的にユーザビリティの品質を評価する。

プレイアビリティのテスト

ゲームにもユーザビリティのテストは存在する。それらは「ショップで鉄の剣と革の盾アイテムを購入する」や「バトル中に直感的に操作をする」といった目的が達成できるかどうかをテストするものだ。しかし、ゲームでは他のプロダクトと異なり、ゲームプレイを通して「面白かったか」や「鉄の剣が欲しくなったか」といったメカニクスの評価やユーザーのインタラクションも評価・検証する必要がある。

後者がプレイアビリティと呼ばれているもので、両者をひっくるめてユーザーに提供したい体験を実現できているかどうかを評価するのがユーザーテストだ。調査手法はユーザビリティテストと大きくは変わらないものの、観点がユーザーの目的達成だけではなく、狙った感情やモチベーションを作れているかの検証がそこに含まれている*3

端的に言えば、ゲームの遊びやすさ (ユーザビリティ) と面白さ (プレイアビリティ) の双方をテストするのがゲームにおけるユーザーテストという訳だ。

ユーザーテストのやり方

まずは目的と観点を明確にする

テストの目的と活用方法を明確にするのはあらゆる調査において重要だ。FTUEの改善という文脈では大上段の目的は定まっているが、より具体的にユーザーのどういった体験に着目するかをあらかじめ明確にしておくべきだ。

その際、想定されるユーザーのプレイ体感や離脱の原因について事前に仮説を持っておくことが大切だ。仮説もなくただ漫然とテストをするのと、仮説をもってユーザーの行動を観察するのとでは得られる結果に天と地ほどの差が出ると言える。前記事で述べたファネル分析もここでは有効だ。

単純に「初日のRRが低いからユーザーテストで調査をする」という粗い粒度に留まらず、RRが低い原因として○○と△△と◇◇が考えられるが、そのどれが主要因なのかを見極めたい。そうやって観点を持ってユーザーテストに向き合うことがテストの価値を引き上げると言える。

想定ユーザーと対象人数を決める

次に、テストの対象者を決める。対象者はゲームがターゲットしているユーザーが好ましい。例えばワンピースのゲームを作っているならば、ワンピースファンでアプリゲームを遊ぶ人という具合だ。

対象人数は1ターゲットあたり5人もいれば十分と言える。研究によれば、5名にテストを行えばユーザビリティ上の問題の80%は発見されることが分かっている*4。それ以上は人数の効果が逓減し、時間やお金といたコストに見合わなくなるため、基本はこの5人という数字を基準にすれば問題ないだろう。

ユーザビリティテストの人数とそれによってどれくらいの問題を発見できるかの関係を示したグラフ。出典:https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

分析方法とテストのプロセスを設計する

FTUEの調査に関して言えば、1回のセッションで対象者は1人で、その人に実際にゲームを最初からプレイしてもらい、遊んでいる様子を観察するのが一般的だろう。

なるべく普段の環境に近い状態でゲームを遊ぶよう設計されているのが望ましい。つまり、テストプレイ中に横からあれこれ口を出したりせず、基本は30分なり1時間なりを通しでプレイしてもらい、その後インタビューを行って所感をヒアリングする流れにした方がより自然だ。

ゲームプレイを観察している際に気になる点が出てくるとは思うが、それは最後のインタビューのときにまとめて聞いた方が良いだろう。

テスト協力者を募集する

テストの協力者は人づてで集めることもできるが、市場調査会社やQA会社経由で集めることでよりターゲットに当たる一般の人を集めることができる。これが最もバイアスのかからない方法だ。

予算や時間、情報管理の問題で外部の会社や一般の人を対象にできない場合、社内で人を集めることも検討に入れてよい。当然、社員は人数も限られ、ゲームに対するリテラシーも一般の人と比べて高いことが多いため、ややバイアスのかかった意見が集まる可能性はある。そのため解釈には注意が必要だが、まったくテストを行わないよりは多少ターゲットからずれていたとしても社員を集めてテストを実施する方が結果的に良いことも少なくないだろう。

ユーザーテストを実施する

対象者を集め、日時と場所を調整したら実際にテストを実施して問題の確認・検証を行おう。テストの流れは基本、先に定めたプロセスに沿えばOKだ*5

テストを行う際は先に述べた通り、普段の環境に近い状態でゲームプレイできるようにすることが重要だ。テストをする部屋は実験室的な感じではなく、内装や明るさを自然な家庭に合わせる。遊んでいる様子をその場で後ろからじろじろと観察するのではなく、カメラとモニターを通じて遠隔で見るようにする。ゲームプレイ中にあれやこれや質問を浴びせかけないなどだ。

対象者に、ゲームプレイ中に感じたことや思ったことをなるべくその場で口にしてもらうようにするやり方もある (発話思考法)。この方が観察から得られる情報は多くなるが、あまりに度が過ぎると普段の遊び方とは異なってしまうため、自然な範囲でお願いするのが良いだろう。

結果を分析する

テストが終わればその結果を分析し、問題を明らかにして改善策を検討する。その際、分析した資料を丸投げしてあとは開発者に任せるスタイルだとうまくいかないことが多い。実際にテストに参加してもらった開発メンバーを交えて、テストの様子を振り返りながら何が問題だったかを議論するセッションを設けよう。

そこでチーム全体で課題認識をすり合わせ、それに向けて自分事として解決に取り組む雰囲気を醸成することが何より重要だ。実際に改修が入り、継続率が改善した時の達成感は大きい。ぜひ皆さんもFTUEの改善を通じて、その体験を味わっていただければと思う。

FTUE分析の関連記事

*1:https://yuranhiko.hatenablog.com/entry/whatis_ftue_2

*2:UXデザインの教科書

*3:Games User Research (English Edition)

*4:https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

*5:インタビューに慣れたプロの方であれば、その場の雰囲気ややり取りの自然さ、想定される回答なども加味して柔軟にフローを変えることもある。