前回は,システム開発契約を一括請負契約でカバーしようとすると,要件定義等の工程に費やした作業に対する報酬を受け取れない可能性が発生することを説明しました。では,このような場合,ベンダーは全く法律的に救済されることはないのでしょうか。過去の裁判例では,契約締結上の過失の理論によってベンダーの救済が図られたことがあります。今回はこの法理を紹介した上,実際の裁判例を検討してみようと思います。
裁判例に見るシステム開発紛争への契約締結上の過失の理論の適用
契約締結上の過失の理論とは,「契約の準備段階に入った当事者は,相手方当事者の財産等を害しない信義則上の義務を負い,この義務に違反して相手方に損害を発生させた場合には,これを賠償しなければならない」とする法理のことをいいます。この法理は,民法等の条文で定められているものではなく,判例法理として確立されたものです。
それではこの法理が,システム開発の場合にどのように適用されているのか,実際の裁判例に基づいて検討してみましょう。実際の裁判で,契約締結上の過失の理論に基づいてベンダーがユーザーに損害賠償を請求した事案には,名古屋地裁平成16年1月28日判決,東京地裁平成17年3月28日判決,東京地裁平成17年3月24日判決などがあります。これらの事案では,いずれも,ベンダーがユーザーに対し,開発費用等を請求しています。
これらの裁判例では,以下のような事実認定に基づいて,ユーザーに信義則上の義務違反があったかどうかを判断しています。
- 請負契約の要素である「仕事の内容」「請負代金」についての合意がどの程度成熟した状態であったのか
- 契約が成立しなかった理由
- 損害が発生した原因
以下,名古屋地裁と東京地裁の判決文に基づいて具体的に検討していきましょう。
事例1 名古屋地裁平成16年1月28日判決 ユーザとベンダーとの間で(1)カスタマイズの範囲及び費用の負担についての理解などに大きな隔たりがあり,ベンダーにおいて,カスタマイズ費用についてベンダーが主張する金額での合意ができない可能性があることは十分に予測し得たものと考えられること,(2)ベンダーが,カスタマイズ費用について明確に合意ができたとはいえない状況でカスタマイズ作業に入らざるを得なかったのは,原課との仕様確認作業が予定の期間に終了せず,平成11年1月のシステム稼働を実現するために早急にカスタマイズ作業に着手する必要があったためであるところ, 仕様確認作業が予定の期間に終わらなかったのは,ベンダー名古屋支社に「○○パッケージ(仮称)」の導入経験がなく,また,原課が要望する「○○パッケージ(仮称)」の帳票サンプルや「○○パッケージ(仮称)」を実際に使用した打合せを行うことができなかったことなどから,原課の納得を得られる内容の説明等ができなかったことなどに原因があることが認められることを考え併せると,ユーザにベンダーの主張する信義則上の義務の違反があったものと認めることはできない。 ※原告をベンダー,被告をユーザとして表記しています。 |
この事案を見ると,カスタマイズの範囲(請負契約における仕事の内容)および費用(請負代金)という請負契約の要素についての合意が十分ではなかったという事情,さらにシステム開発の中断により損害が発生したのは,ベンダー側の事情に起因するものであることを認定し,ユーザーに信義則上の義務違反がないと判断しています。
事例2 東京地裁平成17年3月28日判決 ベンダーとユーザとが本件システム開発の請負について相当具体的な交渉,協議を行ったことは確かであり,ユーザの担当者であるEがベンダーに発注したいとの意向を示していたことも一概には否定できないものの,
※原告をベンダー,被告をユーザとして表記しています。 |
この事案における1~7の事情は,請負契約の要素となる仕事の内容や請負代金について合意が十分ではなかったことを示しています。また,7では契約が成立しなかった理由がベンダーの見積り額の上昇にあることを,ユーザーの信義則上の義務違反を認定しなかった根拠として指摘しています。
逆に,契約締結上の過失を肯定した東京地裁平成17年3月24日判決は,ユーザーによるシステムの検証が実施されていたこと,ユーザーはベンダーに対し内示書を提出していたこと,ユーザーにおいて予算化が認められていたこと等を認定しており,仕事の内容や,請負代金については,ほぼ確実な合意が存在していたと評価することができる事案であった考えられます。その上で,ユーザー側のインターネット環境におけるデータの流出可能性等を理由とする開発の中止について,以下のように判示しています。
事例3 東京地裁平成17年3月24日判決 本件システムは,ユーザAのマーケティングにより,独自の開発としてはじまったものであること,末端の装置は,ユーザAの製品であり,ユーザらの顧客のもとにあり,その設置状況はユーザらの方が詳しいと考えられること,インターネットの利用による場合,データ等の流出の危険を完全に払拭することはできないが,相当の方策により,その危険を相当程度軽減できるほか,本件システムが,生化学自動分析装置の障害や消耗品の残量などの情報の収集等が中心であって,顧客の個人データなどとは全く無関係であること等からすると,ユーザらが理由とするところは,結局,ユーザらが,事前にマーケティング調査を行った際の目論見が外れたため,採算がとれないと判断してこれを中止したものと認められる。 ※原告をベンダー,被告をユーザとして表記しています。 |
この裁判例では,仕事の内容や請負代金について合意が十分成熟していたこと,および契約が成立しなかった理由はユーザー側の「ユーザらが,事前にマーケティング調査を行った際の目論見が外れた」という一方的な事情であることから,ユーザーの信義則上の義務違反を認定しています。
これらの裁判例を見ると,上記したように「1.請負契約の要素である『仕事の内容』『請負代金』についての合意がどの程度成熟した状態であったのか」という点を検討した上で,「2.契約が成立しなかった理由」や「3.損害が発生した原因」等も考慮して,ユーザーに信義則上の義務違反があったのかどうかを認定していると考えられます。
以上のように,契約の締結が認められなかった場合であっても,契約締結上の過失の理論を利用して,ベンダーがユーザーに対し損害賠償請求するという方法で,開発費用等をユーザーに請求できる場合もあります。しかし通常,契約交渉の中で「仕事の内容(開発するシステムの仕様)」や「請負代金」についての合意が得られそうであるにもかかわらず,最終的な契約が成立しないという場合は少ないように思われます。実際には,開発するシステムの仕様や請負代金についての合意が得られずに,交渉が長引くケースの方が圧倒的に多いのではないでしょうか。
そして,契約締結上の過失の法理が「仕事の内容(開発するシステムの仕様)」や「請負代金」についての合意がほぼ確実になっている状況で適用される法理であるとすれば,現実にこの法理でベンダーが救済されるケースは多くはないでしょう。また,契約締結上の過失の法理が認められそうなケースであったとしても,通常は,ユーザーの過失を立証することに労力を要するものです。
従って,結局のところ,前回述べた「工程ごとの個別契約」のような手法によってシステム開発に関する契約内容を契約書や仕様書等で文書化して,合意内容を明らかにしておくことが重要なのです。
次回以降は,契約が締結されたことを前提として発生する各種の問題について検討してみます。