技術的負債の利息とは何か

技術的負債を道徳の問題として語ると結論は出ません。これは経済の問題です。借りを作り、以後の操作が毎回利子を払っています。

利子は数値化できる

症状	測定できる指標
一箇所の変更で多数のファイルを触る	変更あたりのファイル数
触るのが怖い	壊していないことを示す試験があるか
フィールド追加で五箇所直す	同じ概念の定義箇所数
ビルドが遅くなる	編集から結果が見えるまでの秒数
新しい人の立ち上がりが遅い	clone から最初の修正まで日数

症状を数値に訳せば、負債は意見ではなく事実になります。

元本と利子

• 元本：その部分を書き直す一度きりの費用
• 利子：以後の変更が毎回払う追加時間

返すべきかは、元本と将来の利子の合計を比べます。

リファクタ費用：3 日
フィールド追加ごとの追加：2 時間
今後追加する数：20 → 40 時間 ≈ 5 日
結論：今リファクタする方が得

そのモジュールを三か月触らないなら、利子はゼロで返す必要はありません。 危険なのは負債の存在ではなく、高利子の領域に積み上がることです。

高利子の領域

• 全員が依存する中核の型：一変更が全体に波及
• 毎回のリリースで手作業の手順：一つ飛ばすと事故
• 誰も触れない起動スクリプト：壊れたとき追跡不能
• 試験が無い重要経路：変更は運任せ

最初の二つは複利です。毎回払ううえ、規模とともに高くなります。

意図的な借り入れは許される

「今出す、一週間後に直す」は正当な判断です。条件は書き残すことです。

TODO(負債): 決済コールバックが同期処理で、時間切れで注文が消える。
影響: 繁忙時に注文を失い得る。
返済: 非同期の待ち行列へ、約 1 日。
期限: 公開後二週間以内。

要点は期限です。期限の無い TODO は永久の負債で、しかも当時トレードオフだったことを誰も覚えていません。後から読む人には意味不明なコードに見えるだけです。

醜さを負債と呼ぶな

不格好な名前、少し長い関数、少ないコメント。それらが将来の変更費用を上げないなら、負債ではなく流儀です。負債と呼ぶと本物の負債が埋もれます。

判定は一つです。次の変更でいくら余分に払うか。払えない分だけが返済に値します。