会計

技術的負債とは、知識資本の減損である

みなさん、おはようございます！こんにちは！こんばんは。Jindyです。 　

技術的負債という言葉を聞くと、多くの人は古いコード、読みにくいコード、継ぎはぎだらけのシステムを思い浮かべる。

もちろん、それは間違っていない。
ただ、それだけで止まると、少しもったいない。

本当に怖いのは、コードが汚いことではない。
なぜそのコードになったのか、誰も説明できなくなることだ。

このブログでは、技術的負債を単なる開発現場の話ではなく、組織の知識資本の問題として読み直す。コードの奥にある判断、制約、暗黙知、意思決定の履歴。そこが腐ると、システムは動いていても、会社の中身は少しずつ硬直していく。

リファクタリングは掃除ではない。
ドキュメント作成は議事録作りではない。
設計レビューは儀式ではない。

それらは、将来の変更能力を守る投資であり、過去に積み上げた知識の棚卸しでもある。

会計でいえば、技術的負債は帳簿に載りにくい簿外債務に近い。今月のPLには出ない。だから経営会議では見落とされる。でも、ある日突然、改修不能、障害対応の長期化、属人化した担当者の退職、AI導入の失敗という形で噴き出す。

なぜシステムは古くなるのか。
なぜ人が抜けると現場が止まるのか。
なぜAIでコード生成が速くなっても、むしろ負債が増える可能性があるのか。

技術的負債とは、コードの問題である前に、知の扱い方の問題だ。

ここ、かなり怖い話です。

技術的負債はコードではなく、判断の残骸に宿る

技術的負債という言葉は便利だ。
便利すぎるせいで、雑に使われる。

この画面は古いから技術的負債。
このコードは読みにくいから技術的負債。
このシステムはレガシーだから技術的負債。

そう言いたくなる気持ちはわかる。命名がぐちゃぐちゃ。似た処理が何本もある。テストがない。改修のたびに誰かが祈る。

ただ、それは症状だ。
病巣はもう少し深いところにある。

コードは結果であって、原因ではない

Ward Cunninghamが技術的負債の比喩を出したとき、中心にあったのは短期的なスピードと長期的なコストの交換だった。早く出すために、完全ではない設計や理解のまま進める。その判断自体は悪ではない。ビジネスには締切がある。市場も待ってくれない。

問題は、その借金を借金として扱わないことだ。

会計なら、借入金は負債に載る。利息も発生する。返済期限もある。
ところが技術的負債は、かなりの部分が帳簿に載らない。

今月の売上は立つ。
納期も守れる。
見た目には成功する。

でも裏側では、将来の改修コストが静かに膨らむ。新機能を一つ足すだけで、影響調査に何日もかかる。小さな仕様変更なのに、なぜか三部署が集まる。担当者が一人休むだけで、リリース判断が止まる。

これはコードというより、知識の配置の問題である。

消えるのはコードではなく、なぜそうしたか

システム開発で本当に失われやすいのは、成果物ではない。
意思決定の理由だ。

なぜこのテーブル設計にしたのか。
なぜこのAPIは例外的な動きをするのか。
なぜこのバッチだけ深夜に動くのか。
なぜここだけ手作業が残っているのか。

こうした理由は、最初は誰かの頭の中にある。会議で話した記憶もある。チャットに断片も残っているかもしれない。でも時間が経つと薄くなる。人が異動し、資料の置き場も変わる。

そしてある日、現場はこう言う。

触らない方がいいです。
昔からそうなっています。
詳しい人がもういません。

この瞬間、技術的負債は成熟する。
説明不能な資産になる。

投資でいうなら、事業内容を説明できない会社の株を持ち続けるようなものだ。利益は出ている。でも、何がリスクなのか分からない。

ソフトウェアでも同じことが起きる。
理解できないものは、変更できない。

負債は利息を生む。しかも複利で増える

技術的負債の嫌なところは、放置しても静かに増える点だ。

