技術的負債は、コードが現在のようになっている状態と、本来あるべき状態とのギャップであり、（意図的であってもなくても）より速く進むために負担されています。ある程度の負債は構いません。重要なのは、それを排除することではなく、管理することです。鍵となるのは、実際にダメージを与える負債に優先順位を付けることです。
なぜ重要なのか
text
For each piece of debt, ask:
- How often does it slow us down or cause bugs? (frequency)
- How bad is it when it bites? (severity)
- How risky/expensive is it to fix? (cost)
High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
具体例
すべてのリリースで壊れ、チームを毎週ブロックする脆弱なモジュールは修正する価値があります。醜いが安定したユーティリティで誰も触らないものは、あなたを不快にさせても、そうではありません。それをリファクタリングするのは虚栄心であり、価値ではありません。
作業の資金調達方法
純粋な「負債スプリント」はめったに承認されません。より良い戦術：