システム開発の仕事の完成は検収だけで決まらない｜未完成の判断基準

システム開発は工期が長く、仕様変更や追加開発も重なりがちなため、ベンダーにとって「何をどこまでやれば仕事を終えたことになるのか」は切実な問題です。

システム開発の多くは請負契約で行われ、ベンダーは「仕事の完成」を約束します（民法632条）。法律上の完成は検収と必ずしも一致せず、裁判例では当初予定していた最後の工程まで終えたかどうかで判断されています。ただし、完成と認められても契約を解除される場合があります。

本記事では、システム開発が未完成かどうかの判断基準と、完成の前後で変わる報酬・解除の扱いを解説します。

システム開発の「完了」と法律上の「仕事の完成」の違い

システム開発の現場では、検収を終えた時点を「完了」と捉えるのが一般的です。しかし、法律上の「仕事の完成」はベンダーが契約上の債務を履行したかどうかで判断されるため、両者は必ずしも一致しません。

技術者の感覚では「検収の終了」がゴール

システム開発の現場で「開発の完了はいつか」と尋ねれば、「テスト工程を終えて成果物を納品し、ユーザーの検収が終わったとき」という答えが一般的でしょう。実際、システム開発は、実装すべき機能を洗い出す要件定義に始まり、各種設計書の作成、プログラムの実装へと進み、正しく動作するかを確認するテスト工程を経て、ユーザーの検収をもって終わるのが基本的な流れです。

そのため、技術者の目線では「システム開発の完了＝検収を終えたとき」と理解されることが多いでしょう。なお、ユーザーの検収がなかなか進まない場合の法律問題については、以下の記事で解説しています。

法律上の「仕事の完成」は請負人の債務の履行（民法632条）

法律の目線で「システム開発の完了はいつか」を考えると、問題になるのは、ベンダーが契約上負っている債務をいつ履行し終えたといえるかです。システム開発の契約は、基本的に請負契約か準委任契約のどちらかに分類されます。

2つの契約類型の違いは上の記事で詳しく解説していますが、請負契約では、ベンダー（請負人）が負う債務の内容そのものが「仕事の完成」です。

民法632条
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。

出典：e-Gov法令検索「民法」第632条

完成させるべきものが完成しなければ、ベンダーは債務を履行したことにならず、報酬も原則として請求できません。反対に、完成していれば、途中の経過をことさら問題にする意味はありません。

完成が問われるのは請負契約と成果完成型の準委任

「仕事の完成のタイミング」が問題になるのは、基本的に請負契約です。準委任契約は、特定の結果を約束する契約ではありません。専門性を持つ者が一定の裁量のもとで、善良な管理者の注意をもって事務を処理する（民法644条）ことを内容とする契約です（民法656条により委任の規定を準用）。請負は「結果」を、準委任は「プロセス」を重視する契約ともいえます。

準委任の報酬の定め方には、2つの型があります。1つ目の履行割合型では、事務を処理した後に報酬を請求できます（民法648条2項）。委任者の責めに帰することができない事由で履行できなくなった場合や、委任が途中で終了した場合でも、既にした履行の割合に応じて報酬を請求できます（同条3項）。

民法648条
1　受任者は、特約がなければ、委任者に対して報酬を請求することができない。
2　受任者は、報酬を受けるべき場合には、委任事務を履行した後でなければ、これを請求することができない。ただし、期間によって報酬を定めたときは、第624条第2項の規定を準用する。
3　受任者は、次に掲げる場合には、既にした履行の割合に応じて報酬を請求することができる。
一　委任者の責めに帰することができない事由によって委任事務の履行をすることができなくなったとき。
二　委任が履行の中途で終了したとき。

出典：e-Gov法令検索「民法」第648条

2つ目は、「成果物の納品に対して報酬を支払う」と定めた成果完成型です。システム開発の準委任でも、この型をとることがあります。成果完成型では、報酬は成果の引渡しと同時に支払われ（民法648条の2第1項）、請負の割合報酬の規定（民法634条）も準用されます（同条2項）。ベンダーが成果の完成そのものを約束するわけではありません。しかし報酬が成果と結びつくため、請負と同じように「成果が得られたか」が報酬を請求できるかどうかの分かれ目になります。

民法648条の2
1　委任事務の履行により得られる成果に対して報酬を支払うことを約した場合において、その成果が引渡しを要するときは、報酬は、その成果の引渡しと同時に、支払わなければならない。
2　第634条の規定は、委任事務の履行により得られる成果に対して報酬を支払うことを約した場合について準用する。

