Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
Search
Masato Ishigaki / 石垣雅人
February 11, 2025
Technology
0
300
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
2025/02/12 技術的負債解消の軌跡~現場と経営をつなぐ実践事例~
https://findy.connpass.com/event/343423/
Masato Ishigaki / 石垣雅人
February 11, 2025
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
4
2.1k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
28
20k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
9
2.7k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
68
26k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.5k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.6k
内製化で強化させる、事業のスケーラビリティーとエンジニアの成長戦略 / insourcing
i35_267
2
390
見積もりをしない。
i35_267
4
1.3k
The Metrics Key_ Connecting Product, System, Team
i35_267
4
4.5k
Other Decks in Technology
See All in Technology
AWSエンジニアに捧ぐLangChainの歩き方
tsukuboshi
2
450
クラウドネイティブ時代を乗り越えるためのオブザーバビリティ(可観測性)ことはじめ_CloudNative-Observability
tkhresk
0
110
ろう・難聴者のコミュニケーションを円滑化する取り組み
chiemi627
0
120
サーバーレスアーキテクチャと生成AIの融合 / Serverless Meets Generative AI
_kensh
7
880
これからSREになる人と、これからもSREをやっていく人へ
masayoshi
4
3.7k
5分で紹介する生成AIエージェントとAmazon Bedrock Agents / 5-minutes introduction to generative AI agents and Amazon Bedrock Agents
hideakiaoyagi
0
140
自動と手動の両輪で開発するデータクレンジング
estie
2
170
SCSAから学ぶセキュリティ管理
masakamayama
0
130
Power BI は、レポート テーマにこだわろう!テーマのティア表付き
ohata_ds
0
140
サーバーレスで楽しよう!お気軽に始められる3つのポイント / Have fun with Serverless!
_kensh
3
290
talk_about_wasmwasi
junkishigaki
0
100
FastConnect の冗長性
ocise
1
9.4k
Featured
See All Featured
How GitHub (no longer) Works
holman
313
140k
A Tale of Four Properties
chriscoyier
158
23k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
7
240
GraphQLとの向き合い方2022年版
quramy
44
13k
Gamification - CAS2011
davidbonilla
80
5.1k
Speed Design
sergeychernyshev
25
770
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
VelocityConf: Rendering Performance Case Studies
addyosmani
328
24k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
11
920
The Language of Interfaces
destraynor
156
24k
Transcript
技術負債の 「予兆検知」と「状況異変」のススメ 1 Masato Ishigaki Fed. 12, 2025
2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム開発本部 第1開発部 部長
VPoE室 / アルファ室 ・著 : 『正しく』失敗できるチームを作る(技術評論社, 2025) new ・著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版,2020) ・連載中 : 『開発生産性の多角的視点』(CodeZine) ・連載中 : 『スモールチームが武器になる時代へ』(ProductZine) ・連載中 : 『群知能から紐解く、スケールする“組織“の作り方 』(NewsPicks) 2
None
- クリエイター組織は、約1,200名 - チーム数は、約200チーム - 現在進行中の開発プロジェクトは約500 4 DMM.comの開発組織アウトライン
- 予兆検知をして課題を洗い出す - 負債のキャッチアップはどこか - 経営/事業責任者への説明 - 抑制 = 「将来への投資にかける費用」の優先順位
- 解消 = 負債を脱却する 5 Table of Contents
6 予兆検知をして課題を洗い出す 開発 0→1 健全な ソフトウェア 変更容易性が低い ソフトウェア t 健全な
ソフトウェア 【抑制】 負債の進行をできるだけ遅らせる 【解消】 負債の解消を早める 【予兆検知】 予兆をモニタリングし、アラートをかける
7 予兆検知をして課題を洗い出す 開発 0→1 健全な ソフトウェア 変更容易性が低い ソフトウェア 【抑制】 負債の進行をできるだけ遅らせる
いかにして保守性が悪いソフトウェアができて、 開発生産性が下がっていくかの予兆を検知する 仕様書 開発環境 バージョン管理・CI/CD テスト・静的解析 CI/CD RC / STG / PRD ・コードの複雑性 ┗ クラス・モジュール設計 ┗ SOLID原則 ・〇〇図の欠如による仕 様漏れの手戻り ・環境差異による障害 ・可観測性の欠如 ・テストケース漏れ ・リリース作業の属人化
8 予兆検知 = 負債のキャッチアップはどこか 1. 計画見積もりと実績値の差分で予兆検知 a. ブラックボックステスト 2. コードの変更やレビューにかかる時間が増加で予兆検知
a. 主にFour keysデータ 3. 障害件数の再発防止策完了件数で予兆検知 a. ポストモーテム分析 4. エンゲージメントスコアの低下で予兆検知 a. 社員モチベーションの移動平均 オススメ順
9 計画見積もりと実績値の差分(ブラックボックステスト) で予兆検知する 引用: IPA 「IT企業4,564プロジェクト プロジェクトマネジメントの実践・改善に活かす 最新定量データと分析結果」 計画より上回っている
計画より下回っている
計画工数 予測 フェーズ 超概算 (予測) 詳細 (予測) 開発 (予測)
リリース (実績) 1人月 10人月 一般的に このぐらいだろう (類推見積もり) バックログ アイテムに分解した 結果、倍ぐらいか かった PRD / DD 書いた 企画 設計→Ready 開発中 振り返り 予測(見積もり) コミットメント(約束) 実績 10
計画工数 予測 フェーズ 超概算 (予測) 詳細 (予測) 開発 (予測)
リリース (実績) 1人月 10人月 一般的に このぐらいだろう (類推見積もり) バックログ アイテムに分解した 結果、倍ぐらいか かった PRD / DD 書いた 企画 設計→Ready 開発中 振り返り ここのズレが大きいと予 兆あり 色んな原因が混在 11
12 コードの変更やレビューにかかる時間が増加 で予兆検知する ※ Findy Team+
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 エンゲージメントスコアの低下 で予兆検知する モチベーションサーベイを確認する wevox / SPACE / 社内アンケート...etc
- 予兆検知をして課題を洗い出す - 負債のキャッチアップはどこか - 経営/事業責任者への説明 - 抑制 = 「将来への投資にかける費用」の優先順位
- 解消 = 負債を脱却する 15 Table of Contents
16 経営層 / 事業責任者への説明 「コスト」ではなく、将来への「投資」であることを伝える 実際リファクタリングに否定的な事業サイドの人はおらず、 「なぜか」を説明できないエンジニアが多い。 短期的な効果
- 〇ヶ月間のリファクタリングで、開発スピードが〇%向上し、新機能リリースまでの時間が短縮される - 変更容易性の向上により、今後の機能追加のリードタイムが〇%短縮される 中長期的な効果 - バグ修正コストの削減(障害発生率〇%低下、ホットフィックスの削減) - 採用力の向上(モダンな技術環境により優秀なエンジニアを惹きつけやすくなる) - 退職率の低下(技術負債のストレスによる離職を防ぎ、組織の安定化を図る)
新規開発 エンハンス開発 保守開発 運用 管理業務、その他 現状システムの維持費用 新しい価値を作れる費用 資産化 費用化
※ 実態としてはエンハンス開発に保守開発が混在しているので もう少し比率が変動する 【開発区分の構造】 ・約48%が「新しい価値を作れる費用」= 新規・エンハンス開発(アジャイル文脈) ・約7%が「将来への投資にかける費用」=保守開発 ・約37%が「運用・開発以外の費用」= 運用・管理業務、その他 現状の区分を分析し、「将来への投資にかける費用」を適切に増やす 保守開発※の確保が「抑制」に繋がる第1歩目 ※ 保守開発 : 資産価値を耐久年数を維持する・伸ばす(振る舞いを大きく変 えずに内部品質を整え、現状維持を行うリファクタリング・バージョンアップ等) ※ 勤怠と工数管理を紐づけてDWH連携 17
「将来への投資にかける費用」の優先順位 優先順位(プライオリティー)というより 開発区分の割合に着目する。 必ず必達したい機能開発だけの人件費ではなく、 保守開発に必要な工数をきちんと積む。 現在の人数で出来ないのであれば、採用するか管理業務を見直して工数を 捻出する 人を増やしたいが、何に使うのかを説明できない人が多い(あとチームを増やしすぎてヘッドカウント
を整えがちになる) 新規開発 エンハンス開発 保守開発 運用 管理業務、その他 ここだけで開発リソースの計算が完結しがち この2つも見る 18
- 予兆検知をして課題を洗い出す - 負債のキャッチアップはどこか - 経営/事業責任者への説明 - 抑制 = 「将来への投資にかける費用」の優先順位
- 解消 = 負債を脱却する 19 Table of Contents
解消 = 負債を脱却する 基本方針 - 作り変えは1年以内に終わらせるように予算を作り突っ込む(大規模でも) - 2年以上経つと完了している頃には
2年前の設計になっているため チーム分割方針 - 同じチームで保守開発の割合を増やしても現状のチーム人数だと解消に足りない負債の場 合、 - 分岐1. 人を増やしても耐えきれるチームであれば 既存チームでやる - 分岐2. 耐えきれない場合は、専門チームとして切り出してやる(ことがおおい) 20
解消 = 既存チーム vs 専門チーム 既存チームでの負債解消 メリット - 既存のシステムに精通しているため、 負債の影響を正しく把握できる
- 機能開発と並行して改善を進めることで、業務への影響を最小限に抑えられる デメリット - 機能開発のプレッシャーが強いと、リファクタリングの優先度が下がりがち - 「今すぐに成果が求められる開発」と「長期的な技術的改善」の バランスが難しい 専門チームでの負債解消 メリット - 他チームの負担を増やさず、技術的な改善を推進できる デメリット - プロダクト開発チームとの連携が必要(分断されると新たな負債が発生する可能性がある) - 技術的な改善とビジネス要求の優先順位を調整する必要がある - 対象プロダクトへの予算やヘッドカウントの確保 が追加で必要 21
- 負債の予兆をプロダクトごとの勘所を見つけを検知し、抑制していく - できるだけ資産の耐久年数を長くし、一定期間で解消 = 脱却していく 22 まとめ