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

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

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

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

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

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

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

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

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

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

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

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

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