基幹システム刷新に踏み切れない情シス責任者へ｜5つの失敗パターンと現実解としてのリライト戦略

「いつかは刷新しなければならない。しかし、やり切れるのか。コストは膨らまないか。失敗すれば取り返しがつかないのではないか」
COBOLやPL/I等で構築されたレガシーシステム（オープン言語のシステムやERPパッケージは対象外）を担当される情シス部門の責任者であれば、一度はこうした不安を抱かれた経験もあるかと思います。「2025年の崖」はすでに通過し、メーカーEOS（製造・保守の終了）、IT人材の不足、保守費の高騰は、もはや将来の懸念ではありません。
本記事では、刷新が先送りされてきた理由と乗り越え方を整理します。結論から申し上げると、“レガシー”と呼ばれがちな業務ロジックは、長年のノウハウが蓄積された貴重な経営資産です。これを維持したまま無理なく基盤を刷新できる「リライト」こそ、踏み切れなかった刷新を現実的な打開策に変える手法。
失敗パターンからベンダー選定、大規模事例まで、経営層への上申を見据えて整理しました。

基幹システム刷新とは｜定義・対象範囲と関連用語の整理

刷新の検討を始めると、「モダナイゼーション」「マイグレーション」といった似た言葉が次々と登場します。意味を曖昧にしたまま議論を進めると、社内の認識がすれ違い、検討が空回りしかねません。まずは共通言語づくりから始めましょう。

システム刷新とは｜定義と対象範囲

システム刷新とは、業務システムを最新の技術環境へ作り変える戦略的な取り組みです。ハードウェアやソフトウェアの置き換えにとどまらず、業務プロセスやデータフローまで含めた抜本的な作り直しを指します。守りのIT投資から攻めのIT投資への転換点と言ってもよいでしょう。

「刷新」「モダナイゼーション」「マイグレーション」の違い

それぞれの用語の関係を整理すると、次のようになります。

• システム刷新：業務プロセスを含めて作り変える取り組み全般です
• モダナイゼーション：既存資産を活かしながら、段階的に現代化していく考え方を指します
• マイグレーション：システムを別の環境へ移す具体的な作業です。移行それ自体をゴールとせず、モダナイゼーション（現代化）へ繋げる第一歩と位置づけることが望ましいでしょう

基幹システム刷新が対象とする範囲

対象となるのは、販売・生産・在庫・会計・人事など、事業の根幹を支える業務システムです。範囲はアプリケーションにとどまらず、データベース・帳票・外部連携・ハードウェア・OSまで広範に及びます。事前検討を含めると、プロジェクトは3〜5年規模の長期戦になるのが通例。検討開始すべきタイミングは、想像されているより早く訪れます。

外部環境の急変｜なぜ今、基幹システム刷新が先送りできないのか

なぜ「いつか」ではなく「今」なのか。経済損失リスク、メーカーEOS、人材不足、コストの硬直化、そしてAI時代の基盤整備という5つの観点から、刷新を先送りできない理由を整理します。

2025年の崖と最大12兆円の経済損失リスク

経済産業省が2018年に公表した「DXレポート」は、レガシーシステムの問題を放置した場合、2025年以降に年間最大12兆円の経済損失が生じる可能性があると警告しました。いわゆる「2025年の崖」です。その2025年はすでに過ぎましたが、崖が消えたわけではありません。刷新できていない企業は、競争力の低下・保守費の増大・障害リスクという形で、今も損失リスクを抱え続けています。「うちはまだ動いているから大丈夫」という判断こそが、リスクを静かに膨らませ続けるのです。

メインフレームと主要ERPに広がるメーカーEOS

ハード面では、日立製作所が2017年にメインフレームのハードウェア開発から撤退し、2026年5月にはメインフレーム向けOS「VOS3」の販売終了(2027年11月)、保守終了(2034年12月)を発表しました。富士通も2030年度末（2031年3月）にメインフレームの製造販売を終息し、2035年度末（2036年3月）には保守サポートの終了を予定しています。ソフト面でも、業務基盤として広く採用されてきたSAP ERP（ECC 6.0 EHP6以降）が2027年末に標準サポート終了を控えます（EHP5以前は2025年12月末で終了済み）。メーカーEOS（End of Sales／End of Service：製造販売・保守の終了）が相次ぎ、レガシーシステムを支える土台そのものが消えていく局面と言えるでしょう。

COBOL技術者の高齢化と45万人のIT人材不足

