4.5 技術的負債の測定

概要と動機

ウォード・カニンガムによって作られた比喩である技術的負債は、過去の近道、何かをより早く出荷したが後でコードベースを変更しにくくした便宜的な決定の蓄積されたコストを記述します。これは、金融的な負債が、後で利子を払う代償を払って今使うことを可能にするのと同じです。すべてのコードベースはいくらかの技術的負債を抱えており、それは自動的に失敗ではありません。この比喩の本当の価値は、負債を恥ずべき秘密や避けられない永続的な負担としてではなく、管理可能なトレードオフとして枠組みづけることです。本トピックは、すべてのエンジニアが感じているが誰も証拠をもって行動できない、漠然とした永遠に優先度を下げられた心配事としてそれを放置するのではなく、測定を通じてそのトレードオフを可視化し管理可能にすることについてです。

本トピックに先立つトピック、複雑さ(4.1)、カバレッジ(4.2)、チャーンとホットスポット(4.3)、静的解析(4.4)は、それぞれ技術的負債の一面を表面化させます。本トピックの仕事は統合です。これらの別々の信号を、どんな自動化されたスキャンにも決して現れない項目(文書化されていないアーキテクチャの近道、意図的に延期された移行)と一緒に、機能の仕事と公平に投資を競い合う、単一で優先順位づけられた可視化されたバックログに変えることです。それに指標が結びついておらず計画会議に擁護者がいないという単純な理由でその競争に既定で負けるのではなくです。

大規模なチームにとって、管理されていない技術的負債は、本物に危険で過小評価しやすい形で積み重なります。それぞれの新しい近道は次の変更をわずかに難しくし、これはより多くの近道へのプレッシャーを生み出し、それがさらに積み重なります。何年にもわたってシステムを維持する企業や政府の組織は、特にこの積み重なる効果にさらされており、本トピックの中心的な推奨事項、可視化され定量化され優先順位づけられた負債のバックログは、組織が危機へと漂流するのではなく、実際にそのトレードオフを意図的に管理することを可能にする仕組みです。

重要な原則

技術的負債は、恥ずべき秘密ではなく管理可能なトレードオフのための意図的な比喩である。 知りながら引き受けられたいくつかの負債は、合理的なビジネスの決定です。
測定されていない負債は、機能の仕事に対する優先順位づけの競争に既定で負ける。 それがより重要でないからではなく、目に見える擁護者がいないからです。
意思決定者が比較検討できる言葉で負債を定量化してください。修正のコスト対それを抱え続けるコストです。 「コードが乱雑だ」という漠然とした主張は、具体的な機能の依頼に対してめったにうまく競争しません。
負債は積み重なる。 それぞれの新しい近道は将来の変更をわずかに難しくし、管理されないままだとその効果は加速します。
すべての負債が返済されるべきではない。 それを修正するコストがそれを抱えて生きるコストを超えるなら、無期限に抱え続ける価値があるものもあります。

推奨事項

可視化された単一の技術的負債バックログを構築する

このパートの前のトピックからの信号、複雑さの外れ値、低いミューテーションキル率の領域、ホットスポット、未解決の静的解析の発見を、人間だけが特定できる負債の項目(アーキテクチャの近道、延期された依存関係のアップグレード、文書化されていない回避策)と一緒に、あなたの機能のバックログと同じ厳密さと可視性で追跡される、一つの可視化されたバックログに統合してください。個々のエンジニアの記憶の中だけに、あるいは散在するコードのコメントの中だけに生きる負債は、優先順位づけの目的のためには事実上存在しません。

各負債項目のコストと抱え続けるコストを定量化する

各項目について、二つの数字を見積もってください。それを修正するコスト(エンジニアリングの時間、修正自体のリスク)と、それを修正せずに抱え続けるコスト(関連する仕事がどれだけ遅くなるか、どれだけの追加の欠陥リスクを抱えるか、どれだけ他の仕事をブロックするか)です。金融的な負債の比喩自身のロジックから直接借用されたこの枠組みは、意思決定者に、抽象的で定量化されていない苦情ではなく、機能の仕事のコストと期待される価値と比較するための本物の基盤を与えます。

年齢や最も声の大きい擁護者ではなく影響を使って優先順位づける

