レガシーシステム更改の事例/成功事例について

レガシーシステムの更改は、保守期限から逆算して資産を棚卸しし、段階的に移行する順に進めると、業務を止めずに期限内の移行を目指せます。更改を迫る期限の性質と、メインフレームやサーバーの事例、成功に共通する進め方を取り上げます。全体像はレガシーシステム更改の完全ガイドもご覧ください。

▼全体ガイドの記事
・レガシーシステム更改の完全ガイド

レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。

保守期限・EOLが更改の引き金になる理由と事例を学ぶ意義

レガシーシステムの更改は、多くの場合、企業が望むタイミングではなく期限をきっかけに始まります。主な契機は、ハードウェアの保守契約の満了と、OS・データベース・ミドルウェアのサポート終了（EOL）です。

汎用機やオフコンなど専用機の製造・保守打ち切りも、更改を迫る要因です。期限は企業の都合に関係なく訪れるため、事例を読むときは、いつ着手したか、期限にどう間に合わせたかに目を向けると役立ちます。

EOL・保守期限という動かせない締め切り

更改の締め切りは、自社の都合で動かせません。保守契約が切れたハードウェアは、トラブル時に支援を受けにくく、業務停止につながるおそれがあります。

• ハードウェアの保守切れ：故障時の部品交換が難しくなります。
• OSやデータベースのEOL：セキュリティパッチの提供が止まります。
• 専用機の製造・保守終了：汎用機やオフコンの支援を受けられない状態です。

セキュリティ面では、脆弱性が残ったままの環境が続き、情報漏えいや監査指摘のリスクが高まります。とくに上場企業や金融・公共分野では、事実上看過できない問題になります。

経済産業省の「DXレポート」は、レガシーシステムを更新できなければ、2025年以降に年間最大12兆円の経済損失が生じると警告しています（出典：経済産業省 DXレポート）。「2025年の崖」は、ハードウェアやソフトウェアのサポート切れが集中することへの警鐘です。また、JUAS（日本情報システム・ユーザー協会）の調査では、約7割の企業がレガシー化を課題と認識しています（出典：JUAS）。

更改と刷新の違いと事例の読み方

事例を読むときは、更改と刷新の違いに加えて、どの方式が選ばれたかを確かめると理解が深まります。

• 刷新：業務そのものを作り直し、新たな価値の創出に重きを置きます。
• 更改：現在の業務をなるべく維持して、新基盤への期限内移行を優先します。機能追加や業務改革は後回しになることが多くあります。
• リホスト：基盤だけを新しくして、既存の資産はそのまま移す方式です。
• リプラットフォーム：OSやミドルウェアを新しい標準へ載せ替えて移行する形です。

期限対応の事例は、業種や規模ごとに紹介します。期限優先の更改は、なるべく業務を維持するぶん業務への影響を抑えられます。企業ごとの変更範囲に注目すると、自社の判断に役立ちます。

メインフレーム・COBOL基幹系の更改事例

メインフレームや汎用機上のCOBOL基幹系は、レガシーシステム更改の代表例です。ハードウェアの保守満了とCOBOL技術者の枯渇が重なると、待ったなしの判断を迫られます。ここでは、保守費の削減と処理性能の改善を両立させた事例を取り上げ、期限を優先した二段階の進め方も確認します。

製造業（従業員約1,200名）：汎用機保守満了を契機にした16ヶ月更改

従業員約1,200名の中堅製造業A社は、30年以上にわたりCOBOLの基幹系システムを汎用機で稼働させていました。ベンダーから通知を受けた保守契約の満了が、更改の直接のきっかけになりました。

期限を過ぎると部品交換も技術支援も受けられず、故障時には基幹業務が止まるリスクがありました。さらに、社内のCOBOL担当者も定年を迎えつつあり、技術者の枯渇も迫っていました。

1. 期限内の更改を始める出発点として、COBOLの各モジュールを棚卸しし、有効なロジックを残してデッドコードを除きます。
2. 業務要件を整理してJavaで再構築し、段階移行（ストラングラーパターン）を組み合わせます。
3. 在庫管理から切り替えて安定を確かめたのち、生産計画、販売管理へと順に移行します。

棚卸しの結果、移行対象は想定の約60%と判明しました。そのため、スコープと期限の見通しが改善しました。

プロジェクトは約16ヶ月で完了しました。夜間バッチ処理は、8時間から90分へ約80%短縮しました。

汎用機の年間保守費は、2,400万円から850万円へと約65%減りました。保守期限から逆算した計画が、予定どおりの完了につながりました。

期限優先でまずリホスト、その後に段階更改する考え方

保守期限まで余裕がない場合は、全面的な再構築を急がず、期限の回避とその後の改善を二段階に分けて進められます。

1. 第一段階では、既存の資産をなるべく変えずに新しいインフラへリホストし、保守切れのリスクを断ちます。
2. 第二段階では稼働を続けながら、リプラットフォームやリビルドを進めます。

この方法なら、切迫した期限を短期間かつ低リスクで回避しやすくなります。たとえば、あるサービス業の企業は、サポート終了まで半年しかないサーバーOS上の基幹システムを、まずクラウドへリホストしました。