一つの例外処理を残す。
その例外に合わせて次の処理を書く。
さらにその次の処理も、例外を前提にする。
気づけば、最初の小さな妥協が、システム全体の設計制約になる。

これが利息だ。
しかも単利ではない。かなり複利に近い。

会計でいえば、減損の兆候を見て見ぬふりしている状態に似ている。帳簿価額は残っている。でも、将来キャッシュフローを生む力は落ちている。

早めに返せば、数日の整理で済む。
遅れると、数カ月の刷新になる。
もっと遅れると、刷新すらできず、周辺に新しいシステムを建て増しする。

その結果、古い本丸は残る。
新しい別館もできる。
連携用の通路が増える。
誰も全体図を描けない城になる。

技術的負債は、コード、設計、運用、組織、人の記憶。その間にある。

だから返済も、コードを直すだけでは足りない。
判断の理由を掘り起こし、構造を見直し、誰が何を知っているのかを並べ直す必要がある。

これは掃除ではない。
知識の監査だ。

知とは何か。ドキュメントに書けないものが、現場を動かしている

技術的負債を知の問題として見るなら、避けて通れない問いがある。

そもそも知とは何か。

これを曖昧にしたまま、ナレッジ共有しましょう、と言ってもだいたい失敗する。知識は資料の量では測れないからだ。

フォルダにPDFが百本あっても、誰も使えなければ知識ではない。
紙一枚の図でも、全員の理解がそろうなら強い知識になる。

知識は、行動を変える。
判断を速くする。
未来の失敗を減らす。

データ、情報、知識は同じではない

データは素材だ。
ログ、数値、コード、仕様項目、エラー件数。そこに意味はまだ薄い。

情報は、データに文脈が乗ったものだ。

このエラーは月末処理のときだけ増える。
この画面は特定部署しか使わない。
この処理は昔のキャンペーン対応の名残である。

知識は、そこから判断できる状態だ。

この改修は危ない。
ここは先にテストを書くべきだ。
この機能は捨てても業務影響が小さい。
この設計は短期では早いが、半年後に詰まる。

つまり知識とは、意思決定に使える理解である。

経理でも同じだ。売上データがあるだけでは管理会計にならない。部門別、商品別、顧客別に切り、どこに打ち手があるか見える状態にして、ようやく経営に使える数字になる。

技術的負債の管理も同じである。
コードの一覧では足りない。
変更判断に使える形に加工しなければ、知識にならない。

プログラミングは、コードを書くことではなく理論を作ること

Peter Naurは、プログラミングの本質を理論構築だと捉えた。
これはかなり深い。

開発者は、ただ命令文を書いているのではない。
業務を理解し、制約を読み、利用者の動きを想像し、将来の変更を見込みながら、頭の中にシステムの理論を作る。その理論の一部がコードになり、一部がテストになり、一部が設計資料になる。

だから、同じコードを見ても、理解できる人とできない人がいる。

詳しい人は、コードの背後にある理由まで読んでいる。

ここはあえて冗長にしている。
ここは業務例外を吸収している。
ここは将来消す前提で残している。

一方、理論を持っていない人には、ただの変なコードに見える。
そして、善意で直して壊す。

ここ、開発現場のあるあるです。

技術的負債の解消で怖いのは、見た目だけ綺麗にすることだ。処理を短くする。重複を消す。命名を直す。それ自体は悪くない。でも、背景の理論を理解せずに触ると、昔の制約ごと消してしまう。

会計でいえば、注記を読まずに財務諸表の数字だけ見るようなものだ。数字は合っていても、企業の実態は読めない。

コードも同じだ。
本文だけでなく、注記がいる。

暗黙知は悪ではない。ただし放置すると爆弾になる

知識には、言葉にできるものと、言葉にしにくいものがある。

Polanyiの暗黙知の議論で有名なのは、人は語れる以上のことを知っている、という考え方だ。現場にもそれは山ほどある。

レビューで感じる違和感。
障害対応で身についた勘。
この人に確認した方が早いという判断。
この仕様変更は揉めるぞ、という肌感覚。

