ユーザー行動調査の分析と問題の理解
志賀：ゴルフダイジェスト・オンライン（GDO）の志賀と申します。執行役員として、マーケティングとITを担当しております。GDOは、ゴルフ用品のオンラインショップやゴルフ場の予約など、ゴルフに関連するインターネットサービスの提供がメイン事業になります。その他にも、メディア運営、レッスン、練習場のDX、スコア管理アプリといった事業やポータルサイトの運営をしています。!
志賀：Contentsquareを導入した目的は、セッションリプレイ機能を用いて、ウェブサイトやモバイルアプリで起こっている問題を把握するためでした。社内でユーザーテストは根付きつつありますが、簡単には分析できず、ユーザーの行動調査が難しいという課題がありました。
一般的なユーザーテストでは、シナリオ通りに行動してもらい、何度も動きのテストを記録していくなかで、問題点を見つけ出していきます。しかし、ゴルフスコア管理アプリは、実際にゴルフ場でプレイをしながら使用するサービスです。そのため、室内で行う従来のユーザーテストでは調査が十分にできないことが課題でした。セッションリプレイが可能なContentsquareの存在を知り、導入に踏み切りました。!
志賀：現在、3つのフェーズに分けて、検証しているところです。フェーズ1は、サイトに埋め込み、ユーザーテストの代替手段として使用できるかどうかです。フェーズ2は**、開発プロセスのなかにユーザーテストを入れることが可能かどうかと、そのテストから課題を抽出できるかどうかです。今はこの段階にあります。フェーズ3は、実際に開発のプロセスで出てきた課題を改善した施策の検証**です。また、その結果を切り分けて開発に渡し、実装ができるかどうか検証します。このPDCAサイクルにユーザーテストを組み込みたいというわけです。
導入の対象はウェブサイトとアプリです。ゴルフ場予約サイトについては、パソコンとスマートフォンからユーザーテストを行い、課題の抽出ができるかを確かめています。アプリでは、しっかりセッションリプレイが取得できるかどうかを検証中です。
検証の体制は、当社の場合、UXD本部というUXを考える専門の部署があります。ゴルフ場予約の事業部門と協力して動いたり、UXD本部で開発しているゴルフスコア管理アプリを検証したりしています。そのサポートとして、ギャプライズさんに入っていただいています。
UXの課題発見と改善
堀井：ここからは、具体的なテーマに沿って、お話を伺えればと思います。まずは、**「そのUX改善は大丈夫ですか？」**というテーマです。志賀さん、いかがでしょうか。
志賀：UX改善をしたことによって新たなバグが発生することがあります。**よかれと思っていても実際には邪魔になってしまうことや、検証をしてみないと分からないことがあるんですよね。**今回、GDOのゴルフスコア管理アプリでも、よかれと思って取り組んだことが悲劇を生んでいたというエピソードがあります。ギャプライズの鎌田さんからご説明をいただきたいと思います。
鎌田：まずContentsquareを使って、GDOゴルフスコア管理アプリを分析し、ボトルネックを確認していきました。ゴルフのコースは主に18ホールあり、全ホールのスコアをアプリに入力したら、ラウンドが終了します。このアプリの課題は、全ホールのスコア入力が終わり、あとは保存するだけという状態で、ユーザーが保存をしないままに離脱するケースがかなり多いことでした。
志賀：保存をしなければ、何のために記録をつけたのか分かりませんから、アプリの使用目的が失われてしまいます。
鎌田：何％が離脱しているのかは分かりますが、なぜ保存せずに離脱してしまうのかが分からなかったため、Contentsquareのカスタマージャーニー分析を使いました。
鎌田：画面の真ん中が18ホール目です。18ホールを終えた後に、ユーザーがアプリ内でどのような行動をとっているのかをドリルダウンして確認していきました。入力後に保存を完了できる人や、入力し直す人がいるなかで、エラーが多く発生している箇所がありました。そのエラーをさらにドリルダウンしていくと、エラーに遭遇したユーザーがスコアカードを見直して、またエラーが出てはスコアカードを見て、という繰り返しのジャーニーをたどっていることが分かりました。そこで、セッションリプレイからドリルダウンして、このジャーニーをたどったユーザーが実際にどのような画面を見ていたのかを検証しました。
鎌田：これが表示画面のイメージです。未入力があるために、保存ができないというエラーが表示されています。でも、項目を確認しても全て入力済みなんです。ユーザーからすれば早く保存したいところです。しかし保存ができないので、もう一度スコアカードの入力ページに戻る。入力項目の不備を確認しても、ちゃんと入力はできている。そこで保存を諦めてしまうというジャーニーでした。
エラーが出ていた理由は、赤の枠線で囲まれた欄です。自分のスコアではなく、ゴルフコースを一緒に回ったメンバーのスコアが入っていなかったからでした。そして、スコアの未入力箇所には、小さく線が入っているだけなので、見落としがちです。
志賀：**これは、ユーザーへの配慮が足りていませんでした。**基本的にユーザーは、同伴者のスコアでなく自分のスコアを残すためにアプリを使用します。コンペでなければ、他の人のスコアは関係ありませんから。自分のスコアの入力を終えたのに、なぜ未入力と表示されるのだろうと悩むわけです。一方、開発のプロダクトチームからすると、全てのスコアを入れて、きれいなデータが残せるようにとユーザーに気を遣っている状態なんです。しかし、ユーザーの心理には寄り添えていません。よかれと思って表示した「未入力」という一言が、悲劇を生みました。未入力の内容も分かりやすく説明すべきなんですよね。
堀井：UXを悪くしようと思う方はいないと思いますが、結果のトレースをしていないケースは多くあります。リアルなユーザー体験をトレースできるところが、カスタマージャーニー分析の非常に大きなポイントでした。
ユーザーテストをDXするためには
堀井：それでは、2つ目のテーマ、「ユーザーテストをDXするには？」に移ります。前段でお話しいただいたのは、リリース後のPDCAでしたが、ここからは、リリース前のPDCAの活用例ということですね。
志賀：はい。これは検証のフェーズ2です。ユーザーテストを開発のプロセスに入れられるかという検証です。
鎌田：こちらは一般的な開発からリリースまでの流れになります。まず要件定義をして、実装をし、リリース前に受け入れテストをします。リリース後にモニターを集めて、実際に使用し、フィードバックをもらうという流れです。このユーザーテストは、時間とコストがかかるため、かなりのリソースが必要になります。
そこで今回取り組ませていただいたのが、リリース前の受け入れテストと、リリース後のユーザーテストを、開発前に一緒に行ってしまおうという検証です。一般的なユーザーテストでは、なかなか人数が集まらず、5人ほどのモニター集めにも時間とコストがかかってしまいます。例えば、先ほどのようなスコアアプリのテストをやろうとした場合には、本来はゴルフ場まで行かないとできないわけですから、そういった場所の制約もあります。
志賀：開発フェーズの受け入れテストも、人集めは難しいです。証跡を残さないといけなかったり、開発者に渡すための文書を作る必要があったり、手順がたくさんあります。数とバリエーションのどちらも確保するのが難しいという点が開発フェーズのボトルネックですね。
鎌田：Contentsquareを使えば、そういった証跡も、理論上はセッションリプレイで残したり、データで残したりできるのではないかという構想のもとでの検証でした。
鎌田：ゴルフ場の予約を完了するまでのプロセスである、ブッキングのフローを2つの方法でテストしました。1つは、モニターにシナリオ通りのブッキングのフローを取っていただいて、完了まで行ってもらうというテストです。もう1つは、フローやUIを把握していない人が予約をとるタイプの、いわゆるモンキーテストでした。期間はたったの2日間で、参加人数は従来の手法では5人ほどだったところ、78名を確保できした。
鎌田：78名のテストのサンプルをもとに、Contentsquareでジャーニーを作成しました。すると、ブッキングのプロセスにおいて、**申し込み完了の手前で確認ページを何回もループしているというユーザー行動が判明しました。**この理由を探るため、先程と同じ手順で、セッションリプレイを確認していきました。
志賀：ジャーニー分析において、同じ行動の繰り返しやループがみられると、そこに何か問題がある可能性が高いです。
鎌田：今回ループをしていた理由は、入力がうまくいかず、エラーが出ているからでした。
鎌田：このエラーの内容を見ると、1行目の赤字では、「入力に不備があるようです」と記載されており、ユーザーの入力内容が悪いと受け取れます。しかし、3行目では、「選択したスタート時間は売り切れました」と書かれており、在庫がないという別の問題が指摘されています。実際のエラーは「売り切れているので在庫がありません」というメッセージなんです。しかし、案内の文言がエラーメッセージと合致しておらず、表現的な問題があります。
ただ、セッションリプレイを見ていくうちに、他にシステム的な問題も発見されました。ユーザーは予約が完了できないため、ページを戻して、何とかしようとします。しかし、元のページには戻れない仕組みになっているため、どこにもたどり着けずに困ってしまいます。そういったことが、リリース前のユーザー行動調査によって分かりました。
鎌田：また、モンキーテストでは、さらに別の問題が同じ確認ページに現れました。今回の問題はループではなく、15％のユーザーがエラーページに到達していました。これもシステム的な問題で、特定のチェックボックスにチェックを付けるとエラーが表示される現象が発生していました。セッションリプレイがあるおかげで、どういう状況でこの現象が起こるのかという再現条件を把握できるのが、Contentsquareのカスタマージャーニー分析です。
このようにユーザーテストをDXすることで、エラーの要因が複合的に存在していたことに気付くことができました。これらの問題は、5人ほどの一般的なユーザーテストでは見つからなかった可能性が高いです。また1回ぐらいエラーが出ても、その後にうまく進んだ場合、そのまま報告しないこともあります。セッションリプレイでは、そのエラーが記録されているため、ユーザー行動をトレースしてエラーを再現できます。
志賀：鎌田さんは、実際にこのセッションリプレイを開発者と一緒にご覧になって、どう感じましたか？
鎌田：前向きに改善に取り組めるという点で、非常に良いと感じました。ユーザーのセッションリプレイにはユーザーの行動がはっきりと映っているので、開発者とマーケターで共通認識をもつことができます。皆が同じ方向で課題解決に取り組むことができ、ユーザー視点に揃うことがポイントだと思います。加えてスピードも重要です。「これはまずい」と思われるセッションリプレイをリアルタイムでお渡しすることができました。
志賀：かなり迅速に原因の特定ができたと聞いています。
鎌田：当初、セッションリプレイでデータを取得することに問題はないと思っていましたが、分析までできるのかは心配でした。カスタマージャーニー分析を活用してエラーを検出できて、とても良かったです。
志賀：この検証をやって良かったと思いますね。
堀井：たくさんの部署の人が関わるなか、皆の目線をユーザーに合わせて、1つのチームとして問題解決ができるというのは、非常に大きな成果だと感じました。本日は貴重なお話をありがとうございました。