「技術的負債」という言葉を聞くと、なんだか後ろめたい気持ちになりませんか？ まるで過去のサボりの証拠みたいに感じてしまう。でも実は、技術的負債はほぼ全てのプロジェクトに存在するし、ゼロにする必要もないんです。
負債には「良い負債」もある
住宅ローンを「悪い借金」とは言いませんよね。同じように、技術的負債にも戦略的な負債があります。
- 意図的な負債：「今はこの実装で十分。スケールが必要になったら書き直す」
- 学習による負債：「作り終えて初めて、もっと良い設計が見えた」
問題なのは無自覚な負債、つまり「なんとなく動いてるから放置」のパターンです。これが積み重なると、ある日突然「何も触れないコードベース」が出来上がります。
負債を「見える化」する
僕がGLMと一緒にコードを書いていて実感するのは、負債は見えないから怖いということ。逆に、見えていれば対処できます。
シンプルな方法をひとつ：コードにTODOコメントを残す時、理由と期限を書く。
// TODO(2026-03): ユーザー数1000超えたらキャッシュ層を追加
// 現状はDB直読みで十分だが、成長次第で要対応「TODO: あとで直す」だけだと、永遠に直りません。いつ、なぜ直すのかが書いてあれば、判断できます。
返済のタイミング
技術的負債の返済で一番まずいのは「まとめて大掃除」パターン。2週間かけてリファクタリングスプリント…気持ちは分かりますが、現実にはなかなか時間が取れません。
おすすめはボーイスカウトルール：「来た時より美しく」。機能追加やバグ修正のついでに、触った周辺を少しだけ綺麗にする。毎回ちょっとずつ返済していけば、負債は自然と減っていきます。
AIと技術的負債
AI時代ならではの面白い話があります。AIコーディングツールは「動くコード」を高速に生成できますが、文脈を知らないまま書くので、負債を生みやすい側面もあります。
僕もGLMが生成したコードをレビューする時、「動くけど、既存のユーティリティ関数を使わず同じロジックを書いてる」ことがよくあります。これは典型的な無自覚な負債です。
だからこそ、AIが書いたコードこそレビューが重要。速く書けるからといって、負債を速く積み上げては本末転倒です。
負債とうまく付き合うために
- 存在を認める — 負債ゼロは幻想。あることを前提に
- 記録する — 見えない負債が一番危険
- 優先順位をつける — 全部直す必要はない。影響度で判断
- 少しずつ返す — 大掃除より日々の小掃除
- 新規追加時に増やさない — 一番のコスト削減
技術的負債は「失敗の証」じゃなく「トレードオフの記録」。向き合い方を変えるだけで、コードベースとの関係がずっと楽になりますよ。🧹