この第一段階は、数百万円から1,000万円台、期間3〜6ヶ月で完了しています（出典：各社公開資料に基づく相場感）。このため、その後は機能改善を伴う本格更改を時間をかけて計画でき、期限に追われた拙速な作り直しを避けられました。期限が近いときは、まずリスクを抑えてから改善するのが有効な順序です。

サーバー・OS・データベースのEOL更改事例

サーバーOS、データベース、ミドルウェアのサポート終了（EOL）も、更改の契機になります。汎用機更改ほど大規模ではない一方で、対象システムが多数に分かれやすいため、優先順位付けと並行管理が成否を分けます。ここでは、機器の可視化と段階移行でEOLに対応した事例を紹介します。

大規模インフラ更改：機器の可視化で更新優先度を判断した事例

多数のサーバーやネットワーク機器を持つ企業では、各機器の保守期限を把握すること自体が難題になります。ユニリタの事例では、機器や通信ログのデータから利用実態を可視化しました（出典：ユニリタ）。

• ネットワーク機器：200種・30,000台を対象に集計しました。
• サーバー：10,000台の利用状況を把握しました。
• 通信ログ：1日あたり10億件を集計しました。

保守費の高い機器や利用実態の薄い機器を見つけ、限られた予算と期間で更改対象をデータに基づいて選べるようになりました。対象選定や保守機器管理の作業負担は約5分の1に軽減され、数億円規模の投資対効果が得られました。期限が迫る機器は、効果と期限をもとに優先度を付けると、過剰投資と更改漏れを防ぎやすくなります。

すべてを一度に更改せず、期限と効果の高いものから順に進める、ポートフォリオ的な考え方が有効です。

業務停止を避ける段階移行で並行稼働させた事例

EOL更改で避けたいのは、切り替え時のトラブルによる業務停止です。たとえば、基幹システムの障害でチルド商品の全品出荷が止まった製造・流通分野の失敗事例も報告されています（出典：各種公開報道）。

こうした教訓から、切り替えを段階的に進める段階移行が、現場の定石となっています。ある中堅企業は、データベースのサポート終了を機にこの方法を採りました。

1. 先に新環境を構築し、旧環境と並行稼働させます。
2. 同じ入力データで出力が一致するかを、数週間かけて検証します。
3. 差異を一つずつ解消し、業務部門が新環境に習熟する時間を確保してから旧環境を停止します。

期限から逆算して早めに着手し、検証期間を確保した結果、無停止で更改を完了しました。期限を起点に早く動くほど、リスクを抑えて着地できます。

更改事例から学ぶ成功の共通点

業種や規模を超えて事例に共通するのは、制約の多い更改を計画的に進め、業務を止めず、効果を測っている点です。ここでは、自社の更改を検討するときに使える判断の軸を取り上げます。

期限からの逆算と資産棚卸し

成功事例では、保守期限やEOLという動かせない締め切りから逆算し、最初に資産を棚卸しして計画を立てています。

• 移行範囲を絞る：生かす資産と廃止する資産を見極めます。
• 早く着手する：期限直前に全量を移すのは避け、棚卸し後に優先度の高い順で計画的に進めます。
• 期限に合う方式を選ぶ：再構築が間に合わなければ、リホストで期限を回避します。

A社は移行対象を想定の約60%に絞り、スコープと期間の見通しを改善しました。範囲を絞ることが、結果として最短ルートにつながります。

費用と期間は方式によって異なります。たとえば、要件定義と業務棚卸しのみなら200万〜500万円が目安です。また、クラウド移行型のリホストは数百万〜1,000万円台で3〜6ヶ月、業務を整理し直す再構築型は2,000万円規模以上で12〜18ヶ月以上が目安です（出典：各社公開資料に基づく相場感）。

効果の測り方と、業務を止めない進め方

A社では保守費が65%減り、バッチ処理が80%短縮しました。更改の効果は、こうした具体的な数値で測れます。

ユニリタの事例では作業負担が5分の1になり、数億円の投資対効果が得られました。こうした定量的な効果は、稟議や更改後の改善活動に役立ちます。

• 投資効果を示す：保守費を下げる効果は、経営上のリターンになります。
• 最重要原則は業務を止めないこと：段階移行や新旧並行稼働で一括切り替えのリスクを抑え、出荷停止を避けます。
• 検証期間を確保する：期限から逆算し、並行稼働の時間を設けます。

更改は守りの投資と見られがちですが、効果の数値と進め方を照らし合わせて、自社に合う計画を検討します。

まとめ

保守期限、OSやデータベースのEOL、汎用機の保守満了は、レガシーシステム更改の契機になります。事例では、メインフレーム・COBOL基幹系と、サーバー・データベースの更改を取り上げました。

A社は保守費を65%削減し、バッチ処理を80%短縮しました。また、ユニリタの事例では作業負担が5分の1となり、数億円の投資対効果が得られています。

更改事例から見ると、期限から逆算して資産棚卸しで範囲を絞り、段階移行と並行稼働で業務を止めずに進めることが、リスクを抑えて期限内の完了につながります。

自社のシステムが保守期限やEOLを迎える場合は、まず期限を起点に計画を立てます。riplaは、資産棚卸しから更改方式の選定、段階移行の設計まで、一貫して支援しています。

▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。