“仮説出し”は「自分でプレイしてユーザーの気持ちになる」ことが大切　ゲームのデータ分析官がこだわるポイント

Gunosyからバンダイナムコネクサスへという経歴

齊藤一織氏（以下、齊藤）：バンダイナムコネクサスの齊藤と申します。本日は「バンダイナムコネクサスにおけるゲーム分析の流れと事例紹介」についてお話しします。私のLTは、分析業務の初心者向けの内容となっています。シニアアナリストの方にとってはだいたい既知の内容になっているかもしれませんが、よろしくお願いいたします。

あらためて自己紹介をしたいと思います。齊藤一織と申しまして、所属はバンダイナムコネクサスのデータ戦略部のプロダクトアナリティクスオフィス、PAオフィスというところに務めています。現在の仕事は、主にバンダイナムコエンターテインメントが配信しているゲームアプリの分析業務を行っています。

私の入社は2022年の6月で、まだ1年経っていませんが。前職は株式会社Gunosyという、ニュースアプリを配信している会社に新卒入社をしまして、アプリの分析業務をいろいろやっていました。趣味は記載のとおりで『マジック：ザ・ギャザリング』とか、いろいろなゲームとか。ポケモンでいろいろやったりしていました。あとは私自身アイマスが好きで、推しは書いてあるとおりです。

経歴というか仕事の話をすると、私自身のデータ分析者としてのキャリアは、先ほどお話ししたとおり前職のGunosy社に新卒で入ったのがファーストキャリアになります。就職活動中に分析系の仕事をいろいろ探していましたが、出身が経済学部卒ということで、文系の学部卒でも応募可能なところがあまりないというのと、そもそも新卒で分析系の業務ができるところが、私が探した限りでは貴重だったので、Gunosy社に入って分析のキャリアが積めればなというところで応募しました。

新卒採用において課題みたいなものがあったんですが、ちょうど大学のゼミでプログラミング経験が多少あって、当時はJuliaという言語を使ったシミュレーションの実装や、あとはDjangoをベースにした経済実験の実装をやっていたので、そこの経験が活かせて、採用されたかなというところです。

自己紹介は以上にしまして、これからプロダクトアナリティクスオフィスの紹介に移っていきたいと思います。弊社のデータ戦略部では、主にバンダイナムコ系列のゲーム分析を行っています。一部ではゲーム以外の案件もあります。ゲームの1タイトルにつき、だいたいプロダクトアナリティクスオフィスの分析担当者が1人から2人ついて、分析業務を行っている感じです。分析者はゲームのプロデューサーとか開発会社さまとかといろいろと連携して、業務を行っています。

準備フェーズのヒアリングが一番大事

ここから、実際の業務の流れに移っていきます。業務についてですが、何らかの分析のタスクが各ゲームで発生した場合に、以下のとおりの準備フェーズ、分析フェーズ、報告フェーズというような感じで、こちらに書いてあるように進めていく流れです。次ページ以降で、それぞれの詳細についてお話できればと思います。

まずは準備フェーズです。最初がヒアリングという内容になっています。だいたいの場合、ゲームのプロデューサーから分析相談を受けるかたちで分析がスタートするのですが、その際に分析の目的や背景などをしっかり確認していく流れになります。

相談の内容としてはここに書いてあるとおりで、「何らかのKPIが低下傾向です」や「新機能の反応がどんな感じかというのを知りたい」みたいな感じで、わりとざっくりとした感じで課題観を持って相談を受けることが多いので、ここを詳細に詰めていく必要があります。例えば集計の期間をどれくらいの期間で見たいかであったり、中期や短期と言っているけど具体的に何ヶ月ぐらいを想定しているのかだったり。

