技術的負債の優先順位｜修正を提案するための整理表

技術的負債の優先順位を相談するときは、「設計が古い」「きれいにしたい」という評価だけでなく、どの変更で何が困るのかを示す必要があります。修正にも時間と影響範囲があるため、すべてを一度に解消する前提では合意を作りにくくなります。

この記事では、負債の候補を記録し、修正と先送りを比較するための整理方法を提案します。数値による削減効果や実際の社内事例を示すものではありません。

不満の一覧から、変更を妨げる構造の一覧へ

カーネギーメロン大学SEIは、短期的な利点を選んだ設計などによって将来の変更が高コストになる問題を技術的負債として説明しています。コードの見た目だけに限定されず、可視化したうえでトレードオフを判断することを勧めています。SEIの技術的負債管理の解説

「重複が多い」なら、どの規則が何か所に分かれ、変更時にどのような確認が必要なのかを書きます。単に好みと異なる実装なのか、今後の変更に具体的な負担を生む構造なのかを区別するためです。

すでに発生している障害や脆弱性は、技術的負債という名前を付ける前に、それぞれの対応基準で扱います。負債の整理表へ入れたことで緊急対応が後回しにならないよう、別の対応経路が必要かを先に確認します。

以下はチーム内の比較に使う提案です。合計点を自動的な結論にせず、観測事実と見積もりを分けて記入します。

記録した件数やコードの行数は、負担の一面を示す材料です。それだけで事業影響や修正の難しさを置き換えないようにします。

説明用に、同じ料金規則が複数の処理へ分散しているシステムを考えます。次の料金改定で各処理の修正が必要だと分かったとしても、即座に全面共通化が最善とは限りません。

比較する案は、たとえば「今回は変更箇所と確認ケースを明文化する」「共通化する部分を限定する」「料金計算全体を再設計する」です。それぞれについて、今回の改定に間に合うか、挙動を保てるか、次の変更で負担が残るかを比べます。

計算結果の確認材料が不足しているなら、まず期待結果を整理する作業を分ける方法があります。修正そのものと、その安全性を判断するための準備を一つの大きな見積もりに隠さないことがポイントです。

「次の改定で再び複数箇所を触るため、限定的な共通化を先に行う」「変更予定がなく影響が小さいため、次回改修時に見直す」のように、順番の理由を文章にします。

修正費用が分からない候補同士を、精密な費用対効果で順位付けしたように見せないでください。比較できない場合は、最初に調べる範囲と、その結果で判断する事項を決めます。

採用しなかった案にも、今回見送る理由を残せます。設計上の選択肢を記録する方法は、ADRの書き方も参考になります。

整理表は作成時点で完成ではありません。対象機能の変更予定、実際に生じた負担、調査で分かった修正範囲が変われば、優先順位も見直します。

まずは一つの負債候補について、困った変更の例、修正案、先送りした場合の見直し条件を残してください。チームが判断できる粒度に分けることが、解消に着手する場合にも、今は着手しない場合にも役立ちます。