1時間で徹底解説！『DMM.comを支えるデータ駆動戦略』出版記念イベント！ / Data- Strategy

by Masato Ishigaki / 石垣雅人

Slide 1

Slide 1 text

を支えるデータ駆動戦略刊行記念 2020/11/11 19:15 ~ 20:30 [Wed] 著 : 石垣雅人 1時間で徹底解説！

Slide 2

Slide 2 text

About me Masato Ishigaki / 石垣雅人 DMM.com 総合トップ開発部部長   2015年度エンジニア新卒入社 2017年より、DMMにおける3000万のアカウント(ID)、認証(Auth) のバックエンド周りのプロダクトオーナーを経て、 2018年7月にリードナーチャリング領域を強化するチームの立ち上げを行う。 2020年より、DMMの総合トップなどを管轄する総合トップ開発部の部長を務める。現在は『DMM PointClub』アプリやモバイルSDKのプロダクトオーナーにも従事 @i35_267 i35-267

Slide 3

Slide 3 text

　監修 : 松本勇気さん（DMM.com CTO）への謝辞 https://note.com/y_matsuwitter/m/mdc584510ef76

Slide 4

Slide 4 text

Outline / Structure of the Talk ・書籍のChapterをベースにお話していきます・書籍の中で述べられなかった部分に言及・読んでいる人には復習に。まだの方には興味を持つきっかけに。・書籍内で使っている図を使っていきます

Slide 5

Slide 5 text

はじめにキーワード「不確実性」

Slide 6

Slide 6 text

はじめにキーワード「武器」キーワード「アジャイル」キーワード「データ駆動」

Slide 7

Slide 7 text

はじめにキーワード「データ」キーワード「普通の人」

Slide 8

Slide 8 text

Chapter構成登場する要素は、主に 4つ・事業（サービス）・ユーザー・組織・データ

Slide 9

Slide 9 text

Chapter構成登場する要素は、主に 4つ・事業・ユーザー・組織・データ基盤現場が不確実性と戦うにはこの「4つ」を組み合わせたプロセスの構築が必要同時にこの4つがあらゆる不確実性を生み出し混乱させている事実もある特に「データ」を正しく扱い、武器として戦っていくデータは魔法ではない　

Slide 10

Slide 10 text

Part 1-1 事業を科学的アプローチで捉え、定義する

Slide 11

Slide 11 text

　データ駆動戦略の全体像を理解する

Slide 12

Slide 12 text

- まずは対象をすることが大事 - なんとなく利益が出ているのは駄目 - きちんと事業を計測し、数値モデルとして捉える。 - システム理論的な事業理解が必要 - あらゆる対象を「システム」として定義する - システムの3つの特徴〜システムが形を成す過程〜 - 入出力からシステムは作られる - システムの階層性 - ミクロからマクロまでをズームイン / ズームアウト - 事業を「システム」として定義する - 何をインプットとするか - インプットに対してどのような処理が行われているか - 何をアウトプットしているか　事業→システム理論で理解する

Slide 13

Slide 13 text

事業の可観測性（Observability）を高める - 事業モデルを定量的な数値モデルで捉える - ソースコードで定義する - 科学的手法を意識する - 1. 測定可能性 2. 定量性 3. 再現性 4. 統計的有意性 5. 論理的整合性 - 一連の動作をログデータでプロットする - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 事業ソフトウェア = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化

Slide 14

Slide 14 text

　事業構造をKPIで表現し、予測可能性をつくる - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が見えてくる - ということは変数に対して代入すれば出力を予測できる - 科学的な事業構造把握 = KPIツリー - プロダクトにおける一連の動作を数値モデルとして表現しただけでは事業の現状を可視化しただけで事業改善は生まれません。 - 継続的な事業改善を行うためには指標を決め、それに向かって改善を進めていく必要があある - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる - KPIツリーは事業の健康診断

Slide 15

Slide 15 text

事業の計算式が見えることで予測ができる

Slide 16

Slide 16 text

事業の計算式が見えることで予測ができる

Slide 17

Slide 17 text

操作可能な変数を把握して、事業の予測をする - KPIを用いた予測可能性を高める - KPIツリーの中で操作可能変数 = 自分たちが操作できる変数を見つけて値を代入する - Ex. - クーポン単価 - 広告予算 - 商品単価

Slide 18

Slide 18 text

