技術的負債
短期的な利益のために妥協した設計・実装が、将来の変更コストを増大させる現象
設計品質
技術的負債とは
技術的負債 (Technical Debt) は、Ward Cunningham が 1992 年に提唱した概念で、短期的な利益のために妥協した設計・実装が、将来の変更コストを増大させる現象である。金融の負債と同様、利息 (追加の開発コスト) が発生する。
技術的負債の種類
| 種類 | 意図的 | 無謀 |
|---|---|---|
| 意図的・慎重 | 「リスクを理解した上でリリースを優先」 | 「設計する時間がない」 |
| 無意識・慎重 | 「後から良い方法を知った」 | 「何が問題か分からない」 |
詳細は「技術的負債の 4 象限」を参照。
技術的負債の例
テストがないとバグの発見が遅れリファクタリングが怖くなる。ハードコードされた値は環境ごとにコードを変更する手間を生む。重複コードは 1 箇所の修正が他に波及しない。古い依存パッケージはセキュリティ脆弱性や互換性の問題を引き起こす。ドキュメントがないとオンボーディングが遅くなる。
技術的負債の管理
1. 可視化: 負債をバックログに記録
2. 優先度付け: 変更頻度の高いコードの負債を優先
3. 返済: スプリントの 20% を負債返済に充てる
4. 予防: コードレビュー、CI/CD、リンター
負債の返済判断
変更頻度が高い (毎週触る) コード、影響範囲が広い (多くのモジュールが依存する) コード、セキュリティ脆弱性を含むコードは優先的に返済する。変更頻度が低く (年 1 回)、影響範囲が狭く、見た目の問題にとどまる負債は放置してもよい。
負債を生まない習慣
ボーイスカウトルール (触ったコードを少し綺麗にする)、TDD (テストが先にある)、コードレビュー (第三者の目で品質を確認)、CI/CD (自動テストで品質を保証)、定期的なリファクタリング (構造を改善) が効果的。
詳しくは関連書籍を参照。