失敗から学んだデータドリブン開発

Transcript

1. GENSPARK AI PRESENTATION 失敗から学んだ データドリブン開発 — データドリブンな意思決定のための共通⾔語 — 2025.12.12
2. ⽬次 01 はじめに 02 伸びなかった時代 03 データドリブンへの転機 04 A/Bテストの具体的⼿法 05 気づきと学び 06 実践例とサイクル 07 まとめ 08 +α マーケット選び
3. はじめに：なぜこの話をするのか 痛い⽬と学びの共有：過去の失敗から得た教訓 A/Bテストを回し続けて得た、現場レベルのリアルな気づき スクラム検査フェーズで「効果はあったのか？」を数字で振り返る重要性 データドリブンな意思決定のための「チームの共通⾔語」を今⽇つくる
4. 02 伸びなかった時代 最初のスタートアップ 創業者：ソフトバンク最年少部⻑の実⼒者 iPhone普及の⽴役者、⼟⽇も稼働 優秀な開発陣、圧倒的な⾏動量 夜3時まで仕事、睡眠30分の⽇々 RESULT でも、グロースしなかった。 ⼤⼿企業アプリ開発（副業） RESULT メンバー優秀だが、アプリ評価は星2程度。 「優秀で⾏動量もある。じゃあ、なんで伸びないんだろう？」
5. 03. TURNING POINT 転機：データドリブンの業界へ チーム構成 エンジニア1名‧ディレクター1名の⼩規模なハイパーカ ジュアルゲーム事業チーム。 そこに「データ分析担当」 としてジョイン。 データドリブン⽂化 広告費 vs 広告収益のシビアな戦い。 「数字のバランス が全て」という世界観での挑戦。
6. ハイパーカジュアルゲームの定義 定義 SNSや動画広告で配信される 「広告収益 型」 の超カジュアルゲーム 特徴 & 収益モデル すぐ遊べる‧3秒で理解 ⾔語不要‧全世界配信 基本無料‧広告収益 マス向け（⽼若男⼥） 実際のゲーム例（Google Play Store） Ragdoll Bike 100万+ 4.4 Boundman Adventure 100万+ 4.4 Flip Beat: Ragdoll Shooter 100万+ 4.4
7. 定義の再確認 ハイパーカジュアルゲームは、ストーリーやハイグラフィックな表現ではなく コアメカニクスを楽しむことで即時的な快感を楽しむゲームです。 ⽐較項⽬ ハードコア ミッドコア カジュアル ユーザー層 熱⼼なゲーマー 広い範囲のゲーマー ⼀般的なユーザー 幅広いユーザー ⽬的 深い没⼊と挑戦 気軽ながらも やりがいのある体験 気軽な楽しみ 即座の楽しみ プレイ時間 ⻑時間 中時間 短時間 数分以内 複雑さ ⾼い 中間 低い ⾮常に低い 収益モデル サブスクリプション インアプリ購⼊ インアプリ購⼊ 広告 広告 インアプリ購⼊ 広告（インアプリ購⼊） 具体的 タイトル Call of Duty Genshin Impact Clash Royale Marvel Contest Candy Crush Angry Birds 2 Snow Race Mannequin Downhill ハイパーカジュアル 今回のテーマ REF ハイパーカジュアルゲームとは何か？（ユーザー⽬線）
8. WORD ⽤語解説：CPIとROAS CPI Cost Per Install ユーザー1⼈を獲得（インストール）するためにかかった広告費 ⽤。「獲るためのコスト」を⽰す指標。 広告費 ÷ インストール数 EXAMPLE 10,000円を使って、250⼈がインストールした場合 10,000 ÷ 250 = 40円 ハイパーカジュアルの⽬安 $0.30 〜 $0.50 (約45〜75円) ※低いほど良い（安く獲れている） ROAS Return On Ad Spend 使った広告費に対して、どれだけ売上が回収できたかを表す指 標。「儲かっているか」を⽰す指標。 売上 ÷ 広告費 × 100 (%) EXAMPLE 10,000円の広告費で、12,000円の売上があった場合 12,000 ÷ 10,000 × 100 = 120% 判断基準（合格ライン） 100%超で黒字化 ※広告運⽤では120%〜を⽬指すことが多い
9. マーケットインな開発⼿法 ⼀般的な開発とは異なり、作り込む前に「市場の答え」を聞く。プロトタイプ段階でフィードバックを取り⼊れ、リスクを最 ⼩化する。 IDEA アイデア考案 ヒット作の傾向や SNSトレンドを分析し、 コアメカニクスを考案する PROTOTYPE プロトタイプ開発 完成度60〜80%でOK。 コアな⾯⽩さのみを 数⽇〜1週間で実装する MARKET TEST 市場テスト 実際に広告配信を⾏う。 CPI（獲得単価）などの 客観的指標を測定する FEEDBACK 改善 / 判断 データに基づき判断。 数値が悪ければ即座に撤退、 良ければ詳細を作り込む 03 ハイパーカジュアルゲームの開発⼿法
10. 開発プロセスの最適化 LTVとROASの検証を統合し、実情に合わせた3ステップのリーン開発モデルを採⽤。 特にROASテスト期間での「磨き込み」がタイトルの成否を分 けます。 フェーズ Step 1: CPIテスト Step 3: 正式リリース 概要 市場性の確認 コアゲームだけ開発し、動 画広告でクリック率‧CPIを検証 収益化と磨き込み 広告を実装した上で、どんどん磨き上げ るサイクル ステージ追加‧UI改善を⾏い、収益と継続率を 最⼤化 グロース 全世界配信＆クリエイティブ改 善でDL最⼤化 所要期間 2~5 days 2~3 months N/A テスト指標(クリア基 準) CPI < $0.4 獲得単価 D1 RR > 25% 翌⽇継続率 Time > 10min プレイ時間 D0 ROAS > 50% 当⽇回収率 D14 ROAS > 100% 14⽇回収率 D30 ROAS > 100% 30⽇回収率 タイトル本数 100本 ↓ (通過) 1~5本 約3本 ↓ (通過) 約2.5本 約2.5本 クリア確度 1~5% 66% 50% Step 2: ROASテスト 最重要フェーズ ハイパーカジュアルゲームの開発ステップ
11. 学びの源泉：⽇本No.1のナレッジ ⽇本企業アプリ ダウンロー ド数 4年連続 No.1 Kaggle⾦賞クラスの 優秀なメンバーとの協働 4年連続⽇本⼀を達成した 事業部のナレッジ データドリブンな 意思決定の極意を吸収
12. 03 A/Bテスト基盤：Firebase × BigQuery 基盤アーキテクチャ App / Game Firebase SDK Data Warehouse BigQuery Visualization ダッシュボード POINT Firebaseのログが⾃動でBigQueryに流れる設定をするだ エンジニア視点の要点 FirebaseとBigQueryの連携プロジェクトを紐付けるだけで、全 ての⾏動ログがSQLで叩ける状態になる。 ログにパラメータを⾜し込むこれを使って「A群」「B群」の振 り分け情報を仕込むのがカギ。 段階公開の併⽤を推奨コード内の乱数振り分けだけでなく、ス トア機能での段階公開（50%配信）も併⽤してバグを早期検知 する。
13. ここが最重要ポイント ユーザープロパティを使うことで、イベントごとに実装しなくても、勝⼿に「誰がどの群か」が紐づく！ STEP 01 乱数⽣成 ユーザーがアプリを起動した際 に、0〜1の間の乱数を⽣成して保 存する。 STEP 02 閾値で振り分け 乱数を元にグループを決定。 例：0.5未満ならA群 0.5以上ならB群 STEP 03 プロパティ保存 決定したグループ情報を Firebaseの 「ユーザープロパティ」へ設 定。 GOAL ⾃動ログ連携 BigQueryに送られる 全てのイベ ントログに A/B情報が⾃動付与さ れる。 04 ユーザーの振り分け⽅法
14. t検定とは？ 「この結果の差がたまたま（偶然）なのか、実⼒（必然）なのか」を確率で計算する⽅法。 P値（Probability Value）という指 標で判断します。 P値 確率 解釈 判断 P = 0.5 50% 50%の確率で偶然。 コイントスと同じで信⽤できない。 信⽤不可 P = 0.1 10% 10%の確率で偶然。 まだ誤差の可能性が⾼い。 怪しい P = 0.01 1% 1%の確率で偶然。 ⾼信頼 P = 0.05 基準 5% 5%の確率で偶然。 ⼀般的にここを「有意」のラインとする。 採⽤基準 05 統計的な判断基準（P値）
15. ABTestHelper.ts のコアロジック 「乱数による公平な振り分け」と「永続化による⼀貫性」が鍵。⼀度決まった設定はユーザー体験保護のため勝⼿に変えない。分析基盤 （Firebase/BigQuery）への同期も⾃動化し、実装漏れを防ぐ設計。 アプリ起動 START componentDidMount で初期 化処理 initialize()呼出 既存設定確認 CHECK loadFromStorage() AsyncStorage確認 キャッ シュ優先 新規振り分け ASSIGN generateConfig() 乱数で3つ のテストを 独⽴して判定 永続化 PERSIST saveToStorage() 結果を保存 し グループを固定 分析連携 SYNC syncToFirebase() User Property送信 BigQuery分析 ⽤ キャッシュ保持 CACHE メモリ保持 次回以降は 即座に設定を返す DEV 実装フロー：起動→振り分け→永続化→Firebase同期
16. コード実装：乱数振り分け∕永続化 乱数による独⽴振り分け 各テスト項⽬（AdMob, Interstitial, AppOpen）に対し て、Math.random() と設定⽐率（RATIOS）を⽐較して判 定。 それぞれのテストは独⽴しており、全ての組み合わせ が発⽣しうる設計です。これにより、各広告フォーマット の影響を個別に計測可能にします。 AsyncStorageによる永続化 2. 永続化 (saveToStorage) 1. 乱数振り分け (generateConfig)
17. DEV コード実装：Firebase同期 同期ロジックの要点 User Propertyへのセット analytics().setUserProperty()を使⽤し て、ユーザー属性として値を送信。イベントパラメータではなくプ ロパティにすることで、セグメント分けが可能に。 BigQuery連携と分析 重要 Firebaseの⽣データをBigQueryにエクス ポート。SQLを⽤いて「テストAのグループ」と「リテンション率」 をクロス集計できる基盤を作る。 安全な実⾏処理 try/catchブロックで囲むことで、万が⼀Firebase SDKが初期化エラーを起こしても、アプリ⾃体がクラッシュしない よう保護。 全テストIDの⼀括送信 Promise.all()を使⽤し、AdMob、 Interstitial、App Openなど全てのテスト設定を並列で確実に同期。
18. 設定画⾯での可視化 運⽤‧確認のポイント 現在のステータス確認 設定画⾯の「A/Bテスト設定」欄で、⾃⾝に割り当てられたパターン（有効 /無効）を即座に確認可能。 再振り分けの⼿順 ① アプリのストレージ削除 → ② 再起動 → ③ initialize() で乱数再⽣成‧再割り 当てを実⾏。 分析環境での確認 Firebase DebugViewやBigQueryで、User Property が正しく送信されているか 検証。 注意：本番環境の既存ユーザーは「永続化」によりグループが固定されます。 DEV 開発者向け確認⽅法：割当の可視化と再振り分け 現在の適⽤パターン
19. A/Bテストで得た5つの気づき 絶対に良くなる仕組み：A/Bで良い⽅だけを採⽤し続ける 変数へのフォーカス：市場要因ではなく、⾃分たちで操作できる変数に集中する 勘の正体：データ検証の積み重ねによって、直感の精度が磨かれる トッププレイヤーの思考：10億DL達成者はA/B結果のシミュレーションを常に内⾯化している コア体験優先：「どこに⼿を⼊れるか」が全て。周辺機能よりコアの磨き込み
20. よくある勘違いを解く 勘違い：「⼩さいテストしかできない」 ⼤規模な変更こそ検証すべき 開発コストが⾼い施策ほど、全ユーザー展開前にA/Bテストで効果を確認することで、リスクを最⼩限に抑えられます。 勘違い：「複数テストは同時に回せない」 影響が被らなければ並⾏OK 例えば「UI変更」と「パラメータ調整」など、互いに⼲渉しないテストは同時に⾛らせて、開発スピードを落とさないのが鉄則です。 勘違い：「過去の勝ちパターンを繰り返せばいい」 守り＋新仮説の「攻め」が必要 過去の成功事例は「守り」。他社事例や新しいアイデアから仮説を⽴て、まだ⾒ぬ「攻め」の施策を検証し続けることが成⻑の鍵です。 勘違い：「すべての修正をテストすべき」 シンプルなバグ修正は即時適⽤ 明らかなバグや不具合の修正は、データ検証をするまでもなくユーザー体験を損ねています。迷わず即座に全ユーザーへ適⽤すべきです。
21. 06 応⽤：コード外やビジネスアプリへ コード外（SNS等）の活⽤ 「昨⽇の投稿と今⽇、どっちが伸びた？」という⽐較も⽴派 なA/Bテスト 条件をある程度揃え、10〜20%以上の明確な改善が⾒られた ら判断する 完璧な統計を求めすぎず、「⼤きな差」があるかどうかをま ず⾒る POINT 迷ったら検定するくらいでOK。 まずは⼤きな差を⾒ることから始める。 Web/業務アプリへの応⽤ ゲームと違い、機能的価値が⾔語化されやすいため、他社の 事例を応⽤しやすい NetflixやAmazonなどの⼤⼿テック企業のA/Bテスト事例は宝 の⼭ ⾏動経済学の研究など、効果が証明されているものは積極的 に取り⼊れる POINT ⾮⾔語的なゲームよりも、 論理的な仮説検証がしやすい領域。
22. 今後どう活かすか（スクラム検査） 「この施策、数字で⾒るとどうだった？」 「勝ち / 負け / 中⽴、どれだった？」 「次のスプリントで検証すべきことは何だろう？」 感覚ではなくデータに基づいた議論へ
23. 並⾏処理による⾼速化 判定を待ってから開発するのではなく、常に「データ収集」と「次の実装」を並⾏して進める。週2回の判定で、改善スピードを最⼤化す る。 リリース＆判定 ⽕曜⽇ ⾦曜実装分をリリースし 同時に前週⾦ 曜分の判定を⾏う。 結果を⾒て⽔〜⾦ の計画を修正。 収集 ＋ 並⾏開発 ⽔曜〜⽊曜 ⽕曜リリース分のデータを収集しつつ、 ⾦曜リリース分を実装する。 ⼿を⽌め ずに開発を進める。 リリース＆判定 ⾦曜⽇ ⽕曜実装分をリリースし 同時に⽕曜リ リース分の判定を⾏う。 週末〜⽉曜の 計画を決定。 収集 ＋ 並⾏開発 ⼟曜〜⽉曜 ⾦曜リリース分のデータを収集しつつ、 ⽕曜リリース分を実装する。 ⽕曜⽇の リリースへ備える。 06 開発サイクル：週2回のリリースと判定
24. 同時並⾏での検証 影響範囲が被らなければ、開発スピードに合わせて複数のテストを同時に回すことが可能です。 1週間で6個程度の施策を検証していた実際例です。 ID テスト項⽬ カテゴリ テスト内容 (A vs B) AB1 スローモーション Mechanic 従来 VS 敵に当たってから発動 AB2 操作性 UX 従来 VS 回転しやすく調整 AB3 透明壁 Level あり VS なし AB4 キャラのHP Balance なし VS あり AB5 表⽰情報 UI レベル番号 VS 撃破数カウンター AB6 画⾯切り替え Tempo 通常 VS ⾼速化 実際の検証画⾯（同時検証中） 06 ABテスト実例（同時に複数回す）
25. 07 実ダッシュボード構成：サマリーと各A/Bテスト詳細 上半分：サマリー（全体KPI） リテンション指標: D1 / D7 Retention 収益性指標: CPI, ROAS, 収益額 規模指標: DL数, セッション数 下半分：各A/Bテスト詳細 ステージ分析: 離脱率のヒートマップ プレイ体験: 平均クリア秒数, タップ数, アンドゥ数 進⾏度: リテンション推移, 最⼤ステージクリア数 社外秘
26. 07 判定プロセスと運⽤フロー 判定プロセス図 Googleスライド上での意思決定プロセスの可視化例 運⽤フロー詳細 判定フロー 1. 検証 & 統計判断 ダッシュボード確認 → t検定で P値 < 0.05 を確認。 統計的な有意差があるかを客観的に判断します。 2. 判定基準 勝ち全体KPI‧主要指標が有意に改善（即採⽤） 継続効果傾 向あり‧サンプル不⾜（追加実験） 負け悪化または有意差な し（優先度低‧却下） 社外秘
27. 例1: スローモーション 明確な差 A: 従来 Ret 22.15% B: 敵接触発動 Ret 20.10% A採⽤（従来） 例2: 画⾯切り替え速度 数値は同等 A: 通常 Ad 10.76 B: ⾼速化 Ad 10.76 体験が良い⽅を優先 B採⽤（UX重視） 例3: 決着がつかない 誤差範囲 A: パターン0 Ret 34.41% B: パターン1 Ret 34.83% 判断するには早すぎる 継続計測 判定の基本ルール 勝ち 迷わず採⽤する 負け 撤退か、磨き込むか判断 中⽴‧同等 UXが良い⽅ / 進⾏しやすい⽅ 07 判定の実例と対応
28. ⼩さな改善の積み重ねが、⼤きな成果を⽣む D1リテンションが15%から28.5%へ、約2倍に改善。 これは⼀発逆転のホームランではなく、毎週のA/Bテストによる地道なヒットの積み重ねでした。 週 CPI(⽬標 $0.40以下) (翌⽇継続率) 広告視聴(回数/⼈) 0週 ⽬ $0.40 15.0% 3.0 1週 ⽬ $0.38 17.8% 4.3 2週 ⽬ $0.38 21.1% 5.4 D1 Retentionの推移 07 改善推移（CPI/Retention/広告視聴）
29. 効いた施策 / 効かなかった施策 効いた施策 ステージ⼤量追加（数⼗単位） ボイス‧SE（効果⾳）の追加 画⾯切り替え秒数の短縮 ステージの印象に個性を持たせる 効かなかった / 中⽴ キャラをマネキンに変更（悪化） ホールド中スロー機能 フライテキスト（HEADSHOT!など） 弾痕エフェクト / COMPLETE表⽰ 「絶対良くなる」と思った施策が効かないこともある。
30. 共通⾔語による⾼速改善サイクル 「失敗」を責めるのではなく、データに基づいた「学習」として扱うことで、チーム全体で精度を⾼めていく。 WEEKLY 整理と計画 今週やった施策と結果、 翌週やるべき検証項⽬を 毎週整理する。 ANALYZE 要因の⾔語化 「なぜ効いたか」 「なぜ効かなかったか」を チームで議論し⾔語化する。 STOCK ナレッジ資産化 「効かなかった」も重要な資 産。 失敗事例として蓄積し、 同じ失敗を再発させない。 CULTURE 壁打ちの関係性 綺麗な資料ではなく、 ⽣のダッシュボードを⾒ながら 「この数字どう？」と話す。 07 チーム学習サイクルの構築
31. まとめ 優秀さと⾏動⼒だけでは伸びない。それを痛感した A/Bテストで「良いものだけを採⽤する」仕組みが必要 勘は積み上げた結果。データで磨かれた勘は、最終的に精度の⾼い直感になる 難しい統計は不要。基本的な⼿法で⼗分対応可能 検査フェーズでの振り返りを「共通⾔語」で⾏えるようになろう
32. EXTRA SESSION +α：マーケット選びも データドリブンに 作り込む前に、市場適合を ⼩さく検証する
33. プロダクトを作り込む前に「市場性」を問う 開発リソースを⼤量投下する前に、まず「売れるかどうか」を最⼩コストで確認する。 STEP 01 MVP作成 3ステージ程度の 最低限の機能のみ。 数⽇で⽤意する。 STEP 02 広告配信 実際に広告を出稿。 動画クリエイティブで ユーザーの反応を⾒る。 STEP 03 CPI測定 1インストールあたりの コストを計測。 基準：$0.4（約60円）以下 VALUATION 検証判定 1回の検証コストは 約4万円のみ。 結 果次第でGO / NO GO。 EX CPIテスト⼿法
34. Firebase実測値に基づく⽬安 以下は実際のFirebaseデータを元にしたカテゴリ別リテンション（継続率）の⽬安です。 アプリの性質により「適正値」は異なるため、⼀律の基準ではなくカテゴリ特性を考慮して判断します。 カテゴリ D1 Retention(翌⽇継続率) D7 / D30(⻑期継続率) 特徴‧ポイント 基準例 ハイパーカジュアル 60%以上 - ダダサバイバー開発元の基準例。 ヒットには極めて⾼いD1が不可⽋。 ポイ活‧レシート系 41.6% 23.5% / 15.3% インセンティブ設計により継続率が⾼い。 D30でも15%以上を維持する傾向。 健康‧フィットネス系 42.7% 25.8% / 15.9% 習慣形成アプリのためD1が⾼い。 ⻑期継続も安定しやすいカテゴリ。 エンタメ‧漫画系 25.3% 9.9% / 4.5% コンテンツ消費型で離脱が早い。 ハマる層とそうでない層が⼆極化。 判断基準と参考値：業界別リテンション⽬安（1/2）
35. モデルによる重要指標の違い リテンションだけでなく、規模（DAU）や市場性（CTR）が最優先されるケースもあります。⾃社プロダクトの性質に合わせたKPI設定が重要で す。 業界カテゴリー D1 Retention D7 Retention D30 Retention 特徴とポイント コミュニティ系 6.6% 2.7% 0.9% DAU/MAU重視型 リテンション率は低いが、特定層 の熱狂的な利⽤により規模(MAU)で勝負するモデ ル。 シンプルツール系 34.5% 19.9% 13.5% ⽤途特化‧⽣活密着 カレンダー等は⻑期継続する が、電卓などの単機能ツールは⽬的達成後の離脱 も早い。 LP+広告テスト (軽量検証フェーズ) ※リテンション計測前 CPI換算: アプリにより異なる 市場性（Marketability）検証 プロダクト開発前の 需要確認。CTR（クリック率）とCPI（獲得単価） のみで判断する。 REF 判断基準と参考値：業界別リテンション⽬安（2/2）
36. Presentation by Genspark AI ご清聴ありがとうございました データドリブンな意思決定のための共通⾔語 NEXT SPRINT ACTIONS 1つでいい、 A/Bテストを始める ダッシュボードを⾒て 判定する 数字を共通⾔語にして 学習を回す