弔辞
TL;DR
- 江崎グリコは2019年12月から215億円の予算で基幹システム刷新に着手したが、最終的に342億円(1.6倍)に膨張
- 2024年4月3日にSAP S/4HANAへビッグバン移行、直後に冷蔵食品の出荷が全国停止
- プッチンプリンが店頭から消える事態が約7カ月続き、完全復旧は2024年11月5日
- 2024年12月期は売上150億円・営業利益50億円の下方修正、特別損失56億円計上
- SAP 2025年問題への対応焦りと、後戻り不能なビッグバン方式が被害を拡大させた
企業概要と全盛期
江崎グリコは1922年(大正11年)2月11日、創業者・江崎利一が大阪三越で赤い箱の栄養菓子「グリコ」を販売したことに始まる。牡蠣のグリコーゲンに着目した「一粒300メートル」のキャッチコピーと、両手を挙げてゴールするランナーの看板は、日本人の集合的記憶に刻まれている。
ビスコ(1933年)、プリッツ(1962年)、ポッキー(1966年)、パピコ、ジャイアントコーン、そしてプッチンプリン(1972年)――日本の食卓を彩る定番ブランドを次々と生み出してきた。2023年12月期の連結売上高は3,326億円、従業員数は約5,360人、海外関係会社18社を擁する食品大手である。
経営は創業家による世襲が続く。3代目社長の江崎勝久氏は1982年に40歳で就任し、1984年のグリコ・森永事件で誘拐被害に遭いながらも会社を支え続けた。2022年3月、勝久氏の長男・江崎悦朗氏(当時49歳)が4代目社長に就任。40年ぶりの社長交代であり、創業100周年という節目での世代交代だった。
しかし悦朗体制発足時、グリコは静かな危機にあった。少子高齢化による国内菓子市場の縮小、コロナ禍での消費低迷、近年ヒット商品に恵まれない開発力の停滞。新社長はASEAN事業拡大と健康分野での成長を掲げ、その基盤として「経営の迅速な意思決定」を可能にする基幹システム刷新を最重要戦略投資と位置付けた。
何が起きたか
時系列で追うと、悲劇は緩やかに、しかし確実に進行していた。
2019年12月:基幹システム刷新プロジェクト発足。調達・生産・出荷・会計を一元管理するSAP S/4HANA採用を決定。当初予算215億円、完了予定2022年12月。主幹事にデロイト トーマツ コンサルティングを起用し、構築作業を複数ITベンダーに分担させる体制を組んだ。
2022年3月:江崎悦朗氏が4代目社長就任。プロジェクトは難航し始める。
2023年12月:投資額が342億円に膨張(当初比1.6倍)、既払い額271.8億円。完了予定は2024年3月へ1年以上延期。それでも経営は前進を選んだ。
2024年4月3日:SAP S/4HANAへの一斉カットオーバー(ビッグバン移行)実施。直後からシステム障害発生。
4月14日:乳製品・プリン・果汁飲料など冷蔵品の全国物流センター業務が一時停止。プッチンプリンが姿を消した日として記憶される。
4月下旬:キリンビバレッジへの販売委託商品(トロピカーナ等)にも飛び火。グリコマニュファクチャリングジャパンの東京・那須・岐阜・佐賀の4工場で約1カ月の製造停止。
5月:2024年12月期連結売上高150億円、営業利益50億円、純利益40億円の下方修正を公表。
6月11日:一部商品の出荷再開。しかしプッチンプリンは依然停止。
8月:第2四半期に特別損失56億円計上、純利益は前年同期比53%減の36億円。
11月5日:システム障害発生前の全品出荷状態に完全復旧。障害発生から実に7カ月が経過していた。
失敗の本質的原因
市場・競合環境
国内菓子市場は少子高齢化で構造的に縮小し、コロナ禍が消費に追い打ちをかけた。グリコは近年ヒット商品に恵まれず、売上は減少傾向にあった。さらにSAP ERP 6.0のメインストリーム保守終了に伴う「SAP 2025年問題」が業界全体に重くのしかかっていた。「いつかはやらねばならない」という時間的プレッシャーが、慎重な判断を曇らせた。
経営判断と意思決定
最大の問題は、難航するプロジェクトを止める判断ができなかったことだ。投資額215億円は2021年12月期営業利益193億円を上回る規模であり、本来であれば一時凍結や段階移行への切り替えを真剣に検討すべき局面だった。しかし予算1.6倍膨張・1年超延期という赤信号の中で、4月3日のビッグバン移行を強行した。情報システム部門からのリスク警告が経営トップに適切にエスカレーションされる仕組みも不十分だったとされる。
財務・資金構造
342億円という投資額は年商の1割強に達する。これに加えて2024年第2四半期だけで特別損失56億円、売上150億円減・営業利益50億円減という実害が発生。創業100周年の祝賀ムードは、巨額損失計上で一気に冷え込んだ。
組織と文化
日本企業特有の「ITカースト」――エンドユーザー部門が情報システム部門を、情報システム部門がベンダーを下に見る構造――が指摘される。逆に言えば、現場の運用知見が経営判断に届かず、ベンダー任せの大規模プロジェクトになりやすい。さらに創業家世襲ガバナンスのもとで、経営トップに「待った」をかける独立的な仕組みが機能していたかは疑問が残る。
外部環境・規制
調達・生産・出荷・会計を一体化したシステムを一括移行したため、障害発生時に旧システムへの切り戻し(ロールバック)が事実上不可能だった。SAP在庫管理のパフォーマンス問題で在庫数の不整合が発生し、冷蔵物流という最も時間制約の厳しい領域を直撃した。
経営者の意思決定を再構築する
江崎悦朗社長の立場に身を置いて考えてみたい。
2022年3月、創業100周年という歴史的節目に40年ぶりの社長交代で就任。父・勝久氏が築いた巨大企業を継承し、しかし国内市場は縮小、ヒット商品は出ず、SAP 2025年問題は迫る。海外展開と健康事業という新たな成長軸を実現するには、経営の意思決定を高速化する統合基幹システムが不可欠だった。これは戦略的に正しい判断だった。
問題は2023年12月の決断時点である。投資額が当初予算の1.6倍に膨張し、完了が1年以上遅れている状況で、悦朗社長の前には三つの選択肢があった。①予定通り4月にカットオーバーする、②さらに延期して品質を確保する、③段階的移行に方式変更する。
ここで効いてきたのが「サンクコストの呪縛」だ。既払い271.8億円という金額は、経営者の合理的判断を歪める。「ここまで来たら止められない」という心理は誰しも持つものであり、特に新任社長として「父の代から続くプロジェクトを失敗させた」という評価を恐れる気持ちは想像に難くない。
加えて、SAP 2025年問題への対応という外部圧力、ベンダーからの「準備は整った」という報告、社内エスカレーション体制の弱さが重なれば、ゴーサインを出すのが「合理的」に見えてしまう。失敗を予見していた現場の声があったとしても、それが経営層に届かなければ意思決定は変わらない。
悦朗社長の判断は、決して怠慢でも傲慢でもなかった。むしろ巨額投資の責任を引き受け、前進を選ぶ覚悟ある決断だった。しかし結果として、ビッグバン方式が許容する失敗の余地はゼロだった。
海外類似事例との比較
製菓業界における基幹システム移行失敗の先例として、米Hershey(ハーシー)のケースは教科書的だ。1999年、HersheyはSAP R/3、Manugistics、Siebelの統合導入を強行し、ハロウィン商戦直前の8月にカットオーバー。本来30カ月予定だったプロジェクトを21カ月に圧縮した結果、注文処理と出荷に大混乱が発生し、第3四半期売上は前年同期比12%減、株価は8%下落した。グリコと驚くほど構造が似ている――繁忙期前の強行リリース、ビッグバン方式、複数システム同時導入。
英国の小売チェーンWoolworthsもSAP導入で在庫管理が破綻し、経営破綻の一因となった。Lidl(独)は2018年、SAP S/4HANAベースの基幹システム刷新プロジェクトを7年・5億ユーロ投じた末に断念。「我々のビジネスプロセスにSAPを合わせるのではなく、SAPに合わせる必要があった」と総括している。
これらの事例に共通するのは、①ビッグバン移行の脆弱性、②繁忙期前後のリリース判断ミス、③現場プロセスとパッケージ標準機能のギャップ、そして④サンクコストによる中止判断の遅れである。グリコの事例は、この国際的に共有された教訓が日本企業にも適用されることを改めて示した。
経営者・起業家へのインサイト
-
「ビッグバン移行」は経営判断の選択肢から除外せよ:調達・生産・出荷・会計を一括移行すれば、障害時の切り戻しは不可能になる。段階移行はコストも時間も増えるが、それは「保険料」である。最も時間制約の厳しい領域(冷蔵物流など)は最後に移行する設計原則を持つべきだ。
-
予算1.6倍・期間1.5倍を超えたら、リリースではなく「中止」を検討する:難産プロジェクトは「もう少しで完成」の幻想を生む。サンクコストではなく、これから発生する追加リスクで判断せよ。中止できる経営者こそ強い。
-
SAP 2025年問題のような外部期限を、社内意思決定の言い訳に使わない:期限は交渉可能だが、出荷停止による顧客喪失は不可逆だ。優先順位を逆転させてはならない。
-
「ITカースト」を壊し、情報システム部門に拒否権を与える:現場の運用知見を経営判断に直結させる仕組み――CIOの取締役会出席、リリースゲートでの独立判断権限――を制度化せよ。
-
新任CEOほど「前任の遺産プロジェクト」を冷徹に見直せ:継承した大型プロジェクトは、新CEOにとって最も中止判断が難しい案件である。だからこそ、就任後100日以内に独立した第三者レビューを実施する仕組みを持つべきだ。
あなたが経営者だったら?
-
既払い271.8億円・残り70億円の大型ITプロジェクトが、想定の1.6倍に膨張し1年超遅延している。あなたは「予定通りリリース」「さらに延期」「方式変更」「中止」のどれを選ぶか?その判断基準は何か?
-
自社の基幹システム刷新で、情報システム部門の責任者から「リリース準備は不十分」という報告が上がったとき、あなたはどう意思決定プロセスを設計するか?トップダウンの強行を防ぐ仕組みを持っているか?
-
創業100周年という象徴的な節目に、自社の歴史を背負って下す重大投資判断がある。あなたは「歴史への責任」と「現在の合理性」をどう両立させるか?