2026.11.14 Webシステム

技術的負債とは：意味と溜まり方、発注者が見積と保守費で気付く兆候と返済の判断

技術的負債とは、納期を優先して書いたコードや更新されないまま古くなった基盤のせいで、その後の改修のたびに余分な工数を払い続ける状態を指します。ソフトウェアの内部の話に見えても、発注者にとっては「小さな改修なのに見積が高い」「保守費が毎年上がる」という形で表に出てくる問題です。この記事では、技術的負債の意味と元本・利息の考え方、溜まり方の4分類、見積書や保守費から気付く兆候、SonarQubeなどでの可視化、リファクタリング・段階移行・刷新・放置の選び方、委託先と負債を増やさないための取り決めを順に扱います。開発チーム向けの手法解説ではなく、費用を払う側が判断するための整理です。

まとめ：技術的負債は改修のたびに払う利息で、返済先は変更頻度で決める

技術的負債は「悪いコード」の言い換えではありません。改修のたびに上乗せされる工数、つまり利息が発生しているかどうかで判断する概念です。利息が見えるのは、改修見積に占める影響調査とテストの割合、毎年の保守費、特定の担当者への依存度です。

返済は全部を一度にやるものではありません。変更が頻繁に入る箇所から順にリファクタリングで返し、基盤そのものの保守期限が切れているなら段階移行か刷新を選びます。ほとんど変更されない安定した箇所は、返さないと決めてかまいません。

新たな負債を増やさないためには、委託契約の段階でテストコードや設計書を納品物に含め、暫定対応の記録を保守報告の項目にしておくのが効きます。

技術的負債の意味をカニンガムの比喩と元本・利息の関係で読み解く

技術的負債という言葉は、金融の借金になぞらえた比喩です。比喩の中身を押さえておくと、開発会社が「負債があります」と言ったときに何を指しているのかを具体的に聞き返せます。

1992年にウォード・カニンガムが借金にたとえた技術的負債の由来

この言葉は、Wikiの考案者として知られるウォード・カニンガム氏が、1992年の学会OOPSLAで発表した報告The WyCash Portfolio Management Systemで使ったのが始まりです。報告には「最初に書いたコードを出荷するのは借金をするようなものだ」という一文があり、少しの借金は書き直しで速やかに返せば開発を速めるとも書かれています。

同じ報告は、危険なのは借金を返さないときだと続けます。完全には正しくないコードに費やす時間は、すべてその借金の利息に数えられるという整理です。急ぐこと自体を否定した言葉ではない点は覚えておく価値があります。

元本はコードの整理にかかる工数、利息は機能追加のたびに余分にかかる工数

マーティン・ファウラー氏は2019年に改稿した解説Technical Debtで、変更を本来より難しくする内部品質の欠陥を「cruft」と呼び、機能追加にかかる余分な労力を利息と位置付けています。挙げられている例では、モジュール構造が乱れたままだと6日かかる機能追加が、5日かけて構造を整理した後なら4日で済みます。

この5日が元本の返済にあたります。同種の機能追加が今後2回以上控えているなら、先に整理した方が合計日数は短くなる計算です。発注者が見積を読むときも、この「元本を返すと次回以降いくら軽くなるか」という問いを立てると判断しやすくなります。

改修費用の負担から見るバグや障害と技術的負債を分けて考える理由と境界線

バグは「仕様どおりに動かない」不具合で、利用者が気付きます。技術的負債は、動いてはいるものの直したり足したりするのが高くつく状態で、利用者には見えません。前者は瑕疵対応や保守の範囲で直すもの、後者は改修費用の上乗せとして現れるものです。

分けておく理由は費用の出どころにあります。負債の返済を「バグ修正」として無償対応させようとすると委託先と揉めますし、逆にバグを負債と呼んで有償の改修に回されるのも筋が違います。

技術的負債が溜まる経路を4象限と受託開発の契約構造から整理する

負債はすべて怠慢から生まれるわけではありません。どう生まれたかで、責任の所在も返し方も変わります。

