技術的負債との付き合い方
短期的な近道が将来のコストになる技術的負債の性質と、返済の優先順位をつける考え方を学ぶ
技術的負債とは
技術的負債は、期限内のリリースを優先して選んだ 近道や妥協が、将来の開発速度を遅くする形で「利子」を伴って返ってくることを、 金融の負債にたとえた考え方です。負債そのものが常に悪いわけではなく、 意図的に選ぶ場合と、無意識に生まれる場合があります。
Martin Fowlerは技術的負債を「意図的か無意識か」「思慮深いか無謀か」の2軸で整理しています。
思慮深く・意図的な負債
「今回は期限を優先してこの設計で進め、後で見直す」と自覚した上で選ぶ近道。 チームで合意し、返済計画を残しておくことが重要。
無謀・意図的な負債
「設計を考えている時間はない、とにかく今は動かす」とリスクを承知の上で近道を選ぶ。 その場では速く見えても、後で必ず利子として跳ね返ってくる。
思慮深く・無意識の負債
実装を終えて初めて「本当はこう設計すべきだった」と分かる負債。 設計時点では最善だと思えた判断が、経験の蓄積によって後から見直される。
無謀・無意識な負債
設計を知らない、あるいは考慮せずに書かれたコードによって、後から気づく負債。 コードレビューや設計知識の共有で減らしていくべきもの。
「利子」が意味するもの
技術的負債を放置すると、その部分に関わる変更のたびに理解や修正のコストが積み重なります。 この積み重なるコストを、金融の利子にたとえています。
負債を放置した場合の典型的な進行
1回目の変更: 複雑な条件分岐を読み解くのに30分余分にかかる
2回目の変更: さらに条件分岐が増え、読み解きに1時間かかる
3回目の変更: 誰も全体を把握できず、変更のたびに新しいバグが混入する
→ 「利子」が積み重なり、最終的な開発速度が大きく低下する優先順位のつけ方: 全部返すのではなく戦略的に
技術的負債をすべて解消しようとして開発を長期間止めるのは現実的ではありません。利子の高い負債から優先的に返済する戦略が有効です。
- 変更頻度の高い箇所: よく手を入れる部分の負債は利子が積み重なりやすい
- 障害の発生源になりやすい箇所: バグの温床になっている負債は優先度が高い
- 新機能開発を妨げている箇所: そこを直さないと次の開発が進まない負債
- 滅多に触らない箇所: 多少の負債があっても影響が小さく、後回しでよい
現実的な進め方
新機能開発を止めて負債返済に専念するのではなく、「触るついでに直す(ボーイスカウトルール)」や スプリントの一定割合を負債返済にあてるなど、開発と並行して継続的に返していくのが実務的です。
負債を可視化・追跡する
負債は「なんとなく気になっている」状態のままにせず、記録して可視化することで、 チーム全体で優先順位を議論できるようになります。
// TODOコメントによる記録の例
// TODO(tech-debt): この関数は注文種別ごとの分岐が複雑化している。
// 新しい注文種別を追加する際は、まずポリモーフィズムでの整理を検討すること。
// 関連issue: #482
// 負債レジストリ(バックログ)の項目例
- [ ] 決済モジュールのテストカバレッジ不足(利子: 高, 変更頻度: 高)
- [ ] 通知バッチの重複コード整理(利子: 中, 変更頻度: 低)ポイント
- 技術的負債には意図的なものと無意識なものがあり、意図的な負債は合意と返済計画が重要
- 負債を放置すると変更コストが「利子」として積み重なっていく
- すべてを一度に返すのではなく、変更頻度や影響度が高い箇所から戦略的に返済する
- TODOコメントや負債レジストリで可視化し、開発と並行して継続的に返していく
確認クイズ
1 / 3技術的負債における「利子」が意味するものとして正しいものはどれか？