データに振り回されて失敗したあんなことやこんなこと～ゲームのために必要な本当のビジネス・アナリティクス～

1. CEDEC2014 データに振り回されて失敗したあんなことやこんなこと～ゲームのために必要な本当のビジネス・アナリティクス～ Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. September 4, 2014 NOGAMI Daisuke (@dnogami_dena) Analytics Strategist Analystics-Development Gr. Business-Analytics Dept. DeNA Co., Ltd.

2. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 自己紹介  野上大介（のがみだいすけ） • ビジネスアナリティクス部アナリティクス・ディベロップメントグループ ⁃ 社内アナリストの各種分析・改善提案に対するクオリティ管理、複数の有力ゲームデベロッパーに対する分析のコンサルティング ⁃ 複数のタイトルの比較や相乗効果の分析に用いる指標の定義、指標活用のためのデータ基盤整備 • 業務経験をまとめ、CEDEC2013でも発表をさせていただきました「決定版：サービスの盛り上がり具合をDAUから読み解く方法」 ⁃ DeNA入社以前の経歴 • 東京大学大学院修了後、野村総合研究所を経て、DeNAに入社 • 野村総合研究所時代は、業界を限定せず、事業戦略の実現をクライアントの状況に合わせて支援（リサーチ・戦略立案から、戦略の具体化・業務改革、事業計画の管理体制構築までニーズに応じてカバー） 2

3. 「良いタイトルを、長く楽しめるようにしたい！」  タイトルを提供しつづけるには、面白さと、(最低限の)収益の Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 両方を考えた開発・運営がかかせない • 私自身も、サービス終了に涙したタイトルがありました  面白さをチームの「阿吽の呼吸」で維持するのは難しい • ソーシャルゲームでも開発・運営チームの規模は拡大傾向  面白さを明確に共有し、タイトルが理想像に近づいているか、客観的に確認するには「データ」は便利な道具  しかし、業界では、収益ばかりを気にした、「データだけ」を使った分析が目立ちました  タイトルが理想像に近づいているかを確認するための道具として「データも」をうまく活用した分析を増やしていきたい 3

4. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. CEDEC2013での発表内容  DAU（Daily Active Users、その日に遊んだユーザ数）は、ノイズが多くて使いにくい指標だといわれています  しかし、ユーザの状態で色分けすれば「DAUからユーザの気持ちが読み取れ、サービスの改善に活かせる」ことを発表しました • 資料はCEDiLとSlideshareにて公開中 4

5. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 本日お話させていただくこと  5つの失敗談を、以下の流れでお話しします 1. 失敗談 • DeNAのなかで起こったことがある正しくない分析結果、あるいは、分析を元にして行ったが期待外れの結果に終わった施策 • 失敗を未然に防げた場合はその経験談 2. 失敗の直接の原因 3. 失敗から得られる教訓 4. （外部の類似の事例） 5. 失敗を繰り返さないための分析業務の進め方 ※質疑応答の時間が短くなってしまったらごめんなさい ※Twitterでの質問も、タグ#cedec2014 付きや、私へのメンションであれば極力お答えいたします 5

6. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. Mobage developers blogでも予告したところ…  リリース前のKPI（Key Performance Indicator）予測について知りたいというコメントをいただきました ⁃ KPI = 最終的な成果につながる重要な実績を測る指標 • Source: http://developers.mobage.jp/blog/notice-of-cedec2014  直接この質問にお答えできるわけではないのですが、本日最初の失敗談は、リリース前のタイトルに対して行った分析の失敗談にします 6

7.  事前テスト結果からLTVを予測しようとしたときの話 ※LTV = Life Time Value、ユーザ1人当たり生涯課金額のこと ⁃ リリース前の各種テストを実施している担当者が、 #1 社外ユーザアンケート（開発中タイトルを1回遊んでもらってから回答する）の結果からLTVが予測できると報告  3つの点から「相関があります！」と報告したが、納得されず Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1 リリース前のKPI予測 7 アンケート結果リリース後の LTV R2=0.***** Y=**X+*** サンプル数増えてもだめ！

8. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1の直接の原因  事象の背景や構造、原理を考えない ⁃ LTVの増加は、以下の4つの要因で説明できる ⁃ この要因を測定できるテストかどうかを考慮しなかった • 遊び続けるか、課金を続けるか、は、1回のプレイでは分からない  自分の守備範囲の中だけで結論を出そうとする ⁃ より確からしい予測に使えるテストの形式はあるはず ⁃ 自分が担当したテストだけで「分かる」といってしまった 8 遊び続ける = 継続率課金する = 生涯課金率課金を続ける = 課金継続率月額平均課金額 × 課金継続月数 #1

9. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. “事象の背景を考えない”事例  “需要”（ゲームを遊んでくれるユーザさんの数）という背景に対する考慮が弱い分析も散見される  例：「LTVが、1人当たりのユーザ獲得費用を上回っていれば、プロモーションをいくらでも続けても良い」 • ターゲットとするユーザ層以外のLTVは低くなりがち • いつかはターゲット層を獲得しつくすので、LTVは低下する 9 遊び続ける = 継続率課金する = 生涯課金率課金を続ける = 課金継続率月額平均課金額 × 課金継続月数ターゲットのユーザ層とそれ以外では、継続率などが大きくことなる #1

10. “自分の守備範囲だけで結論を出そうとする”事例  減少したタイトルの売上を回復させたい、という事例新規新規新規ユーザの売上が既存既存 ⁃ 先月と今月の違いはプロモーション予算を減らしたことだけ ⇒LTVで採算性を確認、予算を元の水準に増やして集客した 10 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 5月の売上6月の売上減少していた新規＝その月にゲームを始めたユーザ既存＝前月迄にゲームを始めたユーザ #1

11. “自分の守備範囲だけで結論を出そうとする”事例 #1  より大きな課題「ゲーム開始翌月以降のユーザからの売上減少」 5月 4月以前 6月 5月 4月以前 ⁃ 始めて1,2ヶ月すると課金を止めるタイトルになっている ⁃ よって、タイトルの中身を改善する方が優先課題 11 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 5月の売上6月の売上ゲームを始めた月に読み替えると、原因は「既存」にあることが分かる

12. #1 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#1から得られる教訓  原因に挙げたことへの対処 ⁃ 事象の背景の構造に対する仮説を立てた上で分析をする ⁃ 自分の守備範囲外の情報が必要になったら、他の担当者のサポートを求める  加えて：手段と目的の関係を明確にする ⁃ 「社外ユーザに開発中タイトルを1回プレイしてもらい、アンケートを取る」テストの目的は何か？ • 目的：タイトルの改善点を洗い出す ⇒遊んでもらった感想を聞くことは改善点洗い出しには有効（すべての改善点を洗い出せるわけではないが） • データを無理やり、目的外の分析に流用しない 12

13. 失敗談#1 を繰り返さないための分析業務の進め方  失敗をしないためには、仕事の進め方から変えることが望ましい  製造業などで用いられる課題解決の手法「シックスシグマ」で整理すると、Analyzeの部分の進め方を変えるのが良さそう 13 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. • （手段と目的の関係を明確にする）取り組む課題の定義（Define）現状の把握（Measure） • 事象の背景の構造に対する仮説を立てた上で分析をする根本原因の特定（Analyze）改善策の検討・設計（Improve / Design ）効果や設計の検証（Control / Verify ） #1

14. 他と比べて継続率が低いステップがあればそれが原因だが、全体的に低かった Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2 リリース直後のタイトルの改善  とあるタイトルのリリース直後の話 ⁃ n日後の継続率が低く、ユーザが定着しない • チュートリアルの各段階での継続率に分解したが（いわゆるファネル分析）が、原因を発見できず継続率 ⁃ 日次の課金率(=課金UU / DAU)は悪くなかった • 新規ユーザ向け限定に、コンティニュー初回限定の割引を実施  そのタイトルは成功せず ⁃ ユーザが定着せず、課金率も低下してしまった 15 ステップ番号1 2 3 4 5 6 7 8 … #2

15. #2 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2の直接の原因  タイトル改善のための課題が適切ではなかった ⁃ ユーザの定着のための課題：想定していたユーザ層の獲得状況をチェックしていなかった • 30代男性を想定してゲームを制作していたが、実際のユーザは 40代女性の割合が高く、全体的に継続率を押し下げていた ⁃ 課金率維持のための課題：課金継続率をチェックしていなかった • 初回限定の割引を利用して課金をしても、メリットが低かった（コンティニューをしてもクリアできないステージが多かった） • 課金継続率の変化を確認していれば、問題の重大さに早く気付くことができた 16

