システム障害、なぜ起こる？ユーザー企業のノウハウ空洞化、コンサルとの能力差

　江崎グリコは4月に発生したシステム障害が原因で、ほぼすべてのチルド食品（冷蔵食品）が2カ月以上にわたり出荷停止に。ユニ・チャームでも5月に発生したシステム障害の影響で出荷遅延や販売停止が発生。両プロジェクトの主幹事ベンダが外資系のデロイト トーマツ コンサルティングである点も注目されているが、相次ぐシステム障害の要因としてベンダ側と発注するユーザ企業側の「情報の非対称性」があるのではないかという指摘がSNSで議論を呼んでいる。ベンダ側およびユーザ企業側に起因する問題、または両者の関係性に起因する問題としては何があるのか、専門家の見解を交えて追ってみたい。

　システム更新作業に伴う障害によってサービスに大きな影響が出るケースが後を絶たない。

　グリコは業務システムについて、独SAPのクラウド型ERP「SAP　S／4HANA」を使って構築した新システムへ切り替えるプロジェクトを推進してきた。旧システムからの切替を行っていた4月3日、障害が発生し、一部業務が停止。その後、一部商品の出荷が停止となり再開されたが、「プッチンプリン」「カフェオーレ」「アーモンド効果」をはじめとする大半のチルド食品は再び出荷停止に。さらにキリンビバレッジから販売を受託している果汁飲料「トロピカーナ」や野菜飲料の出荷も停止するなど、影響は他社にも拡大している。6月11日、一部の商品の出荷を25日以降順次再開することを発表したが、これによりグリコが被る損失は大きい。同社は5月、24年12月期連結決算見通しについて、売上高は従来予想を150億円下回る3360億円（前期比1％増）に、純利益は従来予想を40億円下回る110億円（前期比22％減）に下方修正すると発表した。

　ユニ・チャームでも5月、一部商品について出荷が遅延。「日経クロステック」記事によれば、ゴールデンウイークに実施した基幹システムの更新で新基幹システムと物流システムの接続でデータ連係に不具合が生じたことが原因。更新したシステムはグリコ同様に「SAP S/4HANA」だったという。

　今月19日にはデリバリーサービス「出前館」のウェブサイトとアプリが利用できなくなる事象が発生。同社は原因について、システムの更新作業に起因するデータベースの不具合だと説明している。

　グリコとユニ・チャームのシステム更改プロジェクトについては、ともに主幹事ベンダがデロイトであると「ダイヤモンド・オンライン」が報じ、注目されているが、大手SIerのSEはいう。

「大規模なSAP案件はデロイトが強い領域なので、必然的に絶対数として同社が関与するプロジェクトの数は多い。システム作業に障害はつきものであり、また障害は複合的な要因で起きるケースが大半なので、デロイトにどこまで責任があるのかは判断できない。2社の件だけをもってデロイトを批判するのは無理があるものの、プロジェクト全体を推進する立場にある主幹ベンダであったのだとしたら、一定の責任は免れない」

リーダー割に合わない問題

　大規模なシステム作業に障害はつきものだが、企業のシステム企画・支援を手掛ける株式会社AnityA代表の中野仁氏がX上に投稿した

＜ユーザー側とシステムを本業にしているベンダー側で組織の能力差がでるし、結果的に情報の非対称性が拡大する＞

との指摘が一部SNS上で話題を呼んでいる。

　一般論として、システム開発プロジェクトの失敗の原因として、発注者であるユーザー側企業に起因するものには、どのようなものがあるのか。中野氏はいう。

「失敗プロジェクトが発生する時はユーザー企業側とベンダー企業側のどちらかが一方的に問題の原因がある場合は少なく、双方の問題があるという大前提の元でお話します。まずはユーザー企業側の問題です。ユーザー側のIT部門が要件を取りまとめられず、体制を整えられないというケースが多いです。SAPのようなERPパッケージを導入する場合、各部門の業務プロセスを整理し、それに基づいて設計を行いますが、システムに合わせて業務プロセスを変更しなければならない場合があります。基幹系システムの更新などの大規模なプロジェクトでは多くの部門が関係してくるため、プロジェクトマネージャー（PM）が各部門の協力を得ながらこのような作業を行うには膨大な労力を要します。それを実行できるだけの体制が取れない訳です。

　社内でプロジェクトのリーダーシップをとる役割の人には大きな負荷がかかり、最悪、心身を壊して休職なども散見されます。自分が得ている報酬に対して割に合わない仕事になってしまったりします。

　また、いわゆる『システム子会社問題』もあります。大企業の場合、システム開発・運用部門をシステム子会社というかたちで切り離して持っているケースが多いですが、力関係的にシステム子会社より親会社のほうが上であることが多く、また事業会社の社内でIT部門の立ち位置が弱かったりするので、各部門から『現行業務は変えずに、システムのほうが業務に合わせるべきだよね』と言われ、言うことを聞いてもらえない傾向があります。各部門のシステムが何十年も稼働している古いものだと、そのシステムの全体像や詳細を誰も把握していないというケースもあるでしょう。企業はコスト削減の観点からコストセンターであるシステム部門を外部に切り離す目的でシステム子会社を設立したという経緯から、システム子会社の給与は本体企業より低めに抑えられているケースが多いです。結果的に、報酬的に採用競争に勝てず満足な体制を組めない可能性もあります。プロジェクト企画推進が不足して、外部ベンダーに発注する事が業務の中心になっているケースもあります。

