【融合情報学特別講義Ⅱ】事業とエンジニアリングを繋ぐ力学 - 東京大学大学院講義 / Connecting Engineering - Business

Slide 1

Slide 1 text

事業とエンジニアリングを繋ぐ力学東京大学大学院講義「融合情報学特別講義Ⅱ」 1 Masato Ishigaki December 15, 2021 融合情報学特別講義Ⅱ

Slide 2

Slide 2 text

2 About me Masato Ishigaki - 石垣雅人部長 / VPoE 室 DMM.com エンジニアとして新卒入社専門分野 - ソフトウェア工学 - スモールチームでの開発（アジャイル）著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版 ,2020）連載中 : 『スモールチームが武器になる時代へ』 @i35_267

Slide 3

Slide 3 text

3 - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline

Slide 4

Slide 4 text

4 - Target - エンジニア、事業責任者（ PdM） - サービスを作っていきたい、作っている。その事業分野で活躍したい。 - サービスを作っていくのにあたって、エンジニアリングをどこまで理解しておくべきか知りたい - エンジニアだが、ビジネス側をどこまで理解しておくべきか知りたい - Scope - Scope : - 事業とエンジニアリング , データ, KPIマネジメント, 仮説検証, A/B Test, スモールチーム - Scope out : - DHW, DataPipeline, etc… Outline

Slide 5

Slide 5 text

5 - Expert - ソフトウェア（ハードは弱いです） - ソフトウェア工学 - Product Management - 事業戦略・戦術 - 事業の数値管理 / 予実管理 - データ分析→施策 - Human Management - 事業組織・エンジニア組織のマネジメント - 1on1を中心にしたメンタリング - エンジニア / デザイナー / プランナー評価・育成 - 採用 - Project Management - Howを考える。どうやったらアジリティ高くプロダクトをデリバリーできるか - アジャイル・リーン,etc... Job description Photo by Markus Spiske on Unsplash

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

- Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Why Software Is Eating The World 引用 : https://future.a16z.com/software-is-eating-the-world - すべてが、ソフトウェア化する - ユーザーへ価値 x ビジネスの価値を「ソフトウェア」が繋ぐ世界へ。 - Mobile Application - Web Application - クラウドベースのサービス - 組み込み系 - ウェアラブル型 - VR, AR - IoTデバイス - ,etc…. - DMMも多様なビジネスモデルに対するテクノロジー的アプローチがある - 逆を返せば、ソフトウェアの設計・在り方が、多大な影響を及ぼす時代へ 14

Slide 15

Slide 15 text

Why Software Is Eating The World 引用 : https://future.a16z.com/software-is-eating-the-world - 社会工学的デザインにおけるソフトウェアの複雑性 - インターネットバンキングのソフトウェアに問題があれば家賃が払えない。 - タクシー配達に問題があれば、家から遠く離れた場所で足止めを食らう。 - 医療機器に問題があれば命が危機に晒される。 - Googleサービスが全て落ちたら ...etc. - これらのソフトウェアの設計・実装をしているのは、エンジニアであり、チームである。 - ソフトウェア x 組織デザイン = エンジニアリングを真剣に考える必要が出てきている。 - そうしないと、社会的インフラが危ない状態。デジタル庁が発足など。引用 :   チームトポロジー | マシュー・スケルトン,マニュエル・パイス (著) | https://www.amazon.co.jp/dp/4820729632/ 15

Slide 16

Slide 16 text

16 - “ DX ” の正体 - すべての活動がデジタルによると「データ」として出力される。 - 事業 = サービスの振る舞いがデータとして記録され、ログデータとしてプロットできる。 - エンジニアリングが事業に影響する度合いが高まる。 - “DX”と叫ばれる昨今、DMMは事業をどのように捉えているのか - すべてを計測可能にしていく。 - 事業、組織、開発プロセスもあらゆるものを「データ」によってプロットしていくことからすべてが始まる。 - すべてが物語りのように観測できるようになる。 - Observability（可観測性）の獲得 - 計測して観察できれば、改善はいくらでもコントロールできる - そこからデータを活用してプロセスの自動化（電子署名など行政や契約周りや事業で言えばレコメンド等）などを改善活動をしていく。ソフトウェアの複雑性を解きほぐすものは何か Isaac Smith on Unsplash