16. #2 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#2から得られる教訓  原因に挙げたことへの対処 ⁃ タイトルを改善するために適切な課題とKPIを設定する • ユーザの定着⇒想定していたユーザ層の獲得状況 • 課金の継続⇒課金継続率、LTV  加えて：さまざまな切り口とKPIを普段から貯めておく ⁃ 分析の切り口 • 性別、年代、端末、アクティビティを用いたセグメント、… • それらの切り口を用いた集計の仕方を普段から準備しておく ⁃ KPIの事例 • 複数日課金率( = 課金を2日以上したユーザ÷ 全ユーザ) ⁃ ゲームを始めてから、課金をした日が2日以上あるユーザの割合 ⁃ 日付が変わっても課金をしているということは、初回の課金の効果を感じてリピートしてくれているということ ⁃ 優秀なタイトルはこの割合が相対的に高めのことが多いです 17

17. 失敗談#2 を繰り返さないための分析業務の進め方  この失敗への予防策・改善策は、DefineとAnalyzeで行う Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 必要がある  Analyzeを楽にするようなMeasureの改善もあると、なお良い 18 • （手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • （様々なKPIを、すぐに見れるようにしておく）現状の把握（Measure） • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze）改善策の検討・設計（Improve / Design ）効果や設計の検証（Control / Verify ） #2

18. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3 レコメンドなどの仕組みの評価  Mobageの様々な場所に表示されるタイトル紹介の改善 • 以前は、タイトルの人気とLTVを元に一律に表示していたが、ユーザ毎にレコメンドで効率が数倍改善された • モバコイン消費の合計が増えることを期待し、レコメンドの仕組みを拡大し、改善を重ねた  レコメンドは成功したが、モバコイン消費の合計は増えない 19 レコメンドにより効率が大きく改善紹介する場所を増やし、レコメンド自体の精度も向上、レコメンドによるコイン消費も増えた #3

19. #3 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3の直接の原因  モバコイン消費の増加見積もりに用いた比較対象が適切ではない ⁃ レコメンドの成果は、レコメンドの仕組みの巧拙ではなく、ユーザ体験全体の改善によるものだった • 以前の表示の仕組みでは、表示対象になる人気タイトル・高LTVのタイトルは少なく、結果として紹介されるタイトルに変化がなかった • 実は、レコメンドによって現れた効果は、紹介されるタイトルがそのユーザにとって新しく適切なものに変わったことだった  効果測定の指標が（売上だけなのは）適切ではない ⁃ レコメンドの仕組み自体には効果があるし、改良の成果は送客などに出ているが、成果を売上だけで測ってはいけない • 紹介の対象になる良いタイトルがなければ、当然売上は増えない • タイトル紹介の機能なので、タイトルのインストール数や、適切なタイトルを紹介できたかどうかを測る指標が適切 20

20. #3 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#3から得られる教訓  原因に挙げたことへの対処 ⁃ 効果測定の指標や比較対象を適切にする  加えて：投資対効果を求めすぎない ⁃ 売上を増やそうという気持ち自体は悪くない • 売上がクリエーターに還元され、新しい作品作りに活かされる ⁃ 「その効果は売上にするといくらか？」を過剰に聞くと、結果の伝え方がミスリーディングになる場合がある 21

21. 失敗談#3 を繰り返さないための分析業務の進め方  この失敗への予防策・改善策は、Controlで行う必要がある ⁃ とくに、会社全体や、事業部全体のリソース配分をする Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 立場の人が留意したい教訓 22 • （手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • 様々なKPIを、すぐに見れるようにしておく現状の把握（Measure） • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze）改善策の検討・設計（Improve / Design ） • 効果測定の指標や比較対象を適切に／投資対効果を求めすぎない効果や設計の検証（Control / Verify ） #3

22. 変更前…遊ぶ日数は考慮せず変更後…全チームに毎日遊ぶ人がいる Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4 ゲーム内のバトルが盛り上がらない  ゲーム内でのグルーピングを改善してバトルを盛り上げたい ※チーム同士で競ったり戦ったりするバトルを想定 ⁃ 「各チームに毎日遊んでいる人を必ず入れる」というグルーピング方式を野上が提案して導入 ⁃ 初回のバトルは大きく盛り上がりました ⁃ しかし、2回目以降は効果がなくなり元に戻りました 23 チームX チームY 眠眠眠活活眠眠眠眠眠眠眠チームX’ チームY’ 眠眠眠活眠眠眠眠眠活眠眠 #4 相手チームは反撃しない ⇒楽勝！お互いに反撃の応酬 ⇒激戦！

