2026.08.10 Webシステム

基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解

基幹システムの刷新が失敗したとき、その事実は決算開示か判決文という形で外に出ます。江崎グリコは2024年4月3日の全面移行で出荷が止まり、同年5月8日に通期の売上高予想を150億円下方修正しました。特許庁は約54億5千万円を投じた開発を2012年1月に中断しています。この記事では公表された一次記録からグリコ・ユニ・チャーム・特許庁の3事例と、スルガ銀行・旭川医科大学・野村ホールディングスの3判決を工程別に分解し、要件定義・切替・現場定着のどこで何を潰しておけば避けられたのかを発注者の視点で示します。

まとめ：基幹システム刷新の失敗が現れる三つの地点と着手前に決める回避策

公表事例をたどると、失敗が表面化する地点は三つに絞られます。第一に要件定義の終わり方。仕様を凍結した後に変更要求を出し続けたプロジェクトは、旭川医科大学と野村ホールディングスの二件とも発注者側が敗訴しました。第二に切替直後の数時間から数日。グリコもユニ・チャームも、基幹システム本体ではなく物流システムとの接続点と処理件数で詰まっています。第三に稼働後の現場運用です。

この三地点に対する打ち手は、いずれも契約書に署名する前に決まります。仕様凍結日と凍結後の変更受付条件を個別契約に書くこと。移行リハーサルの合格条件を「本番と同じ受注件数・品目数を、本番と同じ時間帯で流し切れること」と数値で定義すること。そして未解決の障害が残ったまま稼働日を迎えそうなら、切替を延期する権限を誰が持つかを先に決めておくこと。この三つを外した状態で着手した案件は、規模を問わず同じ壊れ方をしています。

江崎グリコとユニ・チャームの2024年事例が示す切替直後の出荷停止の起点

2024年は、国内の大手メーカー2社が基幹システムの切替直後に出荷を止めた年でした。どちらも技術的に無謀な計画ではありません。それでも止まった理由が、開示資料に具体的に書かれています。

2024年4月3日の全面移行から出荷停止までの経緯と業績予想の修正幅

江崎グリコが2024年5月8日に開示した資料によれば、同社は調達・生産・物流・ファイナンスの情報を統合する基幹システムを構築し、2024年4月3日にそのシステムへ全面的に移行しました。切替時に発生した障害で全国の物流センターの出荷業務に遅滞が生じ、チルド食品とキリンビバレッジから販売受託しているチルド商品で遅配・欠配が発生します。同社は4月14日から出荷を一時停止し、4月18日に一部を再開しました。

ところが再開後、物流センターでの出荷に関するデータの不整合が発生したうえ、想定を超える受注品目数に対して処理が間に合わず、4月19日から再度停止に追い込まれます。常温と冷凍のカテゴリーは出荷を続けていたため、システム全体が停止したわけではありません。止まったのはチルドという一部の商品群だけです。それでも同社は2024年12月期の通期連結業績予想を、売上高3,510億円から3,360億円へ150億円、営業利益190億円から140億円へ50億円下方修正しました。営業利益の減少率は26.3%です。全品出荷の状態に戻ったのは、同社が2024年12月6日に公表したとおり11月5日の出荷再開分でした。切替から復旧まで7か月かかっています。

ユニ・チャームで起きた基幹と物流システムのデータ連携不具合という共通点

同じ2024年、ユニ・チャームもゴールデンウイークに実施した基幹システム更新で出荷遅延を起こしました。日経クロステックの報道によれば、新しい基幹システムと物流システムの接続でデータ連係に不具合が生じたことが原因です。同社は5月16日に一部商品の出荷遅延を告知し、6月3日時点でデータ連係の不具合と処理の遅延はおおむね解消したものの、一部のEC直営店は休店が続きました。

二社に共通するのは、障害が起きた場所です。基幹システムの内部ロジックではなく、基幹と物流をつなぐ接続点で詰まっています。基幹システムそのものの構成領域については基幹システムと業務システム・ERPの違いと構成領域の側で整理していますが、刷新の実務で先に壊れるのは、その構成図では線1本で描かれている部分です。連携先を持たない単体システムの刷新と、同じ難易度で見積もってはいけません。

