請負契約の成立するとき

深沢隆司氏の『ＳＥの教科書２』（技評ＳＥ新書017, 2008） を読みました。システム開発について、おおよそ以下のような主張がなされていまして、興味深いと感じたのですが。

営業段階・受注段階で作成されたスケジュール（初期計画）に従っていては、システム開発プロジェクトを成功させることはできない。 業務分析、要求定義が完了した段階で、開発計画を改めて作成する必要がある。にもかかわらず、ベンダは初期計画を絶対視して変更をしようとせず、そのままプロジェクトを進めようとしている。だから、システム開発のほとんどは、失敗に終わる。

ソフトウエア受託開発では、受注金額と納期だけが決まっていて、開発要件は不明確、という形で、「請負契約」が締結され、契約書が交わされる、ということが往々にしてありますね。

しかし、法的には、請け負う仕事の内容が不明確な状態では、請負契約というのは成立しません。何を請け負うのかわからないのに、請負契約が締結される、というのは奇妙な話です。契約書の内容にもよるでしょうが、開発計画がまともに立てられないような契約書というのは、紙くずでしかないわけです。

名古屋地裁平成16年1月28日判決

本件総合システムの導入に際して締結されるような，業務用コンピューターソフトの作成やカスタマイズを目的とする請負契約は，業者とユーザ間の仕様確認等の交渉を経て，業者から仕様書及び見積書などが提示され，これをユーザが承認して発注することにより相互の債権債務の内容が確定したところで成立するに至るのが通常であると考えられる。

システム開発をめぐる法律問題（3）個別契約で上流工程の不払いリスクを回避する (ITPro)

日経BP社 ITPro の連載記事『システム開発をめぐる法律問題』では、名古屋地裁の判例をひいて、「外部設計相当の内容について合意が得られている」時点を請負契約成立の時点と考えるのが良い、と提示しています。

ベンダの営業、経営層が、受注時点の「初期計画」をもって、「請負契約成立」とみなそうとするのは、売上を早期に計上したいというインセンティブがあるからでしょう。

深沢隆司氏によれば、

たいていの場合、開発計画は初期計画の２・３倍程度になる

とのことですが、これは、ベンダの営業・経営層にとっては都合がよいわけです。本来必要な工期の 1/2 ・ 1/3 の時点で、キャッシュが手に入るわけですから。

顧客側は、契約書にある納期に従って入金の事務処理を進めたいでしょうから、実態としてシステム開発が完了していなくとも、検収書発行、入金が行なわれる可能性が高いです。また、顧客も初期計画の予算・納期で開発を進めてもらいたいわけでして、そこをベンダに付け込まれている面もあるでしょう。

もちろん、これらは開発現場にとっては最悪なわけでして。もともと達成不可能な計画を押し付けられ、最後はプロジェクト失敗の責任を負わされますからね。

上の名古屋地裁判例の判決文は、裁判所の判例データベース内に登録されていて、読むことができるのですが、読んでいると、こうした構図が透けてみえます。顧客側（原告）敗訴の判決ですけど、少々この顧客には同情してしまいますね。顧客の契約管理が甘かったのは確かのようですが（契約書すら存在しない）、ベンダにうまくやられた、という印象も受けます。