2026.11.02

レガシーシステムのモダナイゼーション｜手法の違いと進め方

十数年前に作った業務システムが、いまも会社の中心で動いている。改修できる人が限られ、サーバーやOSのサポート期限が近づき、新しいサービスとつなごうにも仕組みが古くてつなげない。こうした状態のシステムを新しい技術や環境に移し替える取り組みが、レガシーシステムのモダナイゼーションです。

モダナイゼーションという言葉からは、システムを最新の技術で全面的に作り直すことを想像しがちです。しかし実際の手法は、いまのシステムをほぼそのままクラウドに移すものから、使っていない機能を廃止するもの、市販のパッケージやSaaSに置き換えるもの、一から作り直すものまで幅があります。どれを選ぶかによって、費用も期間もリスクも大きく変わります。

よくある失敗は、手法を先に決めてしまうことです。「古いから全部作り直す」と決めて大規模な再構築に踏み切った結果、現行システムの仕様を把握しきれずに計画が長期化したり、完成したシステムが業務に合わなかったりします。反対に、問題を先送りし続けて、ハードウェアの故障やサポート終了をきっかけに追い込まれるケースもあります。

この記事では、レガシーシステムが何を問題にしているのかを整理したうえで、モダナイゼーションの主な手法の違い、手法の選び方、進め方、失敗しやすいポイントを発注側の立場から解説します。

レガシーシステムが経営の問題になる理由

経済産業省は2018年9月に公表した「DXレポート」で、既存システムの老朽化・複雑化・ブラックボックス化がデジタル化の足かせになっていると指摘し、こうした課題を克服できない場合、2025年以降に最大12兆円/年の経済損失が生じる可能性があるとして、これを「2025年の崖」と呼びました。この試算の前提や妥当性にはさまざまな議論がありますが、古いシステムが経営上の問題になりうるという認識を広めるきっかけになりました。

ただし、古いこと自体が問題なのではありません。長く安定して動き、業務に合っているシステムは、それだけで価値があります。問題になるのは、次のような状態が重なったときです。

仕様を理解している人が社内にも開発会社にもほとんどいない
OSやミドルウェア、ハードウェアのサポートが終了している、または終了が近い
小さな改修にも長い期間と大きな費用がかかる
新しいサービスや他のシステムとデータをやりとりできない
使う技術を扱える技術者が市場で見つかりにくい

これらは「リスク」と「機会損失」の2つに分けて考えると整理しやすくなります。サポート切れや担当者の不在は、障害が起きたときに復旧できないリスクです。改修の遅さや連携のしにくさは、事業の変化に追いつけない機会損失です。どちらが大きいかによって、モダナイゼーションの目的と優先順位が変わります。

主な問題	目的の置き方
サポート切れや故障への不安が大きい	安定稼働の確保を最優先にし、まずは動く環境を移す
改修が遅く、事業の変化に追いつけない	変更しやすい構造への作り替えを目的にする
他のシステムやデータ活用とつながらない	データの取り出しや連携の仕組みを先に整える

参考：DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～（本文）／経済産業省

モダナイゼーションの主な手法と違い

既存システムをクラウドなどへ移す際の手法の整理として、AWSは「7R」と呼ばれる7つの移行戦略を示しています。モダナイゼーション全般を考えるうえでも使いやすい整理なので、これをもとに各手法の違いを見ていきます。

手法	内容	変更の大きさ
リタイア（Retire）	ほとんど使われていない機能やシステムを廃止する	小さい
リテイン（Retain）	当面はいまの環境に残す	なし
リホスト（Rehost）	アプリケーションを変えずに、クラウドなど別の基盤に移す	小さい
リロケート（Relocate）	仮想環境などをまとめてクラウド上の同種の基盤に移す	小さい
リプラットフォーム（Replatform）	一部を調整し、データベースをマネージドサービスに移すなど基盤の利点を取り入れる	中程度
リパーチェス（Repurchase）	市販のパッケージやSaaSなど、別の製品に置き換える	大きい（業務の見直しをともなう）
リファクタ／リアーキテクト（Refactor）	クラウドの機能を活かせるよう、構造から作り替える	大きい