予測値と目標値による事業改善の流れ - 目標値 - あとは目標値を設定してその差分を埋めていく作業に入ります - Ex. 売上KGIを1,000万円 → 2,000万円 - 予測値と実測値のズレを検知する - 施策のROIやコスト面を意識して施策を実施 - 結果と予測値が合っているかどうかを中心にモニタリング - 施策実施のプロセスは後述します

Slide 19

Slide 19 text

事業をソフトウェアで捉えると自動化ができる

Slide 20

Slide 20 text

事業をソフトウェアで捉えると自動化ができる

Slide 21

Slide 21 text

Part 1-2 仮説検証を繰り返すことで不確実性を下げていく

Slide 22

Slide 22 text

仮説 → 実験 → 学習 → 意思決定 - 不確実性とどう戦っていくか - 不確実性が高いプロダクト開発の現場では、どんな施策がユーザーに受け入れられるかはとても難しい問題 - 事業の寿命は無限にあるわけではなく、常に予算を中心としたタイムリミットを意識する必要がある - 実験しながら学習していく - "実験"をすることが大事 - 実験とは言葉のとおり「実際の経験」という意味 - ユーザーという指針を頼りにしながら、実験を繰り返し、そこから得られる結果を「データ」というファクトをもとに学習しながら、意思決定をしていく - 仮説検証のプロセスが大事

Slide 23

Slide 23 text

5つのプロセス 1. 失敗できる環境をつくり出すことで組織は加速する 2. ムダを排除して効率的な実験を行う 3. イテレーティブな改善の流れをアジャイルでつくり出す 4. 仮説検証プロセスで型をつくり、ノウハウを蓄積させる 5. 「流れ」を思考する

Slide 24

Slide 24 text

型を学び、組織を方向付ける - これらの手法は決して"成功"を保証するものではない - ある種の「型」であり、このプロセスや方法論さえ守っていれば事業が必ず成長する、といった銀の弾丸ではありません。 - プロセスや方法論は、手段であり目的ではありません。 - 「型」を何も考えずに組織へ導入すると思考停止になり導入自体が目的となりがちです。 - 例えば、開発手法 1つ取っても「アジャイル開発を導入したからうまくいくはずだ」「スクラムではこうなっているから組織もこうなるべきだ」というように混同しがちです。

Slide 25

Slide 25 text

型を学び、組織を方向付ける - 実際にはあらゆる型を組織に適用して、組織文化とマージ（併合）すると必ず差分が出てきます。 - その差分を組織としてどう馴染ませていくかが肝心なわけですが、例外が出てくると「この方法論ではダメだ」「私たちの組織には合わなかった」という結論に陥るケースを多く見られます。 - 一方、「型」というものは提唱者の思想を肉付けする形で、世の中にわかりやすく適用できるようにパッケージ化されたものです。 - つまり、作られた背景や思想の部分を理解していれば、提唱者の肉付け部分（パッケージの部分）を独自にアップデートしていく形で、組織に順応されて、新たな組織文化を更新していけるのではないかと考えています。

Slide 26

Slide 26 text

失敗できる環境をつくり出すことで組織は加速する - 失敗の恐怖。PDCAのPを重視しない - 事業をスケールさせるには、改善施策を合理的に正しい方向でどれだけ数多く実行できるかが鍵になる。 - ハードルとなっているのが、失敗への恐怖心です。誰もが思う「失敗したくない」という壁が、あらゆる改善の実施に歯止めをかけている。それが組織として存在する - = 前段階にある計画の部分に時間をかける - 失敗をコントロールする - 失敗を”なくす”のではなく、事業構造を理解した上で失敗できる範囲（予算など）を明確にし、その影響範囲の中で適切に失敗をさせるこ

Slide 27

Slide 27 text

A/Bテストによる実験 - A/Bテスト - A/Bテストとは、元の機能に変更を加える際に AパターンとBパターンを用意してテストする手法 - A/Bテストの比重と期間の考え方 - A/Bテストの比重については、統計学的な分析でサンプル数を満たす割合を見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する

Slide 28

Slide 28 text

MVPによる実験はじめからさまざまな要素を盛り込んでリリースするのではなく、狙った仮説が検証できる程度の必要最低限の機能を盛り込んだ形でスピーディーに構築し、その状態でユーザーに提供します。そこから得られるユーザーのフィードバックをもとに、仮説の正当性を確認していき、徐々に学習しながら機能を充実させていくアプローチ

Slide 29

Slide 29 text

