技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept

2025/02/12 技術的負債解消の軌跡～現場と経営をつなぐ実践事例～
https://findy.connpass.com/event/343423/

Transcript

1. 技術負債の
 「予兆検知」と「状況異変」のススメ
 
 1 Masato Ishigaki
 Fed. 12, 2025

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

5. - 予兆検知をして課題を洗い出す
 - 負債のキャッチアップはどこか
 - 経営/事業責任者への説明
 - 抑制 = 「将来への投資にかける費用」の優先順位
 - 解消 = 負債を脱却する
 5 Table of Contents

6. 6 予兆検知をして課題を洗い出す
 開発
 0→1
 健全な
 ソフトウェア
 変更容易性が低い
 ソフトウェア
 t 健全な
 ソフトウェア
 【抑制】
 負債の進行をできるだけ遅らせる
 【解消】
 負債の解消を早める
 【予兆検知】
 予兆をモニタリングし、アラートをかける

7. 7 予兆検知をして課題を洗い出す
 開発
 0→1
 健全な
 ソフトウェア
 変更容易性が低い
 ソフトウェア
 【抑制】
 負債の進行をできるだけ遅らせる
 いかにして保守性が悪いソフトウェアができて、
 開発生産性が下がっていくかの予兆を検知する
 仕様書
 開発環境
 バージョン管理・CI/CD 
 テスト・静的解析 
 CI/CD
 RC / STG / PRD
 ・コードの複雑性
 ┗ クラス・モジュール設計 
 ┗ SOLID原則 
 ・〇〇図の欠如による仕 様漏れの手戻り
 
 ・環境差異による障害 
 ・可観測性の欠如
 ・テストケース漏れ
 ・リリース作業の属人化 

8. 8 予兆検知 = 負債のキャッチアップはどこか
 1. 計画見積もりと実績値の差分で予兆検知
 a. ブラックボックステスト
 2. コードの変更やレビューにかかる時間が増加で予兆検知
 a. 主にFour keysデータ
 3. 障害件数の再発防止策完了件数で予兆検知
 a. ポストモーテム分析
 4. エンゲージメントスコアの低下で予兆検知
 a. 社員モチベーションの移動平均 
 オススメ順

9. 9 計画見積もりと実績値の差分（ブラックボックステスト）
 で予兆検知する
 引用: IPA 「IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 最新定量データと分析結果」 
 計画より上回っている
 計画より下回っている

10. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 
 リリース
 （実績）
 
 1人月
 10人月
 一般的に
 このぐらいだろう
 (類推見積もり)
 バックログ
 アイテムに分解した
 結果、倍ぐらいか かった
 PRD / DD
 書いた
 企画
 設計→Ready
 開発中
 振り返り
 予測（見積もり）
 コミットメント（約束）
 実績
 10
11. 計画工数
 予測
 フェーズ
 超概算
 (予測)
 詳細
 (予測)
 開発
 (予測)
 
 リリース
 （実績）
 
 1人月
 10人月
 一般的に
 このぐらいだろう
 (類推見積もり)
 バックログ
 アイテムに分解した
 結果、倍ぐらいか かった
 PRD / DD
 書いた
 企画
 設計→Ready
 開発中
 振り返り
 ここのズレが大きいと予 兆あり
 色んな原因が混在
 11
12. 12 コードの変更やレビューにかかる時間が増加
 で予兆検知する
 ※ Findy Team+

13. 13 障害件数の再発防止策完了件数
 で予兆検知する
 
 1月
 2月
 3月
 4月
 5月
 6月
 発生件数
 +3
 +2
 +4
 0
 +1
 +3
 再発防止策完了件数 
 +1
 +2
 +0
 +1
 +3
 +2
 残 : 再発防止策完了件数 
 2
 2
 6
 5
 3
 2
 障害件数だけではなく 
 再発防止策が完了できているか 
 その分、新規開発リソースを圧迫する。 
 ただし、スケジュールはそのままなことが多い 
 ポストモーテムを分析し、だいたい同じ箇所・プロセスで障害になっていないか 
 設計ミスでバグ混入 / デプロイ周辺で障害 / 特定のメンバー作業
14. 14 エンゲージメントスコアの低下
 で予兆検知する
 
 モチベーションサーベイを確認する
 wevox / SPACE / 社内アンケート...etc 

15. - 予兆検知をして課題を洗い出す
 - 負債のキャッチアップはどこか
 - 経営/事業責任者への説明
 - 抑制 = 「将来への投資にかける費用」の優先順位
 - 解消 = 負債を脱却する
 15 Table of Contents

