Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

技術負債による事業の失敗はなぜ起こるのか / Why do business failures...

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

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

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

  1. 2 About me
 石垣 雅人
 合同会社 DMM.com
 プラットフォーム開発本部 部長 


    ・著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版) 
 ・連載中 : 『開発生産性の多角的視点』(CodeZine) 
 ・連載中 : 『スモールチームが武器になる時代へ』(ProductZine) 
 ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』(NewsPicks)
 
 2
  2. 事業の計画性と予算
 A-1施策
 チームA
 → 来期
 A-2施策
 B-1施策
 B-2施策
 B-3施策
 A-3施策


    A-4施策
 チームB
 売上
 t
 B-4施策
 A-5施策
 開 発 計 画
 予 算 計 画
 YoY 130%
 上半期
 下半期
 11
  3. 時間がかかりすぎて、間に合わなかった価値がある
 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
  4. 追加予算の分だけ売上を作らないといけない
 A-1施策
 チームA
 A-2施策
 B-1施策
 B-2施策
 B-3施策
 A-3施策
 チームB
 A-5施策


    開 発 計 画
 A-4施策
 B-4施策
 予算(開発予算)
 追加予算
 予算
 予 算 計 画
 コ ス ト
 差し込み
 獲得できなかった価値
 13
  5. 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(失敗とは): マーティンファウラー

  6. 初動で少しズレ始めたからといって 
 リカバリープランをエンジニア側に求めてもしょうがない 
 → この感覚をどう伝えるか 
 不確実性コーンを頭ではなく実態として適合していく
 本来はランニングしていきながら 


    検査・適応の中で、少しずつ歯車を合わせて行く 不確実性が高いのに 
 最初に色々と決めすぎている 
 契約もある
 引用 : https://xtech.nikkei.com/it/article/COLUMN/20131001/508039/

  7. 19 課題解決が遅くなればなるほど、詰む
 課題認識
 課題解決の遂行
 課題解決の遂行 課題認識
 報告
 リリース日
 報告
 リカバリープランが豊富


    時間がなくリカバリープランがない 
 (且つ二次被害が起きる) 
 隠されている失敗
 a)
 b)
 t

  8. 事業責任者の心情
 技術負債への解釈
 - そもそも内部品質が改善したら、どうなるのかがわからない
 - 実際に多いのはエンジニア自身もその効用がよくわかっていない。故にうまく説明でき ない / してもらえない
 -

    リファクタリングをすることは良いことは知っているが、かと言ってどこまで必要なのかが わからないので予算見込みが不明
 - 結果、度重なる不具合や開発生産性の低下から大きなリプレイスが必要になったが、 踏み込むタイミング(数億円規模)を見失いがち
 23
  9. win-winを作るエンジニアリングの言語化
 - 開発優先度をブラックボックスにせずに伝える
 - 新規開発やエンハンス開発といった機能を増やすではない 
 - ミドルウェアのバージョンアップ、セキュリティーへの対応、テストの追加やイケてない設計 のリファクタリング、開発生産性をあげるルール改善、新しいメンバーのオンボーディングな ど


    - ユーザーに直接的に価値を届ける以外の様々なIssueがバックログへ 
 - 🙋この案件を差し込もうとすると半年後です。状態へ 
 - ちゃんと説明責任を果たさないと「何しているかわからないがいつも忙しそう」と 見られる。細かく優先度をつけられる
 
 24
  10. 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
  11. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 


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

  12. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 


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

  13. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 


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

  14. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 


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

  15. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 


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

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