事業とエンジニアリングを繋ぐ力学

by Masato Ishigaki / 石垣雅人

Slide 1

Slide 1 text

事業とエンジニアリングを繋ぐ力学〜DMMサービスを作るエンジニア組織と在り方〜東大講義「ICTと産業」 1 Masato Ishigaki April 20, 2021

Slide 2

Slide 2 text

2 About me Masato Ishigaki - 石垣雅人 DMM.com エンジニア新卒入社 DMMにおける3000万のアカウント(ID)、認証(Auth) のバックエンド周りのプロダクトオーナーを経て、2018年7月にリードナーチャリング領域を強化するの立ち上げを行う。2020年より、DMM / FANZAの総合トップなどを管轄する総合トップ開発部の部長を務める。現在は、DMM PointClubアプリのプロダクトマネージャも遵守。著 : 『DMMを支えるデータ駆動戦略 ]』（マイナビ出版 ,2020） @i35_267 総合トップ開発部部長  

Slide 3

Slide 3 text

3 - “DX”と叫ばれる昨今、DMMは事業をどのように捉えているのか - その中で、現場はどのような動き方・在り方で活躍するべきなのか - ICT産業に触れていくにあたって、現代で最低限となるエンジニアリングの理解 - 事業のスケールを支えるビジネス的な観点とエンジニアリング観点の点と点を繋げる - 財務諸表、マーケティング、エンジニアリング組織、アーキテクチャ、組織、ガバナンス、制度 ,etc... - DMM Groupを事例に議論を展開していく - Target - インターネットサービスを作っていきたい、作っている。その事業分野で活躍したい - サービスを作っていくのにあたって、エンジニアリングをどこまで理解しておくべきか知りたい - エンジニアだが、ビジネス側をどこまで理解しておくべきか知りたい - Learning Outcomes - これからの事業の科学的な捉え方 - その中で活躍できる人材の在り方 Outline

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

7 - Mission - DMMをプラットフォーム軸で観察し、送客・回遊という軸で売上貢献 - DMMサービスがすべて同一の ID・決済・ポイントで繋ぐことで DMM経済圏を作る - Product Management - Why / Whatの定義 - 事業の数値管理 / 予実管理 - データ分析→施策 - 新規事業提案 & MA検討 - People Management - 事業組織・エンジニア組織のマネジメント - 1on1を中心にしたメンタリング - エンジニア / デザイナー / プランナー評価・育成 - 採用 - Project Management - Howを考える。どうやったらアジリティ高くプロダクトをデリバリーできるか - アジャイル・リーン,etc... Job description Photo by Markus Spiske on Unsplash

Slide 8

Slide 8 text

8 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda

Slide 9

Slide 9 text

9 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda

Slide 10

Slide 10 text

1 0 - すべてを計測可能にしていく。 - 事業、組織、開発プロセスもあらゆるものを「データ」によってプロットしていくことからすべてが始まる。 - すべてが物語りのように観測できるようになる。 - Observabilityの獲得 - 計測して観察できれば、改善はいくらでもコントロールできる - そこからデータを活用してプロセスの自動化（電子署名など行政や契約周りや事業で言えばレコメンド）などをしていく。 DX = あらゆるプロセスをデータでプロットするところから始まる Isaac Smith on Unsplash

Slide 11

Slide 11 text

1 1 - 特に事業を作るプロセスのプロットには、コツがある - 事業のスケールを行うことで必要な「点」が 2つ - ビジネスサイドとエンジニアリングサイド - 現場を見ると、その歯車がうまく噛み合っておらず、事業拡大によるビジネス側の機能要求に対して、システムという歯車が耐えられない（技術負債）ことが多くある。 - “同期”と”連動” - 事業を構成するすべての歯車がすべて噛み合い、システムの進化が事業の進化を促進させ、ビジネス側の進化にシステムが耐えられるようなエンジニアリング組織が必要になる。「点」と「点」 Pascal Swier on Unsplash

Slide 12

