LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

レガシーシステムのモダナイゼーションとは

レガシーシステムのモダナイゼーションとは、老朽化・複雑化・ブラックボックス化した既存のITシステムを、現代の技術・アーキテクチャ・運用手法に刷新することで、ビジネスの俊敏性と維持コストの適正化を同時に実現する取り組みです。

「モダナイゼーション（modernization）」という言葉は広義であり、単純なサーバー移行（リホスト）から、アーキテクチャの再設計（リファクタ）、業務プロセスごと見直す再構築（リビルド）まで、手法は多岐にわたります。どの手法を選ぶかによって、プロジェクト期間・費用・リスクが大きく異なります。

IT資産が事業の中核を担う今日、老朽システムへの過度な依存は保守費の増大や障害リスクの上昇を招きます。モダナイゼーションは、そうした負の蓄積を解消しながら、変化への対応力を取り戻す投資として位置づけられています。

「2025年の崖」とモダナイゼーションが急務になった背景

経済産業省は2018年に公表した「DXレポート」の中で、レガシーシステム問題が放置されると日本全体で大規模な経済損失が生じると警鐘を鳴らしました。このリスクシナリオは「2025年の崖」として広く知られています^*1。

「2025年の崖」が注目された背景には、複数の要因が重なっています。まず、基幹系システムの多くが2025年前後にサポート終了を迎えるタイミングと、IT人材の大量退職（団塊世代）が重なることで、保守・運用の担い手が急減するリスクが指摘されました。加えて、既存システムの複雑さ・ブラックボックス化が進むほど、刷新に要する技術・費用・期間が増大します。

IPAが継続的に実施している「DX動向」調査（2024年版・2025年版）でも、レガシーシステム刷新はDX推進における主要テーマの一つとして毎年取り上げられています^*2。技術利活用の側面では「アジャイル活用」「データ利活用」「AI・生成AI」と並んで「レガシーシステム刷新」が調査項目に明示されており、企業の現場でこの課題が依然として継続的な経営課題であることを示しています。

「放置」という選択肢はコストゼロではありません。老朽システムを維持し続けることは、セキュリティリスクの蓄積・保守要員の高齢化・新機能追加の困難さという形で、じわじわと競争力を損ないます。

モダナイゼーションの7手法（7R）と費用特性

クラウド移行・システム刷新の文脈では、AWS（Amazon Web Services）が整理した「7R」フレームワークが参照点として広く活用されています。7Rとは、Rehost・Relocate・Replatform・Repurchase・Refactor/Re-architect・Retire・Retainの7つの移行戦略を指します^*3。

以下に各手法の概要と費用特性を整理します。同一組織・同一システムに対してどの手法を選ぶかは、業務要件・技術負債の深さ・許容できるダウンタイム・中長期的なIT戦略によって判断が分かれます。

実際のプロジェクトでは、一つのシステムに対して単一の手法だけを適用することはほとんどありません。機能モジュールごとに手法を組み合わせる「ポートフォリオアプローチ」が実務上の標準的な進め方です。たとえば、基幹トランザクション処理はリホストで早期移行し、頻繁に改修が入るフロントエンドはリファクタを適用するといった組み合わせが典型例として挙げられます。

費用構造の内訳：何にコストがかかるか

モダナイゼーションの費用は、大きく「初期費用」と「移行後の運用費用」に分かれます。初期費用が注目されがちですが、移行後のランニングコストを含めた総所有費用（TCO：Total Cost of Ownership）で評価することが重要です。

初期費用の主な構成要素

• 現状調査・設計費：資産棚卸し・依存関係分析・移行設計（アーキテクチャ検討）の費用。ドキュメントが整っていないほど大きくなります。
• 開発・改修費：手法によって大きく異なります。リホストは小さく、リファクタ・リビルドは大きくなります。
• データ移行費：既存データのクレンジング・変換・移行検証。データ品質が低いほど工数が増加します。
• テスト・検証費：移行後の業務検証・性能試験・セキュリティ検証など。
• プロジェクト管理費：PMO（プロジェクトマネジメントオフィス）・ベンダー調整・ステークホルダー対応。
• 教育・研修費：新システムへの移行に伴う操作研修・運用手順の習得。

移行後の運用費用

クラウド移行後はインフラの利用料（従量課金）が継続して発生します。SaaSへの切り替えの場合はライセンス費が定期的にかかります。

加えて、移行後しばらくの間は「旧システムと新システムの並行稼働費用」が発生します。並行期間が長引くほど総費用が膨らみます。並行稼働の終了タイミングを事前に計画しておくことが、費用コントロールの鍵の一つです。

