つぶやく元ゲームアナリストがデータ分析業務の課題と解決策を紹介した，「Google Cloud Game Day '22」のセッションをレポート
Googleは2022年6月29日，オンラインイベント「Google Cloud Game Day '22」を開催した。このイベントは，ゲーム業界のインフラエンジニアやサーバーサイドエンジニア，分析に関係する職種の人たちに向けて，ゲーム開発に役立つ最新のソリューションと事例を紹介するものだ。
本稿では，ゲームパブリッシャでゲームアナリスト業務の経験を有する現Google社員より，ゲーム業界における分析業務の実態とその課題を解説したセッション「元ゲームアナリストが語るゲームデータ分析業務の課題とその解決策とは」の内容をお伝えする。スピーカーは，以下の2名である。
セッションの前半では，ゲーム業界における分析業務の実態と課題が紹介された。最初のテーマは「分析チームの組織と役割」だ。細谷氏は，専任のアナリストがプロジェクトに紐付くケースと，複数のプロジェクトに対して複数のソリューションを提供するオーダー組織として分析チームが存在し，案件ごとに派遣されるケースを体験してきたとのこと。
後者のオーダー組織タイプの分析チームには，大きく3つの領域があるという。1つめは定量分析を得意とする「データサイエンス」の領域，2つめは市場調査やユーザーインタビューからインサイトを収集する「ユーザーサイエンス」の領域だ。
そして細谷氏自身が経験したという3つめは，ゲーム市場のトレンド把握のため定性的なアプローチからインサイトを収集する「ゲーム分析」の領域である。
ゲーム分析の領域で行うのは，「競合分析」「KPI分析」「施策立案」「イベントPDCA」の4つ。競合分析では，トレンドを把握するためにトップ100のゲームを継続的にプレイしつつ，サイクルやコンテンツの数と内容，育成要素などを分解し分析していく。
KPI分析と施策立案は，基本的にデータサイエンスの領域と連携して行う。具体的には，データ分析から見える課題や伸び代に対して，他社事例から得た定性的な視点を組み合わせて改修案を作成し，プロデューサーに提案していくそうだ。例えば初期の継続率が低ければ，チュートリアル以降のフロー──初心者ミッションの見直しなどを，企画開発担当と足並みをそろえて最適化を目指したという。
最後のイベントPDCAは，振り返りをサポートする役割を担っていたとのこと。同じスキームのイベントを複数回実施したケースでは，改修した内容に関するデータが前回と比較して改善したのかどうかの判断が，意外に難しかったという。そのため，目標とする重点KPIを何にするのかを事前に設定し，次の改修内容を確定していったそうだ。例えばコアユーザーのイベント参加率が低かった場合，「難度が低すぎて飽きられているのではないか」という仮説を作り，「複数のキャラクターを入れ替えるやり込み要素を追加することで面白さを掘り起こし，コアユーザーの参加率向上を目指す」という改修案を提案。このケースでは，デッキの入れ替え回数や各キャラクターの使用回数が重要KPIとなった。
次のテーマは，「ゲームデータ分析の課題」である。細谷氏は，自身が直面した課題を大きく3つのエリアに分けて紹介。1つめは，「分析における“リアルタイム性”が，企画開発の現場から求められるようになったこと」。そこには，運用年数の長いタイトルが増え，イベントのPDCAを回して細かいチューニングを施すことが重要になったという背景がある。
加えて，プロジェクトメンバーが増えたことにより，レポーティングのニーズが高まったことも理由の1つだ。運用年数の長いタイトルほど多くのデータを取り扱うことになるが，それだけデータ抽出に時間がかかるため，依頼を受けた翌日にしかアウトプットできないという事情もある。そのため細谷氏が分析の現場にいた当時は，データの鮮度が落ちても仕方がないとされていたという。
2つめの課題エリアは，「データガバナンス」について。運用タイトルや他社との協業が増えると，各種データをメンバー以外には絶対に見せないという鎖国のようなプロジェクトや，逆に閲覧権限管理に工数を割きづらくなり，管理がずさんになってしまうプロジェクトが混在し，整理が付かない状況に陥るケースもあったそうだ。
3つめの課題エリアは，「属人化」である。SQLを書ける一部のアナリストだけで分析をするため，データ分析のプロジェクトに対する影響がアナリストによって異なるという課題が生じたとのこと。
それらの課題が生じた事例と理想も紹介に。細谷氏によると，すべての課題を解決することはできなかったという。最初に，外部の開発会社との共同開発タイトルの運営体制の事例が示された。このタイトルでは多種多様なイベントを実施しており，イベントのPDCAを回して振り返りをすることはユーザーの課金率に直結するため，極めて重要だったとのこと。しかし，4つの要因がPDCAを回すスピードを下げていた。
1つめの要因は，「データ分析に時間がかかる」。大容量のデータ分析には時間がかかり，依頼された当日中には結果を確認できないし，考察や提案も含めたアウトプットとなると，さらに時間がかかってしまう。
2つめは，「同じBIツールを使えない」。パブリッシャではBIツールを使っていたが，そのデータを開発会社と共有できないため，都度データを加工して渡すという手法を採らざるを得なかったという。その結果，パブリッシャと開発会社が同時にデータを分析できない事態となり，会社間に時差が発生した。
3つめは，「分析チームの工数肥大」。上記のとおり，メンバーおよびレポーティング回数の増加や，ディレクターからのイレギュラーな分析依頼が増えたとのこと。
4つめは，「分析にムラがある」。アナリストのスキルによって，分析結果の質が異なり，タスクの提示がなされるケースとそうでないケースが出てくるという。またタイトルごとに分析担当を配置し，タイトル独自の運用をしているため，多くの場合，同じ観点で横断分析と評価ができない環境が続いてしまう。
これらの要因により，この事例ではデータドリブンでの意思決定がズムーズに行えないという状況に陥ってしまった。
続いて，会社全体のデータ知見を向上させるミッションの事例が示された。普段，データに触れる機会がないスタッフも対象とするこのミッションでは，4つのボトルネックが存在したという。
1つめのボトルネックは，「アナリストのスキルと熱量に依存する」こと。例えば，プランナーレベルにまで寄り添い，横展開が可能なレベルまでカスタムしたインサイトを提供するアナリストもいたが，手間がかかるため常に実行するのは難しい。
2つめは，「分析業務が民主化されていない」。分析にはSQLのスキルが必須であり，誰もが仮説をもとに能動的にデータを取りに行けるわけではない。また企画開発の現場で手軽に分析ができないため，分析チームに依頼するのが億劫になり，依頼しないというケースもあったそうだ。
3つめは「新鮮なデータの提供が難しい」で，前日，前々日のデータを見ることが多く，新鮮なデータを見ることができないため，データ分析そのものへの期待値が低くなってしまうとのこと。
4つめは，「データがパーソナライズされていない」。ゲーム内のパフォーマンスのKPIと，マーケティング関連の指標が1つのダッシュボードにまとめて表示されるため，情報量が多くハードルが高いと感じる人がいたという。またダッシュボードのカスタマイズができないため，「KPIを確認してほしい」と啓蒙してもなかなか浸透しなかったそうだ。
細谷氏は「ゲームアナリストは売上を作ることができない」とし，「どのようにすれば付加価値が上げつつ，前線で頑張っている企画開発の現場をサポートできるかを分析チーム内で議論することが多かった」と振り返る。その中で出た結論は「影響範囲を広げる」で，大きく3つのステップがあるとのこと。
1つめのステップは，アナリスト個人としての付加価値を上げることで，すなわち担当タイトルのメンバーに対してアクショナブルなインサイト──具体的に行動を起こせるインサイトを提供することだ。
2つめは，担当タイトル以外の分析チームメンバーと連携し，見るべき指標や効果のあった施策など共有を通じて，タイトル間のシナジーを生むトリガーとなること。
3つめは，以上のステップで生まれたインサイトを一般化し，分かりやすい形に落とし込んで企画開発以外のメンバーに認知させることである。例えば細谷氏が以前在籍していた会社では，マーケティングチームが企画したゲーム外プロモーション施策が，ゲーム内での施策を理解したうえで構築されていないケースも少なくなかったという。しかし，実施中のイベントやガチャがどのようなユーザーセグメントをターゲットにしている施策なのかを理解することで，プロモーションの内容も精度も大きく変わったとのこと。
以上をまとめて細谷氏は，「SQLの知識がなくとも，見るべき人がリアルタイムに正確なデータを手軽に手に入れ，またそれらを共有できる環境」が理想だとした。
セッションの後半では，ゲーム会社が構築すべきデータ分析環境とユースケースが紹介された。藤吉氏によると，昨今の無料でマルチプレイゲームがプレイできる状況では，ゲームビジネスにおける生命線は，データを活用し最適化収益モデルを構築することだという。データを収集・分析し，インサイトを導出する作業は，ユーザー獲得やプレイヤーに合わせたリアルタイムオファーの提供，継続率や収益の改善，そして社内でのデータ共有に大きな影響を与えるとのこと。
とくにゲーム会社では，企画開発やマーケティング，ビジネスアナリストなどさまざまな部門があり，それらの間でユーザーのプライバシーを保護しつつデータを共有し，成果を生み出す体制を構築する必要がある。
その一方で，インフラのスケーリング，高度な分析処理の実施，そしてコストの削減といった多くの課題に直面しているゲーム会社も少なくないそうだ。それは，昨今のデータドリブンなゲーム分析のニーズに，従来のデータウェアハウス基盤が対応できないことが理由だという。
それらデータ分析の障害となる課題を解決できるデータウェアハウスと分析基盤を構築することには，会社のすべての部門が必要なデータに素早くアクセス可能になるメリットがある。例えば企画開発部門は「どのようなアセットがユーザーに人気なのか」をリアルタイムに知りたいし，プロダクトマネージャーは「ユーザーがどのようにゲームに関わっており，それに応じてゲームを最適化できるか」が気になる。同様にマーケティングやIT管理，財務など部門ごとに異なるデータを活用される環境が求められていると，藤吉氏はまとめた。
本稿では，ゲームパブリッシャでゲームアナリスト業務の経験を有する現Google社員より，ゲーム業界における分析業務の実態とその課題を解説したセッション「元ゲームアナリストが語るゲームデータ分析業務の課題とその解決策とは」の内容をお伝えする。スピーカーは，以下の2名である。
- Google Cloud データアナリティクス営業統括部 セールス スペシャリスト 藤好健太郎氏
- Google Cloud デジタル エンターテインメント事業本部 ストラテジック ゲーム事業部 シニア アカウント エグゼグティブ 細谷錬平氏
 |
