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

by Masato Ishigaki / 石垣雅人

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

失敗とは、見積もりの失敗である  納期が遅れたとか、予算がオーバーしたとかでプロジェクトが失敗したと言うよりも、   失敗したのは見積もりなのだと言いたい。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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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 資産 / 減価償却 “開発生産性”はレイヤーごとに意味が違う 

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

51 BigQuery

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

参考文献  - 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   

Slide 63

Slide 63 text

参考文献  - 著 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   

Slide 64

Slide 64 text

参考文献  - 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   

Slide 65

Slide 65 text

参考文献  - 経営とソフトウェアエンジニアリングの接続 | 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       