二つの事例に共通する本番相当の受注件数を想定しない負荷見積りの穴

グリコの開示にある「想定を超える受注品目数に対し処理が間に合わず」という一文は、テスト設計の失敗を端的に示しています。機能テストは通っていたはずです。通らなければ本番切替を承認しません。通らなかったのは、本番と同じ量を流したときの処理性能でした。

受注件数と品目数は、切替直後に跳ね上がる性質を持ちます。停止のアナウンスを受けた取引先が復旧を見越して発注をためるためです。つまり切替直後に必要な処理能力は、平常月の平均ではなく、停止明けのピークで測るべき数値になります。ERPを新規導入する場面で起きる失敗の型はERP導入でよくある失敗例と教訓にまとめていますが、既存の基幹システムを入れ替える案件では、既に流れている実データの量そのものが最大のリスク要因です。

特許庁の開発中断が示す発注者側の管理能力不足と体制規模の失敗要因

切替に至らず、開発の途中で止まった案件もあります。公的機関の案件は検証結果が公表されるため、内部で何が起きていたかを追えます。

2006年の入札から2012年1月の中断までに投じた開発費の規模

情報システム学会が2013年3月22日に公表した提言資料「政府のソフトウェア調達の改善について」によれば、特許庁は平成18年(2006年)7月に基幹システムの設計・開発業務を落札させ、同年12月には管理支援業務の契約を別に締結しました。開発が終わらないまま時間が過ぎ、平成24年(2012年)1月に技術検証報告書が提出されて開発中断が発表されます。同資料は開発費を約54億5千万円、管理支援側の受注額を24億8,700万円と記しています。

着目したいのは中断までの年数です。2006年の発注から2012年の中断まで、5年以上にわたって走り続けています。途中で止める判断が働かなかったこと自体が、この案件の失敗の核でした。

管理費が総費用の26%を占めながら統制が効かなかった1300名体制

同じ提言資料は、特許庁の案件でプロジェクト管理費が総費用の26%を占めていたと指摘しています。JUAS調査による平均は9.7%ですから、管理に平均の3倍近い費用をかけていた計算です。それでも投入人員は1,300名規模に膨れ、意思疎通が成立しない状態に陥ったと同資料は分析しています。

管理費を積めば統制が効くわけではない、という事実がここにあります。効くのは、決定を下せる人が発注者側にいるかどうかです。自社に大規模案件の管理経験が無い場合、ITコンサルティングの種類と費用相場・依頼先の選び方で整理しているような第三者の管理支援を入れるのも選択肢の一つです。ただし管理支援を入れても、要件を決める権限と中止を判断する権限は発注者に残ります。ここを渡した瞬間、特許庁の案件と同じ構図になります。

訴訟に至った刷新プロジェクト3件の判決が分けた発注者と受注者の責任

刷新が破綻して訴訟になった案件では、裁判所がどちらの落ち度かを判断します。この判断基準は、発注者が自分の振る舞いを点検する物差しとして使えます。3件の判決は、発注者の勝敗をきれいに分けました。

スルガ銀行事件で認定されたベンダーのプロジェクト管理義務違反と減縮された賠償額

スルガ銀行が日本IBMに損害賠償を求めた事件で、東京高裁は2013年9月26日に判決を出しました。同行の開示によれば、認容額は41億7,210万3,169円。第一審の74億1,366万6,128円から減縮されたものの、ベンダー側の責任は認められています。日本IBMが提起した125億5,198万4,823円の反訴請求は全面的に棄却されました。この判決は2015年7月8日の最高裁決定で確定しています。

争点はベンダーのプロジェクトマネジメント義務でした。実現できないと分かった時点で中止を提言する責任が問われた形です。発注者の立場で読み替えるなら、ベンダーから「このままでは間に合わない」と告げられた記録が残っているかどうかが、後から効いてきます。

旭川医科大学事件で発注者の協力義務違反が全責任とされた逆転の分岐点