ゲーム業界における分析業務の実態と課題
セッションの前半では，ゲーム業界における分析業務の実態と課題が紹介された。最初のテーマは「分析チームの組織と役割」だ。細谷氏は，専任のアナリストがプロジェクトに紐付くケースと，複数のプロジェクトに対して複数のソリューションを提供するオーダー組織として分析チームが存在し，案件ごとに派遣されるケースを体験してきたとのこと。
後者のオーダー組織タイプの分析チームには，大きく3つの領域があるという。1つめは定量分析を得意とする「データサイエンス」の領域，2つめは市場調査やユーザーインタビューからインサイトを収集する「ユーザーサイエンス」の領域だ。
そして細谷氏自身が経験したという3つめは，ゲーム市場のトレンド把握のため定性的なアプローチからインサイトを収集する「ゲーム分析」の領域である。
ゲーム分析の領域で行うのは，「競合分析」「KPI分析」「施策立案」「イベントPDCA」の4つ。競合分析では，トレンドを把握するためにトップ100のゲームを継続的にプレイしつつ，サイクルやコンテンツの数と内容，育成要素などを分解し分析していく。
KPI分析と施策立案は，基本的にデータサイエンスの領域と連携して行う。具体的には，データ分析から見える課題や伸び代に対して，他社事例から得た定性的な視点を組み合わせて改修案を作成し，プロデューサーに提案していくそうだ。例えば初期の継続率が低ければ，チュートリアル以降のフロー──初心者ミッションの見直しなどを，企画開発担当と足並みをそろえて最適化を目指したという。
最後のイベントPDCAは，振り返りをサポートする役割を担っていたとのこと。同じスキームのイベントを複数回実施したケースでは，改修した内容に関するデータが前回と比較して改善したのかどうかの判断が，意外に難しかったという。そのため，目標とする重点KPIを何にするのかを事前に設定し，次の改修内容を確定していったそうだ。例えばコアユーザーのイベント参加率が低かった場合，「難度が低すぎて飽きられているのではないか」という仮説を作り，「複数のキャラクターを入れ替えるやり込み要素を追加することで面白さを掘り起こし，コアユーザーの参加率向上を目指す」という改修案を提案。このケースでは，デッキの入れ替え回数や各キャラクターの使用回数が重要KPIとなった。
 |
