Rosarium

考察 / 公開物 / essay

レガシーシステムは、変えやすくしながら終わらせる

廃止予定でも変更要求が続く既存システムを、どう保守しながら終わらせるか考えます。依存や変更箇所を減らし、役割を段階的に移す判断を整理します。

公開:最終更新:

更新履歴

  1. 改訂

    機能と実装を分離し、保持する条件と引き継ぎ先から廃止を設計する観点を整理した

  2. 公開

レガシーモダナイゼーション / ライフサイクル / 変更容易性

目次
  1. レガシーの問題は、古いことだけではない
  2. 終わらせるまでの期間も長い
  3. 「楽に与件対応できる状態」を作る
  4. 終わらせやすさも設計できる
  5. 機能と実装を分離し、役割を移す
  6. 「残すこと」にもコストがある
  7. 私が探求していること

最近、私はレガシーシステムについて、

どう終わらせるか そして、 終わらせるまでの間、どう楽に与件変更へ対応できるようにするか

を考えることが増えています。

新しいシステムを作る話は目立ちます。

一方で、企業の現場には、 すぐには捨てられない既存システムが大量に残っています。

それらは古いからといって、簡単に停止できるわけではありません。

利用者がいる。 業務が依存している。 他システムと連携している。 過去の仕様を前提にした運用が残っている。

だから現実には、

今すぐ作り直す

でも、

そのまま永遠に保守する

でもない選択が必要になります。

私はその間にある、

「変えやすくしながら、終わらせやすい状態へ持っていく」

ことに大きな価値があると考えています。

レガシーの問題は、古いことだけではない

レガシーシステムというと、

  • 古い言語
  • 古いフレームワーク
  • 古いOS
  • 古い設計

といった技術面が注目されがちです。

しかし、企業にとってより大きな問題は、

変更するたびにコストがかかること

ではないでしょうか。

小さな与件変更なのに、

  • 影響範囲の調査に時間がかかる
  • 仕様が分からない
  • 関係する処理が多い
  • テスト範囲が広い
  • 一部を変えるだけなのに全体確認が必要になる

という状態では、変更するたびに企業の負担が積み上がります。

レガシーシステムの本当のコストは、

古いことそのものより、変えにくいこと

にあると思っています。

終わらせるまでの期間も長い

もう一つ重要なのは、

レガシーシステムは、終わらせると決めてから実際に終わるまでが長い

ということです。

新システムへの移行を決めても、

  • 利用者移行
  • データ移行
  • 周辺システムの切り替え
  • 契約整理

などが必要になります。

その間も既存システムには、 法改正や仕様変更、障害対応、新しい要求が入ってきます。

つまり、

廃止予定だから何も変えなくてよい

とはなりません。

終わるまでの数年間、 企業はそのシステムを維持し続ける必要があります。

だからこそ、

終焉設計と変更容易性はセット

で考える必要があります。

「楽に与件対応できる状態」を作る

私は、レガシーシステムに対して、

すべてをきれいに作り直す

ことだけが正解だとは考えていません。

むしろ重要なのは、

必要な変更を、できるだけ小さな影響範囲で実施できる状態にすること

です。

たとえば、

  • 変更点を局所化する
  • 既存ロジックと新しい処理を分離する
  • 外部依存を明確にする
  • 設定値やルールをコードから分離する
  • テスト可能な境界を作る
  • 仕様を理解しやすい形で残す

といったことによって、

次の変更を少し楽にする

ことはできます。

一回の改修を楽にするだけではありません。

その後に続く変更コストを下げる。

企業にとってはこちらの方が大きいと考えています。

終わらせやすさも設計できる

システムを終わらせるときも同じです。

廃止直前になってから考えるのではなく、

日々の改修の中で、

  • 機能を分離する
  • 依存関係を減らす
  • データ移行しやすくする
  • 代替先へ役割を移しやすくする

といったことを積み重ねておく。

そうすることで、

少しずつ終わらせやすい状態へ近づける

ことができます。

私は、これを単なる保守ではなく、

ソフトウェアライフサイクルの設計

だと考えています。

機能と実装を分離し、役割を移す

必要な機能を残すことと、現在の実装を残すことは同じではありません。依存する業務、データ、周辺システムを確認し、機能を後継へ引き継げれば、実装を段階的に入れ替えられます。

一方、業務・組織・データ・運用が密接に結び付いていると、一つのシステムを終えるにも周囲の変更が必要です。終了の速さを目標にする前に、何を保持し、誰が引き継ぎ、どの条件で切り替えられるかを明らかにします。

「残すこと」にもコストがある

企業では、

今動いているから残す

という判断がよくあります。

しかし、残すことにもコストがあります。

  • 保守要員
  • テスト
  • セキュリティ対応
  • 問い合わせ対応
  • 仕様理解
  • 周辺システムとの整合
  • 古い技術の維持

などを払い続ける必要があります。

つまり、

廃止しないことも、一つの投資判断

です。

だから私は、

残すか 変えるか 終わらせるか

を継続的に判断することが重要だと考えています。

私が探求していること

私自身は今、

レガシーシステムをどう終わらせるか

と同時に、

終わるまでの間、どう楽に変更要求へ対応できる状態を作るか

を考えています。

すべてを一度に刷新するのではなく、

  • 変更コストを下げる
  • 影響範囲を狭める
  • 依存を減らす
  • 役割を少しずつ移す
  • 最終的に安全に終わらせる

という流れです。

これは企業にとって大きな価値があると思っています。

新しいシステムを作ることは分かりやすい投資です。

しかし、

古いシステムを楽に変えられるようにすること そして 古いシステムを安全に終わらせること

も、同じくらい重要なIT投資です。

私は、

作る・変える・終わらせるまで、ソフトウェアライフサイクル全体を見ること

が、IT戦略の重要な役割の一つだと考えています。