レガシーシステムの刷新は、現行システムの棚卸しと目標設定から始め、PoCで小さく試したうえで、データ移行と並行稼働を経て本番に移すのが基本の流れです。
先送りのツケは年々膨らみます。COBOL人材の退職、ハードウェア保守終了（EOS）、セキュリティリスクの増大、保守コストの高騰などがその代表例で、先送りするほどリスクは膨らむため、早めに全体像をつかんでおくことが大切です。
より広い論点は、以下の完全ガイドにまとめています。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
システム刷新の定義と今取り組む理由
システム刷新とは、老朽化した既存システムを新しい技術基盤へ移し、事業の成長に耐えられる形に作り変える取り組みです。単なる作り直しではなく、業務プロセスの見直しやデータ構造の最適化、クラウドネイティブ化までを含む包括的な変革にあたります。
刷新を先送りするほど、ブラックボックス化と属人化は進みます。いざ着手する段階になって「仕様を知る人がもういない」という事態に陥りやすくなります。
レガシーシステムの定義と「2025年の崖」の本当の意味
レガシーは古いだけのシステムではありません。経済産業省の定義では、技術的負債が蓄積してブラックボックス化していること、ビジネスの変化に追随できないこと、保守運用に過度なコストがかかることの3点がそろったシステムを指します。COBOLやPL/Iのメインフレーム系に限らず、10年以上前に作られたVB6のクライアントサーバーシステムや、サポート切れのOracle Formsも広義のレガシーに含まれます。
「2025年の崖」は経済産業省のDXレポートで広まった言葉ですが、2025年に何かが起きるという話ではありません。この時期を過ぎても刷新に着手できていない企業は、年間最大12兆円の機会損失リスクに晒される、という警鐘です。2026年現在、この崖は既に現実となり、COBOLエンジニアの平均年齢は55歳を超えて、5年以内に大半が引退します。
加えて深刻なのが、ハードウェア保守の打ち切りです。IBMメインフレームの一部機種や、富士通・日立のオフコンは既に保守終了が公表されており、障害が起きても部品の供給が止まります。ここで焦って着手すると、ベンダーに足元を見られ、通常の2〜3倍の見積もりを提示される事例も散見されます。
放置した場合の具体的リスクと保守コストの実態
刷新を放置した場合の最大のリスクは、セキュリティインシデントの発生確率が指数関数的に高まることです。サポート切れのOSやミドルウェアを使い続けると、ゼロデイ脆弱性に対応できなくなり、ランサムウェア被害の温床になります。2024年以降に大手製造業やインフラ企業で起きた大型インシデントの多くは、レガシーシステムの脆弱性が起点でした。
保守コストの実態も深刻です。一般的に年間保守費用は初期開発費の15〜20%が目安とされますが、レガシー化が進むと25〜30%まで跳ね上がります。さらに、「保守時間達成率」で見ると、月50時間の契約に対して実稼働は10時間程度というケースが多く、達成率20%の過大な支払いが常態化している企業も少なくありません。
また、機会損失の観点も見逃せません。レガシーシステムではAPI連携やリアルタイムのデータ活用ができず、DX施策の土台としても機能しません。競合がSaaSと生成AIを組み合わせて業務効率を倍増させている中で、自社だけが手作業のExcel集計に追われる状況は、採用市場でも大きなマイナス要因になります。
システム刷新の手法の比較（7Rフレームワーク）
AWSが提唱する「7Rフレームワーク」では、7つの手法のうち、既存システムを残す・やめる・移すという3つの選択肢が先頭に並びます。
- リテイン（現状維持）
- リタイア（廃止）
- リロケート（移設）
続いて、リホスト（IaaS移行）、リプラットフォーム（一部最適化）、リファクタリング（再設計）があり、最後にリパーチェス（SaaS買替）が加わります。それぞれコスト、リスク、得られる効果が異なるため、システム特性や経営目標に照らして最適解を選ぶ必要があります。
リホスト・リプラットフォーム：最短最安の選択肢
リホストは「リフト&シフト」とも呼ばれ、オンプレミスのサーバーをAWS EC2やAzure VMといったクラウドのIaaSに、そのまま移す手法です。アプリケーションのソースコードには手を入れないため、最短3〜6ヶ月で済み、コストも刷新の中では最も低く抑えられます。
ただし、クラウドの料金は従量課金のため、チューニングを怠ると「オンプレ時代より月額費用が高くなる」という典型的な失敗に陥ります。
リプラットフォームは、OSやミドルウェアの一部をクラウドネイティブなサービスに差し替える手法です。たとえば、Oracle DatabaseをAmazon RDS for PostgreSQLに置き換えたり、オンプレのファイルサーバーをAmazon S3に移したりします。コードの大部分を維持しながら運用負荷とライセンス費を下げられるため、コストパフォーマンスのバランスが良い選択肢です。
リライト・リファクタリング：COBOL→Java自動変換の実力
リライトは既存のロジックを保ったまま別の言語に書き換える手法で、COBOLからJavaへの移行が代表例です。TISが提供する「Xenlon〜神龍」は自動変換ツールとして知られ、JFEスチールでは3,400万ステップのCOBOL資産を29ヶ月でオープン化し、移行期間とコストを約50%短縮しました。ソフトロードのAI変換では、従来手法の1/2〜2/3の期間に短縮した事例も報告されています。
リファクタリングは、内部構造を作り直しつつも外部仕様を保つ手法で、マイクロサービス化やコンテナ化を伴うケースが多くなります。FPTジャパンHDはベトナムに「COBOLアカデミー」を設立し、3,000名超のメインフレームエンジニアを擁するなど、大規模リファクタリングの受け皿も整いつつあります。
ただし自動変換は万能ではなく、業務ロジックに深く埋め込まれた「暗黙の仕様」や、画面遷移の使い勝手といった非機能面は拾いきれません。そのため、結局は人手による補正の工数が膨大になります。見積時には「変換工数」と「補正工数」を別建てで確認することが重要です。
リビルド・リプレイス：ゼロから作り直す覚悟
リビルド（リパーチェスも含む）は、既存システムを一度捨てて、新しいアーキテクチャまたはSaaSで作り直す、最も抜本的な手法です。SAP S/4HANA、Oracle NetSuite、Salesforceといったパッケージ・SaaSに置き換えるケースが典型例です。業務プロセスをパッケージの標準に合わせる「Fit to Standard」が成功の鍵になります。
一方で、過剰なアドオン開発（カスタマイズ）は、パッケージ刷新の失敗原因の筆頭です。スルガ銀行の次期勘定系プロジェクト（Corebank、総額95億円）は、パッケージの適合性評価が不十分なまま進んで白紙撤回となり、東京地裁は日本IBMに約42億円の賠償を命じています。この事例は、「パッケージは標準機能で使えないと意味がない」という教訓の象徴です。
自社に合った手法の選び方
手法の選定では、コストと期間、業務改革度、リスクの4軸でマトリクス評価するのがおすすめです。競争優位の源泉となるコア業務は、リファクタリングやリビルドで差別化を追求します。一方、会計・人事・経費精算などのノンコア業務は、SaaSへリプレイスして運用負荷を下げ、両者を組み合わせるハイブリッド戦略が2026年現在の主流です。
近年注目されている「コンポーザブルERP」は、モノリシックな巨大パッケージを導入するのではなく、会計や販売、在庫、製造といった領域ごとに最適なSaaSを選び、iPaaSでAPI連携する方式です。初期投資を抑え、部分最適で素早く効果を出せる一方、連携設計を誤ると逆に複雑性が増すため、アーキテクトの腕が問われます。
失敗しないプロジェクトの進め方【5つのステップ】
刷新プロジェクトは、綿密な事前準備が成否の8割を決めると言っても過言ではありません。ここでは、現行システムの棚卸しから並行稼働までの5つのステップ（As-Is分析、目標設定、PoC、データクレンジング、並行稼働）に分けて、実務で使える進め方を解説します。どのステップにも教科書では語られにくい泥臭い現実があるため、その点も包み隠さずお伝えします。
ステップ1：現行システムの棚卸しとAs-Is分析
最初の関門は、現行システムの棚卸しです。ドキュメントが残っていない、仕様を知る人が退職している、誰も使っていない機能が山ほどある、という三重苦に直面する企業が大半です。
キングジムは10億円規模の基幹刷新で、最終選定に残った3社のうち最高額の見積もりを出したJQ社を選びました。決め手は、旧システムの全構成を洗い出すと明言したことです。この一点で逆転選定が起きるほど、棚卸しの重要性は高いと言えます。
棚卸しの具体的な手法としては、ソースコード解析ツールで呼び出し関係を一覧にし、本番ログから実際に使われている機能だけを抽出する方法が有効です。ある食品加工工場では、長年続けてきた不要なチェック業務が棚卸しで見えるようになり、刷新と同時に業務を廃止したことで工数を大幅に減らしました。
ステップ2：経営・IT・現場の三位一体での目標設定
目標設定は、経営層・IT部門・現場部門の三位一体で行う必要があります。経営層だけで決めると現場が動かず、IT部門だけで決めると業務価値が出ず、現場だけで決めると技術的負債が再生産されます。三者それぞれの言語を翻訳し、合意をまとめるプロジェクトオーナー（PO）の存在が、成功の決定的な要因です。
ある食品加工工場では、各部署から「システムキーパーソン」を選び、要件定義に専任で関わらせる体制を取りました。熟練者が参画したことで、暗黙知が仕様書に反映され、稼働後の抵抗も最小限に抑えられました。この「キーパーソン制」は、規模を問わず応用できる実務テクニックです。
ステップ3：スモールスタートとPoC
ビッグバン移行の失敗リスクは極めて高いため、最初は限定された業務領域でPoC（概念実証）を行い、段階的にスコープを広げるのが鉄則です。PoCの目的は技術の検証だけでなく、組織の学習コスト、現場の受容度、ベンダーとの相性を測ることにあります。
PoCの期間は2〜3ヶ月、予算は全体の5〜10%程度に設定するのが目安です。ここで得た知見をもとに本番の見積もりをより正確にし、必要なら手法やベンダーを組み替えられるよう、柔軟性を残しておきます。PoCで失敗が見えたときは、本番に進まないという判断も選択肢に入れておく必要があります。
ステップ4：泥臭いデータクレンジングの実務
多くの記事では省かれがちですが、データ移行の泥臭さはプロジェクト炎上の主要因の一つです。典型的な問題は、取引先マスタの重複（同一企業が10種類以上の表記で登録）や、商品コードの桁数の不整合です。ほかにも、ステータス欄への自由記述（「出荷済」「済」「完了」が混在）や全角と半角の揺れがあり、どれも「見えない地雷」になります。
実務ではまず本番データをダンプして統計プロファイリングを行い、異常値や欠損、重複を洗い出します。次に、「機械的に寄せられるもの」「業務ルールで判断が必要なもの」「現物確認が必要なもの」の3層に分け、それぞれに担当と期限を割り当てます。
ミッション・プロデュース社では、ERPの移行計画とテストが不足したまま本稼働を迎え、在庫データの混乱から3ヶ月で数億円の損失を計上しました。また、データクレンジングはIT部門だけでは完遂できません。現場の業務担当者が「このレコードは残す、これは捨てる」を判断し、その時間を業務工数として確保することが、経営層の責務です。
ステップ5：並行稼働とリスクヘッジ
本稼働の前には、新旧システムを並行稼働させ、同じ入力に対して同じ結果が得られるかを検証する期間を設けます。並行稼働は最低でも1ヶ月、基幹系であれば3ヶ月〜6ヶ月が望ましいとされています。並行期間中は二重入力の負荷が現場にかかるため、その工数を見込んだ要員計画が必要です。
NHKと日本IBMの訴訟（2025年2月判決）は、新システムへの100%移行の非現実性を示す象徴的な事例です。刷新では、一部機能を旧システムに残す、段階的に切り替えるといった現実解を認める設計が、結果的に最短かつ低リスクのゴールにつながります。
実名で学ぶ失敗事例と成功事例
抽象論だけでは、刷新プロジェクトの現実は伝わりにくいものです。ここでは、実名で公開されている失敗事例と成功事例を取り上げ、そこから教訓を引き出します。判例集や業界紙で広く知られた事例で、反面教師にも模範例にもなるため、自社の設計で押さえておきたい知見です。
スルガ銀行から学ぶパッケージ選定の罠
スルガ銀行と日本IBMの法廷闘争は、日本のシステム開発史に残る大型案件です。次期勘定系システム「Corebank」は総額95億円規模で進んでいましたが、パッケージの適合性が不十分なまま計画が膨らみ、最終的に白紙撤回となりました。東京地裁はIBM側に約42億円の賠償を命じています。
この事例の教訓は、パッケージ選定の時点で「業務フィット率」を定量的に評価し、合わない部分を業務側で吸収できるかを早めに判断することです。アドオン開発が全体の30%を超えた時点で、そのパッケージは選定ミスの可能性が高いと言えます。
みずほ銀行から学ぶ組織課題
みずほ銀行は2021年2月のATM障害で、キャッシュカードを取り込まれた顧客が多数発生し、社会問題となりました。第三者委員会の報告書では、技術的な要因以上に「失点を恐れない企業風土」の欠如が根本原因として指摘されました。3行統合の過程で生まれた縦割りの組織文化が、情報連携と迅速な判断を阻害した構図です。
この事例が示すのは、システム刷新の成否はアーキテクチャ以上に組織文化に左右されるという点です。失敗を報告しやすい心理的安全性、現場から経営層へ直接上げられるエスカレーション経路、外部有識者を交えたレビュー体制といった組織の地力が、巨大プロジェクトの品質を決めます。
キングジムの逆転劇とベンダー選定の本質
キングジムは10億円規模の基幹システム刷新で、最終選定に残った3社のうち最高額だったJQ社を選びました。決め手は、「旧システムの全構成を洗い出す」と明言した唯一のベンダーだったことです。安さよりも、棚卸しに強くコミットする姿勢を重視した選定だったと言えます。
この事例は、ベンダー選定において「見積金額」以上に「プロジェクトに対する当事者意識」を評価すべきだと示しています。具体的には、候補ベンダーの既存顧客へのリファレンスチェック（実際に電話で話す）を必ず行うことや、提案書の記述と担当PMの面談内容に乖離がないかを確かめることが有効です。
プロジェクト炎上時の「撤退の作法」
撤退戦略を事前に設計しておくことは、刷新プロジェクトで欠かせない守りの準備です。多くの記事では「成功させる方法」が語られがちですが、現実には2〜3割のプロジェクトが当初計画から大きく逸脱します。そこで、着手前に撤退ラインを定め、契約にも撤退条項を盛り込んでおくと、傷を最小限に抑えられます。
サンクコストの判断基準
炎上したプロジェクトから撤退できない最大の理由は、サンクコスト（埋没費用）の呪縛です。「ここまで5億円使ったのだから、いまさら止められない」という心理が、追加投資の泥沼を生みます。撤退判断の基準としては、「残工数の再見積もり額」と「完成後のビジネス価値」を比べ、NPV（正味現在価値）がマイナスなら即時撤退するというルールを、事前に経営会議で合意しておくことが重要です。
撤退判断のタイミングとしては、マイルストーンごとに「ゲートレビュー」を設け、進捗や品質、コスト、リスクという4つの観点で継続の可否を決めるアプローチが有効です。特に、要件定義完了時、基本設計完了時、結合テスト開始時の3ポイントは、後戻りのコストが急増するため慎重な判断が求められます。
契約形態別（請負/準委任）の解除手続き
契約形態によって、撤退時の権利関係は大きく異なります。請負契約では完成義務があるため、途中で解除する場合は出来高に応じた精算と、未成果部分の損害賠償責任の整理が必要です。準委任契約では、民法上はいつでも解除できますが、相手に不利な時期に解除すると損害賠償義務が生じるおそれがあります。
契約書には、「プロジェクト管理義務違反」「仕様不確定時の協力義務」「中間成果物の帰属」といった条項を明記しておくことが、自社を守る基本です。スルガ銀行事件の判決でも、IBM側のプロジェクト管理義務違反が損害賠償の根拠となりました。弁護士を交えた契約レビューは、刷新プロジェクトに欠かせないコストと考えるべきです。
費用相場・補助金・エンジニア単価の最新実態
刷新の費用は「工数×人月単価＋PM費＋環境費＋保守費」の積み上げで算定されます。基幹系の中規模プロジェクトなら1〜5億円、大企業の全社ERP刷新なら10〜100億円規模となり、期間も1〜5年に及びます。2026年現在のエンジニア単価と、見落とされがちな補助金の活用を見ていきます。
2026年最新のエンジニア単価
2026年時点のフリーランスエンジニアの平均月単価は78.3〜80万円、時間単価は約5,319円です。言語別では、Rustが93.7万円、Goが87.0万円、TypeScriptが85.5万円と上位を占めます。生成AIを活用してコードの50%以上を生成できる層には、さらに月10万円のプレミアムがつく傾向があります。
オフショア単価は全体で平均34万円まで下落しましたが、国別では二極化が顕著です。中国は58.3万円（前年比+31.3%）と上昇傾向にある一方、インドは37.5万円（-29.6%）、フィリピンは37.2万円（-13.5%）と低下しています。国内フリーランスとの差が縮まっているため、品質とコミュニケーションコストを加味すると、必ずしもオフショアが安いとは限りません。
補助金・助成金のリアルな活用法
刷新に使える補助金には、IT導入補助金、事業再構築補助金、ものづくり補助金などがあります。ただし採択率は30〜50%にとどまり、申請から給付まで1年以上のタイムラグが生じることも珍しくありません。そのため、採択を待ってから動くのでは手遅れで、自社資金か借入で先行投資するのが実務の前提です。
補助金は支払ったコストの一部を還付する性質のため、見積段階で補助金を当て込んだ計画を立てるのは危険です。採択後も中間検査や実績報告の工数がかかり、採択金額の5〜10%相当を社内工数として見込んでおく必要があります。それでも、数千万円〜数億円の還付が得られる可能性があるため、活用しない手はありません。
保守費用については、年間保守費用が初期開発費の15〜20%という目安が一般的です。保守時間達成率を毎月確かめ、過大な支払いを防ぐ仕組みを契約の段階で組み込んでおくべきです。日常運用は内製、障害対応と特定領域だけを外注する「ハイブリッド型」が、2026年現在のコスト最適解として定着しつつあります。
刷新後の「次の技術的負債」対策
システム刷新は、完了した時点から次の課題が始まる新たなスタートです。今回の刷新で採用した技術も、5〜10年後には次のレガシーになる可能性があります。その未来を見据えて、刷新の設計段階から負債化させない仕組みを組み込むことが、真のIT戦略と言えます。
クラウドロックインを防ぐ設計
AWSやAzure、Google Cloudなどの固有サービスに深く依存すると、将来の移行コストが爆発的に増えます。この「クラウドロックイン」は、メインフレーム時代のベンダーロックインの現代版です。そのため、コンテナ（Kubernetes）やTerraform、OpenTelemetryなどのオープン標準を中核に据え、ベンダー固有の機能は必要な箇所だけに限る設計を基本にします。
マルチクラウド戦略は聞こえが良い一方で、運用負荷やスキルセットが分散するというデメリットも伴います。災害対策としてのマルチクラウドと、通常運用のマルチクラウドは別物として切り分けたうえで、費用対効果を冷静に評価する姿勢が求められます。
コンポーザブルERPという選択肢
ガートナーが提唱する「コンポーザブルERP」は、一枚岩のERPに代えて、領域ごとのベストオブブリードSaaSをiPaaSで組み合わせる新しい潮流です。会計はfreee、人事はSmartHR、経費精算はConcurといった組み合わせが典型例で、販売管理は自社開発で補うこともあります。領域ごとに最適解を選べる柔軟性と、部分的に入れ替えやすい点が最大の利点です。
「内製が理想」と語られがちですが、現実には優秀なエンジニアの採用が極めて難しく、育成にも5年以上かかります。2026年の採用市場では、フルスタックエンジニアの年収が1,200万円を超える水準にあるため、中堅企業が複数名をそろえるのは容易ではありません。そこで、内製と外注の最適なバランスを模索する「スマート・ソーシング」という考え方が、現実的な解になります。
現場の「デジタルデバイド（ITリテラシー格差）」への配慮も、負債化防止に欠かせません。新しいシステムが高度すぎて現場が使いこなせず、結果としてExcelに逆戻りするパターンは意外に多く発生します。UI/UXの使いやすさ、トレーニングプログラム、現場サポート体制までを含めた「定着設計」が、刷新の真のゴールとなります。
まとめ：刷新を成功に導くための総括
レガシーシステム刷新の進め方を、実務の現実まで含めて解説してきました。大切なのは、教科書的な成功方法だけでなく、失敗事例や撤退戦略、次の負債対策まで一貫して設計することです。スルガ銀行、みずほ銀行、NHKといった実名事例が示すとおり、刷新は技術プロジェクトである以前に、組織文化と意思決定構造のプロジェクトでもあります。
成功のための重要チェックリスト
手法選定では7Rフレームワークで自社に合う選択肢を見極め、経営・IT・現場の三位一体で合意をつくります。そのうえで、PoCを通じて技術と組織の両面を検証することが大切です。データクレンジングと並行稼働は十分な期間を確保し、ベンダー選定では価格より当事者意識とリファレンスを重視します。
見落としやすいのが、撤退戦略と次の負債対策です。ゲートレビューで継続の可否を定期的に判断し、契約書には撤退条項と管理義務を明記します。クラウドロックインを避け、コンポーザブル設計で将来の部分入れ替えに備えたうえで、現場への定着設計まで含めて完了と考えます。
最初の一歩の踏み出し方
「どこから始めればいいかわからない」という場合、まず着手すべきは、現行システムの棚卸しと業務フローを一覧にすることです。これだけで全体規模の肌感がつかめ、社内の温度感をそろえる材料にもなります。外部のコンサルやSIerに依頼する場合も、棚卸しの結果があるかないかで、見積もりの精度とプロジェクトの成功率が大きく変わります。
システム刷新は、投資額も期間も大きく、社内外の多くのステークホルダーを巻き込む大事業です。だからこそ、ここまでの「泥臭い現実」と「実名事例の教訓」を踏まえ、綺麗事だけでない実効性のある設計を進めていただければと思います。不明点や、自社に合う手法を第三者の視点で診断したい場合は、信頼できる専門家への相談をおすすめします。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。