「開発生産性」はエンジニア”だけ” のモノではなくなった？ / "Development productivity" is no longer just for engineers?

「開発生産性」はエンジニア”だけ”  のモノではなくなった？  ── 開発組織から経営層までが“組織“の生産性を考える時代へ ──     1 Masato Ishigaki 
February 26, 2024 

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

現在までの歩み  歴史・時流  事業〜開発生産性  への接続    大規模組織  の開発生産性  3

4 - 開発生産性はエンジニア"だけ"のモノではなくなった？  - 見積もりによる「すれ違い」  - 開発の費用対効果による「すれ違い」  - ゼロリスク主義を辞める  -
誰のために、何を計測するのか  - 開発生産性はレイヤーごとに意味が違う  Outline 

誰のために、何を計測するのか  - 開発生産性はレイヤーごとに意味が違う  Outline  導入・時流 

誰のために、何を計測するのか  - 開発生産性はレイヤーごとに意味が違う  Outline  課題整理 

誰のために、何を計測するのか  - 開発生産性はレイヤーごとに意味が違う  Outline  解決策としての  開発生産性 

“だけ”ではなくなったのは  どういうことか  9

「開発生産性」は  エンジニア”だけ”のものではなくなった  最近の時流  - エンジニアリングのコモディティー化  あらゆる技術は誰でも利用可能な武器となる    - 競争優位性としての”生産性”  投入タイミングの自由自在さ、機能優位性を作れるか 
    10

❶ 事業的観点での開発生産性向上の効果   = 利益損失機会の最小化  PdM, BMが考えた仮説が ”一定の確率” で価値を上げると仮定すると”継続的な速さ”は価値になる 
  - Q単位の仮説検証プロセスの回転数  - 1施策あたりのリードタイム短縮      11

- 売上損失の最小化ができる  - 最小限の障害、ロードバックの素早さ  - サーバー費用の最小化、A/B環境の構築による影響範囲小    - 無駄な開発費用（販管費）  -
車輪の再発明、炎上プロジェクトへの人員投下  12 ❷ 事業的観点での開発生産性向上の効果   = 利益損失機会の最小化 

14 見積もりの不完全性による、事業計画のズレ    t  見積もりの工数  = 15人月  実際の工数  = 20人月 
(工期も1ヶ月ズレ)  超過分  ・調子が悪くなる  └ 設計ミス    ・スコープクリープ  1ヶ月  2ヶ月  3ヶ月  4ヶ月  5ヶ月  6ヶ月  ・景気よくスタート    工数  ・見積もり計画 

15 もちろん、早まることもある  t  見積もりの工数  = 15人月  1ヶ月  2ヶ月 
3ヶ月  4ヶ月  5ヶ月  6ヶ月  工数  見積もりの工数  = 6人月   

16 t  見積もりの工数  = 15人月  1ヶ月  2ヶ月  3ヶ
月  4ヶ月  5ヶ月  6ヶ月  工数  見積もりの工数  = 6人月    もちろん、早まることもある  ただ、早くなった原因は探る  - 開発速度が早くなった（成長した）のか  - バッファを積みすぎたのか  - バッファを積まないといけない現場なのか    パーキンソンの法則もあり、不思議とこの事例は多くない  ┗ 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」 

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

18 すれ違いの発生箇所  開発組織  - 見積もりは、そもそも大小外れるものという共通認識がある  - 遅れた事実は数値化しやすいが、“なぜ遅れたか”は数値化しにくい。  - 予算を使い大量投入されても、”人月の神話”状態（課題 !=
解決策）  - 内部品質の改善に予算を使いたいが結果がでるのに時間がかかる  - ┗ やり方によっては効果が出ない可能性も大いにあるため投資に踏み込むべきは組織のスキルを見極める必要あり 

🙅「不確実性が高くて、工数・工期が読めません」  🙋「とりあえず計画を出そう！」  🙆「2人月程度、足が出そうです」  🙎「話と違う」→ 信頼を落とす  の問題について  19 すれ違いの発生箇所 

