ITビジネスに関わる契約を取り扱う場合、取引の実情だけでなく技術的な背景に対する一定の理解も必要となります。ITビジネスに関する取引から契約を分類するとすれば、資産を提供するレンタルサーバー契約やシステム（ソフトウェア）開発契約等があり、サービスを提供するSES契約やシステムの運用・保守契約，クラウドサービス利用契約等があります。

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

システム開発委託（ソフトウェア開発委託）契約はシステムの発注者が、受注者（ベンダ）に対してシステム開発に関する業務を委託する際に締結する契約のことであり、その時に作成する契約書がシステム開発委託契約書となります。契約の形態は請負契約，委任契約（正確には準委任契約）または請負契約＋委任契約が考えられます。

システム開発委託契約書の全体像

システム（ソフトウェア）開発は着手から完成までに長期間を要することが多いです。ユーザー（発注者）の要望する内容をシステムに反映させて開発する場合、契約交渉のみならず仕様確定に向けて常にやり取りをしながら進めていく必要があります。ユーザー，ベンダ（受注者）間に認識の齟齬が生じないようにするため、やり取りは書面を介して行うようにすることが大切です。システム開発に関する契約書は、両当事者がシステムの完成に向けて行動するための指針としても有効に機能するよう意識して作成することが重要です。システム開発はウォーターフォール型の手法が用いられることが多く、以下ではウォーターフォール型の手法を用いることを前提にしています。

契約書の構成

システムの完成までを一括で請け負う構成（一括契約方式）とシステムの開発を複数の工程（要件定義，基本設計，詳細設計，プログラミング・単体テスト，システムテスト，運用テスト等）に分けて工程毎の個別契約を締結する構成（多段階契約方式）があります。比較的小規模のシステムや当事者の意向により一括契約方式を締結する場合もありますが、工程を複数に分けて、各工程にかかる契約を締結する場合が多いと思われます。多段階契約方式の場合、各契約に共通の条件についてまとめて規定する基本契約を締結した上で、具体的な委託業務等は個別契約で定める場合が多いです。

請負契約と委任契約（準委任契約）

システム開発委託契約は請負契約あるいは準委任契約として締結されるのが通常です。仕事の完成を目的とする場合は請負契約が締結され、事務の処理を目的とする場合には準委任契約が締結されます。請負か準委任かというのは、契約の名称や条項に「請負契約である」とか「委任契約である」等と記載されていることによって決まるものではなく、契約の実質的な内容が仕事の完成を内容としているのか、事務の処理を内容として委託しているのかによって定まります。請負契約と準委任契約とではその性質に違いがありますが、個別契約を締結するにあたって、請負と準委任のどちらを選択すべきかということは契約交渉の本質ではありません。それぞれの個別の契約の目的に照らし、ベンダが単独で遂行できるような内容の工程か、発注者の情報提供や協力が必要な内容の工程なのか等、契約を締結する段階で完成すべき仕事や目的の内容が明確になっているかということが重要です。システム開発の各工程と契約の性質を簡単に明記すると

• システム化計画，要件定義　⇒　『準委任契約』
• 基本設計　⇒　『請負契約，準委任契約』
• 詳細設計　⇒　『請負契約』
• プログラミング＋単体テスト　⇒　『請負契約』
• システム結合テスト　⇒　『請負契約，準委任契約』
• 運用テスト　⇒　『準委任契約』

と考えられます。

契約書の法的性質

システム開発委託契約は請負契約あるいは準委任契約として締結されるのが通常です。仕事の完成（システム開発業務の完了）を目的とする場合には請負契約が締結されますが、事務の処理（要件定義，基本設計等エンジニアの専門知識の提供）を目的とする場合には準委任契約が締結されます。請負契約か準委任契約かというのは契約の名称や、条項などに「準委任契約とする」等と記載することによって一義的に決まるものではありません。契約の実質的内容で定まります。一括契約の場合は請負契約となりますが、多段階契約の場合、各工程毎の契約を請負にするのか準委任にするのかは、それぞれの契約の目的に照らし、どのような業務を遂行するのか（受注者が単独で行えるのか、発注者側の情報提供や協力を必要とするのか）、完成すべき業務や目的物が明確になっているか等を考慮して検討する必要があります。例えば、要件定義工程の場合、通常システムで実現すべき業務を分析し、必要となるシステムの機能，要件を明確にする業務が行われます。受注者（ベンダ）の専門的知識やノウハウを利用して、最終的な成果は要件定義書という文書の完成を目的として請負契約と考えられます。しかし要件定義は発注者（ユーザー）の業務やニーズを踏まえて進める必要があり、ユーザーからの積極的な情報提供や協力が必須となります。ユーザーからの情報提供を基にベンダの専門知識を利用して要件を取りまとめることを目的とした事務処理として準委任契約とも考えられます。

