「開発生産性を上げる改善」って儲かるの？に答えられるようにする / Is development productivity profitable?

by Masato Ishigaki / 石垣雅人

Slide 1

Slide 1 text

「開発生産性を上げる改善」って儲かるの？  に答えられるようにする  ── “信頼”と”儲かる”を実現する開発生産性の改善──     1 Masato Ishigaki  June 29, 2024 

Slide 2

Slide 2 text

2 About me  石垣雅人  合同会社 DMM.com     ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版）   ・連載中 : 『開発生産性の多角的視点』（CodeZine）   ・連載中 : 『スモールチームが武器になる時代へ』（ProductZine）   ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方』（NewsPicks）   

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

4 - 「開発生産性の改善」のその先  - 開発生産性は”信頼”を作ることに価値がある  - 開発生産性という言葉の勘所 ①〜③  - 開発生産性の正確性と立体感  - 開発生産性を上げることで「儲かる」のカラクリ  Table of Contents 

Slide 5

Slide 5 text

5 - 「開発生産性の改善」のその先  - 開発生産性は”信頼”を作ることに価値がある  - 開発生産性という言葉の勘所 ①〜③  - 開発生産性の正確性と立体感  - 開発生産性を上げることで「儲かる」のカラクリ  Table of Contents 

Slide 6

Slide 6 text

「開発生産性の改善」のその先  最近の時流  - 開発生産性を上げるノウハウは集まってきた  ・Four keysやSPACEの文脈や付加価値生産性の文脈  ・改善策のプラクティスが広がってきた状態  6

Slide 7

Slide 7 text

「開発生産性の改善」のその先  - 次のフェーズは「実行」に移せる現場を増やせるか  - ・炎上案件で忙して開発生産性に割く工数がない  - ・うちの会社はそういうのにお金を出してくれない。  - という壁からの脱却。  - その投資の対して効果をエンジニアが説明責任を果たさないといけない      7

Slide 8

Slide 8 text

8 ここの生産量を目的にすると駄目。  グットハートの法則に陥る  数値が状態を作るわけではなく、  状態が数値を作る    in  ヒト・モノ・カネ  out  生産される  改めて。生産性のin/outと勘所  生産活動 

Slide 9

Slide 9 text

目的は、生産量（生産効率）を武器として付加価値を見る。  生産性の改善はアウトプット量ではなく、プロセスの改善へ  価値創造の武器としての生産量 / 生産効率である  9 out  生産される  エンドユーザー 

Slide 10

Slide 10 text

価値創造への主体性と開発生産性  ── 責務とコミット──     10 付加価値生産性と物的生産性（とアジャイル）  ・エンジニアも「付加価値生産性」にコミットしつつも、アジャイルサイクルの原資となっている「物的生産性（回転数）」に責務を持つ  ・回転数 = 不確実性への生産証明として、曝露（Exposure）の回数を増やす。  引用 : 大規模言語モデル時代の開発生産性（広木さん）          

Slide 11

Slide 11 text

11 - 「開発生産性の改善」のその先  - 開発生産性は”信頼”を作ることに価値がある  - 開発生産性という言葉の勘所 ①〜③  - 開発生産性の正確性と立体感  - 開発生産性を上げることで「儲かる」のカラクリ  Table of Contents 

Slide 12

Slide 12 text

獲得したい価値  ● 開発生産性に関するデータは  ● “信頼”を作るための糸口で使う  ヒトは感情で動くもので、相手の「意志」を理解しながら説明責任を果たしていく。   ただ、感情だけで訴えても駄目なが多いので、開発生産性のデータもセットで会話しにいく  

Slide 13

Slide 13 text

本来、信頼が積み上がれば  開発生産性は気にならなくなる  13 - 管理・監視という意味合いでは可視化は不要になる（にする）  - 興味は戦略的にタイミングでモノが出てくる開発組織かどうか    - エンジニアが自分たちのため（ケイパビリティ）に開発生産性を考えるのが本来は正しい 

Slide 14

Slide 14 text

