「仕事の完成」とは？～ソフトウェア開発紛争の解説①～

　近年、ITビジネスの急増に伴い、ソフトウェアやシステムの開発に関する紛争が多くなってきました。
　今回から数回に分けて、実際にあったソフトウェア等の開発に関する裁判例から、IT事業者の方が押さえておくべき法律知識や紛争の回避策などを解説します。

１　実務上よく見られる紛争パターン

　ソフトウェアやシステム（以下、まとめて「ソフトウェア」といいます）の開発は、発注者（ユーザー）が受注者（ベンダー）に対してシステム開発を依頼し、ベンダーないしその下請企業がシステムを完成させるという流れで進みます。
　裁判例で多く争われる争点は、次のものおおよそ整理できます。

1. ・仕事が完成しているかどうか

　ベンダーがソフトウェア開発を完成させたとして請負代金を請求し、これに対してユーザーがソフトウェア開発は完成していないとして代金の支払を拒否するパターン

2. ・契約の追加、変更があったかどうか

　ベンダーがソフトウェア開発契約に追加変更があるとしてその追加代金を請求し、これに対してユーザーが追加的変更契約の存在を否定し追加代金の支払を拒否するパターン

3. ・ソフトウェアに瑕疵があるかどうか

　ユーザーが、ベンダーが納品したソフトウェアには欠陥があるとして瑕疵担保責任または不完全履行に基づいて損害賠償を請求するパターン

4. ・完成の遅延についてベンダーに責任があるかどうか

　ユーザーが、ベンダーの帰責事由によりソフトウェア開発が遅延したとして、債務不履行に基づいて損害賠償請求するパターン

5. ・請負契約か準委任契約か

　ソフトウェア開発が中途で終了した場合で、ベンダーが本件ソフトウェア開発は準委任契約であるとしてその履行割合に相当する報酬を請求するのに対し、ユーザーが本件ソフトウェア開発は請負契約であるとして完成していない以上報酬は支払えないとするパターン

6. ・ベンダーの作業の出来高はいくらか

　ソフトウェア開発が中途で終了した場合で、ベンダーが終了時までの報酬を出来高として請求し、ユーザーがその査定金額を不相当であるとして支払を拒否するパターン

２　仕事が完成しているかどうかが争われたケース

　ソフトウェア開発に関連する紛争には、上記のとおり様々なパターンがありますが、まず最初に、実務上最も多い報酬に関する紛争から解説していきます。

２－１　仕事の完成がなぜ争われるのか？

　ソフトウェア開発契約が請負契約である場合には、ベンダーは、仕事を完成させた後でなければユーザーに対して報酬を請求することができません。

民法第６３２条　請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
民法第６３３条　報酬は、仕事の目的物の引渡しと同時に、支払わなければならない。ただし、物の引渡しを要しないときは、第六百二十四条第一項の規定を準用する。

　また、納品した成果物に瑕疵がある場合、発注者（ユーザー）は期間を定めて修補請求ができるほか、契約の解除や損害賠償請求ができると定められています。これらは一般に請負の瑕疵担保責任といわれます。

民法第６３４条　仕事の目的物に瑕疵があるときは、注文者は、請負人に対し、相当の期間を定めて、その瑕疵の修補を請求することができる。ただし、瑕疵が重要でない場合において、その修補に過分の費用を要するときは、この限りでない。
２　注文者は、瑕疵の修補に代えて、又はその修補とともに、損害賠償の請求をすることができる。この場合においては、第五百三十三条の規定を準用する。
民法第６３５条　仕事の目的物に瑕疵があり、そのために契約をした目的を達することができないときは、注文者は、契約の解除をすることができる。ただし、建物その他の土地の工作物については、この限りでない。

　そのため、仕事の完成は、請負契約においてベンダーがユーザーに対して報酬を請求できるかどうかの基準であり、非常に重要なポイントです。不具合があるが仕事は完成したと判断されたら、あとは瑕疵担保責任の問題となります。

２－２　仕事の完成とは？

　「仕事の完成」について、民法では特に定めはありません。もっとも、仕事の完成が争われた建築訴訟の判決では、仕事の完成について、次のように判示しています。

　この判決は建築訴訟の場合のものですが、システム開発の事例でも同様に判断されています。つまり、予定された工程を終了した場合には、「仕事は一応完成した」として、基本的にはベンダーには報酬請求権があると判断されます。

