【CEDEC 2018】「何故、データ分析が必要なのか」…gumiが『ドールズオーダー』の事例をもとに”意思決定”に利用できる分析データを紹介

 
コンピュータエンターテインメント協会（CESA）は、8月22日～24日の期間、パシフィコ横浜（神奈川県横浜市）にて、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2018」（CEDEC 2018）を開催した。
 
本稿では、8月22日に実施された講演「アプリ改善を深化するデータ分析 〜現場で使えるデータを片っ端から可視化するコツ〜」についてのレポートをお届けしていく。
 
本セッションには、gumi・Technical Strategy & Development Managerの松浦遼氏が登壇。昨今、モバイルゲームのリッチ化により精度の高い施策立案が不可欠になっている中、各アプリ個別のユーザ行動データを可視化して現場のプランナーが活用できるようにしなければならないという課題にgumiがどのようにして立ち向かってきたのか。実際に利用しているサーバーサイドの統一内製フレームワークを説明しながら、外製クラウドデータ基盤・BIツール・データ分析ツールなどを組み合わせたデータ活用事例を紹介した。
 

▲gumi・Technical Strategy & Development Managerの松浦遼氏。
 

■タイトルをヒットさせるためのデータ分析

 
まず松浦氏は、今回の講演では『ドールズオーダー』の事例を中心に話を展開していくとコメント。持ち帰って欲しいポイントとして下記の2点を挙げた。
 
●分析は何度でもしよう
●『後出しジャンケン』の分析準備をしよう
 

▲2018年3月より配信開始された『ドールズオーダー』は2on2のオンラインバトルゲームである。
 
1.なぜ何度も分析を？
では、なぜ何度も分析をする必要があるのかについて松浦氏は順を追って説明した。
 
そもそも、なぜデータ分析をする必要があるのか。ここで松浦氏は、来場者に「皆さんがしているサービスは当たっていますか？」と質問した。全てのゲームアプリが上手くいくわけではないが、「ヒットさせたい」というのは多くの方が持つ想いである。しかし、昨今は「市場のレッドオーシャン化」、「ゲームのリッチ化」などによりマーケティング費用・開発費の高騰、開発期間の長期化が叫ばれている。そこで、1タイトルの精度を上げたい、そのためにデータ分析が必要になるのだと解説した。
 

▲データ分析とは、データを用いてビジネス上の課題に対する意思決定のサポートをすることであるとのこと。
 
続いて、松浦氏は下記のとある数値を公開する。
 
 
▲この数値は半年間にBIツールで作成された帳票の数である。断続的に作成するのではなく、継続的に作り続けているのが特徴のひとつであると松浦氏は語った。
 
そして、帳票を作り続けている理由はデータ分析のワークフローにあると松浦氏は話す。
 

▲データ分析者と意思決定者は異なるため、両者の知見共有が必要となる。この際に分析したデータが必要となるのだが、サービスが続く限りサイクルは何度も繰り返されるためデータ分析も何度も行う必要があるというわけだ。
 
そのほか、知見共有のためにはデータ分析者もディスカッションに耐え得るためのゲーム理解が必須となると松浦氏は話す。時間の許す限り担当アプリを遊び、社内外でヒアリングを行い、課金をして遊んでみることは重要なファクターとなると強く念を押した。
 
2.『後出しジャンケン』のための分析データ
次に、松浦氏は何度も分析するにあたって「何が起きるか」、また「どんなデータが必要になるのか」についての説明を行った。
 
そもそも、意思決定のサポートに使えるデータとはどのようなものなのか。例として松浦氏は、「KPIを意思決定に使えていますか？」と問う。数字を見ているだけでは判断し辛い部分も多いのではないだろうかというのだ。そこで、どのようなデータを見れば意思決定に使えるかという部分を解説した。
 

 
上記の課題を解決するため、基礎KPIからデイリー売上の結果は得ることができるが、数値だけではその原因まで特定することはできない。
 

 
そこで必要となるのがユーザーの行動データだ。例えば、ガチャの回転枚数や課金通過の保有増減量を確認することで、「無償通貨の保有量が多かったため」など、何故売り上げが良かったのか、悪かったのかといった原因まで特定することができるのだ。
 

 
原因が特定できれば対策が立てられる。
 
先の話から分析は何度も行われているため、同じ結果が得られることもある。その際に分析を自動化していくのだが、そこでも「要件の再設計」が発生する。このように分析を繰り返すうちに要件が変化していくため作り直しが発生してしまうことから、分析要件は『後出しジャンケン』であるという話に繋がるわけだ。
 

▲作り直しが発生することは分かっているため、1番最初に何でも決めているわけではないと松浦氏は説明した。
 

 
次に「インゲーム要素接触状況ごとのユーザー量を監視したい」というケースについて。これは仮に、「PvPを遊んでいるユーザーが○人」、「降臨クエストを遊んでいるユーザーが○人」といった数値である。
 
この数値をユーザーの行動データで確認したとき、知見から原因を推測することはできるが、実際にそうなのかはデータを分析してみないと分からない部分でもあるという。
 

 
しかし、この際に下記のように再度分析が不可能な状態になっていることがあるため、再加工できるように集計前のローデータに近い粒度のデータを残しておくことが重要であると語る。後から見直したい要件は発生することが多いため、対応できるデータが必要になるとのこと。
 

 
事前にあらゆる要件に対応できるようにはしたいが、何が起きるかを想定できていないと定義ができない。このように、分析要件は『後出しジャンケン』の要素が強いため、思いもよらないトラブルにも対応できるデータを持っておくことが大事なのだと説明した。
 