こういうものは、全部をドキュメントにできない。

だから暗黙知をゼロにする発想は危ない。現場から熟練の価値まで消える。

必要なのは、暗黙知を敵にすることではない。どこにあるのかを知り、必要な部分だけ形式知に移すことだ。

Nonakaの知識創造理論では、暗黙知と形式知は相互に変換される。経験を共有し、言葉にし、組み合わせ、また実践に戻す。この循環が組織の知識を育てる。

開発現場なら、ペア作業、レビュー、ADR、障害ふりかえり、オンボーディング、テストケース化がそれにあたる。

ドキュメントだけでは知識は移らない。会話だけでも残らない。

両方いる。面倒だけど、そこをサボるとあとで高くつく。

知識は、保存するものではなく、使い続けるものだ。

古い資料を残すだけでは足りない。
ベテランの頭の中に閉じ込めても危ない。
AIに要約させるだけでもまだ浅い。

知識は、判断に使われ、実務で試され、間違っていれば更新される。その循環が止まったとき、技術的負債は静かに増え始める。

技術的負債の返済とは、知識資本を再投資することである

ここまでくると、技術的負債の返済は単なる改善活動ではなくなる。

それは、知識資本の再構築だ。

でも、システムを理解し続ける力への投資は、なぜか後回しになりがちだ。短期の売上に直結しにくいからだ。今月の数字に出にくいからだ。ここが罠です。

技術的負債の返済は、短期PLでは費用に見えやすい。でも中身は、将来の変更能力を買い戻す投資でもある。

最初にやるべきは返済ではなく、棚卸し

借金の総額が分からないのに返済計画は作れない。
技術的負債も同じだ。

いきなり全部直そうとすると失敗する。現場は忙しい。だから最初に必要なのは、きれいな理想論ではなく棚卸しである。

どの機能が売上に直結しているのか。
どの処理が障害時に事業を止めるのか。
どのコードが特定の人しか触れないのか。
どの資料が古く、どの判断が失われているのか。
どの負債は今すぐ返すべきで、どれは保有してもよいのか。

ここで大事なのは、負債を全部悪者にしないことだ。

ビジネスには意図的な借入がある。同じように、短期で市場に出すために技術的負債を抱える判断もある。

問題は、借りた自覚がないこと。
返済期限がないこと。
利息を測っていないこと。

管理された負債は戦略になる。放置された負債は事故になる。

知の交通整理には、置き場所と通路がいる

知識を整理するとき、多くの組織は保管場所を作る。

それ自体は必要だ。でも置き場所だけでは足りない。

必要なのは通路である。

新しく入った人が、どこから読めばよいか。
障害時に、何を見ればよいか。
設計変更時に、過去の意思決定へどうたどり着くか。

これが交通整理だ。

実務で使うなら、すべてを長文資料にする必要はない。

ADRで、なぜその設計にしたかを残す。
テストで、壊してはいけない業務ルールを固定する。
READMEで、最初に見る地図を作る。
障害報告で、再発防止策だけでなく判断の遅れも残す。
レビューで、ベテランの違和感を言葉にする。

美しい百科事典を作る必要はない。
迷子にならない地図を作ればいい。

会計でいえば、総勘定元帳だけ見せられても困る。試算表、補助元帳、注記がつながって、初めて読める。技術知識も同じだ。

知識は、置くよりつなぐ。
ここが肝だ。

AI時代は、コード負債より認知負債が増える

AIによって、コードを書く速度は上がる。
これはほぼ間違いない流れだ。

ただし、速度が上がるほど別の問題が出る。
人間が理解していないコードが増えることだ。

AIが書いたコードは、一見それっぽい。
動くことも多い。
でも、なぜその設計なのか、どの前提で書いたのか、将来どこが壊れやすいのかを人間が説明できないなら、それは新しい負債になる。

最近の議論では、技術的負債だけでなく、認知的負債や意図の負債という考え方も出ている。コードはある。説明もある。けれど、チームの理解が追いついていない。そこが危ない。

