システム開発契約書の解説・チェック事項

システム開発契約においてよく見かける条項を参照しながら、契約書の作成及びチェックに際して注意すべきポイントを以下解説します。
なお、本記事では、主として、IT企業＝システム開発受託者側の観点からとなります。
（※以下では、甲＝ユーザ・委託者側、乙＝ベンダ・受託者側とします）

1 システム開発契約に関する条項

システム開発契約に関する条項

契約の目的

第１条（契約の目的）
１　甲は、本契約の定めるところにより、甲の××（以下「本件システム」という）の開発に関する以下の業務を乙に委託し、乙はこれを受託する。
①企画支援業務
②基本設計業務
③プログラム作成業務
④移行・運用準備支援業務
２　乙は甲に対し、本件システムに関する保守管理業務を別途定める契約に基づき行うものとする。

システム開発契約において一番重要となる条項は、何をどこまで制作するのかできる限り具体的に明確化することです。
ここではサンプルである関係上、抽象的にしか記述していませんが、例えば「企画支援業務」といっても、現在稼働しているシステムを一から作り直すのか、現在稼働しているシステムに新たな機能を実装するだけなのか、実装するのであれば他のシステムとの連携や整合性はどうするのか等、内容は多岐にわたります。
執筆者個人の経験からすれば、システム開発のトラブルは、ユーザ（委託者）とベンダ（受託者）の認識の齟齬、すなわち「どの範囲まで業務を行うのか」の相違に由来することが一番多いように思いますので、この部分は十二分に意識して欲しい内容となります。

ところで、契約締結段階では細部について十分に協議ができておらず、開発作業を進めながら随時確認し完成を目指すケースもよくある話です。しかし、例えば、この確認時のユーザ（委託者）の要望が注文変更と判断せざるを得ず、システム完成後にベンダ（受託者）が追加報酬の請求を行ったところ、ユーザ（委託者）が追加報酬の支払いを拒否するといったトラブルが生じがちです。

この点、事前に仕様書等が作成されているのであれば、「なお、当該業務の詳細は別紙仕様書の通りとする。」と一文追加し、業務範囲の明確化・特定化を図ることが考えられます。また、システム内容の詳細を定めた文書等が無い場合であっても、企画書や提案書等の最低限の共通認識を確認しうる資料があるはずなので、「なお、当該業務は企画書（提案書）を前提に行われるものとし、詳細については別途協議の上定める。」と定め、業務範囲の明確化・特定化を少しでも図るよう努めるべきです。
このような対策を講じれば、注文変更と言えるのか（追加報酬が発生するのか）判断しやすくなります。

成果物の納入

第２条（成果物の納入）
乙は、甲乙合意の上定めた期限までに、乙が本契約に基づいて作成したもの（以下「成果物」という）を甲の指示する方法により納入する。但し、甲により本件業務内容が変更された場合、又は天災地変その他不可抗力によって乙の業務遂行に支障が生じた場合には、乙は、甲に対し、納期の延長を求めることができる。

ベンダ（受託者）とすれば、納入期限を明らかにしておくことはもちろん重要です。
しかしもっと大事なことは、様々な事情（ユーザ（委託者）からの追加注文や工程上発見された新たな課題解決のために余計な時間を費やした等）により、成果物の納入が期限までに間に合わない状態となった場合に備えて、納入期限の延期手続きが認められる場合を明示しておくという点です。
これは、後々トラブルとなった場合、必ずと言っていいほど、ユーザ（委託者）は「納期に間に合わなかった」という主張を行ってくるからです。
なお、当然のことながら、ベンダ（受託者）の見込み違いで納入期限に間に合わなかったのであれば、ユーザ（委託者）からの納期遅延の主張を甘受するべきです。

また、成果物の納入方法についても、できる限り具体的に記載するべきです。
一般的には、ユーザ（委託者）が指定するサーバ内に格納する形で納入することが多いと思われますが、上記条項では「甲の指示する方法」となっていることから、もしかしたら記録媒体に保存して納入ということも有り得るかもしれません。この場合、ソースコード等を事実上引渡すことになりますので、ベンダ（受託者）はそれでよいのか考えておく必要があります。

