古いコードを見るたび「全部直したい」と思う一方、機能の依頼は止まりません。そこで「空いた時間にリファクタリング」とだけ決めると、影響の大きい部分も後回しになりがちです。
この場面では、きれいに見えるかより、次に触る予定のある場所で、実際に繰り返し払っている負担を優先します。 ただしセキュリティやデータ破損など、直ちに扱うべきリスクは別枠で緊急に判断します。
技術的負債は便利な比喩ですが、古いコードを全て同じ緊急度にする言葉ではありません。Martin Fowlerの説明でも、利息にあたる負担が小さい、めったに触らない箇所なら返済を急がない判断に触れています。
「負債がある」を、観測した負担へ言い換える
架空の問い合わせ管理アプリで、改善候補が四つあるとします。
| 候補 | 観測できた負担 | 次に触る予定 | 先に確かめること |
|---|---|---|---|
| A：件名の入力条件が画面とAPIで別実装 | 前回の上限変更で片方だけ直り、101文字が保存された | 来月、入力項目を増やす | 条件の正本をどこへ置くか。画面とAPIの表示責任 |
| B：古い管理画面のクラス名が読みにくい | 読みにくいという声はあるが、直近半年の変更はない | 当面なし | 実際の修正時間へどの程度影響しているか |
| C：通知失敗時に再送の成否を追えない | 障害時に調査が長引き、利用者への回答が遅れた | 再試行機能を改修予定 | ログと識別子でどこまで追えるか |
| D：一覧表示の処理が遅い | ある条件で応答が遅いとの報告。測定値は未取得 | 利用者が増える予定 | 実測の遅さとボトルネック |
この時点で私なら、Aを次の入力項目追加と同じ計画に載せると提案します。直近の不具合という実害があり、次の変更でも同じ重複を触るからです。Cは通知改修に先立って調査と改善案を準備します。Dは測定が先。Bは読みづらさの報告だけで大きな改修を始めません。
ただしCで通知の欠落や二重送信が今も発生しているなら、Aより優先する可能性があります。表は一回の結論を固定するためでなく、事実が増えたときに判断を変えるためのものです。
点数より、「いつ何に困るか」を比べる
候補を機械的に合計点へ変えると、根拠の薄い数字でも精密に見えてしまいます。小さなチームなら、次の四つを短い文章で比べる方が使いやすいです。
- 実害：障害、手戻り、変更にかかった余分な時間はあるか。
- 繰り返し：その負担は何回起きたか。次にまた起きそうか。
- 変更予定：次の機能改修で同じ部分を触るか。
- 対処費用と危険：直す範囲、確認範囲、戻す難しさはどれくらいか。
もしAを完全に作り直すと広い回帰確認が必要なら、まず「画面とAPIが同じ条件を参照する」「両経路の境界値テストを追加する」という小さな範囲から始めます。費用と危険に応じて返済方法を調整します。
改善チケットを記入してみる
件名：件名の文字数上限が画面とAPIでずれないようにする
困っている事実：前回の上限変更で画面側のみ直し、API経由で101文字を保存できた。修正と確認が二度手間になった。
今回の範囲：上限値と判定条件の置き場所を整理し、画面・APIの100文字／101文字テストを追加する。既存データの一括修正は含めない。
期待する結果：両経路で100文字は受理、101文字は拒否される。次の上限変更時に変更箇所が明示される。
確認者：画面担当とAPI担当。影響する外部連携は別途確認する。
実施時期：次の入力項目追加に着手する前。
「共通化する」とだけ書くと、手段が目的になります。この票では、二重の修正と不一致を減らすという成果を先に置きます。チームの設計規約や入力経路が違えば、共通化の形は別案でも構いません。
改修しない判断も、期限付きで残す
Bの古い管理画面は、今すぐ全面改修しない判断がありえます。ただ「放置」で終わらせず、利用者や改修予定に変化があったら再評価する、と記録します。Dは性能測定の担当と日付を決め、観測しないまま「遅そうだから作り直す」とは決めません。
技術的負債を人・組織の判断まで広げて学ぶ候補として、『エンジニアリング組織論への招待』の出版社紹介を確認できます。本記事の四候補と判断表は独自の架空例です。リーダー候補の本棚（Amazon・アフィリエイトを含みます）にも載せています。
次の改善会議では「直したいコード」を一つ挙げ、最近の実害と次に触る予定を一行ずつ書いてください。両方が示せれば、ほかの仕事と並べて相談できます。
