江崎グリコシステム障害からユーザー企業が学ぶべき教訓
プッチンプリン、また再販延期。
いつになったら発売再開されるんですか！
そうなんです、割と好きなんです。
いやーやっちゃいましたね、デロイトさん。
今日は、江崎グリコのシステム障害に関する件について、SAPプロジェクトってよく炎上していたなーと昔の話を思い出しまして、この件からユーザー企業にとっての教訓が何なのか、お話してみたいと思います。
私も炎上気味のITプロジェクトの当事者になった経験がありまして、本件の関係者は他人事とは思えないですが、プロジェクトマネジメントにおいて押さえるべきポイントを押さえればもう少しリスクは低減できた事案とも感じます。
ちょっと本日は長いですが、お付き合いください。
本件をご存知ない方は、ご隠居_むらたんさんの記事で概要を確認されてみてください。
非常に整理されていて、ご自身の考察も面白い良い記事です。
プロジェクトデザインから絵に描いた餅だった
メディア情報と周囲から聞いた話を私なりに総合しますと、様々な記事でも書かれていますが、グリコの一件は、プロジェクト初期段階の導入計画自体がリスクを踏まえず、理想だけを掲げた絵に描いた餅状態で、そもそも最初から破綻していたのたのだろうと推察します。
数十年に渡って各部門で業務に合わせてガチガチに作り込まれていた基幹系システムを、パッケージのSAPに統合して一気に全移行するという、リスクしか感じないとてつもない荒技をデザインして実行してしまうのに少々驚きです。
(知識のない素人がやったのか？と思うくらい通常では考えられないやり方です）
言い方は申し訳ないですが、プロジェクトデザインのセンスに難ありと言わざるを得ません。
グリコはアンタッチャブルクライアントになるかも
グリコ側からの強い要望に忖度して進めてしまったのか、それとも見積もりを高くしたいからデロイト社側から無理な計画を提示したのか、その経緯は関係者のみぞ知る点ですが、今後両社で損害賠償訴訟になるでしょうから、詳細がその都度明らかになってくるんだろうと思います。
お互い言い分はあるでしょうけど、プロジェクト計画がそもそも破綻した状態でスタートし、進行中にクライアント側の理解不足、丸投げ意識とベンダー側の忖度、ユーザーに対する思い込み、スコープ拡大の思惑も混じり合って、コミュニケーションのクリティカルエラーを生んで炎上した、ITプロジェクト失敗あるあるの代表例と見て間違いないと私は考えています。
本件がきっかけで、グリコはどのベンダーもお守りしたくないアンタッチャブルなクライアントになってしまうかもしれません。
もしお守りしてくれるベンダーが見つかったとしても、ベンダーの言い値で依頼せざるを得なくなるのではないでしょうか。
また、その言い値で受けたベンダーも収束できず炎上する、という形で被害が更に拡大するシナリオも想定されます。
（だとしても、プッチンプリンは早く販売して…)
アンタッチャブルなクライアントで有名なのはみずほ銀行ですね。
本にもなっていて、メッチャ面白いです。まるで池井戸潤の世界です。
SAP選択が炎上に火を焚べることに
さて話を戻して、グリコ炎上の件は、まずリスクヘッジしない無理なプロジェクトデザインが失敗の火種となり、その上ソリューションにSAPを選択した事が、炎上のさらなる燃料として火を焚べる結果になったのだと思います。
SAPプロジェクトがよく炎上することは、ITコンサルやSIerの方であればご存知の話かと思いますが、そういった業界外の方からすると「なんでそんなあり得ない失敗するの？」と感じる方もいるかもしれません。
少し長くなってしまいますが、なるべく簡単にお話しようと思います。
20年前からSAPは燃えていた
まずERP(エンタープライズ・リソース・プランニング)自体が何なのかという話ですが、超ざっくり言うと、「企業にとって超重要なヒト・モノ・カネ・情報のデータを搭載した巨大なデータベースから必要な情報を都度引っ張り出して、営業活動、顧客管理、人事、会計、生産計画で使えるようにするシステム」の総称です。
また、アプリケーションはモジュール化(個別に切り分け)されていているので、企業は欲しい領域だけ導入が可能です。
欲しい分だけ使う考え方は、クラウド全盛の今では当たり前になってきていますが、一昔前は当たり前ではなかったんです。
私が新卒で入社した総合系のコンサルティングファームは、当時大企業へのERP導入を非常に得意としていて、売上の大半もERP導入でした。
その頃、日本企業は「ERPと言ったらSAPかOracleかの二択」状態でした。
私の所属していたファームは両社の導入を得意としていて、数多くのERP導入プロジェクトが社内で行われていました。
私も入社後の新人研修でSAPの当時最新バージョンだったR/3(今回のグリコは最新バージョンS/4HANA)の資格を取りました(強制的に)。
本当はOracleの資格をとりたかったのに、何故かSAPとれって人事に言われて不服だったのを思い出します…。
幸いなこと(？）に、私は上流流工程系(戦略、業務改革、リスクマネジメントなど）やその他スクラッチ系のシステム改修プロジェクトが多かったのですが、同期入社の仲間たちがSAPプロジェクトで疲弊(徹夜、休日出社のオンパレード)しているのを日々目の当たりにして、「SAPってほんとよく燃えるなー」と思っていました。
SAPが炎上する話は、もう20年前から言われていることで、2003年の以下の記事で既に触れられています。
今回のグリコも、過去の前例を踏まえず、「自分たちだけはうまくいく」という思い込みが招いた炎上だったとも思います。
ERPは本来カスタマイズしない
本来、ERPはそのまま使うことが大前提です。
日本だとオービックが大変有名ですが、ユーザーの満足度が非常に高いことで知られている高収益企業です。
オービックはほとんどカスタマイズをせずにユーザーにそのままシステムを使ってもらうことでも有名です。
カスタマイズをしないので導入費用も安くできるし、一度入って慣れてしまえば、ユーザーは長く使い続けるからサブスク的に儲かるとてつもなく素晴らしいビジネスです。
財務内容が凄いです。
SAPもERPですが、業務標準化を全面に押し出した極めてドイツ的な思想で設計されています。
プロセスマイニングツールを提供している企業もドイツ系企業が多いですが、とにかく標準の型を作ってそのテンプレこそベストプラクティスだ！と展開する思想が強いです。
仕様が云々とか細かい話をし出すとオタクな話になってくるのでやめますが、ざっくり言うと、「業務プロセス標準を私たちのシステムに詰め込んだからそのまま使ってね」が前提になっています。
さらに、「カスタマイズも標準化している」という考え方で、もちろん多少の柔軟性はあるものの、当時もう一つのオプションだったOracleと比較すると柔軟性は低いと言われていました。
合わないパッケージ選択が引き起こす炎上
何が言いたいかというと、SAPはそういう思想で作られたパッケージだということです。
SAPのパッケージ自体が悪いんじゃないんです。
むしろ大企業のサイズに耐え得る完成度の高いパッケージです。
ユーザーが自社のビジネスに合わないパッケージを選択するから、こういった炎上を引き起こすんです。
SAPプロジェクトで炎上している企業にはある程度特徴があって、メーカー系が圧倒的に多いです。
私が所属していたファームでも、炎上していたSAPのプロジェクトの1つは、自動車メーカーでした。
（社内ではコンサルの墓場と言われてました…)
メーカー系の企業はトヨタの「カイゼン」に代表されるように、プロセスの業務効率化や生産性向上が常に意識されていますから、業務改善を繰り返して、オリジナルな業務プロセスがガチガチにシステムで固められているケースが大半です。
そんな状況下で、何故かカスタマイズ性が低い完成度の高いパッケージソフトのSAPを自社に合うようにカスマイズしまくって日本企業は導入しようとするので、結果として導入に加えてカスタマイズ部分の開発工程が複雑になり、システムエラーの確率が極めて高い状態になります。
自社の業務に合うようにいじくりまわしたいのに、柔軟性がないパッケージを選択する。そりゃあ、失敗すると思いませんか？
ユーザー自身が自社のビジネスの特徴を理解して、フィットするパッケージを選択する。
こんな当たり前のことが、なぜか両社で議論もされず、パッケージのカスタマイズで安易に対応しようとしたのか、外部から見ても失敗の香りしかしない一件でした。
自社プランを持ってベンダーと対峙する
なぜこう誤ったパッケージ選択をしてしまうのかと考えると、外部ベンダーの理屈に因るところが大きいわけです。
SAPとも業務提携していますから当然売るインセンティブが働きますし、何よりベンダーは人月工数商売ですから、カスタマイズ領域で見積もりを膨らませたいわけです。
以前、ある統計で見ました(ごめんなさい、出所は忘れてしまいました)が、SAP導入時の費用内訳が、導入8割、カスタマイズ2割なのに対し、日本では真逆の導入2割、カスタマイズ8割だそうです。
カスタマイズ領域が多ければ運用・保守の費用も高止まりしますから、企業にとっては利益を圧迫し続けることになるわけです。
ちなみに、これは世界でも日本だけの現象で、SAPだけでなく多くの海外ベンダー(AWS、MSなど)が経済成長率が低いはずの日本に近年フォーカスしている理由もここにあります。
日本のデジタル赤字が増えるのは必然です。
（こちらについてはまた別記事で書きます）
私は今ベンダーとしての立場ではなく、DXコーディネーターとしてユーザー企業側の成長に資するかどうかという立場から、DXに向けた上流工程のご支援をしているのですが、ベンダー側との折衝は半分戦いです。
ベンダー側は実質はシステム屋さんですから、商売としては高い見積もりを通すためにてんこ盛り提案をしてくるケースが大半です。
ただ提案の中身を精査すると、ユーザー企業にいらないものも多かったりします。
まるっととりたいのでしょうけど、我々がご支援している場合は、ユーザー企業の皆様と共に見積もりの根拠や必要性を確認させてもらっています。
ユーザー企業自身が、自分たちがどうしたいのかという解像度高いビジョンを持ち、そのビジョン実現のためにはどんなビジネスアーキテクチャであるべきなのか、それを実現するためにはどんなシステムをどんな優先順位で導入すれば良いのか、ここまでプランを持てるよう、内部で整理を行ってからベンダーと折衝することが理想だと考えています。
方法論は既に確立されてますから、きちんとした手順さえ踏めばプロジェクトリスクは低減可能です。プロジェクト規模の大小関係なく何事も基本に忠実に進めていくことの重要性を、グリコの件は改めて教えてくれました。
たまには普段の仕事関連の話を書いてみようかと思いましたが、熱くなって書いているうちにかなり長い記事になってしまいました。。
次回はもう少しコンパクトに書けるように努力します。
最後まで読んでいただきありがとうございます。