出典：e-Gov法令検索「民法」第648条の2

履行割合型の準委任では、完成よりも、事務を処理する過程での注意義務違反が問題になりやすいといえます。いずれにしても、「システム開発の完了はいつか」という問題は、多くの場合、請負契約における「仕事の完成」をどう解釈するかの問題に置き換えられます。

システム開発が未完成かどうかの判断基準

裁判例は、システム開発が未完成かどうかを、当初の契約で予定していた最後の工程まで終えたかどうかで判断しています。バグが残っていることだけを理由に、未完成とされるわけではありません。

「最後の工程」基準を示した裁判例（東京地判平成14年4月22日）

東京地方裁判所平成14年4月22日判決（判例タイムズ1127号161頁）は、ベンダーが開発した販売管理システムについて、納品・検収後の本稼働で処理速度などの不具合が判明した事案です。開発工程自体はすべて終わっていたことから、「仕事の完成」といえるかが争われました。

判決は、民法が「仕事の目的物に不具合がある場合」と「仕事が完成していない場合」とを区別していることを根拠に、目的物に不具合があっても、そのために仕事が未完成になるわけではないとしました。そのうえで、完成したかどうかは「仕事が当初の請負契約で予定していた最後の工程まで終えているか否か」を基準に判断すべきとし、本件では仕事の完成を認めています。最後の工程まで終えて目的物を引き渡した以上、ユーザーは、不具合があるというだけの理由で代金の支払を拒むことはできないとされました。

ただし、この判決は結論として、不具合が重大であることを理由に、ユーザーによる契約の解除を有効と認めています。完成と認められても解除される場合については、後で詳しく解説します。

バグが残っていても完成と認められる理由

システムには一定の不具合が残ることが避けられず、納品後の修補もある程度は予定されています。不具合の有無で完成を判断すると、いつまでも完成と認められず、ベンダーは報酬を請求できなくなってしまいます。

一方で、完成後に見つかった不具合については、ユーザーは契約不適合責任として、修補などの追完、報酬の減額、損害賠償、契約の解除を求めることができます（民法559条・562条〜564条）。修補に代わる損害賠償を請求する場合は、その支払と報酬の支払とを引き換えにするよう求めることもできます（民法533条）。不具合への救済はこうした枠組みで図られるため、「仕事の完成」をある程度広く捉えても、ユーザーに不公平を強いることにはなりません。

なお、完成か未完成かによって、報酬の請求（民法633条）、完成前の解除（民法641条）、不具合の責任を追及できる期限（民法637条）の扱いが変わります。そのため、この区別には実務上大きな意味があります。

仕様変更・追加開発で「最後の工程」が動く場合

ベンダーにとっては、「当初の仕様は既に満たしているのに、仕様の変更や機能の追加を再三求められ、業務を終わらせようにも区切りがつかない」という局面もあり得ます。

「最後の工程」の基準は、当初の契約で予定していた工程を前提にしています。そのため、仕様変更や追加開発について当事者が合意すれば、その分だけ完成を判断する対象となる仕事の範囲も変わり得ます。反対に、合意のない追加の要望は、当初の契約で予定した仕事に含まれないと考える余地があります。どこまでが当初の範囲で、どこからが変更・追加なのかで争いにならないよう、変更の内容・費用・納期は書面で合意しておくことが重要です。

追加開発の報酬をどう考えるかは、以下の記事で詳しく解説しています。

仕事の完成の前と後で変わる3つの法的効果

仕事の完成の前と後では、報酬を請求できるか、ユーザーがどのような場合に解除できるか、不具合の責任をどう追及するかが変わります。主な違いは次のとおりです。

未完成の段階では原則として報酬を請求できない（民法633条・634条）

請負契約の報酬は、仕事の目的物の引渡しと同時に支払うものとされています（民法633条）。そのため、仕事が完成したといえなければ、ベンダーは原則として報酬を請求できません。前払金を受け取っていた場合も、契約が解除されれば、原則として返還しなければなりません（民法545条）。

ただし、例外もあります。ユーザーの責めに帰することができない事由で完成できなくなった場合や、完成前に契約が解除された場合です。このとき、既にした仕事のうち可分な部分の給付によってユーザーが利益を受けるなら、その部分は完成したものとみなされ、ベンダーは利益の割合に応じて報酬を請求できます（民法634条）。