費用の目安（市場参考値）

費用の相場はシステム規模・複雑さ・手法によって大きく異なるため、一次資料に基づく確定値の提示は困難です。ここでは市場でよく語られる参考レンジを、あくまで目安として示します（一次資料ではありません）。

• 小規模（部門システム・業務ツール）：数百万円〜数千万円規模が多い傾向があります。
• 中規模（基幹システムの一部）：数千万円〜1億円台の規模感が参照されます。
• 大規模（基幹系全体・グループ連携）：数億円〜十数億円を超えるケースがあります。

これらの数値は市場での参考値であり、実際の費用は個別の技術要件・スコープ・契約形態によって変動します。自社プロジェクトの見積もりは、専門ベンダーへの要件定義ヒアリングを経て取得することをお勧めします。

費用が膨らむ5つの要因と対策

モダナイゼーションプロジェクトは、当初見積もりから費用が大幅に超過するケースが少なくありません。費用超過には共通したパターンがあります。事前に要因を把握しておくことが、費用コントロールの出発点です。

要因1：ドキュメント不備によるスコープの拡大

既存システムの設計書・仕様書が最新の状態に保たれていない場合、現状調査に予想以上の工数がかかります。設計書と実際の動作が異なる「ドリフト（乖離）」が積み重なっていると、移行設計の前提が崩れ、手戻りが発生します。

対策としては、モダナイゼーション着手前に資産棚卸しとドキュメント整備を独立フェーズとして設定し、現状の可視化に時間を確保することが有効です。

要因2：データ品質の問題

長年にわたって蓄積されたデータには、重複・欠損・フォーマット不統一が生じているケースがあります。データ移行時のクレンジング工数は、データの品質状態によって大きく変動します。移行前にデータプロファイリングを実施し、クレンジング工数を事前に見積もることが重要です。

要因3：並行稼働期間の長期化

旧システムから新システムへの切り替えは、多くの場合で一定期間の並行稼働を伴います。並行稼働は移行リスクを低減する一方、旧システムの保守費と新システムの運用費を二重に負担する期間でもあります。並行稼働の終了条件と期限を契約・計画に明記しておくことで、コストの長期化を防ぎます。

要因4：要件変更・追加

プロジェクト途中での要件変更や機能追加は、開発・テスト工数を増加させます。特にステークホルダーが多い大規模プロジェクトでは、要件の確定に時間がかかる場合があります。変更管理プロセス（チェンジリクエスト手順）をプロジェクト開始前に合意しておくことで、スコープの際限ない拡大を抑制できます。

要因5：技術的負債の深さの過小評価

スパゲッティ化した依存関係・ハードコーディングされたビジネスルール・不明確な権限設計など、既存システムに蓄積された技術的負債は、表面上は見えにくいです。移行着手後に初めて全容が判明し、追加の解析・リファクタリング工数が発生することがあります。フィジビリティスタディ（実現可能性調査）を軽視せず、初期段階で概念実証（PoC）を行うことが費用超過リスクの低減につながります。

モダナイゼーションの進め方：フェーズ設計と優先順位

モダナイゼーションを「いきなり全体」で進めようとすると、プロジェクト規模が大きくなりすぎて失敗リスクが高まります。費用・リスク・効果のバランスを保ちながら進めるには、段階的なフェーズ設計が重要です。

フェーズ1：現状可視化とポートフォリオ分析

まずシステムポートフォリオ全体を可視化します。「ビジネス価値（重要度）」と「技術リスク（老朽度・保守困難さ）」の2軸でシステムをマッピングし、優先的に刷新すべき領域を特定します。この段階でポートフォリオ全体の方向性（各システムへの7Rの仮割り当て）を固めることで、全体費用の精度ある試算が可能になります。

フェーズ2：パイロット実施と知見蓄積

優先度の高いシステムの中から、リスクが小さく成果が見えやすいものをパイロット案件として選定します。小さな成功を早期に得ることで、プロジェクト全体のモメンタムを維持できます。また、パイロットで判明した技術課題・移行パターン・費用実績を次フェーズの見積もりに反映できます。

フェーズ3：コアシステムの段階移行

パイロットの知見をもとに、コアとなる基幹系システムの移行を進めます。一度にすべてを移行するのではなく、機能単位・業務フロー単位で区切り、移行完了を確認しながら進めることが推奨されます。各フェーズの完了基準（受け入れテストの合格条件、並行稼働終了条件）を事前に定義しておくことで、スコープクリープを防ぎます。

優先順位の考え方

