仮説と実験主義への挑戦と失敗 〜正しい方向で、正しい戦術で、正しいリソースで〜 DevLead by DMM Group 1 Masato Ishigaki October 20, 2021 DevLead #4 by DMM Group

2 About me Masato Ishigaki - 石垣 雅人 メンバーシップサービス部 部長 / VPoE室 DMM.com エンジニア 新卒入社 2017年より、DMMにおけるアカウント(ID)、認証(Auth) のバックエンド周りのプロダクトオーナーを 経て、2018年7月にリードナーチャリング領域を強化するチームやDMMの入り口である総合トップ などを管轄する総合トップ開発部の立ち上げを行い、部長を務める。 現在は、DMMポイントクラブの立ち上げからグロース、ID・認証を司るメンバーシップサービス部の 部長、DMM全体のエンジニア・デザイナー組織課題を解決するVPoE室を兼務している。 著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版 ,2020） @i35_267

3 - Target - 事業責任者, プロダクトマネージャー , エンジニア, デザイナー, プランナー, データアナリスト - Outline - なぜ、仮説と実験か （概念的な話） - 予算 / リソースの制限がある中で、正しい方向に、正しい戦術を、正しいリソースを使って進まないと、事業はすぐに死んでしまう - 3つの “ 正しさ ” （挑戦と失敗のケーススタディ ） - 正しい方向性で、正しい戦術を、正しいリソースで - Scope（= Learning Outcomes） - Scope in : - toC（プロダクトを持ちながらビジネスを展開） , 1 → n… , 仮説検証, KPI, エンジニアリング - Scope out : - DHW, DataPipeline, A/B Test , toB, etc… Outline

4 - Outline - なぜ、仮説と実験か - 予算 / リソースの制限がある中で、正しい方向に正しい戦術で進まないと、事業はすぐに死んでしまう - 3つの “ 正しさ ” - 正しい方向性で、正しい戦術を、正しいリソースで

5 - 事業の短命さと継続性 - 事業の寿命は無限ではない。常に予算とリソースのタイムリミットを意識する必要がある。 - エンジニア含めてプロダクトチーム全員が、裁量と権限があるかは別として、意識はしなければいけない。 必要に応じてはコミットしなければいけない。 - 不確実性が高い事業環境下のなか、イテレーティブな仮説と実験によって伸ばさなければ、事業はすぐに 死んでしまう。作ったシステムもなくなってしまう。 - 天才 と 凡人 - 勝手に伸びることは、天才的なビジネスセンスがなければ、ほぼない。 - 私含めて、普通の人は「データ」を武器に戦わなくてはいけない。再現性の観点。 - 大きなブレイクスルーよりも、 1%の改善を繰り返す。 - “実験” = 実際の経験を行う。ユーザーという指針に実際に適応していく。 - そこから得られる結果を「データ」というファクトをもとに学習しながら、意思決定をしていく。 - 仮説 → 実験 → 学習 → 意思決定を高速に繰り返す。 なぜ、仮説と実験か

6 - 正しい方向で、正しい戦術を、正しいリソースで。 - ただし、仮説と実験が大事だと言っても、闇雲に高速に開発して、リリースすれば良いわけではない。 - 正しい方向で、正しい戦術で、正しいリソースを使いながら進む - “ 正しさ“ - 正しい方向 = - 正しい方向を KPIツリーで語れるか。 - 事業の収益モデルを理解した上で、ログデータでプロットしていく。 - それをKPIツリーに落とし込む。物語としてユーザー行動を追う。 - 課題となるKPIを理解する = この事業を伸ばすための方向性・道標の明確化。 - 正しい戦術 = - 課題のKPIツリー（方向性）に対して、どういった施策を当てるのが良いのかの作戦。 - 大きな機能追加なのか、 UI刷新なのか、キャンペーンなのか。 - 正しいリソース = - 戦術に対して、組織的なコスト（人・モノ・金）をどのぐらいのリソース配分で攻め込んでいくか。 予算コントロールとプロジェクトマネジメント - これを ”仮説” と “実験” で転がしていく なぜ、仮説と実験か 正しい方向 正しい戦術 正しいリソース 仮説 と 実験 で転がしていく t 価値

