Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

仮説と実験主義への挑戦と失敗〜正しい方向で、正しい戦術で、正しいリソースで〜 /

仮説と実験主義への挑戦と失敗〜正しい方向で、正しい戦術で、正しいリソースで〜 /

DevLead by DMM Group 登壇資料
https://dmm.connpass.com/event/224908/

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

  1. 2 About me Masato Ishigaki - 石垣 雅人 メンバーシップサービス部 部長

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

    データアナリスト - Outline - なぜ、仮説と実験か (概念的な話) - 予算 / リソースの制限がある中で、正しい方向に、正しい戦術を、正しいリソースを使って進まないと、事業はすぐに死んでしまう - 3つの “ 正しさ ” (挑戦と失敗のケーススタディ ) - 正しい方向性で、正しい戦術を、正しいリソースで - Scope(= Learning Outcomes) - Scope in : - toC(プロダクトを持ちながらビジネスを展開) , 1 → n… , 仮説検証, KPI, エンジニアリング - Scope out : - DHW, DataPipeline, A/B Test , toB, etc… Outline
  3. 5 - 事業の短命さと継続性 - 事業の寿命は無限ではない。常に予算とリソースのタイムリミットを意識する必要がある。 - エンジニア含めてプロダクトチーム全員が、裁量と権限があるかは別として、意識はしなければいけない。 必要に応じてはコミットしなければいけない。 - 不確実性が高い事業環境下のなか、イテレーティブな仮説と実験によって伸ばさなければ、事業はすぐに

    死んでしまう。作ったシステムもなくなってしまう。 - 天才 と 凡人 - 勝手に伸びることは、天才的なビジネスセンスがなければ、ほぼない。 - 私含めて、普通の人は「データ」を武器に戦わなくてはいけない。再現性の観点。 - 大きなブレイクスルーよりも、 1%の改善を繰り返す。 - “実験” = 実際の経験を行う。ユーザーという指針に実際に適応していく。 - そこから得られる結果を「データ」というファクトをもとに学習しながら、意思決定をしていく。 - 仮説 → 実験 → 学習 → 意思決定を高速に繰り返す。 なぜ、仮説と実験か
  4. 6 - 正しい方向で、正しい戦術を、正しいリソースで。 - ただし、仮説と実験が大事だと言っても、闇雲に高速に開発して、リリースすれば良いわけではない。 - 正しい方向で、正しい戦術で、正しいリソースを使いながら進む - “ 正しさ“

    - 正しい方向 = - 正しい方向を KPIツリーで語れるか。 - 事業の収益モデルを理解した上で、ログデータでプロットしていく。 - それをKPIツリーに落とし込む。物語としてユーザー行動を追う。 - 課題となるKPIを理解する = この事業を伸ばすための方向性・道標の明確化。 - 正しい戦術 = - 課題のKPIツリー(方向性)に対して、どういった施策を当てるのが良いのかの作戦。 - 大きな機能追加なのか、 UI刷新なのか、キャンペーンなのか。 - 正しいリソース = - 戦術に対して、組織的なコスト(人・モノ・金)をどのぐらいのリソース配分で攻め込んでいくか。 予算コントロールとプロジェクトマネジメント - これを ”仮説” と “実験” で転がしていく なぜ、仮説と実験か 正しい方向 正しい戦術 正しいリソース 仮説 と 実験 で転がしていく t 価値
  5. 9 正しい方向で - まずはじめにすること。事業モデルを観測可能( Observability=可観測性)にしていく - ユーザーの細かい挙動をトラッキングしていく - ログデータとして出力することで「データ」として表現できる -

    KPIツリーで表現する - 一連の動作を「ログデータ」でプロットする - 事業 = 記録できる = データで見える - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 組織が、数字を共通言語へ - 背景としては、クラウド技術の発展や大規模データの並列処理基盤の進化
  6. 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 -> パーソナライズ
  7. - 失敗例 / パターン - KPIツリーの分解不足による注力箇所を間違える - 自分たちがこれぐらいで良いだろうという分解で、よくないことが多い - Ex.

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

    - 健康診断ダッシュボードを作成して、 1分以内にチェックするべきデータを確認できる 状態へ。KPIモニタリングの基礎。データを見る文化を形骸化させない。 - プラスして、毎週1hデータ分科会を開催して、予実比の確認 / 今週作ったデータ(クエ リ)の確認 / 各施策を進捗確認を 全員で行う。 13 正しい方向で
  9. - 「KPI」と 「仮説と実験」はセットで考える。 - KPIツリーが分解 → ダッシュボードで数値管理できるようになったら、目標値を設定。 - Ex. KGI(利益)を1,000万円

    → 3,000万円 → どうやったらココにいけるか。その差分を埋め ていく作業に入る。 - 正しい方向に対して、どのような戦術で攻めるか。 - 施策ごとに「予測値」と「実測値」をモニタリングしていく。 - 必ず、学習しないと同じ失敗を繰り返す - だいたい、施策の採用率 / 成功率 = 40 ~ 60% 15 正しい戦術を どんな戦術 = 施策で攻めていくか
  10. - 問いたい “ 仮説 ” と それを証明する “ 実験 “

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

    → 実施→結果→理解(認識) →次へ - 仮説 → 施策 → 実施→結果→理解(認識) → 学習→ 次へ - ログが仕込まれてない → 検証 & 学習ができない - 実装してから気づくことが大きい。 - 実装までにトラッキングの設計が不十分。 - 実際の改善案 → BMLループを浸透させる 17 正しい戦術を どんな戦術 = 施策で攻めていくか
  12. - 実際の改善案 - BMLループのプロセスの浸透 1. Learn → Idea = 仮説を考える

    = 正しい方向 2. Build → Product = どう作るか = 戦術 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 逆回転からの順回転 - その仮説で証明したいことを確認(先に数値管理ダッシュボードを作成する)してから、施策を Buildする 正しい戦術を 18
  13. - どこに / どのぐらいのリソースを / どの期間 突っ込めるか - プロダクトは、常に動き続けている。 -

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

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