Slide 17

Slide 17 text

17 - 事業を作るプロセスのプロットには、コツがある - ビジネスサイドとエンジニアリングサイドという「点」と「点」 - 事業規模関係なく、組織が大きくなれば、役割や責任箇所の分散によってセクショナリズムが起こりやすい構造になります。サービスをスケールさせていく過程で、組織として密結合だったものが徐々に疎結合になっていく。 - 現場を見ると、その歯車がうまく噛み合っておらず、事業拡大によるビジネス側の機能要求に対して、システムという歯車が耐えられない（技術負債）ことが多くある。 - “同期”と”連動” - 事業を構成するすべての歯車がすべて噛み合い、システムの進化が事業の進化を促進させ、ビジネス側の進化にシステムが耐えられるようなエンジニアリング組織が必要になる。 Pascal Swier on Unsplash ソフトウェアの複雑性を解きほぐすものは何か

Slide 18

Slide 18 text

18 - エンジニアが、1行のコードから財務諸表を意識する世界線を作る - エンジニアが今が書いている 1行のコードあるいは、 1つのプルリクエストというミクロな集合体がプロダクトを作り、事業の収支を作っていることを財務諸表レベルで感じてほしい。 - セクショナリズムによる分断とそれによる主体性の欠如 - 事業・組織のスケールによって役割や責任箇所の分散によってセクショナリズムが起こりやすい。 Ex．エンジニアサイド、ビジネスサイド - エンジニアリングの領域に至っては、要求定義で決まっているものを「どう作るか」「作れるか」だけにフォーカスした状態になりやすい。Howの部分にこだわり出して手段の目的化の出来上がり。 - なぜ作っているか、作ったあとにどうなった？の意識的な欠如が起こる構造。（ - - ）( ) { -- --- - - -- -- ; ( ----- -- ----- --) ----- -- ; } Engineering Developer Service 収益費用利益 P/L KPI Process   Cycle ソフトウェアの複雑性を解きほぐすものは何か

Slide 19

Slide 19 text

- 事業のスケールによる、エンジニアリングの犠牲の誤解 - 品質に対するスピードとコストの誤解。トレードオフじゃない。 - 事業責任者も、エンジニアも、そこから逃げてはいけない。 - Is High Quality Software Worth the Cost? - 品質にはexternal quality（機能やインターフェイス）と internal quality（アーキテクチャやコードなどの内部品質）の 2つ。 - Aプロダクト（機能やUIが優れている。ただし、internal qualityはぐちゃぐちゃ - Bプロダクト（機能が少ない。ただし internal qualityは綺麗） - では、初期だとユーザーは、誰しもがAにお金を払うでしょう。 - では、nヶ月後は？ - 事業責任者やエンジニアは、中長期的な視点が必要。 19 B B A B internal quality external quality A nヶ月後 B nヶ月後ソフトウェアの複雑性を解きほぐすものは何か

Slide 20

Slide 20 text

20 引用 : Is High Quality Software Worth the Cost? A. 事業とエンジニアリングの点と点をつなげた意思決定ができる人材が大事。最短、1ヶ月以内には、Bのほうが開発スピードで上回る。損益分岐点。負債・福利も、指数関数的に伸びる。ソフトウェアの複雑性を解きほぐすものは何か

Slide 21

Slide 21 text

Slide 22

Slide 22 text

技術のコモディティ化にエンジニアは敗北する - 世の中は、コモディティ化に溢れている - 消費者にとっては、個性がない状態へ。 - 需要があるものは、コモディティ化する。 - 牛丼、ガソリン、家電、etc... - すべてが平均的な価値になり、あとは価格競争へ。引用 : https://hataraku.vivivit.com/works/commoditization 22