7 - Outline - なぜ、仮説と実験か - 予算 / リソースの制限がある中で、正しい方向に正しい戦術で進まないと、事業はすぐに死んでしまう - 3つの “ 正しさ ” - 正しい方向性で、正しい戦術を、正しいリソースで

正しい方向で 8

9 正しい方向で - まずはじめにすること。事業モデルを観測可能（ Observability=可観測性）にしていく - ユーザーの細かい挙動をトラッキングしていく - ログデータとして出力することで「データ」として表現できる - KPIツリーで表現する - 一連の動作を「ログデータ」でプロットする - 事業 = 記録できる = データで見える - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 組織が、数字を共通言語へ - 背景としては、クラウド技術の発展や大規模データの並列処理基盤の進化

1 0 Netflix - 正しい方向（KPI）と正しい戦術の例 - Artwork Personalization 引用: https://netflixtechblog.com/artwork-personalization-c589f074ad76 引用 : https://netflixtechblog.com/learning-a-personalized-homepage-aa8ec670359a Learning a Personalized Homepage 極限まで細かくユーザー行動をプロットし、キードライバーとなる KPIに対して、適切な戦術（ = パーソナライズ）を当てていく （仮）KPI : ARR / MRR -> 魅力的なコンテンツを沢山見てもらう -> CTR -> パーソナライズ

© DMM.com DMM ポイントクラブ ここを作っているチームを例に話していく。 モバイル Web

- 失敗例 / パターン - KPIツリーの分解不足による注力箇所を間違える - 自分たちがこれぐらいで良いだろうという分解で、よくないことが多い - Ex. 新規は十分に取れているのに「友達招待キャンペーン」をやる等 - 結局、バケツの穴が空いている状態なので同じことになる。 - プロダクトの初期フェーズなので、まずは熱狂的なコアファンを作る - もっと分解すると、モバイルアプリであれば、ストア経由での流入が多いのか、広告経由な のか、SNS経由なのか。分解できるところまで分解 → 定量化しないと、どこにリソースを 突っ込めば良いかわからない。 - 一緒の数値を見ていない。 - 常に重要KPIは変わっていく。戦略的に変える。 - チーム全員が同じ方向を見るためには、同じデータを見るように整備する。 - 実際の改善案 - KPIダッシュボード = 1つのプロダクトとして管理する意識をつけ数値理解を行う。 - そのためには自分たちで、データ分析する力を全員が身につける。 正しい方向で n n n 利益 MAU 新規 定着 （既存） 復帰 × MAU - User Status 新規 定着 復帰 休眠 70% 20% 10% 8月 12 9月 10月

- 実際の改善案 - KPIダッシュボード = 1つのプロダクトとしての意識性をもたせる - バージョン管理もする（クエリレビュー等） - 毎日のデイリースクラムで確認する - 健康診断ダッシュボードを作成して、 1分以内にチェックするべきデータを確認できる 状態へ。KPIモニタリングの基礎。データを見る文化を形骸化させない。 - プラスして、毎週1hデータ分科会を開催して、予実比の確認 / 今週作ったデータ（クエ リ）の確認 / 各施策を進捗確認を 全員で行う。 13 正しい方向で

正しい戦術を 14

- 「KPI」と 「仮説と実験」はセットで考える。 - KPIツリーが分解 → ダッシュボードで数値管理できるようになったら、目標値を設定。 - Ex. KGI（利益）を1,000万円 → 3,000万円 → どうやったらココにいけるか。その差分を埋め ていく作業に入る。 - 正しい方向に対して、どのような戦術で攻めるか。 - 施策ごとに「予測値」と「実測値」をモニタリングしていく。 - 必ず、学習しないと同じ失敗を繰り返す - だいたい、施策の採用率 / 成功率 = 40 ~ 60% 15 正しい戦術を どんな戦術 = 施策で攻めていくか