経済産業省委託の「IT人材需給に関する調査」（2019年4月公表）によると、2030年には中位シナリオで約44.9万人、最大で約78.7万人のIT人材が不足すると試算されています。COBOLをはじめとするレガシー言語の技術者は、その中でも特に希少です。ベテラン技術者の引退は今後も続き、公的な教育環境も無い中で新規育成はほとんど期待できません。保守を担える人材が現場に残っているうちに手を打てるかどうかが、刷新の成否を左右します。

保守運用コストの急増とIT予算の硬直化

IT予算の大半が既存システムの保守・運用に費やされ、新規・戦略投資に回す余力が乏しい。多くの企業調査が指摘してきた構造です。レガシーシステムを抱え続ける限り、保守費は増えることはあっても、減ることはまず期待できません。守りに偏った支出構造を断ち切らない限り、攻めの投資への転換は始まらないのです。逆に言えば、刷新による保守費の適正化は、それ自体が攻めの投資の原資づくりにもなり得ます。

AI時代の基盤整備に向けた戦略的メリット

ここまでの4つは「追い込まれる理由」でしたが、最後は前向きな理由です。オープン環境・クラウド環境へ移行すれば、生成AIやSaaS等、外部サービスとのAPI連携が容易になります。まず技術的負債を解消し（Lift）、その上でAI時代の基盤整備を進める（Shift）。刷新は、AI活用の前提条件を整える戦略投資でもあります。レガシーを抱えたままでは、AI活用の検討すら基盤の制約で頓挫しかねません。

5つの失敗パターンを回避する基幹システム刷新の進め方

「踏み切れない」段階を乗り越えて着手した企業でも、実行段階には5つの典型的な失敗パターンが待ち構えています。本章では、失敗パターン（どこでつまずくか）と処方（どう回避するか）をペアで見ていきます。これらの回避策を、業務ロジックを維持しながら最も実践しやすい手法が、次章で扱う「リライト」です。

失敗1．現行踏襲の罠｜「廃止可能業務」まで踏み込んだ業務仕分け

現場の「今と同じように使いたい」という要望に流されると、要件は際限なく膨張します。その結果、非効率なプロセスを新システム上にそのまま再現し、高額で保守困難なレガシーを再生産してしまうのです。「全部いままで通り」は、一見安全に見えて最も高くつく選択と言えます。
要点は、現状資産の棚卸しではなく、「変える業務・残す業務・廃止する業務」まで踏み込んで仕分けることです。画面・帳票・プログラム・ジョブ・データベース・外部連携・人的運用などを業務単位で洗い出し、業務の継続価値を経営目線で再評価します。未使用資産や廃止可能業務まで対象を絞り込めば、移行規模は大幅に圧縮できます。後述するJFEスチール様の事例では、この仕分けによって移行資産を約6割削減されています。

失敗2．経営層と現場のギャップ｜三者の言語を翻訳し、上申材料を設計する

経営層は「コスト削減・DX推進」、現場は「業務継続・使い慣れた画面の維持」。優先順位がずれたまま進めると、意思決定は揺れ続けます。情シス部門の権限だけで部門間の対立を押し切るのは困難でしょう。
要点は、経営層・現場・情シスの三者が使う言語を翻訳することです。経営層には投資対効果と事業継続性を、現場には日常業務へのインパクトと移行負荷を、情シスには技術的合理性と運用効率化を、それぞれの言葉で示します。業務仕分けで得たアセスメント結果（規模・難易度・課題）を、三者の言語に翻訳した上申材料として設計する。実はこの翻訳と設計こそが難所であり、ここでつまずくと各層の関心がすれ違ったまま、意思決定が宙づりになってしまいます。

失敗3．過度なカスタマイズ｜業務をパッケージに合わせる経営判断

カスタマイズが膨張すると、将来のバージョンアップは事実上不可能になります。保守は属人化し、パッケージ本来の価値が失われる「凍結されたパッケージ」と化してしまいます。
要点は、Fit&Gap分析という手段ではなく、「業務をパッケージに合わせる」という経営判断と、それを支える組織的な覚悟です。「うちの業務は特殊だ」という現場の主張に対し、経営層が「標準化すべき業務」「独自性を残すべき業務」を仕分ける判断を下します。独自性を残す業務が多いほどカスタマイズは膨らみ、難易度も上がります。カスタマイズの許容範囲を経営判断として事前に合意し、RFPに明文化しておくこと。これではじめてパッケージによる業務の「凍結」を防げます。

失敗4．ベンダー丸投げ｜発注側の判断軸とPoCで見極める実力

