業務システム刷新は、現行システムの洗い出しから始め、関係者の目標をそろえ、小さく検証してから、データを整えて並行稼働で切り替える5つの段階で進めます。
「このシステム、もう限界かもしれない」と感じても、どこから手をつければよいかわからず、刷新を先送りにする企業は少なくありません。
▼全体ガイドの記事
・業務システム刷新の完全ガイド
レガシーシステム刷新の工程ごとの進め方と注意点については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
業務システム刷新の概要と今取り組む理由
レガシーシステムの定義と「2025年の崖」の本当の意味
経済産業省は、レガシーシステムを「技術的な老朽化・肥大化・複雑化によって、保守・運用が困難になり、ビジネスの変化に対応できなくなったシステム」と定義しています。COBOLやFortranで書かれた基幹系はその代表例です。また、2000年代に導入されたJavaのシステムも、設計思想が時代遅れになれば立派なレガシーです。
問題の本質は、言語の古さよりも、変更コストが青天井になっていることにあります。経済産業省が2018年に警鐘を鳴らした「2025年の崖」は、同省の試算で「レガシーシステム問題を放置した場合、2025年以降に年間最大12兆円の経済損失が生じる」という警告です。その核心は二点あります。
一つは、1980〜90年代に構築された基幹システムを支えてきたSEやプログラマーが、2025年前後に大量に退職することです。もう一つは、同じ時期にサポート終了（EOS）を迎えるミドルウェアやOSが急増し、セキュリティホールがむき出しになることです。2025年を過ぎた今、「崖の手前にいる」企業はほぼ存在せず、多くは「崖を転落中」か「崖の底でなんとか立っている」状態です。
放置した場合の具体的リスク（セキュリティ・コスト・人材）
刷新を先送りにし続けた企業のリスクは三つの層に分かれ、第一層は「セキュリティリスク」です。EOSを迎えたシステムは脆弱性パッチが提供されなくなるため、ランサムウェアや標的型攻撃の格好の標的となります。さらに、金融機関では金融庁検査で「EOSシステムの使用継続」を指摘されるケースも増えており、規制リスクも無視できません。
第二層の「コスト構造の歪み」では、IT予算の大半がレガシーシステムの維持・保守に消え、新規開発に回せない「守りのIT」状態に陥ります。実際に、経済産業省の調査では、多くの企業でIT予算の80%以上が維持・保守に充当されているという実態が明らかになっています。
第三層は「人材の空洞化」です。COBOLエンジニアの平均年齢は60代に近づいており、定年退職によって属人化した知識が消えてしまうリスクが現実味を帯びています。2026年現在、フリーランスエンジニアの平均月単価は約78〜80万円に達しており、希少なCOBOL技術者を引き留めるコストも高くなっています。
業務システム刷新の手法の比較（7Rフレームワーク）
リホスト・リプラットフォーム（短期・低コスト型）
AWSが提唱した「7R」フレームワークは、刷新手法を7つに分類したものです。そのうちリホスト（Rehost）は、最もコストと期間が少なく済む手法で、業務ロジックを変えずにインフラだけをクラウドへ移します。オンプレミスのサーバーをAWSやAzureのIaaS上に移す「リフト＆シフト」が、これに当たります。
期間は数ヶ月〜半年程度で、既存の動作を維持できる反面、業務プロセスの改善効果はほぼ得られません。そのため、「とにかくEOS対応を急がなければならない」という局面でのみ有効な手段です。
リプラットフォーム（Replatform）は、コアのロジックを変えずに、データベースをマネージドサービスに移すなど一部の基盤を最適化する手法です。リホストよりやや高度ですが、業務への影響を最小限に抑えながら運用コストを削減でき、バランスが良いことから、中堅企業の第一手として選ばれることが多いです。
リライト・リファクタリング（業務ロジック維持型）
「リライト（Rewrite）」は、COBOLなどのレガシー言語で書かれた業務ロジックを、JavaやGo、TypeScriptなどのモダン言語に書き換える手法です。業務ロジック自体は維持されるため、現行業務への影響を抑えながら技術的負債を解消できます。
TIS株式会社の「Xenlon～神龍」は、この分野の代表例です。COBOLからJavaへロジックを自動変換する仕組みにより、移行期間とコストを約50%短縮しました。また、JFEスチール東日本製鉄所では、3,400万ステップの基幹システムを29ヶ月でオープン化することに成功しています。
ソフトロードが開発した独自AIの変換サービスは、従来の手動リライトと比べて納期を1/2〜2/3に短縮できるとされています。一方、リファクタリング（Refactoring）は、外部の振る舞いを変えずにコードの内部構造を整理・最適化する手法です。段階的な品質改善に向いていますが、根本的な構造問題の解決には限界があります。
リビルド・リプレイス（ゼロベース再構築型）
「リビルド（Rebuild）」は、業務ロジックを参照しながら、完全にゼロからシステムを作り直す手法です。最もコストと期間がかかりますが、業務プロセス自体を抜本的に見直す絶好の機会になります。一方、「リプレイス（Replace）」は、自社開発をやめてSAPやSalesforceなどのパッケージソフト・SaaSに切り替える手法です。
近年注目されている「コンポーザブルERP（ポストモダンERP）」は、リプレイスの発展形です。単一の巨大ERPに頼らず、CRM・会計・在庫管理などの機能をそれぞれ最適なSaaSで組み合わせて構築します。手法を選ぶ際の基準は、「業務の独自性がどの程度あるか」です。
業界標準のパッケージで8割以上の業務をカバーできるならリプレイス、自社固有の業務ロジックが競争優位の源泉になっているならリライトやリビルドを検討します。さらに、予算規模と経営のタイムラインも考慮が必要です。「3年で成果を出せ」という経営指示があるなら、リプラットフォームで即効性を確保しながら、並行して本格刷新を進める「二段階戦略」が現実的です。
失敗しないプロジェクトの進め方【5つのステップ】
5つの段階を順に追うと、刷新に伴う判断と準備を整理できます。
- 現行分析：システムと業務の洗い出し
- 体制構築：経営・IT・現場の目標の擦り合わせ
- PoC：小規模な検証による実現性の確認
- データ整備：移行前のデータ点検
- 並行稼働：リスクを抑えた定着化
ステップ1：現行システムの棚卸しとAs-Is分析
刷新プロジェクトが失敗する原因の一つは、現行システムの全容が把握できていないことです。長年の改修が積み重なるうちに、誰も全体像を把握していないシステムが多数存在します。そこで、まずやるべきことは「ドキュメントの発掘」ではなく、「動いているシステムの実態調査」です。
実態調査では、ソースコードのステップ数、使用技術のバージョン、外部との連携数を定量的に把握し、日次・月次のジョブ処理数も押さえます。キングジムの基幹システム刷新（10億円規模）では、一度頓挫した後の再コンペで「最も見積金額が高かった」ベンダーが選ばれました。その決め手は、「旧システムの構成を全部洗い出す作業から始める」と明言したことでした。
他社が踏み込まなかったAs-Is分析を約束したことが、発注側の信頼を勝ち取りました。現行システムの棚卸しは地味で時間もかかりますが、ここを省略したプロジェクトは後工程で必ず痛い目を見ます。
ステップ2：経営層・IT部門・現場の三位一体での目標設定
業務システム刷新が失敗する典型的なパターンの一つは、IT部門が主導し、現場が置いてきぼりになる構造です。経営層はROIと投資回収期間を重視し、IT部門は技術的な負債の解消を目指します。一方、現場には「今のやり方を変えたくない」という気持ちがあります。
三者の目標が乖離したまま進めると、システムが完成しても現場に使われないという最悪の結果を招きます。たとえば、ある食品加工工場の刷新事例では、長年の慣習で行われてきた不要なチェック業務を、刷新のタイミングで廃止しました。その結果、大幅な工数削減を実現しています。
この事例の成功の鍵は、各部署から「システムキーパーソン」を選び、その人物が現場と開発側の橋渡し役を担ったことにあります。キーパーソンには、業務の「なぜ」を語れる人材であることが求められ、単なるパワーユーザーとは異なります。こうした三位一体の目標設定と推進体制は、プロジェクト開始前に必ず整えておくべき組織的な準備です。
ステップ3：スモールスタートとPoCの実施
大規模な刷新をいきなり全社に展開するのは、もっとも避けるべきアプローチです。「ビッグバン移行」と呼ばれるこの方法では、移行リスクが一度に集中し、問題が発覚した際のリカバリーコストも膨大になります。
現実的な進め方は、業務への影響が小さい部門や機能から始め、成功体験を積み重ねながら段階的に広げていく「フェーズドアプローチ」です。その前段として有効なのがPoC（概念実証）で、「本当にそのアーキテクチャで要件を満たせるか」「新技術を自社開発チームが扱えるか」を、小規模な実験で確かめます。
PoCの目的は、「成功させること」よりも「リスクと課題を早期に発見すること」にあります。PoCで想定外の課題が見つかれば、それはプロジェクト全体を見直す重要なシグナルです。「進めてしまったから後戻りできない」という心理に陥らないためにも、PoCは役立ちます。
ステップ4：泥臭いデータクレンジングの実務【競合にない切り口】
多くの解説は「データ移行の重要性」に触れても実務はあまり語らず、データクレンジングは想像をはるかに超えて泥臭いものです。旧システムには、全角・半角の混在（「株式会社」と「株式会社」が別データとして登録されている）が潜んでいます。ほかにも、住所欄への自由記述による意図しないデータの混入や、微妙に異なる名前で複数レコードになる「名寄せ問題」、NULL値と空文字の不整合などがあります。
実務では、まずデータプロファイリングツール（Talend Data QualityやInformatica Data Qualityなど）で問題の全体像を定量把握します。次に、自動変換ルールで処理できるものとできないものを分類します。一方、自動化できない部分は、業務部門の担当者が手作業で確認・修正する「データ棚卸し作業」が必要になります。
この作業は、システムの規模によっては数名のチームが3〜6ヶ月以上を費やすことも珍しくありません。計画の段階では、データクレンジングの工数を「想定の2〜3倍」と覚悟しておくのが現実的です。また、データ品質が低いまま移行すると、新システムで出力される帳票や分析データが信頼できないものになり、移行後に大規模な修正対応が発生します。
ステップ5：並行稼働とリスクヘッジ体制の構築
本番稼働前の「並行稼働期間」は、保険であると同時に、現場が業務に慣れるための期間でもあります。旧システムと新システムを一定期間同時に動かし、同じ業務処理の結果を突き合わせることで、データの不整合や業務ロジックの漏れを見つけ出します。
並行稼働の期間は業務の複雑さにもよりますが、月次締め処理を含む場合は最低2〜3ヶ月を確保すべきです。リスクを抑えるには、カットオーバー（旧システムから新システムへの切り替え）の日程で「繁忙期を外す」ことが鉄則です。たとえば、小売業であれば年末年始や決算期、製造業であれば生産ピーク期を避けます。
切り戻し手順（新システムに問題が発生した場合に旧システムに戻すプロセス）を事前に文書化し、関係者全員で訓練しておくことも不可欠です。さらに、「切り戻せる設計」でシステムを構築しておくことも、問題への備えになります。
実名で学ぶ失敗事例と成功事例
スルガ銀行（95億円白紙撤回）から学ぶパッケージ選定の罠
スルガ銀行と日本IBMの訴訟は、日本のシステム開発史に残る大型案件です。スルガ銀行は次期勘定系システムの開発をIBMに発注し、総額95億円を投じたにもかかわらず、プロジェクトは白紙撤回となりました。裁判では最終的にIBM側に約42億円の賠償命令が下されましたが、問題の本質は判決内容よりも「なぜ失敗したか」にあります。
根本原因は、スルガ銀行が自行固有の業務フロー（スルガスタンダードと呼ばれた独自の審査プロセスなど）を、パッケージに当てはめようとしたことです。「標準パッケージをカスタマイズすれば何でも実現できる」という幻想が、要件定義の段階での仕様の膨張を招き、開発の複雑性を制御できない状態にしました。
パッケージを導入するなら、「パッケージの標準機能に業務を合わせる」という意思決定を先に固めておくべきです。一方で、「パッケージを自社の業務に合わせる」という発想は、コスト・期間・品質のすべてに悪影響を及ぼします。パッケージで変えられない業務フローがあるなら、最初からスクラッチ開発を選ぶべきです。
みずほ銀行（企業風土が根本原因）から学ぶ組織課題
2021年2月に発生したみずほ銀行のATM障害では、ATMで通帳とカード約5,000枚が取り出せなくなるという前代未聞の事態が起きました。技術的な原因はシステムの設計問題でしたが、金融庁の業務改善命令が指摘したのは、より深刻な問題である「企業風土」でした。
報告書が指摘した「失点を恐れて積極的行動を取らない」「縦割りで横断的な情報共有が機能しない」という文化的問題は、システムの問題であると同時に、組織の問題でもあります。システム刷新プロジェクトでは、チェンジマネジメントが「おまけ」扱いされることも少なくありません。
しかし、最新のシステムを導入しても、それを運用する組織の文化や行動様式が変わらなければ、性能を最大限に発揮することはできません。そこで、意思決定の迅速化、情報共有の仕組み、エスカレーションルールの明確化といった組織変革を並行して進めることが、長期的な投資対効果を高める鍵となります。
キングジム（最高額ベンダー選定の逆転劇）に学ぶ正しい選び方
キングジムの10億円規模の基幹システム刷新では、一度頓挫した後の再選定で、示唆に富む意思決定が行われました。コンペ3社のうち「最も見積金額が高かった」ベンダーが選ばれたのです。
キングジムの調達担当者は、低価格で受注し後から追加費用を積み上げる手法（いわゆるディスカウント見積もりからのスコープクリープ）を見抜き、「なぜそのベンダーが高いのか」の中身を精査しました。高かったベンダーは、他社が見積もりから除外していた「旧システムの全構成調査」「データクレンジング支援」「現場担当者へのトレーニング」を、正直に工数として計上していたのです。
さらに有効だったのが「リファレンスチェック」で、最終候補ベンダーの過去のクライアントに直接連絡し、実際の評価を聞く手法です。ある金融機関では、有力候補が過去に大幅な納期遅延を繰り返していた事実を、このチェックで見つけ、発注を回避しました。見積もりは「金額」より「中身」で比べ、契約前にベンダーの評判を独自に調べることが、正しい選び方です。
プロジェクト炎上時の「撤退の作法」【他記事にない独自視点】
サンクコストをいつ切り捨てるか：判断基準
業務システム刷新の記事の多くは、失敗を避けるための進め方を説いています。一方で、すでに炎上しているプロジェクトをどう着地させるかは、あまり語られていません。しかし、スルガ銀行やNHK（2025年2月に日本IBMを提訴）の事例が示すように、引き際の判断こそ、最も重要な経営上の意思決定の一つです。
NHKの事案では、IBMが品質の確保は困難だとして代替策を提示し、その後NHKが契約解除を決定して、訴訟へと発展しました。撤退の指標は、「完了コスト見積もりの2倍超え」「スコープの30%以上が未確定のまま開発が半分以上進行」「主要ステークホルダーがプロジェクトへの信頼を失っている」という三つの警戒サインです。
サンクコスト（すでに投じた費用）は、意思決定に影響を与えてはなりません。「ここまで投資したから続けなければならない」という心理こそ、失敗プロジェクトを泥沼化させる元凶です。継続か撤退かを判断する際は、「これから投じるコスト」と「継続した場合に期待できる価値」を比べるべきです。
契約形態別（請負／準委任）の解除手続きと責任分解
プロジェクトを中断するときは、契約の法的な性質を正確に理解してから手続きを進めることが欠かせません。システム開発契約には、大きく「請負契約」と「準委任契約」の二種類があります。契約書の精読と法務担当者の関与は、プロジェクト開始時だけでなく、危機の発生時にこそ必要です。
請負契約は「成果物の完成」を約束する契約で、ベンダーは仮にコストがかさんでも、成果物を完成させる義務を負います。また、発注者側も中途解除の場合には「残工事相当分の費用」をベンダーに支払う義務が生じます（民法641条）。準委任契約は「業務の遂行」を委託する契約で、成果物の完成は約束されません。
準委任は、いつでも解除できますが、解除で損害が生じた場合の賠償リスクは残ります。炎上プロジェクトで最も多いトラブルは、「請負なのに準委任と同様に運用されていた」あるいはその逆のケースです。責任分解では、「どの時点で、誰が、何を承認したか」の記録（議事録・メール・承認ドキュメント）が後の紛争時の証拠になるため、こうした証跡を残す習慣は、リスクヘッジの基本です。
刷新後に備える「次の技術的負債」対策
クラウドロックインを防ぐアーキテクチャ設計
レガシーシステムをクラウドに移行したあと、多くの企業が直面するのが「クラウドロックイン」の問題です。特定クラウドの独自サービスに深く依存すると、別のプロバイダーへ移行する際のコストが膨大になります。その結果、「レガシーシステムをクラウド製のレガシーに置き換えただけ」という皮肉な結果を生むおそれがあります。
ロックインを防ぐアーキテクチャ設計の考え方は、「クラウド固有サービスの使用を制御すること」です。たとえば、Kubernetes（コンテナオーケストレーション）を活用すると、アプリケーションをクラウドプロバイダーから独立した状態に保てます。データベースも、各クラウドの独自マネージドDBより、PostgreSQLなどオープンソースベースのものを優先すると、移行コストを抑えられます。
2026年現在、クラウド利用料の高騰（特にAWSは毎年のように一部サービスの値上げを実施）が、IT部門の新たな悩みになっています。そのため、「クラウドファーストからクラウドスマートへ」という思想の転換が求められています。コスト最適化の観点では、オンプレミスと特定クラウドのハイブリッド構成や、マルチクラウド戦略を初期設計の段階から検討することが大切です。
コンポーザブルERP（ポストモダンERP）という選択肢
次の技術的負債を防ぐ設計思想として注目されているのが「コンポーザブルERP」です。従来のモノリシックなERPパッケージ（SAPやOracleの単一巨大システム）に依存せず、機能ごとに最適なSaaSを組み合わせ、APIで連携させるアーキテクチャです。この設計の最大のメリットは、一部の機能だけを最新のサービスに入れ替えられる柔軟性にあります。
たとえば、会計はfreeeやMoneytree、CRMはSalesforceといった具合に組み合わせます。在庫管理はロジザード、人事はHR Brainのように、機能ごとに別のサービスを当てはめます。特定の機能領域でより優れたサービスが登場した場合、その部分だけを差し替えられるため、全体の陳腐化リスクが大幅に下がります。
ただし、複数のSaaSを連携させるためのAPI管理や、データの統合管理・ガバナンスの複雑さという課題もあります。導入する場合は、SaaS間のデータの流れと、マスターデータ（顧客、商品、仕入先など）の管理場所を決める「データハブ」の設計が肝になります。この設計を怠ると、複数のシステムに散らばったデータが矛盾を起こし、新たなデータ品質の問題を招きます。
費用相場と保守コストの算出方法
開発費用の構成と2026年の単価相場
業務システム刷新の費用は、「工数（人月）× 人月単価 + PM費 + インフラ費 + テスト費用」という構造で決まります。2026年現在、フリーランスエンジニアの平均月単価は約78〜80万円に達しており、AI活用スキルを持つエンジニアは、そうでないエンジニアより月単価が約10万円高い傾向があります。
言語別では、Rust（93.7万円）、Go（87.0万円）、TypeScript（85.5万円）が高単価の三強です。また、オフショア開発の単価動向には大きな変化が生じており、中国の単価は前年比31.3%増の58.3万円に跳ね上がって、「安いオフショア」の常識が崩れつつあります。対照的に、インドは前年比29.6%減の37.5万円となっており、インドへのオフショアシフトが加速しています。
FPTジャパンホールディングスは、ベトナムで独自の「COBOLアカデミー」を設立し、3,000名超のメインフレームエンジニアを安定して供給しています。オフショア戦略は、国によって明暗が分かれています。規模感の目安としては、中規模の基幹システム（従業員500名規模）で1〜5億円、大規模な全社的刷新で10〜50億円以上が一般的な相場です。
「初期費用 × 15〜20%」で計算する年間保守費の現実
システム刷新のあとに見落としがちなのが、運用保守コストの継続的な負担です。年間保守費用の目安は、業界の経験則として「初期開発費 × 15〜20%」とされています。たとえば2億円で構築したシステムなら、毎年3,000〜4,000万円の保守費用が発生する計算になります。
この数字を初期予算の段階で経営層と共有しておかないと、稼働後に「なぜこんなにかかるのか」という軋轢が生まれます。見積の妥当性を測るKPIとして「保守時間達成率（実稼働時間 / 見積時間）」を計測すると、過不足を定量的に把握できます。コスト最適化の実践的なアプローチとして有効なのが、「ハイブリッド型」の保守体制です。
日常の運用監視やパラメータ変更といった軽微な対応は内製チームが担い、障害対応・セキュリティパッチ適用・特定領域の改修だけを外注するモデルです。この分担により、属人化を解消しながら保守コストを20〜30%程度削減できるケースが報告されています。IT導入補助金などの支援制度も使える場合がありますが、補助金の要件が技術選定を縛ることもあるため、申請前に制約を精査することが大切です。
まとめ：業務システム刷新を成功に導く本質
業務システム刷新は、技術プロジェクトである以上に、経営プロジェクトです。スルガ銀行の95億円白紙撤回も、みずほ銀行の繰り返す障害も、その根底にあったのは「技術の問題」より「意思決定の問題」と「組織の問題」でした。
さらに、キングジムの逆転選定が示すように、高い見積もりの中身を読み解く力と、ベンダーのリファレンスを自ら調査する行動力が、プロジェクトの成否を分けます。
成功するシステム刷新に共通するのは、現行システムの棚卸しを怠らないこと、経営層・IT部門・現場の三位一体を実現すること、データクレンジングを軽視しないことです。加えて、撤退の判断基準をあらかじめ合意しておくことと、刷新後の次の技術的負債を意識して設計することも、押さえておきたい点です。
教科書的なステップを追うだけでなく、炎上時の撤退の作法と、移行後のクラウドロックインへの警戒を持ってこそ、業務システム刷新は真の意味で成功したといえます。
貴社のシステム刷新プロジェクトにおいて、本記事が具体的な判断の助けになれば幸いです。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・業務システム刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。