システム障害のグリコ、CIOが不存在だった…純利益半減でデロイトの責任問題

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

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

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

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

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

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

コンサルバブルの弊害

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