Slide 23

Slide 23 text

技術のコモディティ化にエンジニアは敗北する - 技術も常に進化し、コモディティ化する - 新しい技術が登場し続ける、ソフトウェアの世界。 - Ex. コンテナ技術、k8s、Maschine Learning、NFT - 魅力的な技術であれば、沢山のプラクティスが出てくる。 - 技術の標準化・規約化が行われる。 - X as a Service / OSS として、サービス提供される。 - 昔は苦労して皆が実装していたものが、平等に利用可能な「武器」になるｔ技術競争価格競争価値コモディティ化技術発展の S字カーブユーザーニーズ引用 : https://muchinare.com/archives/13693034.html 23

Slide 24

Slide 24 text

- クラウドの発展が、コモディティ化を促進させた - 2005年ごとに登場した「クラウド」によるコンピューターリソースの可搬性（ポータビリティー）。 - 自前でリソースを所有するところから、インターネット上で、必要な分だけ利用する時代へ。 - クリエイティビティを発揮する部分と、任せる部分を思案する時代へ。 - 上から下まで、自前でやる必要はなし。技術のコモディティ化にエンジニアは敗北する Application Middleware Virtualization Hardware / Network OS Application Middleware Virtualization Hardware / Network OS Application Middleware Virtualization Hardware / Network OS Application Middleware Virtualization Hardware / Network OS Vendor You On - premises IaaS PaaS SaaS 24

Slide 25

Slide 25 text

25 技術のコモディティ化にエンジニアは敗北する - エンジニアもコモディティ化する - コモディティ化した技術を使う、エンジニアもコモディティ化する現象。 - ノーコードやローコードも今後さらに加速。 - 一部の天才を除いては「コードを書く」「サーバーを構築できる」というシンプルなスキルだけでは勝てない世界（淘汰される）になってくる。 - では、エンジニアはどうするべきか。 - それは自分の仕事じゃないよね。というメンタリティーを破壊していく。引用 : ［速報］AWS、ローコードでWebのフロントエンドを開発できる「AWS Amplify Studio」発表。

Slide 26

Slide 26 text

26 技術のコモディティ化にエンジニアは敗北するひとつの答えは、事業をスケールさせるエンジニアリングを学ぶこと - 技術を武器として、事業に「観点」を与えることに力点を置く。 - 技術を使いこなした先にある、事業への「問い」「解」を与える。 - 仮説検証への参加（何を→なぜ）。レコメンドアルゴリズムへの参加。 - 今まで、時間をかけていたものに時間をかけなくて良くなる。 - そのバッファーをどこに費やすか。

Slide 27

Slide 27 text

27 Netflix - エンジニアリングで事業に「観点」を与えている例- レコメンドエンジンへの「問い」 KPI = CTVR（魅力的なコンテンツ） , Churn Rate（継続率） Artwork Personalization 引用: https://netflixtechblog.com/artwork-personalization-c589f074ad76 引用 : https://netflixtechblog.com/learning-a-personalized-homepage-aa8ec670359a Learning a Personalized Homepage エンジニアがアルゴリズムに対して「問い」と「解」を与えて、事業をエンジニアリングでスケールさせている

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Slide 37

Slide 37 text

- KPIで事業を語る - 「データ」を使いながら事業改善を進めていくには共通言語が必要。 - KPIというアプローチ。構造で捉える x データで細かく分解できる - 最近では、ほとんど何をするにも KPIをもとに会話することが多い。 - Ex. この機能を作りたい。〇〇 KPIに効きそうだから。なぜなら ... - 感覚ではなく、事業構造 x データというエビデンスを元にした意思決定 - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が見えてくる。事業の方程式が見えてくる。 - 変数に対して代入すれば出力を予測できる - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる KPIで事業を語る 37

Slide 38