20 見積もり＝予測には4つの側面がある  1. 施策のGoを判断するための「見積もり価値」  ┗ 特に判断に迷うエンハンス開発に多い。開発がこんなにかかるならやめよう等   ┗ 精度は低くてOK。最悪、1人月 or
10人月 or 50人月程度の精度でもOK   2. 設計のセンスやシステムの複雑性を検知するための「見積もり価値」  ┗ 施策に対して複雑なこと・ムダなことをしようとしていないか   ┗ システムの複雑性の説明責任にもなる   3. 納期・スケジュールの管理のための「見積もり価値」  ┗ プロマネ的な進行管理のため。契約状況により納期もあるためバッファを積む考え方もあり。   4. 自分たちの予測精度をあげるための「見積もり価値」  ┗ 自分たちの成長のため。バッファはいらない。失敗することが前提。    

21 見積もりが使われる箇所を理解する  実施前  ┗ そもそも、お金を出すべきかを判断したい。   1,000万の想定が1億円かかった。実はエンジニアは薄々わかっていた状態の回避   1. 施策のGoを判断するための「見積もり」 
2. 設計のセンスやシステムの複雑性を検知するための「見積もり価値」  開発開始  リリース後  ┗ できるだけ設計ミス・漏れをなくすための行動   3. 納期・スケジュール管理のための「見積もり価値」  ┗ 見積もりをもとに計画・イテレーション管理をして予測するため   ┗ 契約状況やキャンペーン施策の他ラインとの整合性も考える   4. 自分たちの予測精度をあげるための「見積もり価値」  ┗ 終わった後の振り返り。今後に反省点を次に活かす成長の定量データ  

22 見積もりが使われる箇所を理解する  実施前  ┗ そもそも、お金を出すべきかを判断したい。   1,000万の想定が1億円かかった。実はエンジニアは薄々わかっていた状態の回避   1. 施策のGoを判断するための「見積もり」 
2. 設計のセンスやシステムの複雑性を検知するための「見積もり価値」  開発開始  リリース後  ┗ できるだけ設計ミス・漏れをなくすための行動   3. 納期・スケジュール管理のための「見積もり価値」  ┗ 見積もりをもとに計画・イテレーション管理をして予測するため   4. 自分たちの予測精度をあげるための「見積もり価値」  ┗ 終わった後の振り返り。今後に反省点を次に活かす成長の定量データ   どのレイヤーの「見積もり価値」のことを  言っているのかを認識し、話し合いをして決定していく 

24 開発の投資対効果を測るのは難しい  時間軸の違い  「見えやすく測りやすい」👀  「見えにくく測りにくい」✘  ・キャンペーン施策、効果に直結するエンハンス開発    リリースした直後に数値（例えば売上）として跳ね返ってきたり、KPIがLTVでも期間で予算
のリクープの計算がしやすい    ・リファクタリングやリプレイス、定期的なバージョンアップといった内部品質    半年後、1年後、数年後を見据えて「今やっておくべきこと」が多く存在するがリターンも不安定で不確か     

25 見えにくく測りにくいもの  リプレイス  リファクタリング  膨大な予算をかけて  元に戻す 

26 見えにくく測りにくいもの  引用 : https://martinfowler.com/articles/is-quality-worth-cost.html

説明責任を果たす    - 人やサービスが多くなると分業体制になるのは仕方ない。多いのは、事業側とクリエイター側という区分け    - 事業側とクリエイター側が一緒になっているプロダクトチーム（スクラム等）が複数ある場合でも同じ。  -
施策の優先度の議論になる。 

営業  マーケ  プランナー・PMM  エンジニア  デザイナー  PM・PdM  単一事業    同じ目線を持てるように  PdM 
エンジニア  デザイナー  PdM  エンジニア  デザイナー  Team  Team  Team  Team  PdM  エンジニア  デザイナー  Team  施策の優先順位  の調整  ドメインごとのチーム  システム面の相互利用者 

認知のオーバーラップを意識する  事業側  ┗ 営業  ┗ プランナー・PMM  ┗ マーケ,etc..  クリエイター  ┗
エンジニア  ┗ デザイナー  ┗ EM, PM, PdM等    すれ違いを埋めるのは  人なのかプロセスなのか体制なのか  ソフトウェア  資産を作る  資産を使って  売上を作る 