慎重か無謀か、意図的か無自覚かで負債を分けるファウラーの4象限

ファウラー氏は2009年のTechnical Debt Quadrantで、負債を「無謀か慎重か」と「意図的か無自覚か」の2軸で4つに分けました。

分類	典型的な場面	発注者から見た扱い
慎重・意図的	展示会に間に合わせるため、返済を前提に暫定実装した	返済時期と費用を合意しておけば健全
無謀・意図的	時間がないとして設計を省き、記録も残さなかった	最も揉めやすい。記録の有無を確認する
無謀・無自覚	設計の知識が足りないまま作り込んだ	委託先の技術力の問題として選定時に見る
慎重・無自覚	作り終えてから、より良い構造に気付いた	避けられない。定期的な見直しで返す

実務で問題になるのは2行目です。暫定対応そのものより、暫定であることが誰にも共有されないまま本番で使われ続ける点が負債を膨らませます。

納期優先の暫定対応が検収後も恒久化する受託開発ならではの溜まり方

受託開発では、検収日と予算が先に決まり、要件の追加は後から入ってきます。追加分を期日内に収めるため、既存の処理をコピーして一部だけ書き換える、条件分岐を継ぎ足すといった対応が選ばれやすくなります。

検収時点では動いているため、受入テストでは見つかりません。次の改修を別の会社や別の担当者が受けたときに初めて、同じ処理が5か所に散らばっていることが判明し、影響調査の見積に跳ね返ります。発注者が仕様変更を出す時期が遅いほど、この形の負債は増えます。

ライブラリやOSの保守期限切れで、触らなくても増えていく負債

コードに一切手を入れていなくても負債は増えます。利用しているフレームワーク、言語の実行環境、OS、データベースにはそれぞれ保守期限があり、期限を過ぎると脆弱性の修正が提供されません。期限切れの部品が2世代、3世代と離れるほど、更新の手間は段違いに大きくなります。

経済産業省のDXレポートが提起した「2025年の崖」も、根にあるのはこの種の老朽化です。2025年の崖とDXレポートの試算を振り返った記事で、期限を過ぎた今どう刷新を判断するかを扱っています。

発注者が見積書と保守費の推移から技術的負債に気付く4つの兆候

ソースコードを読めなくても、技術的負債は請求書と体制に表れます。次の4つのうち2つ以上が当てはまるなら、委託先に負債の棚卸しを依頼する段階です。

小さな改修でも見積が膨らみ、影響調査の工数が大半を占める状態

画面の項目を1つ追加するだけの依頼で、見積の内訳に「影響調査」が実装より大きく計上されるのは典型的な兆候です。同じ処理が複数箇所に散らばっていたり、どこから呼ばれているか追えなかったりするため、触る前の調査に時間がかかります。

見積を受け取ったら、調査・実装・テストの比率を聞いてください。実装より調査とテストの合計が明らかに大きい状態が続くなら、利息を払っているのとほぼ同じです。

リリースのたびに既存機能が壊れ、回帰テストを毎回手で回す状態

ある画面を直したら別の画面の集計がずれた、という事故が繰り返されるのも兆候です。処理同士の依存が強く、変更の影響範囲を予測できなくなっています。自動テストが無いため、委託先はリリースのたびに手作業の確認を見積に積むしかありません。

この状態ではリリースの間隔も延びます。月1回だった改修が四半期に1回になったら、負債の利息が開発速度に回ってきたと見てよいでしょう。

特定の担当者しかシステムに触れず、異動や退職で保守体制が揺らぐ状態

「この部分は○○さんしか分からない」という箇所は、設計書もテストも無く、知識が個人に溜まっている状態です。担当者が異動した途端に見積が倍になったり、委託先から改修を断られたりします。

ここまで進むと、技術的負債は読めないシステムの問題に変わります。システムが読めなくなる原因と解消手順を整理したブラックボックス化の記事で、現状を把握する手順をまとめています。

保守費が毎年上がる一方で、改修の件数と規模は増えていない状態

