この記事の要点
- 01公表された失敗は切替やテストで表に出たが、原因の種類は計画段階で置く前提だった
- 02調査でも「計画時の考慮不足」と「現行業務の複雑さ」が、品質未達の要因の上位に並ぶ
- 03目的・現行調査・標準との線引き・切替・変更の止め方の5つを、要件定義の前に決める
目次8項目
2024年4月3日、江崎グリコは新しい基幹システムに全面移行しました。その直後から全国の物流センターで出荷が滞り、4月14日にはチルド食品の出荷を止めています。チルド商品が障害前の全品出荷の状態に戻ったのは、11月5日でした。報道によれば、切り替えた先はSAPのERPパッケージ「SAP S/4HANA」です。
同じ年の大型連休には、ユニ・チャームも基幹システムを更新し、紙おむつなどの納品遅れを起こしました。こちらも報道によれば、更新した基幹システムはSAP S/4HANAでした。
こうした失敗が表に出るのは、本番切替やテストの段階です。ただ、公表された説明や判決を読むと、原因は、もっと前の計画段階で置く前提に行き着きます。SAP導入の成否は、要件定義に入る前に置く5つの判断で、かなりの部分が決まると筆者は考えています。 何のために導入するのか。現行の業務をどこまで調べたか。標準に合わせる範囲をどこで線引きするか。切り替えをどう進め、どう戻るか。仕様を固めたあとの変更を誰が止めるか。この5つです。
公表情報で確かめられる事例は、ネット上の「失敗企業一覧」より少ない
「SAP 失敗 企業一覧」と検索すると、多くの社名が並んだ記事が見つかります。ここでは、会社自身の開示、決算説明の記録、判決と、それを取材した報道で、原因までさかのぼれたものに絞ります。今回たどれたのは次の3件で、うち1件はSAPではありません。
| 会社 | 時期 | 起きたこと | 公表された影響 | 製品 |
|---|---|---|---|---|
| 江崎グリコ | 2024年4月 | 基幹システム切替後に出荷が滞り、チルド食品の出荷を停止 | 2024年12月期の連結売上高予想を150億円引き下げ | SAP S/4HANA（報道） |
| ユニ・チャーム | 2024年5月 | 基幹システム更新後に紙おむつなどの納品が遅延 | イレギュラーに発生した物流費約4億円を計上（決算説明会の質疑） | SAP S/4HANA（報道） |
| 野村ホールディングス・野村證券 | 2010〜2012年 | パッケージを使ったシステム開発を中止し、開発を委託した日本IBMと訴訟 | 控訴審で野村側の請求は棄却され、判決は確定 | 海外製パッケージ（SAPではない） |
野村の事案はSAPの導入ではありません。それでも、パッケージを使ったシステム開発がなぜ止まったのかについて、裁判所の事実認定を公開資料で読めるので、あわせて取り上げます。
注意
ネット上の「失敗企業一覧」には、原因を一次情報で確かめにくい社名もあります。自社の判断材料にするなら、会社の開示や判決までさかのぼって確かめてください。
江崎グリコ：統合の目的は明確でも、切替後の処理量で止まった
江崎グリコは、新しい基幹システムの目的を「バリューチェーン構築と経営の迅速な意思決定」と説明しています。調達・生産・物流・ファイナンスなどの情報を統合するシステムです。会計にとどまらず、会社全体の情報をつなぐ土台としての刷新でした。
2024年5月1日と8日の同社の開示によると、4月3日の全面移行のあと、物流センターでの出荷業務が遅れ、一部の取引先で遅配や欠配が起きました。4月14日にチルド食品の出荷をいったん止め、18日に一部を再開します。ところが出荷に関するデータの不整合が起き、想定を超える受注品目数に処理が追いつかず、19日に再び止めました。5月8日には、2024年12月期の連結業績予想を、売上高3,510億円から3,360億円に、営業利益190億円から140億円に引き下げています。売上高で150億円の減額です。
開示に書かれた原因は、データの不整合と、想定を超える受注品目数でした。どちらも、画面や帳票の要件とは別の話です。移行するデータの整え方と、本番で処理する量の前提に関わります。
ユニ・チャーム：物流とのつなぎ目に連休明けの注文が重なり、処理が追いつかなかった
日経クロステックの報道によると、ユニ・チャームは2024年の大型連休を使ってシステムを更新しました。新しい基幹システムと物流システムの間で、データ連係に不具合があったとされます。そこへ連休明けの大量の注文でデータが増え、処理が追いつかずに納品が遅れたと報じられています。6月3日までに不具合と処理の遅れはほぼ解消しました。
同社は2024年12月期の中間決算説明会の質疑で、基幹システムのトラブルの影響として計上しているのは、イレギュラーに発生した物流費の約4億円だと答えています。人手で対応したため、労働時間が延びて人件費も増えたとしています。
ここでも問題が出たのは、周辺システムとのつなぎ目と、切替直後の処理量でした。
野村HD対日本IBM：変更要求が止まらず、計画が崩れた
野村證券は、投資一任サービスを支えるシステムの開発を日本IBMに委託しました。IBMが提案して採用されたのは、スイスのテメノス社のパッケージを使う案です。経緯は、一般財団法人ソフトウェア情報センター（SOFTIC）の判例ゼミ資料が、裁判の認定をもとに整理しています。
2011年4月から、野村證券の変更要求が出はじめます。追加のカスタマイズの要求は止まりませんでした。IBMは2011年12月に新たな変更要求の凍結を求めましたが、翌年2月にも新たな変更要求が出ています。2012年8月、IBMはスケジュールと品質にリスクがあると通知しました。野村證券はコンティンジェンシープラン（不測の事態に備えた代替策）を発動して総合テストを中止し、11月に開発の中止を通告しています。
東京地裁（2019年3月20日判決）は、IBMに約16億円の支払いを命じました。これに対し東京高裁（2021年4月21日判決）は、野村側の請求を棄却し、反対に野村ホールディングスがIBMに約1億1,224万円を支払うよう命じています。高裁は、IBMが工数削減の努力や変更要求の凍結の要請など、可能な範囲でプロジェクト管理をしていたと認めました。そのうえで、野村側が基本設計に入ったあとも変更要求を繰り返し、計画が崩れたと判断しています。その後、野村側が上告を取り下げ、高裁の判決が確定したことが2021年12月に報じられました。
3件とも、問題が出たのは切替とテストでも、原因の種類は計画段階の前提だった
3つの事例で問題が表に出たのは、本番の切替直後か、テストの段階です。一方、公表された説明に出てくる原因は、処理量の想定、周辺システムとのつなぎ目、データの整え方、止まらない変更要求でした。
これらはどれも、計画の段階で前提を置くべき事柄だと筆者は考えています。要件定義の個々の議論より前の話です。本番で1日に何品目の受注をさばくのか。どの周辺システムとどうつなぐのか。いつ、どの順番で切り替えるのか。仕様を固めたあとの変更は誰が決めるのか。こうした前提が空いたまま要件定義に入ると、要件定義そのものは進んでも、切替の直前まで誰も確かめない領域が残ります。
公表された情報から、各社の内部の判断までは分かりません。ここで言えるのは、公表された原因の種類が、計画段階で置く前提に属するものだったという点までです。
問題が表に出たのは切替とテスト。原因の前提は、計画の段階で置ける種類のものだった
SAP S/4HANA（報道）
SAP S/4HANA（報道）
SAPではない
公表情報から読み取れる原因の種類を示したもので、各社の内部の判断は公表されていない。
3件とも、問題が表に出た工程と、原因にあたる前提を置けた工程は離れている。公表された原因は、どれも計画の段階で前提を置ける種類のものだった。
ポイント
自社の計画書に、本番の処理量、周辺システムとの連携、切替の段取り、変更の決め方の前提が書かれているかを確かめてください。
業界団体の調査でも、計画と現行業務の把握に関わる要因が上位に並ぶ
個別の事例だけではありません。日本情報システム・ユーザー協会（JUAS）は「企業IT動向調査報告書2026」（2025年度調査）で、システム開発の工期がどれだけ守られたかをプロジェクトの規模別に集計しています。
| プロジェクトの規模 | 予定どおり、または予定より早く完了 | ある程度は予定どおり完了 | 予定より遅延 |
|---|---|---|---|
| 10人月未満 | 50.6% | 39.8% | 9.6% |
| 10〜50人月未満 | 36.9% | 46.9% | 16.2% |
| 50〜100人月未満 | 25.3% | 49.3% | 25.4% |
| 100〜500人月未満 | 20.2% | 41.0% | 38.8% |
| 500人月以上 | 19.9% | 32.3% | 47.8% |
500人月以上では、半数近くが予定より遅れています。規模が大きいほど、計画は崩れやすくなります。SAPに限った数字ではありません。
同じ調査で、2025年度に品質が予定どおりにならなかった要因として挙がったのは次のとおりです。
| 要因 | 回答の割合 |
|---|---|
| ベンダーのスキル不足 | 59.9% |
| 計画時の考慮不足 | 48.8% |
| 想定以上の現行業務・システムの複雑さ | 48.8% |
| 社員のスキル不足 | 44.8% |
| 仕様変更の多発 | 30.2% |
最も多いのはベンダーのスキル不足です。それに次ぐ「計画時の考慮不足」と「想定以上の現行業務・システムの複雑さ」は、筆者の見るところ、どちらも要件定義に入る前に手を打てる要因です。発注側の社員のスキル不足も44.8%ありました。工期の悪化に影響している傾向としては「システム影響範囲の拡大」48.9%と「要件定義の難易度上昇」46.6%が上位に並び、「要件定義の時間不足」も36.8%ありました。
ベンダーのスキル不足を避ける手立ては、パートナーを選定する段階にあります。同じ規模、同じ業務の導入経験を、会社の実績でなく、実際に担当する人の単位で確かめてください。
情報処理推進機構（IPA）と経済産業省も、2020年に公表した「情報システム・モデル取引・契約書」第二版の解説で、同じ点を指摘しています。既存のシステムを作り直すときは、要件定義に入る前に現行システムを調べ、仕様を明らかにしておく必要がある、という指摘です。調査が不十分なまま作り直しに着手し、後の開発段階でトラブルに陥った事例が多数報告されているとも書かれています。いまのシステムをそのまま作り直すだけだと考える発注側には、この意識が薄いという記述もあります。
ポイント
計画時の考慮不足 48.8%、現行業務・システムの複雑さ 48.8%。ベンダーのスキル不足（59.9%）に次ぐ2つの要因です。
要件定義の前に、発注側が決めておく判断は5つある
事例と調査から逆算すると、発注側が要件定義の前に決めておくべき判断は次の5つです。
5つの判断には、決める人と、決めないまま進んだときに表に出る問題がある
5つとも、要件定義に入る前に、責任者の名前で決めておく。公表された事例の裏付けが厚いのは、2と4と5の判断。
1. 目的を、測れる言葉と責任者で書く
「基幹システムの刷新」は手段です。刷新して何を変えるのかを、測れる言葉で書きます。月次決算を何営業日で締めるのか、利益をどの単位で見るのか、在庫をどの頻度で把握するのか。それぞれに責任者を置きます。JSUGとSAPジャパンがまとめた「ERP導入の羅針盤」は、1990年代後半からERPを導入した日本企業を振り返っています。本来の目的だったリアルタイム経営やデータを活用した経営を実現している企業は必ずしも多くない、という見立てです。そのうえで、指針の最初の軸に「目的」を置いています。会計の目的を決算の日数から組み立てる考え方は、決算早期化の実装支援で紹介しています。
2. 現行の業務とシステムを、要件定義の前に調べる
IPAの指摘どおり、調べるのは要件定義の前です。見るべきは、規程や業務フロー図に書かれた正式な手順だけではありません。月末だけの手作業、例外的な取引の処理、周辺システムとやり取りするデータの本数と件数、そしてピーク時の取引量です。
量の前提は、とくに見落とされやすいと筆者は考えています。江崎グリコの開示にあった「想定を超える受注品目数」も、ユニ・チャームで報じられた「連休明けの大量の注文」も、量が前提を超えた場面でした。現行の実績を数えておかなければ、本番でどれだけの量をさばけばよいのか、誰も前提を置けません。繁忙期、月末、連休明けといった山の高さまで、過去の実績から拾っておきます。
3. 標準に合わせる範囲と、合わせない範囲を経営が決める
SAPは、業務のひな型となる標準の業務プロセスを備えたパッケージです。それに業務を合わせるのか、自社の業務に合わせて追加開発するのかは、一件ずつ判断することになります。この判断を現場の要望の積み上げに任せると、カスタマイズは増え続けます。どの領域は標準に合わせ、どの領域は自社の強みとして作り込むのか。その線を、要件定義の前に経営が引いておきます。追加開発を判定する場の置き方と、費用への効き方は、SAP導入の費用の記事で整理しています。
4. 切替の方式、時期、戻り方を先に決める
一度に全部を切り替えるのか、会社や業務ごとに段階を踏むのか。切替日を繁忙期や大型連休の明けに置いてよいのか。本番と同じ量のデータで処理時間を確かめるテストを、いつ誰がやるのか。そして、切替後に問題が出たとき、旧システムに戻すのか、手作業でしのぐのか。
こうした判断は、切替の直前に決めるには重すぎると筆者は考えています。ユニ・チャームの事例では、連休を使った更新の直後に注文の山が来ました。切替日を決めるときに、切替直後にどれだけの量が流れ込むかを確かめておけば、テストで試すべき量も決まります。戻り方も同じです。野村の事案では、野村證券がコンティンジェンシープランを発動し、新しいシステムの代わりに現行システムを暫定的につなぐ道を選びました。筆者は、代わりの道が用意されていたからこそ、開発を止める判断ができたと見ています。
5. 変更を決める人と、止める手順を置く
仕様を固めたあとに出てくる変更要求を、誰が受け付け、誰が可否を決め、追加の費用と日程を誰が承認するのか。これを決めずに走り出すと、野村の事案のように、ベンダーが凍結を求めても変更が止まらない状態になります。高裁は、野村側が基本設計に入ったあとも変更要求を繰り返したことで計画が崩れたと判断しました。
変更を決める人には、業務と予算の両方に責任を持つ人を充てます。情報システム部門が変更の窓口を持ち、事業部門の責任者とCFOが可否と費用を決める。この分担を体制図に書いておけば、変更を止めやすくなります。
ポイント
- 5つの判断は事業部門の責任者とCFOが決め、情報システム部門が取りまとめる
- 事例の裏付けが厚いのは、2（現行の調査）、4（切替）、5（変更の止め方）
S/4HANAへの移行でも、同じ5つの判断が問われる
いまSAP ERP 6.0を使っている会社がSAP S/4HANAへ移行する場合も、事情は同じです。とくに既存のシステムをそのまま変換する方式は、現行の設定と履歴を持ち越せる反面、現行の業務の作り方も持ち越します。筆者の見方では、IPAが注意を促している「いまのシステムをそのまま作り直すだけ」という考え方に、最も陥りやすい方式です。
注意
IPAは、いまのシステムをそのまま作り直すだけだと考える発注側には、現行を調べる意識が薄いと注意を促しています。既存のシステムを変換する移行でも、現行の業務の作り方をどこまで持ち越すかを先に決めてください。
保守期限を前にした判断の順番は、SAP 2027年問題の記事で整理しています。期限が迫るほど、上の5つを飛ばして要件定義から始めたくなります。飛ばした判断は、切替の直前にまとめて問われることになりやすいのです。
失敗の兆しは、計画書と最初の1か月の議事録に出る
要件定義が始まってから1か月ほどの資料を見れば、上の5つが決まっているかどうかは確かめられます。次のような状態が一つでもあれば、立ち止まって判断を補うべき時期です。
- 計画書の目的欄が「システム刷新」「業務の効率化」のままで、測れる言葉になっていない
- 現行システムの調査に工数も期間も割り当てられておらず、ピーク時の取引量を誰も数えていない
- 標準に合わせない領域の一覧と、追加開発を認める決裁者が決まっていない
- 切替日だけが先に決まり、切替の方式と戻り方が決まっていない
- 変更要求の受付窓口と決裁者が、体制図に書かれていない
5つの判断とは別に、稼働後の定着の準備も同じ時期に確かめます。業務を知るキーユーザーが通常業務と兼務のまま時間を確保できていない、操作の教育とマニュアル作成の担当が決まっていない、稼働後の問い合わせ窓口がない。こうした状態も、切替のあとに効いてきます。
すでに進んでいるプロジェクトで兆しが見えたら、まず新しい変更要求をいったん止めます。そのうえで欠けている判断を補い、切替日はそのあとで決め直します。
兆しは最初の1か月の資料に出る。見つけたら、切替日より先に変更を止める
兆しは、計画書と最初の1か月の議事録で確かめられる。見つけたら変更を止めて判断を補い、切替日はそのあとで決め直す。
切替の日に表に出る失敗は、計画の日に防げる
SAP導入の失敗は、切替の日に起きるように見えます。けれども、公表された事例と判決をたどると、公表された原因はどれも、計画の段階で前提を置ける種類のものでした。次の一歩は、手元の計画書を開き、5つの判断がそれぞれ誰の名前で決まっているかを確かめることです。
Never Redでは、SAP FI（財務会計）の導入・更改と経営管理の設計を、同じ担当者が通して見ます。会計の設計判断とSAPの設定を切り離さないためです。導入の構想や計画の段階、あるいは進行中のプロジェクトの立て直しからご相談いただけます。支援の内容はSAP導入支援と事業紹介をご覧ください。当社が入った工程と担った役割は、SAP導入事例に事例ごとに載せています。
まとめ
- 江崎グリコ、ユニ・チャーム、野村の3件とも、問題が表に出たのは切替直後かテストの段階だった
- 公表された原因は、処理量、周辺システムとのつなぎ目、データの整え方、変更の止め方で、どれも計画段階で前提を置ける
- JUASの調査でも、計画時の考慮不足と現行業務の複雑さが、ベンダーのスキル不足に次ぐ品質未達の要因に並ぶ
- 要件定義の前に、目的、現行の調査、標準との線引き、切替の方式と戻り方、変更を決める人の5つを決める
- 既存システムを変換する移行でも、現行の業務の作り方をどこまで持ち越すかを先に決める
よくある質問
Q. SAP導入で失敗した企業には、どこがありますか。 会社の開示や報道で確かめられる例として、2024年の江崎グリコとユニ・チャームがあります。どちらも基幹システムの切替後に出荷や納品が滞り、報道によれば切り替えた先はSAP S/4HANAでした。ネット上の一覧には、原因を一次情報で確かめにくい社名もあります。
Q. 失敗の原因は、ベンダーと発注側のどちらにありますか。 どちらか一方とは限りません。JUASの調査で、品質が予定どおりにならなかった要因として最も多いのはベンダーのスキル不足（59.9%）です。一方で、計画時の考慮不足（48.8%）や社員のスキル不足（44.8%）といった発注側の要因も多く挙がっています。野村HD対日本IBMの訴訟では、高裁が、野村側が基本設計に入ったあとも変更要求を繰り返したことで計画が崩れたと判断しました。
Q. 要件定義の前に、最低限やっておくことは何ですか。 目的を測れる言葉で書くことと、現行の業務とシステムを調べることです。とくに、ピーク時の取引量と、周辺システムとやり取りするデータの本数と件数は、切替の前提になるので必ず数えておきます。
Q. 本番切替で失敗しないために、何を準備すればよいですか。 切替の方式と時期、本番と同じ量のデータでのテスト、問題が出たときの戻り方の3つを、計画の段階で決めておきます。繁忙期や大型連休の明けに切替日を置く場合は、注文が集中したときの処理量を事前に確かめてください。
Q. SAP移行失敗の原因は、導入の失敗と同じですか。 筆者は、原因の種類は同じだと考えています。SAP ERP 6.0からSAP S/4HANAへ移る場合も、本文で挙げた5つの判断を計画の段階で決めることは変わりません。違うのは、既存のシステムを変換する方式を選んだ場合です。現行の設定や履歴と一緒に、現行の業務の作り方も持ち越します。どこまで持ち越すかを決めないまま進めると、その判断が切替の直前にまとめて回ってきます。
SAPの導入計画の点検や、進行中のプロジェクトの立て直しについてのご相談は、お問い合わせからお寄せください。
出典
- 江崎グリコの基幹システム移行の目的、4月3日の全面移行、出荷停止の経緯（4月14日停止、18日一部再開、19日再停止）、原因の説明（データの不整合、想定を超える受注品目数）：江崎グリコ「当社基幹システム障害に伴うチルド食品（冷蔵品）の出荷停止期間の延長に関するお詫び」（2024年5月1日）
- 江崎グリコの2024年12月期通期連結業績予想の修正（売上高3,510億円→3,360億円、営業利益190億円→140億円）：江崎グリコ「当社グループにおけるシステム障害および今後の見通し（通期連結業績予想の修正）について」（2024年5月8日）
- 江崎グリコのチルド商品の全品出荷状態への復旧（11月5日）：江崎グリコ「当社基幹システム障害に伴うチルド商品（冷蔵品）の全品出荷再開に関するご報告」（2024年12月6日）
- 江崎グリコの切替先がSAP S/4HANAであること：日経クロステック「『S/4HANA』への切り替えでトラブルの江崎グリコ、1カ月経過も商品の出荷停止続く」（2024年5月13日）
- ユニ・チャームのシステム更新の時期、物流システムとのデータ連係の不具合、連休明けの注文集中、6月3日までの解消、SAP S/4HANAであること：日経クロステック「ユニ・チャームの新基幹システム不具合おおむね解消、楽天市場などの直営店は休店続く」（2024年6月3日）
- ユニ・チャームの紙おむつなどの納品遅れ：日経クロステック「ユニ・チャームで紙おむつなどの納品遅れ、基幹システム更新に伴う不具合」（2024年5月27日）
- ユニ・チャームが計上した基幹システムトラブルの影響（物流費約4億円）：ユニ・チャーム「2024年12月期 中間決算説明会 質疑応答」（2024年8月7日）
- 野村HD・野村證券と日本IBMの訴訟の経緯と、東京地裁（2019年3月20日）・東京高裁（2021年4月21日）の判断：一般財団法人ソフトウェア情報センター（SOFTIC）判例ゼミ資料「野村HD対日本IBM」（2021年12月23日）
- 野村側の上告取り下げと判決の確定：日経クロステック「野村HDが日本IBMに『敗訴確定』、システム開発の失敗巡る訴訟の上告を取り下げ」（2021年12月13日）
- プロジェクト規模別のシステム開発の工期遵守状況（2025年度、図表7-1-4）：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査報告書2026」（2026年4月）。品質が予定どおりにならなかった要因（2025年度）とQCD悪化に影響を与えているトレンド（工期）：同「企業IT動向調査2026（2025年度調査）」速報版（2026年4月）
- システム再構築で要件定義の前に現行システム調査が必要であること、調査不足のまま着手してトラブルに陥った事例が多数報告されていること：独立行政法人情報処理推進機構・経済産業省「～情報システム・モデル取引・契約書～ 第二版の公表にあたって」（2020年12月22日）
- 「ERP導入の羅針盤」の位置づけと、指針の4つの軸（目的・導入・体制・活用）：JSUG「日本企業のためのERP導入の羅針盤～ニッポンのERPを再定義する～」
CONSULTATION
SAP導入・S/4HANA移行のご相談
延長保守か移行か、移行ならどの方式か。会計の設計まで含めて、方針を決める段階からご一緒します。SAP FI（財務会計）の導入と経営管理の設計を、同じ担当者が受け持ちます。
あわせて読みたい
