競争力を保つには刷新が避けられませんが、炎上や遅延、大幅な予算超過が繰り返されています。典型的な失敗パターンは、全社一括の切り替え、現場の参画不足、データ移行の軽視です。段階移行、現場参画、独立したデータ移行計画を基本に進めると、失敗リスクを抑えられます。全体像はレガシーシステム刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム刷新が失敗する典型パターン
経済産業省の「DXレポート」は、老朽化システムの放置により2025年以降に年間最大12兆円の経済損失が生じると試算しています。一方で、刷新プロジェクトでは、全社一括移行などの失敗パターンが繰り返されています。
なかでも多いのが、ビッグバンアプローチの採用です。この方式では、基幹システムを特定の時点で全面的に切り替えます。
そのため、切り替え前後の検証期間が短くなりがちです。問題が起きると、事業全体に影響が及びます。
2023年に注目を集めた江崎グリコの事例も、典型例です。基幹システムの切り替え時に障害が起き、チルド商品（冷蔵品）の全品出荷が停止しました。さらに、物流・小売の現場が長期間麻痺しました。
原因は移行計画の不備とされ、本番環境でのデータ連携や業務フローの検証不足が影響したとみられています。この事例は、移行計画の甘さが深刻な事業リスクになることを示す教訓として、繰り返し語られています。
SAP導入で繰り返される「3大疾病」
ERP刷新、とりわけSAP導入では、3つの失敗パターンが繰り返されます。特に注意が必要なのは、現場参画、アドオン開発、データ移行の扱いです。
- 第一の疾病（現場の参画不足）：業務担当者が要件定義や設計に関与しない
- アドオン開発の過多：現場業務に合わせて標準機能を過剰に改修する
- データ移行の軽視：複雑な変換や整合性確認を十分に行わない
現場がほとんど関与せずに要件定義を進めると、業務実態と乖離した仕様が大量に生まれます。こうした仕様が受け入れテストで見つかると、手戻りのコストが膨大になります。
パッケージの標準機能をカスタマイズしすぎると、バージョンアップのたびにアドオン改修が必要になります。その結果、維持コストが雪だるま式に増加します。
COBOLからSAPへ移行する際、COBOLで作り込んだ業務ロジックをそのままSAP上で再現する発想は、最大の危険信号です。また、レガシーシステムからERPへのデータ移行は単純なコピーではなく、コードマッピング、データクレンジング、整合性確認を伴う複雑な作業です。
移行を軽視すると、本番稼働後に得意先コードの重複や在庫数値の不整合が見つかります。実際、業務停止につながるケースが後を絶ちません。
レガシー固有の課題・注意点・リスク
COBOLやメインフレーム、オフコンの刷新には、モダナイゼーション一般とは異なるリスクがあります。そのため、レガシー固有のリスクを把握せずに着手すると、プロジェクト炎上の大きな引き金になります。
仕様書欠如とブラックボックス化
仕様書がなく、担当者もシステムの挙動を説明できない場合、ソースコードの解析と工数見積もりが課題になります。
- 資料の欠如：設計書や仕様書が存在しないか、実際の稼働と乖離している
- 解析工数の超過：長年の改修で複雑化したソースの解析が必要になる
1970〜80年代に構築されたCOBOLシステムでは、資料と稼働状況がずれた状態を「ドキュメントのブラックボックス化」と呼びます。
要件定義でヒアリングしても、挙動を正確に説明できる担当者が社内にいないケースは珍しくありません。その場合は、現行システムのソースコードからビジネスロジックを抽出する「リバースエンジニアリング」が必要になります。
COBOLのソースは数十万〜数百万行に及ぶことも多くあります。さらに、長年の改修で規約やコメントがなく、処理が複数プログラムに分散した状態も見られます。この解析工数を甘く見積もると、要件定義だけで計画の2〜3倍の工期がかかります。
データ移行の落とし穴（EBCDIC・固定長レコード）
レガシー環境のデータ移行では、文字コード、レコード形式、蓄積データの品質を、それぞれ別に確認する必要があります。
- 文字コード：EBCDICからUTF-8やShift-JISへの変換
- データ形式：固定長レコードや独自数値形式のマッピング
- データ品質：重複コードや命名規則の不統一のクレンジング
メインフレームでは、EBCDIC（Extended Binary Coded Decimal Interchange Code）を採用しています。これは、WindowsやLinuxで使われる文字コード体系とは異なります。
そのため、単純な文字コード変換ではデータが壊れます。特に、全角・半角文字や特殊文字、制御コードの変換には細心の注意が必要です。
メインフレームのデータは、バイト数を厳密に定めた「固定長レコード」形式で格納されています。CSVのような区切り文字形式とは異なります。
数値データも「パック10進数」や「ゾーン10進数」という独自形式です。RDBMSのINTEGER型やVARCHAR型へ正確に対応づけるには、専門知識が欠かせません。技術的な変換を過小評価すると、移行後のデータが本番環境で化け、業務停止を招く事例が繰り返されています。
加えて、長年蓄積されたマスタデータのクレンジングも、重大なリスクです。顧客コードの重複、廃止済みコードの残存、命名規則の不統一が残る場合があります。
現行のデータ品質の問題を新システムへ持ち込むと、移行後の業務データの信頼性が根本から損なわれます。そこで、移行はコピー作業ではなく、データ品質改善プロジェクトとして計画します。
技術者枯渇とベンダー丸投げリスク
技術者の枯渇は、現行システムの保守と刷新後の運用の両方に影響します。また、発注者側の管理能力も保つ必要があります。
- 刷新期間中：現行システムの障害を修正できない
- 刷新完了後：新システムの保守人員が確保できない
COBOLやメインフレームを扱う技術者は平均年齢が上がっており、定年退職による人材の喪失が深刻です。そのため、社内外で保守エンジニアが見つからないリスクがあります。
社内に現行システムの知識も新技術の知見もない場合、要件定義からテスト、移行計画までを外部ベンダーへ全面委託する「ベンダー丸投げ」に陥りがちです。発注者側に業務要件を正確に伝える人材がいなければ、設計が机上のものにとどまり、現場で通用しないシステムになります。
さらに、発注者側のプロジェクト管理能力（PMO機能）が欠けたまま大型プロジェクトを進めることは、最大のリスク要因のひとつです。
失敗を防ぐプロジェクト設計の原則
失敗を防ぐには、立ち上げ時にリスクの構造を把握し、それぞれに対応する設計原則を組み込みます。たとえば、一括切り替えには段階移行で、現場参画の不足には参画の仕組み化で対応します。
ビッグバンを避けたストラングラーパターンによる段階移行
最も重要な設計原則は、ビッグバンアプローチ（全社一括切り替え）を避けて、段階的に移行することです。
- 移行単位：機能または業務ごとに新システムへ置き換える
- 稼働方法：新旧システムを並行稼働させて段階移行する
ストラングラーパターン（Strangler Fig Pattern）は、旧システムの機能が新システムに完全に置き換わる手法です。旧機能が「絞め殺される（Strangled）」ように移行することから、この名が付いています。
最大のメリットは、機能ごとに稼働を確認して移行し、問題時の影響を限定してリスクを分散できる点です。さらに、並行稼働中は、旧システムとのデータ整合性も継続的に検証できます。
一方で、並行稼働には二重運用のコストがかかります。旧新間のデータ同期を設計する追加の工数も必要です。
切り戻し手順とダウンタイム見積もりの事前確定
本番稼働後に問題が起きても元に戻せるよう、切り戻し手順と業務停止時間を事前に計画します。
- 切り戻し基準：問題が発覚した場合のGo/No-Goクライテリア
- 復旧手順：旧システムへ戻す時間とデータ整合性の確認方法
- 停止時間：業務部門と合意するダウンタイムの見積もり
江崎グリコの事例が示すように、本番後に問題が発覚して「元に戻せない」状態は大きなリスクです。だからこそ、切り戻し（ロールバック）の詳細設計が必須です。
切り戻しの判断基準と確認手順は、本番移行計画書に明記します。「土日夜間に移行するから業務影響はゼロ」という計画は、現実には機能しないことが多いため、ダウンタイムの見積もりは経営層の事前承認を得ておきます。
見積もりは、移行スクリプトの実行時間、データ移行量、接続テストの時間を実績データに基づいて算出します。本番日程は、業務部門と合意してから確定します。
現場参画の仕組み化
現場担当者をキーユーザーとして正式に配置し、要件定義から移行後まで役割を持たせます。
- 参加と評価：要件定義への参加、プロトタイプ評価
- テストと定着：受け入れテスト、移行後の現場トレーニング
SAP導入でいう「ユーザーにやる気がない」問題の本質は、現場がプロジェクトを自分ごととして認識できていないことです。そのため、現場担当者の参画は、依頼するだけでなく仕組みに組み込みます。
たとえば、キーユーザーは専任または兼任の形でチームに入ります。COBOLのロジック解析の段階からも、現場担当者に関与してもらいます。現行処理の業務上の背景を説明できるのは、長年その業務に携わってきた担当者だからです。
資料がない場合は、暗黙知を引き出す場を正式なプロジェクト活動として設計します。この設計が、要件定義の品質を左右します。
独立したサブプロジェクトとしてのデータ移行計画
SAP導入の第三の疾病「データ移行の失敗」を防ぐため、移行を開発の付随作業にせず、独立したサブプロジェクトとして扱います。計画には、次のフェーズを含めます。
- 移行準備：対象データの棚卸し、文字コード変換ルール確定
- 変換設計：マスタコードの対応づけ、クレンジングルール策定
- 移行検証：移行リハーサル、旧新データの整合性確認
移行リハーサルは、少なくとも2〜3回実施する計画にします。1回目はスクリプトの動作確認、2回目はデータ品質と所要時間の確認です。3回目は、本番手順を最終確認します。
リハーサルを省いて本番に臨むプロジェクトは、ほぼ例外なく移行で問題を起こします。加えて、旧新システムのデータを突合し、件数や金額の整合性を確認する「移行検証プログラム」も必要です。この移行検証プログラムは、初期段階から移行計画に含めて予算化します。
まとめ
刷新の失敗には、一括移行、SAP導入時の現場参画不足やアドオン過多、データ移行の軽視があります。
COBOLやメインフレームでは、仕様書の欠如によるブラックボックス化が起きます。さらに、EBCDICなどの文字コード変換の落とし穴や技術者枯渇によるベンダー丸投げも重なり、炎上を避けられません。
一点目は、段階的に機能を置き換えるストラングラーパターンを採用することです。ビッグバンによる全社一括切り替えを避け、リスクを機能単位に分散します。
二点目は、切り戻し手順とGo/No-Goクライテリアを本番移行前に確定し、経営層の承認を得ることです。
三点目は、現場担当者をキーユーザーとして正式に配置し、要件定義の段階から参画してもらうことです。
データ移行は、EBCDICからUTF-8への変換、固定長レコードからRDBMSへのマッピング、マスタデータのクレンジングを含む、独立したプロジェクトとして扱います。移行リハーサルは2〜3回行います。
技術的負債の解消と移行リスクの管理を同時に設計へ組み込むことが、失敗率を下げるうえで欠かせません。戦略立案から推進まで伴走できるパートナーについては、専門家への相談もご検討ください。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。