保守費の請求額を3年分並べ、同じ期間の改修件数と比べてみてください。件数が横ばいなのに金額だけ上がっているなら、1件あたりにかかる手間が増えています。期限切れ部品への個別対応や、障害の調査工数が保守費に溶け込んでいる場合もあります。

保守契約の範囲と費用の考え方はシステム保守の費用相場と契約形態で整理しています。保守報告に作業内訳を出してもらうと、増えている原因を切り分けられます。

技術的負債を数字で示すSonarQubeの負債比率と優先順位の付け方

兆候に気付いたら、次は量を測ります。社内で予算を通すには、感覚ではなく数字が要ります。

SonarQubeの負債比率は1行30分の開発コストに対する修正工数の割合

静的解析ツールのSonarQubeは、検出した保守性の問題ごとに修正工数を分単位で割り当て、その合計を技術的負債として表示します。2026年11月時点の公式ドキュメント（SonarQube Server 2026.5の指標定義）では、負債比率を「修正工数 ÷（1行あたりの開発コスト × 行数）」と定義し、1行あたりの開発コストの既定値を30分、日数換算は8時間を1日としています。

保守性レーティング	負債比率
A	5%以下
B	5%以上10%未満
C	10%以上20%未満
D	20%以上50%未満
E	50%以上

たとえば10万行のシステムで比率が10%なら、修正工数は10万行×30分×10%で30万分、つまり5,000時間で、8時間を1日として625日分と計算されます。この日数は工数の目安であって、そのまま見積額にはなりません。委託先に解析結果を出してもらい、比率とその推移を確認する使い方が向いています。

指標だけで決めず、変更頻度と業務影響を掛け合わせる返済の優先順位

解析ツールは、変更がめったに入らないモジュールの問題も同じ重みで数えます。返済の順番を決めるときは、負債の量に加えて、過去1年の変更回数と、止まったときの業務影響を掛け合わせて見ます。

変更回数はGitなどの履歴から取れます。負債が多く、変更も多く、受注や請求など止められない業務に関わる箇所が最優先です。負債が多くても1年間一度も触っていない箇所は、後回しにしてかまいません。

技術的負債の返済をリファクタリング・段階移行・刷新・放置の4択で決める基準

返済手段は4つです。どれか1つを全体に当てはめるのではなく、箇所ごとに選び分けます。

変更頻度が高く構造が保てている箇所はリファクタリングで少しずつ返す

言語や基盤がまだ保守期限内で、問題がコードの書き方に留まっているなら、リファクタリングが第一候補です。振る舞いを変えずに内部の構造を整える作業なので、業務への影響を小さく抑えられます。

進め方は、機能追加の見積に整理の工数を一定割合で乗せる形が現実的です。ファウラー氏の例のように、次の改修で回収できる範囲から返すのが進め方の目安です。具体的な観点と着手のタイミングはリファクタリングの観点とタイミングで解説しています。自動テストが1本も無い場合は、先にテストを書く工程を見積に入れないと、整理の途中で既存機能を壊します。

基盤の保守期限切れや言語の世代差が大きい場合に選ぶ段階移行と刷新

フレームワークやOSの保守期限が切れている、言語のバージョンが2世代以上古い、といった場合はコードの整理では返せません。この場合はリファクタリングを採用しません。機能単位で新しい基盤へ少しずつ移す段階移行か、作り直す刷新を選びます。

段階移行は、旧システムを動かしたまま入口で処理を振り分けるため、切り戻しが効きます（ストラングラーフィグパターンによる段階移行）。業務の流れそのものを変える予定があるなら刷新の方が無駄がありません。どちらにするかの診断から移行計画までは、一創のシステムマイグレーション・リプレイスで相談を受けています。

保守期限内で変更の少ない安定した箇所は返済しないと決めるのも正しい判断

ファウラー氏も、cruftがあっても変更の少ない安定した箇所は放置してよいと書いています。年に一度も改修しない帳票出力や、廃止予定の機能に返済費用をかけても、利息が発生していないため回収できません。