再委託

第３条（再委託）
乙は、必要に応じて、各個別業務の全部又は一部を乙の責任において第三者に再委託することができる。但し、当該委託先に対し、第８条に定める乙の秘密保持義務と同等の義務を負わせるものとする。

中小のベンダ（受託者）の場合、協力会社やフリーランス等の個人のSEに一部の業務を委託してシステム開発に従事する場合があります。
したがって、上記条項例のようにベンダ（受託者）の裁量で再委託できることが望ましいのですが、一方で、ユーザ（委託者）としては、責任の所在が不明確になることや情報漏えいのリスクなどを懸念して、再委託はできる限り事前承諾の形式にしようとします。
バランス論としては、契約締結段階で、あらかじめ第三者に再委託（下請）させることが予定されている場合、その点を事前にユーザ（委託者）に告知し、例えば「但し、甲は、乙が××に対して本件業務の一部を再委託することにつき、予め承諾する。」という条項を入れておくことで対処することが考えられます。

委託料、委託料の変更

第４条（委託料）
甲の乙に支払うべき本件業務の対価は、総額金××円とし、甲は、これを以下の通り乙に支払う。
①一時金として、金×円を本契約成立時に支払う。
②それ以降は、以下の通り順次支払う。
・×年×月×日限り、金×円
・×年×月×日限り、金×円
・成果物の引渡しと引き換えに、残額金×円

第５条（委託料の変更）
乙は以下に定める場合、甲に対し、委託料の変更を求めることができる。
①甲がシステムの仕様を変更した場合
②甲がシステムの納期を変更した場合
③甲の提供した情報、資料に含まれた問題に起因して、乙の開発費用が増大した場合

委託料の支払い方法は、ユーザ（委託者）とベンダ（受託者）の力関係が影響するため、様々なパターンがあるかと思います。

ところで、ベンダ（受託者）としては、システム開発は途中で頓挫することが多い…という経験をされているのではないでしょうか。そして、この頓挫した場合にユーザ（委託者）より委託料の支払いを渋られたという経験をされているのではないでしょうか。
このような問題を解決するためには、例えば、経済産業省が公表しているモデル契約例（いわゆる多段階方式）を参照しつつ、それぞれの工程ごと（企画、要件定義、外部設計、内部設計等）に委託料を支払ってもらうというのが一つの解決方法となります。

なお、2020年4月より施行された改正民法において出来高払いの請求が認められたことから、システム開発契約が請負契約に該当する場合、民法第634条に基づき報酬請求できるのでは、と考えるベンダ（受託者）もいるかもしれません。
ただ、これは間違いです。
民法第634条は作業割合に応じた報酬を支払うよう定めてはおらず、①可分であり、②その部分の給付によりユーザ（委託者）が利益を受けたことを条件に報酬支払い義務を定めているにすぎません。システム開発の場合、未完成物が可分といえるのか、仮に可分であるとしてもその部分の給付によりユーザ（委託者）が利益を受けるのか、かなり微妙な問題となり得ます。
したがって、ベンダ（受託者）は、中途解約となっても民法第634条により救済可能と安易に考えるべきではありません。交渉可能であれば、中途解約時における清算方法についても、契約書に明記したいところです。

資料等の提供、管理、返還

第６条（資料等の提供、管理、返還）
１　甲は乙に対し、本件業務に必要な資料等の開示、貸与等の提供を無償で行う。
２　乙は、甲から提供された資料等を善良なる管理者としての注意義務をもって管理、保管し、かつ本件業務以外の用途に使用してはならない。
３　乙は、本件業務が終了した後、速やかに甲に対し返還する。

