技術負債の管理方法｜見つけ方・台帳の作り方・返済の優先順位をプロジェクト目線で解説

技術負債を管理するには、負債を台帳に書き出して見える化し、「よく変更する場所にある負債」から優先して、機能開発の作業に組み込んで少しずつ返すのが基本です。めったに触らない部分の負債は、急いで返す必要はありません。

この記事は、技術負債の意味の説明よりも、プロジェクトの中でどう管理し、どう返していくかに絞っています。用語の意味と語源は技術的負債とは？意味と語源、Fowlerの4象限はTechnical Debt（技術的負債）とは？で詳しく説明しています。

技術負債とは（管理の前に押さえる2点）

技術負債（技術的負債、Technical Debt）は、Ward Cunninghamが1992年のOOPSLAで発表したWyCashの開発についての経験報告で使った比喩です。報告では、初めて書いたコードを出荷することを借金にたとえ、すぐに書き直して返せば開発を速められるが、返さないと「完全でないコードに費やす時間がすべて利子になる」と説明しています。

管理の観点で押さえておきたいのは次の2点です。

• 利子は「そのコードを触るとき」に発生する：Martin FowlerはTechnicalDebtの解説で、本来4日で済む機能追加が、分かりにくい構造のせいで6日かかるなら、差の2日が利子だと説明しています。そして、変更しない場所なら利子は発生しないので、扱いにくくても安定している部分は放っておけると書いています。
• 正確には測れない：同じ解説で、生産性は測れないため、利子も返済の費用も見積もりの精度は低いと認めています。だからこそ、精密な計算より「よく触る場所から少しずつ返す」という単純な方針が効きます。

技術負債の管理の全体像

段階	やること	成果物
1. 見つける	レビュー・作業中の気づき・コードの目印・変更履歴から負債を拾う	負債の候補
2. 記録する	負債台帳に、場所・困っていること・利子の目安を書く	負債台帳
3. 順番を決める	変更の頻度と影響の大きさで並べる	優先順位つきの一覧
4. 返す	近く触る機能の作業に返済を含める／大きいものは計画に入れる	リファクタリングやテストの追加
5. 見直す	計画の会議で台帳を見て、増減と効果を確認する	更新された台帳

1. 技術負債を見つける

負債は、作業している本人がいちばんよく気づきます。見つける場面を決めておくと、拾い漏れが減ります。

• 機能追加や修正のとき：「ここが分かりにくくて時間がかかった」と感じた場所は、利子を払った場所です。
• コードレビューのとき：納期のために見送った改善は、その場で台帳に書きます。
• コードの目印：TODO・FIXME・HACKなどのコメントは、書いた人が負債だと認識していた印です。
• 変更履歴：何度も修正されているファイルや、バグ修正が集中しているファイルは、負債がたまっている可能性があります。
• 依存ライブラリやフレームワークの古さ：サポートが終わったバージョンを使い続けていることも負債です。

コードの読みにくさの典型的な型はコードスメルとは？にまとめています。

2. 負債台帳に記録する

見つけた負債は、課題管理ツールやスプレッドシートの1か所に集めます。項目は多くしすぎない方が続きます。

項目	書く内容の例
場所	billing.py の税計算
困っていること	税率がコードに直接書かれていて、変更のたびに3か所直す必要がある
利子の目安	税率に関わる変更のたびに半日ほど余計にかかる（見積もりでよい）
返済の案と大きさ	税率を設定ファイルに出す。1日程度
近く触る予定	来月の料金プラン追加で触る
見つけた人・日付	担当者名、記録した日

「わざと借りた負債（納期のために選んだ近道）」と「あとで気づいた負債」を区別しておくと、振り返りに役立ちます。わざと借りたものには、返す時期の目安も書いておきます。

3. 優先順位を決める：変更の多い場所から

Fowlerの説明どおり、利子は触るたびに発生します。そこで、変更回数と負債の目印の多さを掛け合わせて、利子を多く払っていそうなファイルを探してみます。Gitの変更履歴を使うPythonの例です。

import re
import subprocess
from collections import Counter
from pathlib import Path

# 1) ファイルごとの変更回数（git log から数える）
log = subprocess.run(
    ["git", "log", "--name-only", "--pretty=format:"],
    capture_output=True, text=True, check=True,
).stdout
changes = Counter(line for line in log.splitlines() if line.endswith(".py"))

# 2) ファイルごとの TODO / FIXME / HACK の数
marks = {}
for path in Path(".").rglob("*.py"):
    text = path.read_text(encoding="utf-8")
    marks[str(path)] = len(re.findall(r"#\s*(TODO|FIXME|HACK)", text))

# 3) 変更が多く、目印も多いファイルほど「利子」を払っている
rows = sorted(
    ((f, changes[f], marks.get(f, 0)) for f in changes),
    key=lambda r: r[1] * max(r[2], 1), reverse=True,
)
print("ファイル\t変更回数\t目印の数")
for f, c, m in rows:
    print(f"{f}\t{c}\t{m}")

