PR

 前回までは,システム開発委託契約で紛争が発生した場合の問題点を検討してきました。具体的には,それぞれの問題点について,裁判所がどのように判断する傾向にあるのか,また問題を防止するためにはどのような方法を採用すればよいのかについて解説しました。

 今回はシステム開発をめぐる法律問題の最終回となります。紛争回避の予防策について簡単に整理した上,紛争になってしまった場合の紛争解決にはどのような手段があるのかを取り上げます。

紛争回避の基本は文書をしっかり残すこと

 システム開発委託契約における紛争を回避するためには,まずは予防が重要です。その基本となるのは,文書をしっかり残すということです。契約書や仕様書が作成されて仕様が特定されていれば,契約の成立をめぐる問題やベンダーがシステムを開発する義務を負担する範囲等の問題は,かなり予防できるでしょう。

 ベンダーの義務が明確になっていれば,ベンダーによる債務不履行や瑕疵(かし)担保責任の問題も減少するのではないかと思います。私がユーザーの代理人だとしたら,契約書や仕様書で明示されていない機能(システムとして当然に有しているべき機能は除く)の不存在についてシステムの瑕疵であると主張して提訴することには,かなり躊躇(ちゅうちょ)します。

 さらに,議事録等において,システム開発におけるプロジェクトの進行状況,進行が遅延している場合にはその原因や対策等を記録しておきましょう。そうすれば,ベンダー側がプロジェクト・マネジメント義務を果たしていたことと共にユーザー側が協力義務を怠っていたかどうかが明らかとなり,結果として,ユーザーによる提訴を思いとどまらせることになるのではないかと思います(もちろん,逆にベンダー側のプロジェクト・マネジメント義務違反が明らかになる場合もあるかもしれませんが,それは致し方ないでしょう)。

 紛争回避の基本は,文書を作成して記録を残すことですが,単に文書を作成すればよいというものではありません。契約書や議事録等も,相手方に作成をまかせていたのではあまり意味がありません。相手方から提示されるこれらの文書は通常,相手方にとって有利な記載内容になっています。相手方から提示された契約書や議事録の内容をそのまま確認もせずに受け入れていたのでは,何らかの紛争が起きた場合,かえって不利になることも少なくありません。システム開発委託契約については,経済産業省からモデル契約等も提案されていますので,参照してみるとよいかと思います。

訴訟はベンダー,ユーザーの双方に重い負担をかける

 それでは,ベンダーとユーザーの間でいよいよ本格的に紛争になりそうな場合,どのような紛争解決手段があるのでしょうか。私が思いつく限りでも,以下のような手段が存在します。

  1. 当事者間による話合による解決
  2. 調停,仲裁,裁判所における和解等の第三者を交えた話し合いによる解決
  3. 判決による解決

 この原稿を読まれている方が紛争解決手段として真っ先に思い浮かべるのは,おそらく「3.判決による解決」ではないでしょうか。判決による解決は,話し合いを前提とせずに,当事者の主張・立証を基に,どちらの言い分が正しいのかということを,裁判所が判決という形式で言い渡すというものです。この方法であれば,判決が確定すれば紛争を終局的に解決することができます。

 しかし,判決による解決ではベンダー,ユーザーの両者にとって望ましい結論にならないことがしばしば見受けられます。ユーザーが勝訴してベンダーが敗訴した場合,敗訴したベンダーには仕事に対する報酬が全く支払われないことになります。勝訴したユーザーにとっても,システムを最初から再度構築しなおさなければならないという意味で,あまり望ましい結果ではないでしょう。

 逆に,ベンダーが勝訴してユーザーが敗訴した場合,ベンダーは代金を支払ってもらうことはできますが,ユーザーとの取引がなくなることを考えると,勝訴によるメリットはあまり大きくないかもしれません。特に,システム開発後の運用で利益を出そうと考えて,開発費用は低価格に見積りをしていた場合等がそれに当たります。また,敗訴したユーザーは,不満の残るシステムを使用し続けるか,別途システムを構築しなおす等の作業を強いられるでしょう。

 また,訴訟という方法は,ベンダー,ユーザー双方の担当者にかかる負担が大きくなる傾向があります。例えば,東京地裁平成9年2月18日判決では以下のように言及しています。

東京地裁平成9年2月18日判決
平成四年事件は,平成四年八月二〇日に提起され,平成八年一二月一七日に口頭弁論が終結されるまでに,三二回の口頭弁論期日が持たれた(その間の平成七年一二月一二日から平成八年一月一〇日までの間には,三回の和解期日も持たれた)。
(中略)
右当事者間の本件検証実験及び原因解明作業は実質二年余りにわたって行われ,特に,平成六年七月から八月までの二か月にわたる作業は,裁判所が夏季休廷期間中であるにもかかわらず,原告と補助参加人の代理人及び担当者が中心となって,夏季の休みも返上して,連日,協働して行われたものであることを記しておきたい。

 このように判決文の中で,代理人や担当者の頑張りを讃えることは,極めて異例です。この事件では,訴訟提起されてから,判決が言い渡されるまで4年以上経過し,その間に32回もの口頭弁論が実施され,当事者による検証実験が2年余りにわたって行われたとされています。おそらく,システムの専門家ではない裁判官が,自分が判決文を書ける程度にまで,当事者が争点の整理をしてくれたことに感激し,判決文の中に,このような記載を盛り込んだのでしょう。

 もちろん,裁判の迅速化が図られるようになり,現在では,同じ事件でも4年以上もの期間を要することはないでしょう。しかし,ベンダー,ユーザーの双方の担当者にかかる負担はそれなり重いものになることは間違いないと思います。従って,勝訴,敗訴した場合のメリット,デメリットを考えると,判決による解決がベストの選択であることは意外に少ないのではないかと思います。まずは,できる限り話し合いでの解決を模索するべきなのではないかと思います。