| 【目 次】 Q1：本契約で対象とするソフトウェア開発委託 Q2：契約名称・前文 Q3：目的及び個別契約 （以上第34回） Q4：定 義 Q5：仕様確定支援業務（準委任業務）の個別契約例 Q6：仕様確定支援業務の実施 Q7：仕様確定支援業務に係る業務終了報告書の提出・確認 Q8：仕様確定支援業務に係る委託料及び費用負担 Q9：仕様の確定 （以上第35回） Q10：開発請負業務（請負業務）の個別契約例 Q11：開発請負業務の実施 Q12：本件ソフトウェアその他納入物の納入・検収 Q13：開発請負業務に係る委託料及び費用負担 Q14：契約不適合責任 Q15：仕様の変更 （以上今回第36回） Q16：再委託 Q17：業務責任者及び業務従事者 Q18：協 議 Q19：納入物等の所有権及び危険負担 Q20：納入物等の特許権等 Q21：納入物等の著作権 Q22：知的財産権の侵害に対する責任 Q23：個人情報の取扱い Q24：秘密保持並びに資料等の利用目的及び返還 Q25：解除及び期限の利益喪失 Q26：反社会的勢力の排除 Q27：損害賠償 Q28：その他一般条項 Q29：契約書末尾 |
Q10：開発請負業務（請負業務）の個別契約例
A10：本契約（1条）では、開発請負業務について、本契約に基づき個別契約を締結することになっていますが、以下にその個別契約の規定例を示します。なお、以下、契約規定例中に、強調又は解説の便宜上、下線を引いている箇所があります。|
○○○システムソフトウェア開発委託基本契約書に基づく ソフトウェア開発請負業務に関する個別契約書
○○○○（以下「甲」という）及び○○○○（以下「乙」という）は、甲乙間で○○年○○月○○日付け締結した「○○○システムソフトウェア開発委託基本契約書」（以下「基本契約」という）に基づき、甲から乙への本件ソフトウェアの開発請負業務（以下「本件業務」という）の委託に関する個別契約（以下「本個別契約」という）を次の通り締結する。なお、本個別契約で用いる用語の意味は基本契約と同じとする。 1. 本件ソフトウェアの仕様：[名称・日付・番号・バージョン等により具体的に特定すること、又は「添付の通り」と記載し仕様書そのものを本個別契約に添付してもよい]
2. 本件業務において、乙が開発し甲に納入すべき本件ソフトウェア（コンピュータプログラム）、及びこれに関連するドキュメント、データベースその他のもの（「納入物」）の明細： （例） (1) 本件ソフトウェアのオブジェクトコード及びソースコード：各CD-ROM 2部 (2) 外部設計書：印刷部数１部及びCD-ROM 1部 (3) システム運用マニュアル：印刷部数１部及びCD-ROM 1部 (4) ユーザ利用マニュアル：印刷部数１部及びCD-ROM 1部 (5) ...... 3. 本件ソフトウェアその他納入物の納入場所(又はダウンロード、送信、クラウド上に構築された本件ソフトウェアへのアクセス情報提供等による納入方法)及び納入期限： （例1）「乙は、上記納入物全てを、甲の○○○○事業所に○○年○○月○○日までに納入する。」 （例2）「乙は、上記納入物全ての電子データを甲がWebサイト上からダウンロードするために必要な情報を、○○年○○月○○日までに甲に提供するものとし、当該情報の提供により納入物の納入が完了したものとする。」
4. 本件業務に関し、甲が行うべき情報・資料・機器・場所等の提供、本件業務の進捗状況・内容等に関する確認及び乙との協議、その他甲が実施又は協力すべき事項 （例） (1) （例）（要件定義書レベルのもののみを仕様とした場合）甲は、乙が仕様に基づき作成する本件ソフトウェアの画面、帳票等のユーザインターフェースについて、乙から求められた場合、甲の意向・評価を速やかに乙に提供するものとする。 (2) （例）甲は、本件ソフトウェアを構成する一部として組み入れられる予定の○○○○ソフトウェア（又はクラウドサービス）を利用する権利を甲の費用負担で取得し乙に対し本件業務遂行実施期間中無償で利用させるものとする。 (3) （例）甲は、乙が本件ソフトウェアを開発するために必要な、以下のハードウェア、ソフトウェア、ネットワーク、場所等の作業環境（開発環境）を甲の費用負担で用意し乙に対し本件業務遂行実施期間中無償で提供するものとする。[2] ......
5. 委託料及びその支払期限等の支払条件、並びに委託料の他甲が負担すべき費用及びその負担方法： (1) 委託料及びその支払期限等の支払条件：(例1)「委託料は○○円（消費税を除く）とする。甲は、全ての納入物の検収が行われた月の翌月末日までに当該委託料及びその消費税額を支払うものとする。」 （例2）「委託料は、以下の通り分割払いする。 ......」 (2) 委託料の他甲が負担すべき費用及びその負担方法：[かかる費用がある場合は､その内容､負担、乙への支払い等の条件を記載すること] 1) 上記4において甲の負担とされている費用 2) ...... 6. 再委託 [既に甲が承諾している再委託がある場合に必要事項記入] 乙は、以下の業務を以下の再委託先に再委託できるものとする。 (1) 再委託対象業務の内容：...... (2) 再委託先：...... 7. 納入物の第三者による利用：[甲が、納入物を第三者に利用させる場合には以下の事項を範囲を記載] (1) 対象納入物：（例）「本件ソフトウェアのオブジェクトコード、システム運用マニュアル及びユーザ利用マニュアル」 (2) 第三者（又はその範囲）：（例）「甲の子会社である以下の会社：株式会社○○○○、××××株式会社、......」
8. その他の開発請負業務遂行上必要な事項： (1) ...... (2) ...... 以上の通り甲乙合意し本個別契約を締結する。 ○○年○○月○○日 （以下省略） |
Q11：開発請負業務の実施
A11：以下に規定例を示します。|
第3章 開発請負業務
第7条 （開発請負業務の実施） 1. 本契約及び個別契約に従い、乙は、本件ソフトウェアの開発請負業務を、個別契約で特定された仕様に基づき行うものとする。 2. 甲は、開発請負業務に関し、甲が実施又は協力すべき事項として個別契約に定められた事項及びかかる事項としてその都度乙が要求し必要かつ合理的と認められる事項を行うものとする。 |
【解 説】
【第1項】 ここで「個別契約で特定された仕様」とし、「仕様確定支援業務の結果確定された仕様」としなかった理由は、ユーザによっては、自ら単独で、又は他のベンダに作成させ承認・確定した仕様に基づき、乙に開発請負業務を委託する場合もあり得ると考え、そのような場合にも対応できるよう、開発請負業務において使用する仕様は、同業務についての個別契約に記載し特定することとしたものです。 この場合、ユーザ（甲）が提示した仕様が、乙が本件ソフトウェアの開発、及び開発費用・請負金額、開発期間・納期等の見積もり・予想が正確に行える程度・水準でないため、乙がその仕様に基づく開発請負業務を受託することが困難な場合、乙は、仕様の訂正・補充等を甲に求め、又は仕様確定支援業務を受託して行い、求められる程度・水準の仕様とした上で、個別契約を締結して開発請負業務を受託することになると思われます。 【第2項】 開発請負業務は、基本的に乙が主体となりその責任のもとで行われますが、例えば、以下のような甲による実施・協力が必要となる場合も考えられます。 (a) 要件定義書レベルのもののみを仕様とした場合、乙が仕様に基づき作成する本件ソフトウェアの画面、帳票等のユーザインターフェース等について、甲の意向・評価が必要である場合 (b) 本件ソフトウェアに第三者のソフトウェア（又はクラウドサービス）を組み入れる予定であり、それを利用する権利を甲の費用負担で取得し乙に開発請負業務実施期間中無償で利用させることとした場合 本項は、このような場合、予め個別契約に定めること、又は、その都度乙が要求することにより、甲が当該実施・協力事項を行うべきことを規定したものです。これらの実施・協力事項には、ベンダが、そのプロジェクト・マネジメント義務[3]に基づき、ユーザに具体的課題・期限を示して要求した意思決定等も含まれます。Q12：本件ソフトウェアその他納入物の納入・検収
A12：以下に規定例を示します。|
第8条 （本件ソフトウェアその他納入物の納入・検収） 1. 個別契約に定める条件に従い、乙は、本件ソフトウェアその他納入物を甲に納入し、甲はこれを受領するものとする。乙は、個別契約に定める期限まで納入物を納入することができない事由が生じた場合、その旨直ちに甲に通知し、その対応について甲と協議するものとする。 2. 甲は、納入物の受領後2週間（但し、個別契約に別段の期間を定めた場合にはその期間）（以下「受入検査期間」という）以内に、納入物が個別契約に定める仕様に適合するか否か（以下、適合することを「契約適合」、適合しないことを「契約不適合」という）の検査（以下「受入検査」という）を行うものとする。 3. 前項の場合において、事前に甲及び乙が書面で合意した受入検査の基準・仕様があるときは、甲は当該基準・仕様に従い受入検査を行うものとする。 4. 甲は、受入検査において契約適合を確認した場合にはその旨、受入検査において契約不適合を発見した場合にはその旨並びにその具体的内容及び理由を、乙に書面で通知するものとし、乙は、契約不適合の通知を受けた場合には直ちにその内容を確認するものとする。 5. 乙は、前項に従い通知された契約不適合が存在する場合、速やかに、これを是正するために必要な納入物の修補を行った上でその終了を甲に通知するものとする。当該修補後の納入物については前各項を準用する。 6. 甲は、受入検査において契約不適合が確認された納入物であっても、甲乙書面で合意した場合には、契約不適合の程度に応じ委託料を減額し納入物を受入れることができるものとする。 7. 前各項に従い、甲が契約適合を確認した旨を乙に通知した場合には当該通知の時点で、甲が受入検査期間が経過するまでに契約適合・契約不適合いずれの通知も行わなかった場合にはその経過時点で、甲及び乙が前項の合意をした場合にはその時点で、当該納入物について受入検査が終了したものとする（以下、これを「検収」という）。 8. 納入物の媒体等の種類及び数量の検査及びその後の対応については、第2項から前項までの規定に定める検査及び対応とともに、これら規定を準用して行うものとする。甲は、検収後は、当該種類又は数量が個別契約に適合しないことを理由としてその是正その他の措置を請求できない。 |
【解 説】
【第1項】 乙は、本件ソフトウェア完成後、本件ソフトウェアを含む納入物を、個別契約に定める条件（納入媒体、納入個数、納入場所・方法、納入期限等）に従い、甲に納入し、甲はこれを受領するものとします。ここでは、甲に納入物の受領義務があることを明確化しています。なお、下請法の適用がある場合、下請事業者（ここではベンダ）の責に帰すべき理由がないのに，下請事業者の給付の受領を拒むことは禁止されています（下請法4条1項1号）。 【第2項・第3項】 ここで定義する「契約適合」及び「契約不適合」の用語は本契約第10条（契約不適合責任）でも共通して用いています。 「モデル契約」（経産省・IPA（情報処理推進機構）発行）（29条）では、契約不適合を納入物についてのシステム仕様書との不一致（バグも含む）と定義しています。この「バグ」とは、辞書等によれば「コンピューターのプログラム上の不具合や誤り」[4]等とされていますが、「モデル契約」上は定義がありません。「モデル契約」において「バグ」がシステム仕様書との不一致の一種であるとすれば、あえて括弧書きを追加する必要はありません。反対に、「バグ」がシステム仕様書との不一致以外の不具合・誤りを含むのだとすれば、「バグ」の意味の曖昧さから、ユーザはユーザの主観的要求・ニーズを満たさないものも含めて広く解釈し、ベンダは狭く解釈しようとすると思われるので、無用な紛争を生じさせかねません。 この点、「システムの機能の全てがシステム仕様書に記載されるとは限らない。例えば、システム仕様書には記載がないが当該業務に用いるプログラムとして当然に備えている機能があるとすれば、そのような機能をプログラムが欠いているのであれば、それは「バグ」と評価し得る」という見解[5]もありますが、「バグ」という言葉だけからそのような解釈を導き出すことはできないと思われます。 そこで、本契約では「契約不適合」を「仕様に適合」しないことと定義し、あくまで仕様を基準としつつ[6]、仕様との「一致」・「不一致」という言葉（仕様の記載との一致・不一致というニュアンスがあるように思われる）ではなく、改正後の民法(562条、637条等)で用いられており、また、情報処理技術分野での常識から見て仕様が当然前提としていると認められる機能・基準等[7]を含み得ると思われる「適合」・「不適合」という言葉を使用しています。 （検査仕様書による受入検査・検収）「モデル契約」では、ソフトウェアの受入検査・検収のため、検収に先立ち、ベンダが検査仕様書を作成し、ユーザが承認した検査仕様書に基づき、システム仕様書（要件定義書及び外部設計書）と納入されたソフトウェアが一致するか否かを点検することにより、受入検査・検収が行われることとなっています（27条、28条）。 検査仕様書を作成する理由の一つは、大規模開発では、納入されたソフトウェアの全体についてシステム仕様書の全ての項目との一致若しくは適合を点検するには、長期間を要し、その完了を待ったのでは、検収が遅れ、その結果委託料の支払が遅れ、一方、ユーザとしてもソフトウェアの利用開始が遅れてしまうからだと思われます。 しかし、本契約では中小規模開発（開発期間最大1年程度の中小規模のソフトウェア開発）を前提としているので、第2項で、原則として、検査仕様書を作成せず[8]、直接仕様を基準として受入検査を行うこととしています。但し、中小規模開発における受入検査であっても検査仕様書のような受入検査の基準・仕様を作成しそれを基準とすることが適切・有効な場合もあり得ると思われることから、第3項を設けています。 【第6項】 ここでは、民法563条（民法559条で請負に準用）のように、甲から一方的に、「契約不適合の程度に応じて代金[ここでは委託料]の減額を請求することができる」（形成権[9]）と規定することも考えられます。しかし、本契約におけるように、特注で開発したソフトウェアに関しては、「契約不適合の程度に応じ」た減額の幅がいくらであるべきかは算定困難[10]ですし、実際的にも両者合意しない限り裁判でもしなければ減額幅が確定しないので、本項では「甲乙書面で合意した場合には」委託料を減額できるものとしています。 なお、下請法の適用がある場合には、「下請事業者の責に帰すべき理由がないのに，下請代金の額を減ずること」が禁止されており（下請法4条1項3号）、減額幅が合理的な額よりも大きい場合には、この禁止に違反するおそれがあると思われます。 【第7項】 ここでの「検収」の意味は、受入検査期間中には契約不適合が発見されなかったという意味であり、委託料支払いの前提条件に過ぎません。「検収」は、契約不適合がなかったこと及びそれによるベンダの免責を確定するものではなく、甲は、第10条に従い、その後に発見された契約不適合について修補を請求することができます。 なお、請負は、「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払う」契約（民法632条）ですが、判例上、「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべきであり、注文者は、......単に、仕事の目的物に瑕疵があるというだけの理由で請負代金の支払いを拒むことはできない」、また、「検収未了であることをもって仕事の完成の成否に影響はない」とされている[11]ので、ベンダが本件ソフトウェアの開発の最後の工程まで終えてユーザに納入をしていれば、仮に検収未了でも、支払い時期は別として、請負代金支払義務は発生していることになります。 【第8項】 民法562条（民法559条で請負に準用）1項では、請負の目的物の「種類、品質又は数量」の契約不適合に対する注文主の追完請求権が規定されています。一方、民法637条1項では同636条を受けて「種類又は品質」の契約不適合についてのみ注文者が「不適合を知った時から1年」（内に通知）の期間制限をしています。従って、これらの反対解釈として、注文主は目的物の「数量」の契約不適合に対する追完請求権についてはこの民法の1年の期間制限を受けず、民法166条による時効消滅（最大引渡しから10年）まで行使できることとなります（これは民法改正でそうなってしまったのであるが、その説明されている改正趣旨については脚注[12]参照）。 しかし、ソフトウェア開発請負における目的物であるソフトウェアの媒体等の数量（及びその種類（例：CD-ROM））が契約通りか否かは、受入検査の際に簡単に検査できるはずであり、民法のように何年も後でもその不適合の是正（追完）を請求できることとするのは極めて非現実的・不合理です。なお、請負には準用されないものの、商人間の売買に適用される商法の売買の規定(商法526(2)本文)では、買主は、目的物受領時の検査により売買の目的物が数量に関して契約の内容に適合しないことを発見したときは、直ちに売主に対してその旨の通知を発しなければ、その不適合を理由とする履行の追完の請求等をすることができないとされており、この商法の規定の方が現実の取引に合っています。 そこで、本項では、現実の取引に合わせ、媒体等の種類・数量の契約不適合は受入検査手続の中でのみ通知・対応することとし、検収後はこれを問題とすることを禁止し、民法の適用を排除しています。Q13：開発請負業務に係る委託料及び費用負担
A13：以下に規定例を示します。|
第9条 （開発請負業務に係る委託料及び費用負担） 1. 甲は、個別契約に定める開発請負業務の委託料及びその消費税額を、個別契約に定める支払期限等の支払条件に従い、乙が事前に甲に書面で通知する銀行口座に振り込むことにより支払うものとする。 2. 甲は、個別契約又は別途甲乙書面において合意し委託料の他甲が負担すべきものとされた費用を、当該合意に従い負担するものとする。 3. 前二項に定める委託料及び費用を除き、乙は、開発請負業務の遂行に要する全ての費用を負担するものとする。 |
【解 説】
【第1項】 甲は、個別契約に定める委託料（通常、固定金額）を、検収後に（又は中間払がある場合はその指定時期に）、個別契約に定める支払期限等の支払条件（例：検収月の翌月末日までに支払い）に従い支払います。 なお、下請法の適用がある場合（第33回Q5参照）、開発請負業務がプログラム作成に係る情報成果物作成委託に該当するときは、その情報成果物の検収日等からではなく情報成果物受領日から60日(又は2か月)以内に支払期限を定め支払わなければならない[13]ので、実務上は、納入物受領月の翌月末日までに支払いを要することになります。 【第3項】 実態は労働者派遣であるのに、労働者派遣法上の義務・制約を免れるため、請負契約や業務委託契約を締結し偽装することは、一般に「偽装請負」と呼ばれ取締りの対象となります（詳細は第33回Q6参照）。これに該当するか否かは、厚労省「労働者派遣事業と請負により行われる事業との区分に関する基準」に基づき、実態に即して判断されますが、本項では、同基準の中の「業務の処理に要する資金につき、すべて自らの責任の下に調達し、かつ、支弁すること」を考慮し、「偽装請負」と判断されることがないよう、業務遂行費用が原則として乙負担であることを明記しています。Q14：契約不適合責任
A14：以下に規定例を示します。|
第10条 （契約不適合責任） 1. 検収された納入物に契約不適合がある場合、甲は、乙に対し、その旨並びに契約不適合の具体的内容及び理由を書面で通知した上納入物の修補を請求することができるものとし、乙は、速やかに、当該契約不適合を是正するために必要かつ適切な方法により納入物を修補するものとする。 2. 前項にかかわらず、乙は、書面で甲の承諾を得た上、前項の修補に代えて、当該契約不適合の回避又は軽減のための措置、委託料の減額又は一部返還その他の措置（以下これらの措置を総称して「代替措置」という）を講じることができるものとする。甲は、合理的理由なく、当該承諾を拒否してはならない。 3. 乙が第1項に従った修補を行うこと及び前項に従った代替措置を講じることが、いずれも、本契約及び個別契約並びに取引上の社会通念に照らして不能である場合、甲は乙に対し当該修補及び代替措置を請求することができない。但し、甲が本契約に従い損害賠償の請求並びに本契約及び個別契約の解除をすることを妨げない。 4. 甲が第1項に規定する通知を当該納入物の検収後1年以内にしない場合、甲は、契約不適合を理由として、納入物の修補及び代替措置の請求、損害賠償の請求並びに本契約及び個別契約の解除をすることができない。 5. 納入物の契約不適合が、甲の提供したものの性質若しくは甲の与えた指図（但し、乙がそのもの又はその指図が不適当であることを知りながら告げなかった場合を除く）その他甲の責めに帰すべき事由によるものである場合、甲は、当該納入物の修補及び代替措置の請求、損害賠償の請求並びに本契約及び個別契約の解除をすることができない。 6. 納入物の契約不適合が本契約及び個別契約並びに取引上の社会通念に照らして軽微(以下「軽微」という)である場合、又は乙が第1項に従った修補を行い又は第2項に従った代替措置を講じた結果当該契約不適合が是正され又は軽微となった場合、甲は、本契約及び個別契約の解除をすることができない。但し、甲が本契約に従い損害賠償の請求をすることを妨げない。 |
【解 説】
【第1項】（追完の方法） 契約不適合責任に関し、民法562条（民法559条で請負に準用）1項によれば、「引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるときは、ユーザは、ベンダに対し、目的物の修補、代替物の引渡し又は不足分の引渡しによる履行の追完を請求することができる。但し、ベンダは、ユーザに不相当な負担を課するものでないときは、ユーザが請求した方法と異なる方法による履行の追完をすることができる」ということになります。ここで、「追完」の意味について民法上は定義がありませんが、一般には「不完全履行をした債務者が、のちにあらためて債務の本旨にかなった完全な給付をすること」[14]と解されています。 すなわち、民法562条では、目的物の修補、代替物の引渡し又は不足分の引渡しの3種類の履行の追完方法のうちどれを選択してどのように追完するかの選択権がユーザ（ここでは甲）にある[15]ことを前提として、但書で、乙は、甲に不相当な負担を課するものでないときは、甲が請求した方法と異なる方法による履行の追完をすることができる旨規定しており、本契約においてもそのように規定することも考えらえます。 しかし、本項では、以下の理由から、追完方法（種類）を修補に限定し、かつ、乙（ベンダ）が、当該契約不適合を是正するために必要かつ適切な具体的方法（どこをどう修補するか）を判断して修補することとしています。 (a) 本契約では、納入物の媒体等の数量違いは、第8条第8項に定める通り受入検査期間内に通知があった場合のみ是正することとしている。また、本条で規定する「契約不適合」とは仕様に適合しないことである。従って、本条において「不足分の引渡し」は関係がない。 (b)「代替物の引渡し」に関しては、例えば、売買取引でその目的物が量産品であれば、契約不適合の製品を修補するか同じ製品の新品（代替物）を提供するかの選択において、その契約不適合が修補により速やかに追完できるにもかかわらず、甲が新品での交換を選択・請求した場合に、乙が甲の請求とは異なる修補で追完することは合理性があると思われる。しかし、本契約は、特注開発のソフトウェアを対象とするので、その「代替物」を想定し難く、また、仮に甲が本件ソフトウェアと同等の機能を包含する既存ソフトウェア製品（おそらくより高額）との交換を請求した場合に、乙にこれに応じさせることが必要・適切とも思われない。従って、本条において、追完方法として「代替物の引渡し」を認める合理性・必要性はない。 (c) 契約不適合に対する修補の具体的方法（どこをどう修補するか）は、本件ソフトウェアを開発しかつ修補に要する費用・時間等の負担を負う乙(ベンダ)がユーザよりも適切に判断できると思われる。 【第2項】（修補の代替措置） 修補が困難な場合に関し、「モデル契約」（29条2項）では、「前項[の履行の追完義務]にかかわらず、当該契約不適合によっても個別契約の目的を達することができる場合であって、追完に過分の費用を要する場合、乙は前項所定の追完義務を負わないものとする。」と規定されており、これによれば、客観的にこの場合に該当する限り、直ちに自動的に乙の追完義務が免除されることになります。 この「個別契約の目的を達する」は改正前民法635条の、「過分の費用を要する」は改正前民法634条1項但書に出てくる用語ですが、これらの判定について両当事者の見解が対立する可能性は高いと思われ、また、過分の費用を要すれば直ちに追完義務を免除される（但し、損害賠償、契約解除の責任は残る）のも行き過ぎであるようにも思われます。 これに対し、本項では、ソフトウェアでは不具合が修補されなくてもその回避方法[16]が提供されればほとんど支障がない場合も多いので、乙は、甲の承諾（合理的理由なく拒否できない）を得た上、当該修補に代えて、当該契約不適合の回避、委託料一部返還等の代替措置を講じることができるものとしました。「甲の承諾（合理的理由なく拒否できない）を得た上」としたのは、甲の承諾なくこれらの代替措置を実行することは困難でありまた実行したとしても甲が満足せず紛争の原因となり得ると思われるからで、甲の承諾を得ることを原則としつつ、甲が不合理な理由で拒否できないようにしました。なお、委託料の減額又は一部返還については、民法563条（民法559条で請負に準用）の代金減額請求権のように甲からの一方的形成権とすることには、受入検査における委託料減額（本契約第8条第6項）に関し述べたのと同じ問題があるので、やはり甲乙の合意により行うこととしています。 但し、修補も代替措置も不能の場合は、本契約では第3項によりそれらの履行は免除されます。 【第3項】（修補等が不能な場合における修補等免除） 本項本文（修補等が不能な場合の修補等免除）は民法412条の2（履行不能）第1項に準じたものです。 本項但書（修補等が不能でも損害賠償・契約解除は可能）は民法415条（債務不履行による損害賠償）1項本文及び民法542条1項1号（債務の全部の履行が不能であるときの無催告解除）に準じたものです。 【第4項】（契約不適合責任の期間的制限） 請負における契約不適合責任の期間的制限に関し、民法637条1項では「注文者がその不適合を知った時から一年以内にその旨を請負人に通知」として、注文者の知った時を起算日として1年間内の通知を要求しています。 このことは、現行民法上、契約不適合責任が、最大、納入物引渡しから10年経過して時効消滅するまで存続し得ることになる（民法166条：債権等の消滅時効)こと（詳細は21回Q2参照）等、一般的には、ソフトウェア開発委託において合理的とも取引の実情に適合するとも言えません。また、改正前民法(637条1項)上、請負の瑕疵担保責任の請求期間は「仕事の目的物を引き渡した時から1年以内」であったことから実際の取引でもほとんど納入又は検収を起算日としており、それは改正後も変わっていません。 従って、本契約では、「モデル契約」（29条）を含めほとんどの契約条項例と同様、甲が契約不適合を通知すべき期間（以下「契約不適合通知期間」）を検収時を起算日として設定しています。 なお、契約不適合通知期間の起算日を、ユーザが「本件ソフトウェアの本番稼働を開始した日」とする規定例もありますが、その場合には、「本番稼働を開始した日」を客観的に判断できる定義が必要であるように思われます。また、ベンダの立場からは、ユーザが「本番稼働日」を遅らせたときには実質的に契約不適合通知期間が延長される結果となるので、例えば、「但し、本番稼働日が検収日から〇か月の期間を超えた場合には、当該期間経過時に本番稼働が開始されたものとみなす」等とすることが必要と思われます。 請負に関する契約不適合通知期間の長さについては、一般に1年間が多く、ベンダの多くも1年を前提として、契約不適合への対応コストを見積り受注金額を決めていると思われることから、本契約でも1年間としています。 なお、上記の起算日又は期間を変更する場合は、個別契約にその変更後の起算日・期間を定めることになります。 【第5項】（契約不適合の原因がユーザ側にある場合の修補・損害賠償の請求、契約解除の制限） 民法415条（債務不履行による損害賠償）1項但書[17]、562条（買主の追完請求権）2項[18]（民法559条で請負に準用）、及び636条（請負人の担保責任の制限）[19]と同趣旨のユーザ側に帰責事由がある場合の修補・損害賠償請求及び契約解除の制限に関する規定です。 【第6項】（契約不適合が最初から軽微な場合又は是正後軽微となった場合の解除制限） 本項は、契約不適合が最初から軽微な場合（例：めったに使わない重要でない機能が機能しないが機能しなくても問題が軽微な場合）又は是正後軽微となった場合（一部修補又は回避措置適用により問題が軽微となった場合）に関し、以下を踏まえて、ユーザの契約解除権を制限したもので、後述する、第21条1項(1)号の契約違反がその通知後30日以内に是正されない場合の契約解除権の例外・特約となります（同号括弧書き参照）。 (a) 民法上、請負の注文者は、契約不適合に対し相当期間を定め追完の履行の催告をしその期間内に履行がない場合、原則として、契約を解除できる（民法564条、541条本文：同559条で請負にも準用）が、民法541条但書により、当該催告の相当期間を「経過した時における不履行[契約不適合]がその契約及び取引上の社会通念に照らして軽微であるとき」は、契約解除できない。 (b) 判例上、情報処理システムの開発に当たっては、作成したプログラムに不具合が生じることは不可避であり、その特殊性に照らすと、ユーザからの通知後ベンダが遅滞なく補修を終えるか、ユーザと協議した上で相当な代替措置を講じた場合には瑕疵には当たらないとされている[20]。この最後の「瑕疵には当たらない」は、もし瑕疵（現在は契約不適合）がないとすれば、そもそも修補の請求もできないことになり、不合理であるが、その趣旨は、プログラムにある程度の不具合が生じることは不可避なのであるから、修補・代替措置が遅滞なくなされれば、もはや契約解除まで認める必要性・妥当性はないという趣旨と思われる。 (c) 「モデル契約」（29条4項)でも、「契約不適合について、追完の請求にもかかわらず相当期間内に追完がなされない場合又は追完の見込みがない場合で、当該契約不適合により個別契約の目的を達することができないときは、甲は本契約及び個別契約の全部又は一部を解除することができる。」として、契約不適合の場合における契約解除を制限している。 (d) 改正民法の審議過程で、『「軽微」という基準ではなく、「契約の目的の達成、不達成」を基準にすることが法制審における審議経過では議論されたが、催告解除においては、たとえ不履行によって契約目的の達成が不可能になったとはいえない場合でも、なお解除は認められるべきというのが実務の要請であるとして、「軽微」という基準が採用されている』（大阪弁護士会編「実務家のための逐条解説 新債権法」（2021,有斐閣）（「逐条」）436)。 — 従って、「契約目的の達成が不可能な」状態の方が、単に契約不適合が「軽微」ではない状態よりも重大な不履行・契約不適合ということになる。 （「軽微」の主張立証及び解釈）「軽微」であることの主張・立証責任はベンダ（乙）が負います。「軽微」か否かは、目的論的に解釈すれば、催告された相当期間経過時[従って既に修補が完全に又はある程度なされた可能性がある]における不履行（契約不適合）又はその治癒・不治癒の状態が、もはや注文者に契約解除を認める（その結果として委託料及び本件ソフトウェアを相互に返還して原状回復する:民法545）ことが相当でない程度のものか否かにより判断されるのではないかと思われます（なお、学説上の解釈について脚注[21]参照）。 （本項但書：損害賠償請求）本項に規定する場合において、契約解除だけでなく損害賠償請求もできないこととすることも考えられます。しかし、修補の結果契約不適合が「軽微」になった（例：不適合がプログラミング上の単純ミスによるもので簡単にその修補はできた）場合でも、既にその不適合により「軽微」ではない重大損害が発生している可能性はあり、その場合でも損害賠償請求ができないこととするのは合理的でないと思われます。そこで、本項では、むしろ、但書で損害賠償請求は妨げられない旨明記しています。Q15：仕様の変更
A15：以下に規定例を示します。|
第11条 （仕様の変更） 1. 甲及び乙は、乙による本件ソフトウェアの開発中、仕様の内容の変更（以下「仕様変更」という）が必要と認める場合、仕様変更の内容、理由、必要性等を明記した書面を相手方に提出し仕様変更の提案をすることができる。 2. 甲及び乙は、前項の提案があった後速やかに、仕様変更の内容、理由、必要性、適否、仕様変更に伴い必要となる本契約又は個別契約の条件（納入期限、委託料等）の変更等について誠実に検討及び協議するものとする。 3. 甲及び乙は、前項の検討及び協議の結果、仕様変更をしようとする場合には、最終的な仕様変更の内容及び当該仕様変更に伴う本契約又は個別契約の条件の変更について、書面により合意するものとし、当該合意により仕様変更が確定したものとする。 4. 甲は、甲が第１項の提案をした後3か月（又は別途甲乙書面で合意した期間）を経過してもなお甲の提案する仕様変更について前項の合意が成立しない場合、開発請負業務の未了部分について個別契約を解約することができる。但し、この場合、甲は、当該解約時点までに乙が遂行した開発請負業務の委託料及びその消費税額を支払うとともに、解約により乙が出捐すべきこととなる費用その他乙に生じた損害を賠償しなければならない。 |
【解 説】
【第1項～第3項】 ソフトウェアの開発において仕様の変更は、納期延長、委託料増加等を伴うことが多いので、一般に好ましくないものの、実際にはユーザ又はベンダから要求され、しばしば、協議が整わず紛争となることがあります。 そこで、第1項～第3項では、そのような紛争を可能な限り回避するための協議及び仕様変更手続を規定しています。 【第4項】 両当事者が合意しない限り仕様の変更は認めず、従来の仕様のままで契約を続行させることも考えられます。しかし、本項のように、ユーザが仕様変更を希望・提案するもののベンダがこれに応じないような場合にまで、契約の履行・続行を強制しても、ユーザが望まない仕様のため利用されないかもしれないソフトウェアを生むばかりで社会的にも不経済・不適切です。また、民法（641条）では、「請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる」と定めています。そこで、本項では、「モデル契約」38条2項を参考に、そのような場合、開発請負業務の未了部分に限定し、かつ、甲が既に遂行された開発請負業務の委託料及びその消費税額を支払うこと、及び乙に生じた損害を賠償することを条件として解約を認めることとしています。 今回はここまでです。 [22] 【注】 [1] 【本稿作成上モデル契約以外で主に参考とした資料】(1)西本強「ユーザを成功に導くシステム開発契約―クラウドを見据えて〔第2版〕」 2016/7/8、商事法務（以下「西本」). (2)伊藤雅浩・久礼美紀子・高瀬亜富「ITビジネスの契約実務〔第2版〕」 商事法務、2021/10/18（以下「伊藤他」). (3)阿部・井窪・片山法律事務所(編集)「契約書作成の実務と書式- 企業実務家視点の雛形とその解説 第2版」2019/9/24(2021/2/20補訂)（以下「阿部・井窪・片山法律事務所」）. (4）上村哲史、田中浩之、辰野嘉則「ソフトウェア開発委託契約 交渉過程からみえるレビューのポイント」2021/7/22、中央経済社（以下「上村他」）. (5)愛知県弁護士会 研修センター運営委員会 法律研究部 契約審査チーム(編集)「新民法対応 契約審査手続マニュアル」 2018/3/5、新日本法規出版（以下「愛知県弁護士会」という）. (6)大阪弁護士会民法改正問題特別委員会(編集)「実務家のための逐条解説 新債権法」 2021/10/13、有斐閣（以下「逐条」という）.(7) 池田聡「システム開発 受託契約の教科書」2018/1/17, 翔泳社（以下「池田」）. (8)難波修一,中谷浩一,松尾剛行「裁判例から考えるシステム開発紛争の法律実務」2017/2/27、商事法務（以下「難波他」） [2] 【ユーザからベンダへの開発環境の提供】「池田」（契約書例2-2-(12)）には、「システム開発においては、請負契約であっても、開発環境を発注者であるユーザーが（少なくとも費用負担としては）提供することがよくあります。開発に使うマシンをそのまま本番に移行する、あるいは開発に使ったマシンを本番稼働後もテスト環境としてユーザーが保持しておく方が合理的なことが多いからです」とある。 [3] 【ベンダのプロジェクト・マネジメント義務】「難波他」p.98-100 [4] 【「バグ」の意味】 コトバンク「バグ」、デジタル大辞泉「バグ」の解説 [5] 【「バグ」に関する見解】「阿部・井窪・片山法律事務所」 p. 430 [6] 【契約不適合の定義】一般社団法人電子情報技術産業協会（JEITA)のモデル契約の第29条（契約不適合責任）でも、「......納入物についてシステム仕様書との不一致（以下「契約不適合」という。）」とある。 [7] 【仕様が当然前提としていると認められる機能・基準等】「上村他」(p. 93,94)には、「同種のシステムでは通常必ず入っているような機能......は、仕様書には明記されていないが、当然に仕様として要求されている、言葉を変えると、黙示的な合意があるとみれば良いのではないかと思います」との記載がある。 [8] 【検査仕様書の不作成】「伊藤他」p. 82にも「しかし、実務では、契約書に定められた「検査仕様書」が作成されていなかったり、具体的にどの文書が検査仕様書に該当するのかが当事者間で明確に把握されていないといった事例も散見される」との記載がある。 [9] 【代金減額請求権の法的性格】 「逐条」p. 513には「何らの留保もなく代金減額請求権の意思表示を内容証明郵便等で行うと、これは明らかに形成権の行使であるから、その行使の効果として直ちに代金は減額されることになる。」と記載されている。コトバンク『日本大百科全書(ニッポニカ)「形成権」の解説』：「一方的意思表示により法律関係の変動（法律関係の創設や消滅）を生じさせる権利」 [10] 【代金減額請求権の減額額の算定のあり方】 「逐条」p. 510には見解（三説）の対立があるとされている。どの説によっても、特に、製品ではない特注品の場合は算定困難と思われる。 [11] 【仕事の「完成」及び「検収」に関する判例】 「難波他」p.137（サンセキ事件）、p.140（第一法規事件）参照 [12] 【改正民法において数量の契約不適合に関し期間制限が適用されないとされた理由】松岡久和,中田邦博(編集)「新・コンメンタール民法(財産法)第2版」（日本評論社、2020/9/5)(p.967)には、同様の規定である、売買の担保責任の期間制限に関する民法第566条に関してであるが、以下の通り解説されている。『「数量」に関する契約不適合の場合には、本条の期間制限は適用されない。数量に関する不適合は、売主にとって比較的容易に判断できることから、履行が完了したことについての売主の期待をとくに保護する必要はないと考えられたからである。改正前民法565条（数量不足の担保責任）が準用する同564条では、1年の権利行使期間の制限が定められていたが、改正法はこれを改めた。』. [13] 【下請法の提供がある場合の支払期限】「下請取引適正化推進講習会テキスト」p. 45等参照 [14] 【「追完」の意味】 コトバンク「追完」、ブリタニカ国際大百科事典 小項目事典「追完」の解説 [15] 【民法562条の追完方法の選択権】 「逐条」p. 505には、「買主に追完請求権が認められる場合の追完方法は、目的物の修補、代替物の引渡し又は不足分の引渡しの三種である。追完方法の選択は、第一次的には買主の選択に委ねられている」と説明されている。 [16] 【ソフトウェアの不具合の回避方法】「難波他」p.161「ヒットマン事件」：ベンダがユーザに販売したシステムに、ユーザにそれなりの不便・不都合を生じさせるものがあったが、ユーザに1分程度の作業で済む運用変更により業務上の支障が解消できることを助言していた事例で、ユーザは売買契約を解除できないとした。 [17] 【民法415条1項但書】「債務者がその債務の本旨に従った履行をしないとき又は債務の履行が不能であるときは、債権者は、これによって生じた損害の賠償を請求することができる。ただし、その債務の不履行が契約その他の債務の発生原因及び取引上の社会通念に照らして債務者の責めに帰することができない事由によるものであるときは、この限りでない。」 [18] 【民法562条（買主の追完請求権）第2項】「２ 前項の不適合が買主の責めに帰すべき事由によるものであるときは、買主は、同項の規定による履行の追完の請求をすることができない。」 [19] 【民法636条（請負人の担保責任の制限）】「請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき（その引渡しを要しない場合にあっては、仕事が終了した時に仕事の目的物が種類又は品質に関して契約の内容に適合しないとき）は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。」 [20] 【プログラムの不具合の不可避性】東京地裁平成14年4月22日判決（サンセキ事件）「情報処理システムの開発に当たっては、作成したプログラムに不具合が生じることは不可避であり、プログラムに関する不具合は、納品及び検収等の過程における補修が当然に予定されているものというべきである。このような情報処理システム開発の特殊性に照らすと、（中略）注文者から不具合が発生したとの指摘を受けた後、請負人が遅滞なく補修を終えるか、注文者と協議した上で相当な代替措置を講じたと認められるときは、システムの瑕疵には当たらない。」（内田・鮫島法律事務所 IT法務.COM「システムの瑕疵とは？」より再引用）。 [21] 【「軽微」の主張立証及び解釈】は、「逐条」(p.437, 438)では以下のように説明されている。「一般的には，「軽微であるとき」と言えるか否かは，①不履行の態様の軽微性，及び，②違反された義務の軽微性により判断されると指摘されている。その際には，当該契約及び取引上の社会通念に照らして，諸事情が考慮されることとなるが，その要素として，「不履行のあった債務の内容（要素たる債務か・付随的な債務か）」，「債務不履行の程度（数量・品質・種類の相違の程度）」，「契約の目的の内容」，「債務の不履行が契約の目的達成に及ぼす影響の程度（債務者の受ける不利益の程度）」，「追完・追履行の容易性（必要なコスト）」，「追完・追履行に係る債務者の態様」等の事情が指摘されている（鎌田薫ほか『重要論点実務民法（債権関係）改正』〔商事法務，2019年〕249頁）。」 [22]＝＝＝＝＝＝＝＝＝＝
【免責条項】
本コラムは筆者の経験にもとづく私見を含むものです。本コラムに関連し発生し得る一切の損害などについて当社および筆者は責任を負いません。実際の業務においては,自己責任の下,必要に応じ適宜弁護士のアドバイスを仰ぐなどしてご対応ください。|
【筆者プロフィール】 浅井 敏雄 (あさい としお) 企業法務関連の研究を行うUniLaw企業法務研究所代表／一般社団法人GBL研究所理事 1978年東北大学法学部卒業。1978年から2017年8月まで企業法務に従事。法務・知的財産部門の責任者を米系(コンピュータ関連)・日本(データ関連)・仏系(ブランド関連)の三社で歴任。元弁理士(現在は非登録)。2003年Temple University Law School (東京校) Certificate of American Law Study取得。GBL研究所理事, 国際商事研究学会会員, 国際取引法学会会員, IAPP (International Association of Privacy Professionals) 会員, CIPP/E (Certified Information Privacy Professional/Europe)【発表論文・書籍一覧】 |