データを武器にプロダクトの不確実性と戦う / DataDriven Development

2021/1/22 ProductZine ウィビナー 登壇資料

Transcript

1. データを武器に プロダクトの不確実性と戦う ProductZine Zoom webinar 1 Masato Ishigaki January 12 , 2021
2. About me Masato Ishigaki / 石垣 雅人 DMM.com 総合トップ開発部 部長 
 2015年度 エンジニア 新卒入社 2017年より、DMMにおける3000万のアカウント(ID)、認証(Auth) のバックエンド 周りのプロダクトオーナーを経て、 2018年7月にリードナーチャリング領域を強化す るチームの立ち上げを行う。 2020年より、DMMの総合トップなどを管轄する総合 トップ開発部の部長を務める。 現在は『DMM PointClub』アプリやモバイルSDKのプロダクトオーナーにも 従事 @i35_267 i35-267
3. 参考書籍 DMM.comを支えるデータ駆動戦略 2020/9/24 マイナビ出版より発売 - プロダクトを不確実性にどう立ち向かうのか - データをもとに事業（プロダクト）を表現する - 仮説検証プロセスを構築する - アジャイル開発で適切な粒度で適切なセグメントで作る - 不確実性に強い組織のあり方 キーワード - 事業 / システム理論 / KPI / 数値モデル / 機械学習 - 仮説検証 / BMLループ / ABテスト / バリューストリーム / プロセス - アジャイル / スクラム / XP / 自己組織化 / Unlearn / パターン - データ民主化 / DWH ,etc..
4. Outline / Structure of the Talk 「データを武器にプロダクトの不確実性と戦う」　
 不確実性が高い事業環境の中、私たちは誰も正解を持っていない状態でプロダクトを開発しなければなりません。 
 正解がないものを作るということは、すべてが「仮説」になってしまうということです。 
 そんな「仮説」と「正解」の間で、私たちはどんな「武器」を持ってこれから戦っていくべきでしょうか。 
 ひとつのアプローチとしては、「データ」を武器にプロダクト開発をあらゆる範囲を組み立てていく方法です。 
 本ウェビナーでは、データを軸としたプロダクト開発であるデータ駆動開発について事業構造、仮説検証、アジャイル、組織のあり方をお話 できればと思います。 
 
 ProductZineより

