技術債務

技術的負債とは、当時としては都合が良かったものの、将来の変更を遅らせたりリスクを高めたりするような実装上の選択によって蓄積されたコストのことです。これは、ワード・カニンガムの比喩で、将来の生産能力を担保に今すぐ出荷を早めるために借り入れを行い、その負債が返済されるまで、その後の変更ごとに利息を支払うというものです。金融負債と同様に、技術的負債は本質的に悪いものではなく、重要なのは、意図的に負った負債と、怠慢によって蓄積された負債との違いです。

この比喩の価値は、コードを書かない人々とトレードオフについて議論できる点にある。リファクタリングの要求を負債の返済と捉えることで、モジュールの書き直し要求では伝えられないこと、つまり、納期の遅延や欠陥率の上昇という形で既にコストが支払われており、問題はそれを払い続けるかどうかであるということを伝えることができる。カニンガムの元の定式化では、負債はコードの構造とチームの現在の問題理解との間のギャップの拡大から生じることも強調されており、これは単に締め切りに間に合わせのずさんなコードを書くというよりも、より広い概念である。

この用語にはいくつかの異なるものが含まれており、それぞれ異なる対応が必要です。意図的な負債は、実際の納期に間に合わせるために計画的に引き受けたものであり、正当なエンジニアリング上の決定です。偶発的な負債は、設計が確定した後にチームの理解が深まったために発生したもので、避けられないものであり、学習に伴う通常のコストです。テストの欠如、ドキュメント化されていない動作、メンテナンスされていない依存関係などによる怠慢な負債は、静かに蓄積され、あらゆる変更のリスクを高めるため、最もコストのかかるカテゴリです。特に古い依存関係は、単なる不便さではなく、セキュリティ上のリスクをもたらします。

コードに問題が現れる前に、デリバリー指標に兆候が現れます。同様の作業に対する見積もり額の増加、欠陥処理に費やすリソースの割合の増加、特定の領域への手出しに対する抵抗感、そしてある箇所の変更が無関係な部分に影響を与えるといった兆候はすべて、利息の支払いが相当な額になっていることを示しています。チームはこれらの兆候をリソース不足の問題として報告し、人員増強を要求することがよくありますが、これは通常、短期的には状況を悪化させるだけです。

管理するには、他のすべての作業と同様に、計画プロセスの中でその作業が可視化される必要がある。余剰能力がある時だけ対処する別リストに載せられた債務は、そもそも余剰能力がないため、決して対処されない。各サイクルの一定割合を債務に割り当てるか、変更対象領域の機能改善作業に是正措置を付随させるかの2つのアプローチは、商業的圧力に耐えうるものである。代替案である定期的な大規模な書き換えは、通常、作業を先延ばしにしすぎた兆候であり、段階的な改善よりもはるかに大きなリスクを伴う。

改善の必要性を伝えるには、エンジニアリングの観点からよりも、デリバリーの観点から伝える方が効果的です。最近の作業実績を根拠に、特定の領域の変更に他の領域と比べて3倍の時間がかかると説明すれば、非技術系の関係者が既に関心を持っている事柄と問題を結びつけることができますが、アーキテクチャ上の懸念事項を説明するだけではそうはいきません。保守されていない依存関係やクリティカルパス上のテストカバレッジの欠如など、負債がコストではなくリスクを伴う場合は、それを品質の問題として捉えるよりも、発生確率と影響を伴うリスクとして捉える方が効果的です。どちらの場合も、継続的なコストを定量化することで、エンジニアリング上の優先事項を、機能開発とリソースを競合できるビジネスケースへと転換できます。

すべての負債を返済する必要はありません。正常に動作し、変更が少なく、問題を引き起こさないコードは、見た目に関係なくそのままにしておいても構いません。それを改善するために費やす労力は、何の利益も生みません。経済的に健全なアプローチは、変更が頻繁に発生し、実際に利息が支払われている箇所に修復を集中させることです。このトレードオフを可視化し、計画段階でそのための明確な能力を確保することは、通常のプロセスの一部です。 製品開発 関与は構造化されており、ロードマップの議論の中に含まれます。 製品スタジオ 製品に関する議論とは切り離された、技術的な問題として扱われるのではなく。