How to measure Developer Productivity. 〜可観測性と再現性〜 1 Masato Ishigaki May 25, 2023 特別講演

2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム事業本部 部長 / VPoE室 / アルファ室 ・略歴 : エンジニア新卒入社 → PjM → PdM / EM → 部長 + 横断 （URL） ・管轄 : ID基盤 / CS-Platform / DMMポイントクラブ / ユーザーレビュー基盤 ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020） ・連載 : 『スモールチームが武器になる時代へ』（ProductZine） @i35_267 @i35_267 @i35_267

3 - Ph.1 : すべてがソフトウェア化する世界 - 社会工学とソフトウェア - “ DX ” = “ 可観測性 “ - リードタイムの変化 - ITプロジェクトの現状 - Ph.2 : How to measure Developer Productivity - 4つのMetrics - 事業 / プロダクト / システム / チーム - 再現性 Outline

4 - Ph.1 : すべてがソフトウェア化する世界 - 社会工学とソフトウェア - “ DX ” = “ 可観測性 “ - リードタイムの変化 - ITプロジェクトの現状 - Ph.2 : How to measure Developer Productivity - 4つのMetrics - 事業 / プロダクト / システム / チーム - 再現性 Outline

5 社会工学とソフトウェア 引用 : https://future.a16z.com/software-is-eating-the-world - 社会システムのソフトウェア化 - 人々の体験とビジネス上の価値を「ソフトウェア」が繋ぐ世界へ - 多様なビジネスモデルに対するテクノロジー的アプローチの登場 - web / mobile / vr / blockchain / metaverse / agi（artifical general intelligence） - 逆を返せば、ソフトウェアの設計・在り方が多大な影響を及ぼす時 代へ マーク・アンドリーセン ｚ Ph.1

6 - 社会工学的デザイン （社会的な振る舞い） におけるソフトウェアの重要性と複雑性 - インターネットバンキングのソフトウェアに問題があれば、家賃が払えない。 - 医療機器に問題があれば命が危機に晒される。 - Googleサービスが全て落ちたら ...etc - 引用 : チームトポロジー | マシュー・スケルトン,マニュエル・パイス (著) | https://www.amazon.co.jp/dp/4820729632/ - ソフトウェアの設計・実装・運用のエンジニアリングの重要性が増している 社会工学とソフトウェア Ph.1

- “ DX ” の正体とは、一般システム理論の実現 - すべての活動がデジタルによると「データ」として出力される - 事業 = サービスの振る舞いがデータとして記録され、ログデータとしてプロットできる - “ 一般システム理論 ” の実現 - 事業のKPIツリーで、1人あたりの収益性など細かい表現がデータによって可能になる - ソフトウェアが、事業の複雑性・ブラックボックスを解きほぐす - 科学的アプローチが、ビジネスに適応可能へ - 可観測性（o11y）が可能に。対象物を観測可能にしていくアプローチ（ Log・Metrics・Trace） - 法則を見出し、推論を論じ、仮説を立て、フィードバックでエントロピーを下げる（ A/Bテスト等） - データがログとして現れることによって、再現性が生まれる 7 “ DX ” = “ 可観測性 “ 入力 input 出力 output フィードバック feedback 事業モデル 構造 補足 : サイバネティクスの「開放システム」 Ph.1

8 開発リードタイムの変化 - コモディティー化とXaaS - 魅力的な技術が登場すれば、沢山のプラクティスが出てくる。 - X as a Serviceや周辺エコシステムとして、サービス提供される。 - クラウドサービスや決済サービス、 etc… - 昔は苦労して皆が実装していたものが、平等に利用可能な「武器」になる - 技術は常に進化して、コモディティー化する - すると、世の中の開発速度は格段とスピードアップする 技術競争 価格競争 価値 コモディティ化 技術発展のS字カーブ ユーザーニーズ h Ph.1

9 - Full Cycle Developers at Netflix Operate What You Build - 構築したものを運用する - “Operate what you build” puts the devops principles in action by having the team that develops a system also be responsible for operating and supporting that system. - サイロを破壊し、学習とフィードバックを最適 - We could optimize for learning and feedback by breaking down silos and encouraging shared ownership of the full software life cycle - 豊富な開発者ツールによるスケール - Ownership of the full development life cycle adds significantly to what software developers are expected to do. Tooling that simplifies and automates common development needs helps to balance this out. 引用 : https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 開発リードタイムの変化 Ph.1

10 - スモールチームが前提のプロダクト開発へ - XaaS / エコシステム / フレームワークが充実 - 安価で早く、スケールしやすいシステムが簡単に - 人件費と開発スピードは、比例しにくい（マネジメントスキル次第） - 市場への投入タイミングの激化と開発組織の変化 リリース9ヶ月でインスタは 既に3,000万会員 開発リードタイムの変化 Ph.1