練習用に作ったリポジトリ（billing.pyを6回、mail.pyを3回、legacy.pyを1回コミットし、目印のコメントをbilling.pyに1つ、legacy.pyに2つ入れたもの）の直下で、Python 3.12で実行した結果です。

ファイル	変更回数	目印の数
billing.py	6	1
mail.py	3	0
legacy.py	1	2

目印がいちばん多いのはlegacy.pyですが、作ってから一度も変更されていません。変更回数の多いbilling.pyの方が、実際に利子を払っている可能性が高いと分かります。数字はあくまで当たりをつけるためのもので、最後は台帳の「困っていること」と「近く触る予定」を見て決めます。

	よく変更する	めったに変更しない
影響が大きい（障害・セキュリティ・データ破損につながる）	最優先で返す	計画に入れて返す
影響が小さい（読みにくい・遅い作業になる）	機能開発のついでに少しずつ返す	台帳に残して様子を見る

サポートが終わったライブラリのように、セキュリティ更新が受けられなくなるものは、変更頻度にかかわらず優先度を上げます。

4. 返済の進め方

機能開発の作業に返済を含める

Fowlerは、金融の借金と同じように元本を少しずつ返すのが通常は最善だと書いています。最初の機能で2日ほど余分に使って整理すれば、次からの利子を減らせる、という考え方です。この方法なら、自然とよく触る場所から返済が進みます。見積もりの段階で「この機能には台帳のこの項目の返済を含める」と書いておくと、作業が見えなくなりません。

大きな負債は計画に入れる

データベースの構造変更やフレームワークの更新のように、機能開発のついでに済まない負債は、独立したタスクとして計画に入れます。返済の目的（何が速く・安全になるか）と、台帳に書いた利子の目安を一緒に示すと、優先順位の議論がしやすくなります。

テストで守りながら直す

返済の多くはリファクタリング、つまり動作を変えずにコードの構造を直す作業です。直す前にテストを用意し、直したあとも同じ結果になることを確かめます。手順はリファクタリングとは？で、Pythonの例つきで説明しています。

5. 定期的に見直す

台帳は書いただけでは役に立ちません。スプリントの計画や週次の定例など、すでにある会議の議題に「負債台帳の確認」を入れます。見るのは次の3つで十分です。

• 新しく増えた項目と、返済が終わった項目
• 次の期間に触る機能と関係する項目
• 返済した項目で、実際に作業が楽になったか（担当者の実感でよい）

技術負債を増やしにくくする工夫

• 近道を選ぶときは記録してから：納期のために近道を選ぶのは悪いことではありません。選んだ時点で台帳に書けば、「知らないうちにたまる負債」になりません。
• 自動テストとCI：変更のたびにテストが走る仕組みがあると、返済のリファクタリングを安心して行えます。
• レビューで設計の意図を共有する：あとで読む人が意図を理解できれば、同じ場所に別の近道が重なるのを防げます。チームでの進め方はチーム開発を成功させる7つのポイントも参考になります。
• 使わない機能を先回りで作らない：使われない汎用化も、読む手間と保守の手間を増やします。考え方はYAGNI原則とは？にまとめています。

よくある質問

Q. 技術負債はすべて返済すべきですか？

いいえ。Martin Fowlerは、扱いにくいコードでも変更しない場所なら利子は発生しないので、安定している部分は放っておいてよいと説明しています。返済の優先度は、そのコードをどれくらいの頻度で変更するかで決めるのが基本です。

Q. 技術負債の返済にはどれくらいの時間を割けばよいですか？

決まった割合はありません。数字を先に決めるより、負債台帳に載った項目のうち、近く手を入れる機能に関係するものを、その機能の作業に含めて返していくやり方が始めやすい方法です。割合を決める場合も、台帳の件数や変更にかかった時間の推移を見て見直します。

Q. 技術負債は誰が管理するべきですか？

台帳の記入はコードを触る開発者全員が行い、優先順位を決めて計画に組み込む役割は、チームのリーダーやテックリードが持つのが一般的です。大事なのは担当者を決めることより、台帳を計画の会議で毎回見る習慣を作ることです。

Q. 経営層や発注者に技術負債をどう説明すればよいですか？

「この機能は本来4日だが、いまの構造だと6日かかる」のように、追加でかかっている時間で説明します。Fowlerが使っている例と同じで、2日分が利子にあたります。そのうえで、整理にかかる日数と、今後同じ場所を何回変更する予定かを並べて判断してもらいます。

まとめ

• 技術負債は、台帳に書いて見える化するところから管理が始まる
• 利子はそのコードを触るときに発生するので、よく変更する場所の負債から返す
• 返済は機能開発の作業に含めて少しずつ。大きなものは計画に入れる
• 台帳は既存の会議で定期的に見直し、近道を選んだときはその場で記録する

あわせて読みたい

学習の進め方はPython学習のロードマップ、職種ごとの違いはエンジニアの職種の違いにまとめています。