開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls

Slide 1

Slide 1 text

開発生産性の低下による  事業の失敗はなぜ起こるのか      1 Masato Ishigaki December 13, 2023

Slide 2

Slide 2 text

2 - ソフトウェア事業の失敗と開発生産性  - 見積もりの不完全性による、事業計画のズレ  - “不安”の定量化が、追加コストを生む    Outline 

Slide 3

Slide 3 text

3 - ソフトウェア事業の失敗と開発生産性  - 見積もりの不完全性による、事業計画のズレ  - “不安”の定量化が、追加コストを生む    Outline 

Slide 4

Slide 4 text

4 About me  石垣雅人  合同会社 DMM.com   プラットフォーム事業本部第1開発部部長   VPoE室 / アルファ室     ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020）   ・連載 : 『スモールチームが武器になる時代へ』（ProductZine）   ・連載 : 『群知能から紐解く、スケールする“組織“の作り方』（NewsPicks）    @i35_267 @i35_267 @i35_267

Slide 5

Slide 5 text

5 ソフトウェア事業における失敗の種類  - 誤った戦略と戦術  - 膨大なイニシャル、ランニングコストによる資金ショート、予算超過  - 市場投入の遅れ    - ただ、開発組織がイケていると結構リカバリーが効くことが多い。  - 継続的な速さは価値  - 逆に、開発生産性が低いと致命的になる 

Slide 6

Slide 6 text

6 ソフトウェア開発の失敗確率  引用: CHAOS REPORT 2015  OnTime（時間通り）、OnBudget（予算内）、OnTarget（目標達成）、OnGoal（目的達成）、Value（価値）、Satisfaction（満足度）   自分たちの ”予測通り” に達成できたか 

Slide 7

Slide 7 text

7 ソフトウェア開発の失敗確率（大〜小）（WF vs Agile）  引用: CHAOS REPORT 2015 

Slide 8

Slide 8 text

8 ソフトウェア開発の失敗確率（日本の場合）  引用: 企業IT動向調査報告書 2023 ユーザー企業のIT投資・活用の最新動向 

Slide 9

Slide 9 text

9 失敗とは、見積もりの失敗である  納期が遅れたとか、予算がオーバーしたとかでプロジェクトが失敗したと言うよりも、   失敗したのは見積もりなのだと言いたい。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（失敗とは）: マーティンファウラー 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

11 見積もりで、何を決定させたいか    （要約）  見積もりをする = 何を獲得したいのか、何を失うのかを問い続ける。  何も得るものがなければ、見積もりはいらない  大体、その多くは施策の実施判断と人的リソースの調整に使われる    For me, estimation is valuable when it helps you make a significant decision.  My first example of an estimation-informed decision is allocation of resources. Organizations have a mostly fixed amount of money and people, and usually there are too many worthwhile things to do. So people are faced with decisions: do we do A or B? Faced with such a decision it's useful to know how much effort (and cost) each will involve. To make sensible decisions about what to do, you need to have a feel for both the cost and the benefits.  引用: PurposeOfEstimation（見積もりの目的）: マーティンファウラー 

Slide 12

Slide 12 text

12 - ソフトウェア事業の失敗と開発生産性  - 見積もりの不完全性による、事業計画のズレ  - “不安”の定量化が、追加コストを生む    Outline 

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

14 見積もりの不完全性による、事業計画のズレ    見積もりの工数  = 15人月  実際の工数  = 20人月  膨張・調子が悪くなる  └ 設計ミス    ・スコープクリープ  ・景気よくスタート    工数  ・見積もり計画  └ この積み重ねが、事業計画（P/L）を圧迫する  遅延分の売上分損失  追加人件費  減価償却の増加    Sales  Marketing  追加投資 2,500万  売上損失  t  1ヶ月  2ヶ月  3ヶ月  4ヶ月  5ヶ月  6ヶ月  見積もり : 7,500万  追加コストの圧迫箇所 

Slide 15

Slide 15 text

15 セクショナリズムの発生箇所  事業/経営  - エンジニアの見積もりを信じて、ソフトウェア事業の計画を作る  - なのに毎回遅れる。ただ、なぜ遅れるのかはわからない  - リカバリーのための人件費（エンジニア、PM）を投入（そこが操作可能変数）  開発組織  - 見積もりは、そもそも外れるものという共通認識がある  - 遅れた事実はわかりやすいが、“なぜ遅れたか”は数値化しにくい。  - 大量投入されても、”人月の神話”状態（課題と解決があっていない）  - だったら、内部品質の改善に予算を使いたいが結果がでるのに時間がかかる 

Slide 16

Slide 16 text

16 - ソフトウェア事業の失敗と開発生産性  - 見積もりの不完全性による、事業計画のズレ  - “不安”の定量化が、追加コストを生む    Outline 

Slide 17

Slide 17 text

17 “不安”の定量化が追加コストを生む  より、詳しい状態を可視化したいので、”監視状態”に入る  - アンチパターンだが、気持ちはわかる  - 1. WBSの詳細化が求められる  - └ すぐにズレてくるので、管理のための管理が増えてくる  - 2 .これに開発生産性の可視化も入ってくることがある  - └ 自分たちのケイパのためにやらないと、モチベーションが下がる  - 3. どんどん説明責任の時間が増える  - └ アラート : 開発のリーダー層とPMのMTGが増えてくる  - 4. 開発業務比率を見ると開発速度が上がらないのは、そもそも時間がないから 

Slide 18

Slide 18 text

18 コンテキストスイッチを甘く見ない  “The Cost of Context Switching  Developers reported that they usually feel most productive when they make progress on tasks and when they have only a few context switches and interruptions.   However, observing developers’ workdays revealed that they constantly switch contexts, often multiple times an hour. For example, developers switched tasks on average 13 times an hour and spent just about 6 minutes on a task before switching to another one. “  “開発者たちは、タスクの進捗を感じる時や、コンテキストの切り替えや中断が少ない時に最も生産的だと感じることが多いと報告しています。    しかし、開発者の労働日を観察すると彼らは絶えずコンテキストを切り替えており、しばしば1時間に何度もこれを行っています。例えば、開発者は平均して1時間に13回タスクを切り替え、約6分間タスクに集中して別のタスクに移っています”  引用 : Rethinking Productivity in Software Engineering Chapter Developers’ Diverging Perceptions of Productivity 

Slide 19

Slide 19 text

19 個々が生産的だと感じる時間帯も偏りはあるがバラバラである  “Three types of developers an d   their perceptions of productivity over the course of a workday”   “湾曲した回帰線は、個々の開発者が信頼範囲を示す影付きの領域で生産的だと感じた日の全体的な   パターンを示しています。朝の人々はまれで（20%）、最大のグループは午後の人々（40%）     これらの結果は、開発者が多様な生産性パターンを持っている一方で、   個人が毎日自分の習慣的なパターンに従っているように見えることを示唆しています。”   引用 : Rethinking Productivity in Software Engineering Chapter Developers’ Diverging Perceptions of Productivity 

Slide 20

Slide 20 text

20 開発生産性を下げる要素    - 開発生産性を下げているのは、開発組織だけとは限らない  - └ 意外に一番下げているのは、開発作業以外の箇所かも  - ただ、説明責任を果たさないと負のループは終わらない  - 予想工数との予実や開発業務比率の可視化  - 一番は、信頼関係が作れれば完璧  - └ 信頼が積み上がっていれば、開発速度は何も気にならない   

Slide 21

Slide 21 text

21 - ソフトウェア事業の失敗と開発生産性  - 見積もりの不完全性による、事業計画のズレ  - “不安”の定量化が、追加コストを生む    まとめ 