技術的負債とは？管理方法と返済の優先順位｜負債一覧表テンプレート

技術的負債とは、早く作るために選んだ近道や、後から分かった設計のずれが原因で、その後の開発に毎回余計な手間がかかり続ける状態のことです。 お金の借り入れにたとえて、余計にかかり続ける手間を「利息」、直すのに必要な工数を「元本」と呼びます。

この記事では、負債を1枚の一覧表にまとめ、利息と元本を数字で書いて返す順番を決める方法を説明します。一覧表のテンプレート（CSVとMarkdown）、架空の備品予約システムでの10行の記入例、Pythonでの検算結果、経営層に説明するための1枚テンプレートをそのまま使える形で載せています。

確認環境：Python 3.11.15（計算の検算）。確認日は2026-10-06です。記入例の数値はすべて架空の例です。

この記事の結論

• 負債は全部返さなくてよい。 利息（毎月余計にかかる工数）が元本（返済工数）を早く上回るものから返します。
• 返す順番は 回収月数＝元本÷月間利息 の短い順が基本です。短いほど早く元が取れます。
• 回収月数が長くても、放置すると止まるおそれがあるもの（リスクが高いもの）は別枠で先に返します。
• ほとんど触らない場所の負債は、一覧表に記録したうえで置いておくのが合理的です。
• 経営層には「放置した場合の月間損失時間」「返済に必要な期間」「返済後に空く工数」の3つの数字で伝えます。

技術的負債の早見表

技術的負債とは：利息と元本で考える

技術的負債はウォード・カニンガム氏が作ったたとえで、マーティン・ファウラー氏の解説ページ（2019年5月21日付）に次の例があります。

• モジュールの構造が整っていれば、機能の追加は4日で済む
• 構造が整っていないため、6日かかる
• 差の2日が「利息」
• 構造を整えるのに5日かかるなら、その5日が 「元本」の返済

1回の機能追加だけを見ると、5日かけて2日を取り戻すので割に合いません。けれども同じ場所に何度も手を入れるなら、3回目で元が取れます。負債を返すかどうかは「その場所を今後どれだけ触るか」で決まる、というのがこのたとえの要点です。

同じページには、返し方の方針も書かれています。

• 整っていなくても変更の少ない安定した場所は、そのままにしてよい
• 変更が多い場所は、利息がとても大きくなるので、こまめに整える
• まとめて一度に返すより、少しずつ返す

この記事の一覧表は、この考え方を数字で扱えるようにしたものです。

技術的負債の4象限（種類の分け方）

ファウラー氏は別のページ（2009年10月14日付）で、負債を2つの軸で4つに分けています。一覧表の「種類」の列には、この4つのどれかを書きます。

4象限は、返す順番よりも 「次に同じ負債を増やさないための手がかり」 として役立ちます。

バグ・リファクタリング・レガシー・設計上の妥協との違い

技術的負債は、似た言葉と混ざって使われがちです。一覧表に載せるかどうかを決めるために、違いを整理します。

どちらに入れるかの判断基準

負債一覧表のテンプレート

列は10個です。利息と元本を必ず数字で書くことが、この表のいちばん大切な点です。

回収月数とスコアは計算で出すので、手では入力しません。

CSV（空のテンプレート）

ID,項目,発生箇所,種類,利息_時間毎月,元本_人日,影響,頻度,リスク,対応方針
D01,,,,,,,,,

Markdown（空のテンプレート）

| ID | 項目 | 発生箇所 | 種類 | 利息（時間/月） | 元本（人日） | 回収月数 | リスク | 対応方針 |
|---|---|---|---|---|---|---|---|---|
| D01 |  |  |  |  |  |  |  |  |

利息の見積もり方

利息は「正確な値」より「桁が合っていること」が大切です。次のどれかで出します。

影響と頻度の目安は次のとおりです（例）。

記入例：備品予約システムの負債10行

架空の社内システム「備品予約システム」で10行を記入した例です。回収月数と対応方針は、後で示すPythonの計算結果をそのまま入れています。

同じ内容のCSVです。表計算ソフトに貼り付けるか、debt.csv という名前で保存すると次の節のコードで読み込めます（対応方針の列は計算で埋めるので空です）。

