【2026年最新】技術的負債をどう返すか｜優先順位の付け方7項目

急ぎで実装した箇所、後で直すつもりで放置した設計、更新されないまま残るライブラリ。こうした状態は開発の速度を徐々に落とします。ただし一斉に直そうとすると手が止まるため、返す順序を決める必要があります。この記事では、優先順位の付け方と進め方を整理します。

負債の種類

【結論】意図的なものと、そうでないものがあります。

意図的な負債

期限を優先して、あえて簡易な実装を選んだものです。判断としては妥当な場合があり、後で返す前提で作られています。

無自覚な負債

知識不足や検討不足によって生じたものです。当時は最善だと思っていた実装が、後から問題になります。

環境の変化による負債

使っているライブラリが更新されなくなった、推奨される書き方が変わったといった、外部要因によるものです。

放置による悪化

いずれの種類でも、時間が経つほど返済の難易度が上がります。周辺のコードが依存を増やしていくためです。

優先順位の7項目

【結論】触る頻度と実害で決めます。

1. 変更の頻度

よく手を入れる箇所ほど、負債の影響を繰り返し受けます。ここから返すと効果が大きくなります。

2. 実害の有無

不具合が発生している、性能が落ちている、といった具体的な問題があるなら優先度は上がります。

3. 安全性への影響

脆弱性を抱えている箇所は、実害が出る前に対処してください。

4. 変更の予定

これから機能を追加する予定の箇所なら、その作業に含めて返せます。別途の工数が要りません。

5. 影響範囲

多くの箇所から呼ばれているものほど、直したときの効果が広がります。ただし壊したときの影響も広がります。

6. 返済の難易度

短時間で終わるものから片付けると、進んでいる実感が得られます。大きなものは分割してください。

7. 担当者の理解度

その箇所を理解している人がいるうちに返すほうが安全です。担当者がいなくなると難易度が上がります。

状況	優先度	進め方
よく触る・実害あり	最優先	専用の時間を取る
よく触る・実害なし	高い	次の変更のついでに
触らない・実害あり	中程度	影響を見て判断
触らない・実害なし	低い	放置してよい

進め方

【結論】少しずつ、機能変更と分けてください。

機能の変更と混ぜない

整理と機能追加を同じ変更に含めると、不具合が出たときにどちらが原因か分かりません。分けて記録してください。

テストを先に用意する

直す前に、現在の動作を確認するテストを書いておきます。変更後も同じ結果になることを確かめられます。

小さく分ける

一度に大量を変えると、確認が困難になります。数百行程度に収めると、見直しも通りやすくなります。

継続的に行う

まとまった時間を確保するより、日常の作業に少しずつ含めるほうが続きます。

周囲の理解を得る

【結論】言葉を変えてください。

「きれいにする」は伝わらない

技術者以外には価値が見えません。何が改善されるかを、成果として説明してください。

時間で示す

「この修正に毎回2時間かかっているが、整理すれば30分になる」という形なら、判断材料になります。

不具合の頻度で示す

「この箇所で過去半年に5件の不具合が出ている」といった数字は説得力があります。

危険で示す

「この状態が続くと、変更のたびに障害の可能性がある」という説明が有効な場面もあります。

やってはいけないこと

【結論】全面的な作り直しは避けてください。

ゼロから書き直す

既存のコードには、表面に見えない考慮が埋め込まれています。作り直すと、それらが失われます。

誰にも相談せず進める

大きな変更を独断で行うと、他の作業と衝突します。事前に共有してください。

完璧を目指す

すべてを理想的な形にしようとすると終わりません。実害のある部分に絞ってください。

放置し続ける

逆に、まったく手を入れないと悪化します。少しずつでも進める仕組みが必要です。

仕組みで防ぐ

【結論】増やさない工夫が最も効きます。

自動検査を入れる

規約違反や危険な書き方を、機械的に検出できます。混入の段階で止められます。

見直しの基準を決める

変更を通す条件を明確にすると、負債の混入が減ります。

記録に残す

意図的に簡易な実装を選んだ場合、その理由と、後で直すべき内容をコメントか課題管理に残してください。

定期的に棚卸しする

溜まった項目を定期的に見直し、優先度を更新してください。放置された項目が増えると、一覧そのものが機能しなくなります。

時間の確保

【結論】日常に組み込む方法が現実的です。

作業の一部として

機能追加の際、その周辺を少し整理する習慣をつけます。まとまった時間を取らずに済みます。

割合を決める

作業時間の1割から2割を整理に充てる、といった目安を設ける方法があります。

専用の期間を設ける

数か月に一度、まとまった期間を取る方法もあります。ただし他の作業が止まるため、合意が必要です。

担当を回す

特定の人だけが担うと偏ります。順番に担当する仕組みにすると、知識も広がります。

よくある質問（FAQ）

Q1. どこから手を付ければよいですか

よく触る場所で、実害が出ている箇所からです。触らない場所は後回しで構いません。

Q2. 上司の理解が得られません

時間や不具合の件数といった数字で示してください。「きれいにする」では伝わりません。

Q3. 全部作り直したほうが早そうです

既存のコードには見えない考慮が埋め込まれています。作り直しは想定より時間がかかります。

Q4. テストがない場合は

直す前に、現在の動作を確認するテストを書いてください。それが安全網になります。

Q5. どのくらいの時間を充てるべきですか

作業時間の1割から2割を目安にする例があります。日常に組み込むほうが続きます。

Q6. 意図的な負債は問題ですか

期限を優先する判断は妥当な場合があります。ただし後で返す前提と、その記録が必要です。

まとめ

技術的負債は、全部を返す必要はありません。よく触る場所、実害が出ている場所、これから変更する場所を優先してください。触らない場所の負債は、放置しても損失が生まれません。

進めるときは、機能の変更と分けて記録してください。混ぜると、不具合が出たときにどちらが原因か分からなくなります。直す前にテストを用意しておくと、変更後も同じ動作であることを確認できます。

周囲の理解を得るには、言葉を変えてください。「きれいにする」では価値が伝わりません。修正にかかる時間や、不具合の発生件数といった数字で示すと判断材料になります。

最も効くのは、増やさない工夫です。自動検査を入れる、意図的に簡易な実装を選んだ理由を記録に残すといった仕組みで、混入そのものを減らせます。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu