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

2024/7/24 Developers Summit Summer 2024の登壇資料です。
https://event.shoeisha.jp/devsumi/20240723

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

2. 2 About me
 石垣 雅人
 合同会社 DMM.com
 プラットフォーム開発本部 部長 
 ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版） 
 ・連載中 : 『開発生産性の多角的視点』（CodeZine） 
 ・連載中 : 『スモールチームが武器になる時代へ』（ProductZine） 
 ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』（NewsPicks）
 
 2
5. - クリエイター組織は、約1,300名
 - チーム数は、約200チーム
 - 現在進行中の開発プロジェクトは、約500個
 - 正社員 : 約60%、業務委託 : 約40%
 
 5 DMM.comの開発組織アウトライン

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

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

8. ソフトウェア事業の失敗
 事業予算に対しての失敗は、ソフトウェア周辺に絞ると
 
 「価値があるものが作れなかった」
 
 ほぼ1択
 
 
 ※ 価値 = 売上を作ったり、ユーザーのリテンションを作ったり。 
 8
9. 
 「価値があるものが作れなかった」
 9 作れなかった原因パターンは2つ
 1. 作ろうとしたけど時間がかかりすぎた。間に合わなかった
 2. そもそも価値がないものを作りすぎた

10. 作れなかった原因パターンは2つ
 
 「価値があるものが作れなかった」
 1. 作ろうとしたけど時間がかかりすぎた。間に合わなかった
 2. そもそも価値がないものを作りすぎた
 a. → ここはエンジニアだけではコントロールできない。事業戦略の筋、業界ドメインの 深い理解、TAM / SAMの見誤り、予算計画の踏み込みの弱さ
 b. 技術負債とは関係が薄いのでここでは省略
 
 10
11. 事業の計画性と予算
 A-1施策
 チームA
 → 来期
 A-2施策
 B-1施策
 B-2施策
 B-3施策
 A-3施策
 A-4施策
 チームB
 売上
 t
 B-4施策
 A-5施策
 開 発 計 画
 予 算 計 画
 YoY 130%
 上半期
 下半期
 11
12. 時間がかかりすぎて、間に合わなかった価値がある
 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
13. 追加予算の分だけ売上を作らないといけない
 A-1施策
 チームA
 A-2施策
 B-1施策
 B-2施策
 B-3施策
 A-3施策
 チームB
 A-5施策
 開 発 計 画
 A-4施策
 B-4施策
 予算（開発予算）
 追加予算
 予算
 予 算 計 画
 コ ス ト
 差し込み
 獲得できなかった価値
 13
14. なぜ、こんなことが起きるのか
 - 事業開発の連続で、技術負債が溜まっていると起こる現象
 - 前提、失敗は見積もりの失敗という理解
 - 隠された失敗が増える
 - 課題解決が遅くなればなるほど詰んでいる状態
 14
15. 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（失敗とは）: マーティンファウラー

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

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

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

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

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

21. 🙎 事業責任者の心情
 21
22. 事業責任者の心情
 期の途中
 - そもそも計画よりも遅れてるし、予算も超過しているからスピード重視！
 - この事業を良いものにしたいという熱い思いから来る、今を切り取った時の「選択と集 中」
 今期を乗り切ったとしても
 - 今期は生き延びたけど、来期は先手先手で早くから価値を作っていきたい
 - 事業はプロジェクトではないのでずっと120%〜の成長が求められる
 
 22
23. 事業責任者の心情
 技術負債への解釈
 - そもそも内部品質が改善したら、どうなるのかがわからない
 - 実際に多いのはエンジニア自身もその効用がよくわかっていない。故にうまく説明でき ない / してもらえない
 - リファクタリングをすることは良いことは知っているが、かと言ってどこまで必要なのかが わからないので予算見込みが不明
 - 結果、度重なる不具合や開発生産性の低下から大きなリプレイスが必要になったが、 踏み込むタイミング（数億円規模）を見失いがち
 23
24. win-winを作るエンジニアリングの言語化
 - 開発優先度をブラックボックスにせずに伝える
 - 新規開発やエンハンス開発といった機能を増やすではない 
 - ミドルウェアのバージョンアップ、セキュリティーへの対応、テストの追加やイケてない設計 のリファクタリング、開発生産性をあげるルール改善、新しいメンバーのオンボーディングな ど
 - ユーザーに直接的に価値を届ける以外の様々なIssueがバックログへ 
 - 🙋この案件を差し込もうとすると半年後です。状態へ 
 - ちゃんと説明責任を果たさないと「何しているかわからないがいつも忙しそう」と 見られる。細かく優先度をつけられる
 
 24
25. 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
26. 26 - ソフトウェア事業の失敗と技術負債
 - 事業責任者が気づくべき、技術負債アラート早見表
 Table of Contents

27. 予測精度の幅を見る
 可観測性（オブザーバビリティー）を見るのと同じように
 とりあえず、各予測フェーズと予実の入出力のズレを見てみる
 
 なぜズレるのかは一旦置いといてデータを見てみてほしい
 27
28. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 
 リリース
 （実績）
 
 1人月
 10人月
 一般的に
 このぐらいだろう
 バックログ
 アイテムに分解した
 結果、倍ぐらいか かった
 PRD / DD
 書いた
 企画
 設計→Ready
 開発中
 振り返り

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

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

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

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

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

34. 参考文献
 
 - 開発生産性の低下による、事業の失敗はなぜ起こるのか | 石垣 雅人 | 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