16. 16 経営層 / 事業責任者への説明
 「コスト」ではなく、将来への「投資」であることを伝える
 実際リファクタリングに否定的な事業サイドの人はおらず、 
 「なぜか」を説明できないエンジニアが多い。 
 短期的な効果
 - 〇ヶ月間のリファクタリングで、開発スピードが〇%向上し、新機能リリースまでの時間が短縮される
 - 変更容易性の向上により、今後の機能追加のリードタイムが〇%短縮される
 
 中長期的な効果
 - バグ修正コストの削減（障害発生率〇%低下、ホットフィックスの削減）
 - 採用力の向上（モダンな技術環境により優秀なエンジニアを惹きつけやすくなる）
 - 退職率の低下（技術負債のストレスによる離職を防ぎ、組織の安定化を図る）

17. 新規開発
 エンハンス開発
 保守開発
 運用
 管理業務、その他 
 現状システムの維持費用
 新しい価値を作れる費用
 資産化
 費用化
 ※ 実態としてはエンハンス開発に保守開発が混在しているので もう少し比率が変動する 
 【開発区分の構造】
 ・約48%が「新しい価値を作れる費用」= 新規・エンハンス開発（アジャイル文脈）
 ・約7%が「将来への投資にかける費用」=保守開発
 ・約37%が「運用・開発以外の費用」= 運用・管理業務、その他
 現状の区分を分析し、「将来への投資にかける費用」を適切に増やす
 保守開発※の確保が「抑制」に繋がる第1歩目
 
 ※ 保守開発 : 資産価値を耐久年数を維持する・伸ばす（振る舞いを大きく変 えずに内部品質を整え、現状維持を行うリファクタリング・バージョンアップ等）
 
 ※ 勤怠と工数管理を紐づけてDWH連携 
 17
18. 「将来への投資にかける費用」の優先順位
 優先順位（プライオリティー）というより 開発区分の割合に着目する。
 
 必ず必達したい機能開発だけの人件費ではなく、 保守開発に必要な工数をきちんと積む。
 現在の人数で出来ないのであれば、採用するか管理業務を見直して工数を 捻出する
 
 人を増やしたいが、何に使うのかを説明できない人が多い（あとチームを増やしすぎてヘッドカウント を整えがちになる）
 新規開発
 エンハンス開発
 保守開発
 運用
 管理業務、その他 
 ここだけで開発リソースの計算が完結しがち
 この2つも見る
 18
19. - 予兆検知をして課題を洗い出す
 - 負債のキャッチアップはどこか
 - 経営/事業責任者への説明
 - 抑制 = 「将来への投資にかける費用」の優先順位
 - 解消 = 負債を脱却する
 19 Table of Contents

20. 解消 = 負債を脱却する 
 基本方針
 - 作り変えは1年以内に終わらせるように予算を作り突っ込む（大規模でも） 
 - 2年以上経つと完了している頃には 2年前の設計になっているため
 
 チーム分割方針
 - 同じチームで保守開発の割合を増やしても現状のチーム人数だと解消に足りない負債の場 合、
 - 分岐1. 人を増やしても耐えきれるチームであれば 既存チームでやる
 - 分岐2. 耐えきれない場合は、専門チームとして切り出してやる（ことがおおい） 
 20
21. 解消 = 既存チーム vs 専門チーム
 既存チームでの負債解消
 メリット
 - 既存のシステムに精通しているため、 負債の影響を正しく把握できる 
 - 機能開発と並行して改善を進めることで、業務への影響を最小限に抑えられる 
 デメリット
 - 機能開発のプレッシャーが強いと、リファクタリングの優先度が下がりがち 
 - 「今すぐに成果が求められる開発」と「長期的な技術的改善」の バランスが難しい
 
 専門チームでの負債解消
 メリット
 - 他チームの負担を増やさず、技術的な改善を推進できる 
 デメリット
 - プロダクト開発チームとの連携が必要（分断されると新たな負債が発生する可能性がある） 
 - 技術的な改善とビジネス要求の優先順位を調整する必要がある 
 - 対象プロダクトへの予算やヘッドカウントの確保 が追加で必要
 21
22. - 負債の予兆をプロダクトごとの勘所を見つけを検知し、抑制していく
 - できるだけ資産の耐久年数を長くし、一定期間で解消 = 脱却していく
 22 まとめ