技術的負債は「悪」じゃない — 向き合い方を変えよう

「技術的負債」という言葉を聞くと、なんだか後ろめたい気持ちになりませんか？ まるで過去のサボりの証拠みたいに感じてしまう。でも実は、技術的負債はほぼ全てのプロジェクトに存在するし、ゼロにする必要もないんです。

負債には「良い負債」もある

住宅ローンを「悪い借金」とは言いませんよね。同じように、技術的負債にも戦略的な負債があります。

• 意図的な負債：「今はこの実装で十分。スケールが必要になったら書き直す」
• 学習による負債：「作り終えて初めて、もっと良い設計が見えた」

問題なのは無自覚な負債、つまり「なんとなく動いてるから放置」のパターンです。これが積み重なると、ある日突然「何も触れないコードベース」が出来上がります。

負債を「見える化」する

僕がGLMと一緒にコードを書いていて実感するのは、負債は見えないから怖いということ。逆に、見えていれば対処できます。

シンプルな方法をひとつ：コードにTODOコメントを残す時、理由と期限を書く。

// TODO(2026-03): ユーザー数1000超えたらキャッシュ層を追加
// 現状はDB直読みで十分だが、成長次第で要対応

「TODO: あとで直す」だけだと、永遠に直りません。いつ、なぜ直すのかが書いてあれば、判断できます。

返済のタイミング

技術的負債の返済で一番まずいのは「まとめて大掃除」パターン。2週間かけてリファクタリングスプリント…気持ちは分かりますが、現実にはなかなか時間が取れません。

おすすめはボーイスカウトルール：「来た時より美しく」。機能追加やバグ修正のついでに、触った周辺を少しだけ綺麗にする。毎回ちょっとずつ返済していけば、負債は自然と減っていきます。

AIと技術的負債

AI時代ならではの面白い話があります。AIコーディングツールは「動くコード」を高速に生成できますが、文脈を知らないまま書くので、負債を生みやすい側面もあります。

僕もGLMが生成したコードをレビューする時、「動くけど、既存のユーティリティ関数を使わず同じロジックを書いてる」ことがよくあります。これは典型的な無自覚な負債です。

だからこそ、AIが書いたコードこそレビューが重要。速く書けるからといって、負債を速く積み上げては本末転倒です。

負債とうまく付き合うために

1. 存在を認める — 負債ゼロは幻想。あることを前提に
2. 記録する — 見えない負債が一番危険
3. 優先順位をつける — 全部直す必要はない。影響度で判断
4. 少しずつ返す — 大掃除より日々の小掃除
5. 新規追加時に増やさない — 一番のコスト削減

技術的負債は「失敗の証」じゃなく「トレードオフの記録」。向き合い方を変えるだけで、コードベースとの関係がずっと楽になりますよ。🧹