エンタープライズアーキテクチャ・システム企画重要度:★★★出題: AM2・PM1・PM2

技術的負債

ぎじゅつてきふさい / Technical Debt

短期的な納期やコストを優先して安易な設計やパッチ当てを行った結果、将来的な変更コストや障害リスクが増大する歪み。

3行速習ポイント

金融の借金と同様に、放置すると「利息（日々の保守コストや改修難度の跳ね上がり）」が雪だるま式に膨張する。
リファクタリングやアーキテクチャ刷新によって「元金を返済」しない限り、開発生産性はゼロに近づく。
ITストラテジストは、経営陣に対して技術的負債の返済（基盤改善）への投資枠確保を提言する。

図解

図技術的負債の雪だるま式膨張メカニズムプロセス・手順フロー

目先の妥協が将来の開発生産性を壊滅させる

▶ 進行順序：1. 借金発生➔2. 利息増大➔3. 債務超過➔4. 元金返済

11. 目先の納期・安易な改修

借金発生

コピペ・パッチ当て

目先のリリース納期を優先するあまり、アーキテクチャ設計やコードレビューを省略して場当たり的なコピー＆ペーストやハードコーディングで急場しのぎの改修を行う。

22. コードの複雑化・属人化

利息増大

ドキュメント不備

度重なる継ぎ接ぎ改修によりプログラムの依存関係がスパゲティ化し、設計書も更新されないため有識者しか触れないブラックボックス状態（高利息の発生）に陥る。

33. 開発スピードの激減

債務超過

バグ頻発・工数激増

わずかな仕様変更でも予期せぬ箇所でデグレード障害が多発し、影響調査と回帰テストに膨大な工数が奪われて新規DX機能の開発スピードが著しく停滞する。

44. 負債の計画的返済

元金返済

リファクタリング・刷新

静的解析で負債箇所を可視化して経営層の理解を得て、各スプリント工数の15〜20%を計画的リファクタリングと自動テスト整備に充当し、開発生産性を再生させる。

💡 午後IIでは場当たり的改修の蓄積（技術的負債）が新規DX開発の足を引っ張っている現状を可視化し、開発工数の一定枠を計画的リファクタリングへ充てる統制を描く。

概要と本質

ウォード・カニンガムが提唱した技術的負債は、短期的なリリースを急ぐために妥協した設計や汚いコード、古いフレームワーク、未更新のライブラリの放置を指します。短期的には早く機能を出せても、中長期的には追加開発のたびにバグが発生し、エンジニアが退職する原因となります。

重要ポイント・コア概念

負債の利息：新機能追加のたびにかかる余計な調査工数、頻発するリグレッションテストの工数増
負債の返済：計画的に開発工数の10〜20%をリファクタリングやテスト自動化、ライブラリ更新に割り当てる
負債の可視化：静的コード解析ツール（SonarQube等）で重複コード、循環的複雑度、セキュリティ脆弱性をスコア化
経営層への説明責任：「動いているから直す必要はない」という経営陣に対し、利息の支払いが新規開発を阻害している事実を数字で示す

試験対策・午後II論文での活用法

午後II論文で『なぜ大規模改修や基盤刷新が必要だったのか』の動機を説明する際の最重要キーワード。『度重なる個別要件のパッチ当てにより技術的負債が蓄積し、新サービスリリースのリードタイムが従来の3倍に悪化していた。そこで負債解消のためのリファクタリング枠をプロジェクトに組み込んだ』と書くことで抜群の現実味が出る。