システム開発の契約の種類は？契約形態別に注意点を弁護士がわかりやすく解説

システム開発委託契約とは

システム開発委託契約とは、ユーザーがベンダーに対してシステムの開発を依頼し、ベンダーがこれを承諾する契約です。
大規模なプロジェクトとなると契約金額は数億円に登ることもあり、ベンダーが一部の業務を下請企業に委託することもよく行われます。

システム開発委託契約で紛争が生じる主な理由

システム開発委託契約では、紛争に発展するケースも少なくありません。
システム開発委託契約で紛争が生じる主な理由は、次のとおりです。

• 契約書が適切に整備されていないから
• 契約書に沿った手続きが採用されていないから
• 報酬請求の条件があいまいになっているから

紛争が生じる理由を知っておくことで、契約書の整備によって紛争を予防しやすくなります。

契約書が適切に整備されていないから

契約書が適切に整備されていないことが原因となり、トラブルに発展することがあります。

規模の大きな開発案件において、最終的な契約書を取り交わさないことはほとんどありません。
しかし、中にはベンダーが納期を重視して正式に契約書を取り交わす前に開発作業に着手したものの、その後ユーザー側の都合によってそのベンダーに発注しないこととなり、契約成立の存否が争われることもあります。

また、ひな型などを元に契約書を作成したところ、契約内容が実態に即してなかったり、必要な取り決めがされていなかったりすることで、紛争に発展することも考えられます。

契約書に沿った手続きが採用されていないから

せっかく契約書がきちんと作り込まれていても、担当者が契約内容を理解していないことで、契約内容に沿った手続きが採用されずトラブルとなる場合があります。

特に、検収に関する条項に関して紛争が生じるケースが少なくありません。
たとえば、契約書に納品後ユーザーから何らの通知がない場合、一定期間を経過することで検収に合格したものとみなすとの規定があることは多いものの、ユーザー側の担当者がこれを理解しておらず、所定の期間を経過してから修正を依頼することなどが考えられます。

報酬請求の条件があいまいになっているから

報酬請求の条件があいまいであることから、トラブルとなる場合もあります。
システム開発委託契約で特に重要となる規定の1つは、報酬を請求できるタイミングに関する規定です。

システム開発委託契約での納品物はシステムという目に見えないものであるため、物の売買と比較して納品のタイミングが曖昧となってしまいがちです。
当然ながら、事前の打ち合わせ内容とかけ離れたシステムが納品された場合、報酬請求ができるはずはありません。

そのため、あらかじめ検査仕様書を作成し、その仕様書に沿ったシステムが納品され、検収を終えた時点で報酬が発生すると取り決めることが一般的です。
しかし、システムは開発過程で仕様が変わることもあるうえ、そもそも作成した検査仕様書があいまいであるケースも散見されます。

ベンダーは仕様に沿ったものを納品したと主張して報酬を請求する一方で、ユーザーが仕様に沿っていないと主張し報酬の支払いを留保することでトラブルとなる可能性があります。

システム開発委託契約の法的性質

民法には、13の典型契約が定められています。
システム開発委託契約は、このうち「請負契約」の側面もあれば「準委任契約」としての側面も持ち合わせています。

そのシステム開発委託契約がいずれであるかを定めることが、必ずしも紛争解決に有益であるとは限りません。
ただし、双方の性質を持つことを意識しておくことで、契約書に定めるべき事項を把握しやすくなります。

ここでは、請負契約と準委任契約の概要を解説します。

請負契約

請負契約とは、仕事の完成を目的とする契約です。

請負契約の場合、ベンダーの主な義務は仕事を完成させることです。
民法上、報酬の支払い時期は目的物を引き渡した時であり、再委託（下請）については特に制限はありません。

仕事の完成が遅れたり契約の目的に適合しない目的物を納品したりした場合、ベンダーは債務不履行責任を負います。

準委任契約

準委任契約とは、依頼された事務処理を目的とする契約です。

準委任契約の場合、ベンダーの主な義務は「善良な管理者の注意をもって事務処理を行うこと（つまり、プロとして必要な注意を払い業務を遂行すること）」であり、仕事を完成させる義務を負うわけではありません。

民法上、報酬の支払い時期は委任された事務を履行した後であり、再委託（下請）は原則として禁止されます。
善良な管理者の注意義務を怠った場合、ベンダーは債務不履行責任を負います。

システム開発委託契約書の2つの方式

システム開発委託契約書には、次の2つの方式があります。

• 一括請負契約方式
• 多段階契約方式

それぞれの方式の概要と、適しているケースについて解説します。

一括請負契約方式

1つ目は、一括請負契約方式です。

一括請負契約方式の概要

一括請負契約方式とは、システム開発委託契約を段階ごとに分けて行うのではなく、システム開発における全体のステップを1つの契約にまとめて行う方式です。

一括請負契約方式が適している主なケース

一括請負契約方式が適しているのは、システム開発が比較的小規模であり、開発期間も短期（3か月程度）であるケースです。
契約工程ごとに個別の契約を締結する多段階契約方式では、コストや手間がかかります。
そのため、比較的小規模なシステム開発の場合は、次で解説をする多段階契約方式をとる必要性は低く、一括請負契約が適していると考えられます。

