請負型のシステム開発における契約書の要チェックポイントとは

経済産業省は、「情報システムの信頼性向上に関するガイドライン」において、ITシステム開発契約におけるモデル条項を提示しています。インターネットの普及などにより、情報システムの障害による業務・サービスの停止や機能低下の社会的影響は深刻化する一途をたどっており、システムの信頼性・安全性向上が喫緊の課題となっている一方で、ITシステム開発という契約類型は、取引内容が不明瞭になりがちであるため、その可視化、及び役割分担・責任関係の明確化を本条項は図っています。本記事では、ITシステムの開発業務において、請負型の契約を締結する場合の契約書のチェックポイントについて、経産省モデル契約の条項を引用しながら解説していきます。

システム開発と請負契約

請負契約とは

請負契約は民法上、以下のように規定されています。

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

請負契約では、条文上「仕事を完成することを約」する事が要件となっています。例えば、期日までにある一定のシステムを作る事を契約の目的とした場合、ベンダー側の債務は「期日までにシステムを完成させる事」となります。もし約束の期日までにシステムを完成させることが出来なかった場合には、履行遅滞としての債務不履行責任を課される場合があります。もっとも、期日までにシステムを完成させ納品したのちに不備が見つかった場合は、上で述べたベンダー側の債務は既に履行されているため、債務不履行は問題にならず、以後は瑕疵担保責任の問題となります。システム開発において、いかなる場合に「仕事の完成」が認められるかについては、以下の記事にて詳細に解説しています。

準委任契約との相違点

請負契約では、ベンダーは仕事の完成義務を負うので、引き渡した成果物に瑕疵があった場合には、瑕疵担保責任を負うこととなります。これに対し、準委任契約では仕事の完成義務はないので、請負契約のような瑕疵担保責任を負うことはありません。もっとも、事務処理の過程において、善管注意義務が認められる場合には、別途損害賠償等の債務不履行責任を負う場合があります。どのような責任がシステム開発契約において問題となるかについては、以下の記事にて詳細に解説しています。

請負型のモデル条文とチェックポイント

要件定義作成支援業務

要件定義は、ユーザーが構築しようとするシステムの要求仕様をまとめる作業です。要件定義工程では、システム構築の方向性を検討し、どのようなシステムを構築するか決定する作業であり、成果物が具体的に想定できていないことから、経済産業省のモデル契約は、準委任型として規定しています。詳細は以下の記事で解説しています。

外部設計書作成業務

（外部設計書作成業務の実施）
第○条 乙は、第○条所定の個別契約を締結の上、本件業務として第〇条の規定により確定された要件定義書に基づき、本件ソフトウェアの外部設計書作成業務を行う。

2.外部設計書作成業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には適時に、これに応ずるものとする。

外部設計書作成は、画面・帳票等、インターフェースにかかわる部分の使用を策定する業務です。外部設計書には、原則として、それに基づいてベンダーがプログラムを開発できる情報がすべて記載されている必要があります。外部設計書は様式使用を詳細化した内容を含むものですが、要求仕様を変更できるのは、業務内容を決定するユーザーの側です。もっとも、外部設計書作成業務の前フェーズの成果である要件定義書がユーザーの需要を明確に定義出来ており、ベンダーが完成させる仕事の内容が明確になっている場合には、外部設計書の作成について、請負型でベンダーが主体となる形で、契約を締結することが出来ます。

第1項は、本工程が請負型であることから、ベンダーが業務遂行の主体であることを規定しています。もっとも、請負型の契約であっても、外部設計はユーザーの業務内容の確定にかかわる部分が大きいことから、ユーザーの積極的関与が求められます。そこで、第２項は、ベンダーはユーザーに対しシステム仕様の検討・決定に必要な協力を要請することができ、ユーザーは適時にこれに応ずるものとして、システム仕様の検討はベンダーとユーザーの共同作業であることを明確にしています。

（外部設計書作成業務に係る個別契約の締結）
第○条 甲及び乙は、外部設計書作成業務について、第〇条第〇項記載の取引条件を協議 の上決定し、外部設計書作成業務に係る個別契約を締結する。

