技術的負債
技術的負債の一般的な原因は次のとおり。
継続的な開発:時間をかけてプロジェクトを強化していくと、古いソリューションは最適ではなくなる。
不十分な先行定義:開発中に要件がまだ定義されていない場合、設計が行われる前に開発が開始される。これは時間を節約するために行われるが、後になって手直しをしなければならないことがよくある。
ビジネス上のプレッシャー:必要な変更が完了する前に、ビジネスが何かをすぐにリリースすることを検討する場合、未完了の変更からなる技術的負債が蓄積される。
プロセスや理解の欠如。企業が技術的負債の概念に気付かず、その影響を考慮せずに意思決定を行う。
緊密に結合されたコンポーネント。機能がモジュール化されていないため、ソフトウェアはビジネスニーズの変化に対応できるだけの柔軟性を持たない。
テストスイートがないため、迅速でリスクの高い応急的なバグ修正が行われる。
文書化の欠如:コードが文書化されずに作成されている。ドキュメントを作成するための作業は負債となる。
コラボレーションの欠如:知識が組織内で共有されず、ビジネスの効率が低下したり、若手開発者が適切に指導されない。
最終的には、機能を提供するためのコストが非常に遅くなり、設計の良い競合ソフトウェア製品が機能面で設計の悪いソフトウェアを追い越すことが容易になる。私の経験では、設計の悪いソフトウェアは、エンジニアのストレスを増大させ、スタッフの離職率を高める(これは、機能を提供する際のコストと生産性に影響する)。さらに、コードベースが複雑になると、作業を正確に見積もることができなくなる。また、開発会社が機能ごとに料金を設定している場合、コードを納品する際の利益率が低下してしまう。 - Junade Aliは、Mastering PHP Design Patternsにこのように書いている。
グラディ・ブーチは、都市を進化させることが、ソフトウェア集約型システムを進化させることに似ていること、そしてリファクタリングの欠如が技術的負債につながることを比較している。
"技術的負債の概念は、システムにかかる力を理解する上で中心的なものであり、システムがどこで、どのように、そしてなぜストレスを受けているのかを説明するのに役立つ。都市部では、インフラの修理が遅れがちで、大胆な変更ではなく段階的な変更が行われる。ソフトウェア集約型のシステムでも同じことが言える。ユーザーは気まぐれな複雑さ、改善の遅れ、不十分な漸進的変化の結果に苦しみ、そのようなシステムを進化させる開発者は、常に追いつこうとしているために質の高いコードを書けないという苦しみを味わうのである。" - グラディ・ブーチ、2014年
オープンソースソフトウェアでは、ローカルな変更を上流のプロジェクトに送ることを先延ばしにすることが、技術的負債の一種である。
ケニー・ルービンは、次のような状態区分を用いている。
ハプニング的な技術的負債:開発チームが、製品に対する通常の作業中に露呈するまで、その存在に気づかなかった負債。例えば、開発チームが製品に新機能を追加している最中に、何年も前に退職した人がコードに回避策を組み込んでいたことに気付いたとする。
既知の技術的負債:開発チームが把握している負債で、前述のいずれかの方法で可視化されたもの。
ターゲットにされた技術的負債:既知の技術的負債で、開発チームがサービスを提供する対象となっているもの。