---------------------------
(東京地方裁判所 平成28年4月28日判決より)

大手総合化学メーカーが、基幹系システムを更新するため，ある海外のＥＲＰパッケージの導入を決定し、ＩＴベンダーに、そのカスタマイズと導入を依頼した。

ところが、プロジェクトの実施中、このソフトウェアの持つ業務プロセスが、「実際の作業に合わない」と現場からの反発を受け、ベンダーは大幅な作業のやり直しをすることとなった。

結果、スケジュールが遅れ、作ったソフトウェアの品質にも数多くの問題があったため、プロジェクトは頓挫してしまった。

化学メーカーは、「プロジェクトの失敗は、システム開発の専門家であるＩＴベンダーが適切なプロジェクト管理を行なわなかったことが原因である」などと述べて、損害賠償を請求する訴訟を提起した。

しかし、裁判所は、「そもそも、ＥＲＰ導入の全社的な目的を変えてしまうような現場の要求を受け入れた時点でこのプロジェクトは破綻しており、責任は化学メーカー側にある」として、訴えを退けた。

※以上、判決文は筆者が要約しています。
---------------------------

この裁判は、ＩＴシステム導入の真の目的が「基幹業務の改革」にあることを現場が理解せず、「今までの自分たちのやり方が良いのだ」と無理なカスタマイズをさせた結果プロジェクトが頓挫し、ＩＴシステム導入を諦めてしまった例です。

しかし、私が膨大な失敗プロジェクトを見聞きしてきた経験から言えば、こうした状態に陥ったプロジェクトが壊れてしまったのは、むしろ「不幸中の幸い」です。

もし、このまま無理にＩＴシステムを導入したところで、旧来のやり方にこだわったシステムでは、経営層が望んだ業務改革などできるわけもありません。メリットの薄いシステムに残りの開発費用をかけた上、導入後何年もリース料や保守・運用費用、更新費用を払い続けることになったのかもしれません。

ましてや、利用中に「やっぱりこれじゃダメだ」と、再度システム企画からやり直すようなことになれば、さらに数十億の支出が必要になったことでしょう。

たとえ、それまでの開発費用をドブに捨てたとしても、その方がまだ「マシな結果」だと思うのです。

では、この化学メーカーは、どうすればよかったのでしょうか？

何に気をつけておけば、「本当に役に立つシステム」「会社全体を幸せにするシステム」を作ることができたのでしょうか？