負債の項目を、抱え続けるコストと影響を受けるコードがどれだけ頻繁に触られるか(トピック4.3のチャーンデータがここで直接役立ちます)の組み合わせによってランク付けしてください。めったに修正されないコードベースの一角にある項目は、どれだけ不快であっても、あなたの最も活発な開発の経路に直接座っているものよりもはるかに重要ではありません。どの項目がバックログに最も長く留まっているか、あるいはどのエンジニアが最も粘り強くそれを擁護しているかによって優先順位づけることに抵抗してください。どちらも本物のビジネスへの影響と確実には相関しません。

負債の是正のために専用の保護された容量を割り当てる

すべての計画サイクルで、入ってくるすべての機能の依頼と項目ごとに競争しなければならない負債のバックログは、一貫して負ける傾向があります。なぜなら、機能の仕事は通常、より明確でより即座のビジネスの擁護者を持っているからです。エンジニアリング容量の保護された割合、一般的なパターンは10%から20%の間ですが、を負債の是正のために特に割り当て、毎回のスプリントで新たに交渉するのではなく事前に決定し、負債の返済が危機の余波の中でだけではなく、当然のこととして起きるようにしてください。

いくつかの負債を永続的なものとして受け入れ、それを明示的に述べる

すべての項目がアクティブな是正計画に属するわけではありません。特に安定していてめったに触られず、まもなく廃止されるシステムのコードについて、修正するコストが無期限にその項目を抱え続けるコストを本物に超える場合、その決定を明示的に文書化し、その項目をアクティブなバックログに無期限に座らせ続けて、その継続的な存在が静かに決して実際には起きない仕事を暗示するのではなく、意図的に優先度を下げられたカテゴリーに移してください。

トレードオフ:長所と短所

アプローチ	長所	短所
正式な負債の追跡なし	オーバーヘッドがない	負債が既定で優先順位づけの競争に負ける。見えないまま積み重なる
非公式で場当たり的な負債の認識	オーバーヘッドが低く、いくらかの可視性	一貫性がない。個人の記憶と擁護に依存する
正式で定量化された負債のバックログ	投資を公平に競争し、情報を与えられたトレードオフを可能にする	継続的な保守と定量化の規律が必要
保護された専用の是正容量	反応的にではなく一貫して返済が起きることを保証する	短期的に機能の仕事に利用可能な容量を減らす

中心にある緊張関係は即座の提供のプレッシャーと長期的な保守可能性です。機能の仕事はほぼ常に負債の是正よりも明確で即座のビジネスの擁護者を持ち、これは、負債の累積コストが高いときでさえ、負債がすべての個々の優先順位づけの決定に負ける構造的なプレッシャーを生み出します。この緊張を解消するには、負債の是正を、保護され事前に割り当てられた容量を通じて項目ごとの競争から完全に取り除き、トレードオフが毎回の個別の計画サイクルで再び争われ、通常負けるのではなく、意図的に事前に決定されるようにしてください。

チームで話し合うべき問い

私たちは単一の可視化された技術的負債のバックログを持っているでしょうか。それとも負債の認識は主に個々のエンジニアの頭の中に生きているでしょうか。正直な答えが後者なら、それが本トピックが最初に閉じることを推奨する単一最大の隙間です。
私たちの上位の負債の項目について、機能の依頼と公平に比較できるほど具体的な言葉で、その修正コストと抱え続けるコストを述べることができるでしょうか。できないなら、実際の現在の項目を使ってこの定量化をグループの演習として一緒に練習してください。
私たちのエンジニアリング容量のうち実際にどれだけの割合が負債の是正に向かっており、その割合は意図的に決定されたのでしょうか、それとも機能の仕事が配分された後に残るものがたまたまそうなっただけでしょうか。あなたの実際の最近のスプリントを見て、印象に頼るのではなく実際の数字を計算してください。
私たちの負債のバックログは本物のビジネスへの影響によって優先順位づけられているでしょうか。それとも最も粘り強く提起された、あるいは最も長く留まっている項目によってでしょうか。あなたの現在の優先順位づけをチャーンデータ(トピック4.3)と相互参照し、両者が一致するかを確認してください。
私たちはどの負債の項目を、アクティブなバックログに無期限に座らせ続けるのではなく、明示的に永続的なものとして受け入れるべきでしょうか。修正するコストが抱え続けるコストを本物に超える少なくとも一つの実際の項目を特定し、それを明示的に優先度を下げられた状態に移すことを話し合ってください。
私たちの負債のバックログは過去1年でどう変化し、成長したでしょうか、縮小したでしょうか、それとも横ばいだったでしょうか。そして、その傾向は私たちの直感と一致するでしょうか。単一の一時点だけを見るのではなく、これを時間とともに追跡してください。傾向は、どんな特定の瞬間における絶対的な大きさよりも、しばしばより多くの情報を与えてくれます。