外部設計書作成業務の範囲等については、前の条項で定めた取引条件に従い、個別契約で取り決めるものとしています。

（外部設計検討会）
第○条 乙は、外部設計書作成のために必要となる事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、外部設計書作成について第〇条所定の連絡協議会（以下本節において「外部設計検討会」という。）を開催し、甲はこれに参加するものとする。

2.甲も、外部設計書作成のために必要と認めるときは、甲が外部設計検討会を開催することができるものとし、乙はこれに参加するものとする。

3.外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第33条（本契約及び個別契約内容の変更）の手続によるものとする。

画面・帳票などのインターフェースを決定する外部設計書作成のためには、ユーザーとベンダーとの協働作業が必須となります。本工程は請負型であることから、第１項は、検討会の主催はベンダーで、ユーザーがこれに参加するという形で規定がされています。外部設計書作成のために必要となる事項の明確化又は内容の確認等は、すべて外部設計検討会で行われ、ベンダー及びユーザーは検討会での検討結果に拘束されます。

第2項は、ユーザーも外部設計書作成業務の実施のために必要な場合に、外部設計検討会を開催できることを定めています。
第3項は、検討等により、ユーザーが要件定義書の内容を変更する場合、個別契約所定の作業期間、委託料等に影響を及ぼす可能性があるため、別の条項にて定めた本契約及び個別契約の内容の変更の方法に従うこととしています。

（外部設計書の納入）
第○条 乙は個別契約に定める期日までに、外部設計書及び外部設計書検収依頼書（兼納品書）を甲に納入する。

本工程が請負型であることから、ベンダーは外部設計書等を成果物として納入することとなります。

（外部設計書の承認及び確定）
第○条 甲は、個別契約において定める期間（以下「外部設計書の点検期間」という。） 内に外部設計書が、第〇条の規定により確定された要件定義書並びに第○条所定の外部設計検討会での決定事項に適合するか、及び論理的誤りがないか点検を行うものとし、適合すること及び論理的な誤りがないことを承認した証として甲乙双方の責任者が外部設計書承認書に記名押印するものとする。但し、点検の結果、外部設計書が、第○条の規定により確定された要件定義書及び外部設計検討会での決定事項に適合しない部分又は論理的誤りが発見された場合、乙は、協議の上定めた期限内に修正版を作成して甲に提示し、甲は再度上記点検、承認手続を行うものとする。

2.外部設計書の点検期間内に甲が書面で具体的な理由を明示して異議を述べない場合 には、甲は外部設計書の点検期間の満了をもって、外部設計書を承認したものとみなされる。

3. 前2項による甲の承認をもって、外部設計書は確定したものとする。

外部設計工程では、その後の内部設計書の作成などを実施するために必要な要件を確定しますが、要件の確定が曖昧なままでは、その後の開発において問題が生じるおそれがあります。本条では、その後の開発作業の前提となる外部設計書をユーザーが点検し、ユーザーの承認により確定させる手続を規定しています。

第1項は、ユーザーは、別の条項で確定された要件定義書及び外部設計検討会での検討結果との適合性並びに論理的誤りがないかを点検する旨を規定しています。外部設計書の承認のための点検において修正が必要と判断される場合もあり、同項但し書きは、この場合の手続を規定しています。
第2項は、仮に承認の記名押印が未了でも一定期間内にユーザーから意義が述べられなければ、ユーザーによる承認がなされたものとみなす規定です。ユーザーからの承認の有無が曖昧なまま内部設計に入ることは、後になってトラブルを引き起こす恐れがあるため、かかる問題を防止することを本項は意図しています。

そして第3項は、ユーザーの承認をもって外部設計書が確定することを定めています。

（瑕疵担保責任）
第○条 前条の確定後、外部設計書について要件定義書及び第○条所定の外部設計検討会での決定事項との不一致又は論理的誤り（以下本条において「瑕疵」という。）が発見された場合、甲は乙に対して当該瑕疵の修正を請求することができ、乙は、当該瑕疵を修正するものとする。但し、乙がかかる修正責任を負うのは、前条の確定後○ヶ月以内に甲から請求がなされた場合に限るものとする。

