データに振り回されて失敗したあんなことやこんなこと＋α 　〜なぜ数字の手助けが必要になるのか、その理由と分析の実践例〜

データに振り回されて失敗した
あんなことやこんなこと＋α
～なぜ数字の手助けが必要になるのか、
その理由と分析の実践例～
Copyright (C) 2014 DeNA Co.,Ltd. All Rights Reserved.
November 22, 2014
NOGAMI Daisuke (@dnogami_dena)
Senior Manager
Analytics Dept.
DeNA Co., Ltd.

本日お話させていただく内容
 自己紹介＋発表の背景
 ゲームを面白くするために、
なぜ「分析」＝数字の手助けが必要になるか
 データに振り回されて失敗した事例集と改善結果
① リリース直後のタイトルの改善
② プロモーション結果の分析
③ ゲーム内のバトルが盛り上がらない
④ 割引に頼った売上増加策の失敗
 まとめ
2

自己紹介
 野上大介（のがみだいすけ）
⁃ 分析部シニアマネージャー
 Mobage全体からタイトルまで、様々な問題の分析と改善提案
+
⁃ 複数の有力ゲームデベロッパーに対する分析のコンサルティング
⁃ 複数のタイトルの比較や相乗効果の分析に用いる指標の定義
⁃ 指標を活用しやすくするためのデータ基盤整備
 他の分析部アナリストの分析・改善提案のサポート
⁃ アナリスト＝担当するタイトル・サービスの「分析系事業参謀」
3

自己紹介
 DeNA入社以前の経歴
• 東京大学大学院修了後、野村総合研究所を経て、DeNAに入社
• 野村総合研究所時代は、業界を限定せず、
事業戦略の実現をクライアントの状況に合わせて支援
（リサーチ・戦略立案から、戦略の具体化・業務改革、
事業計画の管理体制構築までニーズに応じてカバー）
 近頃の趣味…ロケット打ち上げ見学
⁃ 11/30(日) 13:24:48のはやぶさ2打ち上げも
種子島に行きます
⁃ ネット中継に加え
札幌でもパブリック
ビューイングあり
4

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

会場にいらっしゃる皆様に質問です
担当業務：
イベント等の企画をする側
プランナー、企画など
「分析」や「データ」は
ゲーム作りの
参考になると思う
正直、データや数字で
ゲーム作りをすることは
好まない・納得できない
6
担当業務：
企画を形にする側
エンジニア、
アート・シナリオなど

 1人ないし少人数で遊ぶ、完成品を提供するゲームであれば、
事前のテストプレイで改善点は見つけられる
 数多くのユーザがお互いに影響し合いながら楽しむゲームでは、
ユーザのゲーム内の状態も生活スタイルも、とにかく多様である
 多くのユーザに対して面白さを提供できているかどうかを、
事前の想定や、数人によるプレイだけで把握することは困難
7
よろこびいかりかなしみ
たのしみ

 「分析」≒「コックピットの計器もみながら飛行機を操縦する」
⁃ 自分の目や感覚だけではなく、数字“も”つかうことで、
ユーザが感じている喜怒哀楽をより丁寧に知ることができる
8

データに振り回されて失敗した事例集と改善結果
① リリース直後のタイトルの改善
② プロモーション結果の分析
③ ゲーム内のバトルが盛り上がらない
④ 割引に頼った売上増加策の失敗
9

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

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

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

#1
KPIの事例をもう1つ…DAUの読み解き方
 DAU（Daily Active Users、その日に遊んだユーザ数）を
ユーザの状態で色分けする
⁃ DAUのノイズが分かりやすくなると共に、
ユーザの気持ちが読み取りやすくなる
• CEDEC2013で発表しました
• 資料はCEDiLとSlideshareにて公開中
13

失敗談#1 を繰り返さないための分析業務の進め方
 失敗をしないためには、仕事の進め方から変えることが望ましい
 製造業などで用いられる課題解決の手法「シックスシグマ」が
