「システム刷新の進め方がわからない」「刷新プロジェクトを動かしたものの、要件定義でつまずいている」「経営層は乗り気だが、現場とIT部門の温度差が埋まらない」。このような悩みを抱える担当者の方は、決して少なくありません。実際、システム刷新は企業規模や業種を問わず、数年に一度は避けて通れない大型投資であり、失敗すれば数十億円単位の損失につながる事例も実在します。

本記事では、レガシーシステムの定義から刷新手法の比較、失敗しない進め方の5ステップ、実名の失敗・成功事例、そして他記事にはない「炎上時の撤退戦略」や「次の技術的負債への備え」まで、刷新プロジェクトを動かす実務目線で解説します。教科書的なきれいごとではなく、現場で本当に起こる泥臭い課題と具体的な対処法を盛り込みましたので、ぜひ最後までお読みください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・システム刷新の完全ガイド

システム刷新とは？なぜ今やるべきなのか

システム刷新とは、老朽化・陳腐化した既存システムを、新しいアーキテクチャやパッケージに置き換えて業務基盤を作り直す取り組みを指します。単なるバージョンアップやハードウェア入替と異なり、業務プロセスや組織体制の見直しを伴うことが多く、DX推進の中核となる投資判断です。経済産業省が警鐘を鳴らす「2025年の崖」はすでに現在進行形であり、先送りするほど選択肢が狭まります。

レガシーシステムとは、開発から長い年月が経過し、技術的負債を抱えて改修・運用が困難になったシステムを指します。典型的には、COBOLやPL/Iで書かれたメインフレーム基幹系、マルチベンダーで継ぎ接ぎされたブラックボックスの業務システム、サポート切れのOSやミドルウェア上で稼働するアプリケーションなどが該当します。経済産業省の「DXレポート」では、2025年以降もこの状態を放置した場合、最大で年間12兆円の経済損失が発生すると試算されています。

「2025年の崖」の本質は、単にハードウェアの保守期限が切れるという話ではありません。開発当時のエンジニアが定年退職し、仕様書も不十分なシステムを誰もメンテナンスできなくなる「人材の崖」でもあります。FPTジャパンホールディングスがベトナムに独自の「COBOLアカデミー」を設立し、3,000名超のメインフレームエンジニアをオフショアで供給している現実は、国内にもはや十分な人材がいないことの裏返しです。2026年時点では、COBOL保守人材の時間単価が国産エンジニアの1.5倍以上に跳ね上がるケースも珍しくありません。

レガシーシステムを放置するリスクは、大きく三つに分類できます。第一にセキュリティリスクで、OSやミドルウェアのサポート切れによって脆弱性修正パッチが配信されず、ランサムウェアなどの標的になりやすくなります。第二にコストリスクで、一般的に保守費用は初期開発費の15〜20%が目安とされますが、ブラックボックス化が進むと調査工数が膨らみ、実態として30%を超えるケースも珍しくありません。

第三の、そして最も深刻なのが人材リスクです。属人化したシステムは特定の担当者しか全体像を把握しておらず、その人が退職した途端に障害対応が滞ります。見積妥当性の指標として「保守時間達成率（実稼働時間÷見積時間）」という観点がありますが、月50時間で契約しているのに実態が10時間しか動いていないケースでは達成率20%の過大見積もりとなっており、属人化の裏返しでコスト構造が歪んでいるサインです。こうした兆候が見えた段階で、刷新を本格検討する必要があります。

システム刷新の手法を徹底比較（7Rフレームワーク）

システム刷新の手法選定には、AWSが提唱する「7R（リホスト、リプラットフォーム、リファクタリング、リアーキテクト、リビルド、リプレイス、リテイン／リタイア）」というフレームワークが広く用いられます。刷新の目的、予算、移行期間、業務影響の許容度によって最適解が異なるため、手法を固定観念で決めず、業務要件に沿って選ぶ姿勢が重要となります。以下では代表的な3グループに分けて解説します。