引用 : 企業IT動向調査報告書 図表 7-3-1 プロジェクト規模別・年度別 システム開発の工期遵守状況 (https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf) 11 ITプロジェクトの現状 「工期」「予算」「品質」の3つのカテゴリーで分け、 プロジェクト規模を「100人月未満」「100〜500 人月未満」「500人月以上」で分類したデータ 工数 : 34.4% 予算 : 37.0% 品質 : 23.0% 3つの割合の平均 = 31%前後になります。何かしらの原因で満足いかない可能性が 約69% さらに、工数・予算・品質のすべてが予定通りに終わる確率は、工期（ 34.4％）× 予算（37.0％）× 品質（23.0％）で 約3% Ph.1

12 引用 : 企業IT動向調査報告書 図表 7-3-4 予定どおりにならなかった要因(複数回 答)(https://juas.or.jp/cms/media/2022/04/JUAS_IT2022.pdf) [仮説推論] 計測と学習が足りていない 何度も、同じ失敗をしている 原因は、計画・仕様・システムの不確実性 Ph.1

13 “ 「不確実性が高い」という言葉を 計画, 計測, 学習を適切に行っていない言い訳にしない”

14 - Ph.1 : すべてがソフトウェア化する世界 - 社会工学とソフトウェア - “ DX ” = “ 可観測性 “ - リードタイムの変化 - ITプロジェクトの現状 - Ph.2 : How to measure Developer Productivity - 4つのMetrics - 事業 / プロダクト / システム / チーム - 再現性 Outline

４つのMetrics 4. チームの戦闘力 （生産性） 2. プロダクトの戦闘力 （魅力） 1. 事業の戦闘力 （価値） 3. システムの戦闘力 （装置） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… 価値 - 売上（P/L） - 競争優位性（シェア率） - KGI / KPI モノとしての魅力 - UIの心地よさ（離脱率） - UXの体験の良さ - 機能の優位性 - VOCデータ - ,etc.. システム - SLO / SLI（稼働率） - レイテンシー - Crash Free Rate - ,etc… マクロ ミクロ 観測可能範囲 Log / Metrics / Trace 15

16 どんな戦略・戦術で攻めていくか 損益計算書（PL） 事業の戦闘力 （価値） 価値 - 売上（P/L） - 競争優位性（シェア率） - KGI / KPI 入力 input 出力 output フィードバック feedback 事業モデル 構造 ｚ Ph.2 ブレークダウン

17 プロダクトの戦闘力 （魅力） モノとしての魅力 - UIの心地よさ（離脱率） - UXの体験の良さ - 機能の優位性 - VOCデータ ｚ Ph.2

18 システムの戦闘力 （装置） システム - SLO / SLI（稼働率） - レイテンシー - Crash Free Rate ｚ Ph.2

19 チームの戦闘力 （生産性） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… 1. コードを書く → レビュー → Approve → CI → マージ a. ソースコードのホスティングサービスベースでの可視化 b. 機能開発だけにフォーカスした数値 c. Metrics : i. プルリク→マージまでの時間、etc… 2. プロジェクトとしてのバリューストリーム a. 工数・工期。ソフトウェアライフサイクル b. 勤怠ツールと連動 c. Metrics : i. 開発比率/ 非開発比率 / 運用保守 プロジェクトA Ph.2

2 0 - チームや組織ごとにサイロ化せずに中央集権型にしてログに残す - チーム横断で学習と予測に使う チームの戦闘力 （生産性） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… ・ソースコード ・勤怠（工数管理） Ph.2

21 チームの戦闘力 （生産性） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… Ph.2

チームの戦闘力 （生産性） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… 勤怠管理ツール → BigQuery（DWH） → Looker（ビジュアライズ） Ph.2

23 チームの戦闘力 （生産性） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… プロジェクトA - 再現性 - プロジェクトの規模感、属性によっての差分がログとして残る - 過去プロジェクトのログから再現性が作れるので、工数見積もりや注意点回避によるコストマネジメントが可能 Ph.2

Metricsのミクロとマクロを繋げていく チームの戦闘力 （生産性） プロダクトの戦闘力 （魅力） 事業の戦闘力 （価値） システムの戦闘力 （装置） 総工数（Ex.120人月） - 有効稼働率 - リードタイム - ,etc… 価値 - 売上（P/L） - 競争優位性（シェア率） - KGI / KPI モノとしての魅力 - UIの心地よさ（離脱率） - UXの体験の良さ - 機能の優位性 - VOCデータ - ,etc.. システム - SLO / SLI（稼働率） - レイテンシー - Crash Free Rate - ,etc… マクロ ミクロ 観測可能範囲 Log / Metrics / Trace

25 - Ph.1 : すべてがソフトウェア化する世界 - 社会工学とソフトウェア - “ DX ” = “ 可観測性 “ - リードタイムの変化 - ITプロジェクトの現状 - Ph.2 : How to measure Developer Productivity - 4つのMetrics - 事業 / プロダクト / システム / チーム - 再現性 まとめ