❶事業側はエンジニアに説明責任を果たす  - きちんと事業の目指す先（戦略）と戦術を伝える。  - 一緒に考える。会議体の設計をきちんと行い情報の同期精度を上げていく  - 要求（やりたい）をちゃんと伝える。  - ざっくりだと、3点見積もりになり見積もりがブレる &
時間がかかる  - できるだけ、要求を「形」にするイメージを持つ   

❷事業側はエンジニアに説明責任を果たす    - 理解したほうが、開発側がどこに力を入れるべきかを判断できる  - ┗ 大きくレバレッジをかけてサービススケールさせる計画がNヶ月にあるのだったら、内部品質に力を入れてサーバーアーキテクチャをしっかり設計・改善する  - ┗
逆に直近はトップラインをあげてcash inを優先しないといけないのであればスピード感を意識する動きができる    - 現状をわかった上で耐えているのと、情報がなくモヤモヤして内部品質に着手できないでいる現場では全然違う 

エンジニアは事業側に説明責任を果たす  - 要求がざっくりしているなら一緒に考える。壁を作らない  - 中長期的なシステム改善の開発ロードマップを提供する  - ┗ できるだけトップライン、ボトムラインベースで話す  - ┗
サーバーコストの削減や機会損失の換算    - 難しいことをわかりやすく話す  - 小さいところから成果を共有しあう 

システム稼働率のゼロリスク  SLI / SLOを組織で考える  - ちゃんと定量的にサービスレベルを全員に示す。理解してもらう  - 多くの人は、システムがずっと稼働・速さが出ていると思っている  - 少しでもサービスが落ちていると連絡がくる。不毛なやり取りを無くす 
- 実際は、99.9%→99.8%程度のこともある  - 修正対応の優先度判断時間ももったいない  - 動いていることが当たり前ではない意識を持つ  34

プロジェクトのゼロリスク  引用: CHAOS REPORT 2015  OnTime（時間通り）、OnBudget（予算内）、OnTarget（目標達成）、OnGoal（目的達成）、Value（価値）、Satisfaction（満足度）   プロジェクトの失敗確率。自分たちの ”予測通り” に達成できたか 
35

失敗とは、見積もりの失敗である  納期が遅れたとか、予算がオーバーしたとかでプロジェクトが失敗したと言うよりも、   失敗したのは見積もりなのだと言いたい。CHAOSレポートはソフトウェアプロジェクトの失敗の記録ではなく、ソフトウェア見積りの失敗の記録なのだ。    何が成功として勘定できるのか。測ることが可能なのであれば、答えは投資へのリターンとなるべきだ。悲しいかなこれを測ることなど不可能に等しい。  Rather than
saying that a project is failed because it is late, or has cost overruns - I would argue that it's the estimate that failed. So the CHAOS report isn't chronicling software project failure, it's chronicling software estimation failure.  So what counts as success? If we could measure it the answer has to be Return on Investment. Sadly this is usually next to impossible to measure (see my discussion in CannotMeasureProductivity) In the end it's a fuzzy sense of business satisfaction relative to the cost of the project.   引用: WhatIsFailure（失敗とは）: マーティンファウラー   36

そして、その見積もりもだいたい外れる  引用: IPA 「IT企業4,564プロジェクトプロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果」  計画より上回っている   計画より下回っている  
37

誰のために、何を計測するのか  39

誰のために、何を計測するのか    「チームのためか、チーム外のためか」  予算獲得の獲得ため？それともチーム内で利用するため？    計測に時間をかけるのではなく、課題解決に時間をかける  コードの複雑性の可視化に時間をかけるのではなく、手を動かし改善→改善幅を見る     
  40

本来、信頼が積み上がれば  開発生産性は気にならなくなる  41 - 監視・管理という意味合いでは不要になる    - エンジニアが自分たちのため（ケイパビリティ）にやる開発生産性や開発速度を考えるのが本来は正しい 