これは投資でいうと、レバレッジをかけて成長しているようなものだ。
上昇局面では気持ちいい。でも反転した瞬間に効いてくる。

AIは悪者ではない。むしろ強力な道具だ。

ただし、AIで作ったものを人間が理解し、検証し、組織の知識に組み込むプロセスがなければ、コード生成は知識生成にならない。

ここを勘違いすると危ない。
生成されたコードは資産に見える。
でも理解されていないコードは、資産の顔をした負債である。

技術的負債の返済とは、古いものを新しくする作業ではない。
組織がシステムを理解し直す作業だ。

何を知っているのか。
何を知らないのか。
何を誤解しているのか。
何を古い前提のまま使っているのか。

それを棚卸しし、整理し、更新し、次の人が使える形にする。

つまり、技術的負債の返済は知識資本への再投資である。

結論

技術的負債という言葉は、少し冷たい。どこか技術者だけの問題に見える。

でも、本当はもっと人間くさい。

誰かが急いで作った。誰かが悩んで決めた。誰かが説明しないまま異動した。誰かが分かっていたけれど、忙しさの中で残せなかった。

その積み重ねが、システムの奥に沈んでいく。

だから技術的負債を責めるだけでは何も変わらない。
あのとき急いだ理由があった。市場に出す必要があった。人が足りなかった。経営判断もあった。

負債には、たいてい物語がある。

ただし、物語があるからといって、放置していいわけではない。
借りたものは、いつか返す必要がある。
返さなければ、未来の誰かが払う。

未来の開発者が払う。未来の利用者が払う。未来の経営が払う。そして未来の自分たちが、変更できない会社という形で払う。

技術的負債の返済とは、過去を責めることではない。
過去の判断を理解し、今の言葉で並べ直し、未来に渡せる形に整えることだ。

コードを直す。
テストを書く。
設計理由を残す。
古い資料を捨てる。
暗黙知を言葉にする。
分からないものを、分からないままにしない。

一つひとつは地味だ。派手な新機能ほど拍手もされない。でも、こういう仕事が組織の足腰を作る。

会計でいえば、決算整理みたいなものだ。
華やかではない。
でも、やらなければ数字は信じられない。
技術も同じだ。知識の決算整理をしない組織は、自分たちが何を持っているのか分からなくなる。

そして、自分たちが何を持っているのか分からない組織は、未来を選べない。

技術的負債の正体は、古いコードではない。
失われた理解だ。

だから返済とは、理解を取り戻すこと。
知を明確にし、交通整理し、また次の人が走れる道を作ること。

システムを守るとは、コードを守ることではない。
人が積み上げた知を、未来に渡すことだ。

その地味な営みの先にだけ、変わり続けられる組織がある。

あわせて読みたい本

技術的負債を「コードの汚れ」ではなく、「知識の整理・更新・継承」の問題として考えるなら、あわせて読んでおきたい本があります。
開発者だけでなく、プロダクトに関わる人、組織づくりに関わる人、DXやAI活用を考える人にも刺さる本を選びました。

1. アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する

技術的負債を、単なるリファクタリングではなく、技術・組織・戦略をつなげて解消していくための一冊です。
ブラックボックス化したシステム、機能しないドキュメント、改修のたびに増えるリスク。この記事で書いた「知の交通整理」というテーマに、かなり近い本です。

特に面白いのは、アーキテクチャを技術パターンだけで見ないところ。
組織構造、ビジネス目標、システムの進化をまとめて捉えるので、エンジニアだけでなく、事業側・経営側の人にも読み応えがあります。
技術的負債を「将来の成長を止める構造」として見たい人には、かなり相性がいいです。


2. 実践で学ぶコード改善の極意 5行ルールで強く美しくリファクタリングする

リファクタリングを感覚論で終わらせたくない人におすすめです。
「なんとなく汚いコード」ではなく、どこをどう直すべきかを具体的なルールで見ていく本です。

