経済産業省が2018年に発表した「DXレポート」が警鐘を鳴らした「2025年の崖」
老朽化したレガシーシステムを放置すれば、2025年以降に最大年間12兆円の経済損失が生じるという試算は、多くの経営者をシステム刷新へと駆り立てました。
しかしその焦りが、皮肉にも新たな「崖」を生み出しています。江崎グリコ、NEXCO中日本、NHKと日本IBM……
大企業でさえ失敗するDX刷新には、業種や規模を超えた共通の落とし穴が存在します。
この記事では、国内の失敗事例を横断的に分析し、これからシステム刷新を検討している経営者・IT責任者に向けて、原因と対策をわかりやすくお伝えします。
目次
国内DX刷新の主な失敗事例
まず、近年話題になった代表的な失敗事例を整理します。個別事情はそれぞれ異なりますが、後述する共通要因と照らし合わせると、驚くほど同じパターンが浮かび上がります。
① 江崎グリコ（2024年）——SAP刷新に伴う大規模出荷障害
江崎グリコは基幹システムをSAP S/4HANAへ刷新した直後、冷蔵・チルド商品を中心に約2ヶ月にわたり出荷が停止する事態に陥りました。プッチンプリンなどの定番商品が店頭から消え、流通・小売への影響は甚大でした。原因として指摘されたのは、旧システムとのデータ連携における想定外の不整合と、本番移行前のテストが十分でなかった点です。
② NEXCO中日本（2022年）——ETC料金収受システムの大規模障害
中日本高速道路では、ETCシステムのリプレイス後に料金収受ができない障害が多数のICで発生しました。交通インフラという社会的影響の大きい領域でのトラブルであり、移行計画や冗長化設計の不備が批判されました。
③ NHKと日本IBM（2023年〜訴訟）——受信料システム開発の迷走
NHKが発注した受信料管理システムの開発において、要件変更の繰り返しとプロジェクト管理の問題から納期・品質を巡る深刻な対立が生じ、訴訟へと発展しました。発注側と受注側の責任分界点が曖昧なまま進行したことが、問題を長期化させた要因とされています。
④ その他の代表的な事例
| 企業・機関 | 概要 | 主な問題 |
|---|---|---|
| みずほ銀行（複数回） | 統合システム刷新後もATM・振込障害が繰り返し発生 | システム複雑性、組織間連携 |
| 東京証券取引所（2020年） | 全銘柄売買停止（翌日に復旧） | ハードウェア障害＋フェイルオーバー設計ミス |
| ある大手流通チェーン | ERPリプレイス後に在庫管理が崩壊、欠品・過剰在庫が多発 | 要件定義の甘さ、現場巻き込み不足 |
失敗要因① 経営層の「丸投げ」とオーナーシップの欠如
「システムのことはITに任せておけばいい」——この認識が、最初の大きな落とし穴です。
DX刷新は、単なるITツールの入れ替えではありません。業務プロセスそのものを変える経営改革です。にもかかわらず、多くの企業では経営層がプロジェクトの意思決定から距離を置き、IT部門やベンダーへの丸投げが常態化しています。
その結果、何が起きるか。予算・スケジュール・品質のトレードオフ判断が現場レベルに押し付けられ、誰も「止める」決断ができないまま問題が蓄積していきます。グリコのケースでも、経営レベルでのリリース判断プロセスに疑問が呈されました。
💡 対策：CDO（最高デジタル責任者）またはそれに準じる経営レベルのオーナーをプロジェクトに設置する。月次ではなく週次で経営報告を受ける体制をつくる。
失敗要因② 要件定義の甘さ——「現行踏襲」という名の罠
「現行システムと同じ動きをさせてほしい」という要望は、プロジェクトの最初に必ずと言っていいほど出てきます。しかし、これが諸悪の根源になることが多い。
現行システムに蓄積された業務の例外処理・特殊ルール・暗黙の前提は、長年の運用の中でドキュメント化されないまま積み重なっています。それをそのままERPやパッケージシステムに乗せようとすると、膨大なカスタマイズが必要になり、コスト・期間・リスクが際限なく膨らみます。
NHKと日本IBMの訴訟では、「仕様が確定しないまま開発が進んだ」という構図が報道されました。これは業界を問わず非常によくある失敗パターンです。
💡 対策：「現行踏襲」を要件として認めない原則を経営レベルで決める。ERPやパッケージのスタンダード機能（バニラ実装）を最大限活用し、業務をシステムに合わせる発想に転換する。
失敗要因③ スコープの際限ない膨張（スコープクリープ）
プロジェクトが動き出すと、「ついでにこれも」「あれも入れてほしい」という追加要望が後を絶ちません。これをスコープクリープと呼びます。
一つひとつの追加は小さく見えても、積み重なると開発工数は数倍に膨れ上がり、テスト期間は圧縮され、品質が劣化します。
特に「2025年の崖」という期限への焦りがあると、スコープを絞る判断ができず、「全部やろう」としてすべてが中途半端になる悪循環に陥ります。
💡 対策：スコープ変更には必ずコスト・期間への影響評価を添付することをルール化する。フェーズ分割（第一期はコア機能のみ）を前提に計画を立て、「捨てる勇気」を経営が持つ。
失敗要因④ テスト・移行計画の軽視
開発が遅れると、真っ先に削られるのがテスト期間と移行リハーサルです。「大丈夫だろう」という根拠なき楽観が、本番稼働直後の大規模障害を招きます。
グリコの事例はまさにこれです。SAP S/4HANAへの移行では、本番環境に近い条件での統合テストとデータ移行リハーサルが不十分だったことが障害の直接原因とされています。
チルド食品という「止まったら即・機会損失」の業種特性を考えれば、テスト投資の優先度は最高水準であるべきでした。
💡 対策：テスト期間は「削ってはいけないバッファ」として最初から計画に組み込む。本番同等環境でのリハーサルを最低2回実施。障害発生時のロールバック手順も事前に訓練しておく。
失敗要因⑤ ベンダー依存と内製力の空洞化
日本企業のIT部門の多くは、長年のアウトソーシングによって自社でシステムを理解・評価する能力（内製力）が著しく低下しています。その結果、ベンダーの言いなりになるか、あるいは逆に過剰な注文をつけて関係が硬直化するか、どちらかの極端に陥りがちです。
NHKと日本IBMの訴訟は、この問題の象徴的な事例です。発注側に仕様を確定・管理する能力がなければ、どれだけ優秀なベンダーを選んでも、プロジェクトは迷走します。
💡 対策：PMO（プロジェクト管理室）を自社内に設置し、ベンダー管理を内製化する。IT人材の採用・育成に経営レベルで投資する。重要な刷新プロジェクトには第三者のプロジェクト監査（QA）を入れる。
失敗要因⑥ 現場の抵抗と変更管理の失敗
新システムが技術的に完成しても、使う現場がついてこなければ意味がありません。しかし多くのプロジェクトでは、現場への説明・教育・巻き込みが後回しにされます。
「誰も使い方がわからない」「入力項目の意味が違う」「以前のやり方のほうが楽だった」——こうした声は、移行後に必ず出てきます。それが積み重なると、システムへの入力が雑になりデータ品質が劣化し、「新システムより旧システムのほうがよかった」という逆戻りにつながります。
💡 対策：プロジェクト初期から現場のキーマンを巻き込む。移行3ヶ月前からトレーニングを開始し、並行稼働期間を設ける。「変わることへの不安」を取り除くコミュニケーションを経営層自ら行う。
失敗要因⑦ 「とにかく期限ありき」のスケジュール管理
「2025年までに終わらせなければならない」という外部から与えられた期限は、プロジェクトの判断を歪めます。準備が整っていなくても「見切り発車」する、品質が担保できていなくても「リリースする」——この判断の連鎖が、グリコやNEXCO中日本のような本番障害を生みます。
特に、サポート期限切れや法制度の変更など、外部の期限に引っ張られた刷新は要注意です。期限が動かせない場合こそ、スコープを絞り品質を守る判断が不可欠です。
💡 対策：「期限は守る、ただしスコープは削る」という判断基準を経営合意として文書化しておく。リリース判断には必ず品質基準（テスト合格率・障害件数など）を設定し、未達なら延期できる権限をPMOに与える。
刷新前に確認すべき10のチェックリスト
以上の7つの要因を踏まえ、システム刷新の検討を始める前に、以下の項目を経営層・IT責任者で確認してください。
- ☐ 経営レベルのプロジェクトオーナー（CDO等）が任命されているか
- ☐ 「現行踏襲」を求めず、業務プロセス見直しとセットで計画しているか
- ☐ フェーズ分割（段階リリース）の計画があるか
- ☐ スコープ変更管理のルールが文書化されているか
- ☐ テスト期間と移行リハーサルが計画に確保されているか
- ☐ 自社内にPMO機能（ベンダー管理・進捗管理）があるか
- ☐ 第三者によるプロジェクト監査（QA）の計画があるか
- ☐ 現場キーマンがプロジェクトに参画しているか
- ☐ 移行前のトレーニング計画が立てられているか
- ☐ 品質未達の場合に延期できる意思決定ルールがあるか
まとめ——失敗を「他山の石」にするために
江崎グリコ、NEXCO中日本、NHKと日本IBM。これらの失敗事例に共通するのは、技術の問題ではなく、経営・組織・プロセスの問題です。最新のSAPを導入しても、最先端のクラウドに移行しても、この根本的な問題を解決しなければ、同じ失敗は繰り返されます。
「2025年の崖」は、確かに刷新を急かす現実的な理由でした。しかし今、多くの企業が「崖を恐れて走り出した先に、別の崖があった」という現実に直面しています。
これからシステム刷新を考えている企業に伝えたいのは、「急ぐな」ではなく「正しく急げ」ということです。経営がオーナーシップを持ち、要件を絞り込み、テストに時間をかけ、現場を巻き込む。この原則を守れば、DX刷新は必ず成功への道を拓きます。
他社の失敗は、最も安価な授業料です。ぜひ今回の事例と7つの要因を、自社の刷新計画を見直すきっかけにしてください。
※ 本記事に記載の事例は、公開情報をもとに構成しています。各社の公式発表・報道内容を参照の上、ご確認ください。