イテレーティブな改善の流れをアジャイルでつくり出す

Slide 30

Slide 30 text

イテレーティブとインクリメントの違い ● インクリメント = 少しずつ積み上げる ● イテレーティブ = 繰り返す

Slide 31

Slide 31 text

イテレーティブとインクリメントの違いインクリメント型で自動車をつくるイテレーティブ型で自動車をつくる

Slide 32

Slide 32 text

ウォーターフォール型とアジャイル型インクリメント型で自動車をつくるイテレーティブ型で自動車をつくる

Slide 33

Slide 33 text

アジャイルはつらいもの - アジャイルはつらい - アジャイル型の開発は、小さくプロダクトをつくりながら、ある種の石橋を叩いて渡りながら、失敗をコントロールしていくプロセスです - プロセスとして理想的には良いと頭でわかっていても、実現するには難しい部分も沢山あります - - ケーキの例でも各工程に分かれて大量生産したほうがゴールも明確 - コツを掴んでいくことで個人の生産性も徐々に上がっていくでしょう。 - アジャイルは、それを大量生産ではなく小さく形にして、ユーザーのフィードバックも見ながらショートケーキの単位で変更させていくものです。トッピングがいちごではないかもしれません

Slide 34

Slide 34 text

アジャイルにおけるインクリメントの誤解と解消方法 - 「どの単位でユーザーの機能を提供するか」 - 実際の開発現場では「どの単位でユーザーの機能を提供するか」は頭を悩ませる部分です - イテレーションの中で incrementにならないようにする。 - あまり、機能を削り過ぎても、もともと提供しようとしているプロダクトの価値が見えなくなり、逆に機能を盛り込みすぎると開発に時間がかかりすぎ、市場への仮説検証が遅る - ユーザーストーリーピッングを作ろう！

Slide 35

Slide 35 text

ユーザーストーリーマッピングとは

Slide 36

Slide 36 text

ユーザーストーリーマッピングとは

Slide 37

Slide 37 text

ユーザーストーリーマッピングとは商品を検索する商品を購入する商品を検索する商品ページを見るアカウント登録・認証する支払い方法を選択する商品を購入するジャンルで検索商品名で検索価格が見える商品レビューが見えるメールアドレスで登録する SNSアカウントで登録するゲストで登録するカートに入れるクレジットカードを登録するクーポンを使う電子マネーを使う購入完了メールを送るポイントを配るカートに入れるジャンルで検索商品名で検索価格が見える商品レビューが見えるメールアドレスで登録する SNSアカウントで登録するカートに入れるクレジットカードを登録する購入完了メールを送る

Slide 38

Slide 38 text

仮説検証プロセスで実験を加速させる - 「仮説検証プロセス」 1. KPI選定 2. 仮説 3. 検証 4. 計測 - プロセスをつくるということは型をつくることに等しい - 組織の中で属人的にはならない改善の流れをつくることで成果物を安定させることができます。 - そして、そのプロセスの中で数多くの実験を繰り返すことで、組織としてノウハウが蓄積され、プロセスの精度も上がり、事業のブラックボックスも徐々に明らかになっていきます - BMLループという「型」

Slide 39

Slide 39 text

BMLループでプロセスの型を作る - BMLループのプロセス 1. Learn → Idea = 仮説を考える 2. Build → Product = どう作るか 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - Single Piece Flow（1つのサイクルで1つの仮説） - 仮説の1つ流しを意識する - 2つの改善を同時に満たすような施策だとバッチサイズ（1つの処理で回す量）として大きすぎる - 結果として、どの施策が効果があったのかの依存関係が見えづらくなる。

Slide 40

Slide 40 text

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→）

Slide 41

Slide 41 text

「流れ」を思考する流れの高速化と安定化

Slide 42

Slide 42 text

プロセスをモニタリングするストーリー WF 設計 iOS / BE 開発中結合 PO確認クローズ計測をしてボトルネックの可視化

Slide 43

Slide 43 text

Part 2-1 強固な組織体制と学習する組織

Slide 44

Slide 44 text

学習する組織とは何か - 学習する組織の必要性 - 事業や仮説検証プロセスだけでなく、組織も短いサイクルの中で学習していかなければいけない - 組織の中にいるメンバーのメンタルモデルを考える - 学習する組織とは - 目的に向けて効率的に行動するために - 集団としての意識と能力を - 継続的に高め、伸ばし続ける組織 - 能力の高い人たちが集まれば「学習する組織」になるかといえばそうではなく、その個人が集まった「集団」としての学習能力を高めていかなければいけない