- 問いたい “ 仮説 ” と それを証明する “ 実験 “ - その施策をビルドする = 仮説を証明するための一番効率が良い実験方法。 - 失敗例 / パターン - 仮説に対する実験方法が違う = 施策に対する仮説や対象 KPIがない。 - 機能ベースで「これがあったら良い」と主観的に考えがちになる - Ex. 支払い手段を変更してもらいたい。それによって利益が上がる状態になる。 - 予算 : 2,000万円 / セグメントユーザ : DMM会員の200万uu - 戦術として使えるのはポイント。 - パット見の派手さ（バズる）で、山分け方式が案として上がる。 - → しかし、対象 KPIは継続性を求めるもの。 継続ポイント還元 CPが本来の戦術とし ては有効打。 - 対象KPIの理解が前提。 - 戦術バリエーションは他社事例や TTPSでカバー。 16 正しい戦術を どんな戦術 = 施策で攻めていくか

- 失敗例 / パターン - 仮説検証からの学習の部分が全然できていない - 仮説 → 施策 → 実施→結果→理解（認識） →次へ - 仮説 → 施策 → 実施→結果→理解（認識） → 学習→ 次へ - ログが仕込まれてない → 検証 & 学習ができない - 実装してから気づくことが大きい。 - 実装までにトラッキングの設計が不十分。 - 実際の改善案 → BMLループを浸透させる 17 正しい戦術を どんな戦術 = 施策で攻めていくか

- 実際の改善案 - BMLループのプロセスの浸透 1. Learn → Idea = 仮説を考える = 正しい方向 2. Build → Product = どう作るか = 戦術 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 逆回転からの順回転 - その仮説で証明したいことを確認（先に数値管理ダッシュボードを作成する）してから、施策を Buildする 正しい戦術を 18

正しい戦術を 先に仮説と証明したいことを「合意」しておく A/Bテストであれば、A/Aテストも 施策によっては、クエリも先に書いた上で実装に入る A(新) B (既存)

正しいリソースで 20

正しいリソースで 21

- どこに / どのぐらいのリソースを / どの期間 突っ込めるか - プロダクトは、常に動き続けている。 - 人も変化しつづける。 - すべてを器用にこなしながら、走るしかない。 - 施策も、リファクタリングも、データ分析も、 UX改善も、個々の目標 / キャリアも、 n….. - 並列性。どのくらいパラレルに動くか - チームのキャパシティーを計算して、施策の優先度と量を計算する。 - Single Piece Flow（1つのサイクルで 1つの仮説） - 実際の改善案 → 開発プロセスの可観測性を極限まで高める - 試行錯誤中 - 何事もまずは可視化しないと改善できない。改善しても結果がわからない。 22 正しいリソースで

正しいリソースで - 実際の改善案 - 開発プロセスのレイヤーごとの可観測性 - レイヤー1. - コードレベルでのチーム生産性の可視化 - pull request , commit , commentの量から生産性の健全性を可視化 - レイヤー2. - 開発フレームワークに合わせた、ストーリーポイントを元にした生産性の可視化 - Velocity, Cumulative flow, Control Chart - - レイヤー3. - 開発プロセス全般（ MTGの間隔等々も加味した）のリードタイムの改善 - VSM（Value Streaming Mapping） それぞれで可視化をして、現状の戦闘力を知る gilot Cumulative flow Control Chart 23

2 4 - まとめ - なぜ、仮説と実験か - 予算 / リソースの制限がある中で、正しい方向に正しい戦術で進まないと、事業はすぐに死んでしまう - 3つの “ 正しさ ” - 正しい方向性で、正しい戦術を、正しいリソースで