Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データ駆動☓リーン☓スクラムを組織文化に浸透させ、プロダクトをグロースさせる / Data-Driven_Lean_Scrum to Product Growth

データ駆動☓リーン☓スクラムを組織文化に浸透させ、プロダクトをグロースさせる / Data-Driven_Lean_Scrum to Product Growth

2019/06/23 「DevLOVE X」登壇資料

Transcript

  1. 石垣雅人 - DMM.com LLC 2019/06/23 「DevLOVE X」 DevLOVE X 組織文化に浸透させ、

    プロダクトをグロースさせる データ駆動 x リーン x スクラムを Product Growth 100 1
  2. © DMM.com 2 About me 石垣 雅人 Masato Ishigaki i35-267

    @i35_267 i35-267 Product Owner at DMM.com
 プラットフォーム事業本部 2015年度 新卒入社 Role : PO, PM, EM, Dev, Mk スタートアップ 1社 アドバイザー
  3. © DMM.com 3 テーマ / ゴール About DMM.com プロダクト開発において正解はない。 「正解がないもの」を作るにはどうしたら良いか。

    さらにプロダクトをグロースさせるには。 Photo by people building structure during daytime on Unsplash
  4. © DMM.com 4 Agenda About DMM.com プロダクトをグロースさせるには 「武器」を手にするまでのジャーニー 「データ駆動」という武器 強固な組織構造がもたらす「力学」

    最後に
  5. © DMM.com 5 Agenda About DMM.com プロダクトをグロースさせるには 「武器」を手にするまでのジャーニー 「データ駆動」という武器 強固な組織構造がもたらす「力学」

    最後に
  6. © DMM.com 6 1→100 0→1

  7. © DMM.com 7 0

  8. © DMM.com 8 Product Build 1 0 User

  9. © DMM.com 9 ... 10... 1 Product Growth User

  10. © DMM.com 10 プロダクト開発の 「不確実性」 とどう戦うか

  11. © DMM.com 11 1→100 0→1

  12. © DMM.com 12 日々、自問自答している 「どうやったら沢山のユーザーへ」 「そもそも何を作るべきか」 「どうやって作るべきか」

  13. © DMM.com 13 正解はない 銀の弾丸もない

  14. © DMM.com 14 どんな武器をもって 戦っていくか

  15. © DMM.com 15 Agenda About DMM.com プロダクトをグロースさせるには 「武器」を手にするまでのジャーニー 「データ駆動」という武器 強固な組織構造がもたらす「力学」

    最後に
  16. © DMM.com 16 「不確実性」 を下げることがエンジニアリングの本質

  17. © DMM.com 17 Agile Lean Startup 確実性 不確実性 Data-Driven 構造の力学

  18. © DMM.com 18 Agile - Scrum プロダクト開発において「確実」はない。 失敗することが前提。

  19. © DMM.com 19 ... Build Feedback 10... 1

  20. © DMM.com 20 失敗することが前提。 = Agility

  21. © DMM.com 21 ... Agility Build Feedback 10... 1

  22. © DMM.com 22 ... Build Feedback Sprint # 累積 featureC

    featureB featureA MVP #1...
  23. © DMM.com 23 Agility = Build & Feedback Team +

    Architecture
  24. © DMM.com 24 Agility = Build & Feedback Team +

    Architecture
  25. © DMM.com Team 25

  26. © DMM.com Team 集合知によるケイパビリティの向上 26

  27. © DMM.com スクラムの原典 野中郁次郎・竹内弘高の論文 「The New New Product Development Games」

    (1986年) NASAと日本の製品開発プロセスを比較して論じた。 基にジェフ・サザーランドが「スクラム」を提唱 27
  28. © DMM.com 28

  29. © DMM.com このようなチームを 「スクラム」と名付けた 29

  30. © DMM.com TypeCのようなチームで重要な観点として “Unlearn” = 学びほぐし 「Agile x Unlearn」 1.

    不安定な状態を保つ
 2. 自ら組織化する
 3. 開発フェーズを重複させる
 4. 「マルチ学習」
 5. 柔らかなマネジメント
 6. 学びを組織で共有する

  31. © DMM.com スクラムの原典 “Unlearn” 一度学んだものをほぐして再構築する 人間は、自分の経験してきたもの、学んできたものの範囲でしか、物事を考えることができない 新しい経験 新しい経験 “Unlearn”

  32. © DMM.com Team ケイパビリティー 年数 32

  33. © DMM.com Team ケイパビリティー 年数 成長度の塊 成長度の鈍化 戦略的に “Unlearn”する

  34. © DMM.com Team ケイパビリティー 年数 成長度の塊 成長度の鈍化 何を “Unlearn”する

  35. © DMM.com 35 Photo by people Ben White on Unsplash

    「知」も積み重ねると 成長度は鈍化する
  36. © DMM.com 36 Photo by people Ben White on Unsplash

    「知」を”Unlearn”させる
  37. © DMM.com 37 Photo by people Ben White on Unsplash

    組織における「知」の流れを理解 知識創造論「SECIモデル」
  38. 暗黙知
 暗黙知
 暗黙知
 形式知
 形式知
 形式知
 形式知
 暗黙知
 表出化
 内面化


    連結化
 i i g i i i i i i g g g i g o E E E E 共同化
 i = 個人、g = グループ、o=組織、E=環境
  39. 表出化
 内面化
 連結化
 i i g i i i i

    i i g g g i g o E E E E 共同化
 i = 個人、g = グループ、o=組織、E=環境 暗黙知
 暗黙知
 暗黙知
 形式知
 形式知
 形式知
 暗黙知
 形式知
 共同化
 表出化
 連結化
 内面化

  40. 暗黙知
 暗黙知
 暗黙知
 形式知
 形式知
 形式知
 形式知
 暗黙知
 共同化
 表出化


    内面化
 連結化
 i i g i i i i i i g g g i g o E E E E SECIモデル SECIモデルを高速で回すことが 改善が回っている状態で最強。 組織のケイパビリティーを上げる
  41. 暗黙知
 暗黙知
 暗黙知
 形式知
 形式知
 形式知
 形式知
 暗黙知
 共同化
 表出化


    内面化
 連結化
 i i g i i i i i i g g g i g o E E E E SECIモデル 戦略的に “Unlearn”する プロセスを注入する
  42. 暗黙知
 暗黙知
 暗黙知
 形式知
 形式知
 形式知
 形式知
 暗黙知
 表出化
 内面化


    連結化
 i i g i i i i i i g g g i g o E E E E 共同化
 i = 個人、g = グループ、o=組織、E=環境 重要視するところ 42
  43. 暗黙知
 暗黙知
 暗黙知
 形式知
 形式知
 形式知
 形式知
 暗黙知
 表出化
 内面化


    連結化
 i i g i i i i i i g g g i g o E E E E SECIモデル 共同化
 i = 個人、g = グループ、o=組織、E=環境 “Case Study”
  44. t 1week 1week Unlearn Unlearn Learn スプリント スプリント スプリント Learn

    Learn スクラム MTG スクラム MTG 44
  45. YWT レトルスペクティブ 「Fun/Done/Learn」 「闇鍋」

  46. 最近、”Unlearn”して ”スプリントレビュー”をやめました。

  47. ”モブプロ”を文化として実行 「知」の”Learn”と”Unlearn”を交互に変換する 47

  48. © DMM.com 48 Agile = How > What > Why

  49. © DMM.com 49 ... Build Feedback Whyを考える

  50. © DMM.com 50 Agile = How Why, What = ?

  51. © DMM.com 51 Lean Startup 仮説からの学習のサイクル IDEA BUILD PRODUCT MEASURE

    DATA LEARN
  52. © DMM.com 52 スプリントバックログ インクリメント 開発→リリース 効果検証 プロダクトバックログ 直感に頼る仮説

  53. © DMM.com 53 スプリントバックログ インクリメント 開発→リリース 効果検証 直感に頼る仮説は、量産されやすい。 プロダクトバックログアイテムが肥大化して 開発者を圧迫する。

    スーパー経営者だったらそれでも良いかもしれない。 でも私たちは、普通のエンジニアだということを忘れてはい けない。 プロダクトバックログ 直感に頼る仮説
  54. © DMM.com 54 IDEA BUILD PRODUCT MEASURE DATA LEARN BMLループ

  55. © DMM.com 55 IDEA BUILD PRODUCT MEASURE DATA LEARN

  56. © DMM.com 56 IDEA BUILD PRODUCT MEASURE DATA LEARN どう作るか

    ビッグデータ基盤へ データストリーム データの可視化 どう学習するか 効果的な施策立案 何を作るか 顧客開発
  57. © DMM.com 57 スプリントバックログ インクリメント 開発→リリース 効果検証 プロダクトバックログ 仮説に妥当性を持たせる 仮説立案

    A/Bテスト,etc... A B
  58. © DMM.com 58 スプリントバックログ インクリメント 開発→リリース 効果検証 プロダクトバックログ 仮説に妥当性を持たせる 仮説立案

    A/Bテスト,etc... A B プロダクトバックログを減らして 開発しなくていい機能を減らす。 10機能 → 3機能 開発者の負荷軽減
  59. © DMM.com 施策 : ヒット率 40% 59 ... 10... 1

    施策A 施策B 施策C ◎ △ ☓ 施策数 結果
  60. © DMM.com 60 確かに 「やるべきでないこと」はわかった。 「やるべきこと」の精度をもっと高めたい

  61. © DMM.com 61 現在の最善だと思っているアプローチ 「データ駆動」

  62. © DMM.com 62 成功した施策を 「データ分析」をもとに 反復可能・再現可能 にする 施策 A 施策

    A-v1 施策 A-v2
  63. © DMM.com 63 1→10… 持続可能なビジネスを育てる

  64. © DMM.com 64 10% 40% 40% 10% t Growth Early

    Phase Growth Phase HyperGrowth Phase Mature Phase S字カーブ 原文: Data-Informed Product Building (Sequoia Capital Data Science Team)
  65. © DMM.com 65 t Second Functions Third Functions Fourth Functions

    Fifth Functions Growth First Function 原文: Data-Informed Product Building (Sequoia Capital Data Science Team) S字カーブの 連続
  66. © DMM.com Summary 66 t Second Functions Third Functions Fourth

    Functions Fifth Functions Growth First Function 原文: Data-Informed Product Building (Sequoia Capital Data Science Team) S字カーブの連続 Product Growth = Learning from Prev-Functions
  67. © DMM.com 施策 : ヒット率 80% 67 ... 10... 0

    施策A 施策B 施策C ◎ ◯ ◎ 施策数 結果
  68. © DMM.com 68 Agile Lean Startup 確実性 不確実性 Data-Driven 構造の力学

  69. © DMM.com 69 Agenda About DMM.com プロダクトをグロースさせるには 「武器」を手にするまでのジャーニー 「データ駆動」という武器 強固な組織構造がもたらす「力学」

    最後に
  70. © DMM.com 70 データが「駆動」するとは? 「データ」を見ることで次の行動につながること KPI

  71. © DMM.com 71 データが「駆動」するとは? 「データ」を見ることで次の行動につながること プロダクト戦略(KPI)を作っていく

  72. © DMM.com 72 「データ」 ユーザーの声が一番反映されるファクター ユーザーも自身にほしいものはわからない しかし、ときにユーザーの感覚を超えて無意識な行動が集約する

  73. © DMM.com 73 「データ分析」及び「予測モデル」を作ることで プロダクトの少し先の未来を予測可能にする

  74. © DMM.com 74 「データ」に基づいて意思決定 1つのプロダクトの仮説から経営的判断まで

  75. © DMM.com 75 「論点」 「データ」or「直感」 について

  76. © DMM.com 76 論点 「データ」or「直感」 について A. そもそも考えていく フェーズが違う

  77. © DMM.com 77 Product Build 1 0 「イノベーション」 「直感・経験」 「デザイン思考」

  78. © DMM.com 78 Product Growth 10.. 1 「持続可能なビジネス」 「反復可能な施策」 「データ駆動」

  79. © DMM.com 79 Data Data-Driven 意思決定 意思決定 Data Data-informed

  80. © DMM.com 80 1. プロダクトの状態を可視化できる。 2. 仮説/施策を作り、売上に貢献できる 3. 意思決定を最速化できる。 4.

    意思決定を定量的に共有できる。 5. 未来を予測して戦略が作れる。
  81. © DMM.com 81 チーム データ駆動 リーン スクラム 組織構造

  82. © DMM.com 82 Agenda About DMM.com プロダクトをグロースさせるには 「武器」を手にするまでのジャーニー 「データ駆動」という武器 強固な組織構造がもたらす「力学」

    最後に
  83. © DMM.com 83 「データ駆動」= 組織全体

  84. © DMM.com 84 3大要素 データ = ビックデータ基盤 構造の力学 = 縦割りの構造

    Agility = データによって学ぶ回数
  85. © DMM.com 85 3大要素 データ = ビックデータ基盤 構造の力学 = 縦割りの構造

    Agility = データによって学ぶ回数
  86. © DMM.com 86 KPI 相関指標 先行指標 SQL、ML ServiceA ServiceB Tracking

    User Stream Stream BigData
  87. © DMM.com 87 3大要素 データ = ビックデータ基盤 構造の力学 = 縦割りの構造

    Agility = データによって学ぶ回数
  88. © DMM.com 88 PO SM Dev PO SM Dev PO

    SM Dev SRE Service B PO SM Dev PO SM Dev Service A Team ドメインごとに自己組織化
  89. © DMM.com 89 PO SM Dev SRE Service B PO

    SM Dev PO SM Dev Service A アーキテクチャとして Microservicesを採用 コンウェイの法則 アーキテクチャーは、 組織構造を反映させたものになる。 アーキテクチャと組織構造の相関関係 PO SM Dev PO SM Dev Team
  90. © DMM.com 90 PO SM Dev PO SM Dev PO

    SM Dev SRE Service B PO SM Dev PO SM Dev Service A Team 「逆コンウェイの法則」 最適なアーキテクチャーにあわせて組織デザインを設計する。 コンウェイの法則 アーキテクチャーは、組織構造を反映させたものになる。 思考の流れ
  91. © DMM.com 91 PO SM Dev SRE Service B PO

    SM Dev PO SM Dev Service A 「意思決定」の速さ 「意思決定」のスムーズさ 「Agility」 = 施策実施権限 PO SM Dev PO SM Dev Team 構造によって発生する力学
  92. © DMM.com 92 PO PO PO Service B PO PO

    Service A アンチパターン SM Front-end Engineer Back-end Engineer SM
  93. © DMM.com 93 PO PO PO Service B PO PO

    Service A アンチパターン SM Front-end Engineer Back-end Engineer SM ・依存関係が激しい ・リリースするのに調整が必要 ・エンジニアがプロダクトに主体性を持てない ・ビジネス部門と開発部門が分かれているとありがち
  94. © DMM.com 94 PO SM Dev PO SM Dev PO

    SM Dev SRE Service B PO SM Dev PO SM Dev Service A Build & Feedback
  95. © DMM.com 95 Agenda About DMM.com プロダクトをグロースさせるには 「武器」を手にするまでのジャーニー 「データ駆動」という武器 強固な組織構造がもたらす「力学」

    最後に
  96. © DMM.com 96 テーマ / ゴール About DMM.com ・0→1、1→100のフェーズの違い ・プロダクトグロースには「データ駆動」という武器

    ・強固な組織構造による「力学」が必要 Photo by people building structure during daytime on Unsplash
  97. © DMM.com 97 ご清聴ありがとうございました。