ソフトウェア開発（システム開発）委託契約書とは
ソフトウェア開発委託契約書とは、ソフトウェア（システム）の開発を依頼するときに、委託者と受託者の間で締結する契約書です。
例えば、社内で利用する基盤システムの開発を依頼したり、顧客に販売するソフトウェアの開発を依頼したりする場合に利用されます。
ソフトウェア開発は、その内容から、大きく準委任型と請負契約型に分かれます。
準委任型とは、開発するという「作業」をメインに依頼するもので、請負契約型とは、「システム」を作り上げ、それを納品することをメインに依頼するものです。
開発するシステムの規模、期間などにより、性質が決まりますが、おおよそ下記のように段階ごとに分けて考えることができます。
ソフトウェア開発委託契約書は基本契約書と個別契約書の2種類
ソフトウェア開発委託契約書は、基本契約書と個別契約書に分けて締結する例が多くみられます。
基本契約書には、損害賠償、解除、代金の支払方法、裁判管轄などの取引の中で全体的に適用される事項や基本的事項を定めます。
個別契約書とは、開発の段階ごとや、開発の個別具体的な内容ごとに定める契約書です。例えば、開発段階ごとの委託内容や、委託料を記載します。
なお、この２つの契約書で異なる事情が書かれた場合の優先順位について、基本契約書で定めておくことが大切です。通常は個別契約を優先させることが多いですが、個別契約の本数が多く、管理が難しくなる場合は、基本契約の内容を優先させることもあります。
簡単な開発であれば、基本契約と個別契約で記載すべき内容を一つにした契約書を作成することもあります。
ソフトウェア開発委託契約書の作成で参考にできるモデル契約書
ソフトウェア開発委託契約書を作成する際に、参考になるのが、経済産業省やＩＰＡ（独立行政法人情報処理推進機構）が公表しているモデル契約書です。
多数の事例をもとに検討されているものですので大変よいひな型になっています。
しかし、実際に利用する際には、そのひな型をそのまま利用するのではなく、取引内容を反映したものに修正する必要があります。
経済産業省のモデル契約書
経済産業省が2007年に公表した「情報システム・モデル取引・契約書」は、社会インフラに情報システムが入り込み多大な影響を与えることから、モデル契約書が必要と考えて専門家チームの意見やパブリックコメントを集約して作成されたものです。
主に、これまで主流であるウォーターフォール型を基礎に作成されており、民間大手企業が委託者、情報サービス企業を受託者と想定して作成されています。
そのため、開発内容や規模によっては、このモデル契約書を参照しつつも、不要な条項は削除する、という修正が必要になる可能性もあります。
情報システム・モデル取引・契約書
https://www.meti.go.jp/policy/it_policy/keiyaku/model_keiyakusyo.pdf
独立行政法人情報処理推進機構のモデル契約書
ＩＰＡ（独立行政法人情報処理推進機構）も、独自にモデル契約書を公開しています。
ＩＰＡは、経済産業省の政策実施期間で、ＩＴや情報セキュリティについて社会事情の分析や企画立案をしている組織です。
ＩＰＡの契約書は、2000年の民法改正に対応して修正されていますし、経済産業省と同じくウォーターフォール型を念頭に置いた「情報システム・モデル取引・契約書」と、アジャイル型を念頭においた「情報システム・モデル取引・契約書（アジャイル開発版）」も公開しています。
アジャイル型開発を検討している場合は、こちらの契約書ひな型やその解説資料が参考になります。
情報システム・モデル取引・契約書
https://www.ipa.go.jp/digital/model/index.html
ソフトウェア開発委託契約書の主な条項
ソフトウェア開発委託契約を締結する際には最低限定めておくべき条項があります。
開発手法は、大きく分けてアジャイル型とウォーターフォール型に分かれています。
アジャイル型とは、新機能を短期間で継続的にリリースしていく手法であり、機能ごとに開発するので、前工程に戻ることも想定されています。
ウォーターフォール型とは、開発が「要件定義」「外部設計」「内部設計」「開発」「テスト」と作業工程ごとに分割されており、これを順に行っていく手法で、前工程に戻ることは想定されていません。
実際に契約書を作成する際には、まずどちらのタイプなのかを念頭において、具体的な開発内容及び作業に必要なことをしっかり記載していくことが大切です。
以下、各条項について解説していきます。
契約の目的
ソフトウェア開発委託契約に限らず、どの契約でも、契約の目的を定めることは重要です。
特に、ソフトウェア開発においては、ソフトウェアを、誰が最終ユーザーなのか、どのような目的で利用するシステムなのか、を記載しておくとよいでしょう。
この目的条項は、契約不適合責任や、債務不履行の際に、「本来の義務がなにか」を示す重要な要素として検討されます。
そのためにも、目的を明確に記載しておくことは大切なのです。
本契約は、甲が、甲社内で利用する営業推進顧客管理システムのコンピュータソフトウェアの開発に関する業務（以下「本件業務」という。）を乙に委託し、乙がこれを受託することに関する基本的な契約事項を定めることを目的とする
用語の定義
ソフトウェア開発委託契約書においては、専門的な用語を利用することが多いため、契約書内で利用する用語の定義を定める定義条項を規定します。
用語の解釈が当事者で違う、という場合には、業務を遂行する上でも不具合が生じ、最終的には紛争になる可能性があります。
定義条項は、用語の内容が正確かに加えて、その用語が契約書内で利用されている場合に、定義されている内容で意味が通じるのか、さらに定義変更が必要ではないのか、を念頭に置いて審査する必要があります。
本契約で用いる用語の定義は、次のとおりとする。
① 本件ソフトウェア
本契約及び個別契約に基づき開発されるソフトウェアであって、プログラム、コンテンツ、データベース類及び関連資料など個別契約において定めるもの
② 要件定義書
本件ソフトウェアの機能要件（甲の要求を満足するために、ソフトウェアが実現しなければならない機能に係る要件。システム機能及びデータにより定義される。）及び非機能要件（機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要件、技術要件、移行要件、運用要件及び付帯作業等から成り、それぞれに対する目標値及び具体的事項により定義される。）をとりまとめた文書
③ ・・・・
適用範囲
ウォーターフォール型のように、開発が各段階に分かれており、それぞれの段階ごとに個別契約を締結するような場合には、基本契約書に、基本契約書が適用される範囲を記載します。
また、開発段階ごとに、その内容が、請負契約的なのか、準委任契約的なのかによって、適用される条文を分けるという場合もあります。
そのときに、どの個別契約に、基本契約書のどの条項が適用されるかを記載します。
これは、そもそもの個別契約の中身や種類を知ったうえで、適切な内容になっているかを審査する必要があります。
アジャイル型の場合は、適用範囲を規定する必要がないことが多いです。
1．本件業務は、第〇条の要件定義作成支援業務、第〇条の外部設計書作成支援業務、第〇条のソフトウェア開発業務、第〇条のソフトウェア運用準備･移行支援業務から構成され、本件業務の個々の業務（以下｢個別業務｣という。）には本契約のほか、次条に基づき締結される当該個別業務に関する契約（以下「個別契約」という。）が適用される。
2．甲及び乙は、個別契約において本契約の一部の適用を排除し、又は本契約と異なる事項を定めることができる。この場合、個別契約の条項が本契約に優先するものとする。
個別契約
ソフトウェア開発委託契約書でも、ウォーターフォール型の開発方式の場合、開発段階ごとに個別契約を締結します。
この個別契約において、詳細かつ具体的な業務内容を定めます。
そのため、個別契約において定めるべき内容を、基本契約において定めます。
また、個別契約の成立方法と成立時期も定めるほうがよいでしょう。なぜなら、個別契約の成立自体が争われる場合もあるからです。
1．甲及び乙は、個別業務に着手する前に、提案依頼書、提案書及び見積書に基づいて、当該個別業務について以下の各号のうち必要となる取引条件を定め、個別契約を締結する。
①具体的作業内容（範囲、仕様等）
②作業期間又は納期
③甲乙の役割分担
④・・・
2．個別契約は、甲乙間で個別契約に署名捺印した場合又は甲が乙に対し発注書を交付し、乙が発注請書を提出した場合に成立するものとする。
委託料と支払い方法
委託料について定める条項も必要です。
ウォーターフォール型の契約の場合、各段階において委託料が発生するのと、計算方法が異なる場合もあるため、委託料の詳細は個別契約で定めると記載する例が多いです。
そのほか、委託料の条項で、実費についても定める例があります。
どのような実費について、どちらが負担するのかを、あらかじめ明確にしておきます。
なお、下請法に該当する場合には、業務完了や納品から60日以内に支払う必要がありますので、注意してください。
1．甲は乙に対し、本件業務の対価として、各個別契約で定めた委託料を当該個別契約で定めた方法で支払う。
2．本件業務の遂行に際して必要な実費については、個別契約でその負担について定める場合は個別契約で定めた内容に従う。個別契約で定めがない場合は、甲乙間で別途合意した場合を除き、乙の負担とする。
作業期間または納期
ソフトウェア開発契約においては、作業期間や納期を定めることは必須です。
ウォーターフォール型の契約の場合には、開発段階ごとに、個別契約で定めることが多いといえます。
アジャイル型開発の場合でも、内容が準委任契約であれば作業期間を、請負契約であれば納期を定めます。
なお、予定どおりに開発が進まない場合に備えて、再協議できる条項を設ける例もあります。
各個別契約の業務期間又は納期は、当該個別業務にかかる個別契約において定める。
再委託
ソフトウェア開発において、受託者が、さらにその業務の全部や一部を、再委託することはよくある例です。
一方、委託者からすると、知らないうちに再委託されてしまうと、その品質や内容に不安が生じることは否定できません。
そこで、再委託を可能とするのか、可能とした場合に、事前に再委託先を知らせるようにするのか等を定めておく必要があります。
多い例としては、再委託は原則禁止として、事前の書面の許諾がある場合のみ再委託可能とする例ですが、受託者の裁量によって再委託先を選択できる、とする例もあります。
いずれにしても、再委託先の責任については、受託者が負います。
1．乙は、事前に書面による甲の承諾を得た場合に、各個別業務の全部又は一部を第三者に再委託することができる。
2．乙は、前項の規定により再委託した場合、再委託先の行為及び結果について、責任を負うものとする。
システムの仕様と変更
ウォーターフォール型の契約の場合は、上流の要件定義の段階で、システムの仕様についても決定しますので、途中から変更するということはあまり想定されていません。
一方、アジャイル型の契約の場合には、後戻りも想定して、ある程度幅をもった開発をする場合が多いので、仕様を途中で変更する場合もあります。
このとき、システム変更を、どのような手順で行い、変更後の内容を決定するか、という条項をおくことが大切です。
1．甲と乙は、本契約又は別途作成した仕様書に記載された内容について変更の必要が生じた場合には、その変更の具体的内容及び理由を示した書面を相手方に交付して、変更の協議（以下「変更協議」という。）の開催を要請することができる。
2．甲と乙は、相手方より前項の要請があったときは、速やかに協議に応じなければならない。
3．変更協議の結果、本契約の内容を変更することが合意された場合には、変更内容が記載された変更合意書を作成し、甲乙双方が当該合意書に記名押印する。
ソフトウェアの検収
ソフトウェア開発委託契約の目的たるソフトウェアやシステムが完成した場合、受託者は制作したソフトウェアを納品し、委託者はそのソフトウェアが契約書どおりのものか確認します。
この確認を検収といいます。
検収条項には、検収方法、検収期間、検収が不合格だった場合の修正内容等を記載します。
特に、ソフトウェアやシステムの場合には、検査の方法や合格の基準を定めておくことが重要で、定めた内容については仕様書にして双方とも認識できるようにしておくことも大切です。
1．乙は、本件ソフトウェアを受領後、納入を受けた日から14営業日以内に、本契約及び別途定める仕様書に合致するか否かを検査しなければならない。
2．甲は、本件ソフトウェアが前項の検査に適合する場合、検査合格書に記名押印の上、乙に交付するものとする。また、甲は、本件ソフトウェアが前項の検査に合格しない場合、乙に対し不合格となった具体的な理由を明示した書面を速やかに交付し、修正又は追完を求める。乙は、甲乙間で協議の上定めた期限内に無償で修正して甲に納入する。この場合の検査は前項の規定による。
3．検査合格をもって、本件ソフトウェアの検収完了とする。
契約不適合責任
契約不適合責任とは、完成した成果物が、契約の内容や目的に沿わない場合（契約不適合の場合）に、受託者が責任を負うものです。
民法に契約不適合責任の条文がありますが、民法上は、発覚してから１年以内に委託者が通知すればよいとなっているため、相当長期にわたって責任が生じる可能性があります。
そのため、受託者としては、その期間を短くしたり、検収完了日を起算点としたりと変更したほうがいいでしょう。
一方、委託者としては、民法上はまずは補修や追完を請求することになりますが、補修や追完を請求せずとも、代金の減額ができるような条項にする方法も考えられます。
ソフトウェア開発委託契約において、最も双方で修正要望が出る条項の一つ、といっても過言ではありません。
1．前条の検収完了後、成果物について本契約又は仕様書との不一致（バグも含む。以下本条において「契約不適合」という。）が発見された場合、甲は乙に対して当該契約不適合の補修又は追完を請求することができ、乙は補修又は追完するものとする。但し、乙がかかる責任を負うのは、前条の検収完了後６ヶ月以内に甲から書面により通知された場合に限るものとする。
2．前項にかかわらず、契約不適合が軽微であって、甲の業務に実質的な影響を及ぼすものではなく、かつ成果物の補修又は追完に過分の費用を要する場合には、乙は前項所定の責任を負わないものとする。
3．第1項の規定は、契約不適合が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。
知的財産権の帰属・侵害の責任
開発したソフトウェアやシステムに関する特許権や著作権を、甲乙どちらが有するのかを決定します。
委託者が不特定多数に販売することを想定しているようなソフトウェアの開発であれば、特許権や著作権は委託者に帰属しておいたほうがいいでしょう。
一方、受託者が有する特許権や著作権を主に利用して開発したような場合には、受託者としては、使用権は認めるけれども、権利の譲渡まではしたくない、という場合もあります。
また、開発したソフトウェアやシステムが、第三者の知的財産権を侵害していた場合の責任についても規定します。
このとき、受託者に対して、開発したソフトウェアやシステムが、第三者の知的財産権を侵害していないことを表明保証させる例もあります。
1．本件業務遂行の過程で新たに生じた発明その他の知的財産又はノウハウ等（以下、あわせて「発明等」という。）に係る特許権その他の知的財産権（特許その他の知的財産権を受ける権利を含む。但し、著作権は除く。）、ノウハウ等に関する権利（以下、特許権その他の知的財産権、ノウハウ等に関する権利を総称して「特許権等」という。）は、当該発明等を行った者が属する当事者に帰属する。
2．本件業務遂行の過程で乙が新たに作成した著作物に関する著作権（著作権法第27条及び第28条の権利を含む。以下同じ。）は、甲に帰属する。乙から甲への著作権移転の対価は、委託料に含まれるものとする。
3．乙は、本件成果物が、第三者の知的財産等を侵害しないことを表明保証する。
4．甲が成果物に関し第三者から著作権又は特許権等の侵害の申立を受けたときは、速やかに乙にその事実及び内容を通知する。
5．乙は、前項の申立がなされた場合、乙が責任と費用をもって、当該紛争を処理するものとする。
業務の終了確認
準委任契約型の開発契約や、ウォーターフォール型の契約における準委任型の個別契約の場合、納品する物がないため、業務が適切に行われたかを確認する方法を定める必要があります。
多くの場合は、受託者が業務終了の報告書を提出し、委託者がそれを確認する、という方法になります。
1．乙は、本件業務の終了後10営業日以内に、業務終了報告書を作成し、甲に提出する。
2．甲は、前項の業務終了報告書を受領してから10営業日以内に、当該業務終了報告書を点検し、その内容に疑義がない場合、業務終了確認書に記名押印の上、乙に交付する。当該書類が交付された時点で、本件業務の終了を確認するものとする。
3．前項記載の期間に甲から異議がない場合には、前項記載の期間の満了をもって、業務の終了を確認したものとみなす。
法務をシームレスに支援する次世代リーガルテック「LegalOn Cloud」
「LegalOn Cloud」は、法務業務をシームレスに支援する次世代リーガルテックです。契約審査から締結後の契約管理、法務相談案件の管理、法令リサーチ、法改正対応まで、あらゆる法務業務を最先端のAIを搭載したLegalOn Cloudがカバーします。日々の業務の中で生まれる自社の法務ナレッジ。LegalOn Cloudなら自然に集約、AIが自動で整理し適切なタイミングでレコメンド。ナレッジマネジメントの未来の形を実現します。
【新任～若手法務の方へ】
そもそも契約とは何か、なぜ契約書を作成するのか、正しく答えられますか？
以下の無料資料をダウンロードして、契約の基本を網羅的に理解しましょう。
<この記事を書いた人>
Nobisiro編集部
AI法務プラットフォーム「LegalOn Cloud」を提供するLegalOn Technologiesが運営する、法務の可能性を広げるメディア「Nobisiro」編集部。の法務担当者の日々の業務に役立つ情報を発信しています。