この条項は、どちらかというと情報流出や漏えいを防止したいユーザ（委託者）が要求する条項となります。
ベンダ（受託者）としても、ユーザ（委託者）より開示された情報を濫りに開示することは当然慎むべきですので、この程度の条項であれば受け入れた方が無難です。
なお、ベンダ（受託者）でチェックする内容としては、貸与された資料等について賃料等が発生するのか、貸与された資料等について保管場所など管理方法に制限が付されているのか（例えば個別独立のセキュリティールームを設けることが要求されていないか等）、返却の時期はいつなのか、といった内容となります。

連絡協議会

第７条（連絡協議会）
甲及び乙は、本件業務が終了するまでの間、その進捗状況の報告、問題点の協議・解決、その他本件業務が円滑に遂行できるよう必要な事項を協議するため、別途定める方法により連絡協議会を開催することとする。

よく見かける条項なのですが、ユーザ（委託者）もベンダ（受託者）も大手である場合を除き、実際には連絡協議会をきちんと開催して進めていくのは、むしろ稀ではないかというのが執筆者個人の印象です。
また、システム開発契約の法的性質を委任契約と考えれば進捗状況については報告義務を負いますし（民法第645条参照）、請負契約と考えても、システム開発はその性質上、両者の協力なくして開発を進めることは不可能です。
したがって、連絡協議会という会議を設けるか否かはともかく、ベンダ（受託者）としては、業務遂行に際してベンダ（受託者）が要請した場合、ユーザ（委託者）も情報開示を行う等の協力を行う義務があることを明記することが望ましいかもしれません。

知的財産権の取扱い、著作権の帰属、成果物の所有権

第８条（知的財産権の取扱い）
１　本件業務遂行の過程で生じた発明その他の知的財産権及びノウハウ等（以下「発明等」という）が甲又は乙のいずれか一方のみによって作出された場合、当該発明等に関する特許権その他の知的財産権及びノウハウ等に関する権利（以下「特許権等」という）は、当該作出を行った者が属する当事者に帰属する。
２　乙が従前から有していた特許権等を本件システムに利用した場合又は前項により乙に帰属する特許権等が本件システムに利用された場合、甲は、本契約に基づき本件システムを自己利用するために必要な範囲で、当該特許権等を実施又は利用することができる。
３　本件業務の過程で生じた発明等が甲及び乙の共同で行われた場合、当該発明等についての特許権等は甲乙の共有（持分均等）とする。この場合、甲及び乙は、それぞれに属する当該作出等を行った者との間で特許権等の承継その他必要な措置を講ずるものとする。
４　甲及び乙は、前項の共同発明等にかかる特許権等について、それぞれ相手方の同意等を要することなく、これを自ら実施又は利用することができる。但し、これを第三者に実施又は利用を許諾する場合、持分を譲渡する場合及び質権の目的とする場合は、相手方と事前に協議した上で、実施又は利用の許諾条件、譲渡条件等を決定するものとする。
５　本条の定めにかかわらず、成果物に関する著作権については、第９条によって定めるものとする。

第９条（著作権の帰属）
成果物のうち、プログラムの著作権について、当該プログラムに結合され又は組み込まれたもので乙が従前から有していたプログラム（コンテンツ及びデータベースを含む。以下同じ）の著作権及び乙が本件業務において新たに作成したプログラムの著作権は、乙に留保されるものとする。但し、甲は、納入された当該プログラムの著作物の複製物を、自己使用の範囲において自由に使用し、また著作権法の規定に基づき複製、翻案することができるものとする。

第１０条（成果物の所有権）
乙が、甲に納入した成果物の所有権は、第４条に基づき、甲より乙へ委託料が完済されたときに乙から甲に移転する。