Slide 45

Slide 45 text

組織を戦略的にUnlearnさせる - Unlearnとは - Unlearnとは、学習する上で必要な知識をどう積み上げていくべきかという概念 - 組織や個人によって、外からのさまざまな情報や知識をインプットしながら、それをどう適応していくか、アップデートしていくかの考え方です - 人はどうしても今までの経験値や学んできた経験の視野の中に囚われていることが多くあります - Unlearnという言葉は、直訳すると学ぶ（ Learn）の否定（un）なので「学ばない」「脱学習」といった印象を持ちますが、少しニュアンスが異なる

Slide 46

Slide 46 text

組織を戦略的にUnlearnさせる - 「知」について - 既存の知識に対して、新しい知識の「型」が相互作用する中で、知識と知識が結びつき言語化されたり、自分が普段思っている課題や不安に対しての理解が深まったりします - これは、新しい知識を入れたときに発生する不安定な「ゆらぎ」のプロセスによって生まれます。知識と知識が不安定にゆらぎながら、結びついていきます。 - プロダクト開発の現場でも「いまよりも良いやり方はないか」を常に探していく探求心をもちながら、戦略的 Unlearnすることが大事

Slide 47

Slide 47 text

アジャイルとUnlearn : 「場」をつくるアジャイル

Slide 48

Slide 48 text

戦略的Unlearn : 「型」への適応と「ゆらぎ」の場をつくることが必要

Slide 49

Slide 49 text

戦略的Unlearnの着想は、XP（エクストリーム・プログラミング） - XPのパラダイム「注意して、適応して、変更する」 - 運転というのは車を正しい方向に走らせるのではなく、常に注意を払いながら、こちらに行ったら少し戻して、あちらに走らせてしまったらまたこちらに戻して、と「小さい軌道修正」をしていくものです - ソフトウェア開発の周りにあるものは常に変化を続けています。事業環境も組織にいる人も、つくるべきものの要件の変化やソフトウェア技術の変化などが存在する中で、私たちが考えるべきことは、周辺の変化ではなく、その変化にどのように対応していくかでしょう - ソフトウェア開発における変化への対応で大事なことは、新しいプラクティスを身軽に試せる環境です。また、常に新しい変化を柔軟に取り入れ、自分たちを変化させる中でフィードバックをもらい、積極的に改善を受け入れることが重要。

Slide 50

Slide 50 text

戦略的Unlearnの着想は、XP（エクストリーム・プログラミング） - 継続的な改善とは何か - 継続的な改善と聞くと、絶え間なく連続的に改善を続けていると思われがちですが、そうではありません。継続的に注意して、適応して、そこからフィードバックをもらい、積極的に改善を受け入れる準備体制ができていることが継続的な改善 - XPの理論構成には、「価値」「原則」「プラクティス」の3つがあります。特にプラクティスの部分についてはあらゆる問題の改善アプローチが用意されています。 - その理由は、開発チームが継続的改善のプロセスをやめさせないことだと考えられます。何もない状態で、自ら改善策やアプローチ方法を見つけ出すことは難しく時間がかかります。そんなときは、 XPで用意されているプラクティスをその価値を理解した上で、自分たちの問題点と照らし合わせてみて適応し、変更してみましょう。そこから出てきたフィードバックをもとに学習していけば良いのです

Slide 51

Slide 51 text

戦略的Unlearnの着想は、XP（エクストリーム・プログラミング）価値 - コミュニケーション（ Communication） - シンプリティ（Simplity） - フィードバック（Feedback） - 勇気（Courage） - リスペクト（Respect）原則 - 人間性（Humanity） : 機会（Opportunity） - 経済性（Economics） : 冗長性（Redundancy） - 相互利益（Mutual Beneﬁt） : 失敗（Failure） - 自己相似性（Self-Similarity） : 品質（Quality） - 改善（Improvement） : ベイビーステップ（Baby Steps） - 多様性（Diversity） : 責任の引き受け（Accepted Responsibility） - 振り返り（Reﬂection） : 流れ（Flow）プラクティス - 共同のプラクティス - 開発のプラクティス - 管理のプラクティス - 顧客のプラクティスチームが継続的改善が行えるように観点が提供されている。一方、これらは銀の弾丸ではない。

