本記事のサマリー動画

こちらの動画で、受託者側（ベンダ側）に立ってシステム開発契約書を審査する場合に、GVA assist を使うと生産性と品質がどのように向上するかをご覧いただけます。

システム開発契約の特徴

システム開発契約は、顧客（ユーザー）が、システム開発会社（ベンダー）に対して、ユーザーの業務上の課題を解決するシステムの構築等を委託し、その対価として金銭を支払う契約であり、民法上の請負契約又は準委任契約の一種と言えます。

システム開発においては、冒頭に述べたような「顧客の業務上の課題」を明確に定義することが難しく、また同課題を解決するシステム自体も、建築物や製造物における設計図面のように要件・仕様を定義する方法が確立されていないため、要件定義・設計・開発・納入・検収・運用の各段階で契約当事者間の認識の齟齬に基づく争いが生じやすい、と言われています。

本記事では、納入物のあるシステム開発契約において、特に争点になりやすい条項と、代表的な争点の内容について、ベンダーの視点からどうチェック・修正するのかを解説した上で、実際に弊社のAI契約書レビュー支援クラウド GVA assist を使ったレビュープロセスを動画にてご紹介します。

検収条項

検収とは、一般には、納入物が、契約当事者間で合意した要件・仕様を満たすかを、契約当事者の一方（又は契約当事者の一方から委託を受けた第三者）が検査した上で、委託者が合格した当該成果物を受け入れることをいいます。

検査の結果が不合格であれば、ユーザーはベンダーに対し、検収条項にのっとった再履行の要請や、契約不適合責任の追及をすることになります。

一方で、検査が合格して検収完了となった場合、検収完了の時点は、成果物に関する知的財産権の移転時や、委託の対価の支払いの基準となることも多いです。そのため、同条の重要度は高く、争点になりやすい条項と言えます。

検査不合格の場合のユーザーによる理由の通知義務

検査の結果、納入物が当事者間で合意した仕様と一致しない場合、すなわち不合格となった場合は、「引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないもの（民法第562条第1項）」といえるので、ユーザーはベンダーに対し、「目的物の修補、代替物の引渡し又は不足分の引渡し」を内容とする追完請求権（民法第562条第1項）の行使が可能となります。（もちろん、契約において別途定めがあれば、当該規程に基づく請求を行うことになります）

しかし、ベンダーにしてみれば、「目的物の修補」を行うためには、どのような仕様の不一致があったかを具体的に知る必要があります。

したがって、ベンダーとしては、検査不合格の通知は、単に不合格との結果だけでなく、不合格の具体的理由の記載を要する（具体的理由の記載のない通知は、検査不合格通知として認めない）ことを定める必要があります。

検収完了のみなし条項

ベンダーがユーザーに納入物を納入しても、ユーザーの事情で検査が完了しない、あるいは具体的理由の記載のない不合格通知しか来ない、という事態も生じ得ます。

このような場合、ベンダーは納入したにもかかわらず、納入物の修補等の要否又は修補の必要な点がわからない、という非常に不安定な立場に立たされることになります。上述したように、実務上では検収完了時を基準として、委託の対価の支払いを定めることが多くあるため、資金の回収の点でも問題となります。

したがって、ベンダーとしては、あらかじめユーザー・ベンダー間で検査期間を定め、当該検査期間の経過をもって納入物の検査の合格、あるいは検収完了とみなす規定を入れる必要があります。

契約不適合責任条項

システム開発契約における契約不適合責任とは、ベンダーがユーザーに納入したシステムが「契約の内容に適合しない（民法562条第1項）」、すなわち合意した仕様などの契約内容と一致しないときにベンダーがユーザーに対して負う債務不履行責任のことをいいます。

このような場合、ユーザーはベンダーに対し、民法上の各要件（あるいは当事者間の契約上の条件）を満たせば追完請求権（民法第562条第1項）、代金減額請求権（民法第563条）、損害賠償請求権（民法第564条、民法第415条）、解除権（民法第564条、民法第541条又は第542条）を行使できることになります。

契約不適合の内容（軽微なバグ（不具合）の排除）