ただし放置が許されるのは、保守期限内の基盤の上に載っている場合に限ります。期限切れの部品を使っている箇所は、触らなくても脆弱性という形で負債が増えるため、放置の対象から外してください。

返済費用を予算化するときに見積に入れてもらう項目と社内説明の材料

返済は新機能を生まないため、社内では後回しにされがちです。予算を通すには、委託先に次の項目を見積に分けて書いてもらいます。

返済対象の箇所と、その箇所の過去1年の改修回数
返済にかかる工数（元本）
返済後に1回の改修で減る見込みの工数（利息の削減分）
返済しない場合に保守期限切れで生じるリスクと期日

元本と利息の削減分が並んでいれば、何回の改修で元が取れるかを示せます。経営層への説明は、この回収回数と期限切れの期日の2点に絞ると通りやすくなります。

委託先と技術的負債を増やさないために契約と受入で決めておくこと

負債の多くは、発注時の取り決めが無いことから生まれます。新規開発でも保守契約の更新でも、次の2点は契約書か仕様書に書いておきます。

受入時にテストコードと設計書と依存部品の一覧を納品物に含める

納品物が「動くプログラム」だけだと、次の担当者は中身を読み解くところから始めることになります。自動テストのコード、設計書、利用しているライブラリとそのバージョンの一覧を納品物に明記しておけば、委託先が変わっても改修の起点が残ります。

依存部品の一覧があれば、保守期限が近づいた部品を発注者側でも把握できます。受入テストでは、テストコードが実際に実行できることまで確認してください。

暫定対応の箇所と理由を記録する負債台帳を保守契約の月次報告項目にする

期日を守るための暫定対応は避けられません。問題は、暫定であることが記録されずに消えることです。暫定対応を入れた箇所、理由、本来の対応、想定工数を一覧にした負債台帳を、月次の保守報告に含めてもらいます。

台帳があれば、慎重・意図的な負債だけが残る状態を保てます。年に一度、台帳の上位から返済分を予算に組み込めば、刷新が必要になるまで負債を溜め込む事態を避けられます。

よくある質問

技術的負債について、発注者や情報システム部門から寄せられやすい質問をまとめました。

技術的負債を一言で言うと何ですか？

後から余分な手間を生む、ソフトウェアの作りの問題です。急いで書いたコード、継ぎ足された分岐、更新されないまま古くなった部品などが原因で、改修のたびに調査やテストの工数が上乗せされます。この上乗せ分を借金の利息に、作りを整える作業を元本の返済にたとえた言葉で、1992年にウォード・カニンガム氏が使ったのが始まりです。

技術的負債にはどんな例がありますか？

同じ処理のコピーが複数箇所にある、自動テストが無く毎回手作業で確認している、保守期限の切れたフレームワークを使い続けている、設計書が無く特定の担当者しか構造を知らない、といったものが代表例です。いずれも今は動いていますが、次の改修で影響調査やテストの費用として表に出てきます。

技術的負債はゼロにすべきですか？

ゼロを目指す必要はありません。期日を守るために返済計画つきで負う負債は、開発を速める手段として正当です。変更の入らない安定した箇所に残る負債も、利息が発生しないため放置してかまいません。問題になるのは、記録が無いまま放置された負債と、保守期限切れの部品に由来する負債です。

技術的負債はどうやって見える化しますか？

SonarQubeなどの静的解析ツールで、修正工数と負債比率を出すのが一般的です。SonarQubeでは1行あたり30分を開発コストの既定値とし、比率が5%以下ならA、50%以上ならEと評価します。これに加えて、Gitの履歴から箇所ごとの変更回数を取り、改修見積の内訳から影響調査の比率を見ると、返済の優先順位を付けられます。

技術的負債の返済は誰の費用負担になりますか？

契約で暫定対応の返済を約束していない限り、返済は発注者の費用で行う改修として扱われるのが一般的です。仕様どおりに動かない不具合であれば瑕疵や保守の範囲ですが、動いている作りを整える作業は別扱いになります。揉めないためには、暫定対応を負債台帳に記録し、返済の時期と費用負担を保守契約で決めておくことです。