総額117億円を投じた京都市の基幹系システム刷新（バッチ処理のマイグレーション）が中断に至った訴訟をご存じの方も多いかもしれません。2024年2月、東京地裁はベンダー側に開発遅延の責任を認めつつ、「市にも開発作業に協力すべき義務があった」として双方の責任を認定しました（その後、京都市は控訴）。発注側の当事者意識の不足が、法的トラブルにまで発展した教訓です（出典：日経xTECH「基幹刷新失敗を巡る京都市とシステムズの争い」2024年）。
要点は、RFPを作ること自体ではなく、発注側が技術選定の判断軸を自ら持つことです。候補ベンダーにPoC（概念実証）を依頼し、自動変換の精度・性能・保守体制を自社の目で検証します。RFPは、そこで得た判断軸を文書化したものに過ぎません（ベンダーの評価軸は後述の「刷新の完遂を支えるベンダー選定の3視点」で整理します）。

失敗5．本番障害｜テストとリハーサルで「一括移行」をやり切る

移行テストの軽視、リハーサル不足、切り戻し計画の不在。これらが重なると、本番障害は事業停止に直結し、被害は雪だるま式に拡大します。逆に、ここを固めれば、一括移行（ビッグバン方式）であっても本番障害は十分に防げます。
要点は、移行方式を小刻みにすることではなく、一括移行を成功させるだけの品質を作り込むことです。具体的には、本番同等の大量データで新旧システムの出力が完全に一致するかを検証する現新比較テスト、本番さながらの移行リハーサルの反復、そして万一に備えた切り戻し手順の整備。この3つを徹底すれば、一括での切り替えは「賭け」ではなく「検証済みの計画実行」になります。
なお、段階移行は一見、低リスクに見えるかもしれません。しかし実務では、移行期間中に新旧システムをつなぐ中間インターフェースを新たに構築する必要が生じ、段階ごとのテスト重複が現場の負担を増やし、結果として全体の期間とコストが膨らむケースも少なくありません。一括移行で完遂してきた実績を持つベンダーであれば、品質を担保したうえで、こうした段階移行特有のリスクを回避できます。

4手法の比較とリライトが現実解として浮上した理由

失敗パターンを押さえたところで、刷新の4手法を比較します。前章が「どこでつまずくか」の現象論だったのに対し、本章では各手法の特性と適合判断に焦点を当てます。前提として、どの手法にも適所があるということ。自社の刷新目的と制約に照らして読み進めてください。

4手法の比較表｜コスト・期間・リスクで選ぶ

コスト・期間・リスク・DX推進度・技術的負債解消の5軸で整理しました。社内上申の資料としてもご活用いただけます。

※リライトのDX推進度を「△」としているのは、既存の業務ロジックを踏襲する手法であるためです。
DX（業務改革）は、リライト完了後に段階的に進める形になります。

リビルド｜ゼロから新たに作り直す正攻法

業務要件を見直し、ゼロから新たに作り直す正攻法です。業務改革を伴う理想形ではありますが、開発期間と費用は4手法で最大となり、規模が大きいほど中断リスクも高まります。仕様書が残っていない長期稼働システムでは、要件定義だけで数年を要するケースも珍しくありません。

リプレイス｜パッケージ・SaaSへの置き換え

パッケージやSaaSへ置き換える手法です。業界標準のベストプラクティスを取り入れて業務効率化を進められる一方、Fit&Gap分析の精度が成否を分けます。自社の業務がパッケージの標準機能とどこまで適合するか。導入前の見極めが甘いと、失敗3で見たカスタマイズ膨張への入り口になってしまいます。

リホスト｜基盤だけ載せ替える低リスク手法

プログラムは現行のまま、ハードウェア・OSだけをオープン環境へ載せ替える手法です。低リスク・短期間で移行でき、メーカーEOS対応など短期的なリスク低減には有効でしょう。ただしレガシー言語が残存するため、COBOL技術者不足という根本課題は解決されません。「いったんメインフレーム依存から脱出する」中間ステップとして、将来のモダナイゼーションへ段階的に進む前提で位置づけるのが現実的です。

リライト｜業務ロジックを維持してJava化

変換ツールでCOBOLやPL/I等の資産をJava等のオープン系言語へ書き換える手法です。業務ロジックを維持したまま技術的負債を解消できる、リビルドとリホストの長所を取り入れた現実解として近年注目されています。変換ツールの進化により、数千万ステップ規模の大規模案件でも成功事例が複数積み上がってきました。リビルドと比べて費用・期間を大きく圧縮できる点も特長です。

大規模刷新で「リライトが現実解」となる3つの理由

大規模・長期稼働の基幹システムでは、リライトが現実解として浮上しています。理由は3つあります。
①業務ロジック維持で「踏み切れなさ」を最小化：業務改革リスクを伴わないため、経営判断のハードルが4手法で最も低くなります（失敗2の発生確率も下がります）
②変換ツールの実用化で完遂可能性が向上：変換精度・工期・コストが予見可能になりました
③Lift→Shiftの段階的アプローチ：技術的負債の解消（Lift）から、クラウド・AI連携・業務改革（Shift）へ段階的に推進できます