Slide 38 text

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Slide 44

Slide 44 text

- 事業の短命さと継続性 - 事業の寿命は無限ではない。 - 常に予算とリソースのタイムリミットを意識する必要がある。 - 不確実性が高い事業環境下のなか、イテレーティブな仮説と実験によって伸ばさなければ、事業はすぐに死んでしまう。作ったシステムもなくなってしまう。 - 天才と凡人 - 勝手に伸びることは、天才的なビジネスセンスがなければ、ほぼない。 - 私含めて、普通の人は「データ」を武器に戦わなくてはいけない。 - 大きなブレイクスルーよりも、 1%の改善を繰り返す。仮説と実験で、転がしていく 44

Slide 45

Slide 45 text

- 正しい方向で、正しい戦術を、正しいリソースで - ただし、仮説と実験が大事だと言っても、闇雲に高速に開発して、リリースすれば良いわけではない。 - 正しい方向で、正しい戦術で、正しいリソースを使いながら進む - 仮説と実験で、転がしていく - 正しい方向 = - KPI駆動からの事業戦略。 - 課題となるKPIを理解する = この事業を伸ばすための方向性・道標の明確化。 - 正しい戦術 = - 課題のKPIツリー（方向性）に対して、どういった施策を当てるのが良いのかの作戦。大きな機能追加なのか、UI刷新なのか、キャンペーンなのか。 - 正しいリソース = - 戦術に対して、組織的なコスト（人・モノ・金）をどのぐらいのリソース配分で攻め込んでいくか。予算コントロールとプロジェクトマネジメント正しい方向正しい戦術正しいリソース仮説と実験で転がしていく t 価値仮説と実験で、転がしていく 45

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

仮説と実験で、転がしていく 49

Slide 50

Slide 50 text

A（新） B（既存）仮説と実験で、転がしていく 50

Slide 51

Slide 51 text

- 失敗例 - KPIツリーの分解不足による注力箇所を間違える - 自分たちがこれぐらいで良いだろうという分解で、よくないことが多い - Ex. 新規は十分に取れているのに「友達招待キャンペーン」をやる等 - 結局、バケツの穴が空いている状態なので同じことになる。 - プロダクトの初期フェーズなので、まずは熱狂的なコアファンを作る - もっと分解すると、モバイルアプリであれば、ストア経由での流入が多いのか、広告経由なのか、SNS経由なのか。分解できるところまで分解 → 定量化しないと、どこにリソースを突っ込めば良いかわからない。 n n n 利益 MAU 新規定着（既存）復帰 × MAU - User Status 新規定着復帰休眠 70% 20% 10% 8月 51 9月 10月仮説と実験で、転がしていく

Slide 52

Slide 52 text

- 「KPI」と「仮説と実験」はセットで考える。 - KPIツリーが分解 → ダッシュボードで数値管理　 →　目標値を設定。 - Ex. KGI（利益）を1,000万円 → 3,000万円 → どうやったらココにいけるか。その差分を埋めていく作業に入る。 - 正しい方向に対して、どのような戦術で攻めるか。 - 施策ごとに「予測値」と「実測値」をモニタリングしていく。 - 必ず、学習しないと同じ失敗を繰り返す - だいたい、施策の採用率 / 成功率 = 40 ~ 60% 52 どんな戦術 = 施策で攻めていくか仮説と実験で、転がしていく

Slide 53

Slide 53 text

- 問いたい “ 仮説 ” とそれを証明する “ 実験 “ - 仮説を証明するために、どういった戦術（施策）を組んで実行するかを考える際の大前提は「問いたい仮説に対して、その戦術（施策）で、果たしてきちんと証明できるか」です。 - 失敗例 - 仮説に対する実験方法が違う = 施策に対する仮説や対象 KPIがない。 - 機能ベースで「これがあったら良い」と主観的に考えがちになる - Ex. 支払い手段を変更してもらいたい。それによって利益が上がる状態になる。 - 戦術として使えるのはポイント（電子マネー） - パット見の派手さ（バズる）で、山分け方式が案として上がる。 - → しかし、対象 KPIは継続性を求めるもの。継続ポイント還元 CPが本来の戦術としては有効打。 - 対象KPIの理解が前提。 - 戦術バリエーションは他社事例や TTPSでカバー。 53 どんな戦術 = 施策で攻めていくか仮説と実験で、転がしていく