Slide 52

Slide 52 text

戦略的Unlearn : 「型」への適応と「ゆらぎ」の場をつくることが必要既存のプラクティスを導入することで組織内に「ゆらぎ」をつくります。それから、既存の知と新しい刺激としてのプラクティスをうまく調和しながら、、既存の知と新しい知の「差分」を出していきます。そのときに大事なのは、組織が「知」というのものをどうつくり出していくかその「流れ」を見ていくことで、型からチームにあった形で差分をつくり出せるでしょう。

Slide 53

Slide 53 text

暗黙知から差分を出する - 暗黙知と形式知 - 私たちが「知る」という行為には大きく分けて、暗黙知と形式知があります。 - 「暗黙知」とは、一言でいうと言語化されていない感覚的で身体的な知識のことです。経験知ともいい、経験として体に馴染んでいるが言葉として説明できない知識のことです。この暗黙知には、大きく分けて2つあります。メンタルモデルを代表とする「認知スキル」と、ノウハウや技巧、熟練といった「身体スキル」 - 一方、「形式知」とは、言語化、理論化されている知識のことです。感覚的な知識を形式化して全員にわかるような形で知識を共有することができるようになります。

Slide 54

Slide 54 text

暗黙知から差分を出する - 「身体スキル」 - 例えば自動車の乗り方について - 自動車の乗り方をいくら座学で学んだとしても、いきなり運転できる人は多くないでしょう。 - 実際に自動車に乗り、ハンドルを握り、アクセスを踏んでみる、などの体験を通じて体に染み込ませる - アクセルやクラッチ、ハンドルを絶妙な感覚で操作しながら運転する感覚はとても論理的に説明できません。

Slide 55

Slide 55 text

暗黙知から差分を出する - 「認知スキル」 - 個人の根幹にあるメンタルモデル - 人はさまざまな意思決定をするときに過去の体験や経験をもとにしたメンタルモデルをもって行動する - 例えば、新卒のときに大きな障害を起こしてしまった。 - そうするとベテランになっても障害に対する恐怖から、厳重に仕組みを用意する傾向がある

Slide 56

Slide 56 text

暗黙知から差分を出する - SECIモデル（セキモデル） - SECIモデルとは、暗黙知と形式知の 2つの知識形態が、相互作用して変換を繰り返すことで「知識変換」が行われ、新しい知識が創造され拡大するという集合知モデル ● 共同化（Socialization）（暗黙知→形式知） ● 表出化（Externalization）（暗黙知→形式知） ● 凍結化（Combination）（形式知→形式知） ● 内面化（Internalization）（形式知→暗黙知）

Slide 57

Slide 57 text

暗黙知から差分を出する - SECIモデルと「ゆらぎ」 - SECIモデルをもとに組織が学習するプロセスを設計する - アジャイルと暗黙知 - モブプログラミングで暗黙知を共有する

Slide 58

Slide 58 text

戦略的Unlearn : 「型」への適応と「ゆらぎ」の場をつくることが必要

Slide 59

Slide 59 text

パターン化して広げる - パターンを「作る」 - パターン化とは、差分から生まれたその組織の独自プロセスを形式知として新たにつくり出すことです。 - どんな「状況」のときに - どんな「問題」が発生しやすい - そんなときには、この「解決」を適用すれば改善するかもしれない - この「状況（Context）」「問題（Problem）」「解説（Solution）」の3 つ記載した上で、「名前（パターン）」をつけていくことで、 1つのパターンができあがります。

Slide 60

Slide 60 text

パターン化して広げる - パターンを「広げる」 - パターンをつくったのならば、その型をつくったチームでブラッシュアップしていくのはもちろん、ほかのチーム、組織にも広げていきましょう。 - 各々がパターンをつくっていき、それを型としてあらゆるチームや組織に落とし込み、「ゆらぎ」をつくりながら暗黙知へ落とし込んでいきます。 - そして、それぞれの「状況」「問題」にあったパターンとしてアップデートしていき、それを違うチームがまた参照していくというサイクルを回していくことで、強い組織にしていきます。

Slide 61

Slide 61 text

統治分割でパターンを広めるトップダウンではなく、ボトムアップで広げる。根幹にあるのは「暗黙知」の重要性です。トップダウンでプロセスを標準化して、強制的にパターンを導入させるのは危険。それぞれのチームが、保有しているプロダクトやチームメンバーによって生まれる「ゆらぎ」による暗黙知を大切にして、それぞれに最適化したプロセスをつくる必要があります。