あとはどういう仮説をプロデューサー側で持っていて、それを検証してわかったとして、どういう打ち手につなげていきたいのかなどを聞いていくのがメインです。ここがかなり大事な段階になっていて、一番初めのところなんですが、最初が肝心というところで、分析観のブレが出るところです。このヒアリングの段階で不備があると、報告した時に「この報告内容は、ほしいと思っていた内容と違うな」みたいなことになっちゃって、意味のない分析になりかねないので、ここはかなりしっかりと詰めていく必要があります。

分析対象となる課題や仮説を整理

次に、分析のタスクが長期に及ぶ場合や、あとはゲームで初めて分析の案件が入りますみたいな場合だと、その分析の大まかな内容をすり合わせるフェーズがここで入っていきます。ヒアリングが終わったところで「分析デザイン」と書いていますが、分析対象となる課題や仮説を整理して、どこまでを扱っていくのかを決めて、そこからスケジュールを埋めて「こんな感じでどうでしょう？」というような感じでプロデューサーや開発会社さまに向けて提案していきます。

もういろいろと分析をやっている長期タイトルであったり、1回キックオフなどをやって分析と報告をどのぐらいのサイクルでやるかがある程度固まっているような場合は、ここは省略することが多いです。準備段階はこんな感じです。

分析設計は新人アナリストにとって時間をかけて行うべきポイント

次からは、分析のメインの部分に入っていきます。まずは分析設計という項目ですね。分析設計では、先ほどのヒアリングした内容を基に、詳細を明らかにすべき内容を確認して、そこから逆算して分析の報告の構成を考えて、「こういうことを言うためにはこういうグラフがあればいいよね」というような、必要なデータのアウトプットイメージを固めていきます。

その際に、ここのチェックのところに書いてあるとおり、目的からズレていないかや、集計対象はちゃんと目的に沿っているか、検証したい仮説についてこういうようなグラフで大丈夫か、あとはそもそもその手法を使うのが本当に適切なのか、というところなどをいろいろチェックしていきます。ここも、先ほどのヒアリングと同じように、かなり重要な点です。

特に新人アナリストにとって、ここはかなり時間をかけて行うべきポイントで、ここさえ終わってしまえば、あとは実際に手を動かしてクエリを書いて、みたいなことになりますが、逆にここでミスがあるともうこっちの書いたクエリなどは意味がなかったりして、手戻りが多くなって、作業時間がどんどん長くなっちゃうことが多い。

なので特に新人アナリストの場合は、この段階でチームレビューを入れたりして、ちゃんとした分析設計ができているかなどを確認しています。レビューについては後ほど説明します。

ダッシュボード化して必要なデータを集める

分析設計が固まったあとは、実際に必要なデータを集めるところですね。バンダイナムコネクサスでは、さまざまなゲームのログデータをBigQueryに入れて格納しているので、そこにSQLなどを投げてデータを取ってくるところが基本になっています。取得したデータはExcelで可視化したり、あとは機械学習を分析時に使う場合もあるので、適宜PythonでXGBoostなりK-meansなりで、使う必要のあるものをいろいろと実行したりしています。

あとは分析をしていく中で、こういう指標はちゃんと定期的に確認したほうがいいよね、みたいなのが出てきた場合は、ダッシュボード化して、ちゃんとプロデューサーや開発のメンバーが確認できるような環境を作るというタスクが発生していくことはあります。今は、ダッシュボードを作るのは「Looker Studio」というGoogleのツール（旧データポータル）を使っています。安くて使いやすいので、けっこうおすすめです。

こんな感じで、データ収集や実際の可視化などを行っていったあとに、あとは取ってきたデータの解釈や報告資料の作成を行っていきます。報告資料の作成も、こちらに記載しているとおりいろいろと注意点がありまして、特に見栄えについてなんですが、弊社の中に前職が編集者という特殊なバックグラウンドを持って働いている方がいて、その方が作成したレイアウトの参考資料みたいなのがあったりするので、それを基に資料のデザインを整えたりしています。