電子カルテシステムの開発をめぐる旭川医科大学とNTT東日本の事件では、札幌高裁が平成29年(2017年)8月31日に、旭川医科大学へ14億9,744万8,554円の支払いを命じました。第一審が認めた過失割合2対8が、高裁で10対0へ逆転した判決です。ベンダーのプロジェクトマネジメント義務違反は否定されました。

分岐点は、仕様確定後に発注者が大量の追加要望を出し続けた点にあります。裁判所はこれを発注者の協力義務違反と評価しました。刷新プロジェクトで現場から要望が上がり続ける状況は、珍しくありません。それを制御せずベンダーへ流し続けた場合、遅延の責任は発注者側に帰属しうる。この判決はその線を引きました。

野村ホールディングス事件が示す仕様凍結後も続いた変更要求という敗因

野村ホールディングスと野村證券が日本IBMを訴えた事件でも、東京高裁は令和3年(2021年)4月21日に第一審を覆しました。ラップ口座向けのフロントシステムで、スイスTemenos社のパッケージをカスタマイズする構成です。第一審は日本IBMに支払いを命じていましたが、高裁は野村側の請求を棄却し、逆に未払いの委託料を野村側が支払うよう命じました。野村側が上告を取り下げて確定しています。

高裁が失敗の原因と見たのは、仕様凍結後も繰り返された変更要求でした。旭川医科大学の事件と同じ構図です。パッケージを採用しながら現行業務に合わせて変更を積み上げる進め方は、費用と期間の膨張だけでなく、法的な責任の所在まで発注者側へ寄せます。

判決と事例から逆算した要件定義と変更管理の工程で先に潰しておく論点

3件の判決が示した敗因は、いずれも要件定義工程の終わり方に集約されます。ここで決めておくべきことは、具体的な文書の形にできます。

現行踏襲の範囲を決める判断ラインとパッケージ標準に寄せる線引き

刷新の要件定義でまず割れるのが、現行機能をどこまで残すかです。判断ラインは一つ。その機能が競合との差になっているかどうかです。差にならない業務、たとえば債権消込の画面遷移や帳票の並び順は、パッケージの標準に寄せます。差になる業務、たとえば自社固有の受注区分や原価配賦の考え方だけを個別開発の対象に残す。

この線引きを先送りしたまま設計に入ると、現場ヒアリングで挙がった機能が全部要件に入ります。野村ホールディングスの事件はパッケージ採用案件でした。標準に寄せる前提で選んだはずのパッケージへ変更を積み上げれば、パッケージを選んだ意味が消えます。線引きは、要件定義の開始前に経営層の承認を得た文書として持っておきます。

仕様凍結日と変更要求の受付条件を個別契約に書き込む実務上の手順

仕様凍結は、宣言するだけでは機能しません。凍結後に上がってきた要望を止める根拠が要るからです。個別契約に書き込むのは次の4点です。

  1. 仕様凍結の日付と、凍結対象となる成果物の名称
  2. 凍結後の変更要求を受け付ける条件（法令改正・重大な業務上の不備に限る等）
  3. 変更要求ごとに費用と期間の再見積りを提示し、発注者が承認するまで着手しない手順
  4. 変更要求を承認する権限を持つ発注者側の役職名

4点目を空欄にした案件が、いちばん危険です。権限者が定まっていないと、現場から出た要望が誰の承認も経ずにベンダーへ届きます。旭川医科大学の事件で協力義務違反とされたのは、まさにこの状態が続いた結果でした。

判決が証拠として重視した議事録と課題管理表という記録の残し方の基準

3件の判決はいずれも、当時のやり取りの記録に基づいて責任を判断しています。会議の議事録、課題管理表、リスクの報告メール。これらが揃っていない側は、自分の主張を裏づけられません。

残し方の基準は二つあります。会議で決めたことは、決定事項・保留事項・次回までの担当を分けて当日中に共有し、相手の同意を文面で得ること。もう一つは、遅延やリスクの兆候を課題管理表へ番号付きで登録し、放置日数が見える状態にすること。「言った・言わない」を防ぐためではありません。プロジェクトが傾き始めた時点を後から特定できるようにするためです。