業種別の視点

スタートアップ。 意図的で情報を与えられた負債は、この段階ではしばしば合理的な戦略です。仮説を検証するために速く出荷し、製品が実証されたら特定の近道を再検討する明確な計画を伴うことは、失敗ではなく正当な取引です。危険なのは、どの近道が意図的で可逆的だったか、どれがコードベースが成長するにつれて静かに永続的で検証されない負債になったかを見失うことです。

中小企業。 あなたの既知の近道とそのおおよその修正コストを名指しする、非公式なものであっても単純で共有されたリストは、この規模では通常十分です。採用する価値のある主な規律は、それを静かに蓄積させ親しみを通じて見えなくするのではなく、定期的にそのリストを見直すことです。

企業。 保護され事前に割り当てられた是正容量はここで最も重要です。なぜなら、負債と機能の仕事の間の個々の優先順位づけの競争は、構造的な対抗力なしに、数十のチームにわたって同時に機能を確実に好むからです。負債の項目がポートフォリオレベルの投資決定のためにチームを横断して公平に比較できるように、負債の定量化の慣行を組織全体で標準化してください。

政府。 長寿命のシステムは、何年あるいは何十年もの段階的で個別には合理的な要件変更を通じて負債を蓄積し、しばしば危機がその問題を強制するまで正式な負債の追跡がまったくありません。定量化され可視化された負債のバックログは、監督機関に近代化予算を正当化するための本物に説得力のある道具です。なぜなら、それは「システムが古い」という漠然とした主張を、投資のための具体的でコスト計算された事例に変えるからです。

事例

企業。 ある電気通信会社の請求プラットフォームは、エンジニアがふりかえりで「請求エンジンは混乱している」と日常的に引用するが追跡が一度もなされないまま、10年以上にわたって非公式に認識されているが正式には追跡されたことのない技術的負債を蓄積していました。新しいエンジニアリングディレクターは、すべてのチームに、各項目の修正コストと抱え続けるコストを見積もる定量化された負債のバックログを構築することを要求し、今後エンジニアリング容量の固定された15%を負債の是正に割り当てました。1年以内に、件数でバックログ全体のごく一部を代表する、最も抱え続けるコストの高い上位5項目が解決され、請求関連のデプロイについての変更失敗率(トピック2.10)は測定可能に改善し、バックログを任意の順序で処理するのではなく最も抱え続けるコストの高い項目を最初に狙うことの不均衡な影響を実証しました。

政府。 20年以上前に元々構築された、ある国家統計機関の中核データ処理システムは、重要な部分が脆く理解されていないという広く行き渡った非公式な認識にもかかわらず、正式な負債の評価を一度も受けたことがありませんでした。静的解析の発見、ホットスポットのデータ、そして最も古い構成要素を理解している残り少ないエンジニアへのインタビューを組み合わせた構造化された負債の評価は、複数年の近代化予算要求を直接裏づける定量化され優先順位づけられたバックログを生み出しました。重要なことに、この評価はまた、いくつかの安定しためったに触られないレガシーの構成要素を変更せずに残すことが合理的であると明示的に特定し、データが最も高い継続的なコストを負っていると示した特定の領域への的を絞った投資を優先し、不必要に広範で高価な完全システムの書き直しを避けました。

ビジネスケース:動機、ROI、総所有コスト

技術的負債を意図的に管理することからの見返りは、積み重なるコストの回避です。対処されない近道はそれぞれ将来の変更をわずかに難しくし、その効果は介入なしに加速し、最終的には単純な変更さえ遅くリスクの高いものになるほど脆いコードベースを生み出します。上記の電気通信の例は見返りを具体的に示しています。少数の最も抱え続けるコストの高い項目を狙うことは、それらの項目が代表したバックログ全体のわずかな部分に不均衡な、測定可能な提供と品質の改善を生み出しました。