行動につなげやすい
14
• タイトルを改善するために適切な課題とKPIを設定する
• 様々なKPIを普段から貯めておく
取り組む課題の定義
（Define）
• （様々なKPIを、すぐに見れるようにしておく）
現状の把握
（Measure）
• 事象の背景の構造に対する仮説を立てた上で分析をする
• 様々な切り口を普段から貯めておく、すぐ集計できるようにする
根本原因の特定
（Analyze）
改善策の検討・設計
（Improve / Design ）
効果や設計の検証
（Control / Verify ）
#1

新規新規ユーザの売上が
失敗談#2 プロモーション結果の分析
 プロモーション予算を変えたときの話
新規
既存既存
⁃ 先月と今月の違いはプロモーション予算を減らしたことだけ
⇒LTVで採算性を確認、予算を元の水準に増やして集客した
16
5月の売上6月の売上
減少していた
新規＝その月にゲームを
始めたユーザ
既存＝前月迄にゲームを
始めたユーザ
#2

#2
 本当の課題「ゲーム開始翌月以降のユーザからの売上減少」
5月
4月
以前
6月
5月
4月
以前
⁃ 始めて1,2ヶ月すると課金を止めるタイトルになっている
⁃ よって、タイトルの中身を改善する方が優先課題
17
5月の売上6月の売上
ゲームを始めた月に
読み替えると、
原因は「既存」にあることが
分かる

失敗談#2と似た事例…LTVを基にした広告出稿
 プロモーションの予算を立てるときの考え方
• 「LTVが、1人当たりのユーザ獲得費用を上回っていれば、
プロモーションをいくらでも続けても良い」
 実績を元にLTVを予測して出稿したが、予測どおりにならない
• ターゲットとするユーザ層以外のLTVは低くなりがち
• いつかはターゲット層を獲得しつくすので、LTVは低下する
18
遊び続ける
= 継続率
課金する
= 生涯課金率
課金を続ける
= 課金継続率
月額平均課金額
×
課金継続月数
ターゲットのユーザ層とそれ以外では、
継続率などが大きくことなる
#2

失敗談#2から得られる教訓と、分析業務の進め方
 事象の背景の構造に対する仮説を立てた上で分析をする
 他の担当者にもサポートを求め、自分の守備範囲外の情報も得る
19
• （手段と目的の関係を明確にする）
（Define）
• （様々なKPIを、すぐに見れるようにしておく）
現状の把握
（Measure）
（Analyze）
#2

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

#3
 成功の要因を適切に把握せず、改良すべき点に気づかなかった
