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

2021/04/20 東京大学 講義 「ICTと産業」

Transcript

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

3. 3 - “DX”と叫ばれる昨今、DMMは事業をどのように捉えているのか - その中で、現場はどのような動き方・在り方で活躍するべきなのか - ICT産業に触れていくにあたって、現代で最低限となるエンジニアリングの理解 - 事業のスケールを支えるビジネス的な観点とエンジニアリング観点の点と点を繋げる - 財務諸表、マーケティング、エンジニアリング組織、アーキテクチャ、組織、ガバナンス、制度 ,etc... - DMM Groupを事例に議論を展開していく - Target - インターネットサービスを作っていきたい、作っている。その事業分野で活躍したい - サービスを作っていくのにあたって、エンジニアリングをどこまで理解しておくべきか知りたい - エンジニアだが、ビジネス側をどこまで理解しておくべきか知りたい - Learning Outcomes - これからの事業の科学的な捉え方 - その中で活躍できる人材の在り方 Outline
7. 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
8. 8 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda
9. 9 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda
10. 1 0 - すべてを計測可能にしていく。 - 事業、組織、開発プロセスもあらゆるものを「データ」によってプロットしていくことからすべ てが始まる。 - すべてが物語りのように観測できるようになる。 - Observabilityの獲得 - 計測して観察できれば、改善はいくらでもコントロールできる - そこからデータを活用してプロセスの自動化（電子署名など行政や契約周りや事業で言 えばレコメンド）などをしていく。 DX = あらゆるプロセスをデータでプロットするところから始まる Isaac Smith on Unsplash
11. 1 1 - 特に事業を作るプロセスのプロットには、コツがある - 事業のスケールを行うことで必要な「点」が 2つ - ビジネスサイドとエンジニアリングサイド - 現場を見ると、その歯車がうまく噛み合っておらず、事業拡大によるビジネス側の機能要 求に対して、システムという歯車が耐えられない（技術負債）ことが多くある。 - “同期”と”連動” - 事業を構成するすべての歯車がすべて噛み合い、システムの進化が事業の進化を促進 させ、ビジネス側の進化にシステムが耐えられるようなエンジニアリング組織が必要にな る。 「点」と「点」 Pascal Swier on Unsplash
12. 12 “同期” と “連動” - “同期” するのに必要なこと - 職能関係なく “全員“ が収益構造からエンジニアリングまでを理解している必要がある。 - それを成すには、数値などでの共通言語を作り同じ言語で話すことや文化づくりが大事 になってくる。（他にも沢山ある） - エンジニアリングが事業にどんな影響を及ぼしているか。 1エンジニアがコードを書き、毎 日チームと会話をしてチケットを Doneする行動が、事業にどんな影響を与えているの か。 - ”連動” される = 駆動させる - 歯車を高速に動かす、馬力の根源はどこかを意識する - 組織全員が、同じ方向を見てサービスを作っていくには、文化やら組織構造ならをキチン と整理していおく必要がある。 Stillness InMotion on Unsplash
13. 1 3 - システム理論で事業を捉える - あらゆる対象を「システム」として定義する - システムの3つの特徴 〜システムが形を成す過程〜 - 入出力からシステムは作られる - システムの階層性 - ミクロからマクロまでをズームイン / ズームアウト - 事業を「システム」として定義する - 何をインプットとするか - その中で、どんな処理が行われているか - 結果として何かアウトプットされるか - この3つをもって、Observabilityを高めていく 事業を科学的アプローチで捉える
14. 1 4 - 事業モデルを観測可能（Observability）にしていく - ユーザーの細かい挙動をトラッキングしていく - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 一連の動作を「ログデータ」でプロットする - プロダクトにおける一連の動作を数値モデルとして表現する - ユーザー行動を物語のように追うことができる - 事業をソフトウェアとして捉える = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化 事業を科学的アプローチで捉える
15. 1 5 事業をソフトウェアとして捉えたときのインパクト 1. ログデータを中心としたレコメンデーション 2. 財務諸表と1ユーザの行動までを繋げる
16. 1 6 事業をソフトウェアとして捉えたときのインパクト - ログデータを活用した Machine Learning が当たり前のプロダクトへ - 人は判別できない粒度で記録できる - 反復可能性 - 何度でも同じ観点で同じ動作を獲得できる。最近だとその計算リソースもクラウドで安易に。 - DMMだと、1日に数億レコードのログデータが格納され続けている。 - 推奨レコメンドエンジンによる、 ”ユーザー単位” での情報提供 - 商品レコメンド - サービスレコメンド - キャンペーン（広告配信） - 人は仮説を考え、観点を与えるだけで良くなる - 人力で人気商品などを考えて代入する必要はなし - 何を作るべきかを考えれば良い
17. 1 7 ログデータを活用した Machine Learning が当たり前のプロダクトへ 〜DMMでの事例〜
18. 1 8 Netflix Artwork Personalization 引用: https://netflixtechblog.com/artwork-personalization-c589f074ad76 引用 : https://netflixtechblog.com/learning-a-personalized-homepage-aa8ec670359a Learning a Personalized Homepage
19. 1 9 Uber 引用 : https://note.com/tak1/n/ned32591f9322 Taxi dispatch Dynamic pricing
20. 2 0 - マクロからミクロまでをつなげる - 事業の最終的な出力は、財務諸表に表れてくることが大きい - P/L, B/S, C/F - 例えば、P/L（損益計算書） - どれだけ売上をあげて（売上高、原価を引いた粗利） - その中で、コストがかかり（販促費 ,etc..） - どのぐらいの利益がでたか（営業利益 ,etc..） - このP/Lの売上は、1ユーザー行動の合算である。 - 詳細に事業の可観測性をデータでプロットができれば、よりユーザーのことが理解でき る。 財務諸表（マクロ）と 1ユーザー行動（ミクロ）を繋げる
21. 2 1 - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が 見えてくる。事業 の方程式が見えてくる。 - 変数に対して代入すれば出力を予測できる - 事業構造を科学的に把握する手段 = KPIツリー - プロダクトにおける一連の動作を数値モデルとして表現しただけでは事業の現状を可視 化しただけで事業改善は生まれません。 - 継続的な 事業改善を行うためには指標を決め、それに向かって改善を進めていく必要が あある - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる - KPIツリーは事業の健康診断 事業構造をKPIで語る
22. 2 2 事業構造をKPIで語る ※ 実際はもっと複雑になります
23. 2 3 事業構造をKPIで語る ※ 実際はもっと複雑になります
24. 2 4 - KPIを用いた事業改善は、操作可能変数を意識する - KPIツリーの中で操作可能変数 = 自分たちが操作できる変数を見つけて値 を代入する - 変数を代入したことによる KGIがどう変化するのかを観察する - Ex. クーポン単価 / プラットフォーム手数料 / 広告予算 - キードライバーを理解する - キードライバー（影響力の強い変数） - Ex. ユニットエコノミクスや先行指標となる KPI 計算式で表現して、予測可能性を作る
25. 2 5 ユニットエコノミクス - 1人あたりの経済性 LTV CAC
26. 2 6 仮説検証は、予測値と目標値のズレをなくす作業 - 予測値と実測値の不確実性をなくす - 目標値を設定する - KPIツリーと操作可能変数がわかったら、 - あとは目標値を設定して、その差分を埋めていく作業に入る。 - Ex. 売上KGIを1,000万円 → 2,000万円 - 仮説検証の繰り返しで、予測値と実測値のズレを検知する - 仮説検証は、この予測値と実測値のズレをなくすこと - 初期の仮説検証は、質よりも量を重要視する - トレードオフスライダーを作る - 計画に時間をかけない。 - まずは、高速に仮説検証プロセスを回す基盤を作り、仮説の学習を繰り返すことで 徐々に精度（採用率）が上がってくる
27. 2 7 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda
28. 2 8 - 不確実性とどう戦っていくか - 事業の寿命は無限にあるわけではなく、常に予算を中心としたタイムリミットを意識する 必要がある - “ 実験 ” しながら学習していく - "実験"をすることが大事 - 実験とは言葉のとおり「実際の経験」という 意味 - ユーザーという指針を頼りにしながら、実験を繰り返し、そこから得られる結果を「データ」 というファクトをもとに学習しながら、意思決定をしていく - 仮説検証のプロセスが大事 仮説→実験→学習→意思決定
29. 2 9 - 失敗の恐怖。PDCAのPを重視しない - 事業をスケールさせるには、改善施策を合理的に正しい方 向でどれだけ数 多く実行できるかが鍵になる。 - ハードルとなっているのが、失敗への恐怖心です。誰もが思う「失敗したくな い」 という壁が、あらゆる改善の実施に歯止めをかけている。それが組織とし て存在する - = 前段階にある計画の部分に時間をかける - 失敗をコントロールする - 失敗を”なくす”のではなく、事業構造を理解した上で失敗できる範囲（予算な ど）を明確にし、その影響範囲の中で適切に失敗をさせること 失敗をコントロールする
30. 3 0 - A/Bテスト - A/Bテストとは、元の機能に変更を加える際に Aパター ンとBパターンを用意し てテストする手法 - A/Bテストの意味は、「失敗をコントロール」すること - A/Bテストの比重と期間の考え方 - A/Bテストの比重については、統計学的な分析でサンプル数を満たす割合を 見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する - また、仮説検証の大きなによっては A/Bテストに向かないケースもある。 Ex. UIの大々的なリブランディング ABテストによる “ 実験 ”
31. 3 1 ABテストによる “ 実験 ”
32. 3 2 ABテストによる “ 実験 ” A（新） B（既存）
33. 3 3 - BMLループのプロセス 1. Learn → Idea = 仮説を考える 2. Build → Product = どう作るか 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 仮説検証とデータ - Product → Measure - ログデータの設計 - トラッキングを仕込む - Measure → Data - 施策（仮説検証）ごとにダッシュボードを作成する - 日々、観測する ABテストを加速させるBMLループ
34. 3 4 レジリエンスを効かせる - MVP ログデータを軸にしたプロダクト開発について。 はじめからさまざまな要素を盛り込んでリリースするのではなく、 狙った仮説が検証できる程度の必要最低限の機能を盛り込んだ形でスピーディーに構築し、その状態でユーザーに提供します。 そこから得られるユーザーのフィードバックをもとに、仮説の正当性を 確認していき、徐々に学習しながら機能を充実させていくアプローチ。
35. 3 5 イテレーティブとインクリメント レジリエンスを意識したプロダクトの作り方 • インクリメント = 少しずつ積み上げる • イテレーティブ = 繰り返す
36. 3 6 イテレーティブとインクリメント レジリエンスを意識したプロダクトの作り方
37. 3 7 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda
38. 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
39. 3 9 - 結局は、人 - ABテスト x BMLループを駆使して、失敗をコントロールする仕組みを実施するのは、現場のプロダクトチームである。 - システム構成による人をどう配置するかは、失敗をよりコントロールすることができイテレーティブな改善を行えることができる 事業スケールに伴う組織のスケール クロスファンクション型 職能型 機能型（feature） 営業・マーケ デザイン エンジニアリング 構築 仮説ベースの検証 0→1 1→... 営業 部門 デザイン 部門 エンジニア部門 少数精鋭でがむしゃらに作る 事業拡大とともに人数もスケールしていく。 専門職に分かれていく。チームだったり部門 徐々に受託関係のような関係になっていくため、再度クロスファンクショ ン。規模感が大きくなっているためマイクロサービスなどを軸に組織を分 解していく
40. 4 0 - マイクロサービスとは - 事業スケールの初期はスピード感をもって機能拡充していくためモノリスな環境ができ あがることが多い。 - そのため、きちんと関心事を見極めてマイクロサービス化してドメインごとに独立したプ ロセスを実現して、よりイテレーティブな改善を実現する - ペイン - モノリスな環境によってドメインの依存関係がごちゃごちゃになって技術的負債が溜 まっていき機能追加もしずらく、さらにリリースするにも他チームとの調整が必要で全 然リリースできない。 - なので、マイクロサービスによってドメインごとにプロセスを独立させて、小さいサービ ス単位でリリース可能にすることでイテレーティブな事業改善を実現する - マイクロサービス化への後押し - 少し前の時代でなぜサーバーを一緒にしていたかについて、実はサーバーコストの問 題がありました。昔はサーバー自体が高価だったため、ドメインごとにサーバーを分割 したり、DBを分割するといったことはコスト的に難しかった マイクロサービス - Microservices https://martinfowler.com/articles/microservices.html
41. 4 1 コンウェイの法則 - 組織構造とシステムの関係性 - コンウェイの法則 - メルヴィン・コンウェイが提供した概念 - 「システム設計(アーキテクチャ)は、組織構造を反映させたものになる」 - マイクロサービスで言えば、関心事にシステムを分けるだけではなく、最適な組織の形も自動 的に変えていく必要がある - 逆コンウェイの法則 - コンウェイの法則を逆手に取っていきます。 - アーキテクチャによって組織構造を変化させる後追いのではなく、そもそも最初から最適なアー キテクチャに合うような組織デザインを設計する = 「アーキテクチャのための組織を作る」という イメージです。 - ただ、実際には既に巨大なシステムが存在することが多いため、かなり難しいです 組織 システム
42. 4 2 DMMの組織構造
43. 4 3 DMMの組織構造 スモールチームが前提
44. 4 4 DMMの組織構造 - プロセス
45. 4 5 - サイロ化 - ドメイン単位で縦割りの組織がある中で、問題になるのは「サイロ化」 - 良くも悪くもプロダクトチームで完結するため、横との連携が少なくなる組織設 計となってしまうこ とです - 組織文化も閉じられた状態になり、良い情報や有益な情報が横に伝わりにく い状態になります。 - サイロ化という文脈では、以下の 2つを防ぐように対策します。 - 事業改善ノウハウのサイロ化を防ぐ - 技術領域のサイロ化を防ぐ - MECE（漏れなく・被りなく）の難しさ - 細かくマイクロサービス化などでチームの独立性を行いすぎると、そのチーム の間にストンと落ちるものが必ずでてくる。そのため、あまり少数精鋭で細かく しすぎるのも問題あり サイロ化とMECE
46. 4 6 - スループット - 時間あたりの処理能力 - 1回の処理でどのぐらいのデータを送ったりできるか。高ければ高いほど性能が良いとい うことになる。 - ただし、一度にたくさんのデータを送ったりするとレイテンシーが低くなる。 - レイテンシ - 応答が返るまでの時間 - 通信の遅延時間 - 組織はスループットではなく、レイテンシを意識する - 1回の処理でどれだけ詰め込めるかではなく、 1回の応答時間をどれだけ短くできるかが 大事になってくる - 特にログデータを軸に A/Bテストを繰り返すような開発では、イテーティブさやアジリティー が必要になってくるため、いかに早くユーザーフィードバックをもらうかが必要となる。 組織はスループットではなく、レイテンシを上げる input output レイテンシ スループット
47. 4 7 組織構造が文化を作るという法則 1. 組織構造は暗黙的に現行のマネージャーと専門家の役職や権限が変わらないように最適化されています。 2. 1の影響により、変化を起こす提案は、元の状態が再定義される、もしくは新しい用語が乱用されることになり、結果的に元々の状態と変わらない状態になり ます。 3. 1の影響により、変化を起こす提案は「理想主義だ」、「机上の空論だ」、「革命だ」、「宗教だ」、「我々の環境に合うようにカスタマイズすべきだ」といった批判 や嘲笑の対象になります。 ーこれは、自分たちの弱点から目をそらすためであり、マネージャーや専門家が現状を維持するためのものです。 4. 1の影響により、本来の変化とは異なる変化になってしまい、仕事にありつけなかったマネージャーや専門家がまだ残っていた場合、彼らは (2)や(3)を推し進 めながら変化を遂行するためのコーチやトレーナーになってしまいます。 5. 組織構造が文化を作ります。 クレイグ・ラーマンの法則
48. 4 8 - 事業のスケールに伴って、否が応でも組織は形を変えなければならない。 - そのときに、コンウェイの法則を中心としたとシステムアーキテクチャの面でも考慮が必要。 - また、組織文化にも影響を与える - まずは、現状の組織構造から発生する「情報の流れ」を意識してみる。 - 正しい速度で、正しいルートで情報が伝達しているかがとても大事。 - 組織が大きくなればなるほど、トップダウンでの情報伝達や、逆にボトムアップでも情報伝達がどこかで止まりがちになる 組織構造から発生する力学を意識する（まとめ）
49. 4 9 - 事業を科学的アプローチで捉える - “実験”を繰り返す - 事業スケールに伴う組織構造の変化 - 最後に Agenda
50. 5 0 ICTサービスだと大きく分けて2つになる。どっちに向かうとしてもデータを使ったモデルの解釈は必要となる 武器を作る側か、使う側か 武器をどう使う 事業を伸ばす（戦士） 武器を作る 武器を売る（武器商人） t t 武器 (技術) の使い方を習得して 武装して強く戦えるようにする XaaS化との戦い。コモディティー化 Ex. MLエンジニア vs AWS,GCP AutoML 市場との戦い 事業知識とそれに適した 武器の使い方の豊富な知識
51. 5 1 1. 自分の好きなサービスやこれから作ってみたい（流行りそう）サービスを1つ考え出してみてください。 2. そのサービスの事業構造をKPIツリーなどで表現し、収益を出すためにはどのKPI（指標）の数値を上げればいいのかを 記載してください。 3. そのKPIを向上させる施策案を３つ考え、優先順位を付けてみてください。なぜ、その優先順位にしたのかをエビデンス を交えて記載してください。 4. 考えた施策案を実施するためには、どのようなリソース（コスト）がどのぐらいの金額、必要そうかを記載してください。 5. 本講義の感想やコメント、改善点などあれば 課題について
52. 52 2023卒以降インターン情報 就業型インターン 　•期間／給与 2021年7月～11月　最短2週間～最大1か月／時給1,500円 •対象 機械学習エンジニア データアナリスト セキュリティエンジニア インフラエンジニア SRE ※オンライン実施予定。オフライン出社の際は交通費・宿泊費全額支給します！ DMMGUILD（複数部門横断型） 　•期間／給与 2021年8月30日（月）～9月10日（金）／時給1,500円＋賞金 •対象 モバイルアプリエンジニア バックエンドエンジニア フロントエンドエンジニア DMMの複数サービスの issueに取り組めます！ 専門特化型・特定の部門でメンターがサポート！