江崎グリコのシステム障害を考える

　朝食の時ににグレープフルーツジュースを飲むのが習慣になっていて、この５年程ずっとキリンの「トロピカーナ」グレープフルーツジュースを買って飲んでいます。先月のある日、いつも行くスーパーにグレープフルーツジュースを買いに行くと、トロピカーナのジュースがなくなっていました。数日後に同じスーパーに行くと、今度はこんな張り紙が。「江崎グリコとキリンビバレージのチルド製品は、メーカーのシステムトラブルのため欠品しています。」

　システムトラブルって何だろうなあと、家に帰ってからネットで調べてみると、結構な大ごとになっていました。江崎グリコの出荷管理システムが社内のシステム更新作業に伴う不具合のために、出荷ができなくなり、キリンビバレージから販売委託を受けている、トロピカーナや野菜飲料も同様に出荷停止になっているとのこと。1ヶ月近く経った、本日(2024年5月15日)時点でも出荷停止は続いており、再開時期は未定です。

　食べ物の恨みは恐いとはよく言ったもので、グレープフルーツジュースが買えないことがきっかけで、しばらく書くのをサボっていたブログを書くモチベーションが湧いてきました。江崎グリコのシステム障害について思うところを書いてみます。

グリコのシステムトラブルの概要

グリコの新基幹システムプロジェクト

　グリコは、調達、生産、出荷、会計などの業務を一元管理する基幹システム刷新プロジェクトを2019年12月に開始しています。当初の完了予定時期は2022年12月、投資予定額は215億円でしたが、目論見通りにはいかなかったようで、2023年12月期の有価報告書によると完了予定時期は2024年3月、投資予定額は342億円となっています。新システムはERPパッケージ SAP社製「SAP S/4HANA」で構築されています。また、プロジェクトを担う主幹ベンダーは「デロイトトーマツ　コンサルティング」と報道されています。

問題の経緯

　グリコからの広報発表や報道されている情報によると、経緯は以下です。

2024/4/3

　基幹システムを新システムに移行したところ、システム障害が発生。このため全国の物流センターでは、システムを利用せず「在庫管理の機能」のみを使って出荷業務を継続。

2024/4/14 

　倉庫内の実際の在庫数とシステム上の在庫数が一致しなかったため、物流センターの業務を一時停止。

2024/4/18

　データの差異を解消した上で18日に出荷業務を一部再開したが、物流センターでの出荷に関するデータの不整合が再度発生した他、受注品目数に対し処理が間に合わない状態になり、冷蔵品の再度出荷を停止。常温品や冷凍品にもシステム障害の影響が出ているが、冷蔵品に比べて賞味期限が長いため、在庫数の誤差を手作業で修正しながら出荷を継続しているとのこと。

2024/5/1

　5月中旬を目処に業務再開する目論みであったがこれを断念。システム改修作業に時間を要するため出荷停止期間を延長。（業務再開時期は未定）

経緯を見ていて気になること

　実際に何が起きているのかは分かりませんが、経緯を見ていくと、元ITエンジニアリングをやっていた身としては、引っかかるところがいくつかあります。

業務停止期間の長さ

　まず驚くのが、出荷業務が停止の期間があまりにも長いことです。なぜ、出荷業務停止がこれほど長期に渡ってしまうのでしょう？

　通常、このようにシステムの切替え後に重大なトラブルが発生した場合には、元のシステムに戻す「切り戻し」を行い業務を継続できるようにします。しかし、今回のグリコのケースでは、これまでわかっている情報を見る限り、切り戻しを行なった形跡はありません。切り戻しができない何らかの理由があったのでしょう。考えられる可能性としては以下のようなものがあります。

• 出荷システムの他、生産、調達、会計などが一体化したシステムになっており、全てを一括で新システムに移行したため、出荷システムだけを切り戻すことができない
• データ構造が複雑になっており、一旦新システムで運用した際に発生したデータを、旧システムに移行するのに、多大な時間がかかってしまう（旧システムから新システムへのデータ変換する仕組みはあっても、その逆はできないとか）
• （流石にこれは考えづらいですが、）旧システムはすでに処分してしまっている