- エンジニア目線  - ┗ GitHub Copilotを入れたい。テストを早くしたい。  - ┗ フロー状態を長くしたい。技術負債を無くしたい。  -
PM / 開発マネージャー目線  - ┗ 開発プロセスのリードタイムを短縮したい  - ┗ 予測どおりに仮説検証したい。リソースマネジメントの簡易化  - 事業 / 経営目線  - ┗ 早く > 安く > 良いものを出したい。場合によっては外注もあり  43 生産性を上げたい意味も全然違う 

「開発生産性」が経営層に伝わらない理由は、  “言語”が違うから   

仮体制図  Eng Des Eng Eng Des BM BM 経理経営
Eng EM PM/Dir 横断組織 45 開発組織    経営層  CxO・役員  （経営企画 / 経理）  事業責任者  PdM  PdM PdM 年商1,000億円  所属 : 100人  年商 1億円  所属 : 10人 

46 開発組織    経営層  CxO・役員  （経営企画 / 経理）   Eng
Des Eng Eng Des BM BM 経理経営 Eng EM PM/Dir PdM PdM 横断組織事業責任者  PdM  財務諸表  ・P/L : 販管費への影響度合い   ・B/S : 資産、償却、税負担への影響   金額  ・販管費の最適化   ※ 同じ単価でも、施策回数と質が違う   ※ 生産性が落ちてくると、追加投資額が必要     工数・工期（計画・ロードマップ）   ・生産性が高くなると当初計画よりも短くなる   ・もしくは類推見積もりの角度が上がる   開発チーム内の向き合い   ・ソフトウェアの内部品質、エコシステム   ・Four keys, テストカバレッジ   数値の流れ  P/L 販管費 cost（⾦額） cost（⾦額） man-month（⼯数）スループット（1⼈⽉あたりの⽣産性） man-month（⼯数） B/S 資産 / 減価償却 “開発生産性”はレイヤーごとに意味が違う 

事業責任者  PdM  Eng Des Eng Eng Des BM BM 経理
経営 Eng EM PM/Dir PdM PdM 横断組織各領域をオーバーラップさせる  47 事業責任者  PdM  開発組織    経営層  CxO・役員  （経営企画 / 経理）   ・“開発生産性が上げるアプローチと抽象度がレイヤーごとに違う  ・良いソフトウェアが企業価値を上げるには”接続”してあげる必要がある  ・ゆえにオーバーラップする部分（接続箇所）の設計が大事になる” 

事業責任者  PdM  Eng Des Eng Eng Des BM BM 経理
経営 Eng EM PM/Dir PdM PdM 横断組織 48 開発組織    経営層  CxO・役員  （経営企画 / 経理）   output input 次元を変換して、入力と出力で渡してあげる    output input output input

Eng Des Eng Eng Des BM BM 経営 Eng EM
PM/Dir PdM PdM 横断組織 49 開発組織    経営層  CxO・役員  （経営企画 / 経理）   オーバーラップさせる箇所のモニタリング  事業責任者  PdM  モニタリング基盤を構築して、   正しくレポーティング  Sales Mktg BigQuery man-month （⼯数）スループット（1⼈⽉あたりの⽣産性） cost（⾦額）経理資産価値 / 減価償却

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

51 BigQuery

52 BigQuery select  project_code  , 工数  , 工期  , 実金額 
, 完了予定日  , 資産計上区分  where  {{本部名}} = “xxxxxx”  and {{部門名}} = “xxxxxx”  and {{チーム名}} = “xxxxxx”  ・開発業務区分  ・開発コード  ┗ 毎月の工数・金額  ┗ 毎月の人数  ┗ 進行ステータス  ・完了予定日・予実  ・資産計上区分    内製 

53 開発業務区分  ビジュアライズ  開発施策  月単位 - 金額  完了予実  資産計上区分  全体サマリー 
月単位 - 工数  部署名 

チームを跨いだ柔軟な分析  54

設定した指標（KPI）を横断的に観測（約1,000名）    KPI : 開発に集中できているか  ミーティングは多くないか  55

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

このアプローチは開発組織が50〜100名以上だとベスト    - これによって、あらゆる開発プロセスを工数と実額で述べられるようになる    - どちらかというと決裁権限がある部長以上が中心で見るもの    -
開発人数の規模が小さかったりエンジニアリングに理解があれば、シンプルなメトリクスでカバーで良いと思う    57

  “数値”を高めると強い組織になるのか、  強い組織の”状態”が数値を高めるのか            58 「グットハートの法則、キャベルの法則」 