次のテーマは，「ゲームデータ分析の課題」である。細谷氏は，自身が直面した課題を大きく3つのエリアに分けて紹介。1つめは，「分析における“リアルタイム性”が，企画開発の現場から求められるようになったこと」。そこには，運用年数の長いタイトルが増え，イベントのPDCAを回して細かいチューニングを施すことが重要になったという背景がある。
加えて，プロジェクトメンバーが増えたことにより，レポーティングのニーズが高まったことも理由の1つだ。運用年数の長いタイトルほど多くのデータを取り扱うことになるが，それだけデータ抽出に時間がかかるため，依頼を受けた翌日にしかアウトプットできないという事情もある。そのため細谷氏が分析の現場にいた当時は，データの鮮度が落ちても仕方がないとされていたという。
2つめの課題エリアは，「データガバナンス」について。運用タイトルや他社との協業が増えると，各種データをメンバー以外には絶対に見せないという鎖国のようなプロジェクトや，逆に閲覧権限管理に工数を割きづらくなり，管理がずさんになってしまうプロジェクトが混在し，整理が付かない状況に陥るケースもあったそうだ。
3つめの課題エリアは，「属人化」である。SQLを書ける一部のアナリストだけで分析をするため，データ分析のプロジェクトに対する影響がアナリストによって異なるという課題が生じたとのこと。
 |