リホストは、既存システムをできるだけそのままクラウドや新しいインフラに「持ち上げる」手法で、いわゆるリフト＆シフトと呼ばれます。アプリケーションのソースコードに手を入れないため移行期間が短く、オンプレからクラウドへの切替では3〜9ヶ月で完了するケースもあります。リプラットフォームは、OSやミドルウェアを新しい環境に合わせて調整しつつ、アプリの主要ロジックは維持する中間的な手法です。

この手法の弱点は、技術的負債を温存したまま移行するため「刷新したつもり」になりやすい点にあります。ブラックボックス化した業務ロジックはそのまま残り、クラウド移行後に改修要望が出た際に結局手を付けられないという事態も発生します。短期で移行するプレッシャーが強い場合の現実解ではありますが、移行後24ヶ月以内にリファクタリングを行う計画とセットで考えるのが賢明です。

リライトは、業務ロジックを維持したまま、プログラミング言語やフレームワークを最新のものに書き換える手法です。TISが提供する「Xenlon〜神龍」のように、COBOL等からJavaへ業務ロジックを約100%自動変換するツールを使うと、移行期間とコストを従来比で約50%短縮できるとされています。JFEスチール東日本製鉄所の事例では、3,400万ステップの基幹システムを29カ月でオープン化した実績が報告されています。

リファクタリングは、外部仕様を変えずに内部構造のみを整理する手法で、モジュール分割やデータベース正規化を通じて保守性を高めます。ソフトロードが提供するAI変換のように、独自AIで従来のリライト工数比で納期を1/2〜2/3に短縮できるサービスも登場しており、仕様書がないブラックボックス状態であってもAI＋手作業のハイブリッドで攻略できる時代になりました。現場業務を止められない基幹系で重宝される手法です。

リビルドは、現行システムの機能を参考にしつつ、ゼロベースでアーキテクチャから作り直す手法です。業務プロセスそのものを見直す良い機会となる一方、投資規模は最大で、数十億円規模のプロジェクトになることも珍しくありません。リプレイスは、自社開発をやめてSaaSやERPパッケージに置き換える手法で、SAP S/4HANAやOracle NetSuite、Salesforceなどへの切替が代表例です。

ゼロベース型で陥りがちなのが、既存業務をパッケージに「寄せ切れない」事態です。後述するスルガ銀行と日本IBMの法廷闘争は、まさにこのパターンで、自社業務要件に合わないパッケージ選定が95億円の損失につながりました。リプレイスを選ぶ際は、業務をパッケージに合わせる覚悟（Fit to Standard）と、どうしても譲れない独自要件の線引きを、プロジェクト開始前に経営層で意思決定しておく必要があります。

手法選びの際は、以下の観点を順にチェックすることをおすすめします。①業務の競争優位性：業務そのものが競争力の源泉であればリライトやリビルドで自社仕様を磨く価値があり、定型業務中心であればリプレイスでSaaSに寄せたほうが合理的です。②移行の許容期間：6ヶ月以内の短期要求ならリホストが現実解、3年かけられるならリビルドも選択肢に入ります。

③予算規模：初期開発費の概算は、リホストが最も軽く、リビルドが最も重くなります。④人材リソース：COBOL人材が社内に残っているかどうかでリライトの難易度が変わります。⑤将来の拡張性：APIエコノミーやAI連携を見据えるなら、マイクロサービス化を伴うリアーキテクトが有力です。これらを総合的に評価し、単一手法に絞らず複数手法の組み合わせも検討するのが実務的なアプローチといえます。

失敗しないプロジェクトの進め方【5つのステップ】

システム刷新は「要件定義さえきちんとやれば成功する」という単純な話ではありません。失敗プロジェクトを分析すると、現行調査の浅さ、組織内の温度差、データ品質の軽視、並行稼働のリスク管理不足といった複数の要因が絡み合っています。ここでは実務で有効性が確認されている5つのステップを、それぞれの落とし穴とともに解説します。