14 すれ違いの発生箇所  事業 / 経営  - エンジニアの見積もり（予測）を信じて、計画を作る  - なのに毎回遅れる。ただ、なぜ遅れるのかはわからない  - リカバリーのための人件費（エンジニア、PM）を投入  - ここが操作可能変数のため 

Slide 15

Slide 15 text

15 すれ違いの発生箇所  開発組織  - 見積もり（予測）は、大小外れるものという共通認識がある  - 遅れた事実は数値化しやすいが、“なぜ遅れたか”は数値化しにくい  - 予算を使い大量投入されても、”人月の神話” 状態  - 根本的に内部品質の改善に時間をかけたいが時間がかかるので後回しになってしまう   

Slide 16

Slide 16 text

16 双方の悩み 

Slide 17

Slide 17 text

こういうことがあると    🙎どうやったら内部品質改善に時間が取れるだろうと考える。    🙅きちんと改善作業を定量的に落とし込まないとバックログに積まれてこない    🙋 開発生産性を上げる = 売上利益への貢献度合いへ落とし込みたい    → 机上の空論から抜け出せない      開発チームの悩み事  17

Slide 18

Slide 18 text

👀 “隠れた失敗”があとから発覚したり、直前になって「間に合いません」という報告が来たり、納得が行く説明が行われないと信頼が落ちていく    → 開発組織の”生産性”どうなってるの？という話に      🙋 でも本当に知りたいのは、シンプルに狙ったタイミングでモノが出てくる開発組織なのか、そうじゃないのか。  事業責任者側の悩み事  18

Slide 19

Slide 19 text

19 ”隠された失敗”が増えると....    1. 優先度を細かく決めないといけなくなる  a. そうしないと意図通りにモノがでてこない  2. 細かく管理しないといけなくなる  a. ホフスタッターの法則があるか  3. 遅れを取り戻す、追加コスト / 調整コストがかかる  a. オンボーディングコスト（ブルックスの法則）  b. 採用コスト（採用業務 + 追加人件費） 

Slide 20

Slide 20 text

20 信頼ポイント  の作り方 

Slide 21

Slide 21 text

this is exactly the problem with "refactoring the code".   In many cases it means doing a really important work, but it's indistinguishable from almost-slacking-off, like renaming variables for no apparent reason.  And this is what I mean by "don't refactor the code": use different words when talking about things you did, are doing or plan to do. Don't "refactor". Instead try these:  「リファクタリングをしたいです」という言葉を使わない  - リファクリングは良いことなので許容するが何をしているかはあまりわかっていない   - かつ、リファクタリングには終わりがないので「いつまでやるの？」状態で工数を取っていく   信頼ポイント - リファクタリング  ──言葉の丁寧さ──  21

Slide 22

Slide 22 text

信頼ポイント - 見積もり  ──傾向値の提供──  ○ 見積もりの予測と実際の乖離が生まれる閾値の共有     引用: IPA 「IT企業4,564プロジェクトプロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果」   計画より上回っている   計画より下回っている   22

Slide 23

Slide 23 text

