Managing Technical Debt: Reducing Friction in Software Development IV-10
https://learning.oreilly.com/library/view/managing-technical-debt/9780135646052/
Part IV: Managing Technical Debt Tactically and Strategically
Chapter 10. What Causes Technical Debt?
原則：すべてのシステムには技術的負債がある。
原則：技術的負債はシステムをトレースしなければならない。
技術的負債の原因をよく理解しておくことは、後に、技術的負債がシステムに与える影響を調査し、 システムのどの部分を変更する必要があるかを特定するのに役立つ。
技術的負債の原因を大きく4つに分類している
・ビジネスの性質
・コンテキストの変化
・開発プロセス
・人とチーム
開発チームが技術的負債に陥るのは、リソースのプレッシャーが原因であることが多い。
詳細な要件を明確にしないこと、期待される機能を実装しないこと、システムを横断するセキュリティ、パフォーマンス、可用性といったアーキテクチャ上重要な要件を理解しないことは、すべて技術的負債を引き起こす。
テクノロジーは、予想された速度で変化するものもあれば、破壊的な方法で変化し、ビジネスの変化を引き起こすものもある。
特定のソフトウェア、ハードウェア、ミドルウェアに固定されたテクノロジーは、最終的に設計の選択肢を狭め、予期せぬ手戻りという形で技術的負債を蓄積することになる。
システムは古くなる。
この自然な進化の一部として、システムは維持され、新しい機能が導入されるにつれて変化する。
このような変化は、最終的にはシステムを機能不全に陥れる。
システム文書があるからといって、そのシステムに技術的負債がないとは限らない。
ドキュメンテーションは、アクセス可能で、適切で、最新のものでなければならない。
効果的でない、あるいは不十分なドキュメンテーションは、システムが技術的負債を抱えるリスクを生む。
システム開発において重要でありながら見落とされがちな影響のひとつが、システムを開発する人々である。
人が意思決定をし、人がシステムを実装し、人がシステムを使う。非効率なチームや開発者がシステムに広く影響を及ぼし、それが後になって技術的負債として認識される例は数え切れないほどある。