最初に行うべきは、現行システムの徹底的な棚卸しです。稼働している機能、連携先システム、バッチ処理、帳票、マスタデータの種類と件数、夜間処理のタイミングまでを一覧化します。キングジムが基幹システム刷新の再選定時に、コンペ3社中で「最も見積金額が高かった」JQ社を選んだ逸話は示唆に富んでいます。他社が踏み込まない「旧システムの構成を全部洗い出す」と明言したことが決め手となり、成功への道筋が描けたのです。

棚卸しで見落とされやすいのが、Excelマクロ、Accessデータベース、個人PCで動く補助ツールなどの「野良システム」です。基幹システムに直接つながっていなくても、帳票転記や集計作業の前提になっていることが多く、刷新後に業務が止まる原因になります。現場ヒアリングでは「普段使っているファイルを全部見せてください」と踏み込んだ聞き方をすることで、これらが浮かび上がります。

プロジェクトが炎上する最大の構造的要因は、経営層・IT部門・現場部門の三者が別々のゴールを見ていることです。経営層は投資対効果とスピード、IT部門は技術的美しさと安定性、現場はいまの業務のままラクになることを求めます。この利害を調整せずにキックオフすると、要件定義の最終盤で現場が「こんな仕様では業務が回らない」と言い出し、大幅な手戻りが発生します。

ある食品加工工場の事例では、長年の慣習で残っていた不要チェック業務をシステム刷新時に廃止する判断を下しました。各部署から「システムキーパーソン」を選出し、部門間の利害調整を行う体制を整えたことで、現場の納得感を保ったままプロセス改革を進められました。経営層がスポンサーとして顔を見せ続ける「スポンサーロードマップ」の実践も、現場のモチベーションに直結します。

全社一斉のビッグバン導入は、失敗時のダメージが大きすぎます。まずは一部業務や一事業所でPoC（概念実証）を行い、新システムの操作感、パフォーマンス、既存システムとの連携可否を確認します。PoCの目的は「成功させること」ではなく「失敗の芽を安く早く見つけること」だと認識しておくと、健全な判断ができます。

PoCで確認すべきは、技術的な動作確認だけではありません。現場ユーザーが実際に画面を操作したときの違和感、既存の帳票レイアウトとの差分、レスポンス速度、エラーメッセージの分かりやすさといった「人間系」の評価項目も重要です。2〜3ヶ月のPoC期間中に改善フィードバックを繰り返すアジャイル的な進め方が、本番移行後のトラブルを大きく減らします。

競合記事の多くが素通りするのがデータクレンジングの実務です。長年使われてきた基幹システムには、全角半角の混在、自由記述欄への誤入力、同一取引先の重複登録、廃止コードの残存など、無数の汚れたデータが蓄積しています。これをそのまま新システムに移すと、検索・集計・与信管理のすべてが狂います。

実務では、データクレンジング専任チームを編成し、3〜6ヶ月かけて取り組むのが標準です。ツールはOpenRefineやTalend、Alteryxなどが使われますが、最終的な名寄せ判断は人間の目視が必要になる局面が多く、社員か外部派遣スタッフを数名配置します。「データクレンジングに費やす工数は刷新プロジェクト全体の10〜15%」という感覚を持ち、予算計上時に最初から織り込んでおくことが大切です。

本番移行の直前に行うのが、新旧システムの並行稼働です。一定期間、同じ業務データを両システムに投入し、出力結果を突き合わせて差異を洗い出します。月次決算をまたぐ1〜2ヶ月の並行稼働が一般的で、差異が許容範囲内に収まった時点で旧システムを停止します。

