見直す対象は、プログラムやデータ、バッチ、外部連携、運用などの7分類です。資産ごとに棚卸しし、刷新手法を選ぶことが成功の鍵です。
刷新全体の進め方や工程管理は、レガシーシステム刷新の完全ガイドをご覧ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム刷新で見直すべき対象範囲の全体像（資産の7分類）
刷新の対象は、プログラムに限りません。資産名に加えて、依存関係や運用条件も整理しておくと、対象範囲の抜けに気づきやすくなります。
棚卸しでは、次の4つの観点をあわせて確認します。
- アプリとデータ：言語・モジュール依存、文字コード・DB形式・データ量
- 実行基盤と処理：OS・ミドルウェア、バッチ・ジョブの依存関係
- 接続と品質条件：連携先・プロトコル、性能・可用性・セキュリティ要件
- 運用と知識：担当体制、障害対応・年次処理の暗黙知
(1) プログラム資産（言語・フレームワーク）
プログラム資産は、最も直接的な見直し対象です。COBOL・PL/I・RPGのように保守人材が減りつつある言語で書かれたアプリケーションのほか、VB6やDelphiなど、現代のIDE・クラウドに対応していない言語資産も対象になります。
棚卸しでは、ソースコードの本数や行数だけでなく、モジュール間の依存関係・循環参照・デッドコードの有無まで確認することが欠かせません。富士通の「ソフトウェア地図」のように、アプリ資産の複雑度や依存関係を把握できるツールを使うと、リファクタリングの優先度や刷新コストを精度高く見積もれます。
(2) データ資産（マスタ・トランザクション・文字コード）
データ資産の棚卸しは、プログラム資産と同等かそれ以上に重要です。メインフレーム環境ではEBCDIC文字コードが使われており、UTF-8やShift-JISの環境へ移行すると、文字化けや桁落ちが起きるおそれがあります。
特に全角カナ・旧字体・機種依存文字を含むマスタデータは、移行前に徹底したクレンジングが必要です。また、トランザクションデータの保有期間・件数・増加傾向を把握すると、クラウドDBの選定やパーティショニング設計に直結します。
データベース方式がIMS（階層型）やIDMS（ネットワーク型）の場合は、リレーショナル・NoSQLへの論理設計変換も対象範囲に含まれます。
(3) バッチ処理・ジョブ運用
基幹系のレガシーシステムでは、夜間バッチが業務の根幹を担っているケースが大半です。JCL（Job Control Language）で定義された何百本ものジョブが複雑な依存関係で連鎖しており、ドキュメントが整っていないことも珍しくありません。
刷新時にはジョブスケジューラの棚卸し・依存関係マップの作成・処理の並列化余地の検討が必要になります。
クラウド化する場合は、AWS Batch・Azure Data Factory・GCPのCloud Composerなどへの置換が候補になります。ジョブスケジューラ製品（JP1・Hitachi JP1など）も、使い続けるか刷新するかを判断の対象に含めます。
(4) ハードウェア・汎用機・OS・ミドルウェア
メインフレーム（IBM System z等）、オフコン（NECのACOS、富士通のGS21等）、UNIXサーバーは、EOL（サポート終了）を迎えると、ハードウェア更改の主な契機になります。棚卸しでは、現行機のEOL時期・保守ベンダーの継続可否・仮想化対応状況を確認します。
OSは、z/OS・HP-UX・TruUNIX64など特定ベンダーへの依存が多く、Linuxへの移行検討が一般的です。また、ミドルウェアにはTPモニタ（CICS・IMS TM等）、メッセージングミドルウェア、プリンタスプーラなども含まれ、廃止になった場合の代替手段の検討まで対象範囲に含めます。
(5) 外部連携・周辺システム
基幹システムは、EDI・FTP・固定長テキスト連携などの旧式プロトコルで、周辺システムと密に結びついているケースが多くあります。棚卸しでは、連携先システムの数・プロトコル・データフォーマット・連携タイミング（リアルタイム/バッチ）を一覧にします。
刷新対象の基幹システムをAPIに切り替えると、連携先のシステムも改修が必要になります。そのため、外部連携の影響範囲は、必ず刷新計画に含めなければなりません。
特にEDIは、取引先との標準仕様（JEDICXや個社EDI）への対応を確認する必要があります。また、SaaSへの切り替えも選択肢として検討します。
(6) 非機能要件（性能・可用性・セキュリティ）
レガシーシステムでは、非機能要件が暗黙の前提として積み重なっており、刷新後に「以前はできていたのに」という問題が起きがちです。棚卸しの対象には、ピーク時のトランザクション数・バッチ処理の時間枠制約・RTO/RPO・セキュリティパッチ適用ポリシーなどがあります。
メインフレームは高信頼性を前提とした設計になっています。そのため、クラウドへ移行する際は、可用性ゾーンの設計とフェイルオーバーの設定で、同等以上の信頼性を確保することが求められます。
暗号化方式・認証方式・アクセスログの取り方も、現行の基準（PCI DSS・ISO27001等）に合わせて見直す必要があります。
(7) 運用・保守体制と属人化したノウハウ
最後に、非常に重要な棚卸し対象として「人的資産」があります。COBOLやJCLを読み解けるエンジニアは年々減っており、特定の担当者しか知らない業務ロジック・障害対応手順・年次処理のノウハウが、文書化されないまま放置されているケースが多くあります。
刷新の対象範囲に「暗黙知の文書化・移転」を明示的に含め、ヒアリング調査やリバースエンジニアリングで要件を明らかにする工程を、計画に組み込む必要があります。
運用体制についても、ITILベースの運用設計への移行や、DevOpsを前提とした新しい組織・プロセスへの切り替えを、検討範囲に含めます。
刷新手法の一覧と各対象範囲への当て方（7R・IPA4分類）
対象範囲の棚卸しが完了したら、次は「各対象にどの刷新手法を適用するか」を決定します。現在、刷新手法の体系として最も広く参照されているのは、AWSの7R（7つの移行戦略）とIPAの4分類です。
それぞれの手法が「どのレガシー資産・どの状況に向くか」を理解すると、プロジェクト計画の精度が大きく上がります。
AWSの7Rと対象範囲別の適用指針
AWSが定義した7Rは、クラウド移行時の戦略選択に使われる7つのアプローチです。ここでは、それぞれの手法を、先に整理した7分類の対象範囲と結びつけて示します。
- Rehost（リホスト）：リフト＆シフトで、アプリやOSをほぼそのまま移す
- Relocate（再配置）：インフラレベルで、ワークロードを再配置する
- Replatform（リプラットフォーム）：一部の基盤を最適化し、アプリは大きく変えない
Rehostでは、移行先として仮想マシンやクラウドIaaSを選びます。変更コストは最小限で済む一方、レガシー構造はそのまま残ります。対象: ハードウェア（汎用機のEOL対応）・OS移行に向きます。COBOLアプリをLinux上のCOBOLランタイムでそのまま動かす構成も、広い意味でのリホストに含まれます。
Relocateでは、VMwareのワークロードをVMware Cloud on AWSなどへ移します。対象: ハードウェア・ミドルウェアの延命に適しています。Replatformでは、データベースをRDS managed serviceに切り替えます。対象: データ資産（DBエンジン切替）・ミドルウェア（TPモニタのAPIゲートウェイ化）などに向きます。
- Repurchase（リパーチェス）：既存のカスタムシステムを、SaaS製品に置き換える
- Refactor（リファクタ）：アーキテクチャを根本から見直す
- Retire（廃止）：使われていない機能やシステムを廃止する
- Retain（現状維持）：刷新の対象から外す
Repurchaseは、対象: 外部連携（EDI SaaS化）・周辺業務系（HR・会計・CRM）の刷新に最も適しています。Refactorは、マイクロサービス化やクラウドネイティブ化を図る手法です。対象: プログラム資産（COBOLのJava/Pythonへの書き換え）・バッチ処理のAPI・イベント駆動化に向く、7Rの中で最も変革度が高い手法です。
Retireは、対象: プログラム資産のデッドコード・廃止業務システムが該当します。棚卸しで見つかった不要な機能にこの手法を積極的に当てれば、全体コストを圧縮できます。
Retainは、コンプライアンス上の理由がある資産や、刷新コストに対して効果が低い資産を、意図的に現状維持とする判断です。対象: 非機能要件を満たしている安定稼働中の補助システムが典型例です。
IPAの4分類と対象範囲への当て方
IPAは、国内の基幹系レガシーを念頭に、刷新手法を4つに分類しています。7Rと重なる部分もありますが、日本のメインフレームやオフコン環境により即した分類です。
- リビルド：現行システムの機能仕様を維持しつつ、新技術・新アーキテクチャで全面再構築する手法
- リライト：ソースコードのレベルで、自動変換ツールなどを使って言語やプラットフォームを切り替える
- リホスト：7RのRehost・Relocateに当たり、移設が主目的の場合に選ばれます
- ハードウェア更改：汎用機やオフコンを、新しいハードウェアや汎用サーバー、仮想化基盤に置き換える
リビルドは、7RのRefactorに近く、COBOLアプリをJavaや.NETで書き直す場合がこれに当たります。対象: プログラム資産・バッチ処理・データ資産の論理設計変換に適しています。変革度が最も高く、コスト・期間も最大規模となります。
リライトは、たとえばCOBOLからJavaへの自動変換ツール（Micro FocusのEnterprise Analyzerなど）を使えば、機能ロジックを保ったままコードを変換できます。対象: プログラム資産（言語変換）が主な対象で、バッチロジックの保持が重要な場合に選ばれます。
リホストは、アプリに手を加えないため最短期間での移行が可能です。ただし、構造的な負債は温存されます。
ハードウェア更改は、対象: ハードウェア・OSに限った最小限の変更で、アプリやデータ構造は維持します。EOL対応の緊急措置として選ばれることが多いです。
対象範囲×手法の選択マトリクス（整理）
対象範囲ごとに適用しやすい手法を、次のとおり整理します。
- プログラム・データ：Refactor・Retire・Replatformが候補で、DBの刷新はReplatform、論理設計の変更はRefactorです。
- バッチ・運用：ジョブのクラウド化はRefactor・Replatform、ノウハウの移行ではRetainも候補です。
- 基盤・非機能：ハードウェアやOSはRehost・Relocate、可用性やセキュリティはRefactor・Replatformを検討します。
- 外部連携：SaaS化はRepurchase、API化はReplatform、不要になったものはRetireです。
手法別の費用・期間とポートフォリオアプローチ
刷新手法を選ぶときは、費用と期間の目安が重要な判断材料になります。しかし、実際のレガシーシステム刷新では、単一の手法だけで完結することはほとんどなく、対象資産ごとに異なる手法を組み合わせる「ポートフォリオアプローチ」が求められます。
手法別の費用・期間目安
手法ごとの費用・期間の概算は、次のとおりです。ただし、実際のプロジェクトコストは、システム規模・複雑度・並行稼働期間などによって大きく変わります。
- クラウド移行型（Rehost・Relocate・ハードウェア更改）
費用目安: 数百万〜1,000万円台
期間目安: 3〜6ヶ月 - 再構築型（Refactor・リビルド・リライト）
費用目安: 2,000万〜数千万円規模
期間目安: 12〜18ヶ月以上 - 小〜中規模（単一業務システム）の刷新
費用目安: 3,000万〜1.5億円
期間目安: 6〜18ヶ月 - 中〜大規模（基幹＋複数周辺）の全面刷新
費用目安: 1.5億〜5億円
期間目安: 18ヶ月〜5年
クラウド移行型は、アプリを変更しないため、コストは最小限で期間も最短です。ただし、構造的な負債は残り、将来的に再刷新が必要になる可能性があります。
再構築型は、変革度が最も大きく、技術的負債の根本的な解消につながります。一方、要件定義・設計工程が長く、SI費用が全体の60〜75%を占めるのが一般的です。大規模の場合は、費用が1.5億〜5億円超、期間が3〜5年になります。
小〜中規模は、周辺系・サブシステムの刷新に多いパターンです。SaaS置換（Repurchase）や一部のReplatformが選ばれることが多くなります。
中〜大規模は、対象範囲が広いため、ポートフォリオアプローチによる段階的な刷新が不可欠です。全工程を一括（ビッグバン）で完了させようとすると、リリース直前の障害や手戻りのリスクが極めて高くなります。
ポートフォリオアプローチの重要性
ポートフォリオアプローチとは、全資産に同じ刷新手法を一律に当てはめるのではなく、各対象資産の重要度・複雑度・コスト対効果に応じて最適な手法を個別に割り当てる考え方です。
例えば同じ基幹システムでも、会計モジュールはRefactor（リビルド）、帳票出力はRepurchase（SaaS化）、旧式EDI連携はRetire（廃止）と、資産ごとに手法を分けることがあります。人事マスタのみReplatformとする組み合わせが、現実的な解になることが多いです。
ポートフォリオアプローチを実践するうえで重要なのが、ストラングラーパターン（Strangler Fig Pattern）の採用です。ストラングラーパターンとは、一度にシステム全体を切り替える「ビッグバン移行」を避け、機能単位で新旧システムを並行稼働させながら、古い機能を新システムへ段階的に置き換える手法です。
オーダー管理の新システムを先行稼働させ、在庫管理・出荷管理・請求管理を順次移行することで、各ステップのリスクを限定できます。
ポートフォリオアプローチでは、棚卸しから移行計画まで、次の順に進めます。
- 対象資産を棚卸しし、そのうえで刷新手法を選ぶ。
- ビジネス価値と技術的負債を評価し、優先順位を決める。
- 段階移行の各フェーズに、スコープ、判断ゲート、ロールバック条件を定める。
対象範囲の定義精度を上げるための実践ポイント
対象範囲の棚卸し精度を高めるには、実務で有効とされる方法がいくつかあります。まずは、ドキュメントのリバースエンジニアリングです。既存のドキュメントが乏しい場合は、富士通の「ソフトウェア地図」のようなツールで、ソースコード・JCL・DB定義から依存関係マップを自動生成できます。その結果、調査工数を大幅に削減できます。
次に、現場ヒアリングによる暗黙知の掘り起こしです。COBOLエンジニアや業務担当者へのインタビューを構造化し、「障害が起きたときにどう対応しているか」「年次処理で特に気をつけている点は何か」などを尋ねて、ドキュメントに現れない運用知識を吸い上げます。この工程を省くと、刷新後に不可解な障害が頻発する原因になります。
さらに、インベントリシートの整備も有効です。対象システム・モジュール・連携先・データフロー・担当者・EOL情報をスプレッドシートにまとめ、プロジェクト関係者がいつでも参照できる状態にします。このインベントリが、後工程の手法選択・工数見積もり・テスト計画の土台となります。
まとめ：対象範囲の棚卸しが刷新成功の鍵
レガシーシステム刷新で見直すべき対象範囲は、7分類に整理しました。そのうち3つは、プログラム資産・データ資産・バッチ処理です。
残る4つは、ハードウェア・外部連携・非機能要件・運用ノウハウです。そのうえで、7R（Rehost/Relocate/Replatform/Repurchase/Refactor/Retire/Retain）を、「どの対象範囲にどの手法を当てるか」という視点から見てきました。IPAの4分類（リビルド/リライト/リホスト/ハードウェア更改）も、同じ視点で整理しました。
費用・期間の目安と、ポートフォリオアプローチ・ストラングラーパターンの重要性についても説明しました。
レガシーシステム刷新で失敗を避けるうえで最も大切なのは、「手法を先に決めない」ことです。先に手法（クラウド移行や全面再構築）を決めてから対象範囲を当てはめると、資産の実態に合わない計画が生まれ、手戻りや予算超過につながります。
正しい順序は、まず対象資産を7分類で棚卸しし、各資産のビジネス価値・技術的負債の深刻度・移行コストを評価したうえで、最適な手法を割り当てていくことです。この「対象範囲起点の考え方」こそが、2025年の崖（年間最大12兆円の経済損失リスク）を乗り越えるための実務的なアプローチといえます。
COBOLや汎用機・EBCDICデータといったレガシー固有の課題は、一般的なシステム移行とは異なる専門知識と経験を要します。そのため、刷新プロジェクトの計画立案から対象範囲の棚卸し、手法選択、ポートフォリオ策定まで、経験豊富なパートナーとともに進めることを強くおすすめします。
開発を相談する前に、次の無料ホワイトペーパーをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。