事業をスケールさせるエンジニアたち 〜技術のコモディティ化にエンジニアは敗北する〜 Developers Boost 2021 基調講演 1 Masato Ishigaki October 20, 2021

2 - Target - エンジニア, プロダクトマネージャー , 事業責任者,etc... - Outline - 技術のコモディティ化にエンジニアは敗北する（課題提起） - エンジニアリングを武器に事業のスケールに注力したエンジニアたちの 「5つの特徴」 - 不確実な世界に立ち向かうためのキャリア戦略 Outline

3 About me Masato Ishigaki - 石垣 雅人 部長 / VPoE室 DMM.com エンジニア 新卒入社 2017年より、DMMにおけるアカウント(ID)、認証(Auth) のバックエンド周りのプロダクトオーナーを 経て、2018年7月にリードナーチャリング領域を強化するチームやDMMの入り口である総合トップ などを管轄する総合トップ開発部の立ち上げを行い、部長を務める。 現在は、DMMポイントクラブの立ち上げからグロース、ID・認証を司るメンバーシップサービス部の 部長、DMM全体のエンジニア・デザイナー組織課題を解決するVPoE室を兼務している。 著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版 ,2020） @i35_267

4 - Outline - 技術のコモディティ化にエンジニアは敗北する（課題提起） - エンジニアリングを武器に事業のスケールに注力したエンジニアたちの 「5つの特徴」 - 不確実な世界に立ち向かうためのキャリア戦略 Outline

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

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

7 技術のコモディティ化にエンジニアは敗北する - クラウドの発展が、コモディティ化を促進させた - 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

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

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

10 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 エンジニアがアルゴリズムに対して「問い」と「解」を与えて、事業をエンジニアリングでスケールさせている

11 - Outline - 技術のコモディティ化にエンジニアは敗北する（課題提起） - エンジニアリングを武器に事業のスケールに注力したエンジニアたち「 5つの特徴」 - 不確実な世界に立ち向かうためのキャリア戦略 Outline

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

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

エンジニアリングを武器に事業のスケールに注力したエンジニアたち 14 引用 : Is High Quality Software Worth the Cost? A. 事業とエンジニアリングの点と点をつなげた意思決定ができる人材が大事。 最短、1ヶ月以内には、Bのほうが開発スピードで上回る。損益分岐点。負債・福利も、指数関数的に伸びる。

15 エンジニアリングを武器に事業のスケールに注力したエンジニアたちの 「5つの特徴」 1. 事業もエンジニアリングも 構造で捉える 2. KPIで事業を語る 3. 仮説と実験で、転がしていく（仮説実験主義） 4. BMLループでの学習サイクルを構築する 5. チームの戦闘力もデータ化する

エンジニアリングを武器に事業のスケールに注力したエンジニアたち - 事業もエンジニアリングも 構造で捉えている - DXの正体 - すべての活動がデジタルによると「データ」として出力される。 - 事業 = サービスの振る舞いがデータとして記録され、ログデータとしてプ ロットできる。 - エンジニアリングが事業に影響する度合いが高まる。 - 事業のナラティブ（物語）を「データ」を使って読んでいる - 何をインプットとするか - その中で、どんな処理が行われているか - 結果として何かアウトプットされるか 16 特徴1.

エンジニアリングを武器に事業のスケールに注力したエンジニアたち - KPIで事業を語る - 「データ」を使いながら事業改善を進めていくには共通言語が必要。 - KPIというアプローチ。構造で捉える x データで細かく分解できる - 最近では、ほとんど何をするにも KPIをもとに会話することが多い。 - Ex. この機能を作りたい。〇〇 KPIに効きそうだから。なぜなら ... - 感覚ではなく、事業構造 x データというエビデンスを元にした意思決定 17 特徴2.

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

- 仮説と実験で、転がしていく。 - ただし、仮説と実験が大事だと言っても、闇雲に高速に開発して、リリースすれ ば良いわけではない。 - 正しい方向で、正しい戦術で、正しいリソースを使いながら進む - “ 正しさ“ - 正しい方向 = 戦略・ベクトル（KPI） - 正しい戦術 = - 課題のKPIツリー（方向性）に対して、どういった施策を当てるのが良 いのかの作戦。大きな機能追加なのか、 UI刷新なのか、キャンペーン なのか。 - 正しいリソース = - 戦術に対して、組織的なコスト（人・モノ・金）をどのぐらいのリソース 配分で攻め込んでいくか。 19 正しい方向 正しい戦術 正しいリソース 仮説 と 実験 で転がしていく t 価値 エンジニアリングを武器に事業のスケールに注力したエンジニアたち 特徴3.

- 正しい戦術 - KPIとセットで考えていく。 - 問いたい “ 仮説 ” と それを証明する “ 実験 “ - 施策ごとに予測値と実測値をモニタリングしていく。 - 課題KPIの現状と目標値の差分を埋めていく作業 - 必ず、学習しないと同じ失敗を繰り返す - だいたい、施策の採用率 / 成功率 = 40 ~ 60% 20 どんな戦術 = 施策で攻めていくか エンジニアリングを武器に事業のスケールに注力したエンジニアたち 特徴3. A(新) B (既存)

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

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

23 エンジニアリングを武器に事業のスケールに注力したエンジニアたち Layer 1. Pull Request Layer 2. Cumulative flow 特徴5.

24 エンジニアリングを武器に事業のスケールに注力したエンジニアたち 特徴5. 引用：https://juas.or.jp/cms/media/2020/05/20swm_pr.pd チームの戦闘力は、世の中と比較して高いと言い切れるか 三乗根に2.7をかける

25 エンジニアリングを武器に事業のスケールに注力したエンジニアたちの 「5つの特徴」 1. 事業もエンジニアリングも 構造で捉える 2. KPIで事業を語る 3. 仮説と実験で、転がしていく（仮説実験主義） 4. BMLループでの学習サイクルを構築する 5. チームの戦闘力もデータ化する

26 - Outline - 技術のコモディティ化にエンジニアは敗北する（課題提起） - エンジニアリングを武器に事業のスケールに注力したエンジニアたちの 「5つの特徴」 - 不確実な世界に立ち向かうためのキャリア戦略 Outline

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

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

- Outline - 技術のコモディティ化にエンジニアは敗北する - エンジニアリングを武器に事業のスケールに注力したエンジニアたちの 「5つの特徴」 - 不確実な世界に立ち向かうためのキャリア戦略 まとめ 29