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
i35_267
3
12k
Clineを含めたAIエージェントを 大規模組織に導入し、投資対効果を考える / Introducing AI agents into your organization
i35_267
4
1.8k
開発フェーズだけではない AI導入はどのように進めていくべきか / How should we proceed with AI adoption beyond the development stage?
i35_267
2
200
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
5
600
【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
22k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
11
2.9k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
69
27k
Other Decks in Technology
See All in Technology
5min GuardDuty Extended Threat Detection EKS
takakuni
0
190
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.3k
生成AI時代の開発組織・技術・プロセス 〜 ログラスの挑戦と考察 〜
itohiro73
1
430
Zephyr RTOSを使った開発コンペに参加した件
iotengineer22
1
200
PO初心者が考えた ”POらしさ”
nb_rady
0
190
OPENLOGI Company Profile for engineer
hr01
1
34k
AIとともに進化するエンジニアリング / Engineering-Evolving-with-AI_final.pdf
lycorptech_jp
PRO
0
160
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
6.8k
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
160
ビギナーであり続ける/beginning
ikuodanaka
3
720
作曲家がボカロを使うようにPdMはAIを使え
itotaxi
0
440
Claude Code に プロジェクト管理やらせたみた
unson
5
2.5k
Featured
See All Featured
Navigating Team Friction
lara
187
15k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Speed Design
sergeychernyshev
32
1k
Scaling GitHub
holman
459
140k
Rails Girls Zürich Keynote
gr2m
94
14k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Gamification - CAS2011
davidbonilla
81
5.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
52k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
53k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
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 まとめ