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

2023/12/13 DMM meetup #39 ～開発生産性を熱く語る会～
https://dmm.connpass.com/event/301567/

Transcript

1. 開発生産性の低下による
 事業の失敗はなぜ起こるのか
 
 
 1 Masato Ishigaki December 13, 2023
2. 2 - ソフトウェア事業の失敗と開発生産性
 - 見積もりの不完全性による、事業計画のズレ
 - “不安”の定量化が、追加コストを生む
 
 Outline

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

4. 4 About me
 石垣 雅人
 合同会社 DMM.com 
 プラットフォーム事業本部 第1開発部 部長 
 VPoE室 / アルファ室 
 
 ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020） 
 ・連載 : 『スモールチームが武器になる時代へ』（ProductZine） 
 ・連載 : 『群知能から紐解く、スケールする“組織“の作り方 』（NewsPicks）
 
 @i35_267 @i35_267 @i35_267
5. 5 ソフトウェア事業における失敗の種類
 - 誤った戦略と戦術
 - 膨大なイニシャル、ランニングコストによる資金ショート、予算超過
 - 市場投入の遅れ
 
 - ただ、開発組織がイケていると結構リカバリーが効くことが多い。
 - 継続的な速さは価値
 - 逆に、開発生産性が低いと致命的になる

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

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

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

9. 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（失敗とは）: マーティンファウラー

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

11. 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（見積もりの目的）: マーティンファウラー

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

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

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

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

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

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

18. 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

19. 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

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

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