Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Masato Ishigaki / 石垣雅人

February 11, 2025
Tweet

More Decks by Masato Ishigaki / 石垣雅人

Other Decks in Technology

Transcript

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


    VPoE室 / アルファ室
 
 ・著 : 『正しく』失敗できるチームを作る(技術評論社, 2025) new
 ・著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版,2020) 
 ・連載中 : 『開発生産性の多角的視点』(CodeZine) 
 ・連載中 : 『スモールチームが武器になる時代へ』(ProductZine) 
 ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』(NewsPicks)
 
 2
  2. 6 予兆検知をして課題を洗い出す
 開発
 0→1
 健全な
 ソフトウェア
 変更容易性が低い
 ソフトウェア
 t 健全な


    ソフトウェア
 【抑制】
 負債の進行をできるだけ遅らせる
 【解消】
 負債の解消を早める
 【予兆検知】
 予兆をモニタリングし、アラートをかける

  3. 7 予兆検知をして課題を洗い出す
 開発
 0→1
 健全な
 ソフトウェア
 変更容易性が低い
 ソフトウェア
 【抑制】
 負債の進行をできるだけ遅らせる


    いかにして保守性が悪いソフトウェアができて、
 開発生産性が下がっていくかの予兆を検知する
 仕様書
 開発環境
 バージョン管理・CI/CD 
 テスト・静的解析 
 CI/CD
 RC / STG / PRD
 ・コードの複雑性
 ┗ クラス・モジュール設計 
 ┗ SOLID原則 
 ・〇〇図の欠如による仕 様漏れの手戻り
 
 ・環境差異による障害 
 ・可観測性の欠如
 ・テストケース漏れ
 ・リリース作業の属人化 

  4. 8 予兆検知 = 負債のキャッチアップはどこか
 1. 計画見積もりと実績値の差分で予兆検知
 a. ブラックボックステスト
 2. コードの変更やレビューにかかる時間が増加で予兆検知


    a. 主にFour keysデータ
 3. 障害件数の再発防止策完了件数で予兆検知
 a. ポストモーテム分析
 4. エンゲージメントスコアの低下で予兆検知
 a. 社員モチベーションの移動平均 
 オススメ順

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


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


    リリース
 (実績)
 
 1人月
 10人月
 一般的に
 このぐらいだろう
 (類推見積もり)
 バックログ
 アイテムに分解した
 結果、倍ぐらいか かった
 PRD / DD
 書いた
 企画
 設計→Ready
 開発中
 振り返り
 ここのズレが大きいと予 兆あり
 色んな原因が混在
 11
  7. 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
 障害件数だけではなく 
 再発防止策が完了できているか 
 その分、新規開発リソースを圧迫する。 
 ただし、スケジュールはそのままなことが多い 
 ポストモーテムを分析し、だいたい同じ箇所・プロセスで障害になっていないか 
 設計ミスでバグ混入 / デプロイ周辺で障害 / 特定のメンバー作業
  8. 16 経営層 / 事業責任者への説明
 「コスト」ではなく、将来への「投資」であることを伝える
 実際リファクタリングに否定的な事業サイドの人はおらず、 
 「なぜか」を説明できないエンジニアが多い。 
 短期的な効果


    - 〇ヶ月間のリファクタリングで、開発スピードが〇%向上し、新機能リリースまでの時間が短縮される
 - 変更容易性の向上により、今後の機能追加のリードタイムが〇%短縮される
 
 中長期的な効果
 - バグ修正コストの削減(障害発生率〇%低下、ホットフィックスの削減)
 - 採用力の向上(モダンな技術環境により優秀なエンジニアを惹きつけやすくなる)
 - 退職率の低下(技術負債のストレスによる離職を防ぎ、組織の安定化を図る)

  9. 新規開発
 エンハンス開発
 保守開発
 運用
 管理業務、その他 
 現状システムの維持費用
 新しい価値を作れる費用
 資産化
 費用化


    ※ 実態としてはエンハンス開発に保守開発が混在しているので もう少し比率が変動する 
 【開発区分の構造】
 ・約48%が「新しい価値を作れる費用」= 新規・エンハンス開発(アジャイル文脈)
 ・約7%が「将来への投資にかける費用」=保守開発
 ・約37%が「運用・開発以外の費用」= 運用・管理業務、その他
 現状の区分を分析し、「将来への投資にかける費用」を適切に増やす
 保守開発※の確保が「抑制」に繋がる第1歩目
 
 ※ 保守開発 : 資産価値を耐久年数を維持する・伸ばす(振る舞いを大きく変 えずに内部品質を整え、現状維持を行うリファクタリング・バージョンアップ等)
 
 ※ 勤怠と工数管理を紐づけてDWH連携 
 17
  10. 解消 = 負債を脱却する 
 基本方針
 - 作り変えは1年以内に終わらせるように予算を作り突っ込む(大規模でも) 
 - 2年以上経つと完了している頃には

    2年前の設計になっているため
 
 チーム分割方針
 - 同じチームで保守開発の割合を増やしても現状のチーム人数だと解消に足りない負債の場 合、
 - 分岐1. 人を増やしても耐えきれるチームであれば 既存チームでやる
 - 分岐2. 耐えきれない場合は、専門チームとして切り出してやる(ことがおおい) 
 20
  11. 解消 = 既存チーム vs 専門チーム
 既存チームでの負債解消
 メリット
 - 既存のシステムに精通しているため、 負債の影響を正しく把握できる

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