CEDEC2014にて発表させていただいた内容です。 発表日時 : 2014年9月4日(木) 13:30～14:30 公式URL : http://cedec.cesa.or.jp/2014/session/BP/16553.html 中継URL : http://www.ustream.tv/channel/cedec-ust-c Mobage Developers blogでの予告 : http://developers.mobage.jp/blog/notice-of-cedec2014 反応 : togetter等でとりまとめ予定 セッションの内容 ■ビッグデータという言葉が一般化しつつある昨今、より重要なのは、データを適切に解釈し、価値を生み出す「アナリティクス（分析）」であると言われています。ゲームアプリやソーシャルゲームの世界においても、データからどのようにゲームを面白くする改善点を見いだすかという分析は、以前から課題となっていました。 ■しかし、実際には、データの適切でない解釈や、不適切に設定されたKPI (Key Performance Indicator）のせいで、「データに振り回されて失敗する」という事例はDeNAにおいても多発しており、どうやらそれはDeNAの中だけの話ではないようなのです。 ■そこで、今回の発表では、「データに振り回された失敗」をふまえ、どのようにデータを解釈すれば「ゲームを面白くするための改善点を見いだせるか」についてお話をさせていただきます。 ■CEDEC2013において、ユーザ数（DAU）だけでサービスの盛り上がり具合を丁寧に読み解く講演を行い、分かりやすいという評価をいただきましたが、その際の事例は、あくまで「非常にリアルに作った架空の事例」でした。今回の発表では、分かりやすさはそのままに、より具体的な失敗例を通じて、本当に必要なアナリティクスとはなにかを発表させていただきます。

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

33. Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved.
• データに振り回されて失敗しないために大切なこと
• アナリストが明日からすぐにできる工夫
まとめ
35

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

36. 38
Twitterでのお問い合わせ先: @dnogami_dena へのメンション
あるいはタグ#cedec2014 付きのツイート
Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved.