技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?

Slide 1

Slide 1 text

技術負債による事業の失敗は  なぜ起こるのか  ── 技術的負債〜困難を乗り越える道筋〜 ──     1 Masato Ishigaki  July 24, 2024 

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

- クリエイター組織は、約1,300名  - チーム数は、約200チーム  - 現在進行中の開発プロジェクトは、約500個  - 正社員 : 約60%、業務委託 : 約40%    5 DMM.comの開発組織アウトライン 

Slide 6

Slide 6 text

6 - ソフトウェア事業の失敗と技術負債  - 事業責任者が気づくべき、技術負債アラート早見表  Table of Contents 

Slide 7

Slide 7 text

7 - ソフトウェア事業の失敗と技術負債  - 事業責任者が気づくべき、技術負債アラート早見表  Table of Contents 

Slide 8

Slide 8 text

ソフトウェア事業の失敗  事業予算に対しての失敗は、ソフトウェア周辺に絞ると    「価値があるものが作れなかった」    ほぼ1択      ※ 価値 = 売上を作ったり、ユーザーのリテンションを作ったり。   8

Slide 9

Slide 9 text

  「価値があるものが作れなかった」  9 作れなかった原因パターンは2つ  1. 作ろうとしたけど時間がかかりすぎた。間に合わなかった  2. そもそも価値がないものを作りすぎた 

Slide 10

Slide 10 text

作れなかった原因パターンは2つ    「価値があるものが作れなかった」  1. 作ろうとしたけど時間がかかりすぎた。間に合わなかった  2. そもそも価値がないものを作りすぎた  a. → ここはエンジニアだけではコントロールできない。事業戦略の筋、業界ドメインの深い理解、TAM / SAMの見誤り、予算計画の踏み込みの弱さ  b. 技術負債とは関係が薄いのでここでは省略    10

Slide 11

Slide 11 text

事業の計画性と予算  A-1施策  チームA  → 来期  A-2施策  B-1施策  B-2施策  B-3施策  A-3施策  A-4施策  チームB  売上  t  B-4施策  A-5施策  開発計画  予算計画  YoY 130%  上半期  下半期  11

Slide 12

Slide 12 text

時間がかかりすぎて、間に合わなかった価値がある  A-1施策  チームA  YoY 130%  → 98%着地予測  A-2施策  B-1施策  B-2施策  B-3施策  A-3施策  チームB  t  A-5施策  開発計画  予算計画  売上  このまま行くと  未達だ。やばい  実績  計画  → 来期  A-4施策  B-4施策  差し込み  予測  上半期  下半期  獲得できなかった価値  12

Slide 13

Slide 13 text

追加予算の分だけ売上を作らないといけない  A-1施策  チームA  A-2施策  B-1施策  B-2施策  B-3施策  A-3施策  チームB  A-5施策  開発計画  A-4施策  B-4施策  予算（開発予算）  追加予算  予算  予算計画  コスト  差し込み  獲得できなかった価値  13

Slide 14

Slide 14 text

なぜ、こんなことが起きるのか  - 事業開発の連続で、技術負債が溜まっていると起こる現象  - 前提、失敗は見積もりの失敗という理解  - 隠された失敗が増える  - 課題解決が遅くなればなるほど詰んでいる状態  14

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

初動で少しズレ始めたからといって   リカバリープランをエンジニア側に求めてもしょうがない   → この感覚をどう伝えるか   不確実性コーンを頭ではなく実態として適合していく  本来はランニングしていきながら   検査・適応の中で、少しずつ歯車を合わせて行く不確実性が高いのに   最初に色々と決めすぎている   契約もある  引用 : https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/ 

Slide 18

Slide 18 text

18 隠された失敗がどんどん増えていく  - 人は、失敗や気不味いことを無意識に隠そうとする  - 直前になって出てくる「間に合いません」  - リカバリーできるという自信から課題をすぐに報告しない  - 不安だから、無意識に無意味なバッファを作る 

Slide 19

Slide 19 text

19 課題解決が遅くなればなるほど、詰む  課題認識  課題解決の遂行  課題解決の遂行課題認識  報告  リリース日  報告  リカバリープランが豊富  時間がなくリカバリープランがない   （且つ二次被害が起きる）   隠されている失敗  a）  b）  t 

Slide 20

Slide 20 text

20 課題解決が遅くなればなるほど、詰む。内部品質改善も  引用:Is High Quality Software Worth the Cost?  

Slide 21

Slide 21 text

🙎 事業責任者の心情  21

Slide 22

Slide 22 text

