システム開発を準委任型で行う場合の、契約書のチェックポイント

現在、我が国の国民生活や社会経済活動においてのIT利用度は、コンピュータの処理性能の飛躍的向上やインターネットの普及等に伴って、急速に高まっています。そのため、情報システムの障害による業務・サービスの停止や機能低下の社会的影響は、日々、拡大しており、システムの信頼性・安全性の向上は大きな課題となっています。

一方で、ITシステム開発という契約の累計は、立法当初に想定がなかったことから、取引内容が不明瞭になりがちであり、発注者（ユーザー）・受注者（ベンダー）間の密接なコミュニケーションを前提とした取引の可視化、役割分担・責任関係の明確化が、課題となっています。

また、情報システムが多様な要素の組み合わせによって構築されるようになったことから、かつてなかった組み合わせ等に係るリスクをも包含するようになってきています。

こうした情報システムの信頼性・安全性の向上のため、経済産業省においてガイドラインが公表され、その中で、システム開発におけるモデル契約が提示されており、逐条で解説が付されています。

本記事では、ITシステムの開発業務において、準委任型の契約を締結する場合の契約書のチェックポイントについて、経済産業省のモデル契約の条項を引用しながら解説していきます。

システム開発と準委任契約とは

準委任契約とは

準委任契約は民法上、委任契約の条文を準用する形で規定されています。

第10節 委任
第643条 委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。
第656条 この節の規定は、法律行為でない事務の委託について準用する。

準委任契約とは、ある者が他の者から委託されて事務処理を行うことを目的とする契約です。受任者は善良な管理者の注意義務（善管注意義務）をもって業務を遂行する義務を負います。善管注意義務とは、簡単に言うと「ベストを尽くす」ということになります。

請負契約との相違点

準委任契約では、上で述べた通り、受任者は善管注意義務を負うこととなりますが、請負契約と異なり、仕事の完成義務は負いません。したがって、明確な目的物が存在しない以上、受任者は、瑕疵担保責任は負わないこととなります。
もっとも、善管注意義務は負っているため、職務怠慢や致命的な注意不足等の場合は、債務不履行に基づく損害賠償責任負う場合や、契約の解除がなされる場合があります。

上記で述べた通り、準委任契約では仕事完成義務を負いません。一方で、請負契約では仕事完成義務を負うことになります。以下の記事では、システム開発を請負型で締結した場合について解説しています。

準委任型のモデル条文とチェックポイント

要件定義作成支援業務

（要件定義作成支援業務の実施）
第〇条 乙は、第〇条所定の個別契約を締結の上、本件業務として甲が作成した情報シ ステム構想書、システム化計画書等に基づいて、甲による要件定義書の作成作業を支援するサービス（以下「要件定義作成支援業務」という。）を提供する。

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うものとする。

要件定義は、ユーザーが構築しようとするシステムの要求仕様（ソフトウェアで実現すべき機能）をまとめる作業であり、ユーザーの業務内容に大きく依存する作業です。そこで、本節では、要件定義作業はユーザーが行い、ベンダーがこれをサポートする形態の準委任契約を前提として規定しています。
しかし、準委任だからといってベンダーが責任を一切負わないわけではなく、受任者として善管注意義務を負っているため、この善管注意義務を怠った結果、要件定義作成支援が適切になされなかった場合は、善管注意義務違反として債務不履行責任を負うこととなります。

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

要件定義作成支援業務の範囲等については、前の条項で示した条件に従い個別契約で取り決めるものとしています。

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

2. 乙も、要件定義作成支援業務の実施のために必要と認めるときは、要件定義検討会を開催することができるものとし、甲は、これに参加するものとする。 　

業務上の要求やシステムの機能要件・非機能要件を定義する要件定義書作成のためには、ユーザーの業務部門と情報システム部門やベンダーとの協働作業が必要となります。本工程が準委任型であることから、第1項は、開催の主体はユーザーとし、支援を行うベンダーがこれに参加するというかたちで規定しています。要件定義書作成のために必要となる事項の明確化又は内容の確認等は、全て要件定義検討会で行われ、ユーザーおよびベンダーは検討会での検討結果に拘束されます。

第2項は、ベンダーも要件定義支援業務の実施のために必要な場合に、要件定義検討会を開催できることを定めています。

（要件定義書の確定）
第〇条 甲が要件定義書の作成を完了した場合、甲及び乙は、個別契約において定める期間（以下「要件定義書の点検期間」という。）内に要件定義書が前条所定の要件定義検討会での決定事項に適合するか点検を行うものとし、適合することを確認した証として甲乙双方の責任者が要件定義書に記名押印するものとする。但し、点検の結果、要件定義書が要件定義検討会での決定事項に適合しないと判断された場合、甲は、協議の上定めた期限内に修正版を作成し、甲及び乙は再度上記の点検、確認手続を行うものとする。

2. 前項による甲乙双方の確認をもって、要件定義書は確定したものとする。

3. 第〇項の修正に伴い作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第〇条の手続によるものとする。 　

要件定義は、ベンダーから概算見積レベルの見積提案を受け、システム設計等を実施するために必要な要件を確定するフェーズです。要件が曖昧なままでは、ベンダーによる正確な見積が困難になり、その後の開発フェーズにおいて問題が生じるおそれがあります。本条は、その後の開発作業の前提となる要件定義書をユーザー・ベンダーが確認し、責任者が記名押印により確定させる手続を規定しています。要件定義書の確定のための点検において修正が必要と判断される場合もあるため、第1項但し書きは、この場合の手続を規定しています。

第2項は、ユーザー、ベンダー双方の確認をもって要件定義書を確定することを明確にしています。
第3項は、第1項但し書きにより要件定義書を修正して再点検を行う作業により、当初の想定よりもベンダーの作業量が増大したり、スケジュールの延長が必要になったりする場合など、個別契約の条件に変更が生じる可能性がある場合に、必要な変更を行うべきことを規定しています。

（業務の終了・確認）
第〇条 乙は、前条に定める要件定義書の確定後○日以内に、業務終了報告書を作成し、甲に提出する。

2. 甲は、個別契約に定める期間（以下「要件定義作成支援業務終了の点検期間」という。）内に、当該業務終了報告書の確認を行うものとする。

3. 甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、 乙に交付し、要件定義作成支援業務の終了を確認するものとする。

4. 要件定義作成支援業務終了の点検期間内に、甲が書面で具体的な理由を明示して異議を述べない場合には、甲は要件定義作成支援業務終了の点検期間の満了をもって、業務の終了を確認したものとみなされる。 　

本工程が準委任型であることから、本条は、ベンダーが善管注意義務に基づき適切に支援作業を実施したかを確認するため、作業内容を記録した業務終了報告書により確認を行う手続を規定しています。
第1項は、業務終了報告書の提出義務について定めています。
第2項は、報告書の確認が延びることをさけるために、報告書の点検期間を明確にしています。
第3項は、業務終了確認書へのユーザーの記名押印によって要件定義書作成支援業務の終了を確認することを定めています。
第4項は、点検期間内に、ユーザーから書面による異議が出されなかった場合のみなし修了確認について規定しています。この規定は、ユーザーが何らかの理由で適時に確認の手続をとらない場合、後続の作業の遅延をもたらしたり、あるいは確認の有無を明確にしないまま後続の作業に着手したりすることはユーザー・ベンダー間の責任関係をあいまいにする恐れがあることを考慮したものです。

外部設計書作成業務

（外部設計書作成支援業務の実施）
第〇条 乙は、第〇条所定の個別契約を締結の上、本件業務として甲による外部設計書
作成作業を支援するサービス（以下「外部設計書作成支援業務」という。）を提供する。

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うものとする。 　

外部設計書作成は、画面・帳票等、インターフェースにかかわる部分の使用を策定する業務です。外部設計書には、原則として、それに基づいてベンダーがプログラムを開発できる情報がすべて記載されている必要があります。外部設計書は様式使用を詳細化した内容を含むものですが、要求仕様を変更できるのは、業務内容を決定するユーザーの側です。
そこで、本条は、外部設計書については、ユーザーが責任をもって完成させ、ベンダーは、準委任契約における受任者として外部設計書の完成を支援する立場にあることを前提とするものです。
しかし、準委任だからといってベンダーが責任を一切負わないわけではなく、受任者として善管注意義務を負っています。よって、この善管注意義務を怠った結果、外部設計書の作成支援が適切になされなかった場合は、善管注意義務違反として債務不履行責任を負う場合があります。

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

外部設計書作成支援業務の範囲等については、個別契約で取り決めるものとしています。

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

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

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

画面・帳票などのインターフェースを決定する外部設計書作成のためには、ユーザーとベンダーとの協働作業が必須となります。
本工程が準委任型であることから、第1項は、開催の主体和ユーザーとし、支援を行うベンダーが参加するというかたちで規定しています。外部設計書作成のために必要となる事項の明確化又は内容の確認等は、すべて外部設計検討会で行われ、ベンダー及びユーザーは検討会での検討結果に拘束されます。
第2項は、ベンダーも外部設計支援業務の実施のために必要な場合に、外部設計検討会を開催できることを定めています。
第3項は、外部設計検討会における検討等により、ユーザーが要件定義書の内容を変更する場合、個別契約所定の作業期間、委託料等に影響を及ぼす可能性があるため、本契約及び個別契約内容の変更の手続によることとしています。

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

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