ID,項目,発生箇所,種類,利息_時間毎月,元本_人日,影響,頻度,リスク,対応方針
D01,予約の重複チェックが3か所に別々に書かれている,予約の登録・変更・一括登録,慎重×意図的,12,3,4,5,中,
D02,自動テストがなく毎回手作業で確認している,予約モジュール全体,無謀×意図的,20,10,5,5,中,
D03,フレームワークの版がサポート終了に近い,システム全体,慎重×意図的,2,15,5,1,高,
D04,日時をサーバーの地域時刻の文字列で保存している,予約テーブル,無謀×無自覚,6,8,3,3,中,
D05,備品マスタ画面が1ファイル2000行ある,備品管理画面,慎重×無自覚,4,5,2,3,低,
D06,通知メールの本文がコードに直接書かれている,通知処理,慎重×意図的,1.5,2,2,2,低,
D07,設定値を環境ごとに手作業で書き換えている,リリース手順,無謀×意図的,5,2,4,4,中,
D08,月次集計バッチが全件を読み込んでいる,利用状況の集計バッチ,慎重×無自覚,1,6,3,1,中,
D09,旧管理画面だけ独自のログイン処理を持つ,旧管理画面（利用者2名）,無謀×無自覚,0.5,12,1,1,低,
D10,帳票出力は変更のたびに不具合が出る,帳票出力モジュール,無謀×無自覚,16,45,5,4,高,

Pythonで回収月数とスコアを検算して並べ替える

計算式は2つです。

回収月数 = 元本（人日）× 8時間 ÷ 利息（時間/月）
スコア   = 影響（1〜5）× 頻度（1〜5）÷ 元本（人日）

回収月数は「返済にかけた工数が、浮いた工数で埋まるまでの月数」です。スコアは、利息を時間で測れないときに使う代わりの指標で、大きいほど先に返します。

debt_calc.py：

import csv

HOURS_PER_DAY = 8          # 1人日 = 8時間
REBUILD_DAYS = 40          # 元本がこれ以上なら「作り直す」を検討（例）
NOW_MONTHS = 6             # 回収月数がこれ以下なら「今返す」（例）
ALONG_MONTHS = 24          # 回収月数がこれ以下なら「ついでに返す」（例）

def decide(row):
    if row["元本"] >= REBUILD_DAYS and row["回収月数"] <= ALONG_MONTHS:
        return "作り直す"
    if row["リスク"] == "高" or row["回収月数"] <= NOW_MONTHS:
        return "今返す"
    if row["回収月数"] <= ALONG_MONTHS:
        return "ついでに返す"
    return "記録して放置"

rows = []
with open("debt.csv", encoding="utf-8", newline="") as f:
    for r in csv.DictReader(f):
        r["利息"] = float(r["利息_時間毎月"])
        r["元本"] = float(r["元本_人日"])
        r["回収月数"] = r["元本"] * HOURS_PER_DAY / r["利息"]
        r["スコア"] = int(r["影響"]) * int(r["頻度"]) / r["元本"]
        r["対応方針"] = decide(r)
        rows.append(r)

print("== 回収月数の短い順 ==")
print("ID   利息h/月 元本人日 回収月数 スコア 方針")
for r in sorted(rows, key=lambda r: r["回収月数"]):
    print(f'{r["ID"]}  {r["利息"]:7.1f} {r["元本"]:7.0f} {r["回収月数"]:8.1f} {r["スコア"]:6.2f} {r["対応方針"]}')

print()
print("== スコア（影響×頻度÷元本）の高い順 ==")
print(" ".join(f'{r["ID"]}({r["スコア"]:.2f})' for r in sorted(rows, key=lambda r: -r["スコア"])))

print()
print("== 方針ごとの集計 ==")
for p in ["今返す", "ついでに返す", "記録して放置", "作り直す"]:
    g = [r for r in rows if r["対応方針"] == p]
    print(f'{p}: {len(g)}件 利息 {sum(r["利息"] for r in g):.1f}時間/月 元本 {sum(r["元本"] for r in g):.0f}人日 ({",".join(r["ID"] for r in g)})')
total = sum(r["利息"] for r in rows)
print(f'全体: 利息 {total:.1f}時間/月 = {total / HOURS_PER_DAY:.1f}人日/月、元本 {sum(r["元本"] for r in rows):.0f}人日')

