窓を開けるか、引っ越すか——二階建ての家で読み解く legacy modernization

legacy modernization、legacy migration、replatform、re-architect……こうした言葉が世間にあふれると、人はすぐ混乱してしまう。私も一時期、区別がつかなくなっていた。古いシステムはその場で改修すべきなのか、それとも新しいプラットフォームへ丸ごと移すべきなのか。後に「二階建ての家」という二つのたとえ話で、この線引きがすっきり整理できた。

一つ目の例：家はそのまま、表通りに面した壁に窓を開ける

私は二階建ての家を持っている。二階は住居、一階は階段を使わずに済むので事実上は倉庫で、買いためた生活用品を置いている。最近、一階の表通り側の壁に小さな窓を開けて、倉庫を小さな店にして商売を始めたいと思っている。

家はやはりその家だ。基礎も耐力壁も、二階での暮らし方も、一切動かさない。ただ壁に窓を一つ開け、これまで家族しか出入りしなかった倉庫を、管理された形で近所に向けて開く。

これはソフトウェアアーキテクチャで Modernization（現代化） と呼ばれ、具体的には Replatform（部分的な改修、土台の最適化） あるいは Refactor / Encapsulate（カプセル化とリファクタリング） に近い。技術的な対応は分かりやすい。銀行のメインフレーム上で動く COBOL の古い基幹系はそのままにして、外側にマイクロサービスや API Gateway をかぶせれば、スマホアプリから古いシステムの口座残高を呼び出し、オンライン事業を始められる。

利点は低コストで効果が早く、中核資産には一切手を付けずに済むことだ。古いシステムが再び商業的な価値を生む。制約も明快で、窓をどれだけ大きくしても家はその家のままだ。何人迎えられるか、どれだけの重さに耐えられるかは、元の基礎と耐力壁で決まる。

二つ目の例：CBD へ引っ越し、商住一体で計画し直す

同じ二階建ての家だが、私は都心の CBD のほうがいいと思い、引っ越すことにする。その際、今のように一階に荷物を積み、二階に住むのではなく、最初から「商売をしながら住む」前提で計画しなければならない。

これがより厳密な意味での Migration（移行、移植） だ。現実には、元の土地を完全に離れる。技術に置き換えれば、古いサーバーや旧アーキテクチャの環境を離れ、リソースが集中するより現代的な場所へ移ることになる。たとえばパブリッククラウドへの移行や SaaS への切り替えだ。新しい土地を最初から商住一体で設計するのは、新規事業に合わせてアーキテクチャを作り直すことに相当する。

ここからさらに一段分かれる。古いプラットフォーム上のデータと業務ロジックをそのまま新しいプラットフォームへ移すだけなら、変更は小さく、純粋な migration だ。家を家具ごと CBD へ吊り上げて運ぶようなものだ。内部構造まで作り直すなら、Re-architect（アーキテクチャ再構築）、さらに Replace（建て替え） の領域に入る。自社サーバールームのモノリスをパブリッククラウドへ移し、同時にマイクロサービスやコンテナ（Docker / K8s）で業務全体を書き直すイメージだ。

動きは大きく、期間も長く、コストも高い。だが技術的負債を完全に断ち切り、天井が開ける。

なぜ世間では混同されるのか

この二つの言葉が混ざりやすいのは、並列ではなく包含関係にあるからだ。

レガシーマイグレーション（Legacy Migration、レガシーシステム移行） の重点は「移転」にある。古いプラットフォーム上のデータと業務ロジックを、ほぼそのまま、あるいは小さな変更で新しいプラットフォームへ移すことが目的だ。家を家具ごと CBD へ吊り上げて運ぶのに似ている。「住所を変える」問題に答えるものだ。

Legacy Modernization（レガシーシステムの現代化） の重点は「進化」にあり、より大きな傘の概念だ。引っ越しだけでなく、古い家に窓を開けること、新しい配管を引くこと、一部を取り壊して建て直すことも含む。最終的な目的は、古い資産に現代的なアジャイルデリバリーと、新規事業へ素早く応える力を備えさせることにある。

だから厳密には、引っ越しは現代化の一部分だ。窓を開けて小さな店にするのは現代化であり、CBD へ移って開業し直すのは、現代化が促す本格的な移行と再構築だ。

窓を開けるべきか、引っ越すべきか

たとえ話をソフトウェアエンジニアリングに戻すと、判断は三つの問いに集約される。

第一に、耐力壁はまだ持つか。古いシステムの中核ロジックが今も信頼でき、外向けの窓口だけが足りないなら、窓を開ける、つまりカプセル化して API を一枚かぶせるだけで足りることが多い。

第二に、制約は家から来るのか、土地から来るのか。ボトルネックがサーバー、運用、弾力性、コストといった「土地」の側にあるなら、内装の改修では解決しない。引っ越す必要がある。

第三に、新規事業が求める間取りに、古い家を改築できるか。業務フローやデータモデルが噛み合わないなら、引っ越しだけでは足りず、設計からやり直すことになる。

この三つの動作は排他的ではない。Modernization はもともと Migration を含んでいる。一つのプロジェクトで窓を開け、引っ越し、ついでに間取りも変えることは十分あり得る。避けるべきなのは、「引っ越し」を万能の答えにすること、あるいは「窓を開ける」ことを終着点にすることだ。

次に誰かが legacy migration と言ったら、こう聞き返せばいい。それは引っ越しの話か、それとも改装込みの話か。この一言で、概念はほぼ整理できる。