冒頭で述べたようにシステムの要件・仕様を定義する方法は確立されているとは言えないため、何が「契約の内容に適合しない」といえるのかを明確にすることは困難です。

ユーザーは、システムに対する要求の全てを漏れなく仕様書に記載することは困難であることから、契約不適合の内容として「通常期待される品質・性能を欠くこと、バグその他の不具合」といった広汎さを含む定義を用いる動機があります。

一方で、ベンダーとしては、当事者間で合意のない事項への対応を一方的に負担することを回避するために仕様を定めていると言えます。また、ユーザーのシステム開発目的達成に関係しない軽微なものであれば、必ずしも修補の必要性は高くありません。

そこで、ベンダーとしては、契約不適合の内容として「仕様との不一致に限る」「軽微な不具合は含まない」などの文言を用いることが考えられます。

ユーザー（委託者）による解除の制限

民法上、契約の解除は「契約及び取引上の社会通念に照らして軽微であるとき（民法541条ただし書）」はできないとされ、無催告解除も「契約をした目的を達することができない（民法542条第1項第3号）」などの厳格な要件を必要とします。

しかし、これらは任意規定であり、契約での修正が可能となっています。そのため、ユーザーとしては契約不適合に基づく契約解除の要件を緩めることが考えられます。

一方で、ベンダーとしては、開発工数の負担は、投下資本に類するものであるところ、軽微な契約不適合を理由に契約解除されることはリスクが大きいといえます。

したがって、ベンダーとしては、契約不適合責任に基づくユーザーによる解除権の行使は、民法の原則に近い制限を加える必要があります。

納入物（成果物）にかかる権利（著作権）の帰属の条項

システム開発契約における知的財産権関連の争点は大きく分けて3つあります。
①納入物にかかる著作権の帰属
②開発業務遂行の過程で生じた知的財産権の帰属
③納入物が第三者の権利を侵害していた場合の対応

本記事では、①納入物にかかる著作権の帰属について解説いたします。

まず、前提として、システム開発の結果作成されたプログラム等には著作権が生じ得ます（著作権法第２条第１項第10の2号、第10条第1項第9号）。

システム開発を委託し、対価を支払うユーザーとしては、納入物にかかる著作権について、全て自分たちユーザーに帰属させること、ベンダー及び納入物を開発した再委託者等が、ユーザーに対して納入物にかかる著作者人格権を行使しないこと、を要求すると考えられます。システムの利用のみならず、拡張・メンテナンスも考慮すれば、ユーザーとしては万全の権利を要求する動機があるためです。

一方で、ベンダーとしては、開発時に自社内で用意した汎用的なプログラムに、ユーザーごとの要求に合わせて作成したプログラムを組み合わせてシステムを開発することが多く、加えて第三者の提供するプログラムやサービスを組み合わせる場合があります。

自社内で用意した汎用的なプログラムの権利をユーザーに譲渡してしまうと、ベンダーとしては今後の開発に生じ得ます。さらに、第三者の提供するプログラムについては、そもそも譲渡する権利を有していません。

したがって、ベンダーとしては、ユーザーのシステム開発の前から権利を有していた自社製の汎用的なプログラムや、第三者の提供するプログラムの権利については、譲渡を留保する条項を入れることが必要となります。

【動画】GVA assistを使ったシステム開発契約書の審査

ここでは、ベンダーの法務部がユーザーから渡されたシステム開発契約書の、検収条項と納入物（成果物）にかかる権利の帰属の条項をチェックする際にGVA assistを使うことで、どのように生産性と品質が向上するか、実際の動画をご案内いたします。

おわりに

いかがでしたでしょうか？

GVA assistはベンダー基準ではなく「自社の契約書審査基準」をセットして、リスク検知～修正例の作成支援まで、その時に必要なナレッジを審査実務で活用できる契約書レビュー支援サービスです。きっと貴社の契約書レビュー業務の生産性と品質アップに貢献します。

よろしければGVA assistの無料デモ（オンライン）にご参加くださいませ。

執筆者：荻野　啓（GVA TECH株式会社／第二東京弁護士会所属弁護士）