並行稼働中は現場の負荷が倍になるため、繁忙期を避ける、夜間バッチのジョブを調整するなどの配慮が必要です。また、トラブル発生時にすぐに旧システムへ戻せる「ロールバックプラン」を文書化し、関係者全員で手順を共有しておきます。NHKと日本IBMの訴訟事例が示すように、100%完全な移行はそもそも非現実的であるため、現実的な許容範囲を合意したうえで移行判断を行う姿勢が重要です。

実名で学ぶ失敗事例と成功事例

システム刷新の教訓は、匿名のベストプラクティス集より、実名の失敗事例から学ぶほうが遥かに身に沁みます。ここでは報道や判決文で事実が公開されている3つの事例を取り上げ、それぞれから引き出せる実務教訓を解説します。自社プロジェクトに置き換えて読むと、いまの状況のどこに危険信号があるかが見えてくるはずです。

スルガ銀行と日本IBMは、次期勘定系システム「Corebank」の開発をめぐって法廷闘争に発展しました。総額約95億円のプロジェクトが白紙撤回となり、IBM側に約42億円の賠償命令が下りました。根本原因は、自社業務要件に合わないパッケージ製品を選定したことと、フィット＆ギャップ分析が十分でなかったことにあります。

この事例から学ぶべきは「パッケージ＝安い、早い」という先入観の危険性です。パッケージに業務を合わせる覚悟がないまま、自社独自の業務ルールを全部カスタマイズしようとすると、スクラッチ開発より高額かつ不安定なシステムができあがります。選定段階でフィット率を定量評価し、ギャップの扱い（業務変更で吸収するのか、アドオン開発するのか）を明文化することが不可欠です。

みずほ銀行は2021年2月にATMで大規模障害を起こし、通帳とカード約5,000枚が取り出せなくなる事態が発生しました。第三者委員会の報告書は「失点を恐れて積極的行動を取らない」企業風土が根本原因であると明記しています。つまり、技術の問題ではなく組織文化の問題だったのです。

この事例は、システム刷新が単なる技術プロジェクトではないことを端的に示しています。いくら最新技術を導入しても、意思決定の遅さ、縦割り組織、責任回避の文化が残っていれば、同じ失敗を繰り返します。プロジェクトの開始時点で、経営層がチェンジマネジメントへの覚悟を示し、組織文化の変革とセットで推進する姿勢が問われます。

キングジムは10億円規模の基幹システム刷新が一度頓挫した後、再選定に踏み切りました。コンペに参加した3社のうち、選ばれたのは「最も見積金額が高かった」JQ社です。他社が踏み込まない「旧システムの構成を全部洗い出す」と明言したことが決め手となり、結果としてプロジェクトは成功しました。

この事例の教訓は、安さで選ぶと結局高くつくという、シンプルだが重要な事実です。複雑な基幹システムの刷新では、調査と設計にどれだけ工数を割いてくれるかが品質を左右します。さらに、最終候補の過去クライアントに直接リファレンスチェックを行うと、見積もり段階では分からない「実際の進め方のクセ」が見えてきます。ある金融機関は、このリファレンスチェックで有力候補の過去の納期遅延が判明し、選定を見直したという逸話もあります。

プロジェクト炎上時の「撤退の作法」

多くの記事が触れないテーマが、プロジェクト炎上時の撤退戦略です。どれほど準備しても、途中で要件の破綻やベンダーの能力不足が明らかになり、このまま進めるべきか撤退すべきかを判断する局面は実際に起こります。撤退は敗北ではなく、損失を最小化するための経営判断であり、方法論として学んでおくべきテーマです。

すでに投じた費用（サンクコスト）を惜しんで撤退判断が遅れるのは、意思決定論における古典的な失敗パターンです。判断基準としては、①今後追加で投じる予算と得られる効果の比、②稼働予定日までの残工程のリアリティ、③現場の疲弊度と離職リスク、④経営計画への影響、の4点を定量的に評価します。