2.前項にかかわらず、瑕疵が軽微であって、外部設計書の修正に過分の費用を要する場合、乙は前項所定の修正責任を負わないものとする。

3.第1項の規定は、瑕疵が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。

本条は、外部設計書に関する瑕疵担保責任について定めています。瑕疵担保期間は、情報システムの規模や対価等を考慮して、当事者間での協議によって、相当と考えられる期間を定めることになります。

第１項は、外部設計書と要件定義書及び外部設計検討会での決定事項との不一致又は外部設計書の論理的誤りを瑕疵としています。

第2項では、瑕疵が軽微であっても、納入物の修正に過分の費用を要する場合に無償での修正をベンダーに求めるのは酷であるので、民法634条第1項但し書きに準じ、ベンダーの保護を図っています。

第3項は、民法第636条但し書きに準じ、瑕疵がユーザーの指示や提供した資料などに起因する場合には、ベンダーが資料等又はユーザーの指示が不適当であることを知って指摘しない場合には、担保責任を免れないとする規定です。

なお、瑕疵担保責任は任意規定であることから、かかる規定を置かなかった場合は民法の一般原則に従って処理がされることになります。瑕疵担保責任は2020年の4月より施行される改正民法の影響を大きく受けているため、改正民法施行後は、従来と扱い方が異なってくる分野となります。詳細は以下の記事にて解説しています。

ソフトウェア開発業務

（ソフトウェア開発業務の実施）
第〇条 乙は、第 25 条所定の個別契約を締結の上、本件業務として前各節により確定したシステム仕様書に基づき、内部設計からシステムテストまでのソフトウェア開発業務を行う。

2.ソフトウェア開発業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には適時に、これに応ずるものとする。

本条以下では、ソフトウェア開発をベンダーが請負型で行う場合の条項について規定しています。システム内部設計工程では、前段階までの作業で開発対象や仕様が定義されているのが通常であることから、経産省のモデル契約では、請負型として規定しています。

（ソフトウェア開発業務に係る個別契約の締結）
第〇条 甲及び乙は、当該ソフトウェア開発業務について、第〇条第〇項記載の取引条件を協議の上決定し、ソフトウェア開発業務に係る個別契約を締結する

ソフトウェア開発業務の範囲などについては、前で定めた取引条件に従って、個別契約で取り決めるものとしています。

（納入物の納入）
第〇条 乙は甲に対し、個別契約で定める期日までに、個別契約所定の納入物を検収依頼書（兼納品書）とともに納入する。
2.甲は、納入があった場合、次条の検査仕様書に基づき、第〇条（本件ソフトウェアの検収）の定めに従い検査を行う。
3.乙は、納入物の納入に際し、甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には、すみやかにこれに応じるものとする。
4.納入物の滅失、毀損等の危険負担は、納入前については乙が、納入後については甲が、それぞれこれを負担するものとする。

本工程が請負型であることから、完成したソフトウェア等を検査の対象となる成果物として納入することになります。第1項は、納入物を検収依頼書（兼納品書）とともに納入することを定めています。

第2項は、ユーザーによる検査の実施について定めています。
第3項は、個別契約で定めた納入場所への納入については、ユーザーの協力を要する場合（ユーザーの事務所に搬入して納入する場合、ユーザーの実運用環境に稼動可能な状態で納入する場合等）もありうることから、ユーザーの協力義務を定めています。
第4項は、納入物に生じた滅失・毀損の危険負担に関する条項であり、物理的な支配の移転により危険負担の移転時期を分けています。

（本件ソフトウェアの検収）
第〇条 納入物のうち本件ソフトウェアについては、甲は、個別契約に定める期間（以下、「検査期間」という。）内に前条の検査仕様書に基づき検査し、システム仕様書と本件ソフトウェアが合致するか否かを点検しなければならない。