日本では、古い言語で書かれたプログラムを別の言語に書き換える「リライト」や、仕様を整理し直して一から作り直す「リビルド」といった言葉もよく使われます。名称は会社によって違うことがあるため、開発会社から提案を受けたときは、手法の名前ではなく「アプリケーションのどこを変え、どこを変えないのか」を確認するのが確実です。

なお、AWSは大規模な移行では、移行と同時に作り替えを行うリファクタは複雑で管理が難しいため、まずリホストやリプラットフォームなどで移行し、その後にモダナイズすることを推奨しています。「移す」と「作り替える」を分けて考えることは、規模の大小にかかわらず有効な考え方です。

参考：移行戦略について（AWS規範ガイダンス）／Amazon Web Services

自社に合う手法の選び方

手法の選択は、システム全体で一つに決める必要はありません。機能や業務ごとに、その部分の性質に合わせて手法を組み合わせるのが一般的です。判断の目安は次のとおりです。

その機能・業務の状態	向いている手法
ほとんど使われていない、または別の方法で代替できる	リタイア。移行の対象から外すだけで、全体の費用と期間が下がる
業務に合っていて変更も少ないが、基盤のサポート切れが迫っている	リホストやリプラットフォーム。まず安定した基盤に移す
どの会社でも似たような業務で、市販の製品で足りる	リパーチェス。業務の側を製品に合わせられるかが判断の分かれ目
事業の差別化に関わり、今後も頻繁に変更が必要	リファクタやリビルド。時間をかけても変更しやすい構造にする価値がある
当面は問題がなく、ほかに優先すべきものがある	リテイン。ただし見直しの時期を決めておく

最初に検討したいのは、リタイアできる機能がどれだけあるかです。長く使われているシステムには、過去の業務のために作られ、いまはほとんど使われていない機能が残っていることがよくあります。利用状況を確認し、使われていない機能を移行の対象から外すだけでも、モダナイゼーション全体の規模を小さくできます。

リパーチェスを選ぶ場合は、業務の側を製品に合わせる覚悟があるかどうかが分かれ目です。現行システムと同じ動きを製品のカスタマイズで再現しようとすると、費用がかさむうえに、製品のバージョンアップのたびに対応が必要になります。業務のやり方を変えられないなら、作り替えのほうが合っている可能性があります。

リファクタやリビルドは、効果が大きい反面、費用と期間、そして現行の仕様を正しく把握できるかというリスクをともないます。事業の中核を担い、今後も変化が見込まれる部分に絞って選ぶのが現実的です。

モダナイゼーションの進め方

モダナイゼーションは、一度にすべてを切り替えるより、段階的に進めるほうがリスクを抑えられます。一般的な流れは次のとおりです。

現状調査で、機能の一覧、利用状況、データ構造、外部連携、基盤のサポート期限を把握する
機能や業務ごとに、リタイア・リホスト・作り替えなどの手法を割り当てる
優先順位と移行の順番を決め、全体の計画と概算の費用を出す
影響の小さい部分から移行し、新旧のシステムを一定期間並行して動かす
データの移行と業務の切り替えを行い、旧システムの対象部分を停止する

最初の現状調査は、独立した契約として開発会社に依頼するのがおすすめです。現行システムの中身を見ないまま全体の見積もりを出すと、調査の段階で想定外の作り込みが見つかり、費用や期間が大きく変わる原因になります。調査の結果を見てから手法と予算を決めれば、計画の精度が上がります。

現状調査で把握したい項目は、技術面と業務面の両方にわたります。技術面では、プログラムの言語や規模、データベースの種類と容量、外部システムとの連携の方式、OSやミドルウェアのサポート期限を確認します。業務面では、機能ごとの利用頻度、利用している部署や人数、業務上の例外的な処理、システムの外で手作業により補っている作業を確認します。後者は利用者へのヒアリングでしか分からないことが多いため、調査の計画に業務担当者の時間を確保しておきましょう。