Slide 54

Slide 54 text

54 どんな戦術 = 施策で攻めていくか仮説と実験で、転がしていく - 失敗例 - 仮説検証からの学習の部分が全然できていない - 仮説 → 施策 → 実施→結果→理解（認識）→次へ - 仮説 → 施策 → 実施→結果→理解（認識）→ 学習→ 次へ - ログが仕込まれてない → 検証 & 学習ができない - 実装してから気づくことが大きい。 - 実装までにトラッキングの設計が不十分。 - プロセスの整備が必要

Slide 55

Slide 55 text

Slide 56

Slide 56 text

- 実際の改善案 - BMLループのプロセスの浸透 1. Learn → Idea = 仮説を考える = 正しい方向 2. Build → Product = どう作るか = 戦術 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 逆回転からの順回転 - その仮説で証明したいことを確認（先に数値管理ダッシュボードを作成する）してから、施策をBuildする BMLループで、学習プロセスを構築する 56

Slide 57

Slide 57 text

- どこに / どのぐらいのリソースを / どの期間突っ込むか - 正しいリソースの再配分をどうしていくか。 - プロダクトは、常に動き続けている。人も変化しつづける。 - 施策も、リファクタリングも、 UX改善も、個々の目標 / キャリアも、 n… - すべてを器用にこなしながら、走るしかない。 - BMLループでの学習サイクルを構築する - BMLループでの開発プロセス構築。 - チームのキャパシティーを計算して、施策の優先度と量を計算する。 - まずは、チームの戦闘力を知るところから。 57 Single Piece Flow（1つのサイクルで1つの仮説） BMLループで、学習プロセスを構築する

Slide 58

Slide 58 text

Slide 59

Slide 59 text

59 チームの戦闘力すら計測して、可視化する「事業もシステムもモニタリングできるなら、開発力もモニタリングできるはず」 - Layer 1. - コードレベルでのチーム生産性の可視化 - pull request , commit , commentから生産性の健全性を可視化 - Layer 2. - チーム開発のストーリーポイントを元にした生産性の可視化 - Velocity, Cumulative ﬂow, Control Chart - Layer 3. - 開発プロセス全般（ MTGの間隔等々も加味した）のリードタイムの改善 - VSM（Value Streaming Mapping）それぞれで可視化をして、現状の戦闘力を知る

Slide 60

Slide 60 text

60 Layer 1. Pull Request Layer 2. Cumulative ﬂow チームの戦闘力すら計測して、可視化する

Slide 61

Slide 61 text

61 引用：https://juas.or.jp/cms/media/2020/05/20swm_pr.pd チームの戦闘力は、世の中と比較して高いと言い切れるか三乗根に2.7をかけるチームの戦闘力すら計測して、可視化する

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

Slide 64

Slide 64 text

出荷出荷スモールチームと技術の力学ウォータフォール出荷。出荷後に顧客の反応を見て、いちごのホールケーキから違うホールケーキにするのは難しい。出荷。残りショートケーキは、ユーザーのフィードバックによってどんどんトッピングを変えていける。ベースの部分の変更は難しいことが多い。結合チーム C チーム A チーム B チーム A x n アジャイルできるだけバッチサイズを小さく。 64

Slide 65

Slide 65 text

