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

2021 東京大学大学院 IIS Lab (東京大学矢谷研究室) 【融合情報学特別講義】の登壇資料
https://iis-lab.org

Transcript

1. 事業とエンジニアリングを 繋ぐ力学 東京大学 大学院講義「融合情報学特別講義Ⅱ」 1 Masato Ishigaki December 15, 2021 融合情報学特別講義Ⅱ
2. 2 About me Masato Ishigaki - 石垣 雅人 部長 / VPoE 室 DMM.com エンジニアとして新卒入社 専門分野 - ソフトウェア工学 - スモールチームでの開発（アジャイル） 著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版 ,2020） 連載中 : 『スモールチームが武器になる時代へ』 @i35_267
3. 3 - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも 構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline
4. 4 - Target - エンジニア、事業責任者（ PdM） - サービスを作っていきたい、作っている。その事業分野で活躍したい。 - サービスを作っていくのにあたって、エンジニアリングをどこまで理解しておくべきか知りたい - エンジニアだが、ビジネス側をどこまで理解しておくべきか知りたい - Scope - Scope : - 事業とエンジニアリング , データ, KPIマネジメント, 仮説検証, A/B Test, スモールチーム - Scope out : - DHW, DataPipeline, etc… Outline
5. 5 - Expert - ソフトウェア（ハードは弱いです） - ソフトウェア工学 - Product Management - 事業戦略・戦術 - 事業の数値管理 / 予実管理 - データ分析→施策 - Human Management - 事業組織・エンジニア組織のマネジメント - 1on1を中心にしたメンタリング - エンジニア / デザイナー / プランナー 評価・育成 - 採用 - Project Management - Howを考える。どうやったらアジリティ高くプロダクトをデリバリーできるか - アジャイル・リーン,etc... Job description Photo by Markus Spiske on Unsplash
12. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも 構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 12
13. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 13
14. 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
15. 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
16. 16 - “ DX ” の正体 - すべての活動がデジタルによると「データ」として出力される。 - 事業 = サービスの振る舞いがデータとして記録され、ログデータとしてプロットできる。 - エンジニアリングが事業に影響する度合いが高まる。 - “DX”と叫ばれる昨今、DMMは事業をどのように捉えているのか - すべてを計測可能にしていく。 - 事業、組織、開発プロセスもあらゆるものを「データ」によってプロットしていくことからすべ てが始まる。 - すべてが物語りのように観測できるようになる。 - Observability（可観測性）の獲得 - 計測して観察できれば、改善はいくらでもコントロールできる - そこからデータを活用してプロセスの自動化（電子署名など行政や契約周りや事業で言 えばレコメンド等）などを改善活動をしていく。 ソフトウェアの複雑性を解きほぐすものは何か Isaac Smith on Unsplash
17. 17 - 事業を作るプロセスのプロットには、コツがある - ビジネスサイドとエンジニアリングサイドという「点」と「点」 - 事業規模関係なく、組織が大きくなれば、役割や責任箇所の分散によってセクショナリズ ムが起こりやすい構造になります。サービスをスケールさせていく過程で、組織として密 結合だったものが徐々に疎結合になっていく。 - 現場を見ると、その歯車がうまく噛み合っておらず、事業拡大によるビジネス側の機能要 求に対して、システムという歯車が耐えられない（技術負債）ことが多くある。 - “同期”と”連動” - 事業を構成するすべての歯車がすべて噛み合い、システムの進化が事業の進化を促進 させ、ビジネス側の進化にシステムが耐えられるようなエンジニアリング組織が必要にな る。 Pascal Swier on Unsplash ソフトウェアの複雑性を解きほぐすものは何か
18. 18 - エンジニアが、1行のコードから財務諸表を意識する世界線を作る - エンジニアが今が書いている 1行のコードあるいは、 1つのプルリクエストという ミクロな集合 体がプロダクトを作り、事業の収支を作っていることを財務諸表レベルで感じてほしい。 - セクショナリズムによる分断とそれによる主体性の欠如 - 事業・組織のスケールによって役割や責任箇所の分散によってセクショナリズムが起こりやすい。 Ex．エンジニアサイド、ビジネスサイド - エンジニアリングの領域に至っては、要求定義で決まっているものを「どう作るか」「作れるか」だけ にフォーカスした状態になりやすい。Howの部分にこだわり出して 手段の目的化の出来上がり。 - なぜ作っているか、作ったあとにどうなった？の意識的な欠如が起こる構造。 （ - - ）( ) { -- --- - - -- -- ; ( ----- -- ----- --) ----- -- ; } Engineering Developer Service 収益 費用 利益 P/L KPI Process 
 Cycle ソフトウェアの複雑性を解きほぐすものは何か