刷新の完遂を支えるベンダー選定の3視点

RFPを作成した後、各社の提案をどう比較するか。評価軸を3つの視点で整理します。見積金額だけで判断すれば、失敗4「ベンダー丸投げ」の再来になりかねません。

視点1｜大規模プロジェクトを完遂するケイパビリティ

問われるのは、PM力・動員力・大規模案件の経験値です。提案書の完成度と完遂能力は別物。過去の完遂規模・件数を最重要指標とし、PoCで提案内容と実力のギャップを見抜きます。

視点2｜自社開発ツールと技術的優位性

変換ツールを自社で開発・改善し続けているSIerには、技術的な優位性があります。評価すべきはツールそのものではなく、ツール変換を活用して構築される移行後システムの長期的な品質（変換率・性能・保守性）です。変換して終わりではなく、移行後のシステムが長期運用に耐えるか。PoCの結果を品質の物差しとしてご活用ください。

視点3｜刷新後の保守・運用まで伴走できる体制

本番稼働後の保守・機能拡張・AI時代への対応まで、長期で伴走できるパートナーかどうか。移行後に既存・新規どちらのベンダーでも保守を継続できる品質・技術を担保し、Lift→Shiftで発展させ続けられるか。ここに真の刷新価値が表れます。移行して終わりではなく、移行してからが始まり。そう捉えているパートナーかどうかを見極めてください。

基幹システム刷新事例

製造・電機という業界の異なる事例をご紹介します。各プロジェクトの詳細は、それぞれのリンク先（TISI株式会社の公式事例ページ）をご覧ください。規模も期間の制約も異なる、長期稼働の基幹システムをリライトで刷新した2事例です。

JFEスチール株式会社様/JFEシステムズ株式会社様

JFEスチール様は、全国の製鉄所・製造所の基幹システムをオープン化する構想のもと、東日本製鉄所（京浜地区）の3,400万ステップに及ぶ基幹システムをリライトで刷新されました。現場主導の棚卸しで移行資産を約6割削減し、29カ月という短期間で完遂。業務ロジックの変換精度はほぼ100%を実現しています。本プロジェクトに先立つ仙台製造所の事例（21カ月で完遂）と合わせてご覧いただくと、進め方の全体像がつかめるはずです。

▶事例詳細：JFEスチール東日本製鉄所（京浜地区）、基幹システム3,400万ステップを29カ月でオープン化。成功を支えたリライト技術×現場主導のPJ推進。
▶事例詳細（仙台製造所）：JFEスチール仙台製造所の基幹システムをリライト手法でオープン化。永続性のある基盤でDXを加速し「脱炭素」の生産プロセス改革を推進する。

パナソニック インフォメーションシステムズ株式会社様

パナソニックグループのIT中核会社であるパナソニック インフォメーションシステムズ様は、1988年構築のグループ人事システムに残存していたCOBOL資産の移行に取り組まれました。メインフレームの保守終了まで約1年という制約の中、ゼロから作り直すリビルドでは間に合わないと判断し、リライトを選択。約7カ月という短期間で移行を完了し（2023年7月）、変換に起因する障害は発生していません。

▶事例詳細：パナソニックグループ人事システムに残存するCOBOL資産をJavaへリライト。短期に脱メインフレーム化を実現。

2事例に共通する成功要因

業界も規模も異なる事例ですが、成功を導いた設計判断には共通点があります。大きく3つです。
① 業務ロジックを「作り直さず、維持する」選択
2事例ともリビルドではなくリライトを選び、仕様書に残らない"暗黙知の塊"をそのまま継承しました。
② 移行元ベンダーに縛られない基盤への移行
Java化によってIBMや富士通のメインフレームから脱却し、移行後は既存・新規どちらのベンダーでも保守を引き継げる状態を作っています。
③ アセスメントから本番稼働後まで続く伴走体制
1年がかりのPoCやユーザ企業・現行システム保守企業・移行ベンダーの3社ワンチームでの推進など、ツールの精度だけに頼らず、稼働後まで支える体制が完遂を支えました。

リライトが、踏み切れなかった刷新を現実的な打開策に変える

基幹システム刷新は、長らく「踏み切れない」テーマでした。しかし外部環境は時間切れを告げています。リライト技術の進化と大企業2事例の蓄積は、踏み切る決断を後押しするはずです。残っているのは、踏み切る決断と、それを支えるパートナーの選定だけではないでしょうか。本記事が、貴社の刷新検討を一歩前へ進める材料となれば幸いです。