特に重要なのが「追加投資で本当に完遂できるのか」という見通しです。すでに予算を1.5倍超過し、かつ重要機能のテストすら始まっていない状況であれば、さらに1年延長しても完遂できない可能性が高いといえます。こうした局面では、外部の第三者監査（PMOやITコンサル）に客観評価を依頼し、撤退の是非を中立的に判断してもらうのが賢明です。

撤退時に最もトラブルになるのが、契約上の責任分解です。請負契約（完成責任あり）の場合、ベンダー側に完成義務があるため、完成遅延や品質不良があれば発注者側から契約解除と損害賠償請求が可能です。一方、準委任契約（業務遂行責任）では、成果物の完成は義務づけられていないため、解除理由の立て付けが異なります。

実務では、中間成果物（要件定義書、設計書、テストコード）の著作権帰属と引渡し義務、既払報酬の精算方法、機密保持義務の継続期間、紛争発生時の管轄裁判所などを、契約書の解除条項で明文化しておくことが重要です。スルガ銀行・日本IBM訴訟でも中間成果物の価値評価が争点となりました。紛争を避けるうえでも、プロジェクト開始前に撤退条項を整備しておく姿勢が、結果的にプロジェクトの健全な進行につながります。

刷新後に備える「次の技術的負債」対策

システム刷新を完了したら終わりではありません。いま選択した技術や契約形態は、10年後には「次の技術的負債」として跳ね返ってくる可能性があります。刷新後を見据えて、将来の身軽さを確保するアーキテクチャ設計を、いまの段階から意識しておく必要があります。

AWS、Azure、Google Cloudといった主要クラウドベンダーは、便利なマネージドサービスを多数提供していますが、依存度を高めると将来の切替コストが跳ね上がるクラウドロックインのリスクがあります。実際、利用料の改定で年間数千万円単位のコスト増となる事態は、2024年以降複数報告されています。

対策としては、コンテナ技術（DockerとKubernetes）によるアプリケーション層の抽象化、データベースはオープンソース系（PostgreSQLやMySQL）を選ぶこと、独自APIよりも標準的なプロトコル（REST、gRPC、MQTTなど）を優先することが挙げられます。マルチクラウド構成まで踏み込まなくても、「いざとなれば移行できる設計」を採用しておくだけで、ベンダー交渉力が大きく変わります。

従来のモノリシックなERPは、一度導入すると数年にわたり変更が難しい重い基盤でした。近年注目されるのが、コンポーザブルERP（ポストモダンERP）という考え方です。これは会計、販売、生産、人事などの機能を個別のSaaSとして組み合わせ、APIで疎結合に連携する構成を指します。

メリットは、部門ごとの最適解を選べる柔軟性と、不要になった機能をいつでも差し替えられる可変性です。デメリットは、データ連携の設計と運用が複雑化することと、ベンダー管理の工数が増えることです。生成AIを使った統合自動化ツールの登場でハードルは下がりつつあるため、大企業に限らず中堅企業でも現実的な選択肢となってきました。自社の規模と組織力を見極めて、次の10年を支える基盤として検討する価値があります。

まとめ

システム刷新は、7Rの手法選定、5ステップの進め方、実名事例からの教訓、炎上時の撤退戦略、次の技術的負債対策までを通して計画する、長期戦のプロジェクトです。教科書的なベストプラクティスだけでなく、データクレンジングの泥臭さ、組織風土の問題、契約上の撤退条項といった現実的なテーマに正面から向き合う姿勢が、成否を分けます。

スルガ銀行95億円の白紙撤回、みずほ銀行のATM障害、キングジムの最高額ベンダー選定による逆転劇。これらの実例が示すのは、システム刷新は技術選定だけではなく、経営判断と組織改革の総力戦であるという事実です。本記事を羅針盤に、自社の状況に即した進め方を描いてみてください。

より深く各テーマを学びたい方は、以下の関連記事もあわせてご覧ください。

・システム刷新のおすすめ会社比較
・システム刷新の費用相場
・システム刷新の発注方法

▼全体ガイドの記事
・システム刷新の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。