65 スモールチームと技術の力学 - チームサイズのスパン・オブ・コントロール - 主にエンドユーザー向けのサービス開発現場において主流となったアジャイル開発は、できる限りプロダクトチームにオーナーシップを持たせます。 - オーナーシップとは、権限と裁量、責任、自律性です。独立したプロセスで意思決定を早めながらプロダクト開発の不確実性に対応できるようにするためです。 - チームサイズにも注目すると、 Amazonが提唱している「ピザ 2枚ルール」や、イギリスの人類学者であるロビン・ダンバーによる「ダンバー数」 - 「ピザ2枚ルール」・・・効率とスケーラビリティの観点で、社内のすべてのチームは 2枚のピザを食べるのにピッタリな人数でなければいけない。 - 「ダンバー数」・・・人類学的に3～5人「社会集団（クリーク）」が最も親密な友人関係を築ける人数である。 The two-pizza rule 5 15 35 150 500 1500 Dunbar’s Number

Slide 66

Slide 66 text

66 スモールチームと技術の力学 - プロダクト開発が、1つのチームで完結する - クラウドサービスを中心に技術のコモディティや 2009年あたりのDevOps, マイクロサービスの再評価によって、 1つのチームで1つのプロダクトという形が多くなった。 - また、サービス規模が拡大したとしても、人数でスケールすることもなくなった。 - Instagram - プロダクトローンチから、わずか 9ヶ月でFacebookに10億ドルで買収された話は有名ですが、驚くべきは社員が 13人であったこと。 - かつ当時のユーザー数は、既に 3,000万人いたことから、数名のエンジニアチームでその規模のトラフィクを捌いていた。 - それを成せたのも、スモールチーム x 技術の部分でのスケーラビリティを支える融合があってこそだったでしょう。引用: https://www.nikkei.com/article/DGXBZO40332590R10C12A4000000/

Slide 67

Slide 67 text

67 - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline

Slide 68

Slide 68 text

- 視座を上げて、視野を知る - 不確実な世界で、何をすれば良いのかは不透明。 - まずは、武器を増やすことに注力する。 - 視座を上げていくと、今までにないスキルが見えてくる。 - 課題がないのではなく、見えていないが正解。 - 一定の視座だと、成長曲線がゆるくなる。不確実な世界に立ち向かうためのキャリア戦略視野視座事業チーム個深さ / 広さ経営 Ex. 開発 Ex. データ分析 Ex. 財務諸表 Ex. マーケティング Ex. PM ベクトル（視点） 68

Slide 69

Slide 69 text

- GRITを底上げする - 色んなキャリアパスを選択する前に、 GRIT（Guts / Resilience / Initiative / Tenacity）和訳だと「やり抜く力」を上げていく。 - 何事も執念や、承認欲求とか、好奇心とか、プライドとか、コンプレックスとか、そういう根底にある強い感情をフックにやり抜く力が大事。 - 1on1で、個々のGRITはどこかを探っていく。そこからベクトルを探る。 - 目標を決めさせない選択肢 - 不確実性が高いと、目標が決めづらい - 本来、目標設定はモチベーション向上のために設定するもの - 「何を達成したいか」ではなく「どういう状態でいたいか」 69 不確実な世界に立ち向かうためのキャリア戦略

Slide 70

Slide 70 text

- 採用は最高の技術投資だが、最悪の技術投資にもなり得る - 人も技術投資と考えると、特に良いエンジニアの採用は、最高の技術投資になる。 - 年収1000万のエンジニアを5人抱えると、ざっと年間 5,000万の技術投資。 - 一方、事業を成り立たせるために必要な技術投資の中でも単純な技術投資と違って、人は不可逆性が高すぎる。 - このツール使いづらいから来月から契約終了しようといったことは、ツールはできても、人（特に正社員）だと難しい。 - 最近のエンジニア採用市場 - 良いエンジニアを取り合っている状態。 - 一方、新卒採用に関して、ある程度のクオリティーのものは、パッケージ化されたもので簡単にできる。技術のコモディティ化の文脈 - きちんと、エンジニア +αを考える 70 不確実な世界に立ち向かうためのキャリア戦略