データ移行と周辺システム連携で切替直後に露見する不整合を防ぐ設計

要件定義を乗り切っても、グリコとユニ・チャームが詰まった地点が残っています。切替直後の数日間です。ここでの打ち手は、テスト設計と切替方式の二つに分かれます。

移行リハーサルを本番同等の件数と品目数で回すときの設計と合格条件

移行リハーサルの合格条件は、機能が動いたことではありません。次の3つを満たしたときに合格とします。

  • 本番と同じ件数・品目数の実データを、本番と同じ時間帯・同じ順序で流し切れた
  • 移行前後で件数・金額・残高の突合が全件一致した
  • 切戻し作業を含めた全工程が、業務停止に使える時間枠に収まった

1つ目の「本番と同じ件数」は、平常時の平均ではなく実績の最大月で測ります。グリコの再停止は、想定を超える受注品目数に処理が追いつかなかったことが引き金でした。件数を絞ったリハーサルは、この失敗を検出できません。3つ目の切戻しを含める点も外せない条件です。切戻しの所要時間を測っていなければ、当日は戻る判断ができなくなります。

基幹と物流や会計をつなぐ接続点ごとに置く受入テストの観点と件数

接続点のテストは、システム単位ではなく接続点単位で設計します。基幹と物流、基幹と会計、基幹とEC、基幹と取引先のEDI。それぞれについて、送信側の出力仕様と受信側の取り込み仕様を突き合わせ、片方だけ変わっていないかを確認します。

見落としが起きやすいのは、コード体系の桁数と、日付・数量の丸め規則です。旧システムが8桁で扱っていた商品コードを新システムが10桁にした場合、物流側が8桁のまま動いていれば取り込みで落ちます。ユニ・チャームの事例で問題が出たのも、基幹と物流の連係部分でした。接続点ごとに、正常系だけでなく異常データを含む件数を決めてテストします。

一斉移行と段階移行の選び分けと切り戻しを判断する期限と基準の置き方

切替方式の判断軸は、業務を止められる時間の長さです。止められる時間が48時間未満で、かつ連携先が3系統を超えるなら、一斉移行は避けるべきです。拠点別・業務別に区切った段階移行へ変えるか、旧システムを一定期間並行稼働させる設計に切り替えます。移行方式そのものの違いと費用感はマイグレーションとリプレイス・モダナイゼーションの違いと発注判断で比較しています。

どちらを選ぶ場合も、切戻しの判断期限を先に決めます。「切替開始から◯時間の時点で、受注取り込みが完了していなければ旧システムへ戻す」という形です。期限を決めていない案件は、必ず粘ります。粘った結果が、グリコの4月18日の一部再開と翌19日の再停止でした。

稼働日を優先して切替を強行すべきでない三つの条件と延期の判断基準

ここからは判断を言い切ります。次の3条件のいずれかに当たるなら、稼働日を動かしてください。年度初めや期首に合わせた日程は、業績への影響と比べれば軽い制約です。

移行リハーサルで未解決の障害が残った状態で切替日を動かす判断基準

第一の条件は、直前のリハーサルで再現性のある障害が残っていることです。原因が特定できていない障害が1件でもあれば、本番では同じ場所で止まります。「本番では起きないはず」という説明は根拠になりません。

ここでの判断基準は単純です。残存障害のうち、業務停止につながる区分のものがゼロになっていない限り切替を承認しない。この基準を稼働日の2週間前に一度評価し、満たなければその時点で延期を決めます。当日朝に判断すると、既に取引先へ告知した後になり、動かせなくなります。

発注者側に専任の責任者を置けない案件へ着手すべきでない理由と条件

第二の条件は、発注者側に専任の責任者がいないことです。兼任では務まりません。要件の取捨選択、変更要求の可否、切替の実行判断という3種類の決定が、プロジェクト期間中ずっと発生し続けるためです。特許庁の案件が5年以上止まらなかったのは、この決定を下す主体が曖昧だったからだと考えられます。

