技術的負債を放置するといくらかかるのか｜返済を判断する基準と進め方
「この機能を追加するには、まず既存の部分を作り直す必要があります」と開発会社に言われ、想定より大きな見積もりを受け取ったことはないでしょうか。あるいは、小さな修正のはずが毎回時間がかかり、修正するたびに別の場所で不具合が起きるという状況に心当たりがあるかもしれません。
こうした状況の背景にあるのが「技術的負債」です。開発を急いだ設計や、場当たり的な修正の積み重ねが、後の変更コストを押し上げている状態を指します。目に見える請求書があるわけではないため、経営者や発注担当者からは存在が分かりにくいのが特徴です。
一方で、技術的負債はすべて返済すべきものでもありません。返済には費用がかかり、その間は新しい機能の開発が止まります。放置した場合のコストと返済のコストを比べ、返済する価値のある部分を選ぶ判断が必要です。
この記事では、技術的負債の意味、放置したときにコストがどこに表れるか、負債の大きさを発注側が把握する方法、返済するかどうかを判断する基準、返済の進め方を解説します。
技術的負債という言葉が指すもの
技術的負債は、プログラマーのウォード・カニンガムが1992年の報告で用いた比喩に由来します。彼は、最初に書いたコードを出荷することを借金にたとえ、少しの借金は開発を速めるが、書き直しによって速やかに返済することが前提だと述べています。つまり、もともとは「借金をしてでも早く出す」判断そのものを否定する言葉ではありませんでした。
日本では、経済産業省が2018年に公表した「DXレポート」で、技術的負債を「短期的な観点でシステムを開発し、結果として、長期的に保守費や運用費が高騰している状態」と説明しています。同レポートは、企業のIT関連費用の8割が現行ビジネスの維持・運営に割り当てられているという調査結果を引用し、既存システムを放置すれば維持管理費がさらに膨らむと指摘しました。
負債という比喩が分かりやすいのは、元本と利息の関係で説明できるからです。
| 比喩 | システムで起きていること |
|---|---|
| 借入れ | 納期や予算を優先して、後で直す前提の設計や実装を選ぶ |
| 元本 | 本来あるべき設計に直すために必要な作業量 |
| 利息 | 負債があることで、修正や機能追加のたびに余計にかかる時間と費用 |
| 返済 | 設計の見直し、コードの整理、古い部品の更新 |
技術的負債は、意図して借りたものだけではありません。開発の途中で業務の理解が深まり、当初の設計が最適ではなかったと後から分かることもあります。担当者の交代で設計の意図が引き継がれず、部分ごとに違う考え方で修正が重なった結果として生まれる負債もあります。どの経緯で生まれた負債かによって、返済の優先度や進め方も変わります。
参考：The WyCash Portfolio Management System／Ward Cunningham（OOPSLA ’92）
参考：DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～／経済産業省
放置するとどこにコストが表れるか
技術的負債のコストは、請求書の中で「技術的負債」という項目として現れるわけではありません。発注側から見えるのは、次のような形です。
- 小さな修正や機能追加の見積もりが、毎回想定より大きい
- 修正のたびに別の場所で不具合が起き、テストと手戻りが増える
- リリースまでの期間が長くなり、業務の変化に追いつけない
- 特定の担当者しか触れない部分があり、その人が不在だと対応が止まる
- OSや言語のサポート期限が切れた部品を使い続け、セキュリティ上の不安が残る
- 保守を別の会社に引き継ごうとしても、調査費用が高く見積もられる
これらは、保守費の増加と、機会損失の二つに分けて考えられます。保守費の増加は、毎月の保守契約や改修の見積もりに表れるため、過去の実績と比べれば把握しやすいコストです。機会損失は、新しいサービスを始めたい、業務を変えたいというときに、システムの変更が間に合わずに失う利益です。こちらは金額にしにくいものの、事業への影響はより大きくなることがあります。
利息にあたるコストは、時間とともに増える傾向があります。負債のある部分に修正を重ねるほど構造は複雑になり、次の修正はさらに難しくなります。また、使っている部品のサポート期限は待ってくれません。サポートが切れた部品の更新を先送りにするほど、まとめて更新するときの作業量は大きくなります。
発注側にとって厄介なのは、利息の支払いが「いつもの保守費」や「いつもの改修費」に紛れて見えにくいことです。毎年少しずつ費用が増えていても、単年度の予算の中では目立たず、気づいたときには機能追加のたびに大きな見積もりが出る状態になっています。費用の推移を複数年で並べて見ることが、負債に気づく第一歩になります。
負債の大きさを発注側が把握する方法
「技術的負債がいくらあるか」を正確な金額で示すことは困難です。ただし、発注側でも、利息がどれくらい膨らんでいるかを推し量ることはできます。開発会社や保守担当に、次の情報を出してもらってください。
| 確認する情報 | 見るポイント |
|---|---|
| 改修の見積もりと実績の推移 | 同じ程度の規模の改修にかかる工数が、年々増えていないか |
| 不具合の発生件数と箇所 | 特定の機能や画面に不具合が集中していないか |
| リリース後の手戻り | 修正のリリース後に、別の不具合の修正が続いていないか |
| 使用している部品の一覧とサポート期限 | OS、言語、フレームワーク、ライブラリのサポートが切れていないか、近く切れるものはないか |
| 属人化の状況 | 特定の担当者しか分からない部分はどこか、設計書やテストコードは残っているか |
このうち、部品のサポート期限は客観的に確認できる情報です。たとえばPHPは、各バージョンにリリースから2年間のバグ修正期間と、その後2年間のセキュリティ修正のみの期間を設け、それを過ぎるとサポートを終了する方針を公式サイトで示しています。自社のシステムがどのバージョンで動いているかを一覧にし、期限と並べるだけでも、更新が必要な時期が見えてきます。
開発会社に負債の状況を尋ねるときは、「問題はありますか」と聞くのではなく、「同じ規模の改修が3年前より時間がかかっている理由は何か」「次に大きな更新が必要になる部品はどれか」のように、具体的な問いを立てると、判断に使える答えが返ってきます。
第三者の目で診断してもらう
現在の開発会社や保守担当から出てくる情報だけでは、判断しにくい場合もあります。負債を作った当事者は、問題を小さく見積もったり、反対に作り直しを強く勧めたりすることがあるためです。判断に迷う場合は、別の開発会社に有償でソースコードや構成の調査を依頼し、負債の箇所と返済の優先度について意見をもらう方法があります。
調査を依頼するときは、目的を明確にしておきます。「今後3年間、月に数件の機能追加を続ける前提で、優先して直すべき箇所を知りたい」のように、今後の使い方を伝えると、返済の要否まで含めた答えが得られやすくなります。調査の結果は、現在の開発会社と返済の計画を話し合うときの共通の資料として使えます。
返済するかどうかを判断する基準
技術的負債の返済は、放置した場合に払い続ける利息と、返済にかかる費用を比べて判断します。判断の材料になるのは、そのシステムを今後どれくらい使い続けるか、どれくらい変更するかです。
| システムの状況 | 判断の目安 |
|---|---|
| 今後も頻繁に機能追加や変更を行う | 変更の多い部分から優先して返済する。利息の支払いが続くため、早く返すほど効果が大きい |
| 安定して動いており、変更はほとんどない | 大規模な返済は不要なことが多い。サポート期限への対応とセキュリティ更新に絞る |
| 数年以内に廃止や入れ替えを予定している | 返済よりも、入れ替えまで安全に動かすための最低限の対応を優先する |
| サポートが切れた部品を使い、外部に公開している | セキュリティ上のリスクがあるため、変更頻度にかかわらず更新を優先する |
| 特定の担当者に依存しており、その人の退職や交代が見込まれる | 設計書の整備と引き継ぎを優先し、属人化を解消する |
変更がほとんどないシステムの負債は、利息がほとんど発生していないため、返済の優先度は低くなります。反対に、毎月のように手を入れているシステムは、負債があるだけで修正のたびに余計な費用を払っていることになります。返済の判断は、システム全体ではなく、変更の多い部分とリスクの高い部分を選んで行うのが基本です。
返済の効果は、利息がどれだけ減るかで説明できると、社内の合意も取りやすくなります。たとえば、改修の実績から「この部分に関わる修正は毎回想定の倍程度の工数がかかっている」と分かれば、今後予定している改修の件数と掛け合わせて、放置した場合の追加コストを試算できます。この試算と返済の見積もりを並べれば、何年で元が取れるかを判断できます。
なお、新規事業の立ち上げや検証の段階では、あえて負債を抱えてでも早く出す判断が合理的なこともあります。その場合は、どこを後で直す前提にしたのかを記録し、本格運用に移る前に返済の時期を決めておくことが重要です。検証段階で作ったサービスを本番運用に移すときに、認証やインフラを含めて作り直す判断が必要になるのは、この返済の典型例です。
返済を見送る判断をした場合も、その理由と、見直す条件を記録しておきます。「変更がほとんどないので返済しない。ただし年に数回以上の改修が必要になったら再検討する」のように条件を決めておけば、状況が変わったときに判断をやり直せます。技術的負債は一度判断して終わりではなく、システムの使われ方に合わせて定期的に見直すものです。年に一度、保守契約の更新や予算策定の時期に合わせて、部品の一覧と改修実績を確認する場を設けると、負債の状況を継続して把握できます。
返済の進め方
技術的負債の返済は、一度にすべてを作り直すよりも、優先度の高い部分から段階的に進めるほうが、リスクと費用を抑えられます。進め方は次のとおりです。
- 現状の把握として、部品の一覧とサポート期限、不具合や改修工数の多い箇所を洗い出す
- 前の見出しの基準で、返済する部分と、当面は手をつけない部分を分ける
- 返済する部分について、作業量と、返済によって減る利息を見積もる
- 通常の機能追加と並行して進めるか、返済のための期間を別に設けるかを決める
- 返済の前後で、改修工数や不具合件数がどう変わったかを確認する
通常の開発と並行して進める場合は、機能追加の際に関係する部分を少しずつ整理する方法が取られます。開発の工数の一部を毎回返済に充てるルールを決めておくと、負債が積み上がり続ける状態を避けられます。サポート期限が迫った部品の更新や、構造の大きな見直しが必要な場合は、返済のための期間と予算を別に確保するほうが確実です。
全面的な作り直しは、最後の選択肢と考えてください。作り直しの期間中は既存システムの保守も続ける必要があり、新しいシステムが既存の業務を漏れなく再現できるかという別のリスクも生まれます。作り直しを検討する場合でも、既存システムの機能と業務ルールを整理する作業から始めることになります。
返済を開発会社に依頼するときは、作業の成果を発注側が確認できる形で約束してもらうことが大切です。「コードをきれいにする」という目標では、終わったかどうかを判断できません。「この部品をサポート期間内のバージョンに更新する」「この機能の自動テストを整備する」「設計書を作成する」のように、完了を確認できる単位で依頼します。
まとめ
技術的負債は、短期的な判断や場当たり的な修正の積み重ねによって、後の変更コストが膨らんでいる状態です。コストは請求書の項目としては現れず、改修見積もりの増加、不具合の多発、属人化、サポート切れの部品といった形で表れます。
返済するかどうかの判断基準を整理すると次のとおりです。
- 頻繁に変更するシステムは、変更の多い部分から早めに返済する
- 変更がほとんどないシステムは、サポート期限とセキュリティへの対応に絞る
- 廃止や入れ替えが近いシステムは、最低限の対応で安全に動かす
- 外部に公開していてサポート切れの部品があるなら、変更頻度にかかわらず更新を優先する
最初の一歩としては、自社のシステムで使っているOS、言語、フレームワークのバージョンとサポート期限を一覧にすること、そして過去数年分の改修見積もりと実績を並べることをおすすめします。この二つの資料があれば、負債の利息がどこで膨らんでいるかが見え、開発会社と返済の優先順位を具体的に話し合えるようになります。