完成前ならユーザーは損害を賠償していつでも解除できる（民法641条）

仕事が完成するまでの間、ユーザーは、ベンダーに損害を賠償すれば、理由を問わずいつでも契約を解除できます（民法641条）。この場合、ベンダーは、既に支出した費用や、完成していれば得られたはずの利益などの賠償を求めることになります（損害の範囲は事案によって異なります）。また、納期を過ぎても完成しない場合には、債務不履行を理由とする解除（民法541条・542条）も問題になります。

システム開発における契約の解除については、以下の記事で詳しく解説しています。

完成後のバグは契約不適合責任として扱われる（民法562条〜564条）

仕事が完成すると、「仕事を完成させていない」ことを理由とする責任は問題にならなくなります。ただし、ベンダーの責任がすべてなくなるわけではありません。納期に遅れていた場合の責任は残りますし、引き渡したシステムが種類や品質の点で契約の内容に適合しなければ、ベンダーは契約不適合責任を負います（民法559条により562条〜564条を準用）。契約不適合責任も債務不履行責任の一種です。契約で品質保証を定めている場合は、その内容も問題になります。

ベンダーにとって特に注意が必要なのは、完成後でも契約を解除される場合があることです。解除されれば報酬を請求する権利を失うため、実務上は「仕事の完成」だけでなく、完成後の不具合の程度も争点になりやすいといえます。

完成と認められてもベンダーが報酬を失うケース

完成と認められても、ベンダーが必ず報酬を受け取れるわけではありません。完成後でも、軽微でない契約不適合があれば契約を解除され、報酬を失うおそれがあります。

契約が解除されると、ベンダーは原則として報酬を請求できなくなり、既に受け取った報酬があれば返還しなければなりません（民法545条1項）。ユーザーに損害が生じていれば、損害賠償を求められることもあります（同条4項）。

軽微でない契約不適合は催告解除の対象になる（民法541条）

完成後に不具合が見つかった場合、ユーザーは相当の期間を定めて修補などの追完を催告できます。その期間内に追完がなければ、契約を解除できます（民法564条・541条）。

民法541条
当事者の一方がその債務を履行しない場合において、相手方が相当の期間を定めてその履行の催告をし、その期間内に履行がないときは、相手方は、契約の解除をすることができる。ただし、その期間を経過した時における債務の不履行がその契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。

出典：e-Gov法令検索「民法」第541条

ただし書のとおり、残った不具合が契約と取引上の社会通念に照らして軽微であれば、解除はできません。ベンダーにとっては、催告を受けたら期間内に追完に応じ、対応の経過を記録しておくことが、解除を防ぐうえで重要です。

契約の目的を達せないと判断された裁判例（民法542条）

不具合が重大で、催告をしても契約をした目的を達するのに足りる履行がされる見込みがないことが明らかな場合などには、ユーザーは催告をせずに直ちに契約を解除できます（民法542条1項）。

システム開発では、完成を認めたうえで、不具合のために契約の目的を達することができないとして解除を有効とした裁判例があります。

• 東京地方裁判所平成14年4月22日判決（判例タイムズ1127号161頁）：前述の「最後の工程」基準を示した判決です。販売管理システムの仕事の完成は認めましたが、検索や月次処理に長時間を要するなど処理速度の不具合が重大で、システムを導入した目的を達することができないとして、ユーザーによる解除を有効と判断しました。
• 東京地方裁判所平成25年5月28日判決（判例タイムズ1416号234頁）：シナリオテストの完了をもって仕事の完成を認めたうえで、多数の不具合が発生して解消に長期間を要する状態にあったことなどから、契約の目的を達することができないとして解除を有効と判断しました。控訴審の東京高等裁判所平成26年1月15日判決も解除を有効としたうえで、ユーザー側にも多数の仕様変更の申入れやデータ移行作業の不備などがあったとして、過失相殺の法理により損害額から4割を減額しています。

どちらの裁判例も、「完成と認められれば報酬を受け取れる」とは限らないことを示しています。ベンダーは、完成したかどうかだけでなく、残った不具合がシステムの導入目的にどの程度影響するかも意識しておく必要があります。

契約不適合を主張できる期限は「知った時から1年以内の通知」（民法637条）

完成後の不具合について責任を追及するには、ユーザーは不具合を知った時から1年以内に、その旨をベンダーに通知する必要があります。