信頼ポイント - リファクタリング  ──外部データの提供──  論文 :   “Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases” (https://arxiv.org/abs/2203.04374)    低品質のコードは高品質のコードに比べて、  - 欠陥数の増加：  - 「15倍」ある  - 問題解決時間の延長：  - 問題を解決するには平均で「124%」  - 予測不可能性の増加：  - 問題解決には最大で「9倍」も長いサイクルタイム  23

Slide 24

Slide 24 text

24 ただ、一番の信頼積み上げは、    言葉の“定義”を定めて「特性と構造」を伝える 

Slide 25

Slide 25 text

25 - 「開発生産性の改善」のその先  - 開発生産性は”信頼”を作ることに価値がある  - 開発生産性という言葉の勘所 ①〜③  - 開発生産性の正確性と立体感  - 開発生産性を上げることで「儲かる」のカラクリ  Table of Contents 

Slide 26

Slide 26 text

開発生産性という言葉の勘所  26 必ず、言葉の定義を定める必要がある    ① どこのフローの話？  ② どのプロセスの話？  ③ どのレイヤーの話？  ④ 生産性を上げて何がしたい？ 

Slide 27

Slide 27 text

開発生産性という言葉の勘所 ①  ── どのフローの話？──   27 - 🙋 いつリリースされるの？なんか遅くね？  - ┗ リードタイムの議論    - 🙋 開発組織にかけるコストの投資対効果あってる？  - ┗ スループットの議論（予算に対する生産）  ┗ エンジニアが不足しているのか多すぎなのか  リードタイム  スループット 

Slide 28

Slide 28 text

開発生産性という言葉の勘所②  ── どこのプロセスの話？──   28 https://www.kaufmanglobal.com/glossary/lead-time/   自分の操作可能なプロセスしか見ていないかもしれない   スケジュールが厳しいと後ろの工程がしんどくなる（BM→PdM→Des→Dev→QA）  

Slide 29

Slide 29 text

開発生産性という言葉の勘所 ③  ── どのレイヤーの話？──   29 開発組織    経営層  CxO・役員  （経営企画 / 経理）   Eng Des Eng Eng Des BM BM 経理経営 Eng EM PM/Dir PdM PdM 横断組織事業責任者  PdM  P/L 販管費 cost（⾦額） cost（⾦額） man-month（⼯数）スループット（1⼈⽉あたりの⽣産性） man-month（⼯数） B/S 資産 / 減価償却組織のレイヤーごとに  開発生産性の意味が違う 

Slide 30

Slide 30 text

- クリエイター目線の期待値  - ┗ GitHub Copilot、Figma AIを使いたい。テストを早くしたい。  - ┗ フロー状態を長くしたい。技術負債を無くしたい。  - PdM / EM目線の期待値  - ┗ 予定どおりに仮説検証したい。  - ┗ 開発プロセスのリードタイムを短縮したい。  - 事業 / 経営目線の期待値  - ┗ （良いもの >）早く > 安くを出したい。場合によってはソ購入も。  30 開発生産性という言葉の勘所 ④  ── 生産性を上げて何がしたい？──  

Slide 31

Slide 31 text

開発生産性という言葉の勘所  31 必ず、言葉の定義を定める必要がある    ① どこのフローの話？ → リードタイム・スループット  ② どのプロセスの話？ → スコープの認識  ③ どのレイヤーの話？ → 出力単位の変換  ④ 生産性を上げて何がしたい？ → 期待値 

Slide 32

Slide 32 text

32 - 「開発生産性の改善」のその先  - 開発生産性は”信頼”を作ることに価値がある  - 開発生産性という言葉の勘所 ①〜③  - 開発生産性の正確性と立体感  - 開発生産性を上げることで「儲かる」のカラクリ  Table of Contents 

Slide 33

Slide 33 text

▼ オブザーバビリティー（ソフトウェアの状態）  ┗ サービス監視ツール・・・Datadog, NewRelic  ┗ クラウドサービス・・・AWS, GCP, Azureサービス   ┗ CI / CD・・・GitHub Actions, Circle CI, Argo CD   ▼ 個・チーム生産性（個・チームの状態）  ┗ コード・・・GitHub, AI（Copilot）, SonarQube   ┗ チームパフォーマンス・・・Findy Team+, Offers MGR   ┗ バックログ・・・JIRA, ZenHubのレポート（Burndown Chart, Control Chart）   ┗ フロー状態・・・Googleカレンダーデータ（ミーティング）   生産性に影響しそうな変数は沢山取れる  33 ▼ P/L（予算のコスト）  ┗ 人件費（ソフトウェア仮勘定）  ┗ 減価償却費  ┗ 採用費（フィー）  ┗ 通信費（サーバー費用等）  ┗ ライセンス費,etc.. 

Slide 34

Slide 34 text

どの変数も正確なソフトウェアの状態、  チームの状況を表すものではない。  あくまでも傾向値・近似値。    組み合わせと傾向（多変量的アプローチ）で  確かさを掴んでいく。    開発生産性の正確性  34

Slide 35

Slide 35 text

  個と個の集団であるチームの数値  そのチームが作るシステム・プロダクトの数値  そのチームとプロダクトを運用するための予算（お金）    に＋して、先ほどのフロー・プロセス・レイヤー・期待値    を立体的に捉えていく      開発生産性の立体性  35

Slide 36

Slide 36 text

事業責任者  PdM  Eng Des Eng Eng Des BM BM 経理経営 Eng EM PM/Dir PdM PdM 横断組織 36 開発組織    経営層  CxO・役員  （経営企画 / 経理）   人数サイズ  予算権限 

Slide 37

Slide 37 text

事業責任者  PdM  Eng Des Eng Eng Des BM BM 経理経営 Eng EM PM/Dir PdM PdM 横断組織 37 開発組織    経営層  CxO・役員  （経営企画 / 経理）   人数サイズ  予算権限  ▼ P/L（予算が操作可能変数）  ┗ 人件費（ソフトウェア仮勘定）   ┗ 減価償却費  ┗ 採用費（フィー）  ┗ 通信費（サーバー費用等）   ┗ ライセンス費,etc..  ▼ 個・チームの生産性  ┗ コード  ┗ チームパフォーマンス  ┗ バックログ  ┗ フロー状態    ▼オブザーバビリティー  ┗ n ...    スループット（1⼈⽉あたりの⽣産性）立体感  プロセスは  上から下へ  生産性の価値  cost（⾦額） man-month（⼯数）使  っ  て  い  る  武  器  接続箇所 

Slide 38

Slide 38 text

事業責任者  PdM  Eng Des Eng Eng Des BM BM 経理経営 Eng EM PM/Dir PdM PdM 横断組織 38 開発組織    経営層  CxO・役員  （経営企画 / 経理）   人数サイズ  予算権限  スループット（1⼈⽉あたりの⽣産性）立体感  プロセスは  上から下へ  生産性の価値  cost（⾦額） man-month（⼯数）接続箇所  無理に飛躍して、  現場の指標を  管理会計に繋げない。  机上の空論になる 

Slide 39

Slide 39 text

Eng Des Eng Eng Des BM BM 経営 Eng EM PM/Dir PdM PdM 横断組織 39 開発組織    経営層  CxO・役員  （経営企画 / 経理）   オーバーラップさせる箇所の意味を変換すればいい  事業責任者  PdM  工数と金額を共通言語として、   現場と事業を繋いでいる  Sales Mktg BigQuery man-month （⼯数）スループット（1⼈⽉あたりの⽣産性） cost（⾦額）経理資産価値 / 減価償却

Slide 40

Slide 40 text

https://findy-team.io/dashboard 40

Slide 41

Slide 41 text

月単位 - 工数・実額  累計 - 工数・実額  完了予実  資産計上区分  全体サマリー  従業員属性  開発区分  施策一覧  フィルター 

Slide 42

Slide 42 text

42 42 select  project_code  , 工数  , 工期  , 実金額  , 人数  , 完了予定日  , 資産計上区分  where  {{本部名}} = “xxxxxx”  and {{部門名}} = “xxxxxx”  and {{チーム名}} = “xxxxxx”  BigQuery

Slide 43

Slide 43 text

43 合計工数  月別工数・実額  合計実額  部署別データ  横断的にプロジェクトにかかった工数と実額が検索できる  プロジェクトの学習データの蓄積 

Slide 44

Slide 44 text

Google Apps Script  にて自動生成  勤怠ツール  プロジェクトA  └ 6時間  ミーティング  └ 2時間    施策と工数  マッピング  人事データ  プロジェクト  データ  BPM  システム  経理・主計  給与  DWH  データパイプライン  生産性  レポート  BigQuery投入  Google Sheet  Looker  44

Slide 45

Slide 45 text

45 - 「開発生産性の改善」のその先  - 開発生産性は”信頼”を作ることに価値がある  - 開発生産性という言葉の勘所 ①〜③  - 開発生産性の正確性と立体感  - 開発生産性を上げることで「儲かる」のカラクリ  Table of Contents 

Slide 46

Slide 46 text

46 - 「その活動をして儲かるの？」の代表格  i. 開発生産性を上げる改善って、どう儲かるの？  ii. スクラムを導入したら、どう儲かるの？  iii. リファクタリングしたら、どう儲かるの？  iv. リモートワークにしたら、どう儲かるの？  v. MVPで小さくしたら、どう儲かるの？  - 本当に思っているかどうかは別にして、本質的には顧客が喜ぶ先にある、コストに対しての売上・利益への貢献依存度は考えている  事業責任者・経営層の頭の中 

Slide 47

Slide 47 text

47 開発に影響がある管理会計（一部）  売上費用利益開発に紐づく勘定項目  （主に販管費）    └ 人件費（給与・賞与）  └ 外注費  └ 法定福利費  └ 地代家賃  └ 減価償却費  └ 採用費  └ ツール・手数料費  └ サーバー設備費    等々    損益計算書（P/L）  貸借対照表（B/S）  現在の資源スナップショット  資産負債純資産 └ 固定資産  └ 無形固定資産  └ ソフトウェア  └ ソフトウェア仮勘定     

Slide 48

Slide 48 text

48 ソフトウェア資産の蓄積と売上の時間軸    資産負債純資産売上費用利益資産の蓄積  （時間軸が長い）  （売上へ間接的）  cash in  （時間軸が短い）  （売上に直接的）  積分（数年先に必要なことを今やってる.ex.バージョンアップやリファクタリング）  微分  開発  資産→売上    開発→資産    作る  減らす  （資産を作っている段階では売れるかわからない） 

Slide 49

Slide 49 text

という前提があったときに  開発生産性を上げると、P/Lはどうなるか 

Slide 50

Slide 50 text

50 開発生産性を上げると、P/L（コスト）はどうなるか    - 固定人件費は変わらない  - ただ、無駄な開発費用が減る  - 無駄 : 炎上プロジェクトへの人員投下、調整コスト、イニシャルコスト増、車輪の再発明  - 税率は一長一短      売上費用利益損益計算書（P/L） 

Slide 51

Slide 51 text

PdM, BMが考えた仮説が ”一定の確率” で価値を上げると仮定すると”継続的な速さ”は価値になる  時間軸のズレから確実に上げるとは言えない  - Q単位の仮説検証プロセスの回転数  - 1施策あたりのリードタイム短縮      51 売上費用利益損益計算書（P/L）  開発生産性を上げると、P/L（コスト）はどうなるか 

Slide 52

Slide 52 text

- 売上損失の最小化  - ロードバックの素早さ、最小限の障害  - 回転数があがるとデプロイが増えるので障害は増えることを考慮  - A/B環境の構築による影響範囲小  - サーバー費用の最小化  52 売上費用利益損益計算書（P/L）  開発生産性を上げると、P/L（コスト）はどうなるか 

Slide 53

Slide 53 text

私達は、ソフトウェア”資産”を作っている  開発したものの付加価値生産性を考えるときに  売上に紐づけるのではなく、資産価値に紐づける   

Slide 54

Slide 54 text

資産を増やす、耐久年数を長くするという観点から入ったほうが良い  売上に無理あり紐づけるのではなく、  まずは“資産化“という価値を知っておいた方が良い。  つまり、B/S的な思考でいた方が良い 

Slide 55

Slide 55 text

55 1. 資産価値があるソフトウェアを作る   a. ソフトウェア仮勘定として蓄積  2. リリースとともに本勘定へ（減価償却）   3. 資産価値がないものは、費用化   4. 資産価値があるものを沢山作ったほうが利益幅は大きくなる（税は大きくなる）    価値  時間  ソフトウェア仮勘定  開発中  1年  2年  3年  4年  5年  ソフトウェアの資産価値があるものを沢山作ったほうが利益幅は大きくなる  資産計上 → 減価償却  残存価値  開発生産性を上げると、P/L（コスト）はどうなるか  利益

Slide 56

Slide 56 text

→ 資産価値があり  （新規構築）  窓の掃除（現状を持続させる）  → 資産化（耐久年数の延長）  テスラのプロモーション  → 費用化  → 資産化  （新規取得）  UnsplashのBram Van Oostが撮影した写真

Slide 57

Slide 57 text

開発業務を資産に結びつけてみる 

Slide 58

Slide 58 text

58 儲かっていない箇所を最適化していく  取っ掛かりとして、  1. 開発中（イニシャルコストの削減 = 開発を継続的に早く）  2. ミーティング（ムダな会議はないか）  3. 保守運用の作業（ムダな作業はないか）  を見てみる。  これを金額に落とし込んでみる。  今期、人件費に対してソフトウェア資産価値を作っている業務の割合を調べてみる / 聞いてみる 

Slide 59

Slide 59 text

- 開発生産性は”信頼”を作ることに価値がある  - 開発生産性の意味を絞り、特性と構造を伝える  - 無理に現場の指標と財務諸表を繋げない  - そのうえで、開発生産性の向上の「儲かる」を意識する  まとめ 

Slide 60

Slide 60 text

参考文献  - 大規模言語モデル時代と開発生産性  https://speakerdeck.com/hirokidaichi/da-gui-mo-yan-yu-moderushi-dai-nokai-fa-sheng-chan-xing  - How Do Interruptions Affect Productivity? | Duncan P. Brumby, Christian P. Janssen & Gloria Mark | https://link.springer.com/chapter/10.1007/978-1-4842-4221-6_9  - 開発生産性の低下による、事業の失敗はなぜ起こるのか | 石垣雅人 | https://speakerdeck.com/i35_267/productivitypitfalls  - IT企業4,564プロジェクトプロジェクトマネジメントの実践・改善に活かす   https://www.ipa.go.jp/publish/wp-sd/qv6pgp0000000vv2-att/000069381.pdf   - 著 Christian Ciceri & 他12名 | 「ソフトウェアアーキテクチャメトリクス」  - 開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 | 石垣雅人 |  https://speakerdeck.com/i35_267/multifaceted-touchpoints-of-development-productivity  - Is High Quality Software Worth the Cost? | martin fowler |   - https://martinfowler.com/articles/is-quality-worth-cost.html  - リファクタリング（第2版）   https://www.ohmsha.co.jp/book/9784274224546/    

Slide 61

Slide 61 text

参考文献  - 著ジェリー・Z・ミュラー | 「測りすぎ――なぜパフォーマンス評価は失敗するのか?」  - 著 Jr FrederickP.Brooks | 「人月の神話【新装版】」  - あらゆるプロセスや方法論は-型-であり-成功を保証するものではない | 石垣雅人 |   https://medium.com/i35-267/eb272f719fe  - ソフトウェアメトリックス調査2020システム開発・保守調査| 一般社団法人日本情報システム・ユーザー協会 | https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf  - 見積もりをしない | 石垣雅人 |   https://speakerdeck.com/i35_267/jian-ji-moriwosinai  - 財務諸表というフレームワークで考えるソフトウェア開発と技術的負債  https://note.com/yshnb/n/ndf039850b614   - 経営とソフトウェアエンジニアリングの接続 | yasaichi |   https://web-salad.hateblo.jp/entry/2022/09/30/130000  - そのリファクタリングは最初から間違っている  https://youtu.be/j2qnF6e_n60?si=aLgIhSdULZTr2qcE    

Slide 62

Slide 62 text

参考文献  - 国税庁 : No.5403 少額の減価償却資産になるかどうかの判定の例示   https://www.nta.go.jp/taxes/shiraberu/taxanswer/hojin/5403.htm   - 国税庁 : 第8節　資本的支出と修繕費   https://www.nta.go.jp/law/tsutatsu/kihon/hojin/07/07_08.htm   - Don't refactor the code   https://dev.to/katafrakt/dont-refactor-the-code-igk   - Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases   https://arxiv.org/abs/2203.04374 