レガシーシステムの更改を計画する際、最初につまずきやすいのが「どこまでを更改の対象範囲とし、どの機能を見直すべきか」という線引きです。更改は新規開発と違い、すでに稼働している膨大な機能群を相手にするため、すべてを一度に作り直すことは現実的ではありません。保守期限やEOLという期限に間に合わせるためには、移すべき機能・捨てるべき機能・新しい標準へ載せ替えるべき機能を冷静に仕分け、対象範囲を意図的に絞り込む作業が欠かせません。
本記事では、レガシーシステム更改で見直すべき機能・対象範囲を整理したうえで、更改の手法（リホスト・リプラットフォーム・リビルド・ハードウェア更改などの方式分類）をどう使い分けるかを具体的に解説します。対象範囲と手法をセットで理解することで、期限内に確実な更改を実現するための地図が描けます。なお、レガシーシステム更改の全体像・費用・進め方の体系についてはレガシーシステム更改の完全ガイドで解説していますので、あわせてご参照ください。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
レガシーシステム更改で見直すべき対象範囲の全体像
レガシーシステム更改の対象範囲は、単に「古いプログラムを新しく書き直す」という話にとどまりません。アプリケーションのロジック、データベース、インフラ基盤、外部システムとの連携、運用・バッチ処理といった複数の層が絡み合っており、それぞれに「見直すべきかどうか」の判断が必要です。期限から逆算して対象範囲を絞るには、まずこの全体像を層ごとに把握することが出発点になります。
インフラ・アプリ・データ・連携の四層で対象を捉える
更改の対象範囲は、大きく四つの層で捉えると整理しやすくなります。第一はインフラ層で、メインフレームや汎用機、保守期限が迫るサーバーやストレージ、ネットワーク機器が含まれます。第二はアプリケーション層で、COBOLなどで書かれた業務ロジックやバッチ処理です。第三はデータ層で、独自形式のファイルや古いデータベースに蓄積された業務データです。第四は連携層で、他システムや外部サービスとのインターフェース、帳票やEDIなどの入出力です。
EOLや保守期限が引き金の更改では、まずインフラ層が更改の起点になります。サーバーやOSのサポートが切れる場合、その上で動くアプリケーションやデータも連動して移す必要が出てくるためです。逆に言えば、どの層に期限が来ているかを特定すれば、最小限どこまでを対象範囲に含めればよいかが見えてきます。期限が来ているのがインフラ層だけなら、アプリは極力そのまま移すリホストで対応範囲を狭められる、といった判断ができるようになります。
注意したいのは、層と層がつながっている境界部分です。アプリケーションが特定OSのバージョンや古いミドルウェアの仕様に依存している場合、インフラだけを新しくしても正しく動かないことがあります。データ層も同様で、独自形式のファイルを前提に作られたバッチは、データベースを移し替えた途端に動かなくなることがあります。対象範囲を四層で捉えたうえで、それぞれの境界に潜む依存関係まで洗い出しておくことが、更改後の不具合を防ぐ前提になります。
残す機能・捨てる機能・載せ替える機能の三分類
対象範囲を絞り込むうえで有効なのが、既存機能を「残す・捨てる・載せ替える」の三つに仕分ける考え方です。残すのは、現在も業務に不可欠で要件が変わっていない機能です。捨てるのは、長年の改修で積み上がったものの実際にはもう使われていないデッドコードや、廃止された業務プロセスを処理しているだけの機能です。載せ替えるのは、業務的には必要でも実装が古く、新しい標準に置き換えるべき機能です。
この仕分けの効果は大きく、実際にある製造業の更改では資産棚卸しの結果、移行が必要なプログラムが想定の約60%にまで絞り込めた例があります（出典：各社公開資料に基づく相場感）。残り40%はデッドコードや不要機能だったということです。更改の対象範囲をこの三分類で見直すだけで、コスト・期間・リスクのすべてを圧縮できます。
仕分けの際に判断が難しいのが「載せ替える」に分類される機能です。業務的には必要でも実装が古い機能は、今回の更改で新しい標準に置き換えるべきか、それとも基盤だけ移して次サイクルで作り直すかという選択を迫られます。ここで効いてくるのが期限の概念です。期限まで余裕がなければ、まずはそのまま移して期限を回避し、改善は後回しにする。期限に余裕があれば、この機会に標準的な作りへ載せ替える。同じ「載せ替える」機能でも、期限との兼ね合いで適用する手法が変わってくるのです。次章では、こうして絞り込んだ対象に対し、どの手法を適用するかを解説します。
更改の手法一覧：7Rとハードウェア更改の使い分け
更改の対象範囲が見えたら、次は各機能をどの手法で移すかを決めます。代表的なフレームワークがAWSの提唱する「7R」と、IPAによる4分類です。これらは「どこまで作り変えるか」のグラデーションを表しており、期限と予算に応じて使い分けることが、更改成功の核心になります。
7R（リホスト・リプラットフォーム・リファクタなど）の定義
AWSの「7R」は、Rehost（リホスト）、Relocate（リロケート）、Replatform（リプラットフォーム）、Repurchase（リパーチェス）、Refactor（リファクタ）、Retire（リタイア）、Retain（リテイン）の7つを指します（出典：AWS）。それぞれを更改の文脈で整理すると次のようになります。
・Rehost：アプリをほぼそのまま新しい基盤へ移す。最も速く期限回避に向く
・Relocate：仮想化環境ごと別基盤へ移す。構成を変えずに移動する
・Replatform：OSやミドルウェアを新しい標準へ載せ替える。一部最適化を伴う
・Repurchase：自社開発をやめてパッケージやSaaSへ切り替える
・Refactor：内部構造を作り変えて保守性を高める。工数は大きい
・Retire：使われていない機能を廃止する。対象範囲を縮小できる
・Retain：当面そのまま残し、次の更改サイクルに回す
更改で特に出番が多いのは、上から数えてRehost・Replatformです。これらは業務ロジックを大きく変えずに基盤だけを新しくできるため、保守期限やEOLという期限を最短で回避するのに適しています。一方でRefactorやRepurchaseは効果が大きい反面、期間と費用がかさむため、期限に余裕がある機能や次サイクルに回せる機能に適用するのが現実的です。
IPAの4分類とハードウェア更改の位置づけ
IPA（情報処理推進機構）は、レガシー更改の手法を「リビルド・リライト・リホスト・ハードウェア更改」の4分類で整理しています（出典：IPA）。リビルドは要件を整理し直して作り直す方式、リライトは既存ロジックを別言語へ自動・半自動で変換する方式、リホストはアプリをそのまま新基盤へ移す方式です。そして4つ目の「ハードウェア更改」が、保守期限・EOL契機の更改で重要な選択肢になります。
ハードウェア更改は、アプリケーションには手を入れず、保守切れとなる機器だけを後継機や同等環境へ置き換える方式です。業務影響が最も小さく、期限回避を最優先する場面で選ばれます。ただし、これは根本的なレガシー脱却にはならず、ブラックボックス化や技術者枯渇という課題は残ります。そのため実務では、まずハードウェア更改やリホストで差し迫った期限を回避し、その後にリプラットフォームやリビルドで段階的に本格更改を進めるという二段構えが定石です。手法は単独で選ぶのではなく、期限の近い機能には軽い手法、時間が取れる機能には重い手法という組み合わせで使い分けることが肝要です。
費用と期間の目安も、手法選択の判断材料になります。クラウド移行型のリホストは数百万〜1,000万円台で3〜6ヶ月程度、業務を整理し直す再構築型は2,000万円規模以上で12〜18ヶ月以上が一つの相場とされます（出典：各社公開資料に基づく相場感）。単一業務システムの更改全体では3,000万〜1.5億円、基幹と複数の周辺システムを含む場合は1.5億〜5億円規模に及ぶこともあります。期限から逆算して再構築が間に合わないと判断できれば、まず軽い手法で期限を回避し、本格的な更改は次サイクルへ回すという現実的な意思決定ができます。手法・費用・期間をセットで把握しておくことが、更改計画の精度を高めます。
更改時に必ず見直すべき機能・領域
手法を使い分ける前提として、更改では特に注意して見直すべき機能・領域があります。基盤だけを移せばよいと油断していると、移行後に思わぬ不具合が出る箇所です。ここでは更改で見落とされがちな三つの重点領域を解説します。
夜間バッチ・帳票・外部連携インターフェース
更改で最も見直しが必要なのは、夜間バッチ処理と帳票、そして外部システムとの連携インターフェースです。これらは長年の運用で複雑化していることが多く、しかも特定のハードウェアやOSの挙動に依存している場合があります。基盤を移した途端に処理時間が変わったり、文字コードや改行コードの違いで帳票が崩れたりする事故は、更改の現場で繰り返し起きています。バッチの処理順序やタイミング依存、他システムとのデータ受け渡し形式は、更改対象として丁寧に検証すべき領域です。
逆に、ここを見直すことで大きな改善につながることもあります。前述の製造業の更改では、汎用機上で8時間かかっていた夜間バッチが、更改後には90分へと約80%短縮されました（出典：各社公開資料に基づく相場感）。古い基盤の制約で長時間化していた処理が、新しい基盤では劇的に速くなることは珍しくありません。バッチや連携は「単に動けばよい」ではなく、更改を機に処理性能や運用負荷を見直す絶好の対象でもあります。
データ形式・セキュリティ・運用保守の機能
二つ目の重点領域はデータ形式です。レガシーシステムは独自形式のファイルや古い文字コードでデータを保持していることが多く、新しいデータベースへ移す際には変換とマッピングが必要になります。ここを軽視すると、桁あふれや文字化け、日付フォーマットの不整合といった問題が移行後に表面化します。更改の対象範囲を決める段階で、どのデータをどう変換するかを早めに洗い出しておくことが重要です。
三つ目はセキュリティと運用保守の機能です。EOLを迎えたOSやミドルウェアはセキュリティパッチが提供されなくなるため、更改ではこの脆弱性を解消することが大きな目的になります。あわせて、監視・ログ取得・バックアップ・権限管理といった運用機能も、新しい基盤の標準的な仕組みへ置き換えることが望ましい領域です。古いシステムでは属人的な手作業に頼っていた運用が、更改を機に標準化・自動化できると、運用負荷とリスクの双方を下げられます。対象範囲を見直す際は、こうした「縁の下の機能」も忘れずにリストへ含めることが、更改後の安定稼働につながります。
大量の機器やシステムを抱える環境では、これらの機能を一つずつ手作業で洗い出すのは現実的ではありません。ユニリタの事例のように、200種・30,000台のネットワーク機器や10,000台のサーバーから通信ログを集計し、保守費の高い機器や利用実態を可視化することで、見直すべき対象を客観的なデータから特定する手法もあります（出典：ユニリタ）。この取り組みでは作業負担が約5分の1に軽減され、数億円規模の投資対効果が得られています。対象範囲が広いほど、感覚ではなくデータに基づいて見直すべき機能を絞り込む姿勢が、更改の精度を高めます。
まとめ
本記事では、レガシーシステム更改で見直すべき対象範囲を「インフラ・アプリ・データ・連携」の四層と「残す・捨てる・載せ替える」の三分類で整理し、更改の手法として7RとIPAの4分類、特にリホスト・リプラットフォーム・ハードウェア更改の使い分けを解説しました。さらに、更改で見落とされがちな夜間バッチ・帳票・外部連携・データ形式・セキュリティ・運用保守といった重点領域を取り上げました。
更改の成否は、対象範囲を意図的に絞り込めるかどうかにかかっています。期限が来ている層を特定し、残す・捨てる・載せ替えるを仕分け、期限の近い機能には軽い手法、時間が取れる機能には重い手法を当てる——この組み合わせの設計こそが、期限内に確実な更改を実現する鍵です。riplaでは、現行システムの資産棚卸しから対象範囲の見極め、手法の選定までを一気通貫で支援しています。どこから手をつけるべきか迷っている段階でも、まずは現状の機能と期限を整理するところからご相談ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。