Slide 12 text

12 “同期” と “連動” - “同期” するのに必要なこと - 職能関係なく “全員“ が収益構造からエンジニアリングまでを理解している必要がある。 - それを成すには、数値などでの共通言語を作り同じ言語で話すことや文化づくりが大事になってくる。（他にも沢山ある） - エンジニアリングが事業にどんな影響を及ぼしているか。 1エンジニアがコードを書き、毎日チームと会話をしてチケットを Doneする行動が、事業にどんな影響を与えているのか。 - ”連動” される = 駆動させる - 歯車を高速に動かす、馬力の根源はどこかを意識する - 組織全員が、同じ方向を見てサービスを作っていくには、文化やら組織構造ならをキチンと整理していおく必要がある。 Stillness InMotion on Unsplash

Slide 13

Slide 13 text

1 3 - システム理論で事業を捉える - あらゆる対象を「システム」として定義する - システムの3つの特徴〜システムが形を成す過程〜 - 入出力からシステムは作られる - システムの階層性 - ミクロからマクロまでをズームイン / ズームアウト - 事業を「システム」として定義する - 何をインプットとするか - その中で、どんな処理が行われているか - 結果として何かアウトプットされるか - この3つをもって、Observabilityを高めていく事業を科学的アプローチで捉える

Slide 14

Slide 14 text

1 4 - 事業モデルを観測可能（Observability）にしていく - ユーザーの細かい挙動をトラッキングしていく - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 一連の動作を「ログデータ」でプロットする - プロダクトにおける一連の動作を数値モデルとして表現する - ユーザー行動を物語のように追うことができる - 事業をソフトウェアとして捉える = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化事業を科学的アプローチで捉える

Slide 15

Slide 15 text

1 5 事業をソフトウェアとして捉えたときのインパクト 1. ログデータを中心としたレコメンデーション 2. 財務諸表と1ユーザの行動までを繋げる

Slide 16

Slide 16 text

1 6 事業をソフトウェアとして捉えたときのインパクト - ログデータを活用した Machine Learning が当たり前のプロダクトへ - 人は判別できない粒度で記録できる - 反復可能性 - 何度でも同じ観点で同じ動作を獲得できる。最近だとその計算リソースもクラウドで安易に。 - DMMだと、1日に数億レコードのログデータが格納され続けている。 - 推奨レコメンドエンジンによる、 ”ユーザー単位” での情報提供 - 商品レコメンド - サービスレコメンド - キャンペーン（広告配信） - 人は仮説を考え、観点を与えるだけで良くなる - 人力で人気商品などを考えて代入する必要はなし - 何を作るべきかを考えれば良い

Slide 17

Slide 17 text

1 7 ログデータを活用した Machine Learning が当たり前のプロダクトへ〜DMMでの事例〜

Slide 18

Slide 18 text

1 8 Netflix Artwork Personalization 引用: https://netflixtechblog.com/artwork-personalization-c589f074ad76 引用 : https://netflixtechblog.com/learning-a-personalized-homepage-aa8ec670359a Learning a Personalized Homepage

Slide 19

Slide 19 text

1 9 Uber 引用 : https://note.com/tak1/n/ned32591f9322 Taxi dispatch Dynamic pricing

Slide 20

Slide 20 text

2 0 - マクロからミクロまでをつなげる - 事業の最終的な出力は、財務諸表に表れてくることが大きい - P/L, B/S, C/F - 例えば、P/L（損益計算書） - どれだけ売上をあげて（売上高、原価を引いた粗利） - その中で、コストがかかり（販促費 ,etc..） - どのぐらいの利益がでたか（営業利益 ,etc..） - このP/Lの売上は、1ユーザー行動の合算である。 - 詳細に事業の可観測性をデータでプロットができれば、よりユーザーのことが理解できる。財務諸表（マクロ）と 1ユーザー行動（ミクロ）を繋げる

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

2 2 事業構造をKPIで語る ※ 実際はもっと複雑になります

Slide 23