契約書に記載しておくべき内容

契約の構成を「一括契約」とするか各工程毎の「多段階契約」とするか、あるいは、請負契約となるか準委任契約となるか等あり、又、発注者側と受注者側ではポイントとなる条項が異なるかもしれませんが、おおよそ共通してポイントになるのは、

• ＜契約の目的と趣旨＞
• ＜仕様＞
• ＜対価＞
• ＜納期＞
• ＜不具合対応＞

が必須と考えられます。もう少し詳しくいうと、
＜契約の目的と趣旨＞は「契約内容に適合しているかどうか」等の解釈に影響します。又、個別の条文の解釈の判断材料ともなりますので、明確に規定しておくべきです。
＜仕様＞は委託する（されている）業務は何か、システムの完成形はどのようなものか、業務の終了を何をもって完了と確定するか、追加費用はどこから必要になるのか等を明確にしておくべきです。
＜対価＞はどの業務に対する報酬なのか、各工程毎（詳細設計，コーディング等）の金額か全体の金額なのか、その支払方法と支払時期（業務によってはレベニューシェア方式の場合もあります）
＜納期＞はどの業務を「いつまで」に完了する（させる）かを明確に
＜不具合対応＞は「いつまで」又は、「どこまで」無償対応か、費用が発生する場合はどうするかなどを明確にしておくべきです。

システム開発委託契約書の重要な条項例

契約書のタイトルは「システム開発契約書」や「開発委託契約書」，「ソフトウェア開発委託契約書」など色々なタイトルが考えられます。タイトルを読めば書いてある内容がイメージできますが、当事者の関係を規定したり、契約内容（請負か準委任）を決めるのはタイトルではなく書かれている内容です。

＜本契約の目的＞

契約の目的は「契約内容に適合しているかどうか」等の解釈に影響します。又、個別の条文の解釈の判断材料ともなりますので、明確に規定しておくべきです。
又、本契約を基本契約とし、個別業務ごとに別途個別契約を締結する場合は のように記載する場合もあります。

＜受託業務＞

受託業務の範囲，内容に関しては既存システムの有無，発注者の協力や役割分担等、色々決め方があります。役割分担，発注者との協働を別途条項を設けて明確にする方法もあります。
又、受託したどのような業務が契約の内容になっているか明確にしておく必要があります。

仕様の確定

受託業務の要件定義，基本設計の成果物としての要件定義書，基本設計書がシステム仕様書となる場合もありますが、別途システム仕様書を作成し、その仕様書を基に要件定義書，基本設計書を作成する場合もあります。いずれの場合も受託業務の内容，システム化の範囲，完成イメージその他の詳細事項を定めた仕様書を作成し、発注者，受注者双方確認のうえ内容を確定し作業に着手する必要があります。。
受注者がシステム仕様書を作成し、契約書に記載する場合 仕様の確定は、業務の完了，受託した業務の範囲，追加費用の発生等にかかわる内容です。どこまでが仕様の変更に該当するのか，仕様の変更が生じた場合は追加費用の発生の有無を含めてどうするのか等を明確に規定しておくべきです。

＜納期，対価＞

成果物の納入先，納入方法なども別途明記しておく必要があります。又、報酬の支払に関しては、発注者による成果物の確認，テスト（いわゆる検収作業）が必要ですが、検収の方法および何をもって完了とするかの基準が必要です。ここでは確定仕様書を前提とすることを明記しておく必要があります。

簡易な内容であれば、メール，電話のみで解決する場合もございます。まずは、ご相談，お問い合わせください。ご相談内容によって費用が発生する場合は、別途お見積りいたします。その場での判断・返答は必要ございません。十分ご検討の上、連絡ください。

その他、よく読まれている記事