▲意思決定に利用できるデータのまとめ。
 
続いて、データ分析のワークフローから、どのような着眼点でデータ分析をしているのかについて紹介した。まず、ユーザーがゲーム外からゲーム内に遷移する際、どれほどのコストが掛かっているのかは分析対象になっている。そして、ゲーム内ではゲームサイクルをもとに下記3点が意思決定のための分析対象となっている。
 

 
・機能の稼働状況の監視
『ドールズオーダー』はPvPをコンテンツの中心に据えたタイトルであるため、切断率を確認しているという。ゲーム体験として楽しければ切断したいという気持ちにもならないため、ここからゲームへの満足度やバトルへの期待感を分析している。また、キャラの利用回数や勝率などからも、ユーザーがどのような体験をしているかを可視化している。こうした着眼点を得るためにも、ゲームへの理解度を深めることが必要になると松浦氏は付け加えた。
 
・想定した遷移の進行度の監視
2つ目は想定した遷移先がしっかりと進行しているかという部分。例えば、チュートリアルを突破したユーザーが最初のバトルに挑戦した割合や、最初のバトルを終えたユーザーが翌日どれくらいログインしているかという部分をチェックしている。チュートリアル後はマイページで自由に行動を選択できるようになるため、そうなったときに一度アクションを取ってもらえるかが重要になるという。この割合が低いと「ホーム画面が散らかりすぎている」、「ホーム画面の遷移にミスがないか」という部分を分析できる。ここに、コンテンツを実施した後に1日継続してもらえるかという要素が加わることで継続率が決まってくるという。翌日ログインがなかった場合には「最初から初心者に重い体験をさせているのではないか」といった懸念を浮上させることができるとのことだ。
 
・多くの要素の中にどんな関係があるのか発見
3つ目の分析は想定外の遷移を発見するための分析。例えば、「キャラと武器、2つの要素がある中で武器を強化すれば強くなるバランスを取っていても、ゲームに慣れていないユーザーは気付くことができずキャラのレベルを中心に上げている」という事象は良く見られると松浦氏は話す。運営としては遷移の想定をしているが、ユーザーがその通りに動いてくれないというケースだ。そこで、原因を突き止めるために関係性を洗い出した図が下記のものになる。


▲こちらは3～7日以上ゲームを継続して遊んでくれたユーザーのデータから、7日以上継続して遊んでもらえるための要因を特定するための分析。「キャラの強化」を行っているなど、どの部分の遷移が強く出ているのかを見ている。
 
こうした分析に挙げられるよう、当初は想像もできないデータの組み合わせが意思決定に利用できるデータに繋がることもあるという。そのため、様々なローデータを残しておくことが必要なのだと話をまとめた。
 
3.分析データ利用の課題と解決
最後は、分析データをどのように処理していたのかという課題と解決法を発表した。
 

▲こちらはgumiのシステム構成。各タイトルで使用している共通基盤となる。
 
●ログ出力

▲先の話にもあった通り、後々どのようなデータが必要になるか分からないため、「このデータが必要」という定義をせず、スキーマレスで全て出力している。
 
●データ集積
データを格納する際に主に問題となるのは「ログ欠損」や「遅延」である。この課題を解決するため、gumiではログ集約をするためのアーキテクチャを内製した。
 

▲当初は一度データをAggregatorに集めて格納先に振り分けていたが、障害が頻発してしまっていたという。
 


▲そこで、集める機能と保存する機能を分離。Kinesisで集めて、Lambdaでストレージに格納するという流れに変更した。
 
●データ格納
こうして無事にデータ格納まで行えるようになったが、ここで「データ格納費用を気にしたくない」、「格納量に応じてパフォーマンスを低下させたくない」という課題が挙がる。その際、「事前に入れるデータを絞っておく」という対策が挙げられがちだが、gumiではデータを絞らず何でも残しておくという方針だったため、高パフォーマンスの分析用ストレージにデータを格納するという力技を行使したという。
 

▲とはいえ、スキーマレス運用と相性が良く思ったほど費用も掛からなかったとのこと。
 
●集計
「集計サーバのパフォーマンスを維持するのが難しい」、「後から集計ロジックを変更するのが難しい」という課題は、DWH内蔵BIツールを運用することで解消した。その際は、パフォーマンスを気にせずツールの方で勝手にスケールしてくれるといった点などが要件として挙げられたとのこと。
 
●帳票作成
最後は帳票作成について。こちらでは「画面作成の担当者が増えない・増やしたい」、「『管理ツール』利用時の維持」という課題に直面。これには下記の通りに対応した。
 

▲SQLはゲーム企業の共通言語であるため、どのセクションからも手が伸ばしやすくなる。これにより、分析チームで作成していた帳票を運用チームのエンジニアが引き継げるようになるなど、作業者がグンと増えた。
 
松浦氏は、全てのデータを取得するという思想をぶらさずに、それに適したツールを使うことが重要であるとまとめて「分析データ利用の課題と解決」についての説明を終えた。
 
分析業務が続く限り、業務改善も続くとのことでgumiでが現在下記のような取り組みを行っている。
 
・継続的なツール選定
・データ理解コスト削減
・共通基盤のさらなる活用
 
最後に松浦氏は、今回の講演で説明したような経緯から「分析は何度でもしよう」、「『後出しジャンケン』の分析準備をしよう」という2つのポイントを持ち帰って欲しいとコメントして講演の締めとした。

 

   

公式サイト

公式Twitter

App Store

Google play

© 2018 gumi Inc. All Rights Reserved.