「基幹システム刷新の進め方」を紹介する記事の多くは、一般論の5ステップや抽象的な失敗パターンの紹介にとどまり、具体的な事例や数値の裏付けに乏しいものが目立ちます。この記事では、実際に報道された企業の事例と公的機関の調査データをもとに、基幹システム刷新で何が起きているのか、そして失敗を避けるためのポイントを整理します。

Contents
  1. 基幹システム刷新、成功率はどのくらいか
  2. 実際に何が起きたのか：報道された事例
  3. 失敗パターンに共通する要因
  4. 成功事例：ライオンの基幹システム刷新
  5. 失敗を避けるための進め方
  6. よくある質問
  7. 参考にした主な調査・資料
  8. まとめ

基幹システム刷新、成功率はどのくらいか

JUAS（日本情報システム・ユーザー協会）が実施する「企業IT動向調査」では、品質・コスト・納期（QCD）をすべて達成したプロジェクトを「成功」と定義しています。2025年4月に公表された同調査によると、2015〜2024年のデータで「計画通り」完了したプロジェクトの割合は、企業規模を問わず低下傾向にあります。「基幹システム刷新の成功率は30%程度」という数値が広く言及されていますが、この数字がどの調査・どの定義に基づくものかは情報源によって表現が異なるため、鵜呑みにせず参考程度に捉えるのがよいでしょう。

IPA（情報処理推進機構）が2025年5月に公表した「レガシーシステムモダン化委員会」総括レポートでは、システム刷新に「一部でも着手した」企業は大企業で65.5%、中小企業で43.8%にとどまることが分かっています。着手できない最大の理由として挙げられたのは「他の案件で要員を割けない」（39.9%）でした。

実際に何が起きたのか：報道された事例

基幹システム刷新の失敗は、時として大きな金銭的損失や訴訟にまで発展します。ここでは実際に報道された事例を紹介しますが、係争中の案件については判決が確定していない点にご留意ください。

文化シヤッター×日本IBM：カスタム比率が想定の5倍近くに膨張（判決確定）

2015年に文化シヤッターが日本IBMに委託した新しい販売管理システムの開発が頓挫した事案です。報道によると、当初想定していたカスタマイズ比率は20%程度でしたが、実際には95%まで膨張し、開発の進捗が50%程度の段階で行われた結合テストでは、標準的な欠陥件数467件を大きく上回る770件の欠陥が検出されたとされています。2025年1月10日、最高裁判所が上告を棄却し、日本IBMに約20億564万円の賠償を命じる判決が確定しました。

江崎グリコ：SAP S/4HANA移行後にシステム障害（2024年）

2024年4月3日、江崎グリコの基幹システム（SAP S/4HANA）移行後に、在庫の不整合や受注処理の遅延といったシステム障害が発生しました。当初215億円だった投資額は342億円まで増加し、完了時期も延期されています。この障害の影響で、2024年12月期の業績は売上高で約150億円の下方修正を余儀なくされました。

京都市×システムズ：一審判決も双方控訴中

京都市の基幹系システム刷新が頓挫し、京都市とシステムズ社の間で提訴合戦に発展した事案です。2024年2月29日の東京地裁一審判決では、京都市がシステムズに約1億9,900万円、システムズが京都市に約4億9,300万円を支払うよう命じられ、双方に責任があるとする判断（責任割合は双方50%）が示されました。ただし両者が控訴しており、本記事執筆時点では確定した判決ではありません。

日本通運×アクセンチュア：154億円の減損に至った事案（係争中）

2017年に開始された日本通運の「新・国際航空貨物基幹システム」開発プロジェクトは、当初約123億円と見積もられていましたが頓挫し、2022年12月期に約154億円の減損処理が行われ、2023年に開発が断念されました。日本通運は2023年7月、約124億9,100万円の損害賠償を求めてアクセンチュアを提訴していますが、本記事執筆時点で判決は確認できていません。

失敗パターンに共通する要因