print()
print("== 経営層向けの3つの数字（「今返す」の4件） ==")
now = [r for r in rows if r["対応方針"] == "今返す"]
interest = sum(r["利息"] for r in now)
principal = sum(r["元本"] for r in now)
CAPACITY = 6               # 返済に充てる人日/月（例）
months = -(-principal // CAPACITY)
print(f"放置した場合の損失: 月 {interest:.0f}時間 = 年 {interest * 12:.0f}時間（{interest * 12 / HOURS_PER_DAY:.1f}人日）")
print(f"返済に必要な工数: {principal:.0f}人日 → 月{CAPACITY}人日ずつで {months:.0f}か月")
print(f"返済後に空く工数: 月 {interest:.0f}時間（{interest / HOURS_PER_DAY:.1f}人日）")
print(f"元が取れるまで: {principal * HOURS_PER_DAY / interest:.1f}か月")

実行結果（python3 debt_calc.py）：

== 回収月数の短い順 ==
ID   利息h/月 元本人日 回収月数 スコア 方針
D01     12.0       3      2.0   6.67 今返す
D07      5.0       2      3.2   8.00 今返す
D02     20.0      10      4.0   2.50 今返す
D05      4.0       5     10.0   1.20 ついでに返す
D04      6.0       8     10.7   1.12 ついでに返す
D06      1.5       2     10.7   2.00 ついでに返す
D10     16.0      45     22.5   0.44 作り直す
D08      1.0       6     48.0   0.50 記録して放置
D03      2.0      15     60.0   0.33 今返す
D09      0.5      12    192.0   0.08 記録して放置

== スコア（影響×頻度÷元本）の高い順 ==
D07(8.00) D01(6.67) D02(2.50) D06(2.00) D05(1.20) D04(1.12) D08(0.50) D10(0.44) D03(0.33) D09(0.08)

== 方針ごとの集計 ==
今返す: 4件 利息 39.0時間/月 元本 30人日 (D01,D02,D03,D07)
ついでに返す: 3件 利息 11.5時間/月 元本 15人日 (D04,D05,D06)
記録して放置: 2件 利息 1.5時間/月 元本 18人日 (D08,D09)
作り直す: 1件 利息 16.0時間/月 元本 45人日 (D10)
全体: 利息 68.0時間/月 = 8.5人日/月、元本 108人日

== 経営層向けの3つの数字（「今返す」の4件） ==
放置した場合の損失: 月 39時間 = 年 468時間（58.5人日）
返済に必要な工数: 30人日 → 月6人日ずつで 5か月
返済後に空く工数: 月 39時間（4.9人日）
元が取れるまで: 6.2か月

結果の読み方

• D01・D07・D02 は2〜4か月で元が取れるので、最初に返します。3件で元本15人日、浮く工数は月37時間です。
• D03 は回収月数60か月で、並べ替えると下から2番目です。それでもリスクが「高」なので「今返す」に入ります。サポートが終わる日という期限があるものは、回収月数とは別の軸で判断します。
• D10 は利息が月16時間と2番目に大きい一方、元本が45人日あります。部分的な手直しを続けるより、モジュール単位で作り直す計画を別に立てます。
• D08・D09 は記録して放置です。合わせて月1.5時間の利息に対し、元本は18人日です。D09 は利用者が2名の画面なので、画面そのものをなくす選択肢もあります。

返済の判断基準表（今返す・ついでに返す・放置・作り直す）

上のコードの decide 関数と同じ基準を表にしたものです。しきい値はチームの状況に合わせて変えてください（6か月・24か月・40人日は例です）。上の行から順に当てはめます。

ついでに返すは、その場所を開く作業と確認の作業を機能開発と共有できるので、単独で返すより少ない工数で済みます。記録して放置は「何もしない」ではなく、「利息が小さいことを確かめたうえで置いておく」という判断です。触る頻度が上がったら利息を書き直し、方針を見直します。

回収月数とスコアのどちらを使うか

経営層向けの1枚説明テンプレート

専門用語を使わず、3つの数字で伝えます。「技術的負債」という言葉自体を「作業を遅くしている原因」と言い換えると伝わりやすくなります。

# 開発を遅くしている原因の解消について（ご相談）

## お願いしたいこと
（例）毎月○人日を、開発を遅くしている原因の解消に充てることを承認いただきたい。

## 3つの数字
| 項目 | 数字 |
|---|---|
| 今のまま続けた場合に余計にかかる時間 | 月○時間（年○時間） |
| 解消に必要な期間 | ○人日（月○人日ずつで○か月） |
| 解消後に空く時間 | 月○時間（新しい機能の開発に回せる） |

## 何が起きているか（3つまで）
1. （例）同じ処理が複数の場所にあり、変更のたびに全部を直している
2.
3.

## 解消しない場合に起きること
（例）新しい機能を出すまでの期間が、今より長くなっていく。

## 進め方
- 期間：○月〜○月
- 機能開発への影響：○月まで、新機能に使える時間が月○人日減る
- 元が取れる時期：開始から約○か月後

## 今回は対象にしないもの
（例）利用の少ない画面の作り直し（余計にかかる時間が小さいため）

記入例

Pythonの出力の「経営層向けの3つの数字」を当てはめた例です。

# 開発を遅くしている原因の解消について（ご相談）

## お願いしたいこと
10月から5か月間、毎月6人日を、備品予約システムの開発を遅くしている原因の解消に充てることを承認いただきたい。

## 3つの数字
| 項目 | 数字 |
|---|---|
| 今のまま続けた場合に余計にかかる時間 | 月39時間（年468時間、約58人日） |
| 解消に必要な期間 | 30人日（月6人日ずつで5か月） |
| 解消後に空く時間 | 月39時間（約5人日。新しい機能の開発に回せる） |

## 何が起きているか（3つまで）
1. 予約が重なっていないかを調べる処理が3か所にあり、変更のたびに3か所を直している
2. 変更後の確認をすべて手作業で行っている
3. 設定を環境ごとに手で書き換えており、リリースのたびに確認が必要

## 解消しない場合に起きること
新しい機能を出すまでの期間が今より長くなる。土台となる部品のサポートが終わると、修正の提供を受けられなくなる。

## 進め方
- 期間：10月〜翌年2月
- 機能開発への影響：2月まで、新機能に使える時間が月6人日減る
- 元が取れる時期：すべて解消してから約6か月後

## 今回は対象にしないもの
旧管理画面のログイン処理、月次集計の作り直し（余計にかかる時間が月1.5時間と小さいため）

説明のコツは次の3点です。

技術的負債の管理方法（運用の流れ）

返済枠は「毎月○人日」のように決まった量で持つと、機能開発の予定と両立させやすくなります。

確かめて分かったこと

• 回収月数の順とスコアの順は一致しません。 D06（元本2人日）はスコアで4番目ですが、回収月数は10.7か月で「ついでに返す」です。スコアは元本が小さいものを高く出すので、最終的な判断は回収月数で行うと安定します。
• 数字だけで並べると、期限つきの負債が下に沈みます。 D03 は回収月数でもスコアでも下から2番目でした。リスクの列を別に持ち、判断基準の先頭に近い位置で拾う必要があります。
• 「今返す」4件だけで、全体の利息68時間/月のうち39時間（約57%）が消えます。 元本は全体108人日のうち30人日（約28%）です。全部返さなくても、利息の大半は減らせます。
• 「記録して放置」の2件は、元本18人日に対して利息が月1.5時間でした。 返しても元が取れるのは48か月後と192か月後です。
• 判断の順番で結果が変わります。 D10 は回収月数22.5か月なので、「作り直す」の判定を先に置かないと「ついでに返す」に入ります。45人日は機能開発のついでには収まらないため、元本の大きさを先に見ています。
• 「返し終えてから元が取れるまで」は6.2か月でした。 返済期間の5か月と合わせると、開始から約11か月です。説明するときは、どちらの月数かを分けて書きます。

よくある質問

Q. 技術的負債とは、簡単に言うと何ですか？ A. 動いてはいるものの、変更や確認のたびに余計な手間がかかり続ける状態のことです。余計な手間を利息、直すための工数を元本と呼びます。

Q. 技術的負債とバグの違いは何ですか？ A. バグは仕様どおりに動かない不具合で、技術的負債は仕様どおりに動くものの開発の手間を増やす状態です。利用者から見えるのがバグ、開発の速さに表れるのが負債です。

Q. 技術的負債は全部返すべきですか？ A. 全部を返す必要はありません。ほとんど触らない場所の負債は利息が小さいので、一覧表に記録して置いておくほうが工数を有効に使えます。

Q. 利息を数字で出せないときはどうしますか？ A. 影響×頻度÷元本のスコアで代用します。上位に来たものだけ、1か月ほど余計にかかった時間を記録すると、利息を数字で書けるようになります。

Q. 返済の時間を取れないときはどうしますか？ A. 回収月数が短い1件だけを選び、3つの数字で説明します。小さく返して浮いた時間を示すと、次の返済枠の相談がしやすくなります。

まとめ

• 技術的負債は、利息（毎月余計にかかる工数）と元本（返済工数）の2つの数字で書く。
• 回収月数＝元本÷月間利息 が短いものから返す。
• リスクが高いものは、回収月数が長くても別枠で先に返す。
• 触らない場所の負債は、記録して置いておく。 半年ごとに利息を見直す。
• 元本が大きく利息も大きいものは、作り直しの計画を別に立てる。
• 経営層には、月間損失時間・返済期間・返済後に空く工数の3つで説明する。

参考・出典

• Martin Fowler「TechnicalDebt」（2019年5月21日）https://martinfowler.com/bliki/TechnicalDebt.html
• Martin Fowler「TechnicalDebtQuadrant」（2009年10月14日）https://martinfowler.com/bliki/TechnicalDebtQuadrant.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。