技術的負債とは？「借金」の比喩の本来の意味と、返済の優先順位の付け方

技術的負債とは、短期には便益がある、または当時の理解では妥当だった設計や実装が、将来の変更や保守に追加コストを生む状態を捉える比喩です。 Software Engineering Institute（SEI）の作業定義では、短期には好都合でも、将来の変更を高コストまたは不可能にし得る設計や実装上の構成要素の集合とされています。 対象はコードだけでなく、アーキテクチャ、テスト、ビルドやデプロイの仕組みなどにも及びます。 現場で「読みにくいコード」「古い作り」の総称としてしまうと、どの負債項目がどの利子を生んでいるのかを判断できません。

「借金」の比喩は何を言っているのか

この比喩を公刊された文献でたどると、広く知られる最初期の記述は、Ward CunninghamがOOPSLA '92に寄せたexperience reportです。 WyCASH+という金融ポートフォリオ管理システムの開発報告で、初回のコードを出荷することは借金をすることに似ていると述べられています。 少額の借金は、速やかに書き直して返済する限り、開発を速められるという説明です。 返済しなければ、新たに得た理解とまだ合っていないコードを扱う追加工数が利子になります。

元の比喩は、「後で直すつもりなら雑に書いてよい」という主張ではありません。 Cunninghamが2009年の説明で示したのは、出荷時点の部分的な理解をできる限り明確にコードへ反映し、利用を通じて理解が深まったらリファクタリングで追随させる開発です。 Martin Fowlerも技術的負債の解説で、この言葉が乱雑なコードを正当化する便利な口実として使われやすいことに触れています。

Fowlerの4象限は意図と慎重さを分ける

FowlerはTechnical Debt Quadrantで、負債を2つの軸で分類しました。 負債を引き受けると認識していたか（意図的／非意図的）と、短期の便益と将来コストを慎重に比較したか（慎重／無謀）です。

慎重かつ意図的な負債は、合理的な経営判断になり得ます。 早期出荷の便益が予想される利子と返済費用を上回り、負債を追跡できるなら、返済せずに低い利子を払い続ける選択も含めて検討できます。 無謀かつ意図的な負債は、借りる自覚がありながら、内部品質を落とすことで失う時間を過小評価した状態です。 無謀かつ非意図的な負債は、設計上の問題を認識できないまま積み上がります。 慎重かつ非意図的な負債は、作った後の学習によって、より適した設計が初めて見えた状態です。 Fowlerは、この種類の負債は優れた設計者にも避けられないと説明しています。 管理で問うべきなのは負債の有無ではなく、負債項目の場所、発生経緯、予想される利子、対処方針です。

利子はどこに現れるか

技術的負債の利子は、追加工数やリスクとして次のように現れることがあります。

• 変更のリードタイムの悪化：同程度の規模の改修に、以前より時間がかかるようになる
• 障害の増加：変更が想定外の箇所を壊し、リリース後の切り戻しや修正が増える
• 見積もりのブレ：影響範囲が読めず、バッファが厚くなる、あるいは超過が常態化する
• 引き継ぎの負荷：新メンバーの立ち上がりに時間がかかり、特定の人しか触れない領域が固定化する

数値で観測する候補の一つが、変更のリードタイムです。 DORAの定義では、変更をバージョン管理へコミットしてから本番環境へデプロイするまでの時間を指します（測り方は変更のリードタイムの解説を参照）。 異なるチームを横並びにせず、同じアプリケーションやサービスで推移を追います。 ただし、長期化は人員の入れ替わり、変更の大きさ、レビュー待ち、リリース手順でも起きるため、リードタイムだけでは技術的負債を原因と特定できません。 負債項目との関係を調べるには、時間が延びた工程、変更した領域、レビューの手戻り、障害記録を突き合わせます。

経営にどう翻訳するか

「技術的負債が多い」という表現だけでは、投資の優先順位を決められません。 影響を開発工数、障害対応、機会損失などの費用や成果に置き換えて示す必要があります。 経営に示す対象は、同じ成果を得るための追加コストと事業への影響です。

仮の例として、昨年は2週間で出せていた規模の機能追加が、今年は同じチームで4週間かかっているとします。 仕様規模、人員、品質基準、リリース工程が同等で、変更を直列に進めるなら、単純計算では同じ期間に完了できる件数が半分になります。 ただし、この比較でわかるのは開発速度が落ちたことまでで、技術的負債が原因だとはまだ断定できません。 返済を提案するときは、対象となる負債項目、観測した追加工数やリスク、返済費用、回収できる効果、検証に使う指標を示します。 「きれいにする」ではなく、「この領域の変更コストを下げ、次の施策に必要な期間を短縮する」という投資案にします。 この翻訳の進め方は開発生産性を経営に説明する方法で詳しく整理しています。

返済の優先順位：全部は返さない

通常、全額返済は目標になりません。 内部品質の低さによる変更時の利子は、その領域を変更するときに発生するからです。 この点では、時間の経過だけで利子が発生する金融の負債と比喩が一致しません。 5年間変更していない読みにくいバッチ処理でも、今後の機能変更がなく、運用、セキュリティ、サポート終了のリスクを別に管理できているなら、コードを整理する優先度は低くできます。

コード内部の負債は、まず「変更頻度×1回あたりの追加コスト」で予想される利子を見積もり、返済費用や残りの利用期間と比較します。 次の表は、その一次スクリーニングです。