他にもいろいろと注意点はありますが、一番大事な点は、ぜんぜん資料作成だけの話ではないんですが、この最後に書いてある何らかの意思決定につながっている分析になっているかというところを、常に意識するようにしています。新人分析官あるあるみたいな感じで、「この数値を見たいから出して」と言われて集計だけをして出すような状態にはならないように、この点を常にみんな気をつけています。

チーム内でレビュー

いろいろと報告資料を作ったあとに、最終的にチーム内のレビューを行っています。プロダクトアナリティクスオフィスは分析のアナリストが所属している部署なんですが、こちらでだいたい4人ぐらいのアナリストが1チームを組んでいます。それぞれのチームにある程度経験の長いシニアアナリストがリーダーとして付いて、そのチームの中で報告資料や、あとは新人アナリストの分析設計のレビューなどを行っています。

目的としては、会社としてその分析の報告のクオリティを担保していくところと、新人の育成ですね。弊社では、前職がぜんぜん分析系ではない方も採用しているので、そういう方の育成も担っていたり、あとは人の分析をレビューするのもけっこう大事な経験なので、ここをしっかりと経験を積んでいくところですね。

あとは分析レビューやレビュー会とはまた別に、自主的な取り組みとしてやっているんですが、社内のSlackでチーム単位でのtimes（分報）チャンネルのような、ちょっと雑に発言できるチャンネルを作成して、今どういう作業をしているかや「ちょっとここで詰まっているんだけど」みたいなのを気軽に共有できる環境を作っています。

作成した報告資料を基に報告

最後は報告段階です。作成した報告資料を基にプロデューサーや開発会社さまへの分析結果を報告するというようなフェーズになります。分析によって明らかになったことをしっかり端的に説明して、それに基づいて施策を提案するところがメインですね。施策の提案にちゃんとつながっているような分析になっているかも常に心がけるべきポイントになっています。そこの提案した施策について実装するかどうかだったり、開発優先度はどうだよねだったりするところまでできれば、よりベストかなという感じですね。

開発会社と専門の会社でも、重視すべき点や抑えるべきポイントは同じ

以上のヒアリングから報告までのサイクルを、だいたいのタイトルで定期的に実行するようにしています。シニアアナリストになるとこのヒアリングから報告までをチームで作って、といったところを毎週やっていて、報告会自体も定期的に設定されています。

こちらは、私の前職がアプリの開発会社だったので、そこでの分析業務と比較した感じになります。バンダイナムコネクサスだと、分析専門の会社として作業フローや日程がけっこうきっちり決まっているな、というのが所感になります。

専門の会社というところで、ちゃんと分析のクオリティを担保するためのレビューを行っていたり、あとは何回か申し上げたとおりゲーム分野ですので、親会社のバンダイナムコエンターテインメントと、あとは開発会社とかと複数会社にまたがって動いているため、けっこう大規模だったりというところが、かなり違うかなと思います。

前職の開発会社だと、かなりラフにタスクが進んでいくというか。役職者やマーケ担当がSlack上で「これどんな感じでしたっけ？」と来て、そこにグラフなどを貼って「こんな感じです」といって返すのが、けっこう多かったかなという感じです。でもどちらの会社でも、つまり開発会社と専門の会社でも、重視すべき点や抑えるべきポイントは同じかなというところです。

ちゃんと分析の目的と背景をしっかりした上で取り組むというところ。あと、分析設計をしっかり固めていく。最終的に施策提案や意思決定につながらないような、あまり意味のないような分析はしないというところは、どこの会社でも同じなのかなという印象を受けています。

私からは以上です。ご清聴ありがとうございました。

ゲームはABテストができない

司会者：ありがとうございました。ここでご質問などを募集できればなと思いますが、どなたかある方はいますか？　「実際に自分も分析をやっていて、こういうことに困っているんですけど」など、そういうものでもいいです。あとは「実際にどうだったんですか？」みたいな感じの、気になったポイントや質問でもいいです。