Slide 23 text

2 3 事業構造をKPIで語る ※ 実際はもっと複雑になります

Slide 24

Slide 24 text

2 4 - KPIを用いた事業改善は、操作可能変数を意識する - KPIツリーの中で操作可能変数 = 自分たちが操作できる変数を見つけて値を代入する - 変数を代入したことによる KGIがどう変化するのかを観察する - Ex. クーポン単価 / プラットフォーム手数料 / 広告予算 - キードライバーを理解する - キードライバー（影響力の強い変数） - Ex. ユニットエコノミクスや先行指標となる KPI 計算式で表現して、予測可能性を作る

Slide 25

Slide 25 text

2 5 ユニットエコノミクス - 1人あたりの経済性 LTV CAC

Slide 26

Slide 26 text

2 6 仮説検証は、予測値と目標値のズレをなくす作業 - 予測値と実測値の不確実性をなくす - 目標値を設定する - KPIツリーと操作可能変数がわかったら、 - あとは目標値を設定して、その差分を埋めていく作業に入る。 - Ex. 売上KGIを1,000万円 → 2,000万円 - 仮説検証の繰り返しで、予測値と実測値のズレを検知する - 仮説検証は、この予測値と実測値のズレをなくすこと - 初期の仮説検証は、質よりも量を重要視する - トレードオフスライダーを作る - 計画に時間をかけない。 - まずは、高速に仮説検証プロセスを回す基盤を作り、仮説の学習を繰り返すことで徐々に精度（採用率）が上がってくる

Slide 27

Slide 27 text

2 7 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

3 0 - A/Bテスト - A/Bテストとは、元の機能に変更を加える際に AパターンとBパターンを用意してテストする手法 - A/Bテストの意味は、「失敗をコントロール」すること - A/Bテストの比重と期間の考え方 - A/Bテストの比重については、統計学的な分析でサンプル数を満たす割合を見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する - また、仮説検証の大きなによっては A/Bテストに向かないケースもある。 Ex. UIの大々的なリブランディング ABテストによる “ 実験 ”

Slide 31

Slide 31 text

3 1 ABテストによる “ 実験 ”

Slide 32

Slide 32 text

3 2 ABテストによる “ 実験 ” A（新） B（既存）

Slide 33

Slide 33 text

3 3 - BMLループのプロセス 1. Learn → Idea = 仮説を考える 2. Build → Product = どう作るか 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 仮説検証とデータ - Product → Measure - ログデータの設計 - トラッキングを仕込む - Measure → Data - 施策（仮説検証）ごとにダッシュボードを作成する - 日々、観測する ABテストを加速させるBMLループ

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

3 5 イテレーティブとインクリメントレジリエンスを意識したプロダクトの作り方 ● インクリメント = 少しずつ積み上げる ● イテレーティブ = 繰り返す

Slide 36

Slide 36 text

3 6 イテレーティブとインクリメントレジリエンスを意識したプロダクトの作り方

Slide 37

Slide 37 text

3 7 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda

Slide 38

Slide 38 text

3 8 事業スケールのフェーズ構築仮説ベースの検証 MVP Minimum Viable Product PMF Product Market Fit Scale PSF Problem Solution Fit 定義サマリー・ターゲットの囲い込みの成功（前提）・Unit Economicsの達成（収益化できる状態。 not 収益化している状態）定義サマリー・Unit EconomicsをScaleさせる。・→ その場合にもきちんと成り立つか。キャズム理論でいう CACの変化など。・必要に応じて、 GTM（Go-To-Market Strategy）の確保・SOMへの達成とSAMの拡大 0→1 1→... Value t 投資に例えたときのイメージシードシリーズA シリーズB→C IPO 0→1の部分でもMVPなり、データを前提としたプロダクト開発をしないといけない。 Pivot

Slide 39

Slide 39 text