総所有コストは是正に割り当てられた保護された容量であり、典型的にはエンジニアリング時間の10%から20%であり、これは短期的には機能の速度と競合する本物の見える目のコストです。そのコストは支払う価値があります。なぜなら代替案、管理されず積み重なる負債は、最終的には対処されないままの特定の項目だけでなくコードベース全体にわたって、遅くなった提供と高まった欠陥率において、はるかに多くのコストがかかるからです。

アンチパターンと落とし穴

可視化され追跡された負債のバックログがない。 負債は既定で優先順位づけの競争に負け、見えないまま積み重なります。
漠然とした定量化されていない負債の主張。 計画における具体的で定量化された機能の依頼に対してめったにうまく競争しません。
影響ではなく年齢や擁護の量によって負債を優先順位づける。 限られた是正容量を誤導します。
是正のための保護された容量がない。 負債の返済は、日常的で意図的な慣行としてではなく、危機の後にのみ反応的に起こります。
すべての負債を等しく修正する価値があるものとして扱う。 高い抱え続けるコストの項目が対処されないままである一方で、低影響の項目に努力を無駄にします。
負債がそれを永続的だと一度も決めることなくアクティブなバックログに無期限に座り続けるに任せる。 決して実際には起きない将来の仕事を暗示し、本物の優先順位づけを散らかします。

成熟度モデル

レベル1、開始: 技術的負債は非公式に議論され、追跡されたバックログも定量化もなく、一貫して機能の仕事に負けます。
レベル2、発展: 一部のチームは非公式に負債を追跡していますが、一貫した定量化、チームを横断した可視性、あるいは保護された是正容量はありません。
レベル3、標準化: 可視化され定量化された負債のバックログが組織全体に存在し、保護された是正容量が一貫して割り当てられています。
レベル4、管理: 負債の項目は測定された影響(チャーンと組み合わされた抱え続けるコスト)によって優先順位づけられ、永続的に受け入れられた負債は曖昧なままにされるのではなく明示的に文書化されています。
レベル5、最適化: 組織は、的を絞った負債の是正にたどれる具体的で測定可能な提供や品質の改善を指し示すことができ、負債の管理は機能の仕事と並んでエンジニアリング投資の決定への日常的で信頼される入力です。

議論のためのアイデア

今、私たちの単一の最も抱え続けるコストの高い負債の項目は何で、私たちはそれを定量化できるでしょうか。
私たちの容量のうち実際にどれだけの割合が今日負債の是正に向かっているでしょうか。
私たちのバックログに曖昧なままにしておくのではなく、明示的に永続的なものとして受け入れるべき負債の項目は何でしょうか。
私たちの負債のバックログは過去1年で成長したでしょうか、縮小したでしょうか、それとも横ばいだったでしょうか。
定量化された負債の評価は、私たちの現在の非公式な認識が見逃しているものを何明らかにするでしょうか。

主な要点

技術的負債は管理可能なトレードオフであり、恥ずべき秘密ではありません。 それを漠然とした永遠に優先度を下げられた関心事として放置するのではなく定量化してください。
それぞれの項目について修正コスト対抱え続けるコストを定量化し、それが機能の仕事に対して公平に競争できるようにしてください。
年齢や擁護の量ではなく影響によって優先順位づけてください(チャーンと組み合わされた抱え続けるコスト)。
負債はそうでなければ機能の仕事に対する項目ごとの競争に確実に負けるため、事前に決定された保護され専用の是正容量を割り当ててください。
修正コストが抱え続けるコストを超える場所では、アクティブなバックログに曖昧に残すのではなく、いくつかの負債を明示的に永続的なものとして受け入れてください。

参考文献とさらなる読書

Cunningham, Ward, “The WyCash Portfolio Management System” (OOPSLA experience report, 1992)。
Managing Technical Debt: Reducing Friction in Software Development, Philippe Kruchten、Robert Nord、Ipek Ozkaya 著。
Refactoring: Improving the Design of Existing Code, Martin Fowler 著。
Your Code as a Crime Scene, Adam Tornhill 著。