　また、システムが止まると業務が継続できないほどに、業務がシステムに依存してしまっているのも引っ掛かります。一部運用していたシステムが融通が効かない作りになっており、手作業での修正作業がとても煩雑になってしまっているのかもしれません。あるいは、以前からシステム化されていた業務が今となってはブラックボックス化しており、手作業で業務をやろうにもやり方を知っている人がほとんどいないのかもしれません。システムに依存せざるを得ないのであれば、そのシステムのバックアップを行う手段が必要はずですが、それが十分ではなかったと言えるでしょう。

SAP S/4HANAを使ったシステム

　二つ目に引っかかるのは、これが「SAP S/4HANA」で構築したシステムであるという点です。SAPのERPパッケージ製品は世界的に多くの実績のあり、日本でも多くの企業で導入されています。うまく使えれば、調達、生産、会計、発注などのERPシステムの構築費用を大幅に低減できるメリットがありますが、一方でデメリットも多くあるソフトウェアです。

エンジニアが確保しにくい

　SAPには「2027年問題」と呼ばれる問題があります。S/4HANA以前にSAPの主力ERP製品であったSAP ECC6.0のサポートがこの年で終了するため、SAP ERPを使っていた数多くの企業はそれまでにS/4HANAに移行しようとしています。しかし、多くの企業が同じ時期に移行プロジェクトを行うために、SAPの専門エンジニアは取り合いの状態になってしまい、優秀なエンジニアを確保するのが非常に困難になっています。

独自機能を組み込むのが難しい

　SAP S/4HANAはERPのパッケージソフトであり、いくつか用意されているテンプレートから必要なものを選び、それらを組み合わせてシステムを組み上げるのが基本的な考え方になっています。テンプレートで賄えない場合は、「アドオン開発」と呼ばれるその企業独自の機能を追加開発することになります。ところが、このアドオンはSAP独自のプログラミング言語を使って開発する必要があり、かなり専門性が求められます。また、アドオンしたモジュールがシステム障害を引き起こすことも多く、これらの問題を解決するのにもSAPに関する専門知識が必要になります。結果としてアドオン開発は非常に高くつきます。

中身はブラックボックス

　SAP に限った話ではありませんが、企業が提供するパッケージソフトウェアの中身は当然公開されておらず、システムを構築する側はブラックボックスとして扱うことになります。パッケージを使うこと自体に問題があるわけではありませんが、システム中にブラックボックスが占める割合が大きくなるにつれて、障害が起きた時の解決は難しくなっていきます。仮にパッケージ側に問題があったとしても、これを修正してもらえるわけではなく、大抵の場合、パッケージを使う側で、問題を回避をする解決方法を取ることになります。特に、ブラックボックスに関わる性能問題が発生した場合は非常に厄介です。最悪システムを作り直しということもあり得ます。

　多くの場合、SAPが抱えるこのようなリスクを計画段階で考慮できていないのが実情のようです。特にSAPを担いでいるコンサルにプロジェクトマネージメントを任せてしまうと、SAPに関するリスクが過小に評価されてしまいがちです。今回の問題が、SAPにまつわる問題に起因しているとすれば、今後SAPの製品を導入している多くの企業でも同じようなことが起きるということになると思います。

システム統合プロジェクトであること

　三つ目は、システムを統合するプロジェクトだったという点です。統合プロジェクトは通常のプロジェクトに比べると非常に難易度が高くなります。（データにまつわるトラブル事例（３）〜システム統合・システム連携編〜 にそのあたりの事を書いています）

　それにしては、当初計画のプロジェクト期間が３年と短かすぎるように思います。プロジェクトスタート時点の前提条件がどうなっていたのかはわかりませんが、私の感覚では少なくとも計画と要件定義に２年、システムの構築と試験などに2年、さらに1年くらいかけて段階的にシステムを移行を行う、最短でも5年はかかるイメージです。果たして、十分な時間をとって計画や要件定義を行ったのか、運用を想定した十分な試験を行う時間があったのかなど、疑わしく思えてしまいます。

おわりに

　このトラブルの原因は、現時点ではわかっていません。しかし、単なるプロジェクトマネージメントとかシステム設計とかの問題ではなく、もっと根が深いものが多分に含まれているような気がします。今後、他でも同じようなことが起こりそうな嫌な予感がします。

　今回のトラブルに関連する話を、この後何回かに分けてもう少し詳しく書いてみたいと思います。次回はSAPについて書いていきます。　　(続く)