「技術リスクが高い×ビジネス影響が小さい」システムは先に廃止（Retire）または移行し、技術負債を早期に解消することが費用の長期削減につながります。一方、「ビジネス影響が大きい×移行リスクが高い」システムはフェーズの後半に回し、前フェーズで得た移行ノウハウを活用しながら慎重に進めるアプローチが実務上よく取られます。

外注先・パートナー選定で確認すべき6つのポイント

モダナイゼーションは、社内のIT部門だけで完結させるのが難しいプロジェクトです。外部パートナーへの委託・協力を前提に検討する企業が大部分を占めます。パートナー選定で確認すべきポイントを6点まとめます。

1. 元請（プライムベンダー）としての一貫支援ができるか

モダナイゼーションは、現状調査・設計・開発・テスト・移行・運用定着まで、長期にわたる一貫した関与が求められます。複数のサブコンを束ねながらも、発注者に対して単一窓口で責任を持てる元請（プライムベンダー）体制を組めるか確認します。責任の所在が曖昧なマルチベンダー体制は、課題発生時の対応が遅れるリスクがあります。

2. 既存システムの業種・規模感に近い実績があるか

金融・製造・流通など、業種固有の業務ロジックや規制要件への対応経験は、プロジェクト設計の精度と移行リスクの低減に直結します。同規模・同業種のモダナイゼーション実績を確認し、参照事例の共有を求めることが有効です。

3. 技術スタックの幅と深さ

レガシーシステムに使われている技術（COBOLやRPGなどのメインフレーム系言語、古いミドルウェア等）の解析・移行経験と、移行先の最新技術（クラウドプラットフォーム、コンテナ、マイクロサービス等）の実装経験の両方を確認します。「読み解く力」と「作り直す力」の両方が必要です。

4. データ移行・品質管理の体制

前述の通り、データ品質は費用超過の主要因の一つです。データプロファイリング・クレンジング・移行検証の専門手順を持っているか、また移行後のデータ整合性を担保する品質管理体制があるかを確認します。

5. プロジェクト管理とコミュニケーション体制

大規模プロジェクトでは、進捗の可視化・変更管理・リスク管理のプロセスが費用コントロールに直結します。週次・月次でのステータスレポートの形式・頻度、エスカレーション経路、変更管理の手順について、契約前に確認・合意しておきましょう。

6. 移行後の運用・保守の継続性

移行プロジェクトの完了後も、システムの安定稼働・継続的な改善を支える運用保守体制が必要です。移行支援と運用保守を一貫して提供できるパートナーは、引き継ぎコストや知識の断絶リスクを低減できます。SLA（サービスレベル合意）の内容とインシデント対応時間も事前に確認することをお勧めします。

パートナー選定で「費用だけを基準にベンダーを選ぶ」という判断は、費用超過・品質問題・スケジュール遅延という形で後から大きなコストとなって戻ってくるリスクがあります。費用だけでなく、技術力・実績・体制・コミュニケーションを総合的に評価することが重要です。

まとめ：費用を適切にコントロールするための3つの判断軸

本稿では、レガシーシステムのモダナイゼーションについて、手法（7R）・費用構造・費用超過の要因・進め方・パートナー選定の観点から整理しました。要点を3つに集約すると次の通りです。

第一に、手法の選択が費用規模を決定します。リホスト（リフト＆シフト）は初期費用を抑えられますが、移行後の最適化費用が後から発生しやすい傾向があります。リファクタ・リビルドは初期投資が大きくなる一方、長期的な保守性・俊敏性の向上が期待できます。「費用だけで手法を選ぶ」のではなく、「何のために刷新するか」から逆算して手法を選ぶことが費用対効果を高めます。

第二に、費用超過の大部分は「見えていないリスク」に起因します。ドキュメント不備・データ品質・技術的負債の深さは、着手前の調査（フィジビリティスタディ・PoC）によって表面化させることができます。初期調査に時間とコストをかけることは、プロジェクト全体の費用を抑える投資です。

第三に、パートナー選定は費用だけで判断しないことが重要です。移行プロジェクトは長期にわたり、技術・業務・マネジメントの多面的な関与が求められます。元請（プライムベンダー）として一貫支援できる体制・実績・コミュニケーション能力を総合的に評価することが、プロジェクトの成否と費用コントロールに直結します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「DXレポート 〜ITシステム「2025年の崖」克服とDXの本格的な展開〜」（2018年9月7日公表）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「DX動向2025」（2025年6月26日公開）
3. *3　出典：AWS「AWS Prescriptive Guidance — Migration glossary（7 Rs）」

Tweet