　もっとも、「では予定された工程はどういうものだったのか？」という点も争点になることが多く、この場合には、先に当初の開発工程の計画はどうだったのか、追加で合意された開発工程はどのようなものだったのかを認定し、そこから仕事の完成の有無を認定するという流れで判断します。

２－３　実際のケース（東京地裁平成１４年４月２２日判決）

　本件は、原告（ベンダー）が被告（ユーザー）と締結したシステム開発契約に基づいて開発したシステムを納品したが、被告からは入出力時の数値の齟齬などの複数の瑕疵があるとして報酬支払を拒絶されたため、仕事が完成したかどうかが争われた事案です。
　裁判所は、次のように判示して、原告は契約で定められたシステムを完成させたと認定しました。

　このように、東京地裁平成１４年４月２２日判決は、システム開発契約（請負契約）の場合の仕事の完成も建築訴訟の場合と同様に「予定していた工程まで終了しているかどうか」を基準にして、仕事が完成したかを判断するとしました。
　そして、この事案でのシステム開発業務は、要件定義、詳細設計、プログラミング、結合テスト、検証、本稼動、ドキュメント作成、ネットワーク回線工事、データ移行という予定工程のすべてが実施されていることから、仕事の完成が認められると認定しました。

　もっとも、この事案では、原告（ベンダー）は上記のとおり仕事を完成させたが、原告に原因がある重大な瑕疵があることから、被告（ユーザー）による契約解除の主張を認め、結局原告の報酬支払請求は認められませんでした。

３　仕事の完成を認定する際の証拠

　仕事の完成は、前述のとおり、当事者間で予定された作業工程が終わっているかどうかで判断されます。そのため、当事者間で予定していた作業工程が示されている資料が、仕事の完成の判断の際の証拠となります。

　具体的には、要件設計書、追加発注・仕様書が挙げられますが、これ以外にも、ユーザーが希望するシステムの仕様を説明した会議の議事録なども証拠となりえます。

４　検収と仕事の完成の関係性

　ソフトウェア開発契約書では、ベンダーが納品した成果物についてユーザーが検収したことをもって、はじめて報酬支払義務が生じるとしているものも多く見られます。では、検収は、仕事の完成とどのような関係にあるのでしょうか。

４－１　検収とは

　検収とは、ソフトウェアが予定したとおり作動することをユーザーが確認して納品を受けることを意味しており、これによって開発作業の終了が確認される性質を有する作業です。
　あくまで終了の確認であって、仕事が完成したかどうかは前述の判断基準により客観的に判断されますが、実務上、検収書が発行されていれば仕事は完成したと認定されることが多いです。

４－２　検収がなされない場合

　この場合でも、仕事が完成したかどうかは、前述の判断基準に従って判断されます。

　また、ソフトウェア開発契約書には、「ベンダーの納品後〇〇日以内にユーザーから検収不合格の通知が出されなければ、検収があったものとみなす」との条項が入れられることがありますが、こういった条項がある場合には、その条項に従って検収がされたとみなされ、仕事は完成したという認定がされることがあります。

４－３　検収は一応された場合

　一応、ユーザーから検収書が発行されたが、実はまったく検査をしていないなど形式的に発行したにすぎない場合には、その検収書から仕事の完成があったと認定することはできません。

　実務でも、開発を次のステージに進めるために形式的な検収書を発行することがありますが、開発の上流でこのようなことをすると、本来であればその時点で開発をストップできたにもかかわらず開発を進めてしまい、結果的に後に紛争が生じたときの損害額が大きくなってしまうという事態に発展するおそれがありますので、逐一検査をして検収書を発行すること（発行を求めること）が必須です。

４－４　法的観点から見た検収の意味合い

　このように、検収は、仕事の完成を判断する際の重要な考慮要素になります。形式的に検収書が発行される場合もありますが、ソフトウェアの内容について最も詳しいユーザーによる検修がなされているかどうかは、裁判所も重要視しています。

５　まとめ

　今回は、ソフトウェア開発に関連する紛争のうち、仕事の完成が争われるケースについて解説しました。
　報酬についての紛争はソフトウェア開発に関連する紛争の中でも多いですので、IT事業者の担当者は是非とも押さえておくべき法的知識です。
　次回以降も、他の紛争パターンについて解説します。

• tweet
•