5. Seminar Target - 領域 組織 ユーザー 事業 データ基盤 ユーザー行動のログデータ データ駆動 / データ活用 - プロダクト開発を構成する 4つ - 事業（サービス） / ユーザー / 組織 / データ基盤 - 不確実性と戦うには、 4つを組み合わせたプロセスの構築が必要 - 同時にこの4つがあらゆる不確実性を生み出し混乱させている - 特に「データ」を正しく扱い、武器として戦っていく必要がある - データは魔法ではない。定性的なものも大事 - 今回のターゲット設定 - プロダクトマネージャー / 事業責任者向け - 事業 / ユーザーについてを中心に触れていきます。 - 時間の関係上、データ基盤 / 組織についてはあまり触れません。
6. Value MVP Minimum Viable Product PMF Product Market Fit Scale PSF Problem Solution Fit 投資に例えたときのイメージ シード シリーズA シリーズB→C IPO 構築 仮説ベースの検証 定義サマリー ・ターゲットの囲い込みの成功（前提） ・Unit Economicsの達成（収益化できる状態。 not 収益化している状態） Pivot 定義サマリー ・Unit EconomicsをScaleさせる。 ・→ その場合にもきちんと成り立つか。キャズム理論でいう CACの変化など。 ・必要に応じて、 GTM（ ）の確保 ・ への達成と の拡大 Seminar Target - Phase データ駆動が中心となる 0→1 1→... t 0→1の部分でもMVPなり、データ駆動を 前提としたプロダクト開発をしないといけな い。
7. 　Q1. Q1. プロダクト開発における データ関連で困っていること 選択肢（複数選択可） ❏ 定量と定性の塩梅 ❏ KPIツリーの作り方 ❏ 仮説検証の実施方法 ❏ データ文化と組織 ✔
8. 　Agenda
9. 　Agenda Part.1 事業を科学的に理解して、正しいベクトルで進む Part.2 仮説検証の繰り返しで、ユーザーを理解する
10. Part. 1 事業を科学的に理解して、正しいベクトルで進める
11. 　Q2. Q2. プロダクトのKPIを設定していますか？ また、きちんと毎日データを見ていますか？ 選択肢 • プロダクトのKPIを知っている • 毎日そのデータを見ている • あまり意識していない • その他
12. 　Q2. A. KPIを認識するということは、 事業構造を詳細に理解することであり、 毎日データを見ることは事業の健康診断である
13. 　事業構造をKPIで表現し、データで予測可能性をつくる - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が 見え てくる。事業の方程式が見えてくる。 - 変数に対して代入すれば出力を予測できる - 事業構造を科学的に把握する手段 = KPIツリー - プロダクトにおける一連の動作を数値モデルとして表現しただけでは事 業の現状を可視化しただけで事業改善は生まれません。 - 継続的な 事業改善を行うためには指標を決め、それに向かって改善を 進めていく必要があある - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる - KPIツリーは事業の健康診断 ≈
14. 事業の可観測性（Observability） を高める - 事業モデルを定量的な数値モデルで捉える - ユーザーの細かい挙動をトラッキングしていく - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 一連の動作をログデータでプロットする - プロダクトにおける一連の動作を数値モデルとして表現する - ユーザー行動を物語のように追うことができる - 事業をソフトウェアとして捉える = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化
15. 財務諸表（マクロ）から1ユーザー行動（ミクロ）をつなげる - マクロからミクロまでをつなげる - 事業の最終的な出力は、財務諸表に表れてくる - 例えば、P/L（損益計算書） - どれだけ売上をあげて（売上高や粗利） - その中で、コストがかかり（販促費） - どのぐらいの利益がでたか（営業利益） - このP/Lの売上は、1ユーザー行動の合算である。 - 詳細に事業の可観測性をデータでプロットができれば、より ユーザーのことが理解できる。
16. 事業の計算式が見えることで予測ができる
17. 事業の計算式が見えることで予測ができる
18. 操作可能変数 / キードライバーを把握して、 事業の予測をする - KPIを用いた事業改善は、操作可能変数を意識する - KPIツリーの中で操作可能変数 = 自分たちが操作できる変数 を見つけて値を代入する - 変数を代入したことによる KGIがどう変化するのかを観察する - Ex. クーポン単価 / プラットフォーム手数料 / 広告予算 - キードライバーを理解する - キードライバー（影響力の強い変数） - Ex. ユニットエコノミクスや先行指標となる KPI ~---- ---- ---- - ここまでで、事業構造がデータとして表現できるようになる。
19. Part. 2 仮説検証を繰り返しで、ユーザーを理解する
20. Value MVP Minimum Viable Product PMF Product Market Fit Scale PSF Problem Solution Fit 投資に例えたときのイメージ シード シリーズA シリーズB→C IPO 構築 仮説ベースの検証 定義サマリー ・ターゲットの囲い込みの成功（前提） ・Unit Economicsの達成（収益化できる状態。 not 収益化している状態） Pivot 定義サマリー ・Unit EconomicsをScaleさせる。 ・→ その場合にもきちんと成り立つか。キャズム理論でいう CACの変化など。 ・必要に応じて、 GTM（ ）の確保 ・ への達成と の拡大 Seminar Target - Phase データ駆動が中心となる 0→1 1→... t 0→1の部分でもMVPなり、データ駆動を 前提としたプロダクト開発をしないといけな い。
21. 仮説検証は、予測値と目標値のズレをなくす作業 予測値と実測値の不確実性をなくす - 目標値を設定する - KPIツリーと操作可能変数がわかったら、 - あとは目標値を設定して、その差分を埋めていく作業に入 る。 - Ex. 売上KGIを1,000万円 → 2,000万円 - 仮説検証の繰り返しで、予測値と実測値のズレを検知する - 仮説検証は、この予測値と実測値のズレをなくすこと - 初期の仮説検証は、質よりも量を重要視する - トレードオフスライダーを作る - 計画に時間をかけない。 - まずは、高速に仮説検証プロセスを回す基盤を作り、仮説 の学習を繰り返すことで徐々に精度（採用率）が上がってく る
22. 仮 説 → 実 験 → 学 習 → 意思決定 - 不確実性と どう戦っていくか - 事業の寿命は無限にあるわけではなく、常に予算を中心とし たタイムリミットを意識する必要がある - 特にシードやシリーズ Aの時期 - 実験しながら学習していく - "実験"をすることが大事 - 実験とは言葉のとおり「実際の経験」という 意味 - ユーザーという指針を頼りにしながら、実験を繰り返し、そこか ら得られる結果を「データ」というファクトをもとに学習しなが ら、意思決定をしていく - 仮説検証のプロセスが大事
23. 失敗できる環境をつくり出すことで 組織は加速する - 失敗の恐怖。PDCAのPを重視しない - 事業をスケールさせるには、改善施策を合理的に正しい方 向 でどれだけ数多く実行できるかが鍵になる。 - ハードルとなっているのが、失敗への恐怖心です。誰もが思う 「失敗したくない」 という壁が、あらゆる改善の実施に歯止めを かけている。それが組織として存在する - = 前段階にある計画の部分に時間をかける - 失敗をコントロールする - 失敗を”なくす”のではなく、事業構造を理解した上で失敗でき る範囲（予算など）を明確にし、その影響範囲の中で適切に失 敗をさせるこ
24. A/Bテストによる ”実験” - A/Bテスト - A/Bテストとは、元の機能に変更を加える際に Aパター ンとBパ ターンを用意してテストする手法 - A/Bテストの意味は、「失敗をコントロール」すること - A/Bテストの比重と期間の考え方 - A/Bテストの比重については、統計学的な分析でサンプル数を 満たす割合を見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する - また、仮説検証の大きなによっては A/Bテストに向かないケー スもある。Ex. UIの大々的なリブランディング
25. 仮説検証プロセスをBMLループで作る - BMLループのプロセス 1. Learn → Idea = 仮説を考える 2. Build → Product = どう作るか 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 仮説検証とデータ - Product → Measure - ログデータの設計 - トラッキングを仕込む - Measure → Data - 施策（仮説検証）ごとにダッシュボードを作成する - 日々、観測する
26. ダッシュボードの種類 - 施策ベースのダッシュボード - 仮説は何か - 指標は何か（改善したい指標） - そこから学習したいことは何か - A/Bテスト実施期間 - ダッシュボードの種類は大きく分けて 3つ 1. KPIダッシュボード（事業向け） 2. 施策ベースのダッシュボード（事業向け） 3. 経営向けダッシュボード（経営レイヤー）
27. 仮説検証の失敗例 - 計測サンプルが足りない - 計測からの学習（Measure → Learn）の部分でよくある事象として、 データ量が足りないケースが あります。 - 特にサービスイン直後、検証に必要なデータ量がそもそも存在せず、 いくらA/Bテストで 比重を調整しながら慎重にテストしたとしても、サン プル数が足りないという罠があります。 - また、異常値である特定ユーザーの趣味嗜好が強く反映されて しまい テストを実施するたびに結果が変わることがあり、全ユーザーに適応し て良いものかが判断で きません。 きちんと整備されたデータ量は多け れば多いほど正しく統計できるため、事前に計測できるデータ量 は確 認しておくべきです。 - ログが仕込まれていない - 仮説から施策を考えて、実装へ落とし込む際によくあることとして必要 なログが仕込まれていないことがあります。 - 実装（Build）の際に計測（Measure）時に必要なデータをきちんと計画 していないことが多く見受け られます。そうすると施策を実施したあと に結果をうまく見ることができずに手戻りが発生するケー スが往々にし てあります。 - 仮説と機能のバランスが崩れている - 仮説に対する機能のバランスが取れていない事象があります。よくあ るケースとしてバッチサイズが 大きくなり、あれもこれもと機能を追加し てしまうことがあります。 前述したSingle Piece Flowに近いものがあ りますが、これは1つのサイクルで検証したいことを 1 つだけにして、最 低限の検証ができるだけの MVPをつくることをいいます。
28. Single Piece Flow - Single Piece Flow（1つのサイクルで1つの仮説） - 仮説の1つ流しを意識する - 2つの改善を同時に満たすような施策だとバッチサイ ズ（1つの処理で 回す量）として大きすぎる - 結果として、どの施策が効果があったのかの依存関係が見えづらくな る。 - 対象KPIが違うのであれば、ある程度は許容
29. BMLループは、逆回転のプロセスで考える - 計画ループ - 1. 学習からの仮説がつくられる（ Idea） - 2. 仮説から何を学びたいか、確証を得たいか（ →Learn） - 3. そのために必要なデータの形は何か（ →Data） - 4. どんな指標をどのように計測するか（ →Measure） - 5. プロダクトの形は何か（ →Product） - 6. どのようにつくるか（ →Build） - 実行ループ - 1. 構築する（Build→） - 2. MVPができる（Product→） - 3. 指標に基づいたログデータが出力される（ Measure→） - 4. データが可視化される（ Data→） - 5. データから学習する（ Learn→） - 6. 次の仮説を考える（ Idea→）
30. 番外編 商品レビューをグロースさせてみよう！
31. 事業改善までの流れ 1. 事業モデルの理解から始めよう …… まずはプロダクトの特性を理解していきます 2. KPIモデルから勝ち筋を見つけよう …… KPIツリーを中心とした数値モデルから課題分析をします 3. A/Bテストで「価値」を測ろう ……プロダクトの価値を知る 4. 予算を確保しよう……戦略と撤退ラインを定義する 5. ユーザーの声を聞こう …… 定量的なデータだけではなく、ユーザーの声を聞いていきましょう 6. さぁ、改善を回していこう …… 実際にプロダクトをグロースさせるための施策を実行していきます
32. 事業モデルの理解から始めよう - 情報の流れを分解する（レビューを見る） 1. ユーザーは検索エンジンや広告などを経て、サイトにアクセスする 2. サービス動線を経由して、各コンテンツの商品ページを表示する 3. 商品ページの末端にある「レビューコメント」や「レビュー評価」を見る 4. 欲しいと思った商品をカートに入れる 5. または、カートには入れずに「今すぐ購入」の場合もある 6. カートに入れたものを購入する 7. 未会員（guest）の場合は会員登録へ 8. 会員の場合（member）はそのまま決済へ
33. 事業モデルの理解から始めよう - 情報の流れを分解する（レビューを書く） 1. レビューを書く 2. 運営のメンバーが、公開しても問題ないレビューかどうかを確認する 3. 問題なければ承認。問題があれば非公開とする 4. 商品ページに商品レビューを追加する
34. 数値モデルへと落とし込もう
35. KPIモデルから勝ち筋を見つけよう！
36. A/Bテストで「価値」を測ろう - 例えば... - 商品ページにおいて商品レビューの有無で売上に影響があるかを探りま す。 - 例えば、現状で1件以上のレビューがついている商品があったとして、 A パターン群が商品レビュー枠に訪問した際には 1件以上の商品レビュー を通常通り表示します。 - Bパターン群が商品レビュー枠に訪問した際には商品レビューを意図的 に減らした状態（0件）で表示する - A/Bテストを行い、当該商品の CVR（経由売上）を比較するというテストを してみます。 - サンプルの基準としては、評価が 1件以上かつ高評価のもの（星 4以上） とします。比重としては、サ ンプル数からの比重は 20%で4日間行えば、 必要なサンプル数が集まると計算しました。
37. A/Bテストで「価値」を測ろう - A / Aテストをきちんと実施する - まずは、実施前に効果測定用のダッシュボードを作成しましょう。 - - そして必ず、A/Bテストの前には、きちんと AAテストをして、データに差異 がないことを確認しましょう。
38. A/Bテストで「価値」を測ろう - A/Bテストを実施する - AAテストで問題なければ、数日間かけて A/Bテストを実施していきます。 - A/Bテストの結果としてB パターン（商品レビュー枠を 0件）にした場合、 CVR（経由売上）が平均して 45%（Aパターン）から20%（B パターン）へ大 幅に下がり、25%の差異が生まれたことがわかりました。 - 売上インパクトが1% = 10万円であれば、4日間で250万円のマイナスに なることがわかりました。 1日にすれば約63万円です。 - 比重を20%→100%のユーザーで単純計算すると 1日で約315万円の影 響があることがわかります。 - これで、ユーザーの購買に影響与えるという「ファクト」がわかりました。
39. A/Bテストで「価値」を測ろう - 価値の仮説（SAM） - A/Bテストの結果として、同じ商品でも商品レビューの有無で、その商品 の売上に影響があることは わかりました。 - 数値としては、商品レビューが 1件以上あるものと0件のものを比較する と、1日で約315万円の影響があります。 - 一方、全体の商品数に対して商品に付いているレビューは全体の 2割だ とします。つ まり、8割の商品には商品レビューは付いていない状態とい うことになります。 - レビューの割合が2割から4割になれば売上貢献が約 315万円→約630 万円になるのではなりそうという仮説 ※4割は目標値
40. 予算を確保しよう - 戦略と撤退ライン - 予算を確保していくためには、戦略（何がしたいか）と撤退ライン（何が失敗か）を決める - 「商品レビューがある割合を 2割から 4割に増やしたときに売上貢献が増加するかどうか」という仮説を検証していきましょう。 - 例えば、「商品レビューが 0件の商品にレビューを投稿したら 100ポイントゲット！」というキャンペー ンを行いたいとします。 - 総商品数が10万コンテンツだったとして、 +2割（計4割）となると最大20,000件のコンテンツに対 して、商品レビューを書いてもらうことになります。 - 例えば、キャンペーンを実施して、商品レビューを投稿 してくれたユーザーに対して 100ポイントを配布するとします。 - つまり、100pt × 20,000件 = 2,000,000円（200万円）の予算を確保する必要があります。 モニタリング指標としては、商品レビュー経由の売上（ CVR） が仮説どおりに向上したか、そしてそれが配布ポイント額よりも上回っているかどうかになります。
41. 予算を確保しよう - KPIモニタリングと予測 - 仮説を検証するためには、どの KPIをどのぐらい上げれば良いかを確認 します。 - KGIは、現状の約315万円から目標である約 630万円とします。 - 重要なKPIであるレビュー投稿数は、 20,000件 → 40,000件 - 平均投稿数を2件 → 2.5件、レビュアー数を10,000人 → 16,000人へ増 加させれば予測 としてKGIの目標が達成できるのではないか
42. 予算を確保しよう - 撤退ライン - 施策の撤退ラインも同時に考えていきましょう。 - 仮説どおりに4割になったときに売上貢 献が約315万円→ 約630万円の ように倍にならなかったとしても、少なくとも、配布ポイント額 （20,000,000円）よりも商品レビュー経由の売上が向上していれば、施 策としては成功となるため、 継続的な改善を繰り返しながら進んでいく選 択肢も取れます。 - もちろん、仮説通りに KGI（経由売上）が向上しているのであれば、追加 予算を確保して、さらに発展させ るという形で合意を得ます。 - しかし、配布ポイント額よりも商品レビュー経由の売上が下回った場合に は施策自体は撤退とします。 なぜなら、この施策を継続すればするほ ど、赤字になるためです。その場合は一旦この施策をやめて 別の戦略を 立てていくのが良いでしょう。
43. ユーザーの声を聞こう - ユーザーからの要望を VOCで可視化する - 一方、プロダクト改善には定量的なデータだけではなく定性的なデータも 必要です。 - 定量的なデータ（ログデータ）は、ユーザーが行動した結果をデータとして 蓄積することで得られます。 - 一方、定性的なデータ（リサーチデータ）は、まだユーザーの中に眠って いるニーズなどを探ってい く必要があります。手段としてはユーザーイン タビューやアンケート、ユーザー要望の問い合わせなどがあります。 - 今回は、既にデータとして蓄積されている VOC（Voice or Customer）の データストアから、データ を取得して過去数ヵ月のユーザーからの要望 やクレームを分析していきましょう。
44. さぁ、改善していこう - あとはひたすらに改善を回していく - あとは、ひたすらに失敗を許容しながら、改善を回していくだけです。 - 事業モデル → KPIツリーから課題となる KPIを抽出して、そこに対する施 策を実施していきます。 - KPIの目標値を立てて、仮説の予測値を立てながら改善を回し、実測値 との差分を学習しながら、埋めていきます。
45. まとめ - 事業を数値的理解を行うことの重要性 - ミクロとマクロをログデータで表現する - 計画に時間をかけずに、データで失敗をコントロールする - 仮説検証の繰り返しで、事業の不確実性を下げていく
46. ご清聴ありがとうございました QAへ