23. #4 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4の直接の原因  成功の要因を適切に把握せず、改良すべき点に気づかなかった ⁃ 実際にゲームの中で起きていたこと • 改良前のイベント：敵チームが1人も遊んでいないことが多いので、バトルの開始直後は様子見をすることが多い • 改良直後のイベント：今回は全チームで遊んでいるユーザがいたので、多くのチームで「敵チームはやる気がある！」と誤解しバトルを始めた（ただし、遊ぶユーザが分散したので、1人当たりの負担は増えた） • 2回目以降のイベント： 1人当たりの負担が増えたことでユーザが疲れるイベントと認識。バトル開始直後の様子見で、敵チームの動いている人数も気にするようになった ⇒ 2回目は複数の指標を組み合わせる方式に改良すべきだった 24

24. #4 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#4から得られる教訓  原因に挙げたことへの対処 ⁃ 成功の要因を的確に把握し、常に改善を加える • 変更が悪影響を与えている部分は把握して対処する • 成功の前提条件が変わった場合にはやり方を見直す  加えて：前提条件や悪影響を測るKPIの集計は自動化する ⁃ 問題が顕在化しないと、分析を後回しにしてしまいがち ⁃ 集計を自動化し、チームのメンバーが自分で過去と比較できるようにしておけば、チェックは漏れにくい • 自分でも確認しやすいし、チームのメンバーにも気づいてもらえる • 今回であれば、チームごとの活動している人数を比較すべきだった 25

25. 失敗談#4 を繰り返さないための分析業務の進め方  この失敗への予防策・改善策は、ImproveとControlで行う Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 必要がある ⁃ Measureが改善されているとより確実になる 26 • （手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • 様々なKPIを、すぐに見れるようにしておく現状の把握（Measure） • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze） • 前提条件が変わった場合にはやり方を見直す改善策の検討・設計（Improve / Design ） • 効果測定の指標や比較対象を適切に／投資対効果を求めすぎない • 改善策が悪影響を与えている部分を把握して対処する効果や設計の検証（Control / Verify ） #4

26. #5 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#5 “期待値”による売上のコントロール【背景】  「ガチャ」の期待値に対する過信 ⁃ 最近のタイトルの主なマネタイズ手段は「ガチャ」なのでガチャの売上を増やしたい ⁃ ガチャの確率から、目玉となるカードを獲得するまでに必要な金額・アクションの期待値を算出することができる ⁃ 期待値を調節すれば売上げが変わる（ように思われている） • 売上= 期待値× ユーザ数 27

27. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#5 “期待値”による売上のコントロール  ガチャを引くユーザ数も売上も増加させたいし、 ARPPUを抑制して継続率を改善したい • 「目玉となるカードが手に入りやすくなれば、多くの人がガチャを回してくれるのでは」「負担が軽くなれば、ゲームを続けやすくなるのでは」 • 実際にはユーザ数は増えず、単価が下がって売上も減少、タイトルの継続率はとくに変わらず 28 ○○ガチャ第2弾第1弾より確率アップ！ (1%->2%) 3回目まで割引 SSR ガチャる！目玉となるカードがより低価格で手に入ると訴求した #5 ※分かりやすさのため、実際に行った施策とは表現を変えてあります。

28. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#5の直接の原因(1,2)  課題に対する手段が適切ではなかった ⁃ 離脱理由ごとの離脱ユーザ数を把握しておくべきだった ※正確な推定は難しいですが、多いか少ないかくらいは把握できる  事象の背景や構造、原理に対する理解が薄かった ⁃ ユーザの、ガチャを回す判断基準は期待値だけではない • 多くのガチャでは、期待値は一目では分からないので、期待値を下げたことをユーザが気づかないこともある • ターゲットとなる（普段ガチャを回さない）ユーザが欲しくないカードを提供しても、ユーザはガチャを回さない 29 ○○ガチャ第2弾第1弾より確率アップ！ (1%->2%) SSR 確率が2倍といっても半額で手に入るわけは無いよな… どうせ高いでしょ僕はこんなに強いカードでなくても十分満足 #5

29. ガチャの回数1 2 3 4 5 6 7 8 … Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. n回以上ガチャをしたユーザ数確率から想定したユーザ数失敗談#5の直接の原因(3)  事前検討やシミュレーションが不足していた ⁃ ユーザ数を増やしても、必ずしも売上が増えないことがある • 期待値を計算するときは、ガチャを回し始めた全員が「目玉カードを取れるまで回し続ける」前提を置くことが多い • 実際は途中であきらめるユーザさんも多い 30 実際にガチャをしたユーザ数割引が効く3回目であきらめたためユーザ数が減った #5

30. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 類似の事例割引販売などの副作用  ユーザの心理を突くテクニックを乱用すると副作用に悩みます ⁃ 割引販売の多用……割引率によってはユーザが定価では購入しなくなる ⁃ おとり戦略の活用…本当に売りたい商品も魅力が損なわれる • 本当に売りたい商品と、比較対象のやや劣る商品を見せることで、高額なセット商品が買いたくなるように誘導する手法 • セット販売が常態化すると、売りたい商品の魅力も薄れやすい（例：不必要なものが手元にあるので、トレード等で節約できる） 31 アイテム8個付き 10連ガチャ 2,700円アイテム10個 3,000円 10連ガチャ 3,000円 1個300円のアイテムのおまけ8個分、 10連ガチャが劣ってみえるガチャが10回引けるので、アイテムだけのセットが劣ってみえるガチャで強くなりたい！アイテムで沢山戦いたい！ #5 余ったアイテム、トレードに使ってガチャ不要！余ったカードをトレードしてアイテムに！

31. 割引が効く3回目を過ぎた影響 ⇒次回は～～をして改善を狙う Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 失敗談#5から得られる教訓  原因に挙げたことへの対処 ⁃ 課題に対する手段を適切に選ぶ ⁃ 事象の背景や構造、原理を十分に理解する ⁃ 事前検討やシミュレーションを十分にしておく  加えて：平均値を要素に分解してみる ⁃ 具体例：ガチャでも”継続率”を見る 33 継続率ガチャの回数1 2 3 4 5 6 7 8 … #5

32. 失敗談#5 を繰り返さないための分析業務の進め方  この失敗への予防策・改善策は、Define,Analyze,Improveで Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 行う必要がある ⁃ これまでの改善点すべてが必要になる事例 34 • 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • 様々なKPIを、すぐに見れるようにしておく現状の把握（Measure） • 事象の背景や構造、原理を十分に理解する • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze） • 前提条件が変わった場合にはやり方を見直す • 事前検討やシミュレーションを十分にしておく改善策の検討・設計（Improve / Design ） • 効果測定の指標や比較対象を適切に／投資対効果を求めすぎない • 改善策が悪影響を与えている部分を把握して対処する効果や設計の検証（Control / Verify ） #5

34. データに振り回されて失敗しないために大切なこと  「現状を正しく把握して改善策を考えよう」とはよく言われる  でも、より大事なのは、「課題の定義」、「根本原因の特定」、 Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. 「効果や設計の検証」である 36 • 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする） • タイトルを改善するために適切な課題とKPIを設定する • 様々なKPIを普段から貯めておく取り組む課題の定義（Define） • 様々なKPIを、すぐに見れるようにしておく現状の把握（Measure） • 事象の背景や構造、原理を十分に理解する • 事象の背景の構造に対する仮説を立てた上で分析をする • 様々な切り口を普段から貯めておく、すぐ集計できるようにする根本原因の特定（Analyze） • 前提条件が変わった場合にはやり方を見直す • 事前検討やシミュレーションを十分にしておく改善策の検討・設計（Improve / Design ） • 効果測定の指標や比較対象を適切に／投資対効果を求めすぎない • 改善策が悪影響を与えている部分を把握して対処する効果や設計の検証（Control / Verify ））

35. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved. アナリストが明日からすぐにできる工夫 1. 自分自身をサンプルとして丁寧に観察してみる • 担当しているタイトルを、1人のユーザとして素直に遊ぶ • 遊んだときのログを取り出して、プレイヤーの気持ちがどのようなログに現れるか確認し、指標にする 2. 作業にかかる負担をなくす • 上記の観察用データを含め、データ集計や可視化は自動化してしまい、作業を後回しにする言い訳をなくす 3. 普段から開発・運用チームのメンバーと真剣に議論をする • 上の2つができていれば、タイトルを理想像に近づける課題が見えてきて、議論の材料もそろうはず • 議論を通じて、チームのメンバーも同じように客観的にゲームの課題を捉えられるようになると、さらに効果が高まる  本日の発表が、より良いタイトル作り・タイトル運営のために参考になれば幸いです 37

データに振り回されて失敗した あんなことやこんなこと ～ゲームのために必要な本当の ビジネス・アナリティクス～

Daisuke Nogami