組織や制度が数値向上を目的にすると、  多少なりとも圧がかかり数字を作るためだけに行動する    状態が数値を作り、数値が状態を作るわけではない 

  まず、アウトプット（出力量）をあげた後に  アウトカム（価値結果）を考える    59 「開発生産性を上げる vs ムダなものを作る確率を下げる」  　  -
もちろん、どっちも大事。  - エンジニアがどこにコミットし責任があるか掴む。コミットすると責任がある。は違う  - 何を作るべきかは、事業戦略・マーケティングセンス、市場分析など  やることが沢山ある     

採用するか、開発生産性をあげるか  技術投資の費用対効果  - 強いエンジニアの採用（難化）  - 大きな福利厚生となり多くの問題を解決する    - 開発生産性をあげていく（明日から）  -
現存する開発リソースの最大化 

誰のために、何を計測するのか  - 開発生産性はレイヤーごとに意味が違う  まとめ 

参考文献  - MAKER'S SCHEDULE, MANAGER'S SCHEDULE | Paul Graham |
https://www.paulgraham.com/makersschedule.html  - DevEx: What Actually Drives Productivity | Abi Noda, Margaret-Anne Storey, Nicole Forsgren, Michaela Greiler | https://queue.acm.org/detail.cfm?id=3595878  - The SPACE of Developer Productivity | Nicole Forsgren,Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler|   - https://queue.acm.org/detail.cfm?id=3454124  - 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  - CHAOS REPORT 2015 | The Standish Group International, Inc.| https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf  - WhatIsFailure | martin fowler |   - https://martinfowler.com/bliki/WhatIsFailure.html  - CannetMeasureProductivity | martin fowler |   - https://martinfowler.com/bliki/CannotMeasureProductivity.html   

参考文献  - 著 Christian Ciceri & 他12名 | 「ソフトウェアアーキテクチャメトリクス」  -
デュアルトラックアジャイルとの向き合い方。あるいはエンジニアとビジネスの距離感| onk |   https://onk.hatenablog.jp/entry/2023/03/10/045349  - 開発生産性の多角的接点〜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  - 著ジェリー・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   

参考文献  - LeanとDevOps生産性の神話(1) - 11年目のState of DevOps Report | シリコンバレーからのノート|
https://note.com/ishiguro/n/n12f6ac8a70a9  - LeanとDevOps生産性の神話(2) - 11年目のState of DevOps Report | シリコンバレーからのノート | https://note.com/ishiguro/n/n08923d170e32  - LeanとDevOps生産性の神話(3) - 11年目のState of DevOps Report | シリコンバレーからのノート | https://note.com/ishiguro/n/n7c8c21fcffb6  - Streamlining change approval | DORA |   - https://dora.dev/devops-capabilities/process/streamlining-change-approval/  - アジャイル・DevOpsからDeveloper Productivityへ ~食べログのDeveloper Productivityチームが目指す姿~ | kokotatata | https://kokotatata.hatenablog.com/entry/2021/12/23/051947  - DPE (Developer Productivity Engineering) & DXE (Developer Experience Engineer) | 雪泥鴻爪--IT技術者の随筆 | https://yinlei.org/it-iot/  - AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり | Kengo TODA | https://blog.kengo-toda.jp/entry/2023/11/03/201546   

参考文献  - 経営とソフトウェアエンジニアリングの接続 | yasaichi |   https://web-salad.hateblo.jp/entry/2022/09/30/130000  - IT企業4,564プロジェクト
プロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果 | IPA |   https://www.ipa.go.jp/publish/wp-sd/qv6pgp0000000vv2-att/000069381.pdf   - Is High Quality Software Worth the Cost? | martin fowler |   https://martinfowler.com/bliki/CannotMeasureProductivity.html       

「開発生産性」はエンジニア”だけ” のモノではなくなった？ / "Development productivity" is no longer just for engineers?

「開発生産性」はエンジニア”だけ” のモノではなくなった？ / "Development productivity" is no longer just for engineers?

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Featured

Transcript