3 9 - 結局は、人 - ABテスト x BMLループを駆使して、失敗をコントロールする仕組みを実施するのは、現場のプロダクトチームである。 - システム構成による人をどう配置するかは、失敗をよりコントロールすることができイテレーティブな改善を行えることができる事業スケールに伴う組織のスケールクロスファンクション型職能型機能型（feature）営業・マーケデザインエンジニアリング構築仮説ベースの検証 0→1 1→... 営業部門デザイン部門エンジニア部門少数精鋭でがむしゃらに作る事業拡大とともに人数もスケールしていく。専門職に分かれていく。チームだったり部門徐々に受託関係のような関係になっていくため、再度クロスファンクション。規模感が大きくなっているためマイクロサービスなどを軸に組織を分解していく

Slide 40

Slide 40 text

4 0 - マイクロサービスとは - 事業スケールの初期はスピード感をもって機能拡充していくためモノリスな環境ができあがることが多い。 - そのため、きちんと関心事を見極めてマイクロサービス化してドメインごとに独立したプロセスを実現して、よりイテレーティブな改善を実現する - ペイン - モノリスな環境によってドメインの依存関係がごちゃごちゃになって技術的負債が溜まっていき機能追加もしずらく、さらにリリースするにも他チームとの調整が必要で全然リリースできない。 - なので、マイクロサービスによってドメインごとにプロセスを独立させて、小さいサービス単位でリリース可能にすることでイテレーティブな事業改善を実現する - マイクロサービス化への後押し - 少し前の時代でなぜサーバーを一緒にしていたかについて、実はサーバーコストの問題がありました。昔はサーバー自体が高価だったため、ドメインごとにサーバーを分割したり、DBを分割するといったことはコスト的に難しかったマイクロサービス - Microservices https://martinfowler.com/articles/microservices.html

Slide 41

Slide 41 text

4 1 コンウェイの法則 - 組織構造とシステムの関係性 - コンウェイの法則 - メルヴィン・コンウェイが提供した概念 - 「システム設計(アーキテクチャ)は、組織構造を反映させたものになる」 - マイクロサービスで言えば、関心事にシステムを分けるだけではなく、最適な組織の形も自動的に変えていく必要がある - 逆コンウェイの法則 - コンウェイの法則を逆手に取っていきます。 - アーキテクチャによって組織構造を変化させる後追いのではなく、そもそも最初から最適なアーキテクチャに合うような組織デザインを設計する = 「アーキテクチャのための組織を作る」というイメージです。 - ただ、実際には既に巨大なシステムが存在することが多いため、かなり難しいです組織システム

Slide 42

Slide 42 text

4 2 DMMの組織構造

Slide 43

Slide 43 text

4 3 DMMの組織構造スモールチームが前提

Slide 44

Slide 44 text

4 4 DMMの組織構造 - プロセス

Slide 45

Slide 45 text

4 5 - サイロ化 - ドメイン単位で縦割りの組織がある中で、問題になるのは「サイロ化」 - 良くも悪くもプロダクトチームで完結するため、横との連携が少なくなる組織設計となってしまうことです - 組織文化も閉じられた状態になり、良い情報や有益な情報が横に伝わりにくい状態になります。 - サイロ化という文脈では、以下の 2つを防ぐように対策します。 - 事業改善ノウハウのサイロ化を防ぐ - 技術領域のサイロ化を防ぐ - MECE（漏れなく・被りなく）の難しさ - 細かくマイクロサービス化などでチームの独立性を行いすぎると、そのチームの間にストンと落ちるものが必ずでてくる。そのため、あまり少数精鋭で細かくしすぎるのも問題ありサイロ化とMECE

Slide 46

Slide 46 text

4 6 - スループット - 時間あたりの処理能力 - 1回の処理でどのぐらいのデータを送ったりできるか。高ければ高いほど性能が良いということになる。 - ただし、一度にたくさんのデータを送ったりするとレイテンシーが低くなる。 - レイテンシ - 応答が返るまでの時間 - 通信の遅延時間 - 組織はスループットではなく、レイテンシを意識する - 1回の処理でどれだけ詰め込めるかではなく、 1回の応答時間をどれだけ短くできるかが大事になってくる - 特にログデータを軸に A/Bテストを繰り返すような開発では、イテーティブさやアジリティーが必要になってくるため、いかに早くユーザーフィードバックをもらうかが必要となる。組織はスループットではなく、レイテンシを上げる input output レイテンシスループット