19. - 事業のスケールによる、エンジニアリングの犠牲の 誤解 - 品質に対するスピードとコストの 誤解。トレードオフじゃない。 - 事業責任者も、エンジニアも、そこから逃げてはいけない。 - 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ヶ月後 ソフトウェアの複雑性を解きほぐすものは何か
20. 20 引用 : Is High Quality Software Worth the Cost? A. 事業とエンジニアリングの点と点をつなげた意思決定ができる人材が大事。 最短、1ヶ月以内には、Bのほうが開発スピードで上回る。損益分岐点。負債・福利も、指数関数的に伸びる。 ソフトウェアの複雑性を解きほぐすものは何か
21. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 21
22. 技術のコモディティ化にエンジニアは敗北する - 世の中は、コモディティ化に溢れている - 消費者にとっては、個性がない状態へ。 - 需要があるものは、コモディティ化する。 - 牛丼、ガソリン、家電、etc... - すべてが平均的な価値になり、あとは価格競争へ。 引用 : https://hataraku.vivivit.com/works/commoditization 22
23. 技術のコモディティ化にエンジニアは敗北する - 技術も常に進化し、コモディティ化する - 新しい技術が登場し続ける、ソフトウェアの世界。 - Ex. コンテナ技術、k8s、Maschine Learning、NFT - 魅力的な技術であれば、沢山のプラクティスが出てくる。 - 技術の標準化・規約化が行われる。 - X as a Service / OSS として、サービス提供される。 - 昔は苦労して皆が実装していたものが、平等に利用可能な「武器」 になる ｔ 技術競争 価格競争 価値 コモディティ化 技術発展の S字カーブ ユーザーニーズ 引用 : https://muchinare.com/archives/13693034.html 23
24. - クラウドの発展が、コモディティ化を促進させた - 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
25. 25 技術のコモディティ化にエンジニアは敗北する - エンジニアもコモディティ化する - コモディティ化した技術を使う、エンジニアもコモディティ化する現象。 - ノーコードやローコードも今後さらに加速。 - 一部の天才を除いては「コードを書く」「サーバーを構築できる」というシンプルな スキルだけでは 勝てない世界（淘汰される） になってくる。 - では、エンジニアはどうするべきか。 - それは自分の仕事じゃないよね。というメンタリティーを破壊していく。 引用 : ［速報］AWS、ローコードでWebのフロントエンドを開発できる「AWS Amplify Studio」発表。
26. 26 技術のコモディティ化にエンジニアは敗北する ひとつの答えは、事業をスケールさせるエンジニアリングを学ぶこと - 技術を武器として、事業に「 観点」を与えることに力点を置く。 - 技術を使いこなした先にある、事業への「 問い」「解」を与える。 - 仮説検証への参加（何を→なぜ）。レコメンドアルゴリズムへの参加。 - 今まで、時間をかけていたものに時間をかけなくて良くなる。 - そのバッファーをどこに費やすか。
27. 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 エンジニアがアルゴリズムに対して「問い」と「解」を与えて、事業をエンジニアリングでスケールさせている
28. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも 構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 28
29. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも 構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 29
30. - 事業もエンジニアリングも 構造で捉える - システム理論で事業を捉える - あらゆる対象を「システム」として定義する - システムの3つの特徴 〜システムが形を成す過程〜 - 入出力からシステムは作られる - システムの階層性 - ミクロからマクロまでをズームイン / ズームアウト - 事業を「システム」として定義する - 何をインプットとするか - その中で、どんな処理が行われているか - 結果として何かアウトプットされるか - この3つをもって、Observabilityを高めていく 事業もエンジニアリングも構造で捉える 30
31. - 事業のナラティブ（物語）を「データ」を使って読んでいる - ユーザーの細かい挙動をトラッキングしていく - あらゆる挙動をトラッキングし、ログデータとして出力する - ログデータとして出力することで「データ」として表現できる - 一連の動作を「ログデータ」でプロットする - ユーザー行動を物語のように追うことができる - 事業をソフトウェアとして捉える = 記録できる - 細かく記録すればするほど可観測性が上がってくる - 柔軟なデータ分析や学習モデル構築も可能へ - 背景としては大規模データの並列処理基盤の進化 事業もエンジニアリングも構造で捉える 31
32. 事業をソフトウェアとして捉えたときのインパクト 1. ログデータを中心としたレコメンデーション 2. 財務諸表と1ユーザの行動までを繋げる 事業もエンジニアリングも構造で捉える 32
33. - ログデータを活用した Machine Learning が当たり前のプロダクトへ - 人は判別できない粒度で記録できる - 反復可能性 - 何度でも同じ観点で同じ動作を獲得できる。最近だとその計算リソースもクラウドで安易に。 - DMMだと、1日に数億レコードのログデータが格納され続けている。 - 推奨レコメンドエンジンによる、 ”ユーザー単位” での情報提供 - 商品レコメンド - サービスレコメンド - キャンペーン（広告配信） - 人は仮説を考え、観点を与えるだけで良くなる - 人力で人気商品などを考えて代入する必要はなし - 何を作るべきかを考えれば良い 事業もエンジニアリングも構造で捉える 33
34. ログデータを活用した Machine Learning が当たり前のプロダクトへ 〜DMMでの事例〜 34
35. - マクロ（財務諸表）からミクロ（ 1action）までを繋げる - 事業の最終的な出力は、財務諸表に表れてくることが大きい - P/L, B/S, C/F - 例えば、P/L（損益計算書） - どれだけ売上をあげて（売上高、原価を引いた粗利） - その中で、コストがかかり（販促費 ,etc..） - どのぐらいの利益がでたか（営業利益 ,etc..） - このP/Lの売上は、1ユーザー行動の合算である。 - 詳細に事業の可観測性をデータでプロットができれば、よりユーザーのことが理解でき る。 事業もエンジニアリングも構造で捉える 35
36. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 36
37. - KPIで事業を語る - 「データ」を使いながら事業改善を進めていくには共通言語が必要。 - KPIというアプローチ。構造で捉える x データで細かく分解できる - 最近では、ほとんど何をするにも KPIをもとに会話することが多い。 - Ex. この機能を作りたい。〇〇 KPIに効きそうだから。なぜなら ... - 感覚ではなく、事業構造 x データというエビデンスを元にした意思決定 - 事業構造の計算式が見えてくる - 事業の入出力に対するシステム処理パターン = 計算式が 見えてくる。事業の方程式が 見えてくる。 - 変数に対して代入すれば出力を予測できる - 可観測性が高ければ高いほど、より細かくツリーを要素分解できる KPIで事業を語る 37
39. ※ 実際はもっと複雑になります KPIで事業を語る 39
40. ※ 実際はもっと複雑になります KPIで事業を語る 40
41. - KPIを用いた事業改善は、操作可能変数を意識する - KPIツリーの中で操作可能変数 = 自分たちが操作できる変数を見つけて値 を代入する - 変数を代入したことによる KGIがどう変化するのかを観察する - Ex. クーポン単価 / プラットフォーム手数料 / 広告予算 - キードライバーを理解する - キードライバー（影響力の強い変数） - Ex. ユニットエコノミクスや先行指標となる KPI KPIで事業を語る 41
42. ユニットエコノミクス - 1人あたりの経済性 LTV CAC 42
43. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 43
44. - 事業の短命さと継続性 - 事業の寿命は無限ではない。 - 常に予算とリソースのタイムリミットを意識する必要がある。 - 不確実性が高い事業環境下のなか、イテレーティブな仮説と実験によって伸ばさなけれ ば、事業はすぐに死んでしまう。 作ったシステムもなくなってしまう。 - 天才 と 凡人 - 勝手に伸びることは、天才的なビジネスセンスがなければ、ほぼない。 - 私含めて、普通の人は「データ」を武器に戦わなくてはいけない。 - 大きなブレイクスルーよりも、 1%の改善を繰り返す。 仮説と実験で、転がしていく 44
45. - 正しい方向で、正しい戦術を、正しいリソースで - ただし、仮説と実験が大事だと言っても、闇雲に高速に開発して、リリースすれば良いわ けではない。 - 正しい方向で、正しい戦術で、正しいリソースを使いながら進む - 仮説と実験で、転がしていく - 正しい方向 = - KPI駆動からの事業戦略。 - 課題となるKPIを理解する = この事業を伸ばすための方向性・道標の明確化。 - 正しい戦術 = - 課題のKPIツリー（方向性）に対して、どういった施策を当てるのが良いのかの作戦。大 きな機能追加なのか、UI刷新なのか、キャンペーンなのか。 - 正しいリソース = - 戦術に対して、組織的なコスト（人・モノ・金）をどのぐらいのリソース配分で攻め込んで いくか。予算コントロールとプロジェクトマネジメント 正しい方向 正しい戦術 正しいリソース 仮説 と 実験 で転がしていく t 価値 仮説と実験で、転がしていく 45
46. - 予測値と実測値の不確実性をなくす - 目標値を設定する - KPIツリーと操作可能変数がわかったら、 - あとは目標値を設定して、その差分を埋めていく作業に入る。 - Ex. 売上KGIを1,000万円 → 2,000万円 - 仮説検証の繰り返しで、予測値と実測値のズレを検知する - 仮説検証は、この予測値と実測値のズレをなくすこと - 初期の仮説検証は、質よりも量を重要視する - トレードオフスライダーを作る - 計画に時間をかけない。 - まずは、高速に仮説検証プロセスを回す基盤を作り、仮説の学習を繰り返すことで 徐々に精度（採用率）が上がってくる 仮説と実験で、転がしていく 46
47. - 失敗の恐怖。PDCAのPを重視しない - 事業をスケールさせるには、改善施策を合理的に正しい方 向でどれだけ数 多く実行できるかが鍵になる。 - ハードルとなっているのが、失敗への恐怖心です。誰もが思う「失敗したくな い」 という壁が、あらゆる改善の実施に歯止めをかけている。それが組織とし て存在する - = 前段階にある計画の部分に時間をかける - 失敗をコントロールする - 失敗を”なくす”のではなく、事業構造を理解した上で失敗できる範囲（予算な ど）を明確にし、その影響範囲の中で適切に失敗をさせること 仮説と実験で、転がしていく
48. - A/Bテストによる”実験” - A/Bテストとは、元の機能に変更を加える際に Aパター ンとBパターンを用意し てテストする手法 - A/Bテストの意味は、「失敗をコントロール」すること - A/Bテストの比重と期間の考え方 - A/Bテストの比重については、統計学的な分析でサンプル数を満たす割合を 見極める必要 - 必ずAAテストを実施して、統計的誤差を正しく把握する - また、仮説検証の大きなによっては A/Bテストに向かないケースもある。 Ex. UIの大々的なリブランディング 仮説と実験で、転がしていく 48
49. 仮説と実験で、転がしていく 49
50. A（新） B（既存） 仮説と実験で、転がしていく 50
51. - 失敗例 - KPIツリーの分解不足による 注力箇所を間違える - 自分たちがこれぐらいで良いだろうという分解で、よくないことが多い - Ex. 新規は十分に取れているのに「友達招待キャンペーン」をやる等 - 結局、バケツの穴が空いている状態なので同じことになる。 - プロダクトの初期フェーズなので、まずは熱狂的なコアファンを作る - もっと分解すると、モバイルアプリであれば、ストア経由での流入が多いのか、広告経 由なのか、SNS経由なのか。分解できるところまで分解 → 定量化しないと、どこにリ ソースを突っ込めば良いかわからない。 n n n 利益 MAU 新規 定着 （既存） 復帰 × MAU - User Status 新規 定着 復帰 休眠 70% 20% 10% 8月 51 9月 10月 仮説と実験で、転がしていく
52. - 「KPI」と 「仮説と実験」はセットで考える。 - KPIツリーが分解 → ダッシュボードで数値管理　 →　目標値を設定。 - Ex. KGI（利益）を1,000万円 → 3,000万円 → どうやったらココにいけるか。そ の差分を埋めていく作業に入る。 - 正しい方向に対して、どのような戦術で攻めるか。 - 施策ごとに「予測値」と「実測値」をモニタリングしていく。 - 必ず、学習しないと同じ失敗を繰り返す - だいたい、施策の採用率 / 成功率 = 40 ~ 60% 52 どんな戦術 = 施策で攻めていくか 仮説と実験で、転がしていく
53. - 問いたい “ 仮説 ” と それを証明する “ 実験 “ - 仮説を証明するために、どういった戦術（施策）を組んで実行するかを考える際の大前提は「問 いたい仮説に対して、その戦術（施策）で、果たしてきちんと証明できるか」です。 - 失敗例 - 仮説に対する実験方法が違う = 施策に対する仮説や対象 KPIがない。 - 機能ベースで「これがあったら良い」と主観的に考えがちになる - Ex. 支払い手段を変更してもらいたい。それによって利益が上がる状態になる。 - 戦術として使えるのはポイント（電子マネー） - パット見の派手さ（バズる）で、山分け方式が案として上がる。 - → しかし、対象 KPIは継続性を求めるもの。 継続ポイント還元 CPが本来の戦術とし ては有効打。 - 対象KPIの理解が前提。 - 戦術バリエーションは他社事例や TTPSでカバー。 53 どんな戦術 = 施策で攻めていくか 仮説と実験で、転がしていく
54. 54 どんな戦術 = 施策で攻めていくか 仮説と実験で、転がしていく - 失敗例 - 仮説検証からの学習の部分が全然できていない - 仮説 → 施策 → 実施→結果→理解（認識）→次へ - 仮説 → 施策 → 実施→結果→理解（認識）→ 学習→ 次へ - ログが仕込まれてない → 検証 & 学習ができない - 実装してから気づくことが大きい。 - 実装までにトラッキングの設計が不十分。 - プロセスの整備が必要
55. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 55
56. - 実際の改善案 - BMLループのプロセスの浸透 1. Learn → Idea = 仮説を考える = 正しい方向 2. Build → Product = どう作るか = 戦術 3. Product → Measure = 計測する 4. Measure → Data = 計測してデータをつくる 5. Data → Learn = データから何を学ぶか - 逆回転からの順回転 - その仮説で証明したいことを確認（先に数値管理ダッシュボードを作成する）してから、 施策をBuildする BMLループで、学習プロセスを構築する 56
57. - どこに / どのぐらいのリソースを / どの期間突っ込むか - 正しいリソースの再配分をどうしていくか。 - プロダクトは、常に動き続けている。人も変化しつづける。 - 施策も、リファクタリングも、 UX改善も、個々の目標 / キャリアも、 n… - すべてを器用にこなしながら、走るしかない。 - BMLループでの学習サイクルを構築する - BMLループでの開発プロセス構築。 - チームのキャパシティーを計算して、施策の優先度と量を計算する。 - まずは、チームの戦闘力を知るところから。 57 Single Piece Flow（1つのサイクルで1つの仮説） BMLループで、学習プロセスを構築する
58. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 58
59. 59 チームの戦闘力すら計測して、可視化する 「事業もシステムもモニタリングできるなら、開発力もモニタリングできるはず」 - Layer 1. - コードレベルでのチーム生産性の可視化 - pull request , commit , commentから生産性の健全性を可視化 - Layer 2. - チーム開発のストーリーポイントを元にした生産性の可視化 - Velocity, Cumulative flow, Control Chart - Layer 3. - 開発プロセス全般（ MTGの間隔等々も加味した）のリードタイムの改善 - VSM（Value Streaming Mapping） それぞれで可視化をして、現状の戦闘力を知る
60. 60 Layer 1. Pull Request Layer 2. Cumulative flow チームの戦闘力すら計測して、可視化する
61. 61 引用：https://juas.or.jp/cms/media/2020/05/20swm_pr.pd チームの戦闘力は、世の中と比較して高いと言い切れるか 三乗根に2.7をかける チームの戦闘力すら計測して、可視化する
62. 62 - 組織はスループットではなく、レイテンシを上げる - スループット - 時間あたりの処理能力 - 1回の処理でどのぐらいのデータを送ったりできるか。高ければ高いほど性能が良いということになる。 ただし、一度にたくさんのデータを送ったりするとレイテンシーが低くなる。 - レイテンシ - 応答が返るまでの時間 - 通信の遅延時間 - 組織はスループットではなく、レイテンシを意識する - 1回の処理でどれだけ詰め込めるかではなく、 1回の応答時間をどれだけ短くできるかが大事になってく る - 特にログデータを軸に A/Bテストを繰り返すような開発では、イテーティブさやアジリティーが必要になっ てくるため、いかに早くユーザーフィードバックをもらうかが必要となる。 - 事業改善を進めるには、スモールチームでの活動が前提となりつつある input output レイテンシ スループット チームの戦闘力すら計測して、可視化する
63. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline 63
64. 出荷 出荷 スモールチームと技術の力学 ウォータフォール 出荷。 出荷後に顧客の反応を見て、 いちごのホールケーキから違うホールケーキにするのは難しい。 出荷。 残りショートケーキは、ユーザーのフィードバックによって どんどんトッピングを変えていける。ベースの部分の変更は難しいことが多い。 結合 チーム C チーム A チーム B チーム A x n アジャイル できるだけ バッチサイズを小さく。 64
65. 65 スモールチームと技術の力学 - チームサイズのスパン・オブ・コントロール - 主にエンドユーザー向けのサービス開発現場において主流となったアジャイル開発は、 できる限りプロダクトチームに オーナーシップを持たせます。 - オーナーシップとは、権限と裁量、責任、自律性です。 独立したプロセスで意思決定を早 めながらプロダクト開発の不確実性に対応できるようにするためです。 - チームサイズにも注目すると、 Amazonが提唱している「ピザ 2枚ルール」や、イギリスの 人類学者であるロビン・ダンバーによる「ダンバー数」 - 「ピザ2枚ルール」・・・効率とスケーラビリティの観点で、社内のすべてのチームは 2枚の ピザを食べるのにピッタリな人数でなければいけない。 - 「ダンバー数」・・・人類学的に3～5人「社会集団（クリーク）」が最も親密な友人関係を築 ける人数である。 The two-pizza rule 5 15 35 150 500 1500 Dunbar’s Number
66. 66 スモールチームと技術の力学 - プロダクト開発が、1つのチームで完結する - クラウドサービスを中心に技術のコモディティや 2009年あたりのDevOps, マイクロ サービスの再評価によって、 1つのチームで1つのプロダクトという形が多くなった。 - また、サービス規模が拡大したとしても、人数でスケールすることもなくなった。 - Instagram - プロダクトローンチから、わずか 9ヶ月でFacebookに10億ドルで買収された話は有 名ですが、驚くべきは社員が 13人であったこと。 - かつ当時のユーザー数は、既に 3,000万人いたことから、数名のエンジニアチーム でその規模のトラフィクを捌いていた。 - それを成せたのも、スモールチーム x 技術の部分でのスケーラビリティを支える融 合があってこそだったでしょう。 引用: https://www.nikkei.com/article/DGXBZO40332590R10C12A4000000/
67. 67 - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る Outline
68. - 視座を上げて、視野を知る - 不確実な世界で、何をすれば良いのかは不透明。 - まずは、武器を増やすことに注力する。 - 視座を上げていくと、今までにないスキルが見えてくる。 - 課題がないのではなく、見えていないが正解。 - 一定の視座だと、成長曲線がゆるくなる。 不確実な世界に立ち向かうためのキャリア戦略 視野 視座 事業 チーム 個 深さ / 広さ 経営 Ex. 開発 Ex. データ分析 Ex. 財務諸表 Ex. マーケティング Ex. PM ベクトル（視点） 68
69. - GRITを底上げする - 色んなキャリアパスを選択する前に、 GRIT（Guts / Resilience / Initiative / Tenacity）和訳だと「やり抜く力」を上げていく。 - 何事も執念や、承認欲求とか、好奇心とか、プライドとか、コンプレックスとか、 そういう根底にある強い感情をフックにやり抜く力が大事。 - 1on1で、個々のGRITはどこかを探っていく。そこからベクトルを探る。 - 目標を決めさせない選択肢 - 不確実性が高いと、目標が決めづらい - 本来、目標設定はモチベーション向上のために設定するもの - 「何を達成したいか」ではなく「どういう状態でいたいか」 69 不確実な世界に立ち向かうためのキャリア戦略
70. - 採用は最高の技術投資だが、最悪の技術投資にもなり得る - 人も技術投資と考えると、特に良いエンジニアの採用は、最高の技術投資になる。 - 年収1000万のエンジニアを5人抱えると、ざっと年間 5,000万の技術投資。 - 一方、事業を成り立たせるために必要な技術投資の中でも単純な技術投資と違っ て、人は不可逆性が高すぎる。 - このツール使いづらいから来月から契約終了しようといったことは、ツールはできて も、人（特に正社員）だと難しい。 - 最近のエンジニア採用市場 - 良いエンジニアを取り合っている状態。 - 一方、新卒採用に関して、ある程度のクオリティーのものは、パッケージ化されたもの で簡単にできる。技術のコモディティ化の文脈 - きちんと、エンジニア +αを考える 70 不確実な世界に立ち向かうためのキャリア戦略
71. - Ph.1 : すべてがソフトウェア化する世界 - Why Software Is Eating The World - ソフトウェアの複雑性を解きほぐすものは何か - 技術のコモディティ化とエンジニアのコモディティ化 - Ph.2 : 事業とエンジニアリングを繋ぐ力学 - 事業もエンジニアリングも 構造で捉える - KPIで事業を語る - 仮説と実験で転がしていく - BMLループで、学習サイクルを構築する - チームの戦闘力すら計測して、可視化する - スモールチームと技術の力学 - Ph.3 : 不確実な世界に立ち向かうためのキャリア戦略 - 視座を高くして、視野を知る - GRITを底上げする - 採用は最高の技術投資だが、最悪の技術投資にもなり得る 71 まとめ