　加えて、プロジェクトの推進過程において適時、経営陣に説明し承認を得るというのもPMの重要なタスクの一つですが、CIO・CTOのような技術領域の管掌役員が不在の企業も多いです。役員から『メディアにこう書いてあったのだけど～』『知り合いの会社ではこうやっているらしいのだけど～』といった付け焼刃的な知識に基づく指摘や意見を受けることもあり、こうしたコメントに一つひとつ応え、説得していくのも骨が折れる仕事です。更に、これらのタスクに発注先ベンダとのやりとりが加わります。最終的に高い費用対効果を実現しなければならないわけです。プロジェクトが大きくなると複数のベンダー企業が関係しますが、それらを連携させてプロジェクトを着地させなければならない。

　つまり、内部では現場に対する交渉だけでも過負荷になりやすいのに、経営からの打ち返しが必要になる。更に外部への調整も必要になる。上下左右への膨大な調整コストが乗ります。

　これらをすべて“真面目にしっかりとやる”のは非常に大変ですし、長時間の残業を強いられることになり、一般的な事業会社で支払われる賃金では“リーダーシップを取る事は割に合わない”ということになります。プロジェクトに関与する社内のIT部門や推進者たちにとっても真面目にやろうとすると“割に合わない仕事”ということになります」（中野氏）

コンサルバブルの弊害

　こうした「リーダー割に合わない問題」が企業のシステムに関するノウハウ不足に拍車をかける事態を招いているという。

「ここ数年、企業のシステム部門の優秀な若手・中堅社員が外資系のコンサルティング会社やベンダ、プラットフォーム企業に誘われて転職するという動きが強まっていました。これらの外資系は元いた会社より数百万円高い年収を提示しており、誘われればそちらに行ってしまうのは、無理はないといえます。こうして人材流出により企業のITノウハウが空洞化し、人月単価に換算すれば自社社員より何倍も高いお金を払って外部のコンサル会社やベンダにPMをお願いするという皮肉な状況が生まれています」（中野氏）

　一方、コンサル会社・ベンダ側に起因するものには、どのようなものがあるのか。

「SAPの保守期限やベテラン社員の定年退職という要因からか、ここ数年、コンサル会社に持ち込まれるシステム開発案件の数が急増し“コンサルバブル”ともいえる現象が起きているとも言えます。コンサル会社はそれらをさばくために新卒や中途で積極的に人材採用を一昨年位までしていました。かつての基準だとジュニアコンサルタントくらいのスキルしかない人材が一人前のコンサルタントといった肩書で顧客の前に出て、高い料金でプロジェクトにアサインされるケースが増えていると聞きます。その結果、コンサルのノウハウ不足でプロジェクトがうまくいかないというケースも少なくないようです」（中野氏）

役員にCIOを置くことの重要性

　では、ユーザー企業はプロジェクトを失敗させないために、どうすればよいのか。

「SAPを例に挙げるならば、まず企画の段階で『SAPありき』で考えないことです。ERPに限らずパッケージソフトやプラットフォームには向き不向きがあるので、自社の業務や実現したい目的に合っているのかという視点を持つべきです。たとえば売上に占める海外比率が7～8割の企業であれば、SAPの導入は十分な投資対効果が見込める可能性があるかもしれませんが、売上がほぼ国内のみの企業であれば、それが適切な選択なのかという視点での検討が必要になってきます。

　コンサル会社の提案を鵜呑みにするのも気をつけた方が良いです。彼らは顧客企業の業務を決められたプロジェクト期間で可能な限り知り仕事を終わらせるという制約があります。当然ながら大企業の複雑な業務や文脈を深く知った上で実行するのは困難です。その上で契約が取れる事を優先に、利益を最大化する提案をしてくるものです。ビジネスですから。

　そしてコンサルは導入後のシステム運用については深く関わらない事も多いです。運用を含めて良い所も悪い所もよくわかっているのは、丸投げをせずに自分の力で導入・運用をしているユーザー企業です。その様な他社のシステム部門に導入を検討しているパッケージソフトのヒヤリングを行うことも重要です。相手企業のシステム部門も常に他社のシステム部門との情報交換をしたがっているので、ダメ元でお願いしてみると意外に応じてくれるケースが多いものです。大規模なシステム導入・更新の企画には高度な技術的知識と費用対効果を検証できるスキルが必要であり、そのような専門的な人材を外部から引っ張ってきて企画業務を委託するというのも一つ方法です。

　また、役員にCIO（チーフ・インフォメーション・オフィサー）を置くことも重要です。日本企業では総務部長や管理本部長などがCIOに就くこともありますが、そのような“名ばかりCIO”ではなく、技術と経営に詳しいCIOが経営会議や取締役会で発言権を持つ仕組みを構築すべきです。たとえばSAPのようなERPを導入する目的は一言でいえば『経営のガバナンス強化』であり、開発プロジェクトについてトップダウンで決断・推進する権限を有する人がいるかどうかは、プロジェクトの成否を大きく左右するカギとなります」（中野氏）

（文＝Business Journal編集部、協力＝中野仁／AnityA代表）