じゃあ、おうちで学べる
本能を呼び覚ますこのコードに、君は抗えるか
技術的負債の変質について
はじめに
最近、ふと気づいたことがある。技術負債って、もう昔とは全然違うゲームになってるんじゃないか？いや、もっと正確に言うなら、ゲーム自体が終わろうとしているんじゃないか？
コーヒーを飲みながら、10年前に書いた自分のコードを眺めていた。当時は「きれいに書いた」つもりだったけど、いくつかの要望がありよく考えずに変更を加えた結果、負債の塊だ。でも、それを直すのに必要な時間とコストの計算が、根本的に変わってしまった。 いや、変わったどころか、もはや「時間とコスト」という概念すら意味をなさなくなりつつある。
私たちは技術負債を「悪いコード」として理解してきた。しかし、それは大きな誤解だった。Ward Cunninghamが1992年に生み出した原初の概念は、現在広く信じられている「技術的問題」とは根本的に異なっていた。
彼の言う負債とは、ソフトウェアを素早くリリースして得られた学びと、現在のプログラムとの乖離のことだった。決して「雑なコードを正当化する」ものではなく、むしろ「現時点でのベストを尽くしたコードを、新しい理解に合わせて継続的にリファクタリングしていく」プロセスを指していたのだ。
でも、AIの登場で、このリファクタリング作業の大部分が「人間がやる必要のない仕事」になってしまった。 私たちが長年「誰もやりたがらない面倒な作業」として押し付け合ってきた技術的負債の処理が、AIにとっては「淡々と処理する単純なタスク」でしかない。
これは技術的負債の概念そのものの終焉を意味するのかもしれない。
このブログが良ければ読者になったり、nwiizoのXやGithubをフォロワーしてくれると嬉しいです。では、早速はじめていきます。
Wardの本来の意図と現在の乖離
ここで驚くべき事実を知ってほしい。Wardが説明している負債メタファーは、一般的にイメージされている「技術的負債」とはかなり違う。
Cunninghamが1992年のOOPSLA '92で述べた言葉：「最初のバージョンをリリースすることは、ある意味で借金を背負うようなものです」。重要なのは、彼が"technical debt"ではなく一貫して"debt"としか言っていないことだ。
実際、彼がこのメタファーを生み出したのは、自社プロダクトWyCash（債権ポートフォリオ管理システム）のリファクタリングについて上司に説明するためだった。金融系ソフトウェアを開発していたから、たまたま金融の例え話を使ったのだ。
現在の「技術的負債」から想像されるのは「リリース優先で雑なコードを書いたものの、結局はきれいに書き直されていないコード」や「古くなってしまった技術基盤」だろう。しかし、これらは誤解から生じているとWardは言う。
Wardの説明を要約すると：
- 借入（負債の発生）: ソフトウェアを急いで世に出して学びを得る（これは良いアイデア）
- 利子: 学びを得たにも関わらず、その学びをプログラムに反映しないことで生じる生産性低下
- 返済: 得られた経験や理解をリファクタリングによってプログラムに反映する
つまり、Wardにとって負債とは「理解の進化に追いつかないプログラム」のことであり、「雑なコード」のことではない。彼は明確に「その時のベストを尽くしてコードを書け」と言っている。
ここで重要なのは、Wardの負債メタファーの本質的な意味だ。彼が言う負債の悪影響とは、開発と共に得られていく知識や理解と目の前のシステムとの乖離が引き起こす生産性低下のことであり、コードの保守性や雑さのことではない。
Wardは明確に言っている：「私は雑なコードを書くことには全く賛成しませんが、たとえ理解が不完全だとしても、目の前の問題に対する現時点での理解を反映するコードを書くことには賛成です」。
そして重要なのは、この負債メタファーが後のXP（エクストリームプログラミング）やTDD（テスト駆動開発）の核心的な考え方になったということだ。実際、WyCashでのリファクタリング経験がKentBeckに強いインスピレーションを与え、『テスト駆動開発』の主要エピソードとして取り上げられることになった。
興味深いのは、「負債」という言葉に対する印象の違いだ。経営に近い人ほどポジティブな印象を持ち（資本のイメージ）、技術面に近い人ほどネガティブな印象を抱く（借金のイメージ）傾向がある。Wardが語っている負債メタファーは明らかにポジティブなものだった。
ソフトウェアを素早く何度もリリースし、経験や仮説検証から学びを得る開発手法は、現代では当たり前になった。しかし、その後「負債」という強い言葉が独り歩きして、現在のネガティブな技術的負債のイメージを作り上げてしまったのだろう。
ちなみに、Wardは一貫して"Debt"としか言っておらず、"Technical"という言葉を付けたのは後の人（Dave Smithという説が有力）なのだ。
Robert C. Martinが指摘するように、「乱雑さは技術的負債ではない。技術的負債は意識的な選択の結果であり、戦略的な理由から生じるものだ」。これはWardの本来の意図と完全に一致している。
技術負債の玉ねぎモデル：多層構造の理解
技術負債を包括的に理解するには、単一の視点では不十分だ。私たちは技術負債を多層構造として捉える必要がある。この「玉ねぎモデル」は、技術負債の表面的な症状から最深層の社会的複雑性まで、体系的に理解するためのフレームワークだ。
テクニカル層：見えやすい表面
最も目に見えやすい層がテクニカル層だ。コードの複雑性、アーキテクチャの不整合、技術スタックの陳腐化などがここに含まれる。しかし、これらは症状であって原因ではない。みんなが「コードが汚い！」って騒ぐのは、実はこの表面しか見てないからなんだ。
トレードオフ層：感情で決まる現実
技術負債の原因は、人間の意思決定のクセにある。特にヤバいのが「アフェクト・ヒューリスティック」。なんか難しそうな名前だけど、要するに「感情で判断してる」ってこと。
Christopher Hseeの研究で面白いのがある。新機能開発で技術負債を増やす判断って、「即時的」「確実」「具体的」「自分が経験する」利益と感じられる。一方で、技術負債を避ける判断は「将来的」「不確実」「無形」「他者が経験する」ものとして受け取られる。
この非対称性がクセモノなんだ。論理的には分かってても、感情的には負債を作る方向に流れてしまう。これは個人の能力の問題じゃなくて、人間の認知システムの構造的な特性なのよ。
システム層：組織という名の罠
でも話はここで終わらない。個人の判断だけじゃなく、組織のシステム自体が技術負債を生み出す構造になってる。
「過剰と崩壊」パターンって知ってる？プロジェクトに圧力がかかると、みんな補助的活動（ちゃんとした設計、テスト、リファクタリング）をサクッと切り捨てる。確かに一時的には進捗が良くなるんだけど、長期的には効率がガタ落ちして「消火活動モード」に突入する。
一度この状態に陥ると、もう抜け出すのは至難の業。技術的負債が「摩擦」となって、どれだけ人を投入しても何も進まなくなる。まさに地獄だよ。
現代の組織では、チーム構造自体が技術負債を生み出すパターンも多い。コンウェイの法則通り、組織の構造がアーキテクチャに反映され、それが負債となって蓄積していく。
経済学層：お金の論理で見えてくる構造
技術負債問題を経済学の視点で見ると、8つの典型的な問題パターンが見えてくる：
- プリンシパル・エージェント問題 - 開発チームとステークホルダーの利害対立
- コモンズの悲劇 - みんなで使う技術資産の荒廃
- 外部性 - 負債を作る人と被害を受ける人が違う
- 短期主義 - 目先の利益優先の判断
- 小さな決断の専制 - 些細な判断の積み重ねによる大きな歪み
- 忍び寄る正常性 - じわじわ悪化していく状況への慣れ
- アナーキーの代償 - 個人最適が全体最悪を生む
- モラルハザード - リスクのツケを他人に回せる状況
これらの問題を見ると、技術的負債が単なる技術問題じゃなくて、組織の構造的問題だってことがよく分かる。
厄介な問題層：最も深い社会的複雑性
技術負債の最深層にあるのが「厄介な問題（wicked problem）」としての性質だ。
厄介な問題っていうのは、こんな特性を持つ：
- 問題は解決策を見つけた後でしか理解できない
- ステークホルダーは根本的に異なる世界観を持つ
- 解決策は真偽ではなく良悪で判断される
- 解決策の効果を即座に判定できない
- あらゆる解決策は「一発勝負」である
- 他の厄介な問題と相互に関連している
この社会的複雑性が組織内の分断を生んで、技術的負債への対処をさらに困難にしてる。みんな正しいと思ってるんだけど、見てる世界が違うから話が噛み合わない。
理想論ではなく現実的な対処法
システム思考で根本から変える
技術負債への効果的な対処は、表面的な症状いじりじゃダメ。根本原因にアプローチするシステム思考が必要だ。
キーワードは「レバレッジポイント」。小さな変更で大きな効果をもたらすポイントを見つけて、そこに集中投資する。全部を一度に変えようとすると確実に失敗する。
ユリシーズ契約という現実的な手法
「ユリシーズ契約」って聞いたことある？将来の自分を特定の状況下で拘束するための事前のコミットメントのことだ。
具体例を出すと、スプリント中に生じた技術負債が一定の閾値を超えた場合、必ず次のスプリントに返済タスクを含めることを事前に約束しておく。人間って弱い生き物だから、その場の判断に任せてたら絶対に後回しにしちゃう。
シミュレーションで未来を見る
技術負債の影響って、静的な分析じゃ分からない。動的シミュレーションモデルを使うと、「納期延長が実はプロジェクト短縮につながる」みたいな反直感的な洞察が得られる。これ、ステークホルダーを説得するのにめちゃくちゃ効果的。
組織を変えるという修羅の道
セメルワイスの悲劇から学ぶこと
19世紀の医師セメルワイスの話は胸が痛い。手洗いの効果を科学的に証明したのに、同僚医師たちに激しく拒絶されて、最終的に精神病院で死んだ。
どんなに優れた解決策でも、組織が受け入れる準備ができてなければ意味がない。 技術的負債対策も同じ。技術的に完璧な解決策でも、組織の政治的現実と衝突すれば確実に潰される。
「理解してから理解される」。これがセメルワイスに足りなかった視点だ。
分断された世界をつなぐ
技術的負債問題は典型的な「厄介な問題」で、ステークホルダー間で根本的に異なる世界観が存在する。
ビジネス側は「なんで簡単な修正にそんなに時間がかかるの？」って思ってるし、技術側は「この人たち、システムの複雑さを全然理解してない」って思ってる。両方とも正しいんだけど、見てる世界が違う。
解決策は、全員が合意することじゃない。互いの立場を十分に理解して、建設的な対話ができる状態を作ること。これがスタートライン。
終わりなき旅
技術的負債管理って、一度で完了するプロジェクトじゃない。「解決する」んじゃなくて「管理し続ける」性質のもの。 継続的な改善サイクルを回して、組織の学習能力を高めていくしかない。
でも、この「常識」も、もうすぐ覆されるかもしれない。
AIが変えたゲームのルール
さて、ここからがこのブログの主なるテーマです。正直に言うと、技術負債というゲームそのものが終焉を迎えつつある。
「返済コスト」という概念の消滅
AIの登場で、技術負債の「返済コスト」が劇的に変わった...と言いたいところだけど、実際には「返済コスト」という概念自体が意味をなさなくなった。これは本当に革命的な変化だと思う。皆さんが実感するのは今日かもしれないし来年かもしれないけど、気づいた時にはもう遅い。
私は先週、2000行のスパゲッティコードをAIに投げてみた。人間なら理解するだけで2日、書き直すのに3日はかかる代物。結果は？30分で最新のベストプラクティスに従った実装が返ってきた。しかもテストコード付き。
もうね、従来の「技術負債返済計画」どころか、「技術負債管理」という考え方すら根本的に意味をなさなくなってる。 返済する必要がないものを、なぜ管理する必要があるのか？
過渡期的な分類の試み（でも、これもすぐ古くなる）
生成AIを極端に否定する人も、過度に賞賛する人も、結局のところ、その技術の長所と短所を客観的に評価する労力を避けているに過ぎない。複雑な現実を単純な二元論に還元することで、思考の負担を軽減しているのである。
ここでは、そうした極端な立場を避け、Software Engineering Instituteが2014年に発表した13種類の技術的負債分類を現在のAI能力と照らし合わせて冷静に評価してみたい。この分類も2025年6月に書いているが急速に変化しているAI能力を考えると、数年で古くなる可能性が高い。
1. AIが大部分を処理可能（ただし人間の監督は必要）
| 負債の種類 | AIの強み | 限界・課題 |
|---|---|---|
| Code Debt | コーディング規約違反、複雑性の問題の多くは処理可能 | プロジェクト固有の文脈理解には限界がある |
| Build Debt | ビルドプロセスの標準的な最適化は得意 | 複雑な依存関係やレガシー環境では課題が残る |
| Test Debt | 基本的なユニットテスト生成は可能 | ビジネスロジックの深い理解や統合テストの設計は発展途上 |
| Documentation Debt | コード説明の自動生成は実用的 | アーキテクチャの意図や設計判断の背景説明は人間が必要 |
2. AIが部分的に処理可能（急速に能力向上中）
| 負債の種類 | AIの強み | 限界・課題 |
|---|---|---|
| Design Debt | パターンベースの設計改善提案は有効 | ビジネス要件や制約条件の理解はまだ限定的 |
| Infrastructure Debt | 設定ファイルの標準化は得意分野 | レガシーシステムとの互換性や運用制約の判断は複雑 |
| Defect Debt | バグ検出能力は向上している | 修正の優先順位やビジネス影響の評価は人間の判断が重要 |
3. AIでは足りない領域（将来的に大幅改善の期待）
| 負債の種類 | AIの強み | 限界・課題 |
|---|---|---|
| Architecture Debt | パターン認識によるアーキテクチャ問題の特定能力は向上中 | 複雑なエンタープライズ環境での適用はまだ実験段階 |
| People Debt | スキルギャップの分析とトレーニング資料生成で支援可能 | 人間関係やモチベーション管理は人間の領域 |
| Process Debt | 開発プロセスの分析は可能 | 組織文化や政治的要因を考慮した改善提案はまだ困難 |
| Requirement Debt | 要件明確化のための質問生成は向上中 | ステークホルダー間の利害調整は人間が必要 |
| Service Debt | パターンベースの問題特定は期待できる | ビジネス戦略との整合性判断は発展途上 |
| Test Automation Debt | 基本的なテスト戦略提案は可能 | リスク評価や投資判断は人間の専門領域 |
4. 「人間の領域」という常識の急速な変化
上記の「AIでは足りない領域」において、これまで人間にしかできないとされてきた要因も、AI能力の向上で根本的に変化しつつある。
| 従来の課題 | AIによる新たなアプローチ |
|---|---|
| 組織の政治的複雑性 | AIは組織政治に巻き込まれず、データに基づく客観的で説得力のある提案が可能。ステークホルダー別に最適化された説明を同時生成できる |
| コミュニケーションの問題 | AIは相手の専門レベルや立場に合わせて瞬時に説明を調整可能。技術者向け、経営陣向け、営業向けの説明を同時に生成できる |
| 知識の属人化 | AIは組織内の膨大な知識を統合し、退職者の暗黙知すらも文書やコードから推論して継承可能になりつつある |
予想以上に早い変化への期待
現在の「段階的な自動化」という慎重な見積もりも、AIの指数関数的な進化を考えると控えめすぎる可能性が高い。特に以下の点で想定を上回る変化が期待される：
- コンテキスト理解の飛躍的向上 - 数百万トークンのコンテキストを扱えるAIが、プロジェクト全体の文脈を人間以上に把握
- マルチモーダル統合の実用化 - コード、設計図、会議録、メールを統合的に理解し、プロジェクトの「空気」まで読み取る
- 継続学習による組織適応 - 各組織の文化や制約を学習し、その組織に最適化された提案を生成
技術負債処理において、我々は歴史的な転換点にいる。 コストが劇的に下がるだけでなく、品質と速度も人間を上回る可能性が現実的になってきた。完全自動化は時間の問題かもしれないが、それまでの過渡期においても、AIと人間の協働は想像以上の成果をもたらすだろう。
最も重要なのは、この変化を恐れるのではなく、積極的に活用して、より創造的で価値のある仕事に人間のエネルギーを振り向けることだ。
踏み倒せる負債という新概念
これが一番衝撃的かもしれない。AIの進化で、技術負債を「踏み倒す」という選択肢が現実的になった。従来なら絶対に「返済」しなきゃいけなかった負債が、AIの能力向上で実質的に「なかったこと」にできる。
ただし、これは楽観論じゃない。Addy Osmaniの「70%問題」が示すように、最後の30%—複雑な問題解決、ビジネスロジックの理解、エッジケースへの対応—は依然として人間の領域だ。
でも、技術的負債の解消に関しては、この30%も残るか疑問である。
正直に言うと、この技術的負債の30%って「高度で知的な問題」というより「クソめんどくさい仕事」なんだよね。高度で知的な問題なんて実際はそれほど多くない。
技術的負債って、よく考えてみると「簡単で単純な仕事の詰め合わせ」なんだよ。 一つ一つは別に難しくない。変数名の統一、古いライブラリの置き換え、重複コードの削除、テストの追加...。個別に見れば、どれも比較的に誰にでもできる作業。
問題は「量」だった。 膨大な量の単純作業に人間が疲弊して、嫌になって、結果的に誰もやりたがらなくなった。まさにAIが最も得意とする領域じゃないか。
正直、この30%って人間の尊厳のために言っているに過ぎないんじゃないか。 「人間にしかできない領域がある」って言わないと、エンジニアの存在意義が揺らいじゃうから。でも冷静に考えれば、レガシーシステムとの互換性を保ちながらの移行作業、謎の仕様書を読み解く作業、ステークホルダー間の調整、政治的な理由で放置されてきた設計債務の整理...。これらも、実は複雑に見えて、分解すれば単純なタスクの組み合わせなのかもしれない。
AIのコンテキスト容量が急速に拡大してモデルが進化していることを考えると、この「文脈依存の壁」もいずれ突破される可能性が高い。これまで「人間にしかできない」とされてきた複雑な文脈理解も、十分なコンテキストを与えられたAIなら処理できるようになるかもしれない。そうなると、人間の尊厳を保つための30%という数字すら、どんどん小さくなっていく。 技術的負債の返済において、本当に人間が必要な領域は10%、5%、そして最終的には限りなくゼロに近づくのかもしれない。
技術的負債の一番しんどかったのは、それを誰もやる気が起きなかった点である。 まじで「ブルシット・ジョブ」なんだよ。
デヴィッド・グレーバーが言う「ブルシット・ジョブ」—本人がその存在を正当化できないほど無意味で不必要な仕事—の典型例が技術的負債の処理だった。古いシステムのバグ修正、無意味に複雑化したコードの整理、政治的な理由で残された設計ミスの隠蔽...。誰がやっても評価されないし、やらなくても（短期的には）問題にならない。
チームミーティングで「この技術負債、誰がやる？」って聞いても、みんな下を向いて沈黙。結局は新人に押し付けるか、炎上してから慌てて対処するかの二択だった。「なんで俺がこんなクソコードの尻拭いを...」って思いながら、みんな嫌々やってた。
でも、AIは文句を言わない。コレがすごい。
「このレガシーコードを現代的に書き直して」って投げても、「はい」って淡々と処理してくれる。愚痴らないし、やる気を失わないし、転職を考えることもない。 技術的負債というブルシット・ジョブの最大の問題—「誰もやりたがらない」—をAIが一気に解決してしまった。
技術的負債って、結局のところ「誰かがやらなきゃいけないけど、みんなが避けて通りたい作業」の集積だったのかもしれない。 AIが文句ひとつ言わずに引き受けてくれたら終わるのかもしれない。
エンジニアの生存戦略：「判断力が全て」という幻想
判断力が全てになった...本当に？
Chip Huyenが言ってる「AIは新しい種類の思考を導入するのではない。実際に思考を必要とするものを明らかにする」。
でも、これって本当だろうか？ コードを書くスキルから、システムを設計するスキルへ。部分最適の思考から、全体最適の思考へ。実装の詳細にこだわるより、ビジネス価値を理解する力へ。こうした「判断力重視」の話も、技術的負債の30%理論と同じく、人間の尊厳を保つための建前なのかもしれない。
もうジュニアもシニアも関係ない。AIが実装を担当する今、人間の価値は「何を作るべきか」「なぜそれが必要か」を判断する能力にかかってる。でも、その判断すらもAIが上手くやる日が来るんじゃないか？
判断力の育成という矛盾した現実
ここが皮肉なところなんだけど、「指示通りに動く」ことにおいて、AIは人間をもう完全に上回る。作業者として生きてきた人には厳しい時代だ。でも、「判断者」として生きていく人にとっても、実は同じくらい厳しいかもしれない。
判断力って一朝一夕には身につかない。 失敗の経験こそが、AIには真似できない「判断力」を形成するんだけど、簡単な判断をAIが肩代わりすることで、人間が判断力を育てる機会が減ってる。これって完全に矛盾してる。
正直に言うと、私にはソフトウェアエンジニアがこれからどうなるかは分からない。 技術的負債の処理がAIに置き換わったように思えたように、システム設計や意思決定も同じ道を辿るかもしれない。「人間にしかできない」とされている領域も、結局は時間の問題なのかもしれません。
歴史の転換点で思うこと
変わった本質、変わらない幻想
ブルックスが『人月の神話』で示した洞察—ソフトウェア開発の本質的な複雑性—は今も変わらない...と言いたいところだけど、本当にそうだろうか？
技術的負債という「複雑性」が実は「簡単で単純な仕事の詰め合わせ」だったように、他の「本質的複雑性」も、分解してみれば案外単純なタスクの組み合わせなのかもしれない。 AIという強力な武器を手に入れた今、「人間にしか扱えない複雑性」という概念自体が崩れつつある。
新しいトレードオフの幻想
技術負債は消えない...と思ってたけど、実際には消えるかもしれない。 「人月の神話」時代のリソース配分問題から、「生成AIのジレンジア」時代の投資判断問題へ。でも、その投資判断すらもAIが最適化する日が来るのかも。
新しい課題として挙げられているもの：
- AIへの過度な依存による思考停止
- 実装能力の空洞化による基礎力低下
- ベンダーロックインのリスク増大
でも、これらの課題も本当に「課題」なのだろうか？ 思考停止と言うけれど、AIの方が適切な判断をするなら、人間が思考する必要はあるのか？実装能力の空洞化と言うけれど、そもそも実装する必要がなくなるなら問題ないのでは？
歴史的転換点にいる僕らには、確かに新しいルールを作る機会がある。でも、そのルールが「人間が主役」である必要はないかもしれない。 エンジニアとしての小さなプライドを捨てて、AIと共生する道を探るのが現実的な選択肢なのかも。
おわりに
技術負債は確実に変質した。いや、もっと正確に言うなら、既存の技術負債は消滅に向かっている。これらの話は夢物語かもしれないしどういう着地をするか分からないが「返済」から「管理」へ、そして今度は「自動解決」へ。私たちが長年戦ってきたドラゴンは、AIという新しいプレイヤーによって、あっさりと倒されようとしている。
これは技術的負債の終焉なのかもしれない。 少なくとも、私たちが知っている形での技術的負債は。
私たちは本当に特別な時代を生きてる。これまでは先人が敷いた道を歩いてきたけど、今は歴史の教科書に載るような大変革の真っ只中にいる。後世の人が「あの時代のエンジニアは、自分たちの仕事がAIに取って代わられることをどう感じていたんだろう」って研究する、まさにその時代の当事者だ。
AIは「コードを書く」という行為だけでなく、「技術的負債を処理する」という作業も奪うかもしれない。 でも同時に、それは私たちを膨大な量の「クソめんどくさい仕事」から解放してくれる。もう誰も嫌々レガシーコードと格闘する必要がなくなる。
正直に言おう。技術的負債の大部分は、人間の尊厳を保つために「30%は人間の領域」と言っているだけかもしれない。 でもそれでいいじゃないか。エンジニアとしてのアイデンティティを保ちながら、本当に価値のある仕事—「何を作るべきか」「なぜそれが必要か」—に集中できるようになる。
技術負債のない世界は、確かにつまらないかもしれない。 でも、その代わりに私たちは新しい種類の問題と向き合うことになる。メタファーとしての臨界点かもしれない。AIとどう協働するか。システムをどう設計するか。ビジネス価値をどう最大化するか。これらは技術的負債とは比べ物にならないほど、創造的で意味のある挑戦だ。
技術負債というドラゴンは、もうすぐいなくなるかもしれない。でも、私たちエンジニアの物語は終わらない。 むしろ、やっと本当に面白いチャプターが始まるのかもしれない。
さあ、明日からは、技術的負債ではなく、もっと本質的な問題と踊ろう。 AIというパートナーと一緒に、これまで想像もできなかった新しい世界を作っていくために。