Slide 62

Slide 62 text

組織文化は個の影響度と多数決で決まる

Slide 63

Slide 63 text

Part 2-2 組織構造の力学を操作する

Slide 64

Slide 64 text

組織構造から発生する力学を操作する

Slide 65

Slide 65 text

自己組織化されたプロダクトチーム

Slide 66

Slide 66 text

データアナリストとの事業改善プロセス

Slide 67

Slide 67 text

組織のサイロ化と向き合う - サイロ化 - ドメイン単位で縦割りの組織がある中で、問題になるのは「サイロ化」です - 良くも悪くもプロダクトチームで完結するため、横との連携が少なくなる組織設計となってしまうことです - 組織文化も閉じられた状態になり、良い情報や有益な情報が横に伝わりにくい状態になります。 - サイロ化という文脈では、以下の 2つを防ぐように対策します。 - 事業改善ノウハウのサイロ化を防ぐ - 技術領域のサイロ化を防ぐ

Slide 68

Slide 68 text

事業改善ノウハウのサイロ化を防ぐ - レポーティング - DMM.comでは、週次レポート / 月次レポートという形で各事業単位やチーム単位でレポートを書くことで、誰でも他事業の施策状況などを参照できるようにしています - 本来、サイロ化という文脈よりも、正しく組織階層に沿ったレポーティングとして機能し、事業の健康状態を理解することに活かされていることが多いのですが、 Wikiとして公開されているため、誰でも改善の知見ノウハウやその組織文化に触れられます - - ここに書かれている施策や改善について詳しく担当者にヒヤリングすることはよくある光景で

Slide 69

Slide 69 text

技術領域のサイロ化を防ぐ

Slide 70

Slide 70 text

Part 3 データの民主化

Slide 71

Slide 71 text

データパイプラインの構築 - データを集約するのが第一歩目 - データ駆動戦略に最も必要なのは、データという資産です。そのデータを使い、組織の意思決定に役立てるには、データを整理整頓して管理しなければなりません。 - 第一歩目として膨大なデータを集約しなければいけません。そして、そのデータを組織の意思決定の材料とするには、私たちが見てわかりやすい形でデータが参照できる必要があります。 - また、データは資産なので盗まれてもいけません。

Slide 72

Slide 72 text

データパイプラインの構築 - データパイプライン - データレイク（Data Lake）・・データの湖 - データウェアハウス（ Data Warehouse）・・データの管理倉庫 - データマート（Data Mart）・・価値があるデータ - データガバナンス - GDPR（一般データ保護規則）の策定 - 権限や役割、個人情報の扱いで - 個人が特定できる情報は入れない

Slide 73

Slide 73 text

データの民主化 - ダッシュボードをつくろう！ - KPIダッシュボード - 事業モデルの指標から導き出された KPIツリーをもとにつくっていきます。 - 施策ベースのダッシュボード - 日々事業を伸ばすために実施している施策ごとのダッシュボード。A/Bテストの結果など - 経営向けダッシュボード - 各事業単位のダッシュボードではなく、事業全体を俯瞰して見れるようなマクロの財務諸表ダッシュボード

Slide 74

Slide 74 text

毎日ダッシュボードを見る仕組みをつくる - 仕組み作り - KPIマネジメントと同じで、 BIツールのダッシュボードも一度つくって終わりではなく運用が必要です。事業環境は刻一刻と変化していくため、できれば、毎日チーム全員で見る習慣をつけることが大事です - ● 前日のDAUはどうだったか - ● 前日の売上はどうだったか - ● UI改善施策のA/Bテストの結果はどうか - ● 追加した機能は使われているか - 毎朝、前日分のデータをチャットツールへ通知 - デイリースクラムで毎日確認

Slide 75

Slide 75 text

まとめ - Chapter8 - 今述べてきた流れをロールプレイ的に網羅した形で書籍のなかで述べています - ぜひ、興味あれば書籍でご覧ください！

Slide 76

Slide 76 text

まとめ Part 1-1 事業を科学的アプローチで捉え、定義する Part 1-2 仮説検証を繰り返すことで不確実性を下げていく Part 2-1 強固な組織体制と学習する組織 Part 2-2 組織構造の力学を操作する Part 3 データの民主化

Slide 77

Slide 77 text

ご清聴ありがとうございました ask the speakerへ