2.甲は、本件ソフトウェアが前項の検査に適合する場合、検査合格書に記名押印の上、乙に交付するものとする。また、甲は、本件ソフトウェアが前項の検査に合格しない場合、乙に対し不合格となった具体的な理由を明示した書面を速やかに交付し、修正又は追完を求めるものとし、不合格理由が認められるときには、乙は、協議の上定めた期限内に無償で修正して甲に納入し、甲は必要となる範囲で、前項所定の検査を再度行うものとする。

3.検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。

4.本条所定の検査合格をもって、本件ソフトウェアの検収完了とする。

本工程が請負型であることから、本条では納品されたソフトウェアに関する検収を行う手続きについて定めています。

第1項は、本件ソフトウェアについて、検査期間内に検査仕様書に基づき検査し、システム仕様書と本件ソフトウェアが合致するかを点検することを規定しています。
第2項は、本件ソフトウェアがシステム仕様書に適合しないことが判明した場合、ベンダーはこれを修正して、修正版をユーザーに納入することを義務づけています。
第3項は、みなし検査合格に関する規定を定めることにより、ユーザーの都合により検収が引き延ばされることを防ぐものです。
第4項は、検査合格をもって本件ソフトウェアの検収完了とすることを明記しています。

（瑕疵担保責任）
第〇条 前条の検査完了後、納入物についてシステム仕様書との不一致（バグも含む。以下本条において「瑕疵」という。）が発見された場合、甲は乙に対して当該瑕疵の修正を請求することができ、乙は、当該瑕疵を修正するものとする。但し、乙がかかる修正責任を負うのは、前条の検収完了後○ヶ月以内に甲から請求された場合に限るものとする。
2.前項にかかわらず、瑕疵が軽微であって、納入物の修正に過分の費用を要する場合、乙は前項所定の修正責任を負わないものとする。
3.第1項の規定は、瑕疵が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。 　

本工程が請負型であることから、本条は納入物に関する瑕疵担保責任について定めています。履行がなされていない（仕事が完成していない）場面での債務不履行責任と、履行が一応完了した（仕事が完成した）後の場面での瑕疵担保責任の境界は実務上判断が難しいところがあります。システム開発についてシステムを完成させたと認められるか否かは、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準とすべきであるとする裁判例（東京地判平成14年4月22日）があります。ソフトウェアを予定されている最後の工程まで終えて納品及び検査合格後、瑕疵が発見された場合には、原則として瑕疵担保責任が適用されることになります。

第1項は、ソフトウェア開発業務において生じた「システム仕様書との不一致」を瑕疵とします。外部設計段階で生じた機能不足などについては、本条ではなく、外部設計段階における瑕疵担保責任などの規定により責任の所在が決まります。瑕疵担保期間は、情報システムの規模や対価等を考慮して、当事者間での協議によって、相当と考えられる期間を定めることになります。

第2項では、瑕疵が軽微であっても、納入物の修正に過分の費用を要する場合に無償での修正をベンダーに求めるのは酷であるので、民法第634条1項但書に準じた規定を設けています。

第3項は、民法第636条但書に準じ、瑕疵がユーザーの指示や提供した資料等に起因する場合にはベンダーは担保責任を負わないが、ベンダーがかかる資料等又はユーザーの指示が不適当であることを知って指摘しない場合には担保責任を免れないとする規定です。

どのような場合に瑕疵が認定されるのか、認定された場合の具体的な責任の内容については下記記事にて詳しく説明しています。

ソフトウェア運用準備・移行支援業務

システムの受入・導入段階では、ユーザーが主体的に行うのが一般的であるので、経産省のモデル契約では、ユーザーが主体となり、ベンダーがこれを支援する形態の準委任型として規定しています。

契約の性質の決定

契約の性質を決するために、契約の全体をみて、その目的が、「完成された成果物を給付する」ことにあるのか、ベンダーが「合理的に業務遂行する」ことにあるのか、という点から検討することになります。完成すべき目的物の内容がある程度具体的に確定しそれに向けてプロジェクトが進行していたかどうかが大まかな目安になります。具体的にどのような点に着目するのかについては、以下の記事にて詳細に解説しています。