専任者を置けないなら、着手しない。もしくは対象範囲を1業務に絞り、決定の量そのものを減らす。この二択です。要件定義から移行リハーサルの実施までを外部の受託開発会社と組んで進める場合も、システムマイグレーション・リプレイスの支援のような形で設計と移行作業を任せられる範囲と、自社に残す決定権限を契約前に線引きしておきます。刷新に着手すべきかどうかという手前の判断はレガシーシステム脱却の判断基準と進め方で扱っています。

延期を決めたあとに再設定する稼働日と現場や取引先への説明の順序

第三に、延期を決めた後の進め方です。新しい稼働日は、残存課題の解消見込みが立ってから設定します。「1か月後」と先に置くと、同じ状態でもう一度期日を迎えます。説明の順序は、社内の運用部門、次に物流や決済でつながる取引先、最後に一般の顧客向け告知という順です。

並行稼働を選んだ場合は、旧システムの停止日を延期と同時に決めて周知します。停止日が決まっていないと、現場は使い慣れた旧システムへ戻ります。JUASの「企業IT動向調査2025」速報値では、2025年度のIT予算増加理由として「基幹システムの刷新」を挙げた企業が44.5%と、前年の40.1%から4.4ポイント増えました。刷新に取り組む企業が増えるほど、稼働日を優先して押し切った案件の失敗も表に出やすくなります。

よくある質問

基幹システムの刷新を検討する担当者から寄せられることの多い質問を、公表事例と判決の内容に沿って5つ整理しました。

基幹システム刷新の失敗率はどのくらいですか？

公的機関が「刷新プロジェクトの失敗率」を単独で集計した統計は、2026年8月時点で公表されていません。近い指標としては、JUASの「企業IT動向調査」がシステム開発プロジェクトの工期・予算・品質の遵守状況を継続調査しており、2015年度から2024年度の10年推移ですべての規模で「予定どおり完了」の割合が下がる傾向を示しています。数値を根拠に安心するより、自社の案件が本記事で挙げた三つの失敗地点のどれに近いかを点検するほうが実務的です。

江崎グリコのシステム障害は結局いくらの損失になったのですか？

同社が2024年5月8日に開示した通期連結業績予想の修正では、2024年12月期の売上高を3,510億円から3,360億円へ150億円、営業利益を190億円から140億円へ50億円引き下げました。営業利益ベースで26.3%の減少です。この時点では出荷再開時期が未確定とされており、全品出荷の状態に戻ったのは同社が12月6日に公表したとおり11月5日の出荷再開分でした。切替日の4月3日から数えて約7か月です。

刷新プロジェクトが訴訟になった場合、発注者とベンダーのどちらが不利ですか？

一律には決まりません。スルガ銀行の事件ではベンダーのプロジェクトマネジメント義務違反が認められて41億7,210万円余りの支払いが命じられた一方、旭川医科大学の事件では発注者の協力義務違反が認定され、過失割合が10対0で発注者側に14億9,744万円余りの支払いが命じられています。分かれ目は、仕様確定後に変更要求を出し続けたかどうかと、当時の記録が残っているかどうかでした。

移行リハーサルは何回実施すれば足りますか？

回数ではなく到達点で判断します。本番と同じ件数・品目数のデータを本番と同じ時間枠で流し切り、移行前後の突合が全件一致し、切戻しまで含めて時間枠に収まった回が1回あれば足ります。逆に、件数を絞った予行演習を5回重ねても合格とは言えません。実務では、条件を満たさない回が続く前提で2回から3回ぶんの日程を確保しておく組み方をします。

刷新の失敗を避けるために、稼働日はどのくらい余裕を見るべきですか？

期首や年度初めに合わせた稼働日を置く場合でも、リハーサル完了から本番切替まで最低2週間は空けます。この2週間は、残存障害の解消と、延期を判断するための評価期間に充てます。切替日の直前にリハーサルを置く日程は、問題が見つかっても動かせない構造になるため避けてください。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る