Slide 47

Slide 47 text

4 7 組織構造が文化を作るという法則 1. 組織構造は暗黙的に現行のマネージャーと専門家の役職や権限が変わらないように最適化されています。 2. 1の影響により、変化を起こす提案は、元の状態が再定義される、もしくは新しい用語が乱用されることになり、結果的に元々の状態と変わらない状態になります。 3. 1の影響により、変化を起こす提案は「理想主義だ」、「机上の空論だ」、「革命だ」、「宗教だ」、「我々の環境に合うようにカスタマイズすべきだ」といった批判や嘲笑の対象になります。ーこれは、自分たちの弱点から目をそらすためであり、マネージャーや専門家が現状を維持するためのものです。 4. 1の影響により、本来の変化とは異なる変化になってしまい、仕事にありつけなかったマネージャーや専門家がまだ残っていた場合、彼らは (2)や(3)を推し進めながら変化を遂行するためのコーチやトレーナーになってしまいます。 5. 組織構造が文化を作ります。クレイグ・ラーマンの法則

Slide 48

Slide 48 text

4 8 - 事業のスケールに伴って、否が応でも組織は形を変えなければならない。 - そのときに、コンウェイの法則を中心としたとシステムアーキテクチャの面でも考慮が必要。 - また、組織文化にも影響を与える - まずは、現状の組織構造から発生する「情報の流れ」を意識してみる。 - 正しい速度で、正しいルートで情報が伝達しているかがとても大事。 - 組織が大きくなればなるほど、トップダウンでの情報伝達や、逆にボトムアップでも情報伝達がどこかで止まりがちになる組織構造から発生する力学を意識する（まとめ）

Slide 49

Slide 49 text

4 9 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda

Slide 50

Slide 50 text

5 0 ICTサービスだと大きく分けて2つになる。どっちに向かうとしてもデータを使ったモデルの解釈は必要となる武器を作る側か、使う側か武器をどう使う事業を伸ばす（戦士）武器を作る武器を売る（武器商人） t t 武器 (技術) の使い方を習得して武装して強く戦えるようにする XaaS化との戦い。コモディティー化 Ex. MLエンジニア vs AWS,GCP AutoML 市場との戦い事業知識とそれに適した武器の使い方の豊富な知識

Slide 51

Slide 51 text

5 1 1. 自分の好きなサービスやこれから作ってみたい（流行りそう）サービスを1つ考え出してみてください。 2. そのサービスの事業構造をKPIツリーなどで表現し、収益を出すためにはどのKPI（指標）の数値を上げればいいのかを記載してください。 3. そのKPIを向上させる施策案を３つ考え、優先順位を付けてみてください。なぜ、その優先順位にしたのかをエビデンスを交えて記載してください。 4. 考えた施策案を実施するためには、どのようなリソース（コスト）がどのぐらいの金額、必要そうかを記載してください。 5. 本講義の感想やコメント、改善点などあれば課題について

Slide 52

Slide 52 text

52 2023卒以降インターン情報就業型インターン　●期間／給与 2021年7月～11月　最短2週間～最大1か月／時給1,500円 ●対象機械学習エンジニアデータアナリストセキュリティエンジニアインフラエンジニア SRE ※オンライン実施予定。オフライン出社の際は交通費・宿泊費全額支給します！ DMMGUILD（複数部門横断型）　●期間／給与 2021年8月30日（月）～9月10日（金）／時給1,500円＋賞金 ●対象モバイルアプリエンジニアバックエンドエンジニアフロントエンドエンジニア DMMの複数サービスの issueに取り組めます！専門特化型・特定の部門でメンターがサポート！