Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
仮説と実験主義への挑戦と失敗〜正しい方向で、正しい戦術で、正しいリソースで〜 /
Masato Ishigaki / 石垣雅人
October 07, 2021
Technology
1
940
仮説と実験主義への挑戦と失敗〜正しい方向で、正しい戦術で、正しいリソースで〜 /
DevLead by DMM Group 登壇資料
https://dmm.connpass.com/event/224908/
Masato Ishigaki / 石垣雅人
October 07, 2021
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
フルサイクルエンジニアリングとは
i35_267
1
140
【SQiP】アジャイル開発の生産性 / What is agile development productivity?
i35_267
3
170
【20min ver.】事業をスケールさせるエンジニアたち〜技術のコモディティ化にエンジニアは敗北する〜 / Connecting Business and Engineering
i35_267
1
1.6k
【融合情報学特別講義Ⅱ】事業とエンジニアリングを繋ぐ力学 - 東京大学 大学院講義 / Connecting Engineering - Business
i35_267
0
410
事業をスケールさせるエンジニアたち〜技術のコモディティ化にエンジニアは敗北する〜 / Connecting Business and Engineering
i35_267
3
1.5k
事業とエンジニアリングを繋ぐ力学
i35_267
1
930
データを武器にプロダクトの不確実性と戦う / DataDriven Development
i35_267
0
1.3k
チームを”群れ”として観察すれば、 アジャイル開発はもっとうまくいく / Swarming Agile
i35_267
0
650
DMM経済圏の確立を目指す上でのパーソナライズ戦略とクロスユース戦略 / DMM Economic Zone
i35_267
1
1.6k
Other Decks in Technology
See All in Technology
創業1年目のスタートアップでAWSコストを抑えるために取り組んでいること / How to Keep AWS Costs Down at a Startup
yuj1osm
3
2k
GitHub Codespaces が拡げる開発環境、いつでもどこでも Visual Studio Code で!
dzeyelid
0
160
証明書って何だっけ? 〜AWSの中間CA移行に備える〜
minorun365
3
2.1k
Oracle Transaction Manager for Microservices Free 22.3 製品概要
oracle4engineer
PRO
5
100
CUEとKubernetesカスタムオペレータを用いた新しいネットワークコントローラをつくってみた
hrk091
1
260
SPA・SSGでSSRのようなOGP対応!
simo123
2
150
あつめたデータをどう扱うか
skrb
1
130
AI Builderについて
miyakemito
0
860
オンプレk8sとEKSの並行運用の実際
ch1aki
0
220
ROS_Japan_UG_#49_LT
maeharakeisuke
0
210
メドレー エンジニア採用資料/ Medley Engineer Guide
medley
3
5k
Airdrop for Open Source Projects
epicsdao
0
500
Featured
See All Featured
A better future with KSS
kneath
230
16k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
7
570
Documentation Writing (for coders)
carmenintech
51
2.9k
What the flash - Photography Introduction
edds
64
10k
10 Git Anti Patterns You Should be Aware of
lemiorhan
643
54k
Three Pipe Problems
jasonvnalue
89
8.9k
Docker and Python
trallard
30
1.9k
KATA
mclloyd
12
9.7k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
29
7.9k
WebSockets: Embracing the real-time Web
robhawkes
58
6k
Mobile First: as difficult as doing things right
swwweet
213
7.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
217
21k
Transcript
仮説と実験主義への挑戦と失敗 〜正しい方向で、正しい戦術で、正しいリソースで〜 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つの “ 正しさ ” - 正しい方向性で、正しい戦術を、正しいリソースで