ではちょっと自分から質問しますと、最近あった分析として、離脱分析などをした際に、ここに離脱があるなとわかって深掘りをしていって、実際に施策につなげるとなると、どういうところを見ますか？　実際にやはり問題がありそうなところをプレイされたりしてみて「ここに問題がありそうだ」という仮説を作っていって、そのあとそこを改善してABテストをして離脱率が落ちたかみたいなことを検証したりする感じですか？

齊藤：そうですね。最初はどういうところで離脱をしているかの仮説立てはそのとおりで、分析は基本的に仮説検証のループにはなっていくので実際にどういうところで離脱しているのかの仮説をいろいろ出して、それを検証していく感じになりますね。

実際に対応の施策を入れてみてどれぐらい改善があったかなんですが、ゲームのほうはABテストが不可能というのはありますね。

司会者：じゃあチュートリアルであったとしても、ABテストはできないと。

齊藤：そうですね。どこでユーザー同士良くない差がついちゃうかのようなところを気にしながらやらないといけないので、ゲームアプリでやるのは難しいかな、という感じですね。普通の脆弱なアプリのテストだったら、ぜんぜんABテストをやります。ABテストが検証としては一番一般的だし、強固。実装までいくと簡単とは言えませんが。それが使えないところは、ゲームの分析の難しい点かなというのはありますね。

司会者：なるほど。それであれば、基本的に前後テストとかでやるしかないということですね。

齊藤：そうですね。

司会者：ありがとうございます。なかなかそこらへんの検証とかも難しいんだろうなと思いましたね。

齊藤：そうですね。

司会者：実際にやってみて、あとはこのチュートリアルは、実は要らない。もしくはあとに回そうという、そういった判断をすることもあると思いますが、その場合にどこのタイミングで離脱を取るのかとか。「機能強化のところのチュートリアルをちょっと後ろの工程にしましょう」という話もたぶんあると思いますが、そういう時に、じゃあ何で評価するかというのを例えば1ヶ月継続率のもうちょっとあとの段階で評価するとか、何かそういう難しさがあるなと思いました。

齊藤：そうですね。単純にチュートリアルの離脱だけを見るのか、それによってちゃんと定着はしたか、継続率は何日時点で続いているか、あとはそれをプレイのほうまで行ってくれているかのような項目達成率まで見るかなど、いろいろ見方はあるかなと感じています。

司会者：このへんは、やはりわりと複数タイトルやっていると、なんとなく「これを見ておけばいいよね」みたいなものは、おそらくだいたい固まっている感じなんですよね。

齊藤：そうですね。だいたいは固まるとは思うんですが、全部が全部同じチュートリアルが入るわけではぜんぜんないので、タイトルによって、ちゃんと項目を設定するのは必要かなという印象がありますね。

司会者：なるほど。ありがとうございます。

背景・目的が曖昧な場合は「ひたすら聞く」

司会者：他の質問も来ていまして、「背景と目的のヒアリングが重要だというお話がありましたが、ヒアリングする相手側の背景・目的が曖昧な場合、取るべき対策はどういったものがあるのでしょうか？」。確かにありがちですね。

齊藤：そうですね、ありがちです。これはもうひたすら聞くしかないです。あとはいろいろな人に聞く。プロデューサーに「こっちのプロデューサーはこう言っているけど……」みたいな。プロデューサーが複数人いる場合もあるので、「こっちはこう言っている」とかがある。あとはその背景が正しいんだっけ？　みたいなところの数値確認は、自分でやったりとかしますね。

そもそもの最初の背景というか認識のところからズレている場合は、ちゃんと分析官側で注意してあげないといけない、というところはあります。

司会者：ヒアリングをする中で、相手にも考えてもらうみたいなところがあったりしますか？

齊藤：そうですね。本当は常に考えるのがプロデューサーというかPMとしては正しい姿勢ではあると思うので、そこはやっていきましょうという感じですね。

司会者：なるほど。ありがとうございました。