発注側とベンダの間で食い違う見解

　大手SIer社員も、今回の事例は非常に珍しいものだという。

「『日経クロステック』記事を読む限り、アクセンチュアは結合テストまで完了して成果物を納品したという見解なのに対し、日本通運は納品されていないという見解で、真っ向から食い違っています。アクセンチュアの主張によれば、日本通運は当初、検収を拒否したとのことですが、考えられるケースとしては、アクセンチュアは不具合だと考えていない部分を日本通運は不具合だと主張し、その点について合意に至らないまま納期を迎え、アクセンチュアは開発は完了したと主張し、日本通運は不具合が改修されていないので完了していないと主張しているというかたちです。部分部分について『これが不具合か、そうではないのか』をめぐり発注側とベンダ側の見解が食い違うというケースは珍しくないですが、大抵はベンダが発注側から言われるままに改修したり、追加費用の契約をして改修したり、改修不要としてそのままにしたりするので、納品が完了したかどうかという点で揉めるということは、あまり聞いたことがありません。

　テストフェーズでは通常、発注側とベンダの間でテスト項目や合否の基準を予め決めておくものなので、今回の事案ではその点がどうなっていたのかが気になります。要件定義や基本設計・詳細設計のフェーズで細かい各項目について合意していても、開発が進んでいくなかで発注側とベンダの間で『これは要件になかった追加項目ですよね？』『これは設計で決めた内容と違いますよね？』などと見解の食い違いが生じるもので、生じないプロジェクトなんてないといっていいくらいです。ベンダ側の詰めや確認が甘かったり、発注側が社内の各部門の要件をきちんとまとめきれていなかったりと、さまざまな原因があげられます。発注側のプロジェクトマネージャー（PM）やプロジェクトリーダー（PL）が社内の各部署の要件をしっかりと把握して、現状からの変更も含めてシステムと業務プロセスを策定して社内の合意を得て、それを正しくベンダに伝えるというのは、かなり大変な作業なので、発注側のPMにそのようなスキルがないと、プロジェクトがうまくいかないということになりがちです。

　日本企業の場合、メーカーだと製造部門や物流部門、銀行であれば支店や営業部門、物流企業であれば物流部門など、本業の現場の声や力が強いため、システム部門は力関係的に下になりがちなので、社内に言うことを聞かせにくいという点も、システム開発プロジェクトの障害としては結構大きかったりします。システム部門が本体から外出しされてシステム子会社になっていれば、なおさらです」（9月27日付当サイト記事より）