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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

- クリエイター組織は、約1,200名  - チーム数は、約200チーム  - 現在進行中の開発プロジェクトは約500  4 DMM.comの開発組織アウトライン 

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

12 コードの変更やレビューにかかる時間が増加  で予兆検知する  ※ Findy Team+ 

Slide 13

Slide 13 text

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  障害件数だけではなく   再発防止策が完了できているか   その分、新規開発リソースを圧迫する。   ただし、スケジュールはそのままなことが多い   ポストモーテムを分析し、だいたい同じ箇所・プロセスで障害になっていないか   設計ミスでバグ混入 / デプロイ周辺で障害 / 特定のメンバー作業

Slide 14

Slide 14 text

14 エンゲージメントスコアの低下  で予兆検知する    モチベーションサーベイを確認する  wevox / SPACE / 社内アンケート...etc  

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

新規開発  エンハンス開発  保守開発  運用  管理業務、その他   現状システムの維持費用  新しい価値を作れる費用  資産化  費用化  ※ 実態としてはエンハンス開発に保守開発が混在しているのでもう少し比率が変動する   【開発区分の構造】  ・約48%が「新しい価値を作れる費用」= 新規・エンハンス開発（アジャイル文脈）  ・約7%が「将来への投資にかける費用」=保守開発  ・約37%が「運用・開発以外の費用」= 運用・管理業務、その他  現状の区分を分析し、「将来への投資にかける費用」を適切に増やす  保守開発※の確保が「抑制」に繋がる第1歩目    ※ 保守開発 : 資産価値を耐久年数を維持する・伸ばす（振る舞いを大きく変えずに内部品質を整え、現状維持を行うリファクタリング・バージョンアップ等）    ※ 勤怠と工数管理を紐づけてDWH連携   17

Slide 18

Slide 18 text

「将来への投資にかける費用」の優先順位  優先順位（プライオリティー）というより開発区分の割合に着目する。    必ず必達したい機能開発だけの人件費ではなく、保守開発に必要な工数をきちんと積む。  現在の人数で出来ないのであれば、採用するか管理業務を見直して工数を捻出する    人を増やしたいが、何に使うのかを説明できない人が多い（あとチームを増やしすぎてヘッドカウントを整えがちになる）  新規開発  エンハンス開発  保守開発  運用  管理業務、その他   ここだけで開発リソースの計算が完結しがち  この2つも見る  18

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

解消 = 負債を脱却する   基本方針  - 作り変えは1年以内に終わらせるように予算を作り突っ込む（大規模でも）   - 2年以上経つと完了している頃には 2年前の設計になっているため    チーム分割方針  - 同じチームで保守開発の割合を増やしても現状のチーム人数だと解消に足りない負債の場合、  - 分岐1. 人を増やしても耐えきれるチームであれば既存チームでやる  - 分岐2. 耐えきれない場合は、専門チームとして切り出してやる（ことがおおい）   20

Slide 21

Slide 21 text

解消 = 既存チーム vs 専門チーム  既存チームでの負債解消  メリット  - 既存のシステムに精通しているため、負債の影響を正しく把握できる   - 機能開発と並行して改善を進めることで、業務への影響を最小限に抑えられる   デメリット  - 機能開発のプレッシャーが強いと、リファクタリングの優先度が下がりがち   - 「今すぐに成果が求められる開発」と「長期的な技術的改善」のバランスが難しい    専門チームでの負債解消  メリット  - 他チームの負担を増やさず、技術的な改善を推進できる   デメリット  - プロダクト開発チームとの連携が必要（分断されると新たな負債が発生する可能性がある）   - 技術的な改善とビジネス要求の優先順位を調整する必要がある   - 対象プロダクトへの予算やヘッドカウントの確保が追加で必要  21

Slide 22

Slide 22 text

- 負債の予兆をプロダクトごとの勘所を見つけを検知し、抑制していく  - できるだけ資産の耐久年数を長くし、一定期間で解消 = 脱却していく  22 まとめ 