エンタープライズアーキテクチャ・システム企画
午前II午後I午後II論文
重要度:
技術的負債
よみがな: ぎじゅつてきふさい
英語名称・略称: Technical Debt
1行要約（本質）
短期的な納期やコストを優先して安易な設計やパッチ当てを行った結果、将来的な変更コストや障害リスクが増大する歪み。
3つの重要ポイント
1
金融の借金と同様に、放置すると「利息（日々の保守コストや改修難度の跳ね上がり）」が雪だるま式に膨張する。
2
リファクタリングやアーキテクチャ刷新によって「元金を返済」しない限り、開発生産性はゼロに近づく。
3
ITストラテジストは、経営陣に対して技術的負債の返済（基盤改善）への投資枠確保を提言する。
構造・プロセスの図解
図技術的負債の雪だるま式膨張メカニズム
目先の妥協が将来の開発生産性を壊滅させる11. 目先の納期・安易な改修
コピペ・パッチ当て
設計を疎かにして場当たり的にリリース。初期借入。
22. コードの複雑化・属人化
ドキュメント不備
誰も全体像を理解できず、修正の影響範囲がブラックボックス化。
33. 開発スピードの激減
バグ頻発・工数激増
ちょっとした修正に数ヶ月。新規機能のリリースが絶望的に停滞。
44. 負債の計画的返済
リファクタリング・刷新
予算と時間を確保し、アーキテクチャの抜本改善を実行して再生。
概要・背景・本質
ウォード・カニンガムが提唱した技術的負債は、短期的なリリースを急ぐために妥協した設計や汚いコード、古いフレームワーク、未更新のライブラリの放置を指します。短期的には早く機能を出せても、中長期的には追加開発のたびにバグが発生し、エンジニアが退職する原因となります。
コア概念と着眼点
- 負債の利息：新機能追加のたびにかかる余計な調査工数、頻発するリグレッションテストの工数増
- 負債の返済：計画的に開発工数の10〜20%をリファクタリングやテスト自動化、ライブラリ更新に割り当てる
- 負債の可視化：静的コード解析ツール（SonarQube等）で重複コード、循環的複雑度、セキュリティ脆弱性をスコア化
- 経営層への説明責任：「動いているから直す必要はない」という経営陣に対し、利息の支払いが新規開発を阻害している事実を数字で示す
ITストラテジスト試験（午後I記述・午後II論文）での論述ポイント
午後II論文で『なぜ大規模改修や基盤刷新が必要だったのか』の動機を説明する際の最重要キーワード。『度重なる個別要件のパッチ当てにより技術的負債が蓄積し、新サービスリリースのリードタイムが従来の3倍に悪化していた。そこで負債解消のためのリファクタリング枠をプロジェクトに組み込んだ』と書くことで抜群の現実味が出る。