この表が扱うのは、自分たちが変更を加えるときの利子だけです。 稼働を続けるシステムでは、ランタイムや依存ライブラリのEOL（サポート終了）、脆弱性、障害対応のリスクが、機能の変更頻度が低くても残ります。 これらは別枠で棚卸しします（レガシーシステムの判定基準）。 また、この優先順位はコード領域単位の返済判断であり、システム単位でどの刷新戦略を選ぶかという仕分け（モダナイゼーション）とは別のレイヤの話です。

ファイルやモジュールの変更回数は、バージョン管理の履歴から機械的に集計できます。 ただし、コミットの分け方、一括整形、生成ファイルによって値がゆがむため、変更頻度の代理指標として扱います。 変更コストは、見積もりとの乖離、レビューの所要時間と往復回数、手戻り、変更後の障害など、取得できる記録で見積もります。 記録に残らない事情は、その領域を変更した開発者への聞き取りで補います。

運用方法の一つは、返済を単発の美化プロジェクトにせず、開発容量の一定割合として継続的に確保することです。 固定する割合に普遍的な正解はないため、計画期間ごとに返済効果を確認して調整します。 枠を使い切るために、利子の低い負債まで返済する必要はありません。 一方、機能開発と返済を毎回その場で比較すると、短期便益を説明しやすい機能が優先され、返済が繰り返し先送りされやすくなります。 なお、返済の範囲を作り直しにまで広げるかは別の判断で、その軸はリファクタリングとリライトの違いで扱います。

AI時代の注意：理解負債

AI支援の利用自体では、技術的負債を生むか返すかは決まりません。 DORAの2025年調査は、AIを組織の強みと弱みをともに増幅するものと位置づけています。 生成した変更量にレビューと理解が追いつかず、チームの誰も設計判断や障害時の挙動を説明できないままマージすると、コード量とチームの理解の間に隔たりができます。 この隔たりは、近年の研究で理解負債と呼ばれています（Comprehension Debt）。 2026年公開のプレプリントは、207人の学生による8週間のソフトウェア開発プロジェクトで、この問題の蓄積パターンを定性的に調べました。 ただし、用語と測定法はまだ定着しておらず、研究結果を専門職の開発組織にそのまま一般化できません。 理解負債はチームの認知にある問題であり、コード内の設計や実装にある技術的負債と同一ではありません。 Fowlerの4象限のどこに当たるかも、AIが生成したという事実ではなく、リスクを認識していたか、便益と将来コストを慎重に比較したかで決まります。 対策では、差分をレビュー可能な大きさに保ち、受け入れ条件のうち自動化できるものをテストで確認し、作成者とレビュー担当者が設計判断と失敗時の挙動を説明できる状態でマージします（AI時代の開発生産性でも扱っています）。

関連して読める記事

技術的負債をシステム単位で評価し、刷新戦略や返済手段を選ぶ場合は、次の記事も参照してください。

レガシーシステムとは？「古い」だけでは決まらない判定基準と放置のリスク

レガシーシステムの本質は古さではなく、許容できるコストとリスクで保守や変更を続けられなくなったことです。経産省のレガシーシステムモダン化委員会総括レポートの定義を起点に、EOL・自動テスト・属人化・ドキュメントなど8観点の判定チェックリスト、セキュリティ・事業・人材の3面から見た放置のリスク、「2025年の崖」その後の政策動向、資産棚卸しから始める対応の入口までを整理します。

2026年7月29日

モダナイゼーションとは？クラウド移行の7Rと選び方の基準

モダナイゼーションとは、既存のアプリケーション、インフラ、開発運用プロセスを更新し、事業や運用上の成果を改善していく取り組みです。クラウド移行との違いを整理したうえで、AWSが定義する7つの移行戦略（7R）を原典に沿って表で解説し、事業価値や変更頻度だけでは決まらない選び方の判断材料、ストラングラーフィグによる段階移行、成果指標から始める進め方と注意点までをまとめます。

2026年7月29日

リファクタリングとリライト（作り直し）の違い：分岐条件と、リライトが失敗しやすい理由

リファクタリングは外部から見た振る舞いを変えずに内部構造を改善する作業、リライトは実装を新たに作って置き換えることです。この2つはリスクの形も前提条件も違います。Joel Spolskyの古典が指摘した全面リライトの2つのリスク（暗黙の仕様の喪失・追いかけ続ける本番）、リファクタリングで足りる条件とリライトに寄る条件の分岐、ストラングラーフィグによる中間の道、どちらでも先に必要になる投資までを整理します。

2026年7月29日

開発生産性を経営に説明する方法：CTO／VPoEのための「翻訳」の技術

デプロイ頻度もリードタイムも測っているのに、経営会議では「で、結局順調なの？」と聞き返される。原因は翻訳の工程が抜けていることです。経営の言語であるお金・時間・リスクへ指標を言い換える方法、ベースライン→投資→差分の報告構造、毎回同じ1枚を出し続ける定点フォーマット、やってはいけない説明、そして報告を受ける経営者側のチェックリスト5問までをまとめました。

2026年7月29日

AI駆動開発では、コード品質が事業競争力になる

AI駆動開発で競争力を出すには、ツール選定よりも既存コードベースの品質・設計・自動テストが重要です。コード品質が事業スピードに直結する理由と、経営層が90日で着手すべき基盤整備を整理します。

2026年6月18日

変更のリードタイムとは？コミットから本番までを測るDORA指標と短縮の順序

変更のリードタイムとは、コミットから本番デプロイまでの時間を測るDORAのFour Keys指標です。なぜ起点が企画ではなくコミットなのか、レビュー待ちとデプロイ待ちに分解する見方、中央値で測る理由、短縮に取り組む順序までを実務目線で整理します。

2026年7月28日