いわゆる権利帰属に関する条項です。
最初に注意喚起しておきますが、報酬を支払ったから知的財産権が当然に譲渡されるという関係には立ちません。この点は、ベンダ（受託者）はしっかり押さえておく必要があります。
さて、システム開発契約の場合、権利の性質を検討することなく、大ざっぱにユーザ（委託者）に帰属させるという形式にすることも多いようです。しかしベンダ（受託者）として厳密に検討した場合、他の案件で技術ノウハウやプログラムを転用できない可能性が生じるため、全てをユーザ（委託者）に帰属させるというのは得策ではないと思われます。
ここでは、著作権、著作権を除く知的財産権、所有権の３つに分けて、その帰属とライセンス（使用許諾）の問題を定めてみました。ただ、権利帰属の問題も、両当事者間の力関係によって決まることが多いことから、権利をすべてベンダ（受託者）に留保しなければならないと絶対視する必要はないかと思います。
特に、著作権についてどうしてもユーザ（委託者）に帰属せざるを得ないこともありますので、例えば、上記9条を修正し、契約前に保有していた著作権はベンダ（受託者）に引き続き帰属する、本件業務遂行によって新たに発生した著作権はユーザ（委託者）に帰属すると分けた上で、必要な範囲でユーザ（委託者）よりライセンスを受けることを明記するのも一案です。

ちなみに、執筆者が感じる近時の交渉スタンスは、権利がどちらに帰属するのかを重視するのではなく、相手に権利が帰属する場合、どのようなライセンスを勝ち取るかに主眼が置かれているように思われます。

検品

第１１条（検品）
１　甲は、乙より成果物の納入がなされた日から×日以内に、成果物の検査を行い、その検査結果について乙に通知するものとする。
２　前項の期間内に甲より乙に通知がなされなかった場合には、当該成果物は検査に合格したものとみなす。

これもよく見かける条項ですが、ベンダ（受託者）として注意するべき視点は、2項のような「みなし合格」の条項が入っているか否かです。
この条項がないことには、検査期間は経過したものの、いつまでたっても合否の連絡がないために報酬を支払ってもらえない、あるいは完成していないことを理由とした修正に応じなければならないということにもなりかねません。

なお、ときどき第1項にある成果物の検査方法につき、「甲の定める検査方法」と定めている場合があります。ベンダ（受託者）にとって納得のできない検査基準による不合格とされるリスクを回避するためにも、検査方法や基準については事前に確認し、当事者双方で認識を共有することが必要です。

成果物についての保証

第１２条（成果物についての保証）
１　乙は甲に対し、甲が指定する仕様書通りの成果物が開発されていることを保証する。
２　前項の保証期間は納入日から３ヶ月とし、同期間内に前項の保証事項に反することが原因で成果物に不具合が生じた場合には、乙は、自らの費用と責任において改修作業を行うものとする。
３　成果物が第三者の特許権等又は著作権を侵害して、当該第三者より成果物の使用を差し止められた場合又は損害賠償を求められた場合、乙は、第４条に定める委託料総額を限度として、甲に生じた損害を賠償するものとする。

ベンダ（受託者）からすれば、あまり大きな保証をしたくないというのが本音かと思います。しかし、ユーザ（委託者）からすれば、プロに委託して報酬も支払っている以上、成果物に対する一定の保証を行ってもらいたいと考えるのは当然のことであり、この問題を避けて通るわけにはいかないと考えるべきです。
むしろ、ベンダ（受託者）としては、上記第3項で記載したような、保証することを前提にしつつ、万一の場合の損害賠償リスクをどこまで軽減できるのかに注力を払うべきです。

ところで、上記第2項に定める責任ですが、2020年4月1日施行の改正民法による重大な変更が行われています。
すなわち、改正前民法では瑕疵担保責任と呼ばれていたのですが、改正民法では、契約不適合責任と改められると共に、「注文者がその不適合を知った時から1年以内にその旨を通知」すれば責任追及可能と大幅にユーザ（委託者）有利に改正されています（民法第637条）。本件の場合、責任を負担する期間について制限が定められていますが、契約不適合責任について特に定めなかった場合、又は定めたとしても改正民法通りの言い回しにした場合、事実上半永久的にベンダ（受託者）は責任を負担することになりかねません。
もし契約不適合責任の範囲及び期間について交渉が難航する場合、第1条第2項に定める保守管理の対応範囲として、契約不適合責任の趣旨を盛り込むといった対策も検討したいところです。

＜2023年1月執筆＞
※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。