この期間内に通知しなければ、ユーザーは、その不具合を理由とする追完・報酬の減額・損害賠償・契約の解除のいずれもできなくなります（民法637条1項）。ただし、引渡しの時点でベンダーが不具合を知っていたか、重大な過失によって知らなかった場合は、この期間制限は適用されません（同条2項）。

民法637条
1　前条本文に規定する場合において、注文者がその不適合を知った時から1年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。
2　前項の規定は、仕事の目的物を注文者に引き渡した時（その引渡しを要しない場合にあっては、仕事が終了した時）において、請負人が同項の不適合を知り、又は重大な過失によって知らなかったときは、適用しない。

出典：e-Gov法令検索「民法」第637条

ここでいう通知は、一般に、不具合の種類やおおよその範囲を伝えれば足りると解されており、1年以内に訴訟を起こすことまでは求められていません。通知をした後の権利は、一般の消滅時効（権利を行使できることを知った時から5年、行使できる時から10年。民法166条1項）にかかります。

もっとも、システム開発の契約では、「検収完了後○か月以内」など、民法とは異なる期間や手続を定めていることが少なくありません。不具合が見つかったら、まず契約書の定めを確認することが重要です。

不具合を知ってから1年という期間は、修補をめぐるやり取りを続けているうちに過ぎてしまうことがあります。ユーザーは期限内にどのような内容を通知すべきか、ベンダーは通知を受けた後にどう回答すべきかで、その後の請求や反論の幅が変わります。期限が気になり始めた段階で、システム開発の紛争に詳しい弁護士にご相談ください。

下請開発・フリーランスへの発注では支払期日にも注意（取適法・フリーランス法）

元請ベンダーが下請に開発を再委託する場合や、個人のフリーランスに発注する場合は、民法に加えて、支払期日を定める法律にも注意が必要です。

取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律）は、プログラムなどの情報成果物の作成委託のうち、資本金や従業員数の基準を満たす取引に適用されます。委託事業者は、検査をするかどうかを問わず、給付を受領した日から60日以内の、できる限り短い期間内で支払期日を定めなければなりません（同法3条）。中小受託事業者の責めに帰すべき理由がないのに受領を拒むことや、不当に給付をやり直させることも禁止されています（同法5条）。

ただし、取適法の対象は、業として提供したり請け負ったりするシステムの作成を他の事業者に委託する場合や、自社で使うシステムの作成を業として行っている企業がその作成を委託する場合です。自社でシステムを作成していない企業が、自社用のシステムをベンダーに直接発注する取引は、通常は対象外です。

また、フリーランス法（特定受託事業者に係る取引の適正化等に関する法律）は、従業員を使用しない個人や一人社長への業務委託に適用されます。従業員を使用するなどの発注事業者は、検査をするかどうかを問わず、給付を受領した日から60日以内に支払期日を定めなければなりません（同法4条1項。再委託の場合の例外あり）。

これらの法律が適用される取引では、支払期日は検収の完了ではなく、給付を受領した日から数えます。「検収が終わっていない」ことを理由に、支払を先延ばしすることはできません。

まとめ：システム開発の未完成トラブルは早期の法的整理を

システム開発の「完了」と、法律上の「仕事の完成」は必ずしも一致しません。本記事のポイントは次の3つです。

• 仕事の完成は、検収だけでなく、当初の契約で予定していた最後の工程まで終えたかどうかで判断される
• 完成の前と後で、報酬の請求、ユーザーによる解除、不具合の責任追及の扱いが変わる
• 完成と認められても、重大な不具合があれば契約を解除され、報酬を失うおそれがある。不具合の通知には、知った時から1年という期限がある

出口が見えにくいシステム開発プロジェクトでも、争いになったときには、法律上の「仕事の完成」という基準が整理の出発点になります。

「未完成だから支払わない」と言われたベンダーにとっては、工程の完了・納品・検収の記録をそろえられるかどうかが、報酬を請求できるかを左右します。相手方への回答で不用意に「未完成」を認めると、後の交渉や訴訟で不利になるおそれもあります。ユーザーにとっても、不具合の通知期限や解除の要件を誤ると、責任を追及する手段を失いかねません。

モノリス法律事務所は、元ITエンジニアの代表弁護士のもと、システム開発の契約書の作成から紛争への対応まで、IT分野の法務を中心に手がけています。トラブルの兆しが見えた段階でご相談いただくことで、取りうる選択肢を広げられます。