事業責任者の心情  期の途中  - そもそも計画よりも遅れてるし、予算も超過しているからスピード重視！  - この事業を良いものにしたいという熱い思いから来る、今を切り取った時の「選択と集中」  今期を乗り切ったとしても  - 今期は生き延びたけど、来期は先手先手で早くから価値を作っていきたい  - 事業はプロジェクトではないのでずっと120%〜の成長が求められる    22

Slide 23

Slide 23 text

事業責任者の心情  技術負債への解釈  - そもそも内部品質が改善したら、どうなるのかがわからない  - 実際に多いのはエンジニア自身もその効用がよくわかっていない。故にうまく説明できない / してもらえない  - リファクタリングをすることは良いことは知っているが、かと言ってどこまで必要なのかがわからないので予算見込みが不明  - 結果、度重なる不具合や開発生産性の低下から大きなリプレイスが必要になったが、踏み込むタイミング（数億円規模）を見失いがち  23

Slide 24

Slide 24 text

win-winを作るエンジニアリングの言語化  - 開発優先度をブラックボックスにせずに伝える  - 新規開発やエンハンス開発といった機能を増やすではない   - ミドルウェアのバージョンアップ、セキュリティーへの対応、テストの追加やイケてない設計のリファクタリング、開発生産性をあげるルール改善、新しいメンバーのオンボーディングなど  - ユーザーに直接的に価値を届ける以外の様々なIssueがバックログへ   - 🙋この案件を差し込もうとすると半年後です。状態へ   - ちゃんと説明責任を果たさないと「何しているかわからないがいつも忙しそう」と見られる。細かく優先度をつけられる    24

Slide 25

Slide 25 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:  「リファクタリングをしたいです」という言葉を使わない  - リファクリングは良いことなので許容するが何をしているかはあまりわかっていない   - かつ、リファクタリングには終わりがないので「いつまでやるの？」状態で工数を取っていく   win-winを作るエンジニアリングの言語化    25

Slide 26

Slide 26 text

26 - ソフトウェア事業の失敗と技術負債  - 事業責任者が気づくべき、技術負債アラート早見表  Table of Contents 

Slide 27

Slide 27 text

予測精度の幅を見る  可観測性（オブザーバビリティー）を見るのと同じように  とりあえず、各予測フェーズと予実の入出力のズレを見てみる    なぜズレるのかは一旦置いといてデータを見てみてほしい  27

Slide 28

Slide 28 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  バックログ  アイテムに分解した  結果、倍ぐらいかかった  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り 

Slide 29

Slide 29 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り  一般的な現行システムのズレで予測工数が増える  ここが多いと、複雑なことが起きている事が多い 

Slide 30

Slide 30 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  バックログ  アイテムに分解した  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り  1つ1つのアイテム見積もりの総和で合計工数が明らかになる。  そこまでズレることは少ない 

Slide 31

Slide 31 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  バックログ  アイテムに分解した  結果、倍ぐらいかかった  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り  スコープクリープや設計ミス   ┗ 現場でズレる : 設計欠陥やスキル感   ┗ 要件でズレる : 途中で要件が変更になる  

Slide 32

Slide 32 text

計画工数  予測  フェーズ  超概算  (予測)  詳細  (予測)  開発  (予測)    リリース  （実績）    1人月  10人月  一般的に  このぐらいだろう  バックログ  アイテムに分解した  結果、倍ぐらいかかった  PRD / DD  書いた  企画  設計→Ready  開発中  振り返り  ここのズレが大きいと予兆あり  色んな原因が混在 

Slide 33

Slide 33 text

33 - 価値があるものが作れなかったのが失敗原因  - 作ろうとしたけど時間がかかりすぎた。間に合わなかった  - その多くは技術負債による予測の見誤りとそれによる隠された失敗の連続  - 事業責任者はとりあえず予測精度のズレを見てみる  まとめ 

Slide 34

Slide 34 text

参考文献    - 開発生産性の低下による、事業の失敗はなぜ起こるのか | 石垣雅人 | https://speakerdeck.com/i35_267/productivitypitfalls  - 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/   - プロジェクトの本質とはなにか   https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/  - Don't refactor the code   https://dev.to/katafrakt/dont-refactor-the-code-igk   - PdM / EMが気づくべき技術負債の異変   https://medium.com/i35-267/気づくべき-技術負債-の異変-pdm-em向けの早見表-3e726e9295fd   - IPA 「IT企業4,564プロジェクトプロジェクトマネジメントの実践・改善に活かす最新定量データと分析結果」   https://www.ipa.go.jp/publish/wp-sd/qv6pgp0000000vv2-att/000069381.pdf      