これらの事例や公的機関の指摘を踏まえると、基幹システム刷新の失敗には共通する要因が見えてきます。

  • カスタマイズ（アドオン開発）のしすぎ：文化シヤッターの事例のように、パッケージソフトの標準機能から大きく外れたカスタマイズを重ねると、開発規模が想定を大幅に超え、品質低下やコスト増を招きやすくなります
  • 要件定義の不備：IPAが公表している「システム再構築を成功に導くユーザガイド」では、現行システムの調査や要件定義といった上流工程を重視することの重要性が強調されています
  • 経営層の関与不足・専任リソースの不足：前述のとおり、「他案件で要員を割けない」ことが刷新の停滞要因として最も多く挙げられています

成功事例：ライオンの基幹システム刷新

一方で、大規模な基幹システム刷新に成功した事例もあります。日用品メーカーのライオンは、2018年に開始した「プロジェクト・レグルス」で、約40年使用してきた基幹システムをSAP S/4HANAへ全社一斉に刷新する「ビッグバン導入」を行い、2022年5月に完了させています。成功要因として、BPR（業務プロセス改革）推進部を設置し各部門にBPRリーダーを配置したこと、段階的ではなく全社横断で一括刷新する方針を明確にしたこと、そしてライオン・システム開発会社JSOL・SAPの三者が常時情報を共有する専用のプロジェクトルームを設けたことが挙げられています。

失敗を避けるための進め方

IPAのガイドでは、一般的には「全体を一度に刷新するのはリスクが高い」として段階的な刷新を推奨しています。ただし、ライオンの事例が示すように、体制と情報共有の仕組みが整っていれば、全社一括のビッグバン導入で成功するケースもあります。段階的にするか一括にするかは、自社の体制に応じて慎重に判断すべきポイントといえます。共通して重要なのは次の点です。

  • アドオン開発は最小限に抑える：パッケージソフトの標準機能をできるだけ活かし、独自カスタマイズは本当に必要な範囲に絞る
  • 要件定義に十分な時間をかける：現行業務の調査・要件定義といった上流工程を軽視しない
  • 経営層が関与し、専任のリソースを確保する：現場の片手間ではなく、専任の推進体制を用意する
  • ベンダー・開発会社との情報共有の仕組みを作る：ライオンの事例のように、常時情報を共有できる体制を整える

ERP・PLMといった基幹システムに関わる仕組みの違いについては、別記事「PLMとは何か？ERP・PDMとの違いをわかりやすく整理」もあわせてご覧ください。

よくある質問

Q. 基幹システム刷新の訴訟事例は、どちらか一方だけに責任があるのですか？

京都市の事案のように、裁判所が発注者・受注者の双方に責任があると判断するケースもあります。要件定義の詰めが甘かった発注者側の責任と、開発を管理しきれなかった受注者側の責任の両方が問われることは珍しくありません。

Q. パッケージソフトのカスタマイズは、どこまでなら安全ですか？

明確な基準はありませんが、文化シヤッターの事例のようにカスタマイズ比率が当初想定を大きく超えていくこと自体が危険信号です。カスタマイズの範囲が広がりそうになった時点で、本当に必要かどうかを都度立ち止まって見直す運用ルールを設けることが有効です。

Q. 中堅・中小企業でも大企業のような専用プロジェクトルームは必要ですか？

専用の物理スペースまでは必要ありませんが、「発注者・開発会社が定期的に、かつ密に情報共有する場を持つ」という考え方自体は、企業規模を問わず重要です。オンライン会議やチャットツールでも代替は可能です。

Q. 訴訟にまで発展した事例を知ることに、実務上どんな意味がありますか？

個別の勝敗よりも、「どのような経緯で問題が拡大したか」というプロセスを知ることに価値があります。文化シヤッターの事例であればカスタマイズ比率の膨張、江崎グリコの事例であれば移行後の運用トラブルというように、それぞれ異なる段階でつまずいています。自社のプロジェクトが今どの段階にあり、どのリスクに注意すべきかを考える参考になります。

参考にした主な調査・資料

まとめ

基幹システム刷新は、成功すれば大きな効果を生む一方、失敗すれば数十億円規模の損失や訴訟に発展することもある、リスクの大きいプロジェクトです。カスタマイズを抑え、要件定義に十分な時間をかけ、経営層が関与する専任体制を整えることが、失敗を避けるための共通したポイントです。

Post Views: 103
ERP システム刷新 基幹システム 大企業DX