エンジニアに「あとはよろしく」と絶対言ってはいけない理由

実は、裁判所はベンダー側の責任を認め、ベンダーに多額の損害賠償の支払いを命じています。

--------------------
（平成16年3月10日　東京地方裁判所判決より　続き）

被告のベンダーは、自らの有する高度の専門知識と経験に基づき、本件電算システムを完成させる債務を負っていた。

そのため、ベンダーは、開発方法と手順、作業工程などにしたがって開発を進めるとともに、常に進捗状況を管理し、システム開発について専門的な知識を有しない発注者のシステム開発へのかかわりを管理し、発注者によって開発作業を阻害する行為がないように、発注者に働きかける義務を負う。

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

簡単に言えば、こういうことです。

「発注者がわがままを言うなら、ベンダーはそれをしっかり断らなければならない」

「どうしても要件を変更せざるを得ないようなことがあるなら、発注者と一緒に検討して、次善の策を考える姿勢が必要だ」

「発注者がプロジェクトを乱すなら、ＩＴの専門家であるベンダーは、それを“リスク”として管理し、発注者が決めることを決めたり、プロジェクトを壊すほどの要件変更をしたりしないように仕向ける義務がある」

発注者が原因となるようなリスクも、ベンダーが管理し、解決に導かなければならないということです。これを「ベンダーのプロジェクト管理義務」と言ったりします。

「なんだ。じゃあ、ベンダーが悪いってことか。発注者に責任はないわけでしょ」

そう思った方は、もう少し、踏み込んで考えてみてください。

『システムを「外注」するときに読む本』 細川義洋：著
価格（本体）：1980円+税　
発行年月：2017年6月　
判型/造本：A5並製、352ページ ISBN：978-4478065792

ベンダーが、発注者のリスクも含めて管理しなければならないということは、発注者も相当の協力をしなければならないということを意味しています。

「この期日までに要件を決めてくれないなら、この機能はあきらめてくれ」とか、「これは当初の想定にない機能だから、追加の費用と納期の延伸を認めてくれ」とか、そんなベンダーの悲鳴にきちんと耳を傾け、そのまま受け入れないまでも、ちゃんと相談に乗ることが必要です。

そうしたこともせずに「なんとかしてよ。プロでしょ？」などとベンダに突き返すような態度をとると、今度は、逆に「発注者の協力義務違反」に問われることにもなりかねません。

ＩＴ導入は、発注者とベンダーがお互いにわがままを言い合いながら、話し合い、双方が妥協をしてなんとか成功させていくものなのです。

システムの外注において、「どのベンダーを選ぶか？」は、プロジェクトの成功を左右する重要な選択です。しかし、無数にあるＩＴベンダーの中から、「良いベンダー」を正しく見抜くのは非常に難しい問題です。

『システムを「外注」するときに読む本』の第3章では、失敗しないベンダ選びのポイントとして、何を基準にベンダーの実力を判断すれば良いのか、いくつかの「判断軸」をお伝えしています。

ベンダー選びとシステム開発がイチかバチかの「バクチ」にならないよう、ご自分の会社やプロジェクトにあてはめていただきながら、ぜひ、ご一読くだされば幸いです。