技術的負債とはメンテコストや古くなったライブラリのセキュリティリスクや、学習コストなどなどエンジニアリングの観点でも様々な負債が積み重なってしまったものを指すものだと私は認識しています。
実世界でも預金通帳みたいに現在残高が分かれば来月生きていけないというのは誰の目にもわかります。
が、金が足りないために借金をしていたという場合、借金の総額については本人すら分からないという場合もあるでしょう。
この 「あといくら、どこから借りてどこに返すか、年利でどれだけ増えるかわからん借金返済問題」 こそ技術的負債の正体だなと思いました。
で、この記事を書こうとする前に以下の投稿をXで見つけて、なるほどこれだなと再認識した次第です。
見える化するためのなにか
ということで具体的に技術的負債を可視化していくために、技術的負債を非エンジニアでもわかりやすい 「借金問題」 に置き換えて考えてみました。
なんだかよくわからないFour Keysやライブラリ、アーキテクチャなどの横文字と開発生産性、保守容易性、などの特性・性質用語もなるべく使わないようにしてみましょう。
借金（技術的負債）の原因
生活費不足
給与が不足していたり、突発的な出費に対応できない場合
エンジニアリングだと予算不足と突然の仕様変更による無理が祟った状態。背景にデスマーチが見え隠れする。
教育・学費
高額な授業料や留学費用など、教育に関する支出。
エンジニアリングだと派遣社員の無理な投入、若手の無理な起用、人件費削減によるスキルギャップが負債を生む。
事業資金
企業の設立や運営資金、設備投資のために借りる。
エンジニアリングだと新規プロジェクトのための資金調達。主にエンジニア採用に使われる。
住宅・自動車購入
マイホームや車の購入に必要な大規模な資金を一括で用意できない場合。
エンジニアリングだとシステム基盤の刷新やインフラ投資。クラウド→オンプレミス、またはその逆などの資産計上。
自社でLLMをするためにGPUを積んだ高スペックサーバーを購入するような場面。
娯楽・浪費
無計画な消費や趣味に高額な費用を費やす。
エンジニアリングだと要件に合わない高コストのエンタープライズ製品の導入や、不要な機能の追加、本質的でない技術選定へのリソース浪費。
投資の失敗
株式、仮想通貨、不動産などでの損失。
エンジニアリングだと導入した新技術やツールが期待を満たさず、保守コストが増大。メンテナンスが終わってしまったOSS、人材獲得したものの離職率が増加など。
ギャンブル依存
パチンコや競馬などのギャンブルにおける多額の損失。
エンジニアリングだとリスクの高い技術や方法に無計画に投資し、予想外のコストがかかる。
あるあるな例だと「流行ってるから」という理由の技術投資。
2. 借金（技術的負債）の種類
無担保ローン
担保を必要としない借金（例：消費者金融、カードローン）。
エンジニアリングだと設計や仕様を無視した、その場しのぎのコード変更や簡易実装。プロジェクトのスケジュール未達、デプロイ頻度やPull Request数などのKPIに対する分かりやすいハックなどで発生。
担保付きローン
担保を設定する借金（例：住宅ローン、自動車ローン）。
エンジニアリングだと一定のリスクを伴うが、計画的に将来解消を目指すアーキテクチャ選択。計画的であれば問題ないが、大抵は「今は事業成長が優先」ということでやれずに負債になっていくパターンが多々有。
クレジットカード借入
リボ払いやキャッシング枠の利用。
エンジニアリングだと日常的な小さな修正やパッチ適用の漏れ。特に多くのOSSに依存するサービスの場合この対応が後手に回りがち。一度遅れると割れ窓理論のように、古くて当たり前の状況が長く続くように……。
学生ローン
教育資金に特化した低利率のローン。
エンジニアリングだと 経験不足のメンバーによる開発で発生する負債。ちゃんとしたレビュアーや指南役がいれば問題にならないかもしれないが、忙しい現場だと放置されがち。
事業融資
企業活動のために借りる資金（例：銀行融資、クラウドファンディング）。
エンジニアリングだと新規事業やプロジェクトで意図的に負債を許容して進める開発。MVPのために汚いスクラッチコードで開発を推進することもある。「これは仮実装だから」が5年残り続けるパターン。
親族や友人からの借金
非公式な借金で利息がない場合が多い。信頼関係がなくなるし社会的地位を失うより辛いパターンかもしれない。
エンジニアリングでは非公式なショートカットやチーム間の口頭合意に基づく負債。よく使われる魔法の言葉 「運用で回避」 。
闇金
ざわ・・・ ざわ・・・・
ざわ・・・「高金利……！それは返済不能への片道切符……！」 ざわ・・・
ざわ・・・違法な利率で膨れ上がる元本……！払えど払えど減らない……！
その実態は、金を借りた瞬間から始まる地獄……！ ざわ・・・・
ざわ・・・ ざわ・・・・
ざわ・・・
エンジニアリングでいうと規約や標準を無視した違法レベルの設計やコーディング。即時対応が必要。GPLライセンスやAGPLのOSSをオレオレ仕様に改造したままSaaSで売ったり、スクレイピングで仕入れた情報を自社の学習モデルに反映させてそのまま使うパターン。帝愛もびっくりなブラック手法！
借金（技術的負債）の返済方法
元利均等返済
毎月一定の返済額を支払う。元本と利息が均等に減少。
エンジニアリングだと小さな負債を計画的に返済し、新たな負債が増えないように進める計画的負債解消手段。バグや品質改善組織が立ち上がり、定期的に活動をし始める。
元金均等返済
毎月一定額の元金を返済し、利息は残高に応じて変動。
→ 優先度の高い負債を先に解消し、その後低リスクな負債を返済する。タスクフォース部隊として組織横断型の組織が結成されるパターン。その後一定の負債が解消されたら、元利均等返済方式に切り替わることがある。
一括返済
借入金全額を一度に返済する。
エンジニアリングだと大規模なリファクタリングやアーキテクチャ変更で、一気に負債を解消する方法。PHP→Go、Ruby→GoやRust、jQuery→Vueなどなど枚挙に暇がないほど各社で行われている。
繰り上げ返済
予定より早く返済を進め、利息を削減する。
エンジニアリングだと余剰リソースを活用し、計画外で負債解消を進める。リファクタリングやリアーキテクチャのプロを雇って専任で進めるプロジェクト立ち上げや、新規プロジェクト、機能開発時の見積もりにリファクタリングを入れ込むなどの手法。
リスケジュール（返済条件の変更）
金融機関と交渉して返済期間や金額を変更する。
エンジニアリングだとチームやステークホルダーと交渉し、負債解消の優先度や計画を見直す。プロダクトオーナーや経営層が泥を被るか覚悟を決める。
借り換え
低金利のローンに借り換えることで負担を軽減。
エンジニアリングだと負債を解消する代わりに、新しい技術やアーキテクチャに移行する。
どちらかというとAzure→GCP、GCP→AWSのようにクラウドサービスのようなインフラでのコスト面での乗り換えが該当。
債務整理
法律を活用して借金を減額または免除。
エンジニアリングだと技術的負債を再評価し、不必要な負債を削除し、優先度の高い部分に集中する。かっこいいことを言っているが、要はもともとの資産（プロダクト）を捨てて全部作り直すこと。リファクタリングのレベルを超えて事業開発ができるので覚悟さえあればなんとかなる。
まとめ
技術的負債も借金同様、原因を正確に把握し、状況に応じた解消方法を選ぶことが重要です。また、負債を完全にゼロにするのではなく、戦略的にコントロールすることで成長を支える要素にもなります。
エンジニアと非エンジニア間で共通言語のように会話できる要素に置き換えることで、若干技術的負債のポイントがわかりやすくなった感じがしました！