いつレガシーシステムをリファクタリング、置き換え、または廃止すべきか？

Question

Accepted Answer

レガシーシステムは不快ですが、しばしば価値があり、ビジネスを運営しています。**リファクタリング、置き換え、または廃止**の決定は、古いコードに対する嫌悪感ではなく、コストと価値によって駆動される必要があります。「古くて醜い」は理由ではなく、「コストがかかっている」というのが理由です。

## なぜ重要なのか

```text
REFACTOR (improve in place) when:
  - Core logic is sound; it's holding business value
  - Problems are localized; you can improve incrementally

REPLACE (rewrite/migrate) when:
  - It blocks important work and can't be incrementally fixed
  - Maintenance cost > rebuild cost over a sensible horizon
  - It's a growing security or reliability liability

RETIRE (remove entirely) when:
  - Its value no longer justifies any maintenance cost
  - Usage has dwindled; a simpler path exists
```

## 書き直しの罠に注意

完全な書き直しは魅力的で、しばしば災難的です。予想より時間がかかり、古いバグが再導入され、その間に動作中のシステムが腐ります。段階的なリファクタリングまたはストラングラー・フィグのパターンによる置き換えを優先します。段階的なパスが本当に塞がっている場合にのみ完全な書き直しに頼ります。

## 具体例

モノリスは厄介ですが、正常に動作しており、ボトルネックではありません。最悪のモジュールをリファクタリングして、書き直さないでください。しかし、来年セキュリティサポートが失われるデータベースバージョン上のシステムで、アップグレードパスがない場合、それは強制的な置き換えであり、意図的に計画します。

## 落とし穴

感情的な決定：十分なシステムが古くさいから置き換えるか、沈没費用から瀕死のシステムにしがみつく。コストと価値に基づいて決定します。

## なぜ重要なのか

不要な書き直しは何年も無駄にし、解決済みの問題を再導入します。放置されたレガシーは時限爆弾になります。

この判断を美学ではなく証拠に基づいて正しく判断することは、シニアTLが下す最も高いリスクを伴う判断の1つです。