契約が成立したというためには

課題

実作業に着手していながらも，契約書を取り交わす前にプロジェクトが頓挫した場合，何らかの対価をユーザに請求できないか？

ケース

上場会社であるＡ社は， J-SOX法に対応するため，Ｂ社に既存のシステムの改修を委託することになった。Ｂ社の営業は，Ａ社の担当からＢ社に対して発注する見込みである旨の話を聞き，さっそくチームの編成にとりかかった。一部の要員は，開発を専門とするＣ社からも調達した。一方では，Ａ社に対し，契約書のドラフトを提出し，Ａ社内での確認を依頼した（まだ署名・捺印に至っていない）。
（登場人物）
Ｐ部長：Ａ社のシステム部長
Ｙマネジャー：Ａ社のプロジェクトを担当するＢ社のマネジャー

Ｐ	「Ｙさん，今日はちょっと申し上げにくいお話が・・」
Ｙ	「金額がまだ固まっていませんでしたね。やはり予算が厳しいですか？」
Ｐ	「いえ，それ以前にですね。この不況で，当社の業績が悪化し，トップから『J-SOX対応は自社の要員でやれ。外部に委託する必要ない』と言われまして。というわけで，当社のメンバーのみで行いたいと。幸い，まだ契約の締結には至っておりませんので・・」
Ｙ	「え？契約書は取り交わしていませんが，先週は両社が参加してキックオフミーティングも行いましたよね。すでに，当社が既存システムのデータベースや帳票の分析作業を開始していることも御社は当然ご存じのはずですよ。当社はＣ社からも無理言って要員を確保していますし。急にやめると言われましても。」
Ｐ	「契約締結前の期間は，御社がリスクをとって作業を進めていると認識しておりますが・・」

このあと，ＰとＹ，そしてＡ社とＢ社はかなり険悪なムードになっていくことは想像に難くありません。

さて，システム開発プロジェクトの納期はますます短くなっているといわれています。
一方で，契約書の取り交わしに至るには営業，法務さらには互いの弁護士の間を行ったり来たりして時間がかかるため，このケースのように，契約書を取り交わす前に作業に着手するということはよくあるのではないでしょうか。

しかし，このケースにおけるＢ社は，それまで発生した費用をＡ社に請求できるでしょうか。
せめてＣ社に対して委託した費用だけでも請求できないものでしょうか。

このような場合，「契約が成立していたか」が第一の争点になります。
契約が成立していなければ，相手方に自らの権利を主張しようと思っても法律上の根拠がなく，原則として請求は認められにくくなります（注１）。

逆に，契約が成立していたといえれば，Ａ社の行為は契約の一方的な解除にあたりますので，Ｂ社は民法641条（注文者による契約の解除）や，民法648条3項（履行の割合に応じた報酬請求）などを根拠にして，損害賠償または報酬の請求ができる可能性があります。

では，どのような状態になっていれば契約が成立したといえるのでしょうか。
この点については，これまでにもいくつかの裁判で争われています。
裁判で契約が成立したか否かが争われた場合，成立したと主張する側（この場合はＢ社）がそれを証明しなければなりませんが，契約書がないときはどうすればよいでしょうか。
これまでの裁判例では，システム開発などの場合，契約書が存在しないときに契約の成立を認めることには消極的な傾向にあります。

本件のケースと似た裁判例（東京地裁平成17年3月28日判決）では，ベンダとユーザが出席した「キックオフミーティング」と題した会議の議事録や，担当者間のメールのやり取りが証拠として提出され，ベンダは契約の成立を証明しようとしました。

しかし，裁判所は，会議が設定された経緯が不明確であることや，ユーザの責任者が出席していなかったことなどを指摘しました。
さらに，「ＳＡ工程」と呼ばれる最初の工程に着手していたことまでは認めつつも，ユーザ側がその作業が有償であるとまでは認識していなかったとして，結局は契約の成立を認めませんでした（その他に種々の要素を判断していますが，ここでは割愛します）。

請負契約の場合，「仕事の内容（開発の対象）」と「報酬」が契約の本質的要素です。
システム設計・開発の場合，その対象は複雑ですから，契約書などの文書がないと，この本質的要素に関する合意があったこと（すなわち契約が成立したこと）を証明することは困難です。

ポイント１　双方の合意内容が書面になっていない段階で作業に着手することは，ベンダにとって大きなリスクとなる

参考までに，契約の成否が争点となったある裁判例では，

「業務用コンピューターソフトの作成やカスタマイズを目的とする請負契約は，業者とユーザー間の仕様確認等を経て，業者から仕様書及び見積書が提示され，これをユーザーが承認して発注することにより相互の債権債務の内容が確定したところで成立するにいたるのが通常であると考えられる。」
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　（名古屋地裁平成16年1月28日判決）

と述べられています。これを厳格に適用すると，契約が成立したというためには，設計が完了しなければならない，といった事態にもなりかねませんから，要件定義や設計，開発といったフェーズごとに段階的に契約を締結するといったことも考えなければならないでしょう。

ポイント２　比較的大規模の開発の場合，フェーズごとに段階的に契約を締結することで，契約不成立や，代金回収不能のリスクを回避することができる。

ポイント２については，ベンダだけのメリットだけでなく，ユーザにとっても，途中でベンダの切り替えや規模の変更が可能になるというメリットがあるといえるでしょう。

「契約書を取り交わすまでは，いっさい作業に着手すべきでない」と，正論をいうだけではプロジェクトを前に進めることはできません。
しかし，後になって契約不成立だと判断されるような状態で作業を開始することはとても危険なことです。
その判断は個別事情によって異なりますから，契約が成立しているといえるかどうかの判断に迷う場合には，弁護士に相談してみましょう。

（注１）	ただし，場合によっては「契約締結上の過失」という法理に基づいて，報酬としてではなく，損害賠償を請求できる可能性はあります。この点については別途次頁にて説明します。

システム開発に関する契約書のご相談

ＵＳＬＦには理系出身で、かつ企業の技術畑で勤務した経験を持つ弁護士が対応致します。単なる法的見地のみならず、ビジネス的見地を融合して紛争解決に対する最適解をご提案します。

「契約書を作成したい」
「契約書を作成したが不安だ」
「開発途中で契約解除されてしまった」

といったご相談に対応可能です。
お気軽にご相談下さい。

ＩＴ法務ドットコムに関して

ＴＯＰへ戻る	事務所概要	弁護士紹介
アクセス	弁護士費用の目安	相談の流れ

情報システム，ソフトウェア，ネットビジネスなどITに関する法律問題を鮫島正洋が解決！