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
2
1.4k
技術負債の「予兆検知」と「状況異変」のススメ / 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 / 石垣雅人
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
2
150
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
4
570
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
7
1.6k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.4k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
29
21k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
11
2.8k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
69
27k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.6k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.7k
Other Decks in Technology
See All in Technology
Cloud Native Scalability for Internal Developer Platforms
hhiroshell
2
420
Tenstorrent 開発者プログラム
tenstorrent_japan
0
300
OCI Oracle Database Services新機能アップデート(2025/03-2025/05)
oracle4engineer
PRO
1
140
New Cache Hierarchy for Container Images and OCI Artifacts in Kubernetes Clusters using Containerd / KubeCon + CloudNativeCon Japan
pfn
PRO
0
150
Securing your Lambda 101
chillzprezi
0
240
Amazon Q Developer for GitHubとAmplify Hosting でサクッとデジタル名刺を作ってみた
kmiya84377
0
2.6k
Grafana MCP serverでなんかし隊 / Try Grafana MCP server
kohbis
0
330
比起獨自升級 我更喜歡 DevOps 文化 <3
line_developers_tw
PRO
0
110
DB 醬,嗨!哪泥嘎斯基?
line_developers_tw
PRO
0
120
Autonomous Database サービス・アップデート (FY25)
oracle4engineer
PRO
2
760
讓測試不再 BB! 從 BDD 到 CI/CD, 不靠人力也能 MVP
line_developers_tw
PRO
0
120
今からでも間に合う! 生成AI「RAG」再入門 / Re-introduction to RAG in Generative AI
hideakiaoyagi
1
160
Featured
See All Featured
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Designing for humans not robots
tammielis
253
25k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.8k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Six Lessons from altMBA
skipperchong
28
3.8k
Thoughts on Productivity
jonyablonski
69
4.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
349
20k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Optimizing for Happiness
mojombo
379
70k
A Modern Web Designer's Workflow
chriscoyier
693
190k
4 Signs Your Business is Dying
shpigford
184
22k
Practical Orchestrator
shlominoach
188
11k
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 まとめ