多段階契約方式

2つ目は、多段階契約方式です。

多段階契約方式の概要

多段階契約方式とは、システム開発を複数の工程に分け、工程ごとに契約を締結する方式です。
ベースとなる基本契約を締結したうえで、システム開発の工程ごとに個別契約を締結します。

経済産業省ではシステム開発委託のモデル契約書を公表していますが、このモデル契約書では多段階契約方式が採用されています。
その理由として「見積り時期とリスクとの関係を踏まえて、ユーザー・ベンダーの双方のリスクアセスメントの機会を確保する観点から」と記載されています。※1

多段階契約方式が適している主なケース

システム開発が比較的小規模であり開発期間も短期である場合を除き、ほとんどのケースで多段階契約方式が適しているといえます。

長期間に及ぶシステム開発や規模の大きいシステム開発では、開発途上において仕様や金額、納期などが変わることが多いです。
工程ごとに契約を締結することで、より柔軟な対応が可能となるためです。

一括請負契約方式のメリット

一括請負方式のメリットは、ベンダー側とユーザー側でそれぞれ次のとおりです。

ベンダー側のメリット

一括請負方式をとるベンダー側のメリットは、途中で契約先を切り替えられたり、契約を打ち切られたりするリスクが低いことです。
最終的な報酬額があらかじめ確定されていることで、資金計画も立てやすくなります。

ユーザー側のメリット

一括請負方式をとるユーザー側のメリットは、契約の初期段階で支払うべき報酬額が確定することです。
また、ベンダー側の都合によってシステム開発が途中頓挫した場合、請負契約による報酬の請求要件を満たさないことから、原則として報酬を支払う必要はありません。

一括請負契約方式のデメリット

一括請負方式のデメリットは、ベンダー側とユーザー側でそれぞれ次のとおりです。

ベンダー側のデメリット

ベンダー側にとっての一括請負方式のデメリットは、当初の見積もりが甘い場合に、追加の報酬請求が難しくなりやすいことです。
開発期間が長かったり規模が大きかったりするシステム開発の場合、予期せぬ事態が発生する可能性が高く、開発の初期段階で正確な見積もりを提示することは容易ではありません。

ユーザー側のデメリット

ベンダーは余裕をもった見積もりを提示することが多く、結果的に報酬額が高くなる可能性があることです
一括請負方式の場合、先ほど解説したように初期段階で正確な見積もりが難しいことが多いためです。

多段階契約方式のメリット

多段階方式のメリットは、ベンダー側とユーザー側でそれぞれ次のとおりです。

ベンダー側のメリット

多段階契約方式のベンダー側のメリットは、工程ごとに報酬を請求できるため、資金繰りがしやすい点にあります。
工程ごとに見積もりを行うこととなるため、見積もりが甘く損失を被る事態を避けやすくなります。

ユーザー側のメリット

多段階方式のユーザー側のメリットは、ユーザー側の都合によってそのベンダーへのシステム開発委託を終了する場合であっても、原則として契約済みの工程までの報酬の支払いで済む点です。
また、ベンダーからの見積もりもより正確なものとなりやすく、報酬額が適正となる可能性が高くなります。

多段階契約方式のデメリット

多段階方式のデメリットは、ベンダー側とユーザー側でそれぞれ次のとおりです。

ベンダー側のデメリット

多段階契約方式を採用するベンダー側のデメリットは、工程ごとに見積もりや価格の交渉などが必要となり、手間がかかることです。
次の工程の委託をされる保証がないため、下請企業との契約も工程ごとに行う必要が生じます。
場合によっては、ユーザーが工程ごとにベンダーを切り替えたり、他のベンダーへ切り替える可能性をにおわせることで値下げ要請をされたりする可能性もあります。

ユーザー側のデメリット

多段階契約方式を採用するユーザー側のデメリットは、工程ごとに見積もりがなされるため、最終的な報酬額が当初の予定よりも膨らむリスクがある点です。

また、ユーザーとしては最終段階までそのベンダーに依頼する予定であったにも関わらず、ベンダー側の都合によってシステム開発が途中で頓挫した場合であっても、既に完了した契約単位での報酬の返還を受けることは困難となります。

たとえば、契約の工程を5つに分け、2つ目のフェーズまでが完了した段階でベンダー側の理由により3つ目のフェーズ以降の開発が困難になったとしても、2つ目のフェーズまでの契約が問題なく完了している以上、3つ目のフェーズ以降の開発ができないからといって、すでに支払った1つ目のフェーズと2つ目のフェーズの分の報酬の返還を受けることは困難になるということです。

まとめ

システム開発委託契約では、ベンダーとユーザーによる認識の違いや契約書の不備などから紛争に発展することが少なくありません。
システム開発委託契約による報酬額は高額となることも多く、一部の業務を下請けすることも多いため、見込んだ報酬が得られないこととなったり報酬の支払い時期が延びたりしてしまうと、ベンダーは大きな不利益を被る可能性があります。

そのため、システム開発委託契約ではひな型などをそのまま用いるのではなく、契約書を作り込むなどトラブルを予防するための対策が特に重要です。
自社のみで契約書を作り込むことは容易ではないため、弁護士へご相談ください。