技術的負債

技術的負債とは

技術的負債 (Technical Debt) は、Ward Cunningham が 1992 年の OOPSLA 経験報告 (Smalltalk で開発した資産運用システムの開発報告) で使った比喩で、短期的な利益のために妥協した設計・実装が、将来の変更コストを増大させる現象を指す。金融の負債と同様、利息 (追加の開発コスト) が発生する。

原典が問題にしたのは、コードの出来の悪さではなく時間軸だった。顧客には問題なく動く未整理のコードでも、溜め込めば誰も全体を把握できなくなり、担当者の固定化と身動きの取れない製品に行き着く。少額の借金は速やかに書き直して返すかぎり開発を速める、返さないまま抱え続けると組織全体が止まる、という趣旨である。この時間軸の区別を落とすと、負債という言葉が品質の悪さの言い換えになり、返すか放置するかを決める道具として機能しなくなる。

技術的負債の種類

負債は「意図して背負ったか」と「無謀か慎重か」の 2 軸で整理できる。Martin Fowler が 2009 年に示した 4 象限 (Technical Debt Quadrant) がその代表で、各象限を現場の台詞で表すと違いが見えやすい。

意図の有無	無謀	慎重
意図的	「設計している時間はない」	「今はリリースを優先し、後で手を入れる」
無自覚	「レイヤ分割というものを知らなかった」	「どう作るべきだったか、作ってから分かった」

返済の判断に効くのは、意図の有無よりも無謀か慎重かの軸だ。慎重に背負った負債は、利息が小さければ返さない選択も成り立つ。一方で無自覚かつ慎重な負債 (「作ってから分かった」型) は、設計に長けたチームでも避けられない。作りながら理解が進む以上、あるべき設計が見えた瞬間に、それまでのコードは負債に変わる。この枠組みは負債の有無を責めるためではなく、どの負債から返すかを決めるために使う。

技術的負債の例

テストがないとバグの発見が遅れリファクタリングが怖くなる。ハードコードされた値は環境ごとにコードを変更する手間を生む。重複コードは 1 箇所を直しても写しが残るため、同じ不具合が別の場所で再発する。古い依存パッケージはセキュリティ脆弱性や互換性の問題を引き起こす。ドキュメントがないとオンボーディングが遅くなる。

技術的負債の管理

管理の手順は 4 段階に落ち着く。可視化されていない負債は「なんとなく開発が遅い」という感覚のまま議論され、優先順位も付けられない。

1. 可視化: 負債をバックログに記録
2. 優先度付け: 変更頻度の高いコードの負債を優先
3. 返済: 各スプリントに返済の枠を固定で確保する
4. 予防: コードレビュー、CI/CD、リンター

負債の返済判断

変更頻度が高い (毎週触る) コード、影響範囲が広い (多くのモジュールが依存する) コード、セキュリティ脆弱性を含むコードは優先的に返済する。変更頻度が低く (年 1 回)、影響範囲が狭く、見た目の問題にとどまる負債は放置してもよい。この判断が成り立つのは、技術的負債の利息が時間の経過ではなく、その箇所に手を入れたときにだけ発生するからだ (金融の負債と比喩がずれる点でもある)。汚くても誰も触らないコードは利息を生まないので放置でよく、逆に毎日触る領域は小さな汚れでも利息が積み上がる。

負債を生まない習慣

ボーイスカウトルール (触ったコードを少し綺麗にする)、TDD (テストが先にある)、コードレビュー (第三者の目で品質を確認)、CI/CD (自動テストで品質を保証)、定期的なリファクタリング (構造を改善) が効果的。

負債の総量を数値で測ろうとすると、開発の生産性そのものが客観的に測れないという壁に突き当たる。追うべきは総量ではなく、よく触る領域で「同種の変更に前より時間がかかっていないか」という一点である。