技術的負債

短期的な利益のために妥協した設計・実装が、将来の変更コストを増大させる現象

設計品質

技術的負債とは

技術的負債 (Technical Debt) は、Ward Cunningham が 1992 年に提唱した概念で、短期的な利益のために妥協した設計・実装が、将来の変更コストを増大させる現象である。金融の負債と同様、利息 (追加の開発コスト) が発生する。

技術的負債の種類

種類 意図的 無謀
意図的・慎重 「リスクを理解した上でリリースを優先」 「設計する時間がない」
無意識・慎重 「後から良い方法を知った」 「何が問題か分からない」

詳細は「技術的負債の 4 象限」を参照。

技術的負債の例

テストがないとバグの発見が遅れリファクタリングが怖くなる。ハードコードされた値は環境ごとにコードを変更する手間を生む。重複コードは 1 箇所の修正が他に波及しない。古い依存パッケージはセキュリティ脆弱性や互換性の問題を引き起こす。ドキュメントがないとオンボーディングが遅くなる。

技術的負債の管理

1. 可視化: 負債をバックログに記録
2. 優先度付け: 変更頻度の高いコードの負債を優先
3. 返済: スプリントの 20% を負債返済に充てる
4. 予防: コードレビュー、CI/CD、リンター

負債の返済判断

変更頻度が高い (毎週触る) コード、影響範囲が広い (多くのモジュールが依存する) コード、セキュリティ脆弱性を含むコードは優先的に返済する。変更頻度が低く (年 1 回)、影響範囲が狭く、見た目の問題にとどまる負債は放置してもよい。

負債を生まない習慣

ボーイスカウトルール (触ったコードを少し綺麗にする)、TDD (テストが先にある)、コードレビュー (第三者の目で品質を確認)、CI/CD (自動テストで品質を保証)、定期的なリファクタリング (構造を改善) が効果的。

詳しくは関連書籍を参照。

関連用語