# 技術的負債 Navigation: [[index]] | [[concepts/_index]] ## 定義 技術的負債(technical debt)とは、Ward Cunninghamが1992年に導入した、速度と品質のトレードオフの帰結を定量化するための枠組みである。金融的負債と同様、戦略的な理由で負債を取ること自体は必ずしも悪ではないが、負債は複利的に増大する傾向を持ち、返済を先延ばしにするとコスト増大・システムの脆弱化・イノベーション速度の低下を招く。伝統的な返済手法にはリファクタリング・単体テストカバレッジの向上・デッドコード削除・依存関係の削減・APIの引き締め・文書化の改善が含まれ、これらは新機能追加を目的とせず、将来の改善を容易にしバグの可能性を減らすことを目的とする。(Source: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]) 機械学習システムは通常のソフトウェアが持つコード複雑性の問題をすべて備えつつ、それに加えてシステムレベルの複雑性という隠れた負債を生み出す。機械学習パッケージは望ましい振る舞いを外部データへの依存なしにソフトウェアロジックとして実装できない点にその存在意義があり、抽象的な振る舞いの不変条件をデータの癖から切り離す方法がほとんど存在しないため、伝統的なソフトウェア工学が前提とする厳密な抽象境界を強制することが難しい。この境界侵食が機械学習特有の技術的負債の源泉になる。(Source: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]) 機械学習特有のリスク要因として、entanglement(**CACE原則**: Changing Anything Changes Everything、何かを変えればすべてが変わる)・隠れたフィードバックループ・未宣言の消費者・不安定/未活用のデータ依存性・訂正カスケード・glue code・pipeline jungles・dead experimental codepaths・configuration debtが挙げられる。(Source: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]) ## 横断的知見 - **技術的負債(コード・システムレベル)とソシオテクニカル負債(組織・人の行動レベル)は解消の難度が異なる階層構造をなす**: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]が扱う技術的負債は、リファクタリング・静的解析ツール・テストといった技術的介入で(困難ではあるが)解消しうる対象として描かれる。一方[[ソシオテクニカル負債]]は、[[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]]によれば「ツールやコードの変更で解消できる技術的負債」とは異なり「人の行動変容」を要するためより解消が難しいと明示的に対比される。両ソースを並べると、技術的負債の枠組みが「システムに何を実装するか」の問題であるのに対し、ソシオテクニカル負債の枠組みは「その実装をチームがどう扱うか」の問題であり、前者の解消(例: データ依存性の自動アノテーションツール導入)が後者を自動的には解消しない、という補完関係が見える。(Source: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]], [[@2026__OReilly__Observability Engineering 2E - Chapter 23 Organizational Learning Speed Is Now Your Biggest Constraint - An Open Letter to CTOs]]) - **負債の「返済」を論じる視点と、負債を「発生させない」ことを論じる視点は補完関係にある**: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]]は負債が既に生じた状態を前提に、リファクタリング・テストカバレッジ向上・依存関係の削減といった返済手法を体系化する。一方 [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 3 Working Code Isn't Enough]]は返済手法そのものではなく、負債を生む「戦術的プログラミング」という心構えの選択を問題視し、開発時間の 10〜20% を継続的な投資に充てることで負債を最初から蓄積させない予防的な姿勢([[戦略的プログラミング]])を主眼に置く。両ソースを並べると、技術的負債の議論が主に「負債が発生した後どう返済するか」という事後対応の枠組みであるのに対し、戦略的プログラミングの議論は「負債が発生する前にどう投資判断を下すか」という事前予防の枠組みであり、負債マネジメントの異なる局面を扱っていることが分かる。(Source: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]], [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 3 Working Code Isn't Enough]]) - **「不要なドキュメンテーションは技術的負債である」という主張は、Ousterhoutの戦術的/戦略的プログラミングの区別を予防的観点からドキュメント領域へ橋渡しする**: 既出の知見はSculleyら(2014)の「事後の返済」とOusterhout(2018)の「事前の予防投資」という2つの局面を対比してきたが、『SREの探求』19章は第三の対象として「ドキュメンテーション」そのものを負債の発生源に加える。19章は「不必要か役に立たないドキュメンテーションは一種の技術的負債であって、複雑さや不確実性を追加し、役に立つ情報を目立たなくするか、場合によっては否定することも少なくない」と明言し、役目を終えたドキュメントを躊躇せず削除・アーカイブすべきだと処方する。この処方は、Ousterhoutが戦術的プログラミングが生む負債を継続的な投資(開発時間の10〜20%)で予防すべきと論じたのと同じ「事前予防」の系譜に属するが、対象がコードではなくドキュメントである点で、技術的負債の枠組みがコード以外の成果物にも適用できる射程を持つことを示す。ただし19章はSculleyのentanglement等のようなドキュメント特有のリスク分類を提示しておらず、ドキュメント負債の構造的な下位分類(19章の枠組みで言えば構造品質/機能品質のどちらが負債化しやすいか)は本ソース単独では示されていない。(Source: [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 3 Working Code Isn't Enough]], [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] §19.3.4) ## 未解決の問い - Sculleyほか(2014)が提示したentanglement・隠れたフィードバックループ等のリスク要因は、その後(2015年以降)の機械学習システム研究や実務でどこまで定量的に検証・反証されたか。 - 機械学習特有の技術的負債(データ依存性・entanglement)の返済コストは、伝統的なソフトウェア工学の技術的負債の返済コストと比べて定量的にどの程度高いか。 - 技術的負債とソシオテクニカル負債の解消順序を決めるフレームワークは存在するか。両者が同時に存在する組織では、どちらを先に解消すべきかの判断基準が必要になる。 - Ousterhout が提案する「開発時間の 10〜20% を投資に充てる」という予防的な割合は、Sculley ほかが扱う機械学習システム特有の負債(entanglement・隠れたフィードバックループ等)の発生を防ぐのにも同程度で十分か、それとも機械学習固有の追加投資が必要か。 ## 関連 - 概念: [[ソシオテクニカル負債]] / [[戦略的プログラミング]] / [[ドキュメンテーションのワークフロー統合]] - ソース: [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]] / [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 3 Working Code Isn't Enough]] / [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] - 関連 MOC: [[structures/Software Engineering - MOC]] ## 出典 - [[@2014__SE4ML2014__Machine Learning - The High-Interest Credit Card of Technical Debt]] — Sculleyほか(Google, Inc.)、SE4ML: Software Engineering for Machine Learning(NIPS 2014 Workshop)。技術的負債の枠組みを機械学習システムに適用し、CACE原則・隠れたフィードバックループ等のリスク要因を体系化 - [[@2018__YaknyamPress__A Philosophy of Software Design - Chapter 3 Working Code Isn't Enough]] — John Ousterhout(Stanford University)、*A Philosophy of Software Design*(Yaknyam Press, 2018)第 3 章。戦術的プログラミングと戦略的プログラミングを対比し、負債の返済ではなく発生させない継続的投資を主眼に置く - [[@2021__OReillyJapan__SREの探求 - Chapter 19 ドキュメント作成業務の改善：エンジニアリングワークフローへのドキュメンテーションの統合]] — §19.3.4: 不要・陳腐化したドキュメンテーションを技術的負債として明示的に位置づけ、容赦ない刈り込みを処方