この記事では、技術的負債の本質は知識の劣化だと書きました。
ただ、最終的にはコードにも手を入れないといけない。
そのときに必要なのは、気合いではなく、安全に改善するための型です。

コードを完全に理解していなくても安全に改善する方法、価値あるコメントの見極め方、リファクタリングのタイミングなども扱われています。
「負債は分かった。で、実際どこから直すの？」と思った人に刺さります。


3. ソフトウェアアーキテクチャメトリクス アーキテクチャ品質を改善する10のアドバイス

技術的負債を感覚ではなく、数字や指標で扱いたい人に向いています。
この記事で会計の話を入れた理由ともつながりますが、負債は見える形にしないと管理できません。

この本は、アーキテクチャ品質をどう測るか、どんなメトリクスを追うべきか、改善の優先順位をどう決めるかを扱っています。
可観測性、テスト容易性、デプロイ可能性、ダッシュボードなど、現場で使える視点が多いです。

技術的負債を「なんとなくヤバい」で終わらせず、経営やチームに説明できる形にしたい人にはかなり実用的です。


4. ソフトウェア設計のトレードオフと誤り

技術的負債は、悪い設計だけから生まれるわけではありません。
むしろ多くの場合、その時点では合理的だった選択が、あとから制約になる。

この本は、まさにその「選択の副作用」を扱っています。
コードの重複、例外処理、柔軟性と複雑性、API設計、ライブラリ選定、分散システム、バージョン管理など、現場でありがちな判断の裏側にあるトレードオフを掘ってくれます。

この記事で書いた「なぜそう決めたのかを残す」という話を、より技術寄りに深めたい人におすすめです。
正解を覚える本ではなく、判断力を鍛える本です。


5. エンジニアリング組織論への招待 不確実性に向き合う思考と組織のリファクタリング

技術的負債を、組織の問題として読みたいならこの本です。
コードや設計だけでなく、コミュニケーションのズレ、経営と現場の認識差、プロジェクトの理不尽、生産性の低下を「不確実性の扱い方」として整理しています。

この記事で書いた「知の明確化と交通整理」は、まさに組織の不確実性を減らす作業でもあります。
技術的負債を返済するには、コードだけでなく、人の認識、責任範囲、意思決定の流れも整えないといけない。

エンジニアリング組織を作る人だけでなく、開発チームと一緒に仕事をする事業側・管理側の人にも読んでほしい一冊です。
技術と経営の間にあるモヤモヤに名前をつけてくれます。


それでは、またっ！！

引用論文等

  1. Ward Cunningham, The WyCash Portfolio Management System, OOPSLA 1992. 技術的負債の原点となる比喩を提示した資料。
  2. Zengyang Li, Paris Avgeriou, Peng Liang, A Systematic Mapping Study on Technical Debt and Its Management, Journal of Systems and Software, 2015. 技術的負債を10種類に分類し、管理活動を整理した研究。
  3. Peter Naur, Programming as Theory Building, Microprocessing and Microprogramming, 1985. プログラミングをコード生成ではなく理論構築として捉えた古典的論文。
  4. M. M. Lehman, Laws of Software Evolution Revisited, 1996. ソフトウェアは環境変化に合わせて進化し続ける必要があるという法則を整理した研究。
  5. Michael Polanyi, The Tacit Dimension, 1966. 暗黙知の基礎となる著作。人は言語化できる以上のことを知っている、という知識観の源流。
  6. Ikujiro Nonaka, A Dynamic Theory of Organizational Knowledge Creation, Organization Science, 1994. 暗黙知と形式知の相互変換による組織的知識創造を論じた代表的論文。
  7. Ioana Rus, Mikael Lindvall, Knowledge Management in Software Engineering, IEEE Software, 2002. ソフトウェア開発における知識管理の必要性を整理した論文。
  8. Margaret-Anne Storey, From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI, arXiv, 2026. AI時代における技術的負債、認知的負債、意図の負債を整理したプレプリント。

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

RECOMMENDこちらの記事も人気です。