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

ノチラ ★

ここで1つ、ＩＴにまつわる裁判をご覧ください。

まずは、この争いの経緯から見ていきましょう。
--------------------
（平成16年3月10日　東京地方裁判所判決より）

原告の発注者と被告のベンダーは、基幹業務システムの開発委託契約を締結した。

しかし、スケジュールが遅延し、期限を数か月過ぎてもシステムは完成せず、発注者は契約を解除。支払済の代金約2億5000万円の返却と、損害賠償3億4000万円の支払いを求めて訴訟を提起した。

しかし、訴えられたベンダーは、開発遅延の原因は発注者による機能の追加・変更、その他の過剰な要求と、発注者が回答すべき懸案事項についての意思決定の遅れによるものだとして、逆に、ベンダーから発注者に対して、委任契約解除における報酬と損害賠償として約4億6000万円の支払いを求めて反訴を提起した。
--------------------

この裁判の判決は後で紹介しますが、これはＩＴ訴訟の中では非常に有名な裁判で、発注者に起因するリスクによって、プロジェクトが失敗した典型例です。

この裁判のように、要件変更や意思決定の遅延などのほかにも、発注者側に起因するリスクというのは、さまざまな形があります。

・プロジェクトの中心となって活躍していた発注者側の担当者が、人事異動で突然いなくなった
・自社の業務プロセスをベンダーに理解させなければならない発注者自身が、実は自社の業務のことをよく知らなかった
・自分が使うシステムなのに、なぜかエンドユーザーとなる社員が協力してくれなかった

そうした理由で、プロジェクトが頓挫することは多いのです。

こうした「発注者の責任によるプロジェクト崩壊」を防ぐためには、どうしたら良いのでしょうか。

「やっぱり、発注者は決めるべき時期までに要件を固めるべきなんだ。一度要件が決まったら、後からいじってはいけないし、意思決定も遅れないようにしなきゃいけない」

初めてシステムを外注する真面目な発注者の方なら、そんなふうに考えるかもしれません。

もちろん、そうできれば一番良いのですが、実際のプロジェクトは、そう教科書通りにはいきません。ＩＴシステムプロジェクトにおいて、要件変更や意思決定の遅延は日常茶飯事であり、そうしたことを絶対に起こさないように、などと考えていたら、ＩＴシステムの導入は事実上不可能であるのが実態です。
中略

さて、先ほどの裁判の話に戻ります。判決文の続きを見てみましょう。

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

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

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

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

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

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

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

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

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

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

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

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