3. 第 1 項の修正に伴い作業期間、委託料等個別契約の条件を変更する必要が生じる場合 は、第〇条（本契約及び個別契約内容の変更）の手続によるものとする。

本条は、ユーザーが作成した外部設計書をユーザー・ベンダーが確認し、責任者が記名押印により確定させる手続を規定しています。
外部設計書の確定のための点検において修正が必要と判断される場合もあるため、第1項但し書きは、この場合の手続を規定しています。

第2項は、ユーザー・ベンダー双方の確認をもって外部設計書を確定することを明確にしています。
第3項は、第1項但し書きにより外部設計書を修正して再確認を行う作業により、当初の想定よりもベンダーの作業量が増大したり、スケジュールの延期が必要になるなど、個別契約の条件を変更する必要が生じる場合に、個別契約の変更を行うべきことを規定しています。

（業務の終了・確認）
第〇条 乙は、前条に定める外部設計書の確定後○日以内に、業務終了報告書を作成し、甲に提出する。

2. 甲は、個別契約に定める期間（以下「外部設計書作成支援業務終了の点検期間」という。）内に、当該業務終了報告書の確認を行うものとする。

3. 甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、 乙に交付し、外部設計書作成支援業務の終了を確認するものとする。

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

本工程が準委任型であることから、本条は、ベンダーが善管注意義務に基づき適切に支援作業を実施したかを確認するため、作業内容を記録した業務終了報告書により確認を行う手続を規定しています。
第2項は、報告書の確認が延びることを避けるため、点検期間を明確にしています。
第3項は、業務終了確認書へのユーザーの記名押印によって外部設計書作成支援業務の終了を確認することを定めています。
第4項は、点検期間内に、ユーザーから書面による意義が出されなかった場合のみなし修了確認について規定しています。この規定は、ユーザーが何らかの理由で適時に確認の手続をとらない場合、後続の作業の遅延をもたらしたり、あるいは確認の有無を明確にしないまま後続の作業に着手したりすることは、ユーザー・ベンダー間の責任関係をあいまいにするおそれがあることを考慮したものです。

ソフトウェア開発業務

基本設計であるシステム外部設計工程の規定の次は、詳細設計であるシステム内部設計工程に関する規定が続きます。システム内部設計工程では、前段階までの作業で開発対象や仕様が定義されているのが通常であることから、経産省のモデル契約では、請負型として規定しています。詳細は以下の記事で解説しています。

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

（ソフトウェア運用準備・移行支援業務の実施）
第〇条 乙は、第条所定の個別契約を締結の上、本件業務として甲が行うシステムテスト、導入・受入支援及び本件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準備･移行支援業務」という。）を行う。

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効果的に行われるよう、善良な管理者の注意をもって支援業務を行うものとする。

本条以下では、ソフトウェア運用準備・移行について、準委任型で行う場合の条項について規定しています。システム受入・導入支援段階では、ユーザーが主体的に行うのが一般的であるので、経産省のモデル契約では、ユーザーが主体となり、ベンダーがこれを支援する形態である準委任型として規定しています。
第2項は、本工程が準委任型であることから、ベンダーは受任者として善管注意義務を負うことを定めています。

（業務の終了・確認）
第 32 条 乙は、ソフトウェア運用準備・移行支援業務の終了後○日以内に、業務終了報告書を作成し、甲に提出する。

2. 甲は、個別契約に定める期間（以下「ソフトウェア運用準備・移行支援業務終了の点検期間」という。）内に、当該業務終了報告書の点検を行うものとする。

3. 甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、 乙に交付し、ソフトウェア運用準備・移行支援業務の終了を確認するものとする。

4. ソフトウェア運用準備・移行支援業務終了の点検期間内に甲が書面で具体的な理由を明示して異議を述べない場合には、ソフトウェア運用準備・移行支援業務終了の点検期間の満了をもって、業務の終了を確認したものとみなされる。

本条では、準委任型として、ソフトウェア運用準備・移行支援作業を、ベンダーが善管注意義務に基づき適切に行ったかどうかの確認を行う手続きを定めています。
第2項は、ベンダーはユーザーに対し、業務終了後所定の期間内に業務終了報告書を提出することとしています。
第3項は、点検期間を明確にした上で、ユーザーが業務終了報告書の確認を行うことを定めています。
第4項は、ユーザーが前2項の業務終了確認を怠る場合のみなし確認を定めています。

契約の性質の決定

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