⁃ 実際にゲームの中で起きていたこと
• 改良前のイベント：
敵チームが1人も遊んでいないことが多いので、
バトルの開始直後は様子見をすることが多い
• 改良直後のイベント：
今回は全チームで遊んでいるユーザがいたので、多くのチームで
「敵チームはやる気がある！」と誤解しバトルを始めた
（ただし、遊ぶユーザが分散したので、1人当たりの負担は増えた）
• 2回目以降のイベント：
1人当たりの負担が増えたことでユーザが疲れるイベントと認識。
バトル開始直後の様子見で、敵チームの動いている人数も
気にするようになった
⇒ 2回目は複数の指標を組み合わせる方式に改良すべきだった
※その他のKPIの例は来週Mobage Developers Blogに
後輩アナリストが記事を書きます!(http://developers.mobage.jp/blog/) 21

#3
⁃ 成功の要因を的確に把握し、常に改善を加える
• 変更が悪影響を与えている部分は把握して対処する
• 成功の前提条件が変わった場合にはやり方を見直す
 加えて：前提条件や悪影響を測るKPIの集計は自動化する
⁃ 問題が顕在化しないと、分析を後回しにしてしまいがち
⁃ 集計を自動化し、チームのメンバーが自分で
過去と比較できるようにしておけば、チェックは漏れにくい
• 自分でも確認しやすいし、チームのメンバーにも気づいてもらえる
• 今回であれば、チームごとの活動している人数を比較すべきだった
22

 この失敗への予防策・改善策は、ImproveとControlで行う
必要がある
⁃ Measureが改善されているとより確実になる
23
• （手段と目的の関係を明確にする）
（Define）
• 様々なKPIを、すぐに見れるようにしておく
現状の把握
（Measure）
（Analyze）
• 前提条件が変わった場合にはやり方を見直す
• 改善策が悪影響を与えている部分を把握して対処する
#3

失敗談#4 割引に頼った売上増加策の失敗
 ガチャの施策で売上を改善しようとした話
⁃ 「目玉カードを手に入りやすくすれば（＝価格を割引けば）、
多くの人がガチャを回してくれるのでは」
「負担が軽くなれば、ゲームを続けやすくなるのでは」
⁃ 実際にはユーザ数は増えず、単価が下がって売上も減少、
タイトルの継続率はとくに変わらず
24
○○ガチャ第2弾
第1弾
より確率
アップ！
(1%->2%)
3回目
まで割引
SSR
ガチャる！
目玉となるカードが
より低価格で手に入ると
訴求した
#4
※分かりやすさのため、実際に行った施策とは表現を変えてあります。
※ ここで示した「確率」とは、アイテム別提供割合のことです。

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

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

失敗談#4と似た事例…セット販売の副作用
 セット販売で、アイテムの価値を高く見せようとした話
⁃ 本当に売りたい商品と、比較対象のやや劣る商品を見せる
ことで、高額なセット商品が買いたくなるようにした
⁃ しかし、セット販売が常態化したときに、
売りたい商品の魅力も薄れてしまった
（例：不必要なものが手元にあるので、トレード等で節約できる）
27
アイテム8個付き
10連ガチャ
2,700円
アイテム10個
3,000円
10連ガチャ
3,000円
1個300円の
アイテムの
おまけ8個分、
10連ガチャが
劣ってみえる
ガチャが10回
引けるので、
アイテムだけの
セットが
劣ってみえる
ガチャで
強くなりたい！
アイテムで
沢山戦いたい！
#5
余ったアイテム、
トレードに使っ
てガチャ不要！
余ったカードを
トレードして
アイテムに！

割引が効く3回目を過ぎた影響
⇒次回は～～をして改善を狙う
⁃ 課題に対する手段を適切に選ぶ
⁃ 事象の背景や構造、原理を十分に理解する
⁃ 事前検討やシミュレーションを十分にしておく
 加えて：平均値を要素に分解してみる
⁃ 具体例：ガチャでも”継続率”を見る
28
継続率
ガチャの回数1 2 3 4 5 6 7 8 …
#4

 この失敗への予防策・改善策は、Define,Analyze,Improveで
行う必要がある
⁃ これまでの改善点すべてが必要になる事例
29
• 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする）
（Define）
現状の把握
（Measure）
• 事象の背景や構造、原理を十分に理解する
（Analyze）
• 事前検討やシミュレーションを十分にしておく
#4

• なぜ「分析」＝数字の手助けが必要になるか
• データに振り回されて失敗しないために大切なこと
• 明後日からすぐにできる「分析」
まとめ
30

 「分析」≒「コックピットの計器もみながら飛行機を操縦する」
⁃ 自分の目や感覚だけではなく、数字“も”つかうことで、
ユーザが感じている喜怒哀楽をより丁寧に知ることができる
31

データに振り回されて失敗しないために大切なこと
 「現状を正しく把握して改善策を考えよう」とはよく言われる
 でも、より大事なのは、「課題の定義」、「根本原因の特定」、
「効果や設計の検証」である
32
• 課題に対する手段を適切に選ぶ（手段と目的の関係を明確にする）
（Define）
現状の把握
（Measure）
• 事象の背景や構造、原理を十分に理解する
（Analyze）
• 事前検討やシミュレーションを十分にしておく
）

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

34
本発表の内容のアップロード先は、@dnogami_dena でのツイートと
Facebookでの投稿（https://www.facebook.com/daisuke.nogami）で告知します

データに振り回されて失敗した あんなことやこんなこと＋α 〜なぜ数字の手助けが必要になるのか、その理由と分析の実践例〜

More Related Content