それらの課題が生じた事例と理想も紹介に。細谷氏によると，すべての課題を解決することはできなかったという。最初に，外部の開発会社との共同開発タイトルの運営体制の事例が示された。このタイトルでは多種多様なイベントを実施しており，イベントのPDCAを回して振り返りをすることはユーザーの課金率に直結するため，極めて重要だったとのこと。しかし，4つの要因がPDCAを回すスピードを下げていた。
1つめの要因は，「データ分析に時間がかかる」。大容量のデータ分析には時間がかかり，依頼された当日中には結果を確認できないし，考察や提案も含めたアウトプットとなると，さらに時間がかかってしまう。
2つめは，「同じBIツールを使えない」。パブリッシャではBIツールを使っていたが，そのデータを開発会社と共有できないため，都度データを加工して渡すという手法を採らざるを得なかったという。その結果，パブリッシャと開発会社が同時にデータを分析できない事態となり，会社間に時差が発生した。
3つめは，「分析チームの工数肥大」。上記のとおり，メンバーおよびレポーティング回数の増加や，ディレクターからのイレギュラーな分析依頼が増えたとのこと。
4つめは，「分析にムラがある」。アナリストのスキルによって，分析結果の質が異なり，タスクの提示がなされるケースとそうでないケースが出てくるという。またタイトルごとに分析担当を配置し，タイトル独自の運用をしているため，多くの場合，同じ観点で横断分析と評価ができない環境が続いてしまう。
これらの要因により，この事例ではデータドリブンでの意思決定がズムーズに行えないという状況に陥ってしまった。
 |
続いて，会社全体のデータ知見を向上させるミッションの事例が示された。普段，データに触れる機会がないスタッフも対象とするこのミッションでは，4つのボトルネックが存在したという。
1つめのボトルネックは，「アナリストのスキルと熱量に依存する」こと。例えば，プランナーレベルにまで寄り添い，横展開が可能なレベルまでカスタムしたインサイトを提供するアナリストもいたが，手間がかかるため常に実行するのは難しい。
2つめは，「分析業務が民主化されていない」。分析にはSQLのスキルが必須であり，誰もが仮説をもとに能動的にデータを取りに行けるわけではない。また企画開発の現場で手軽に分析ができないため，分析チームに依頼するのが億劫になり，依頼しないというケースもあったそうだ。
3つめは「新鮮なデータの提供が難しい」で，前日，前々日のデータを見ることが多く，新鮮なデータを見ることができないため，データ分析そのものへの期待値が低くなってしまうとのこと。
4つめは，「データがパーソナライズされていない」。ゲーム内のパフォーマンスのKPIと，マーケティング関連の指標が1つのダッシュボードにまとめて表示されるため，情報量が多くハードルが高いと感じる人がいたという。またダッシュボードのカスタマイズができないため，「KPIを確認してほしい」と啓蒙してもなかなか浸透しなかったそうだ。
 |
細谷氏は「ゲームアナリストは売上を作ることができない」とし，「どのようにすれば付加価値が上げつつ，前線で頑張っている企画開発の現場をサポートできるかを分析チーム内で議論することが多かった」と振り返る。その中で出た結論は「影響範囲を広げる」で，大きく3つのステップがあるとのこと。
1つめのステップは，アナリスト個人としての付加価値を上げることで，すなわち担当タイトルのメンバーに対してアクショナブルなインサイト──具体的に行動を起こせるインサイトを提供することだ。
2つめは，担当タイトル以外の分析チームメンバーと連携し，見るべき指標や効果のあった施策など共有を通じて，タイトル間のシナジーを生むトリガーとなること。
3つめは，以上のステップで生まれたインサイトを一般化し，分かりやすい形に落とし込んで企画開発以外のメンバーに認知させることである。例えば細谷氏が以前在籍していた会社では，マーケティングチームが企画したゲーム外プロモーション施策が，ゲーム内での施策を理解したうえで構築されていないケースも少なくなかったという。しかし，実施中のイベントやガチャがどのようなユーザーセグメントをターゲットにしている施策なのかを理解することで，プロモーションの内容も精度も大きく変わったとのこと。
以上をまとめて細谷氏は，「SQLの知識がなくとも，見るべき人がリアルタイムに正確なデータを手軽に手に入れ，またそれらを共有できる環境」が理想だとした。
 |
ゲーム会社が構築すべきデータ分析環境とユースケース
セッションの後半では，ゲーム会社が構築すべきデータ分析環境とユースケースが紹介された。藤吉氏によると，昨今の無料でマルチプレイゲームがプレイできる状況では，ゲームビジネスにおける生命線は，データを活用し最適化収益モデルを構築することだという。データを収集・分析し，インサイトを導出する作業は，ユーザー獲得やプレイヤーに合わせたリアルタイムオファーの提供，継続率や収益の改善，そして社内でのデータ共有に大きな影響を与えるとのこと。
とくにゲーム会社では，企画開発やマーケティング，ビジネスアナリストなどさまざまな部門があり，それらの間でユーザーのプライバシーを保護しつつデータを共有し，成果を生み出す体制を構築する必要がある。
 |
その一方で，インフラのスケーリング，高度な分析処理の実施，そしてコストの削減といった多くの課題に直面しているゲーム会社も少なくないそうだ。それは，昨今のデータドリブンなゲーム分析のニーズに，従来のデータウェアハウス基盤が対応できないことが理由だという。
 |
それらデータ分析の障害となる課題を解決できるデータウェアハウスと分析基盤を構築することには，会社のすべての部門が必要なデータに素早くアクセス可能になるメリットがある。例えば企画開発部門は「どのようなアセットがユーザーに人気なのか」をリアルタイムに知りたいし，プロダクトマネージャーは「ユーザーがどのようにゲームに関わっており，それに応じてゲームを最適化できるか」が気になる。同様にマーケティングやIT管理，財務など部門ごとに異なるデータを活用される環境が求められていると，藤吉氏はまとめた。
 |
 |
 |
 |
 |
