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 / 石垣雅人
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.5k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
2
170
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
5
580
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
7
1.7k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.5k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / 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
Other Decks in Technology
See All in Technology
Snowflake Summit 2025 データエンジニアリング関連新機能紹介 / Snowflake Summit 2025 What's New about Data Engineering
tiltmax3
0
300
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
400
Navigation3でViewModelにデータを渡す方法
mikanichinose
0
220
Microsoft Build 2025 技術/製品動向 for Microsoft Startup Tech Community
torumakabe
2
250
監視のこれまでとこれから/sakura monitoring seminar 2025
fujiwara3
11
3.8k
“社内”だけで完結していた私が、AWS Community Builder になるまで
nagisa53
1
350
地図も、未来も、オープンに。 〜OSGeo.JPとFOSS4Gのご紹介〜
wata909
0
110
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
3
800
Windows 11 で AWS Documentation MCP Server 接続実践/practical-aws-documentation-mcp-server-connection-on-windows-11
emiki
0
920
Witchcraft for Memory
pocke
1
220
BrainPadプログラミングコンテスト記念LT会2025_社内イベント&問題解説
brainpadpr
1
160
SalesforceArchitectGroupOsaka#20_CNX'25_Report
atomica7sei
0
140
Featured
See All Featured
Making Projects Easy
brettharned
116
6.3k
The Cult of Friendly URLs
andyhume
79
6.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
930
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
A Tale of Four Properties
chriscoyier
160
23k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
The Straight Up "How To Draw Better" Workshop
denniskardys
233
140k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
A Modern Web Designer's Workflow
chriscoyier
694
190k
Bash Introduction
62gerente
614
210k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
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 まとめ