段階的な移行の方法としては、新しいシステムを少しずつ作り、機能ごとに旧システムから処理を移していくやり方がよく使われます。全体を一度に切り替える方法に比べて期間は長くなりますが、問題が起きたときの影響範囲を小さくでき、途中で計画を見直すこともできます。

データの移行は、モダナイゼーションのなかでも特に手間がかかる部分です。長年運用されたシステムのデータには、入力ルールの変更や過去の不具合によって、形式がそろっていないデータが含まれていることがよくあります。移行の本番より前に、実際のデータを使った移行のリハーサルを行い、件数や金額が一致するかを確認しておきましょう。

費用と予算の考え方

モダナイゼーションの費用は、選ぶ手法、システムの規模、現行の仕様がどれだけ把握できているか、データ移行の難しさによって大きく変わるため、一概に金額を示すことはできません。そのうえで、予算を考えるときに押さえておきたい点があります。

現状調査の費用は、全体の計画の精度を上げるための投資として別枠で確保する
新旧のシステムを並行して動かす期間は、両方の運用費用がかかる
データ移行とテストには、開発そのものと同じくらいの手間がかかることがある
移行後に、利用者への説明や業務手順の見直しにかかる社内の工数も見込む

予算の上限が決まっている場合は、手法の組み合わせで調整するのが現実的です。全体を作り替える予算がなければ、まず基盤の移行で安定稼働を確保し、作り替えは効果の大きい機能から年度ごとに進める、といった分け方ができます。段階を分けておけば、最初の段階の結果を見て次の投資を判断することもできます。

失敗しやすいポイントと対策

モダナイゼーションで起きやすい失敗と、その対策を整理します。

失敗のパターン	対策
「現行と同じ」を要件にして、不要な機能まで再現する	機能ごとに利用状況を確認し、使われていない機能は移行しない
現行の仕様が分からず、作り直した後に業務の漏れが見つかる	現状調査で業務担当者へのヒアリングを行い、例外的な処理も洗い出す
移行と大規模な作り替えを同時に行い、計画が長期化する	まず基盤を移し、作り替えは段階を分けて行う
新旧の切り替え時に業務が止まる	並行稼働の期間と、問題があったときに旧システムへ戻す手順を決めておく
新しいシステムがまた特定の会社にしか分からない状態になる	ソースコードとドキュメントの納品、権利の帰属を契約で押さえる

「現行と同じものを新しい技術で」という要件は、一見分かりやすいものの、失敗の原因になりやすい要件です。現行システムの仕様は、長年の改修の積み重ねで複雑になっており、すべてを正確に洗い出すこと自体が難しいからです。何を残し、何を変え、何を捨てるかを業務の側で決めることが、モダナイゼーションの成否を大きく左右します。

また、モダナイゼーションの目的は、新しいシステムを作ることではなく、今後も変化に対応し続けられる状態をつくることです。新しいシステムが再び特定の会社や担当者にしか分からない状態になれば、数年後に同じ問題が繰り返されます。ドキュメントの整備や、システムの全体像を説明できる社内担当者の確保も、計画の一部として考えておきましょう。

まとめ

レガシーシステムのモダナイゼーションは、全面的な作り直しだけを指すものではありません。廃止、そのままの移行、基盤の調整、製品への置き換え、構造からの作り替えといった手法を、機能や業務ごとに組み合わせて進めるものです。古いこと自体ではなく、リスクと機会損失のどちらが大きいかで目的と優先順位を決めることが出発点になります。

自社の状況によって、最初にやることは変わります。

状況	最初にやること
基盤のサポート期限が迫っている	期限を確認し、まず動く環境を移すことを優先する。作り替えはその後に検討する
改修の遅さや費用が問題になっている	改修が多い機能を特定し、その部分に絞って作り替えを検討する
何が問題なのかがはっきりしない	現状調査を独立した作業として依頼し、機能の利用状況とサポート期限を把握する

明日すぐにできることは、現行システムが動いているサーバーやOS、ミドルウェアの種類とサポート期限を調べ、あわせて普段使っている機能と使っていない機能を業務担当者に聞いてみることです。この2つが分かるだけでも、どこから手をつけるべきかの見通しが立ちます。