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

2020/11/11 『DMM.comを支えるデータ駆動戦略』出版記念イベント！【オンライン】
https://dmm.connpass.com/event/193716/

Transcript

1. を支えるデータ駆動戦略 刊行記念 2020/11/11 19:15 ~ 20:30 [Wed] 著 : 石垣 雅人 1時間で徹底解説！
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 CTO）への謝辞 https://note.com/y_matsuwitter/m/mdc584510ef76
4. Outline / Structure of the Talk ・書籍のChapterをベースにお話していきます ・書籍の中で述べられなかった部分に言及 ・読んでいる人には復習に。まだの方には興味を持つきっかけに。 ・書籍内で使っている図を使っていきます
5. はじめに キーワード 「不確実性」
6. はじめに キーワード 「武器」 キーワード 「アジャイル」 キーワード 「データ駆動」
7. はじめに キーワード 「データ」 キーワード 「普通の人」
8. Chapter構成 登場する要素は、主に 4つ ・事業（サービス） ・ユーザー ・組織 ・データ
9. Chapter構成 登場する要素は、主に 4つ ・事業 ・ユーザー ・組織 ・データ基盤 現場が不確実性と戦うには この「4つ」を組み合わせたプロセスの構築が必要 同時にこの4つがあらゆる不確実性を生み出し混乱させている事実もある 特に「データ」を正しく扱い、武器として戦っていく データは魔法ではない 　
10. Part 1-1 事業を科学的アプローチで捉え、定義する
11. 　データ駆動戦略の全体像を理解する
12. - まずは対象をすることが大事 - なんとなく利益が出ているのは駄目 - きちんと事業を計測し、数値モデルとして捉える。 - システム理論的な事業理解が必要 - あらゆる対象を「システム」として定義する - システムの3つの特徴 〜システムが形を成す過程〜 - 入出力からシステムは作られる - システムの階層性 - ミクロからマクロまでをズームイン / ズームアウト - 事業を「システム」として定義する - 何をインプットとするか - インプットに対してどのような処理が行われているか - 何をアウトプットしているか 　事業→システム理論で理解する
13. 事業の可観測性（Observability） を高める - 事業モデルを定量的な数値モデルで捉える - ソースコードで定義する - 科学的手法を意識する - 1. 測定可能性 2. 定量性 3. 再現性 4. 統計的有意性 5. 論理的整合性 - 一連の動作をログデータでプロットする - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 事業ソフトウェア = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化
14. 　事業構造をKPIで表現し、 予測可能性をつくる - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が 見え てくる - ということは変数に対して代入すれば出力を予測できる - 科学的な事業構造把握 = KPIツリー - プロダクトにおける一連の動作を数値モデルとして表現しただけでは事 業の現状を可視化しただけで事業改善は生まれません。 - 継続的な 事業改善を行うためには指標を決め、それに向かって改善を 進めていく必要があある - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる - KPIツリーは事業の健康診断
15. 事業の計算式が見えることで予測ができる
16. 事業の計算式が見えることで予測ができる
17. 操作可能な変数を把握して、 事業の予測をする - KPIを用いた予測可能性を高める - KPIツリーの中で操作可能変数 = 自分たちが操作できる変数 を見つけて値を代入する - Ex. - クーポン単価 - 広告予算 - 商品単価
18. 予測値と目標値による事業改善の流れ - 目標値 - あとは目標値を設定してその差分を埋めていく作業に入りま す - Ex. 売上KGIを1,000万円 → 2,000万円 - 予測値と実測値のズレを検知する - 施策のROIやコスト面を意識して施策を実施 - 結果と予測値が合っているかどうかを中心にモニタリング - 施策実施のプロセスは後述します
19. 事業をソフトウェアで捉えると 自動化ができる
20. 事業をソフトウェアで捉えると 自動化ができる
21. Part 1-2 仮説検証を繰り返すことで不確実性を下げていく
22. 仮 説 → 実 験 → 学 習 → 意思決定 - 不確実性と どう戦っていくか - 不確実性が高いプロダクト開発の現場では、どんな施策が ユーザーに受け入れられるかはとても難しい問題 - 事業の寿命は無限にあるわけではなく、常に予算を中心とし たタ イムリミットを意識する必要がある - 実験しながら学習していく - "実験"をすることが大事 - 実験とは言葉のとおり「実際の経験」という 意味 - ユーザーという指針を頼りにしながら、実験を繰り返し、そこか ら得られる結果を「データ」というファクトをもとに学習しなが ら、意思決定をしていく - 仮説検証のプロセスが大事
23. 5つのプロセス 1. 失敗できる環境をつくり出すことで組織は加速する 2. ムダを排除して効率的な実験を行う 3. イテレーティブな改善の流れをアジャイルでつくり出す 4. 仮説検証プロセスで型をつくり、ノウハウを蓄積させる 5. 「流れ」を思考する
24. 型を学び、組織を方向付ける - これらの手法は決して"成功"を保証するものではない - ある種の「型」であり、このプロ セスや方法論さえ守っていれば事業が必ず成長す る、といった銀の弾丸ではありません。 - プロセスや方法論は、手段であり目的ではありません。 - 「型」を何も考えずに組織へ導入すると思考停止になり導入自体が目的となりがち です。 - 例えば、開発手法 1つ取っても「アジャイル開発を導入したからうまくいくはずだ」「スクラムではこうなっているから組 織もこうなるべきだ」というように混同しがちです。
25. 型を学び、組織を方向付ける - 実際にはあらゆる型を組織に適用して、組織文化とマージ（併合）すると必ず差分 が出てきます。 - その差分を組織としてどう馴染ませていくかが肝心なわけですが、 例外が出てくる と「この方法論ではダメだ」「私たちの組織には合わなかった」という結論に陥る ケースを多く見られます。 - 一方、「型」というものは提唱者の思想を肉付けする形で、世の中にわかりやすく 適用できるようにパッケージ化されたものです。 - つまり、作られた背景や思想の部分を理解していれば、提唱者の肉付け部分 （パッケージの部分） を独自にアップデートしていく形で、組織に順応されて、新た な組織文化を更新していけるのではな いかと考えています。
26. 失敗できる環境をつくり出すことで 組織は加速する - 失敗の恐怖。PDCAのPを重視しない - 事業をスケールさせるには、改善施策を合理的に正しい方 向 でどれだけ数多く実行できるかが鍵になる。 - ハードルとなっているのが、失敗への恐怖心です。誰もが思う 「失敗したくない」 という壁が、あらゆる改善の実施に歯止めを かけている。それが組織として存在する - = 前段階にある計画の部分に時間をかける - 失敗をコントロールする - 失敗を”なくす”のではなく、事業構造を理解した上で失敗でき る範囲（予算など）を明確にし、その影響範囲の中で適切に失 敗をさせるこ
27. A/Bテストによる実験 - A/Bテスト - A/Bテストとは、元の機能に変更を加える際に Aパター ンとBパ ターンを用意してテストする手法 - A/Bテストの比重と期間の考え方 - A/Bテストの比重については、統計学的な分析でサンプル数を 満たす割合を見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する
28. MVPによる実験 はじめからさまざまな要素を盛り込んでリリースするのではなく、 狙った仮説が検証できる程度の必要最低限の機能を盛り込んだ形でスピーディーに構築し、そ の状態でユーザーに提供します。 そこから得られるユーザーのフィード バックをもとに、仮説の正当性を確認していき、徐々に学習し ながら機能を充実させていくアプローチ
29. イテレーティブな改善の流れを アジャイルでつくり出す
30. イテレーティブとインクリメントの違い • インクリメント = 少しずつ積み上げる • イテレーティブ = 繰り返す
31. イテレーティブとインクリメントの違い インクリメント型で自動車をつくる イテレーティブ型で自動車をつくる
32. ウォーターフォール型とアジャイル型 インクリメント型で自動車をつくる イテレーティブ型で自動車をつくる
33. アジャイルはつらいもの - アジャイルはつらい - アジャイル型の開発は、小さくプロダクトをつくりながら、ある種 の石橋を叩いて渡りながら、失敗をコントロールしていくプロセ スです - プロセスとして理想的には良いと頭でわかっていても、実現す るには難しい部分も沢山あります - - ケーキの例でも各工程に分かれて大量生産したほうがゴール も明確 - コツを掴んでいくことで個人の生産性も徐々に上がっていくで しょう。 - アジャイルは、それを大量生産ではなく小さく形にして、ユー ザーのフィードバックも見ながらショー トケーキの単位で変更 させていくものです。トッピングがいちごではないかもしれませ ん
34. アジャイルにおけるインクリメントの誤解と解消方法 - 「どの単位でユーザーの機能を提供するか」 - 実際の開発現場では「どの単位でユーザーの機能を提供する か」は頭を悩ませる部分です - イテレーションの中で incrementにならないようにする。 - あまり、機能を削り過ぎても、もともと提供しようとしているプロ ダクトの価値が見えなくなり、逆 に機能を盛り込みすぎると開 発に時間がかかりすぎ、市場への仮説検証が遅る - ユーザーストーリーピッングを作ろう！
35. ユーザーストーリーマッピングとは
36. ユーザーストーリーマッピングとは
37. ユーザーストーリーマッピングとは 商品を検索する 商品を購入する 商品を検索する 商品ページを見る アカウント 登録・認証する 支払い方法を 選択する 商品を購入する ジャンルで検索 商品名で検索 価格が見える 商品レビューが見える メールアドレスで 登録する SNSアカウントで 登録する ゲストで登録する カートに入れる クレジットカードを 登録する クーポンを使う 電子マネーを使う 購入完了メールを送る ポイントを配る カートに入れる ジャンルで検索 商品名で検索 価格が見える 商品レビューが見える メールアドレスで 登録する SNSアカウントで 登録する カートに入れる クレジットカードを 登録する 購入完了メールを送る
38. 仮説検証プロセスで実験を加速させる - 「仮説検証プロセス」 1. KPI選定 2. 仮説 3. 検証 4. 計測 - プロセスをつくるということは型をつくることに等しい - 組織の中で属人的にはならない改善の流れ をつくることで成果物を安 定させることができます。 - そして、そのプロセスの中で数多くの実験を繰 り返すことで、組織として ノウハウが蓄積され、プロセスの精度も上がり、事業のブラックボックス も徐々に明らかになっていきます - BMLループという「型」
39. 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つの処理で 回す量）として大きすぎる - 結果として、どの施策が効果があったのかの依存関係が見えづらくな る。
40. 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→）
41. 「流れ」を思考する 流れの高速化と安定化
42. プロセスをモニタリングする ストーリー WF 設計 iOS / BE 開発中 結合 PO確認 クローズ 計測をしてボトルネックの可視化
43. Part 2-1 強固な組織体制と学習する組織
44. 学習する組織とは何か - 学習する組織の必要性 - 事業や仮説検証プロセスだけでなく、組織も短いサイクルの 中で学習していかなければいけない - 組織の中にいるメンバーのメンタルモデルを考える - 学習する組織とは - 目的に向けて効率的に行動するために - 集団としての意識と能力を - 継続的に高め、伸ばし続ける組織 - 能力の高い人たちが集まれば「学習する組織」になるかとい えばそうではなく、その個人が集まった「集団」としての学習 能力を高めていかなければいけない
45. 組織を戦略的にUnlearnさせる - Unlearnとは - Unlearnとは、学習する上で必要な知識をどう積み上げてい くべきかという概念 - 組織や個人に よって、外からのさまざまな情報や知識をイン プットしながら、それをどう適応していくか、アップ デートして いくかの考え方です - 人はどうしても今までの経験値や学んで きた経験の視野の 中に囚われていることが多くあります - Unlearnという言葉は、直訳すると学ぶ（ Learn）の否定（un） なので「学ばない」「脱学習」といった 印象を持ちますが、少し ニュアンスが異なる
46. 組織を戦略的にUnlearnさせる - 「知」について - 既存の知識に対して、新しい知識の「型」が相互作用する中 で、知識と知識が結びつき言語化されたり、自 分が普段思っ ている課題や不安に対しての理解が深まったりします - これは、新しい知識を入れたと きに発生する不安定な「ゆら ぎ」のプロセスによって生まれます。知識と知識が不安定に ゆらぎながら、 結びついていきます。 - プロダクト開発の現場でも「いまよりも良いやり方はないか」を 常に探 していく探求心をもちながら、戦略的 Unlearnすること が大事
47. アジャイルとUnlearn : 「場」をつくるアジャイル
48. 戦略的Unlearn : 「型」への適応 と「ゆらぎ」の場をつくることが必要
49. 戦略的Unlearnの着想は、XP（エクス トリーム・プログラミング） - XPのパラダイム「注意して、適応して、変更する」 - 運転というのは車を正しい方向に走らせるのではなく、常に注意を 払いながら、こちら に行ったら少し戻して、あちらに走らせてしまったらまたこちらに戻して、と「小さい軌道 修正」をしていくものです - ソフトウェア開発の周りにあるものは常に変化を続けています。事業環境も組織にい る人も、つくる べきものの要件の変化やソフトウェア技術の変化などが存在する中 で、私たちが考えるべきことは、 周辺の変化ではなく、その変化にどのように対応して いくかでしょう - ソフトウェア開発における変化への対応で大事なことは、新しいプラクティスを身軽に 試せる環境です。また、常に新しい変化を柔軟に取り入れ、自分たちを変化させる中 でフィードバックをもらい、 積極的に改善を受け入れることが重要。
50. 戦略的Unlearnの着想は、XP（エクス トリーム・プログラミング） - 継続的な改善とは何か - 継続的な改善と聞くと、絶え間なく連続的に改善を続けていると思われがちですが、 そうではありま せん。継続的に注意して、適応して、そこからフィードバックをもらい、 積極的に改善を受け入れる 準備体制ができていることが継続的な改善 - XPの理論構成には、「価値」「原則」「プラクティス」の3つがあります。特にプラクティス の部分についてはあらゆる問題の改善アプローチが用意されています。 - その理由は、開発チームが継続的改善のプロセスをやめさせないことだと考えられま す。何もない状態で、自ら改善策やアプローチ方法を見つけ出すことは難しく時間が かかります。そんなときは、 XPで用意されているプラクティスをその価値を理解した上 で、自分たちの問題点と照らし合わせて みて適応し、変更してみましょう。そこから出 てきたフィードバックをもとに学習していけば良いのです
51. 戦略的Unlearnの着想は、XP（エクス トリーム・プログラミング） 価値 - コミュニケーション（ Communication） - シンプリティ（Simplity） - フィードバック（Feedback） - 勇気（Courage） - リスペクト（Respect） 原則 - 人間性（Humanity） : 機会（Opportunity） - 経済性（Economics） : 冗長性（Redundancy） - 相互利益（Mutual Benefit） : 失敗（Failure） - 自己相似性（Self-Similarity） : 品質（Quality） - 改善（Improvement） : ベイビーステップ（Baby Steps） - 多様性（Diversity） : 責任の引き受け（Accepted Responsibility） - 振り返り（Reflection） : 流れ（Flow） プラクティス - 共同のプラクティス - 開発のプラクティス - 管理のプラクティス - 顧客のプラクティス チームが継続的改善が行えるように観点が提供されている。 一方、これらは銀の弾丸ではない。
52. 戦略的Unlearn : 「型」への適応 と「ゆらぎ」の場をつくることが必要 既存のプラクティスを導入することで組織内に「ゆらぎ」をつくります。 それから、既存の知 と新しい刺激としてのプラクティスをうまく調和しながら、、既存の知と新しい知の「差分」を出していきます。 そのときに大事な のは、組織が「知」というのものをどうつくり出していくかその「流れ」を見ていくことで、型からチー ムにあった形で差分をつくり 出せるでしょう。
53. 暗黙知から差分を出する - 暗黙知と形式知 - 私たちが「知る」という行為には大きく分けて、暗黙知と形式知があります。 - 「暗黙知」とは、一言でいうと言語化されていない感覚的で身体的な知識のことで す。経験知ともいい、 経験として体に馴染んでいるが言葉として説明できない知識 のことです。この暗黙知には、大きく分 けて2つあります。メンタルモデルを代表とす る「認知スキル」と、ノウハウや技巧、熟練といった「身体スキル」 - 一方、「形式知」とは、言語化、理論化されている知識のことです。感覚的な知識を 形式化して全員に わかるような形で知識を共有することができるようになります。
54. 暗黙知から差分を出する - 「身体スキル」 - 例えば自動車の乗り方について - 自動車の乗り方をいくら座学で学んだとしても、いきなり運転できる人は 多くないでしょう。 - 実際に自動車に乗り、ハンドルを握り、アクセスを踏んでみる、などの体 験を通じて体に染み込ませる - アクセルやクラッチ、ハンドルを絶妙な感覚で操作しながら運転する感覚 はとても論理的に説明できません。
55. 暗黙知から差分を出する - 「認知スキル」 - 個人の根幹にあるメンタルモデル - 人はさまざまな意思決定をするときに過去の体験や経験をもとにしたメン タルモデルをもって行動する - 例えば、新卒のときに大きな障害を起こしてしまった。 - そうするとベテランになっても障害に対する恐怖から、厳重に仕組みを用 意する傾向がある
56. 暗黙知から差分を出する - SECIモデル（セキモデル） - SECIモデルとは、暗黙知と形式知の 2つの知識形態が、相互 作用して変換を繰り返すことで「知識変換」 が行われ、新しい 知識が創造され拡大するという集合知モデル • 共同化（Socialization）（暗黙知→形式知） • 表出化（Externalization）（暗黙知→形式知） • 凍結化（Combination）（形式知→形式知） • 内面化（Internalization）（形式知→暗黙知）
57. 暗黙知から差分を出する - SECIモデルと「ゆらぎ」 - SECIモデルをもとに組織が学習するプロセスを設計する - アジャイルと暗黙知 - モブプログラミングで暗黙知を共有する
58. 戦略的Unlearn : 「型」への適応 と「ゆらぎ」の場をつくることが必要
59. パターン化して広げる - パターンを「作る」 - パターン化とは、差分から生まれたその組織の独自プロセスを 形式知として新たにつくり出すことです。 - どんな「状況」のときに - どんな「問題」が発生しやすい - そんなときには、この「解決」を適用すれば改善するかも しれない - この「状況（Context）」「問題（Problem）」「解説（Solution）」の3 つ記載した上で、「名前（パターン）」 をつけていくことで、 1つのパ ターンができあがります。
60. パターン化して広げる - パターンを「広げる」 - パターンをつくったのならば、その型をつくったチームでブラッ シュアップしていくのはもちろん、 ほかのチーム、組織にも広げて いきましょう。 - 各々がパターンをつくっていき、それを型としてあらゆるチームや 組織に落とし込み、「ゆらぎ」をつく りながら暗黙知へ落とし込ん でいきます。 - そして、それぞれの「状況」「問題」にあったパターンとし てアップ デートしていき、それを違うチームがまた参照していくというサイ クルを回していくことで、 強い組織にしていきます。
61. 統治分割でパターンを広める トップダウンではなく、ボトムアップで広げる。根幹にあるのは「暗黙知」の重要性です。トップダウンでプロセスを 標準化して、強制的にパターンを 導入させるのは危険。それぞれのチームが、保有しているプロ ダクトやチームメンバーによって 生まれる「ゆらぎ」による暗黙知を大切にして、それぞれに最適化した プロセスをつくる必要があります。
62. 組織文化は個の影響度と多数決で決まる
63. Part 2-2 組織構造の力学を操作する
64. 組織構造から発生する 力学を操作する
65. 自己組織化されたプロダクトチーム
66. データアナリストとの事業改善プロセス
67. 組織のサイロ化と向き合う - サイロ化 - ドメイン単位で縦割りの組織がある中で、問題になるのは「サイ ロ化」です - 良くも悪くもプロダクトチームで完結するため、横との連携が少な くなる組織設計となってしまうこ とです - 組織文化も閉じられた状態になり、良い情報や有益な情報が横 に伝わりにくい状態になります。 - サイロ化という文脈では、以下の 2つを防ぐように対策します。 - 事業改善ノウハウのサイロ化を防ぐ - 技術領域のサイロ化を防ぐ
68. 事業改善ノウハウのサイロ化を防ぐ - レポーティング - DMM.comでは、週次レポート / 月次レポートという形で各事業 単位やチーム単位でレポートを書くことで、誰でも他事業の施策 状況などを参照できるようにしています - 本来、サイロ化という文脈よりも、正しく組織階層に沿ったレポー ティングとして機能し、事業の健康状態を理解することに活かさ れていることが多いのですが、 Wikiとして公開され ているため、 誰でも改善の知見ノウハウやその組織文化に触れられます - - ここに書かれている施策や改善について詳しく担当者にヒヤリン グすることはよくある光景で
69. 技術領域のサイロ化を防ぐ
70. Part 3 データの民主化
71. データパイプラインの構築 - データを集約するのが第一歩目 - データ駆動戦略に最も必要なのは、データという資産です。その データを使い、組織の意思決定に役 立てるには、データを整理 整頓して管理しなければなりません。 - 第一歩目として膨大なデータを集約しなければいけません。そし て、そのデータを組織の意思決定の材料とするには、私たちが 見てわかりやすい形でデータが参照できる必要があります。 - また、データは資産なので盗まれてもいけません。
72. データパイプラインの構築 - データパイプライン - データレイク（Data Lake）・・データの湖 - データウェアハウス（ Data Warehouse）・・データの管理倉庫 - データマート（Data Mart）・・価値があるデータ - データガバナンス - GDPR（一般データ保護規則）の策定 - 権限や役割、個人情報の扱いで - 個人が特定できる情報は入れない
73. データの民主化 - ダッシュボードをつくろう！ - KPIダッシュボード - 事業モデルの指標から導き出された KPIツリーをもとに つくっていきます。 - 施策ベースのダッシュボード - 日々事業を伸ばすために実施している施策ごとのダッ シュボード。A/Bテストの結果など - 経営向けダッシュボード - 各事業単位のダッシュボー ドではなく、事業全体を俯瞰 して見れるようなマクロの財務諸表ダッシュボード
74. 毎日ダッシュボードを見る仕組みをつくる - 仕組み作り - KPIマネジメントと同じで、 BIツールのダッシュボードも一度つくっ て終わりではなく運用が必要です。 事業環境は刻一刻と変化し ていくため、できれば、毎日チーム全員で見る習慣をつけること が大事です - • 前日のDAUはどうだったか - • 前日の売上はどうだったか - • UI改善施策のA/Bテストの結果はどうか - • 追加した機能は使われているか - 毎朝、前日分のデータをチャットツールへ通知 - デイリースクラムで毎日確認
75. まとめ - Chapter8 - 今述べてきた流れをロールプレイ的に網羅した形で書籍のなか で述べています - ぜひ、興味あれば書籍でご覧ください！
76. まとめ Part 1-1 事業を科学的アプローチで捉え、定義する Part 1-2 仮説検証を繰り返すことで不確実性を下げていく Part 2-1 強固な組織体制と学習する組織 Part 2-2 組織構造の力学を操作する Part 3 データの民主化
77. ご清聴ありがとうございました ask the speakerへ