パッケージソフトウェア導入時にありがちなユーザ内部の争い
ERPパッケージソフトウェアを利用して開発を行うとき、いつも問題になるのが既存の業務プロセスとの関係です。ERPに限らずパッケージソフトウェアというものは、同じような業務が世間一般でどのようなプロセスで行われているか、どういったプロセスが効率的で経営にメリットをもたらすものなのかをソフトウェアの開発者が勉強した結果を元に作られています。このことから、今まで我流のプロセスで業務を行なっていた会社が、他社の好例を元に自社のやり方を改革する良い材料となりこともあります。一般に経営層はこうした業務改革に熱心です。なので、ERPパッケージをあまりカスタマイズせず、むしろ自分達の仕事を変えるべきと考える人も多いようです。
ところが、現場サイドになると話が違ってきます。今までのやり方で会社は回ってきたのに、なぜ変えるのか。新しいシステムで、今までと異なる手順の仕事をするのはかえって生産性を落とすし、そもそもウチの良いところを消してしまうのではないか？……そんな不満や不安が、パッケージソフト導入の際によく聞かれます。
私の知るある会社では、機械製造の生産管理システムを導入する際、製造要員の空き具合を見て自動的に仕事を割り振る機能を持つパッケージソフトを導入しましたが、現場からの「勝手に人を動かされては困る」という意見に押され、この機能を使えないように改造していました。本来、会社は従来の属人的な人員配置を排除し、最も効率的な体制を組めるようにとこのソフトウェアの導入を決めたはずなのですが、現状の人による人員配置に特に問題を感じていなかった現場の声に押し切られたわけです。どちらが正しかったのかはさておき、パッケージソフトウェアを導入しようとするときには、このようなせめぎ合いがよく起こるようです。
パッケージソフトウェアのカスタマイズをめぐる裁判の例
今回、ご紹介するのは、そんなパッケージソフトウェア導入の際の問題が大きくなってしまった結果、プロジェクトが頓挫してしまった例です。ユーザ内部の調整不足がベンダの作業に影響を与え、挙句、プロジェクトが失敗してしまったのですが、ユーザ側はプロジェクトが失敗したのは、ベンダが素人である我々をリードせず、プロジェクトが苦境に陥っても無作為だったからだと訴えています。事件の概要から見てみましょう。
(東京地方裁判所 平成28年4月28日判決より)
大手総合化学メーカが、基幹系システムの更新を企図して，ある海外ERPパッケージの導入を決定し、ITベンダに、そのカスタマイズと導入を依頼した。導入にかかる総予算は約25億円と見積もられた。
ところが、プロジェクトの実施中、このソフトウェアの持つ業務プロセスが、実際の作業に合わないと現場からの反発を受け、ベンダは、大幅な作業のやり直しをすることとなった。結果、スケジュールが遅れ、作ったソフトウェアの品質にも数多くの問題があったため、プロジェクトは頓挫してしまった。
化学メーカは、プロジェクトの失敗は、IT開発の専門家であるITベンダが適切なプロジェクト管理を行わなかった為であるなどと述べて、これに損害賠償を請求する訴訟を提起した。
この連載を長く読んでいただいている方ならご存じかもしれませんが、ITベンダには専門家として素人であるユーザをリードするプロジェクト管理義務があります。開発の途中で、ユーザが「やっぱり、この機能も付けてほしい」「ここを変えてほしい」 と後出しジャンケンのように要件を変えてきたとき、それがプロジェクトの円滑な進捗を著しく乱すようなものなら、これを断るなり、追加費用やスケジュール延長を申し出るなりして、プロジェクトの立て直しを図ることがITベンダの義務とされています(プロジェクト管理義務には、他にも色々とありますが、今回のポイントはここです) 。ユーザはIT開発の素人なので自分たちのワガママがどこまでIT開発に悪影響を与えるのかわかっていない。そこはプロであるベンダ側が、ユーザに教えてしっかりリードしなければならないということです。
