ひとことで言うと
技術的負債は、短期的な都合でコードや設計を妥協した結果として積み上がる、将来の改修・保守にかかる余分なコストです。
「とりあえず動けばいい」「締め切りに間に合わせるために簡単な方法で実装した」といった積み重ねが、時間とともに「触りにくい」「わかりにくい」コードベースを生み出します。 金融の「借金」と同様に、返済を後回しにするほど利息が積み上がるイメージです。
たとえ話でもう少し詳しく
技術的負債は、家の修繕を後回しにし続けることに近いです。
- 雨漏りを応急処置だけで済ませた
- 電気配線の老朽化を見て見ぬふりした
- 使いにくい間取りを変えないまま何年も過ごした
住み続けることはできますが、問題は静かに積み上がっています。 ある日「全面的に直さないと限界」という状態になったとき、最初に直していれば安く済んだはずの費用が何倍にもなります。
コードも同じです。 その場しのぎの実装、重複したコード、わかりにくい命名——これらが積み重なると、新機能を追加するたびに「どこを触ればいいかわからない」「ここを変えると別の場所が壊れる」という状態になっていきます。
よく出る場面・使いどころ
- リリースを急ぐあまり、設計を深く考えずに実装したとき
- 人手や時間が足りず、テストやドキュメントを省いたとき
- 古いシステムに新機能を継ぎ足し続けて、全体の構造がぼろぼろになってきたとき
- 「あとで直す」と言いながら何年も放置されているコードがあるとき
似た言葉との違い
- バグ
- 意図しない動作や誤りそのもの
- 技術的負債は動いているが将来の変更を困難にする設計上の問題で、バグとは別
- リファクタリング
- 動作を変えずにコードの構造を改善する作業
- 技術的負債を返済する手段のひとつ
- マイグレーション
- データベースの構造変更を管理する仕組み
- 大きな技術的負債の返済には、マイグレーションを伴う構造の見直しが必要になることがある
実務で気にするポイント
- 負債がゼロのシステムはほぼ存在しない。完全になくすことより「管理できる量に保つ」ことが目標
- 「今の負債がどこにあるか」を把握して、開発計画に返済の時間を組み込む
- 新機能追加と並行して、少しずつ改善する習慣（リファクタリング）を持つ
- 負債の大きさを非エンジニアにも説明できるようにしておくと、改善への理解を得やすい
注意: 技術的負債は「悪い開発者がいるから生まれる」ものではありません。締め切り・人手・情報の制約の中で判断した結果として自然に積み上がるものです。大切なのは「借りた自覚を持ち、返す計画を立てること」です。