ソフトウェア開発モデル契約の解説【2020 年 4 月 1 日施行 改正民法対応版】

2019 年 3 月

一般社団法人電子情報技術産業協会

ソリューションサービス事業委員会

はじめに
一般社団法人 電子情報技術産業協会（以下「JEITA」という。）は、2020 年版の「ソフトウェア開発
モデル契約」（以下「本モデル契約」という。）を策定しましたので、ここに公表します。
今般の改訂は、JEITA が 2008 年に公表した「ソフトウェア開発モデル契約」（以下「2008 年 JEITA
モデル契約」という。）をベースに、2020 年 4 月 1 日から施行される改正民法（平成 29 年 6 月 2 日法律第 44 号）への対応に伴い見直すことや、2008 年 JEITA モデル契約から約 10 年を経る中でソフトウェ
ア開発取引の条件に必要あるいは規定することが望ましい事項について反映しました。
本モデル契約は、ソフトウェア開発取引の適正化、更には、情報システムが社会に占める重要性に鑑みた情報システムの信頼性向上という観点をも踏まえ策定されてきました。信頼性の高いソフトウェアを開発するためには、ユーザとベンダの協力が不可欠であり、仕様、役割分担、必要な時期に確定すべき課題等に関する双方の認識を合わせることが必須です。これらは、契約条件についてユーザとベンダが協議して取引内容を具体化させていくものと考えられますが、経済産業省モデル契約、JISA モデル契約、2008 年 JEITA モデル契約など改正前民法を前提とした取引契約について、改正民法に対応した見直しが生じる場合、ユーザとベンダ双方が取引条件の理解を深めるためのツールとして、本モデル契約
および解説を広く活用いただければ幸いです。
2019 年 3 月
一般社団法人 電子情報技術産業協会
ソリューションサービス事業委員会

委員⼀覧■ソリューションサービス事業委員会■（敬称略・順不同）
委員長

東

純一

富士通株式会社

副委員長

川井

俊弥

日本電気株式会社

″

込宮

信治

沖電気工業株式会社

橋本

和人

株式会社 ＪＥＣＣ

″

光井

隆浩

東芝デジタルソリューションズ株式会社

″

田渕

樹子

日本電気株式会社

″

佐藤

昌紀

日本電気株式会社″

石塚由香利

日本電気株式会社″

新井隆

日本電気株式会社

″

松口

裕重

日本電気株式会社

″

今泉

利佐

日本マイクロソフト株式会社

″

土井

崇

日本マイクロソフト株式会社

″

銅玄

智昭

日本ユニシス株式会社

″

泉

菜穂子

株式会社 日立製作所

″

高柳

祐治

株式会社 日立製作所

″

堀田

敦志

株式会社 日立製作所

″

小平

憲彦

株式会社 日立製作所

″

押鐘

快之

富士通株式会社″

伊豆則夫

株式会社 富士通クオリティ＆ウィズダム

″

佐竹

秀彦

富士通株式会社″

玉井進

三菱電機インフォメーションシステムズ株式会社

事務局

大塚

豊

一般社団法人 電子情報技術産業協会

″

三浦

守

一般社団法人 電子情報技術産業協会

委

員

執筆者⼀覧

■ソフトウェア開発モデル契約改訂 TF■（敬称略・順不同）
主

査

高柳

祐治

副主査

土井

崇

日本マイクロソフト株式会社

委

西田

悟

沖電気工業株式会社

″

西尾

美和

沖電気工業株式会社

″

服部

史花

沖電気工業株式会社

″

高野つばさ

東芝デジタルソリューションズ株式会社

″

山本

勇司

日本電気株式会社″

深澤愼一郎

日本電気株式会社″

堤一秀

日本マイクロソフト株式会社

″

井沼

宏行

日本マイクロソフト株式会社

″

津川

博紀

株式会社 日立製作所

″

吉崎絵里奈

富士通株式会社″

本杉

文人

三菱電機インフォメーションシステムズ株式会社

″

玉井

進

三菱電機インフォメーションシステムズ株式会社

事務局

三浦

守

一般社団法人 電子情報技術産業協会員

株式会社 日立製作所

⽬ 次
はじめに
委員⼀覧・執筆者⼀覧
略語表・条⽂解説の構成
第１編

本モデル契約および解説の改訂に際して ・・・・・・・・・・・・・・・・・・・ 1

第１章

改訂の⽅針

第２章

改正⺠法への対応

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 1
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 1

第１節

基本的理解／1

第２節

請負について／1

第３節

準委任について／4

第２編

本モデル契約の前提となる開発プロセス等 ・・・・・・・・・・・・・・・・・・ 7

第３編

本モデル契約の条⽂解説 ・・・・・・・・・・・・・・・・・・・・・・・・・・・ 11

第１章

総則

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 12

第１条（契約の目的）／12
第２条（定義）／13
第３条（適用範囲・完全合意）／15
第４条（個別契約）／17
第５条（委託料及びその支払方法）／21
第６条（作業期間又は納期）／22
第７条（再委託）／22
第２章

本件業務の推進体制

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 25

第８条（協働と役割分担）／25
第９条（責任者）／28
第１０条（主任担当者）／29
第１１条（業務従事者）／31
第１２条（連絡協議会の設置）／32
第１３条（複数ベンダによる開発の場合の全体管理責任）／37
第３章
第１節

本件業務

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 39

要件定義作成支援業務／39

第１４条（要件定義作成支援業務の実施）／39
第１５条（要件定義作成支援業務に係る個別契約の締結）／42
第１６条（要件定義検討会）／42
第１７条（要件定義書の確定）／44
第１８条（業務の終了・確認）／47
第２節

外部設計書作成（支援）業務／50

Ａ案

準委任の場合第１９条（外部設計書作成支援業務の実施）／51
第２０条（外部設計書作成支援業務に係る個別契約の締結）／52
第２１条（外部設計検討会）／53
第２２条（外部設計書の確定）／54
第２３条（業務の終了・確認）／56
B案

請負の場合

第○条（外部設計書作成業務の実施）／59
第○条（外部設計書作成業務に係る個別契約の締結）／61
第○条（外部設計検討会）／62
第○条（外部設計書の納入）／64
第○条（外部設計書の承認及び確定）／64
第○条（契約不適合責任）／66
第３節

ソフトウェア開発業務／67

第２４条（ソフトウェア開発業務の実施）／67
第２５条（ソフトウェア開発業務に係る個別契約の締結）／70
第２６条（納入物の納入）／71
第２７条（検査仕様書の作成及び承認）／72
第２８条（本件ソフトウェアの検収）／75
第２９条（契約不適合責任）／77
第４節

ソフトウェア運用準備・移行支援業務／82

第３０条（ソフトウェア運用準備・移行支援業務の実施）／82
第３１条（ソフトウェア運用準備・移行支援業務に係る個別契約の締結）／83
第３２条（業務の終了・確認）／84
第４章

契約内容等の変更

・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 86

第３３条（本契約及び個別契約内容の変更）／86
第３４条（システム仕様書等の変更）／87
第３５条（中間資料のユーザによる承認）／89
第３６条（未確定事項の取扱い）／91
第３７条（変更管理手続）／92
第３８条（変更の協議不調に伴う契約終了）／94
第５章

資料及び情報の取扱い ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 96

第３９条（資料等の提供及び返還）／96
第４０条（資料等の管理）／97
第４１条（秘密情報の取扱い）／98
第４２条（個人情報）／101
第６章

権利帰属 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 103

第４３条（納入物の所有権）／103
第４４条（納入物の特許権等）／104
第４５条（納入物の著作権）／106
第４６条（乙による納入物の再利用）／108

第７章

保証及び責任 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 109

第４７条（知的財産権侵害の責任）／109
第４８条（第三者ソフトウェアの利用）／112
第４９条（FOSS の利用）／114
第５０条（セキュリティ）／115
第８章⼀般条項 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 116

第５１条（権利義務譲渡の禁止）／116
第５２条（解除）／117
第５３条（損害賠償）／118第５４条（輸出関連法令の遵守）／122
第５５条（反社会的勢力の排除）／122
第５６条（和解による紛争解決）／124
第５７条（仲裁）／125
第○条（合意管轄）／125
第５８条（協議）／125
第５９条（存続条項）／126

付録①︓本モデル契約書新旧対照表 ・・・・・・・・・・・・・・・・・・・・・・・・・・ 127
付録②︓JEITA 法務・知的財産部会 改正⺠法対応 TF 公表資料 ・・・・・・・・・・・・ 162
付録③︓ベンダのプロジェクトマネジメント義務・ユーザの協⼒義務に関する裁判例の概要
・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 165

付録④︓個別契約書のサンプル ・・・・・・・・・・・・・・・・・・・・・・・・・・・・ 169
付録⑤︓変更提案書・管理書のサンプル ・・・・・・・・・・・・・・・・・・・・・・・・ 171

略語表
JEITA

一般社団法人 電子情報技術産業協会

改正民法2020 年 4 月 1 日施行の改正民法（平成 29 年 6 月 2 日法律第 44 号）

改正前民法

改正民法が施行される前までの民法2007 年経済産業省報告書

2007 年 4 月経済産業省報告書『「情報システムの信頼性向上のための取引慣行・契約に関する研究会」～情報システム・モデル取引・契約書～（受託開発（一部企画を含む）、保守運用）〈第 1 版〉』

経済産業省モデル契約

2007 年経済産業省報告書に掲載されているモデル契約「ソフトウェア
開発委託基本モデル契約書｣（追補版を含む）

1994 年 JEIDA モデル契約

1994 年に JEITA の前身の社団法人 日本電子工業振興協会（JEIDA）
が作成した「ソフトウェア開発基本契約書」

2008 年 JEITA モデル契約

2008 年に JEITA が作成した「ソフトウェア開発基本契約｣

本モデル契約

今般 JEITA が作成した「ソフトウェア開発モデル契約」

共通フレーム 2013

『SEC BOOKS 共通フレーム 2013 ～経営者、業務部門とともに取組
む「使える」システムの実現～」（独立行政法人 情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター 編・発行 2013 年）

条⽂解説の構成「第 3 編 本モデル契約の条文解説」では、各条文を以下の構成で解説しています。
・【2008 年 JEITA モデル契約との相違】では、改正民法への対応箇所を中心に 2008 年 JEITA モデル契約から変更した点の概要について説明している。
・【条文解説】では、当該条文の趣旨あるいは背景について、実務的観点から JEITA 独自に解説している。
・【適用ガイド】では、当該条文を実際の契約書として活用する際あるいは当該条文に基づく運用を行う際の留意点やアドバイスを説明している。
・要件定義、外部設計、ソフトウェア開発、ソフトウェア運用準備･移行の各フェーズの具体的な取引条
件は個別契約書で定められる。個別契約書の具体的イメージをつかんでいただけるよう、準委任契約（要件定義作成支援業務）と請負契約（ソフトウェア開発業務）のそれぞれ一つずつ個別契約書のサンプルを付録④（169 頁参照）として掲載している。

第１編 本モデル契約および解説の改訂に際して第１章 改訂の⽅針
本モデル契約とその解説は、2008 年に出版した「ソフトウェア開発モデル契約の解説」をもとに、「第3 編 本モデル契約の条文解説」以降においては、今回改訂を加えた条文、原文を維持した条文および新規追加した条文について、前回からどのように変更、維持又は追加されているかの観点で解説を行った。
本モデル契約および解説は、改正民法への対応という観点での改訂に加え、2008 年 JEITA モデル契約以降、契約書への採用が必須となった反社会的勢力の排除条項を新たに追加したことや、近年の関連法令の改正、契約実務の蓄積、ソフトウェア開発関連の裁判例の動向等を踏まえた改訂に加え、各種オ
プション条項（完全合意、プロジェクトマネジメント義務や協力義務、プロジェクトオーナー、ステア
リングコミッティ、免責、不可抗力等に関する条項）の追記その他字句の修正を行った。
また、本モデル契約は、2008 年 JEITA モデル契約の構造を維持しており、想定している開発モデル（7 頁参照）のうち、開発プロセスについては「共通フレーム 2013」をベースとしている。

第２章 改正⺠法への対応
第１節 基本的理解
改正民法により、契約については契約目的や内容などを重視する観点での様々な改正が行われた。
JEITA としては、ソフトウェア開発の取引条件は、改正前民法下で策定された経済産業省モデル契約、
JISA モデル契約、2008 年 JEITA モデル契約等が取引慣行として広く定着し、責任やリスクの負担、見積条件、価格体系等の前提となっていることから、2008 年 JEITA モデル契約の条件が引き続き維持されることがユーザとベンダ双方にとって合理的であるとの基本的理解のもと、改正民法に係る条文について本モデル契約の改訂を行った。
なお、改正事項の中でも中心的な議論となる請負と準委任に関する JEITA の考え方は、本章第 2 節および第 3 節に記載のとおりであり、「第 2 編 本モデル契約の条文解説」以降の個別解説部分においても共通して適用されるものである。

第２節 請負について
１．請負における改正点の概要
改正民法における請負は、仕事の完成を目的とする契約形態であることに変更はないものの、担保責任の制度設計が変わったことや、出来高報酬請求が明文化されたことなど、様々な改正が行われた。
以下に主要な改正点の概要をまとめるが、実際の規定については該当の改正民法条文（改正民法第 559
条、第 562 条、第 563 条、第 564 条、第 565 条、第 566 条、第 634 条、第 637 条）を、本モデル契約の条文に影響する点の詳細解説については、第 29 条の解説（77 頁）および第 38 条の解説（94 頁）
を参照されたい。

1

表１
項目

請負における改正点の概要

改正前民法

改正民法

請負人の義務

仕事を完成させること。

請負人の担保責任完成した仕事に瑕疵がある場合は、こ完成した仕事が、種類・品質に関して

れに対する責任（以下「瑕疵担保責任」 契約の内容に適合しない場合（以下「契という。）を負う。

約不適合」という。）には、これに対する責任（以下「契約不適合責任」という。）を負う。

注文者の責任追修補、契約解除、損害賠償

履行の追完（修補、代替物・不足分引

及手段渡）、代金減額、契約解除、損害賠償

権利存続期間の目的物を引き渡した時点又は仕事が終注文者が契約不適合を知った時

起算点

了した時

権利の保全方法

起算点から 1 年以内に修補請求等の権起算点から 1 年以内に契約不適合の事

利行使を行うこと。

実を通知すること。

請負人の規定なし。ただし、判例上、一定の場

注文者の帰責事由なく仕事が完成でき出来高報酬請求合（注文者の帰責事由がある場合またない場合または仕事の完成前に契約がは仕事の完成前に契約が解除された場解除された場合、請負人は、その仕事

合、仕事の結果が可分な場合など）にの結果の可分な部分について、注文者

は報酬請求権が認められていた。

が受ける利益の割合に応じて報酬を請求できる。

２．本モデル契約における考え方（１）契約不適合の定義
本モデル契約では、第 29 条において、従来の「瑕疵」の定義を「契約不適合」でも維持した。具体的には、契約不適合の定義を「（納入物と）システム仕様書との不一致」としている。主な理由は次のとおりである。
①

ベンダが開発すべきソフトウェアの仕様は、システム仕様書において定めることとしており、ベンダの責務は当該システム仕様書に合致した納入物の開発となることは従来と変更ないため、これに対する責任対象という観点で明確である。

②

改正前民法の解釈においても、瑕疵担保責任における「瑕疵」は、当事者の合意、契約の趣旨に照らし、通常または特別に予定されていた品質・性能を欠く場合をいうと考えられていた。改正民法の「契約の内容に適合しない」との文言はこのような趣旨を明確にしたものと考えられることから、「瑕疵」と「契約不適合」の内容はほぼ同様であるといえこの変更については、実務上、開発現場に大きな影響があるものではないと考えられる。

（２）契約不適合責任の期間（権利存続期間の起算点）
本モデル契約では、従来の取引慣行どおりの権利存続期間の起算点を維持する方が合理的と考え、契約不適合責任の期間は、第 29 条において変更なく「検収完了後○ヶ月以内」としている。主な理2

由は次のとおりである1。
①

改正民法の定めに従い「注文者（ユーザ）が契約不適合を知った時」を契約不適合責任期間の起算点とする場合、取引慣行よりもベンダの責任期間が大幅に長期化する。この点、消滅時効（改正民法第 166 条）という観点では、最大で 10 年間2、ユーザの請求権は存続することになる。

このように改正民法の定めに従った契約条件とする場合、ユーザ・ベンダ共に以下のような弊害・課題が生じることが想定される。
（a）ベンダは、長期の責任期間に必要なコスト（長期化する期間分の修補対応等の人件費・賠償リスク費等）を見積で加算せねばならず、取引対価が大幅に上昇することになるため、ユーザにとってこのような長期の責任期間を設定するメリットがない。
（b）ベンダは長期の責任期間の中で、知見ある技術者を維持・拘束せねばならず、過剰な負荷となる。
（c）長期の責任期間とする以上、ベンダは、再委託先である他ベンダ等との間でも同様の期間で契約する必要があるが、当事者間の契約条件が整合しないことも想定され、実務上困難である。
②

今回の請負の契約不適合責任期間の改正は、売買のルールに合わせるものだが、従前から、売買の担保責任期間は、事業者同士の取引で採用されていない3。法改正を契機に、契約条件を民法に合わせる合理的な理由はないと考えられる。
③

民法は消費者取引にも適用されるものであり、消費者は通常、取引目的物等の検査能力が高くないこと等の理由で、改正民法の責任期間（起算点）は、発注者が契約不適合を「知った時」にしている。これに対し、ソフトウェア開発に関する企業間の取引では、ユーザは注意して検査する役割を担い、かつ、納入後にユーザが検査するプロセスを取っている。これらにより、ユーザ・ベンダ間の取引関係の合理的期間での安定化を図っている以上、現行の取引慣行どおり、検収時を起算点とすることが妥当と考えられる。

④

ユーザから、改正民法の定めに従った責任期間とすれば長期の修補対応が受けられるため、有償保守契約が不要となるのでは、との意見が提示される可能性がある。しかしその場合、上記のとおり開発契約の対価が従来よりも高額となるため、ユーザにとってメリットはない。また、例
えば、後発的にセキュリティ等の課題が発生することへの対応は契約不適合責任の範囲外であり、ユーザにとってこのような予防保守対応等の委託が必要となる以上、保守契約は必要となる。

（３）代金減額請求の位置付け
本モデル契約では、ユーザ・ベンダが従前に比べ高負荷となることや実務上の混乱が生じることを回避するため、第 29 条において代金減額請求を契約条件として定めないこととしている。主な理1 本書付録②（166 頁）「改正民法施行後の契約における売買・請負の担保責任のあり方ついて」（2018 年 5 月 22 日付、

JEITA 法務・知的財産部会 改正民法対応 TF 公表資料）においても具体的な説明があるため、併せて参照されたい。
2 改正民法第 166 条第 1 項により時効消滅するまで（権利行使することができることを知った時から 5 年、又は権利を行使することができる時から 10 年のいずれか早い時に時効消滅）。
3 改正前民法上の売買の担保責任期間は発注者が瑕疵を知ってから 1 年（改正前民法第 566 条第 3 項）であるが、引渡し（又は検収）から数年後に担保責任を追及されることはビジネスにそぐわず、商法は「引渡しから 6 か月」と短縮している（商法第 526 条）。これを受け、売買では、民法と異なる「引渡し（又は検収）時から起算し、○ヶ月」の責任期間とすることが取引慣行になっている。なお、商人間の売買における受注者の担保責任期間は、改正民法施行後も、現行「商法」どおり、引渡し時から 6 か月。

3

由は次のとおりである。
①

改正民法では、 代金の減額の幅は「不適合の程度」に応じるところ、ソフトウェア開発契約
においては、この「不適合の程度」を推し量ることが困難であり、潜在的な訴訟リスクを伴う。
この点、例えば、契約書において「不適合の程度」について具体的に規定することによって、納入物に契約不適合があった場合のリスクを定量化することは考えられるが、ソフトウェア開発においては、開発契約締結の時点で開発対象のソフトウェアの仕様自体を固めることすら難しく、「不適合の程度」を契約書に具体化することは更に困難であると思われる。仮に訴訟になった場
合には、ユーザ・ベンダ間で、代金の減額の幅の根拠となる「不適合の程度」をめぐって争いになる状況は避けられないと思われ、このような状況に陥ることは両社にとって過重な負担となるため望ましくない。

②

代金減額という方法ではなく、あくまで損害賠償として解決する方法を採用する（ユーザはベンダに対し、代金減額的な性質を有する損害賠償請求を行う）こととしても、契約不適合のある仕事の結果と報酬のバランスをとるための救済手段として支障はないと考えられる。

③

企業運営の実務として、ある契約につき既にユーザの検収が完了し、ユーザ・ベンダ間で支払処理・会計処理等が完了した後、事後的に代金減額を行うことは、ユーザ・ベンダ双方にとって実務上の負荷となることが懸念される。

（４）請負人の出来高報酬請求改正民法第 634 条は、仕事の結果が「可分」であることおよび「注文者が利益を受けること」を、請負人による出来高報酬請求の要件としているが、ソフトウェア開発取引には馴染まないと考えられるため、本モデル契約では、第 38 条においてこれらを契約の解約時における費用清算の要件として定めないこととしている。主な理由は次のとおりである。
① 「可分」であることについて、ソフトウェア開発では、検収が未完了である業務において分割
検収のような分かりやすい成果の可分化が実務的に難しい場合が多い。
②「注文者が利益を受けること」について、通常、システム開発では工程ごとに成果物が生じ、客観的には、それ自体経済的価値を有すると考えられるものの、完成していないシステムやその途中成果物について、ユーザの利益という観点での金銭評価は相当に困難であると考えられ、また、変更の協議不調によってベンダのそれまでの投下資本が無に帰するとすれば過度な不経済の結果をベンダに与えることにもなる。

第３節 準委任について
１．準委任における改正点の概要
改正民法における準委任は、仕事の完成を目的とする請負に対し、受任者が善良なる管理者の注意義務（善管注意義務）をもって委任事務（ソフトウェア開発においては、技術的支援、アドバイス、
コンサルティング等の実施を行うことを意味する）を処理することを目的とする契約形態であること

4

に変わりないが、報酬の支払い対象という観点で 2 類型（「履行割合型」と「成果報酬型4」）に分けられる改正が行われた。
成果報酬型準委任5と請負は、報酬の発生する要件（成果が生じて初めて報酬を請求できる）については類似しているが、仕事の完成義務の有無は異なる（成果報酬型準委任は仕事の完成義務を負わないが、請負は仕事の完成義務を負う）。
以下に当該 2 類型の概要をまとめるが、実際の規定については該当の改正民法条文（改正民法第 648
条、第 648 条の 2）を、本モデル契約の条文に影響する個別の詳細解説については、第 14 条の解説（39頁）および第 19 条の解説（51 頁）を参照されたい。
表２
項目

改正前民法

準委任の類型受任者の義務準委任における改正点の概要
改正民法

－

履行割合型

成果報酬型

善良な管理者の注意をもって事務処理を行うこと。
なお、請負と異なり「仕事の完成」義務は無い。

報酬の支払い対象

委任事務の提供委任事務の結果、達成された成果

履行の中途で終了した受任者（ベンダ）の帰責受任者（ベンダ）の帰責

請負の出来高報酬規定

場合の報酬の取扱い

事由なく履行の中途で事由の有無を問わず、委（前記請負の解説（1

終了した場合、既にした任事務の履行ができな頁）の表１「請負人の出履行の割合に応じて報くなった場合又は履行

来高報酬」欄の記載参酬を請求できる。

の中途で終了した場合、 照）が準用される。
既にした履行の割合に応じて報酬を請求できる。

代表例

弁護士、コンサルタント等の専門家の業務。

弁護士の成功報酬

なお、委託料の決め方は、定額払や実績払（月額

不動産仲介業者の報酬払、時間払等）がある。
２．本モデル契約における考え方
本モデル契約では、「要件定義作成支援業務」（第 14 条～第 18 条）および「外部設計書作成（支援）業務」（第 19 条～第 23 条）において準委任型契約を提示している。これら条項における準委任は「履行割合型」を意味することを前提としている（以下、本モデル契約および解説の記載において、「準委任」とあるものは、共通して「履行割合型」を意味する。）。本モデル契約が想定するソフト
ウェア開発取引が、「成果報酬型」になじまないと考える主な理由は次のとおりである。

民法（債権関係）部会資料 46 では、「成果完成型」という用語が用いられているが、請負（「仕事の完成」義務を負う）との混同を避けるため、本書では「成果報酬型」とした。
5 民法（債権関係）部会資料 46、70 頁「成果完成型の委任契約は、受任者がその成果を達成する義務を負っていない点で請負契約とは異なるが、役務の提供そのものに対してではなく、その結果達成された成果に対して報酬が支払われる点で、請負の報酬に類似している。」
4

5

①

本モデル契約の準委任型の「要件定義作成支援業務」および「外部設計書作成（支援）業務」
におけるベンダの役割とは、ユーザに対して、個別契約で約束した一定の技術的支援を行うというものであり、要件定義や外部設計を完成させる主体は、ユーザである。したがって、ベンダが何らか作成したドキュメントを提出するとしても、それは参考資料等に過ぎない。ベンダの履行の結果として何らかの成果（一例として、弁護士が依頼人の弁護を行った結果としての勝訴判決）が得られる取引ではない。ベンダが行うのは支援作業であり、ベンダが要件定義書や外部設計書を作成・納品する取引ではない以上、「要件定義書の完成」や「外部設計書の完成」等をそもそも契約の目的とするものではない。

②

成果報酬型におけるユーザへの出来高報酬請求の要件は、成果が「可分」であること、ユーザが「利益を受ける」ことであるが、成果の内容が契約締結の時点で不明確である上記業務においては、個別契約の契約段階で、成果が可分になるような条件をユーザ・ベンダ間で合意することは非常に困難である。

6

第２編 本モデル契約の前提となる開発プロセス等
１．想定している開発モデル
契約当事者

対等の交渉力のあるユーザとベンダを想定。
（例）ユーザ：民間大手企業、ベンダ：情報サービス企業

開発モデル

ウォーターフォールモデル

対象システム重要インフラ、企業基幹システムの受託開発（一部企画を含む）

プ ロ セ ス

共通フレーム 2013 による標準化されたシステムの要件定義段階、開発段階。
特定のベンダに要件定義段階と開発段階の双方を委託する形態に加え、マルチベン
ダ形態、工程により異なるベンダに発注する形態も加味。

２．前提とする開発プロセス
本モデル契約は、図 1 の開発プロセスを踏襲している。
図１

前提とする開発プロセス6

モデル契約でのフェーズ分け

共通フレーム2013での主たる作業⼀覧
企画プロセス企

システム化の⽅向性

システム化構想の⽴案

画システム化計画

システム化計画の⽴案

・

要

要件定義プロセス
プロセス開始の準備
利害関係者の識別
要件の識別
要件の評価
要件の合意
要件の記録

件
定
義

要件定義

段
階

システム開発プロセス
システム開発プロセス開始の準備
システム要件定義

システム設計（システム外部設計）
システム⽅式設計（システム内部設計）

システム⽅式設計
ソフトウェア実装プロセス開始の準備
ソフトウェア要件定義

開
発
段
階

ソフトウェア設計

ソフトウェア⽅式設計
ソフトウェア詳細設計

プログラミング

ソフトウェア構築
ソフトウェア結合

ソフトウェアテスト

ソフトウェア適格性確認テスト
ソフトウェア導⼊
ソフトウェア受⼊れ⽀援システム結合システム結合システムテストシステム適格性確認テスト

導⼊・受⼊⽀援システム導⼊システム受⼊れ⽀援
運⽤プロセス

運
⽤

運⽤の準備
運⽤テスト

運⽤テスト及びサービスの提供開始
業務及びシステムの移⾏

段
階
6

運⽤

システム運⽤（~略）『2007 年経済産業省報告書』30 頁および『共通フレーム 2013』55 頁～69 頁を参考に作成した。

7

３．「要件定義」以前の「システム化の方向性」、「システム化計画」の重要性
本モデル契約は、「要件定義」から「運用テスト」までの工程におけるユーザとベンダ間の取引を対象としているが、「要件定義」以前の「システム化の方向性」と「システム化計画」の工程に関する取引は対象としていない。
この 2 つの工程は、ユーザの経営戦略･事業戦略およびこれらを踏まえた IT 戦略を明確にし、システム化目的、必要性、課題、実現する機能範囲あるいは投資効果評価や実行計画などシステムおよび
プロジェクトの大枠についてユーザの利害関係者（経営層、業務部門、情報システム部門等）の間で合意を形成していく工程、ユーザが主体となって進めていくものである。その際、ユーザ自らだけでは、これらの工程を進めるだけのノウハウ等が不足している場合には、IT コンサルタント等の力を活用することがある。すなわち、「システム化の方向性」と「システム化計画」の工程では、ソフトウェ
ア開発としての契約とは別のコンサルティング等に関する契約が活用されることが多いとされている。
このことから、ソフトウェア開発を対象とする本モデル契約ではこれらの工程は対象とはしていない。
「システム化の方向性」と「システム化計画」の 2 つの工程は、本モデル契約に基づくソフトウェ
ア開発が成功するために非常に重要な工程であるため、システム化に当り、事業のレベルでは経営層
が、当該事業を実行する業務レベルでは業務部門が、当該業務を実現するシステムのレベルでは情報システム部門がきっちりスクラムを組んで、システム化の入口である「システム化の方向性」と「システム化計画」に取り組み、ユーザにおける多くの利害関係者間で合意を取り付けておくことが必要である。これらの合意がない、あるいは合意があっても合意内容がベンダに正しく伝わらないと、「要件定義」以降の作業の段階で混乱を生じかねず、せっかくの本モデル契約も水泡に帰すことになる。
４. 本モデル契約の構造
本モデル契約の構造を図２に示す。
図２

モデル契約の構造

8本モデル契約は基本契約の形態をとっており、ソフトウェアライフサイクルプロセスのうち「要件定義」から「運用テスト」までの工程を対象としている。それらの工程を、次の 4 つのフェーズに分けて、それぞれのフェーズにおいてユーザがベンダに委託する業務について、それぞれ見積りを行った上でユーザとベンダ間で個別契約書を締結するという多段階契約の構造をとっている。
フェーズ
要件定義フェーズ

業務と契約類型✓ 対象工程：「要件定義」✓ ユーザからベンダへの委託業務：「要件定義作成支援業務」✓ 契約類型：準委任

外部設計フェーズ

✓ 対象工程：「システム設計（システム外部設計）」（以下、単に「外部設計」という。）✓ ユーザからベンダへの委託業務：「外部設計書作成（支援）業務」✓ 契約類型：準委任または請負の選択

ソフトウェア開発✓ 対象工程フェーズ①外部設計フェーズが準委任の場合⇒「システム方式設計（システム内部設計）」～「システム結合」②外部設計フェーズが請負の場合⇒「システム方式設計（システム内部設計）」～「システム結合」、「システムテスト」（※）✓ ユーザからベンダへの委託業務：「ソフトウェア開発業務」✓ 契約類型：請負

ソフトウェア運用✓ 対象工程準備・移行①外部設計フェーズが準委任の場合

フェーズ⇒「システムテスト」、「導入・受入支援」～「運用テスト」②外部設計フェーズが請負の場合⇒「導入･受入支援」～「運用テスト」✓ ユーザからベンダへの委託業務：「ソフトウェア運用準備･移行支援業務」✓ 契約類型：準委任※ システムテストは、外部設計を行った当事者が主体となり実施する。よって、外部設計が準委任契約の場合は、「ソフトウェア運用準備・移行フェーズ」の中でユーザが主体となり実施し、請負契約の場合は、「ソフトウェア開発フェーズ」の中でベンダが主体となり実施する。
５．作業主体と契約類型（準委任と請負）について
開発プロセス

内容

主体

システム化の方向性とユーザの経営戦略･事業戦略およびこれらを踏まえた IT 戦

ユーザシステム化計画

略を明確にし、システム化の目的、必要性、課題、実現する
機能範囲あるいは投資効果評価や実行計画などシステムおよびプロジェクトの大枠についてユーザの利害関係者（経営層、エンドユーザ部門等）の間で合意を形成していく工程で
ある。
9

要件定義

ユーザ自身がシステムで実現しようとする業務（内容、運用

ユーザ

ルール、処理手順、関連部門の権限、決裁手続き等々）を分
析、整理し、システム化する範囲と当該業務を遂行する上で必要となる機能要件ならびに信頼性、セキュリティ、移行･運用方法などの非機能要件を明らかにし、ユーザの利害関係者の合意を取り付けていく工程である。
外部設計

ユーザが日常の業務において使うことになる画面や帳票などのインタフェースを設計し、決定する工程であるが、この工程ではユーザ主体、ベンダ主体のいずれもあり得る。
ソフトウェアで実現するユーザ業務の固有性が強く、そユーザ

こで使用される画面、帳票等にもユーザの固有性が現れるような場合など。
ユーザの固有事情に比較的左右されないような場合、長ベンダ期の取引関係等からベンダにおいてユーザの固有性を把握できているような場合など
システム方式設計

機能要件等のハードウェア、ソフトウェア等による実現方式（システム内部設計）の設計、処理の内部ロジックの設計など、開発すべきソフトからプログラミング

ウェアの詳細を設計し、プログラミングしていく工程であベンダる。
ソフトウェアテストか「ソフトウェアテスト」から「運用テスト」までの各種テス

ユーザ／ら運用テストトは、上記図２のとおり対応する設計どおりであるか確認すベンダ

るものとされている。
（１）ユーザが作業主体の場合「要件定義」、「外部設計」、「システムテスト」、「運用テスト」における作業がユーザ主体というのは、要件定義ならユーザ自身が、システムで実現する業務を分析･整理し、必要な機能を明確にし、利害関係者の合意を得るという作業自体を行うことである。その過程で、ユーザがベンダに期待することは、ユーザには欠けている、あるいは不足している技術的知識、ノウハウなどを自身の作業の過程で補充してくれることであろうと思われる。
すなわち、この場合にユーザがベンダに頼んでいること（契約の主題）は、ユーザが主体となって行う作業が技術的に適切に進むよう必要な技術的なアドバイス、指導などの支援を行うことと考えられる。
このような支援を依頼する業務の契約類型は、準委任契約となる。
（２）ベンダが作業主体の場合「外部設計」から「システムテスト」までの作業をベンダが主体となるのは、まさしくそれらの作業をベンダ自身が行うことである。
そこでユーザがベンダに頼んでいること（契約の主題）は、「システムテスト」まで終わったソフ
トウェアを作り上げることである。
このように何かを完成させることを依頼する業務の契約類型は、請負契約となる。

10

第 3 編 本モデル契約の条⽂解説
委託者：ユーザ（以下「甲」という。）と受託者：ベンダ（以下「乙」という。）とは、コンピュータ
ソフトウェアの開発に係る業務の委託に関して、次のとおりこの契約（以下「本契約」という。）を締結し、その証として本書2通を作成し、甲乙記名押印のうえ各1通を保有するものとする。
年

月

日

（甲）

（乙）

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、前文に関連する実務は現在においても同様と考えられるため、本条に変更はない。なお、和暦表記を削除した。
【条文解説】
１．趣旨（１）前文
契約書の条文の前に記載する文章を「前文」といい、契約当事者、契約の位置付けを明らかにする。
（２）契約当事者
甲（ユーザ）が委託者、乙（ベンダ）が受託者と記述し、契約の当事者を明らかにする。
なお、共通フレーム 20137では、ユーザは｢システム開発に関する契約条項に則り、システム開発
を直接に取得又は調達する組織（企業そのもの及び企業における部・課等の部門）」として「取得者」、ベンダは｢システム開発を直接に取得者に供給する組織（企業そのもの及び企業における部・課等の部門）｣として「供給者」と定めている。
（３）契約書の位置付け
本契約が「コンピュータソフトウェアの開発に係る業務の委託に関して」の契約書であることを定め、ユーザとベンダがこの契約書に定められる事項に合意してこの契約書を締結することを宣言している。
【適用ガイド】１．契約当事者の名称
契約当事者の名称は、登記されている正式名称を記述し、略称や通称を使用しない。各当事者を｢甲｣｢乙｣と定義しているが、これに代えて各当事者の略称や通称を使って定義してもよい。その場合は、以降の条文で甲乙としている部分をここで定義した名称に置き換えることとなる。
例えば、JEITA を甲とする場合は、｢委託者：一般社団法人 電子情報技術産業協会（以下｢甲」という。）｣となるが、甲の代わりに JEITA という略称を使う場合は「委託者：一般社団法人 電子情
報技術産業協会（以下「JEITA」という。）」となり、以降の条文中で甲となっているところを JEITAと書き換えて契約書を作成する。
7『共通フレーム 2013』20 頁

11

２．「本契約」
ここでは「コンピュータソフトウェアの開発に係る業務の委託に関しての契約」を「本契約」と定義している。委託される業務内容に合わせてこの表現を変更することになる。また、以降の条文において「本契約」とは、本モデル契約を指す。
３．記名押印
記名押印については、署名に代えることも可能である（以降の条文においても同じ）。

第１章 総則（契約の目的）第1条

本契約は、甲が、甲の○○○システムのコンピュータソフトウェアの開発にかかる業務（以下「本件業務」という。）を乙に委託し、乙はこれを受託することに関する基本的な契約事項を定めることを目的とする。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨（１）契約対象
契約の対象を明らかにすることにより、取引対象がソフトウェアの開発であることを明らかにしている。
（２）目的条項第 2 条以下の条文の解釈に際しては、本規定に定めた目的に沿うよう解釈され、本契約の一般的な解釈基準として機能することを意図する。
２．条文の背景（１）対象ソフトウェア
本契約が、特定されたコンピュータソフトウェアの開発に関する基本契約であり、ユーザが今後開発するであろうすべてのコンピュータソフトウェアの開発に適用されるものではないことを明らかにしている。
実際に開発するソフトウェアの機能範囲等は「本件業務」を通じて具体化するものであり、基本契約では規定しない。
（２）「本件業務」
甲の○○○システムのコンピュータソフトウェアの開発にかかる業務を「本件業務」と定義している。以下の条文で「本件業務」とされている場合は、この委託された業務を指すものである

12

ことを示している。
【適用ガイド】１．委託業務の名称
対象ソフトウェアの名称「○○○システム」については、当該契約の対象となるコンピュータソ
フトウェアを特定できるように定める。
図３

システムの概念図

図３のような構成のシステムを開発する場合、本契約の対象が全体の場合は「○○○重要基幹システム」とし、構成する一部のサブシステムの場合は例えば、「○○○重要基幹システム

Ａサブシ

ステム」と記載することで、ユーザとベンダが共通して認識でき、対象となるコンピュータソフト
ウェアが特定できる。
（定義）
第2条

本契約で用いる用語の定義は、次のとおりとする。

①本件ソフトウェア
本契約及び個別契約に基づき開発されるソフトウェア②要件定義書本件ソフトウェアの機能要件（甲の要求を満足するために、ソフトウェアが実現しなければな
らない機能に係る要件。システム機能及びデータにより定義される。
）及び非機能要件（機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない
品質要件、技術要件、移行要件、運用要件及び付帯作業等から成り、それぞれに対する目標値及び具体的事項により定義される。）をとりまとめた文書

13

③外部設計書
要件定義書に基づき本件ソフトウェアの画面、帳票などのユーザインタフェース、他システムとの通信やデータ入出力等のインタフェースなど、本件ソフトウェアの入出力全般に関する仕様を定めた設計書④システム仕様書
要件定義書及び外部設計書（但し、要件定義書及び外部設計書に齟齬がある場合は、外部設計書の定めが要件定義書に優先してシステム仕様書を構成するものとする。）⑤中間資料
本件ソフトウェアの開発過程で生成したもので、本件ソフトウェア、システム仕様書及び検査仕様書に該当しないすべてのもの⑥第三者ソフトウェア
第三者が権利を有するソフトウェア（但し、FOSS を除く。）⑦FOSS
フリーソフトウェア及びオープンソースソフトウェア⑧要件定義
共通フレーム 2013 の利害関係者の識別、要件の識別、要件の評価、要件の合意、要件の記録に相当するもの⑨外部設計
共通フレーム 2013 のシステム要件定義プロセスに相当するもの⑩内部設計
共通フレーム 2013 のシステム方式設計プロセスに相当するもの⑪システム結合
共通フレーム 2013 のシステム結合プロセスに相当するもの⑫システムテスト
共通フレーム 2013 のシステム適格性確認テストプロセスに相当するもの⑬導入・受入支援
共通フレーム 2013 のソフトウェア導入プロセス、ソフトウェア受け入れ支援プロセスに相当するもの⑭運用テスト
共通フレーム 2013 の運用テスト及びサービスの提供開始、業務及びシステムの移行に相当するもの【2008 年 JEITA モデル契約との相違】
近年の「共通フレーム 2013」における用語の定義に対応するため、（定義）の第 8 号から第 14 号の内容を「共通フレーム 2013」の引用に変更した。
【条文解説】
１．定義
本契約における重要な用語について定義し明確化している。

14

２．用語
契約当事者および本契約に関係する者（責任者、主任担当者、業務従事者）が契約内容を把握す
るうえで、重要な用語の認識に齟齬がないようにするため、用語を定義する。
【適用ガイド】
１．用語定義の必要性
本契約で使用されている用語は原則、共通フレーム 2013 に準拠した用語としているが、共通フ
レーム 2013 と異なる用語を使用する場合は、ここで追加または修正して定義する。実契約の場においては、ユーザとベンダで用語がかなり異なるので、共通認識できる用語を定義するようにし、その解説としてはユーザとベンダの双方が理解できるようにする。
また、ユーザとベンダのいずれかまたは双方が共通フレーム 2013 の用語を理解していない場合には、共通フレーム 2013 に準拠した用語についても合意の内容に齟齬が生じないように定義する。
２．定義について共通フレーム 2013 では「『共通の言葉』で話すための『共通の物差し』を用意することが必要である」8とされている。本契約での定義は、サンプルであるので、『共通の物差し』としてユーザとベンダの認識が合うように定義をすることが必要であるので、このまま利用するのもよいが、ユーザとベンダの認識に齟齬が無いようにひとつひとつの定義を確認し、必要に応じて用語の定義を修正して本条を用いていただきたい。
（適用範囲・完全合意）
第3条

本件業務は、第 14 条の要件定義作成支援業務、第 19 条の外部設計書作成支援業務（第 19条において B 案を選択する場合は「外部設計書作成業務」）、第 24 条のソフトウェア開発業務、第30 条のソフトウェア運用準備･移行支援業務の全部又は一部から構成され、本件業務の個々の業務（以下｢個別業務｣という。）には本契約のほか、次条に基づき締結される当該個別業務に関する契約（以下「個別契約」という。）が適用されるものとする。
2.

甲及び乙は、個別契約において本契約の一部の適用を排除し、又は本契約と異なる事項を定めることができる。この場合、個別契約の条項が本契約に優先するものとする。また、本契約及び個別契約が当該個別業務の取引に関する合意事項のすべてであり、かかる合意事項の変更は、第 33 条（本契約及び個別契約内容の変更）に従ってのみ行うことができるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。なお、本条第 2 項の内容に鑑み、タイトルに「完全合意」を追加した。
【条文解説】
１．趣旨
8『共通フレーム 2013』9 頁

15

（１）多段階契約方式
作業フェーズごとに個別契約を締結するという多段階契約方式を採用することを規定している。
（２）個別契約の優先
本契約と個別契約で異なる定めをした場合は、個別契約に定められる内容が優先されることになる。
（３）完全合意
本契約および個別契約がすべてであり、それ以外のものについて合意されていたものは、当該個別業務の取引には関係しないことを定めている。
ベンダからは、基本契約および個別契約の締結前にソフトウェアの説明資料、カタログ、パンフレット、提案書等の多種多様な資料がユーザに提示される。場合によっては念書、差し入れ書が提出されたり、覚書などが結ばれているケースがある。そのような場合においても、本条があると、本契約および個別契約がユーザ・ベンダ間の当該個別業務の取引に関する合意のすべてであり（完全合意）、本契約および個別契約において規定されていない内容については、当事者間の契約内容とはならないものと考えられる。
【適用ガイド】１．完全合意完全合意の条文パターンには、次の 2 通りがある。
（１）本条のように契約締結前の合意は無効とし、本契約と個別契約に定められるものがすべてであると定めるもの。
（２）次の条文例のように契約締結前に合意した内容も有効とし、本契約と個別契約において異なる定めをしたときは本契約と個別契約が優先されると定めるもの。
2.

甲及び乙は、個別契約において本契約の一部の適用を排除し、又は本契約と異なる事項を定めることができ、この場合において、当該個別契約の定めは本契約に優先するものとする。なお、本契約締結以前に甲、乙間でなされた協議内容、合意事項、又は一方当事者から相手方に提供された各種資料、申入れ等と本契約の内容とが相違する場合は、本契約が優先するものとする。また、本契約及び個別契約が当該個別業務の取引に関する合意事項のすべてであり、かかる合意事項の変更は、第 33 条（本契約及び個別契約内
容の変更）に従ってのみ行うことができるものとする。

また、次の条文例のように、完全合意条項として独立した形で条文を置く例も多くあり、また、
上記条文パターンの内容に加え、本契約や個別契約の合意内容と矛盾するような発注書等別途提示した条件を無効とする旨や、本契約や個別契約の締結権限者が署名や記名押印した契約のみ有効とする旨など、完全合意条項の条件をより厳格に定める案も採り得る。
（完全合意）
第○条

甲及び乙は、個別契約において本契約の一部の適用を排除し、又は本契約と異なる事項を定めることができる。この場合、個別契約の条項が本契約に優先するものとする。また、本契約及び個別契約がそれぞれの取引の対象事項に関する合意事項のすべて

16

であり、それ以前になされた明示・黙示の合意に優先し、かかる合意事項の変更は、第33 条（本契約及び個別契約内容の変更）又は第 37 条（変更管理手続）に従ってのみ行
うことができるものとする。
2.

甲又は乙が、本契約又は第 4 条に定める個別契約とは異なる発注書等の条件を提示した場合であっても、相手方がこれを当該本契約又は当該個別契約として合意しない限り、適用されないものとする。

3.

本契約及び個別契約並びにこれらの変更契約は、両当事者の契約締結権限のある者が記名押印した場合に限り、適用されるものとする。

２．優先関係
本条では、個別契約に定められた内容が基本契約と異なる場合は、個別契約の内容が優先されることを定めている。そこで、基本契約において不十分であった内容あるいは基本契約と異なる条件を定めたい場合等は、個別契約締結の段階で十分交渉し、個別契約にて適宜反映する。
３．契約締結より前の合意事項
ユーザとベンダ間では、基本契約／個別契約の締結前に多種多様な合意事項がなされることがある。このような商談獲得活動を経て正式な基本契約を締結するのが、一般的な商談パターンである。
そこで、基本契約および個別契約締結後、ユーザ・ベンダ間における合意事項の解釈に起因するトラブルを防止すべく、本条は、基本契約および個別契約がすべてであり、それ以前のすべての合
意事項は効力を有しないこととしている。そのため、契約締結前の合意事項を締結後においても効力を持たせるには、かかる合意事項を基本契約あるいは個別契約に反映しておかなければならない。
そこで、従前の合意事項が基本契約あるいは個別契約にすべて反映されているか確認し、基本契約あるいは個別契約に当該合意事項を定めるか、または当該合意事項を定める覚書等の書面を引用するようにする。
（個別契約）
第４条

甲及び乙は、個別業務に着手する前に、甲から乙に提示された提案依頼書（RFP）及び乙から甲に提案した提案書、見積書を基礎として、当該個別業務について次の各号のうち必要となる取引条件を定め、個別契約を締結する。
①具体的作業内容（範囲、仕様等）②契約類型（請負・準委任）③作業期間、作業工数（作業量）又は納期④作業スケジュール⑤甲・乙の役割分担（第 8 条で定める作業責任分担の詳細）⑥連絡協議会の運営に関する事項⑦甲が乙に提供する情報、資料、機器、設備等（以下「資料等」という。）⑧作業環境⑨乙が甲の委託に基づき作成し納入すべき物件（以下「納入物」という。）の明細及び納入場所⑩委託料及びその支払方法⑪検査又は確認に関する事項

17

⑫その他個別業務遂行に必要な事項
2.

甲及び乙は、作業スケジュールの進捗に支障を来すことのないように各個別契約の締結交渉に着手し、可能な限り早期に合意に至ることのできるよう双方誠実に協議するものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨（１）個別契約の締結
本契約は「基本契約」として、複数の個別契約に共通する条件、基本となる条件を定めており、ベンダが行う作業内容、ユーザが行うべき作業内容およびそれらのスケジュールならびにユーザが支払うべき代金などの具体的な債務内容は個別契約において定められることになる。本条は、個別業務に関する具体的な債務内容を特定する個別契約の必要性および当該特定のために個別契約において定めるべき事項を明確にするものである。
（２）個別契約規定の各項①具体的作業内容（範囲、仕様等）
本契約における各個別業務は、上流工程である要件定義作成支援業務・外部設計書作成（支援）業
務から下流工程であるソフトウェア運用準備・移行支援業務という形式で大まかな枠を設定しているにすぎないため、個別契約において、各個別業務の「対象作業範囲の明細」を確定することが必要となる。
なお、このような構成となっているため、各個別業務における対象作業範囲については、各ベンダが個々のプロジェクトの特性に応じて、流動的に設定することが可能である。そこで、例えば、大規模かつ複雑なプロジェクトで、構築サービスのための適正な「仕様」を早い段階で十分に確定することが困
難なケースでは、構築サービスのインプットとなるシステム仕様書を作成する「要件定義作成支
援業務・外部設計書作成（支援）業務」の工程を、通常よりも広く設定して、十分な仕様書を作成してから、「ソフトウェア開発業務」を行うことなどフレキシビリティを持たせることで、仕様の不確定に起因するリスクをヘッジすることが可能となる。
②契約類型（請負・準委任）
本契約では、各個別業務の契約類型を表３のとおりとしている。
表３

個別業務と契約類型

個別業務

契約類型

要件定義作成支援業務

準委任

外部設計書作成（支援）業務

準委任または請負の選択

ソフトウェア開発業務

請負

ソフトウェア運用準備･移行支援業務

準委任

表３のとおり、外部設計書作成（支援）業務のように個別業務の契約類型を選択する場合には、どちら

18

の契約類型で行うかを当該個別契約において明示する。その他の個別業務にように、その契約類型が、本契約上定められている場合は、本号は不要となる。
③作業期間、作業工数（作業量）または納期
個別業務が請負による場合、当該契約は仕事の完成を目的とするものであるが、｢仕事の完成｣条件として完成物を単に「ソフトウェア」とのみ個別契約に規定しただけでは、ベンダは何をどこに何時までに納入すべきかが分からず、ベンダの責任範囲が不明確となり、ユーザ･ベンダ間でトラブルの原因となる。
そこで通常、納入物の明細、納期（納入期日）、納入場所が個別契約に定められる。個別業務が準委任9による場合は、何らかの成果物を出すことを約束するものではないので、納入物、納期等は定めず、個別業務の内容を特定した上で、当該個別業務を実施する期間（作業期間）または作業工数（作業量）を定め、その範囲内で、ユーザが行う業務に対し、役務を提供する。
④作業スケジュール
作業スケジュールは、請負契約の 4 大要素の「納期」に係わる重要な事項であるから、ユーザとベンダのコンセンサスを反映した適正な作業スケジュールを作成することが必要である。
なお、ソフトウェア開発は、手戻りの最小化を図るために、各種のアウトプットについて、ユーザの承認を得ながら先へ進むという形態が理想である。そのため、各個別業務において検収を受けるだけでなく、各個別業務の過程において作成されるアウトプットについても、「中間資料のユーザによる承認」（第 35条）という形でユーザの承認を得ながら開発作業を行うべきである。開発作業にとって重要なアウトプッ
トについては、その確認手続きの時期を作業スケジュールに組み込むことが望ましい。
⑤甲・乙の役割分担（第 8 条で定める作業責任分担の詳細）
ソフトウェア開発取引においては、ユーザとベンダのどちらがいかなる作業を分担するか、という点について、ユーザとベンダのコンセンサスが一致していないことも多いため、ユーザとベンダの役割分担を明確化することが必要である。その際、ソフトウェア開発作業の性格を考慮して、各個別業務についてユー
ザとベンタの作業分担が適正となるよう決定すべきである。
⑥連絡協議会の運営に関する事項
連絡協議会は、各個別業務内容により、運営方法や頻度、メンバーなどが異なることから、個別契約において定めるものとする。
⑦甲が乙に提供する情報、資料、機器、設備等
ユーザから提供される情報、資料、機器、設備等は、実際のソフトウェア開発作業にとって必要不可
欠であるとともに、ユーザにとって重要な資産であり、完成後のソフトウェアあるいはユーザの日常業務の運用にとっても必要不可欠なものである。そのため、貸借関係を明確にし、賃貸対象物件を特定することが必要である。
⑧作業環境
ソフトウェア開発作業をユーザとベンタのどちらの作業場所において行うのか、その作業場所に関する費用（事務所賃貸料、旅費、宿泊費等）はユーザとベンダのどちらの負担となるのか、等については明確に取り決めておくことが必要である。請負契約の場合は、ベンダの事業所で作業を行っているが、準委任契約の場合やユーザの重要な情報を取り扱う（顧客情報等）場合、ユーザの情報システム環境を使う場合などには、ユーザの指定する場所となるケースが多く見受けられる。
⑨乙が甲の委託に基づき作成し納入すべき物件（以下「納入物」という。）の明細および納入場所
上記③においても記載したとおり、個別業務が請負による場合には、個別業務の内容により、
9

準委任の解説については 4 頁を参照されたい。

19

成果物たる納入物の明細も異なるし、納入場所も異なるので、かかる明細とその納入場所を個
別契約において定める。
しかしながら、準委任による場合には、成果物としての納入物を定めることはない。ただし、準委任による個別業務であっても、その過程で、何らかのドキュメントがベンダからユーザに提出されることがある。もし、かかるドキュメントを個別契約に定める必要が生じた場合には、｢提供資料｣「参考資料」など、請負における｢成果物｣とは明確に異なる用語を用いるべきである。
⑩委託料およびその支払方法
各個別業務の内容により、委託料は異なるし、支払方法も異なるので、個別契約において定める。場合によっては、支払方法については、統一できる場合もあるが、その場合は、次の第 5条を修正し、個別契約では本号を省略できることになる。
⑪検査または確認に関する事項
本号は、各個別業務終了時の確認期間（第 18 条参照）あるいは本件ソフトウェアの検査期間（第 28条参照）などを個別契約に定めることを示す。
⑫その他個別業務遂行に必要な事項①から⑫の各号以外の事項であっても、ユーザとベンダ間で、取り決める必要のある事項がある場合には個別契約で定めるとしている。例えば、納入物の権利帰属について基本契約にて定められている内容を変更する必要がある場合、個別契約において、その旨の規定を追加することが必要であるので、①から⑫の各号以外の事項でも個別契約に定めることができるとしている。
【適用ガイド】１．個別契約の構成
個別契約の締結に際しては、第 4 条第 1 項に定める各取引条件をユーザ･ベンダ間で協議しておくことが必要である。
個別契約書のサンプルは本書付録④（169 頁）を参照されたい。なお、このサンプルでは役割分担等の詳細は別表に記載される構成となっている。この別表は個別契約書に袋とじし、一体としておくことが原則である。もし、例外的に別々とする場合には、当該別表が個別契約の別表であることが明らかになるよう別表の表紙に「〇年〇月〇日付要件定義作成支援業務個別契約第〇項の別表である」などと記述しておかなければならない。また、当該別表の表紙には、ユーザ･ベンダ双方の合意を明らかにするために双方の記名押印も必要となる。
２．準委任契約10における委託料の決め方
要件定義作成支援業務のような準委任契約によるサービスの場合、委託料の決め方には大別して定額払と実績払の 2 種類がある。
（１）定額払例えば、金 1,000 万円というようにサービスの対価の総額をあらかじめ定めておく決め方である。
なお、ユーザが主体となって行う作業に対して技術支援を行うというサービスの場合、ユーザの作業が長引くと、それだけベンダの支援業務の量が増えることになる。そこで、定額払による10

準委任の解説については 4 頁を参照されたい。

20

場合には、当該金額に対応した業務量により制限を設けることが一般的になされる。例えば、作業期間あるいは工数などの作業量を定めるなどである。
（２）実績払例えば、時間当りの技術支援料を定め、実際に行った技術支援の時間数に当該技術支援料を乗ずるという決め方である。
なお、実績払方式の場合、一般的には月単位で実績報告するとともに、業務終了時には業務終了報告書にそれまでの実績全体を記載し、ユーザとベンダ双方で確認することが行われる。
（委託料及びその支払方法）
第5条

甲は乙に対し、本件業務の対価として、各個別契約で定めた委託料を当該個別契約で定めた方法で支払う。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
委託料とその支払方法は、個別契約で定める。
２．条文の背景
本契約では、多段階契約の考え方を採用していることから、委託料は個別契約で定めることになる。また、支払方法を各フェーズで変える場合もあることから、個別契約で定めることする。
【適用ガイド】１．基本契約に支払方法を定める場合
基本契約にて支払方法をあらかじめ定めるときは、第 1 項を次のように修正する。
（委託料及びその支払方法）
第５条

甲は乙に対し、本件業務の対価として、各個別契約で定めた委託料を以下に定める支払方法で支払う。
支払方法：○○○○○○○○○○○○○○○○
２．フェーズ別見積り
多段階契約においては、全体の予算管理に留意しつつも、各段階においてフェーズ別見積りをすることにより、各フェーズが適正な委託料にて委託されるため、無理な作業による後戻りなどを防止できる。ユーザは後工程に費用面のしわ寄せが起こり、重要な開発が完遂できないことにならないように、全体の予算管理にも留意が必要である。
３．支払遅延21

支払期日までに支払がないと、「利息」が発生し、これを「遅延損害金」とする。「遅延損害金」の「利率」の合意がない場合には、民事法定利率（改正民法施行時は年 3％であるが、3 年ごとに見直される。）が適用される（改正民法第 404 条）。
「利息の利率」については、利息制限法、国税通則法による延滞税（年 14.6％の利率）、等を参考にされたい。ちなみに、「政府契約の支払遅延に対する遅延利息の率」については、財務省告示に定められている。なお、本条に支払遅延の条文を追加する場合は次のように 2 項を追加する。
2. 甲が、本契約及び個別契約により生じる債務の弁済を怠ったときは、乙に対し支払期日の翌日から完済の日まで年利○％の割合による遅延損害金を支払うものとする。

（作業期間又は納期）
第６条

各個別業務の作業期間、作業工数（作業量）又は納期は、当該個別業務に係る当該個別契約で定める。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
各フェーズを多段階契約で遂行することを前提としているということで、各個別契約で作業期間、作業工数（作業量）、納期を定める。
２．条文の背景
本契約においては、作業期間、作業工数または納期について、その具体的内容は規定しない。要件定義も行っていないし、また全体工程の試算程度しかわからない基本契約締結段階ではこれらの管理について合意できるものではない。よって、多段階契約により、フェーズごとに見積りを実施した上で、これらの事項を個別契約で定めることとする。
【適用ガイド】１．契約類型（請負／準委任）に応じた定め
請負型の場合は仕事の完成が必要なので、個別契約には納期や納入物を定め、準委任型の場合は仕事の完成責任はない11ので、個別契約には委託された業務の内容やそれを行う作業期間または作業工数を定める。
（再委託）第7条

乙は、乙の責任において、各個別業務の全部又は一部を第三者（甲が指定する再委託先も含む。）に再委託することができる。但し、乙は、甲が要請した場合、再委託先の名称、住所等を甲に報告するものとし、甲において当該第三者に再委託することが不適切となる合理的な理由が存する
11

準委任の解説については 4 頁を参照されたい。

22

場合、甲は乙に、書面により、その理由を通知することにより、当該第三者に対する再委託の中止を請求することができる。
2.

前項但書により、甲から再委託の中止の請求を乙が受けた場合は、作業期間若しくは納期又は委託料等の個別契約の内容の変更について、第 33 条（本契約及び個別契約内容の変更）によるものとする。また、当該請求に従い、乙が当該個別業務に係る当該第三者との再委託に関する契約を解除した場合（但し、前項の合理的な理由が乙と当該第三者との再委託に関する契約の解除事由に該当する場合を除く。）、当該解除に伴い当該第三者に対する損害賠償費用その他解除に伴い、乙に発生する費用を甲は負担するものとする。

3.

乙は、当該再委託先との間で、再委託に係る業務を遂行させることについて、本契約に基づいて乙が甲に対して負担するのと同様の義務を、再委託先に負わせる契約を締結するものとする。

4.

乙は、再委託先の履行について甲に帰責事由がある場合を除き、自ら業務を遂行した場合と同様の責任を負うものとする。但し、甲の指定した再委託先の履行については、乙に故意又は重過失がある場合を除き、責任を負わない。

【2008 年 JEITA モデル契約との相違】
改正前民法では、復委任（再委託）の要件等について明文の規定は無かったところ、改正民法で委任者の許諾を得た場合、またはやむを得ない事由がなければ復委任できない旨の規定が新設され（改正民法第 644 条の 2 第 1 項）、復受任者（再委託先）を選任したときは、復受任者（再委託先）は委任者に対して受任者と同一の権利を有し義務を負う旨の規定が新設された（改正民法第 644 条の 2 第 2項）。
これらの規定は現行法における一般的な解釈を明文化したものではあるが、改正によって影響はな
いと考えられ、また、契約実務にも変更がないため、本条に変更はない。
【条文解説】
１．趣旨（１）再委託の必要性
本契約の前提条件である「重要インフラ・企業基幹システム」のように大規模なソフトウェア
開発では、受注したベンダ 1 社のみで対応することは非現実的であり、コストの面だけでなく、専門性の面でもシステム構築に多数の再委託先が開発に携わっている。しかし、請負と異なり、準委任の場合は委託者の許諾を得た場合またはやむを得ない事由がなければ再委託ができないとされている（改正民法第 644 条の 2 第 1 項）。そこで、本条では、個別契約の契約類型によらず、ユーザの事前承諾なしでベンダの判断で再委託が可能としている。
（２）再委託先の報告
本来、請負における再委託は受注者の責任において自由に実施されるものであるので、ユーザへの事前報告は原則不要としている。しかし、ユーザから事務所立入りに関するセキュリティ面などの理由により報告を求められた場合、例外として、ベンダは再委託先をユーザに報告することとしている。
（３）ユーザの再委託中止請求
再委託先に対するユーザの都合により、ユーザからベンダに再委託の中止請求がされた場合には、ベンダとして、受け入れなければならないことがある。その場合には、再委託先を変更する

23

ことになるが、その変更は作業期間や納期に影響があるのみならず、再委託先の再選定にかかる期間や費用および拒否された再委託先への補償などの費用も必要となることから、委託料等にも影響がある。よって、再委託の中止請求は第 33 条（本契約及び個別契約内容の変更）によるものとする。
（４）再委託中止請求の損害賠償
ユーザからの再委託中止請求の理由が、再委託先において、再委託先とベンダ間の契約の債務不履行などの契約解除事由に該当するような事実があったことによる場合には、ベンダは当該事
由を理由に再委託先との契約を一方的に解除することが可能である。しかし、当該再委託中止請
求の理由が当該再委託先とベンダ間の契約解除事由に該当しない場合には、ベンダは一方的に再委託先との契約を解除することはできず、解除するには、ベンダは再委託先に対して損害賠償を行う必要がある（改正前民法・改正民法第 641 条）。このようにベンダにも再委託先にも法的な責任がないような場合の再委託中止請求に伴う賠償費用については、受益者負担という観点から、ユーザがその事情から当該中止を要請するものである以上、ユーザが負担することとしている。
（５）再委託先の義務
再委託先の義務については、本契約に基づきベンダが負う義務を再委託先にも負わせることとしている。
２．条文の背景（１）再委託先の選定
ベンダは再委託先の選定においては、技術力、実績、プロジェクト遂行能力、セキュリティ、
コストなど様々な面から当該業務に最適な企業を選定し、ユーザに対して提案や見積りを実施している。
他方、ユーザとしては、セキュリティ面などから再委託について利害を有する。例えば、再委
託先の従業員がユーザの施設内で作業に従事することも多く、当該施設において、そのためのセキュリティ対策が必要となる。また、再委託先の従業員が、同業他社のシステム開発にも携わっている又は携わる可能性がある場合には、委託業務の内容によっては秘密情報の漏洩リスクも生じうる。そこで、このようなリスクが想定される再委託先をプロジェクトから排除する必要性が生じた場合、ユーザから再委託の禁止を求めることがある。
そこで、本契約では第三者への再委託を原則として認め、例外的に「合理的な理由」がある場
合に、ユーザは再委託の中止をベンダに請求できるとこととしている。
ユーザの要請により、ベンダが当初予定していた再委託ができない場合、ベンダは、当初の見積りよりも開発費用が膨らんだり、開発スケジュールを遅延したり、最悪のケースでは仕事を完成できなくなることがある。一方で、ユーザにとっても、再委託先の技術力やセキュリティ対策
がソフトウェアの品質や開発スケジュールに大きな影響があり、大きな利害関係がある。よって、再委託先の選定には責任が付随することとなるので、ベンダが選定した場合は、ベンダが再委託先について全責任を負う。しかし、ユーザが再委託先を選定した場合、多数の再委託先が携わる
プロジェクトでは、コミュニケーションによるチーム統制がプロジェクト運営に必要であるが、それを維持できない可能性もある。したがって、ベンダは、ユーザが選定した再委託先の履行については、ベンダに故意または重過失がない限り一切責任を負わないと規定している。

24

第２章 本件業務の推進体制（協働と役割分担）
第8条

甲及び乙は、本件業務の円滑かつ適切な遂行のためには、乙の有するソフトウェア開発に関する技術及び知識の提供と甲によるシステム仕様書の早期かつ明確な確定が重要であり、甲乙双方による共同作業及び各自の分担作業が必要とされることを認識し、甲乙双方による共同作業及び各
自の分担作業を誠実に実施するとともに、相手方の分担作業の実施に対して誠意をもって協力するものとする。
2.

甲乙双方による共同作業及び各自の分担作業は、各個別契約においてその詳細を定めるものとする。

3.

甲及び乙は、本件業務の円滑かつ適切な遂行のためには、相互の協力が必要であることを認識し、乙は、本件業務の進捗管理を行うものとし、甲は誠実に協力（プロジェクトの円滑な遂行のために迅速に判断を行い、時期に遅れた仕様の変更を行わず、かつ情報、人員、施設、設備、什器の提供等）を行うものとする。

4.

甲及び乙は、前各項に定めるプロジェクトマネジメント及び協力を行うにあたり必要となる事項については、速やかに第 9 条ないし第 11 条に規定する者に連絡し、必要に応じて第 12 条に規定する会議体において協議するものとする。

5.

甲及び乙は、共同作業及び各自の実施すべき分担作業を遅延し又は実施しない場合、それにより相手方に生じた損害の賠償も含め、かかる遅延又は不実施について第 53 条（損害賠償）の規定に従い相手方に対して責任を負うものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響はない。ただし、ユーザ・ベンダの協力、第 9 条ないし第 11 条に規定する者への連絡および第 12 条に規定する会議体で協議を行う点について追加した。
【条文解説】
１．趣旨（１）共同作業および各自の分担作業（第 1 項、第 2 項）
情報システムの構築は、いわゆるオーダーメイドであり、ベンダのみではシステムを完成させることはできない。超上流工程における企画や要件定義などは、ユーザが内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確にベンダに伝え、ベンダとともに、要望する機能について検討して、最終的にユーザが機能を決定し、さらに、画面や帳票を決定するなど、ユーザが責任を持って行う必要がある。併せて、ユーザが成果物の検収や運用テ
スト、運用評価といった、最終確認工程においても役割を担う必要がある。よって、情報システ
ムの構築はユーザとベンダの共同作業というべきであり、ユーザは一括して契約すれば「すべてベンダに丸投げできる」と考えがちであるが、実際には各々の役割を履行し、相手の役割を履行するために必要な協力をする必要がある。
（２）ベンダの進捗管理義務、ユーザの協力義務（第 3 項）

25

本件業務の範囲においては、ベンダは本件業務の開発進捗管理、調整等の責任を負い、ユーザは協力義務を負うため、この点を規定した。
（３）情報共有・協議（第 4 項）
プロジェクトの遂行における進捗管理や相互の協力に関しては、適切に情報を共有し、ユーザ
およびベンダの協議がなされることが必要となることから、ユーザ・ベンダの協力、第 9 条ないし第 11 条に規定する者への連絡および第 12 条に規定する会議体で協議を行う点について規定した。
２．条文の背景
ソフトウェア開発は各フェーズにおいて、準委任であればユーザ、請負であればベンダと主体が異なるが、共同作業であることには変わりないことを認識すべきである。また、ユーザごとに異なる業務をシステム化する上では、その要求仕様についてはユーザこそが決定についての権限を有し、責任を持つものである。
【適用ガイド】１．ユーザ・ベンダの協働と役割分担
ユーザとベンダの役割分担についてはプロジェクトの性質によって個々に異なることから、その詳細については個別契約で規定すべきである。また、ユーザ・ベンダはプロジェクトの開始後において変更等が必要な場合には、連絡および協議を行い、また、本契約の定めに従い契約変更手続きを行うことや、仕様書の凍結について合意しこれを書面化しておくこと等、適宜ユーザ・ベンダの役割分担・プロジェクトの進捗および方針について確認を行うべきである。なお、裁判例におけるベンダのプロジェクトマネジメント義務とユーザの協力義務については、次の【参考】を参照されたい。
【参考：裁判例におけるベンダのプロジェクトマネジメント義務とユーザの協力義務】（１）ベンダのプロジェクトマネジメント義務
多くの裁判例においてはユーザ・ベンダにおいてその専門的知識や経験に大きな差がある場合にはそれを考慮して、ベンダはプロジェクトの進行管理のみならず、ユーザを原因とする開発作業の遅延等がないよう、ユーザに働きかける義務があると考えるものがある。具体的には、想定外の事
項やユーザの変更要請などにより、プロジェクトに遅延・不具合が生じ、プロジェクトの目的を達成できなくなる場合においては、その専門的知見、経験に照らして、これを予測・予見した上、ユー
ザに対して、これを告知して説明すべき義務を負うと考える裁判例がある（東京高裁平成 26 年 1 月
15 日判決）。
なお、この予測・予見の対象は、プロジェクトの遂行および完成に関して、これが困難になる事
情や遅延を生じうる事情に関するものであって、その遅延や完成が困難になることによって、ユー
ザの業務上の目的達成の可能性や、ユーザに生じうる業務上の影響、損害の度合い等までを予測・予見しなければならないとまでいうものではなく、ベンダは予測・予見が合理的に困難な事項についての説明義務を負うものではない。
また、企画・提案段階においてもベンダはプロジェクトマネジメント責任を負う場合があるものの、その後の開発段階において、企画・提案どおりに進まないことをもってプロジェクトマネジメ

26

ント責任に違反したとはいえないとされている裁判例もある（東京高裁平成 25 年 9 月 26 日判決）。
そのほか例えば、ユーザの追加要望等がプロジェクトの遅延を生じうることについて、一定の情報を提供してユーザに説明の上、ユーザの意思決定を促したとしても、ユーザがなお、その要望を維持するような場合、ベンダはプロジェクト遅延を防止するためにユーザを説得したり、ユーザの要望を拒絶したりすることを義務として含むというわけでもないと考えられる。
以上のようなベンダの義務は、当該事案の事情に応じて認められたものであり、どんなプロジェ
クトについても認められるものと考えるのは適切ではないと考えられるが、訴訟事案によっては、こうした義務についてベンダに厳しい見方をされることもある。
（２）ユーザの協力義務
一方で、ユーザによる協力義務が認められた裁判例も多くある。具体的には例えば、ユーザが提供する必要があるものとして、支給品、貸与品、施設の提供ないしは使用許可、情報、プログラムの提供などがある（東京地裁平成 16 年 3 月 10 日判決）。
さらに、ユーザとして仕様や要望事項に関する決定などについて遅滞なく必要な意思決定を行う
こともプロジェクトを進めるために不可欠であることから、ユーザによる意思決定も協力義務に含まれる。また、ユーザが合理的な範囲を超えて追加要望や変更要望を行うことは、追加や変更を行う場合はもちろん、そうでなくともベンダに検討のためのリソースを割かれることとなるし、プロジェクトの混乱を招くおそれもある。そのため、最近の裁判例には、ユーザは合理的な範囲を超えて追加要望や変更要望を行わないという不作為義務を、ユーザの協力義務の一環として負っていると認めるものがある（札幌高裁平成 29 年 8 月 31 日判決）。仕様凍結の合意がなされた後になお、追加・変更要望などが行われる場合には、この協力義務違反があると認められる場合も考えられるであろう。このユーザの協力義務についても、個々のプロジェクトの事情に即して判断されることになる。
なお、個別の事案ごとの事情によるものではあるが、ソフトウェア開発におけるユーザ・ベンダの責任に関する裁判例（詳細は、本書付録③（165 頁）を参照されたい。）が出ているので、ユー
ザ・ベンダの協議により、あらかじめそれぞれの責任の範囲について第 8 条第 3 項以降を以下のオプション条項のように規定することも考えられる。

3.

乙は、本件業務の範囲において、本件業務の進捗管理を行う。また、乙は本件業務を阻害若しくは遅延し、又は本件業務の完成を困難にさせる要因について、その専門的知
識と経験に基づいて予見に努め、適宜甲に対してこれを説明するよう努めるものとする。

4.

甲は、本件業務の円滑かつ適切な遂行のために、乙に対し誠実に協力を行うものとする。この甲の協力義務には、情報、人員、施設、設備、什器等の提供のほか、乙の求めに応じて速やかな意思決定を行うこと、及び、合理的な範囲を超えて追加・変更要望などを行うことにより本件業務の遅延を生じさせないことなどが含まれる。

5.

甲及び乙は、前各項に定めるプロジェクトマネジメント及び協力を行うに当り必要となる事項については、速やかに第 9 条ないし第 11 条に規定する者に連絡し、必要に応じて第 12 条に規定する会議体において協議するものとする。

6.

甲及び乙は、共同作業及び各自の実施すべき分担作業を遅延し又は実施しない場合、

27

それにより相手方に生じた損害の賠償も含め、かかる遅延又は不実施について第 53 条
（損害賠償）の規定に従い相手方に対して責任を負うものとする。

（責任者）
第9条

甲及び乙は、各個別契約締結後速やかに、各個別契約における本条に定める権限及び責任を有する各自の責任者（以下「責任者」という。）をそれぞれ選任し、互いに書面により、相手方に通知する。なお、当該個別契約において双方の体制図を定め、当該体制図に当該責任者を記載することをもって通知に代えることができるものとする。
2.

甲及び乙は、事前に書面により相手方に通知することにより、責任者を変更できるものとする。

3.

甲の責任者は、次の各号に定める権限及び責任を有するものとする。
① 第 17 条所定の要件定義書の確定② 第 22 条所定の外部設計書の確定③ 第 27 条所定の検査仕様書の確定④ 第 26 条及び第 28 条所定の納入物の検収⑤ 第 35 条所定の中間資料の承認⑥ 第 36 条所定の未確定事項の確定後、確定した要件定義書、外部設計書の追完、修正の業務の請
求⑦ 第 37 条所定の変更管理書の相手方への交付⑧ 第 48 条及び第 49 条所定の第三者ソフトウェア及び FOSS の採否の行為
⑨

4.

5.

その他本契約及び個別契約の遂行に必要な権限及び責任乙の責任者は、次の各号に定める権限及び責任を有するものとする。
①

第 14 条の要件定義作成支援業務の実施に際し、甲から要請された事項の対応②

第 19 条の外部設計書作成支援業務の実施に際し、甲から要請された事項の対応③

第 27 条の検査仕様書作成支援業務の実施に際し、甲から要請された事項の対応④

第 26 条及び第 28 条所定の納入物の検収の要請⑤

第 35 条所定の中間資料の承認の要請⑥

第 36 条所定の未確定事項の確定の際の、追完、修正の業務の請求の書面での受領⑦

第 37 条所定の変更管理書の相手方への交付⑧

その他本契約及び個別契約の遂行に必要な権限及び責任

甲及び乙は、責任者を複数名定める場合は、それぞれの権限範囲を明確にし、相手方に通知するものとする。

6.

責任者が複数の場合には、甲及び乙は協議の上、総括責任者をおくことができるものとする。

【2008 年 JEITA モデル契約との相違】
第 1 項において「責任者」の定義を明確化して定めた。また、第 3 項および第 4 項において各号の表記方法を簡略化させた。
【条文解説】

28

１．趣旨（１）責任者
情報システムの構築においては、プロジェクト内にグループリーダーなどのプロジェクト責任者を定める。本条は、この位置付けを契約上も明確にし、権限と責任の範囲を定めている。また、権限を明確化することで、トラブルが発生したときの責任が明らかになる。複数の責任者がいる
場合は、それぞれの担務である責任範囲を明確にし、相手方に通知することがプロジェクト遂行上重要であることから、その旨の規定としている。
（２）責任者の設置個別契約締結後速やかに責任者を選定し、書面で通知する。責任者はいわゆるプロジェクトマ
ネージャーであり、プロジェクト遂行において重要な役割を担うので、プロジェクト開始時には選定されていることを義務付けている。
２．条文の背景
ユーザとベンダにおける会社を代表するものとして責任者を設置する。つまり、会社を代表するということは、各々の責任において判断し、対応できることを指す。
責任者の権限と責任を明確にすることで、その他のメンバーにはその権限がないことを明示することでもあり、プロジェクト遂行においては双方の責任者を通してコミュニケーションをとるように定めている。
【適用ガイド】１．責任者の権限および責任各条文で責任者の権限および責任が規定されているので、これらを列挙している。プロジェクトごとで責任者の権限と責任範囲を検討し、本条以降の条文において責任者の権限および責任が追加削除された場合は、本条の列記も修正する。
２．体制図
個別契約において双方の体制図を定め、体制図に責任者を記載することをもって通知に代えることができるものと定めている。
（主任担当者）
第 10 条甲及び乙は、各個別契約締結後速やかに、本件業務を円滑に遂行するため、責任者の下に連絡確認及び必要な調整を行う担当者（以下「主任担当者」という。
）を選任し、書面により、相手方に通知する。なお、当該個別契約において双方の体制図を定め、当該体制図に当該主任担当者を記載することをもって通知に代えることができるものとする。
2.

甲及び乙は、事前に書面により相手方に通知することにより、主任担当者を変更できるものとする。

3.

甲及び乙は、本契約に定めた事項のほか、本件業務遂行に関する相手方からの要請、指示等の受理及び相手方への依頼、その他日常的な相手方との連絡、確認等は原則として主任担当者を通じて行うものとする。

4.

甲及び乙は、主任担当者を複数名定める場合は、それぞれの権限範囲を明確にし、相手方に通知

29

するものとする。
【2008 年 JEITA モデル契約との相違】
第 1 項において「主任担当者」の定義を明確化して定めた。
【条文解説】
１．趣旨
ソフトウェア開発は、プロジェクトの規模に応じて開発期間の長短はあるが、ある一定の期間、ユーザ・ベンダが相互に協力して、開発作業を実施するプロジェクトであり、その取組体制にプロジェクトの成否が懸かっていることから、開発推進体制および定期協議会に関する規定を設けている。
また、ユーザ・ベンダの様々な部門から、ソフトウェア開発に関して多種多様な要望、意見等が出され、相手方が混乱しないよう、ユーザ・ベンダ内部の要望、意見等を集約してから、相手方に連絡すべく、ユーザ・ベンダ間のソフトウェア開発に関する連絡窓口を主任担当者に一本化する。
なお、複数の主任担当者がいる場合は、それぞれの担務である責任範囲を明確にし、相手方に通知することがプロジェクト遂行上重要であることから、その旨の規定としている。
２．条文の背景（１）主任担当者の権限前条にて列記された、責任を伴う事項については、責任者が対応するが、日々のプロジェクト
遂行については、主任担当者が連絡･調整の窓口一本化で対応する。
【適用ガイド】１．開発推進体制
主任担当者は窓口一本化のために設置するが、大規模システムで複数のグループを組織するなど、プロジェクト推進上、複数人の主任担当者を選出する場合は、各々の権限や責任範囲を明確する。
図４

体制図

30

（業務従事者）
第 11 条

本件業務に従事する乙の従業員（以下「業務従事者」という。）の選定については、乙が行う。
2.

乙は、労働法規その他関係法令に基づき業務従事者に対する雇用主としての一切の義務を負うものとし、業務従事者に対する本件業務遂行に関する指示、労務管理、安全衛生管理等に関する一切の指揮命令を行うものとする。

3.

乙は、本件業務遂行上、業務従事者が甲の事務所等に立ち入る場合、甲の防犯、秩序維持等、甲の施設内立入りに関する諸規則を当該業務従事者に遵守させるものとする。

【2008 年 JEITA モデル契約との相違】
第 3 項について、諸規則の範囲や対象が明確化できるよう「甲の施設内立ち入り」の文言を追記した。
【条文解説】
１．趣旨（１）指揮命令
責任者、主任担当者を設置することで、ユーザが業務従事者に直接指揮命令することがないことを確認している。
２．条文の背景（１）ベンダの業務従事者への責任
業務従事者に対してはベンダに雇用者としての責任がある。本契約においては、委託契約を前提としており、労働者派遣契約ではないということで、この条文を定めている。

31

【適用ガイド】
１．セキュリティ
業務遂行上、ユーザの事務所等で作業する場合があるが、その場合、ユーザが入所者に対して行
うセキュリティ上の管理や事務所内での規則遵守指導などは指揮命令に該当しない。
（連絡協議会の設置）
第 12 条甲及び乙は、本件業務が終了するまでの間、その進捗状況、リスクの管理及び報告、甲乙双方による共同作業及び各自の分担作業の実施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議及び解決その他本件業務が円滑に遂行できるよう必要な事項を協議するため、協議会（以下「連絡協議会」という。）を開催するものとする。但し、本契約及び個別契約の内容の変更は
第 33 条（本契約及び個別契約内容の変更）に従ってのみ行うことができるものとする。
2.

連絡協議会は、原則として、個別契約で定める頻度で定期的に開催するものとし、それに加えて、
甲又は乙が必要と認める場合に随時開催するものとする。

3.

連絡協議会には、甲乙双方の責任者、主任担当者及び責任者が適当と認める者が出席する。また、
甲及び乙は、連絡協議会における協議に必要となる者の出席を相手方に求めることができ、相手方は合理的な理由がある場合を除き、これに応じるものとする。

4.

乙は、連絡協議会において、別途甲乙間にて取り決めた様式による進捗管理報告を作成して提出し、当該進捗管理報告に基づいて進捗状況を確認するとともに、遅延事項の有無、遅延事項があるときはその理由と対応策、本章で定める推進体制の変更（人員の交代、増減、再委託先の変更など）の要否、セキュリティ対策の履行状況、個別契約の変更を必要とする事由の有無、個別契約の変更を必要とする事由があるときはその内容などの事項を必要に応じて協議し、決定された事項、継続検討とされた事項並びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者等を確認するものとする。

5.

甲及び乙は、本件業務の遂行に関し連絡協議会で決定された事項について、本契約及び個別契約に反しない限り、これに従わなければならない。

6.

乙は、連絡協議会の議事内容及び結果について、書面により議事録を作成し、これを甲に提出し、その承認を得た後に、甲乙双方の責任者がこれに記名押印の上、それぞれ 1 部保有するものとする。
乙は、議事録の原案を原則として連絡協議会の開催日から○日以内に作成して、これを甲に提出し、甲は、これを受領した日から○日以内にその点検を行うこととし、当該期間内に書面により具体的な理由を明示して異議を述べない場合には、乙が作成した議事録を承認したものとみなすものとする。但し、当該議事録の内容が、第 37 条（変更管理手続）に定める変更管理書又は本契約若しくは個別契約の条件に影響を及ぼす場合は、同条の規定に基づく手続きを経た上で、変更が確定するも
のとする。

7.

前項の議事録は、少なくとも当該連絡協議会において決定された事項、継続検討とされた事項並
びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者の記載を含むものとする。

【2008 年 JEITA モデル契約との相違】
第 1 項において「連絡協議会」の定義を明確化して定めた。また、第 6 項で議事録の合意事項が、変更管理書、本契約や個別契約の条件に影響が及ばない範囲の実務に特化した事項に限定できるよう

32

な規定を追記した。
【条文解説】
１．趣旨（１）コミュニケーション
共同作業である部分と各々の分担作業についての進捗をお互いにチェックする。また、プロジェ
クト遂行上の課題を協力して解決するなどのコミュニケーションをとる。
（２）開催頻度
開催は定期的に開催されるべきであるが、その頻度は各フェーズにより異なるため、個別契約
において定めるとしている。
（３）連絡協議会出席者
第 3 項に最低限のメンバーは定めているが、業務の判るエンドユーザやシステム利用者など、必要に応じて出席要請ができるとしている。
（４）進捗管理
ベンダが進捗報告することを定めているが、分担作業として、ユーザの申告についても確認が必要であれば確認する。
（５）決定事項の遵守
協議会は意思決定の場であるので、その場で決定したことは遵守することを定めている。
（６）議事録協議会で定めたことは、ユーザとベンダで誤解のないように議事録に留め、お互い確認することでプロジェクトを確実に遂行する。また、ペンディング事項などのフォローを行う。
２．条文の背景（１）会議体の運営
議論し決定したことを記録し、決定したことが遵守され運用できていることが重要である。
（２）複数会議体の設置
大規模なシステム開発においては、出席者の異なる複数の種類の連絡協議会を設置する必要がある場合は適用ガイドにあるオプション条文を参考とする。
【適用ガイド】
１．会議の種類
会議開催目的に合わせて会議を開催する必要があり、その出席者選定においても会議目的に合わせて行われる。
会議は定期的に開催されることで、コミュニケーションがとられるので、定期開催が重要である。
２．定期協議会等の開催
本件ソフトウェアに関するコンセンサスの一致や仕様の確定のために、システム部門だけでなく、対象ソフトウェアの利用部門（エンドユーザ）も定期協議会に参加できるよう、ベンダがユーザに対し要請できるものとする。
３．期日33

第 6 項にて「連絡協議会の開催日から○日以内に作成して、これを甲に提出し、甲は、これを受領した日から○日以内にその点検を行うこととし、・・・・」としているが、「○日」は「○営業日」と変更することもできる。ただし、その場合、どこの営業日か明確にすべきであり、必要であれば、「○営業日（土日祝日を除く乙営業日）」などのように定める。
また、「乙は、議事録の原案を原則として連絡協議会の開催日から○日以内に作成して、これを甲に提出し、甲は、これを受領した日から○日以内にその点検を行うこととし、」の文言の前に「個別契約において別段の定めがない限り、」と追記して、個々の個別契約に応じた業務内容に沿って、期日の長短設定が可能な余地を残せるように規定することも一案としてある。
４．議事録作成
第 6 項で議事録をベンダが作成すると定めているが、ユーザが議事録作成者となる場合を想定して以下のようにしてもよい。なお、 連絡協議会の議事録は裁判等において極めて重要な証拠となるので、合意されたこと、されなかったことを区別した明確な記載を行い、ユーザ・ベンダ双方で確認すべきである。

6.

甲及び乙は、甲又は乙のいずれが連絡協議会の議事録を作成するかをあらかじめ取り
決めるものとし、議事録作成者は、連絡協議会の議事内容及び結果について、書面により議事録を作成し、これを相手方に提出し、その承認を得た後に、甲乙双方の責任者がこれに記名押印の上、それぞれ 1 部保有するものとする。議事録作成者は、議事録の原案を原則として連絡協議会の開催日から○日以内に作成して、これを相手方に提出する。
当該相手方は、これを受領した日から○日以内にその点検を行うこととし、当該期間内に書面により具体的な理由を明示して異議を述べない場合には、議事録作成者が作成した議事録を承認したものとみなすものとする。

５．複数種類の会議体を設ける場合のオプション条項案
複数種類の会議体を設置する場合の条項を以下のようにオプションとして用意した。
（複数会議体の設置）
第○条

甲及び乙は、本件業務が終了するまでの間、甲乙双方の共同作業及び分担作業を含む本件業務の進捗状況の報告、課題･問題点の協議･解決、システム仕様書の内容の検討･確認等その他本件業務の円滑な推進のために必要な事項を協議するため、定期的に開催する会議体（以下｢連絡協議会｣という）を設置し、開催するものとする。なお、当該連絡協議会には、責任者及び主任担当者の出席を必須とする。また、複数の種類の連絡協議会を設けることができるものとし、この場合を含め、甲及び乙は、連絡協議会について次の各号を別途協議の上プロジェクト計画書等の書面により定めるものとする。
① 開催頻度･時期② 当該連絡協議会の名称③ 責任者及び主任担当者が複数設けられている場合には、当該連絡協議会の開催に必須とする甲乙双方の責任者又は主任担当者

34

④ 複数種類の連絡協議会を設ける場合は、第 37 条に基づく協議を行う連絡協議会の特定、各連絡協議会において取り扱うべき事項及びそれらの連絡協議会の関係（上下関係等）⑤ 議事録作成の甲乙の分担及び甲乙双方の議事録承認者⑥ 前各号の他連絡協議会の運営に必要な事項
2． 連絡協議会は原則として、前項により定めた頻度で開催するものとするが、甲又は乙が必要と認める場合には随時開催することができるものとする。また、甲及び乙は、連絡協議会における協議に必要となる者の出席を相手方に求めることができ、相手方は合理的な理由がある場合を除き、これに応じるものとする。
3． 第 1 項第 5 号により定めた分担に従い、甲乙のいずれかが連絡協議会の議事録を開催
日から[3]日以内に作成の上相手方に提出し、相手方は受領後○日以内に確認するものとする。相手方の確認後直ちに甲乙双方の承認者が記名押印し、甲乙双方が各一部を保有するものとする。但し、相手方が受領後○日以内に書面により別段の異議を述べない場
合、当該相手方は当該議事録を承認したものとみなし、この場合、作成当事者は、相手方の受領日及び相手方から何等の異議なく○日が経過した旨を記載の上、当該作成当事者の承認者が記名押印し、相手方の承認者にその一部を送付することをもって足るものとする。なお、当該議事録には、当該連絡協議会における配布資料、報告事項、決定事
項、課題事項（調査･検討等を継続して行うこととされた事項であり、実行当事者、スケジュールを含む）等が明確になるよう記載されるものとする。
4． 甲及び乙は、連絡協議会において実行すべき事項とされたものにつき誠実にこれを実行するとともに、連絡協議会で決定された事項については、本契約及び個別契約に反しない限り、これに従わなければならない。但し、本契約及び個別契約の内容の変更は第33 条（本契約及び個別契約内容の変更）に従ってのみ行うことができるものとする。
大規模なシステム開発の場合には、通常、会議体も複数種類設けられることが多い。例えば、次のようなものである。
① 責任者会議
ユーザ･ベンダ双方のプロジェクト責任者を必須の出席者として、最低でも月一度の頻度で開催し、原則はプロジェクト全体であるが個々のサブシステム単位も含め、状況確認、課題管理、解決策の協議等を行う。
② リーダー会議
大規模システムの場合には、推進体制としてサブシステム単位等でグループに分けられることがあり、ユーザ･ベンダ双方のそれぞれのグループリーダーを必須の出席者として、毎週開催
し、当該グループの進捗管理、課題協議等を行う。
③ 仕様検討会･レビュー会
要件定義、外部設計等において、具体的な業務システム要件、ユーザインタフェース仕様等を検討、決定し、ドキュメントのレビュー等を行う会議であり、集中的に毎日でも行われることがある。
このように複数の会議体が設けられる場合には、冒頭の条項では、当該条項が上記のどれを対象

35

として定めているものであるか、現場の SE やユーザの担当部門の人には分かりづらいおそれがある。
そこで、複数種類の会議体が設けられることを前提とした上記の条項例を用意した。なお、各会議
体で取り扱うべき事項、必須出席者等の詳細については、プロジェクト計画書など別のドキュメン
トに定める運用とすることが現実的である。
６．上級管理職および上位会議体を設ける場合のオプション条項案
上級管理職（プロジェクトオーナー）および上位会議体（ステアリングコミッティ）を設置する場合の条項を以下のようにオプションとして用意した。個々のプロジェクトの規模、実態、状況に応じて本オプション条項の追加要否を判断されたい。
（プロジェクトオーナー・ステアリングコミッティ）
第○条

甲及び乙は、本件業務に係る重大な変更を含む甲乙間の協業関係について、それぞれの責任者を指揮監督し、必要な支援を行う上級管理職（以下「プロジェクトオーナー」という。）を指名するものとする。
2.

甲及び乙は、必要があると合意した場合、それぞれのプロジェクトオーナーにより構成される上位会議体（以下「ステアリングコミッティ」という。）を設置するものとする。
ステアリングコミッティは、本件業務の指揮監督を行い、次の各号を決定する本件業務についての最終意思決定機関であるものとする。
①本件業務の戦略的な方向性を決定する。
②本件業務の問題点等に関して、連絡協議会で合意に至らなかった場合に、協議と最終的な意思決定を行う。
③本件業務の大幅な変更、中止の判断を含む、重要な変更要求を承認する。

プロジェクトにおいて、プロジェクト責任者の権限を超える要件が発生した場合には、事業部長などの上級管理職または役員がプロジェクトオーナーとしてこれを支援するべきである。あるいはプロジェクトの中止といった重大な決定についても、プロジェクトの規模、重要性によってはプロ
ジェクト責任者の判断に余る場合がありうる。
プロジェクトオーナーはプロジェクト遂行に関する日常的な業務や意思決定には直接関与しない。
プロジェクトオーナーの任務は、プロジェクトをプロジェクト外から指揮監督するとともに、必要な場合に人員、予算措置を含む総合的な支援を与えることにある。また、プロジェクト遂行に関し、第 12 条に定める連絡協議会の判断を超える事態が発生した場合には、ステアリングコミッティの構成員として当該事態について協議と最終的な意思決定を行う。
ステアリングコミッティの議題は条文に列挙されたとおり、プロジェクト遂行に関する日常的な判断を超えた重大なもの、あるいは連絡協議会で両社の合意が得られなかったものに限られる。このような議題は、大規模なプロジェクトであればあるほど両社の会社の財務、人員配置、企業戦略に重大な影響を及ぼす可能性が高いため、実務担当者レベルの判断に余るものであり、両社の上級管理職間の協議と合意によって行うことが適切と考えられる。
ステアリングコミッティの性質上、その開催頻度は連絡協議会より少なく、毎月に一度、あるいは四半期に一度程度が適当と考えられる。

36

（複数ベンダによる開発の場合の全体管理責任）
第 13 条甲が、本件ソフトウェアの開発等を全体のシステムの一部として乙に分割発注しており、本件ソフトウェアと連携する他のソフトウェアを第三者が開発している場合、当該他のソフトウェ
アと本件ソフトウェアの機能の整合性、開発スケジュールの調整並びに当該第三者と乙の開発進捗
管理及び調整等の全体管理に係る事項については、甲がその責任を負うものとする。
2.

甲が、前項の全体管理を円滑に遂行するために、本件業務に関する範囲で乙の協力を要請する場
合、必要となる条件を個別契約で定めるものとし、乙は個別契約に従い、甲の全体管理に必要な協力を行うものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響はないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。なお、分かりやすさの観点から、条文の見出しを「複数ベンダによる開発の場合の管理責任」に変更した。
【条文解説】
１．趣旨（１）複数ベンダによる開発の場合の管理責任（第 1 項、第 2 項）
ユーザがマルチベンダ方式（複数のベンダがひとつのシステムの部分を担当して開発する方式）を採用したときは、各担当ベンダの作業範囲や体制を明確化するなどの役割と責任はユーザの責任範囲に含まれているとしている（第 1 項）。その一方で、マルチベンダ方式においても、本件業務の範囲については個別契約に規定の上、ベンダはユーザの全体管理の遂行のために協力を行う
ものとしている（第 2 項）。
２．条文の背景（１）情報システム開発の全体管理
マルチベンダ方式の場合、各ベンダ間においては契約関係がないため、実質的に契約関係のあるユーザが情報システム開発の全体管理を行わなければならない。ただし、ユーザがそのスキルを有していない場合は、ベンダに委託する場合もあるが、その場合は、そのベンダが契約の範囲においてその責任を負うこととなる。
図５

マルチベンダ37

（２）ベンダの協力
マルチベンダの場合、ベンダ間の連携や協力など必要な範囲があるが、各フェーズでその内容は異なるため、個別契約において定めることとしている。
【適用ガイド】１．マルチベンダ時のプライムベンダの活用
マルチベンダの場合、各ベンダと契約しているのはユーザである。各ベンダ間には契約が無いので、ベンダ間の調整はユーザ責任となる。ベンダ間の調整責任としてはユーザ側のプロジェクトリー
ダーの責任は重要であり、各契約単位における最終的な責任は契約当事者であるユーザと各システム構築を担当するベンダにあると解される。
また、マルチベンダの場合でも、図５のように統括を請負うベンダ（プライムベンダ）があると
きは、プライムベンダはシステム全体を受託しており、当該システムを構成するサブシステムを委託するベンダ各社との調整を行う責任が生ずる。しかし、この場合でも、ユーザと当該プライムベ
ンダ間の契約において、全体管理に関して一定の役割分担を取り決めているときには、その契約の範囲において、契約当事者であるユーザとプライムベンダの双方がそれぞれの役割について責任が負担することになる。
図６

プライムベンダの活用

38

２．ベンダが単一の場合
全体システムを１つのベンダで請負う場合は、ユーザとベンダの役割分担ということで、個別契約書に定められることになるので、本条は不要な条文となりうる。しかし、プロジェクト推進中に
マルチベンダ方式を採用することもあるので、本条は削除する必要はないと考える。

第３章 本件業務
第１節 要件定義作成⽀援業務（要件定義作成支援業務の実施）
第 14 条乙は、第 15 条所定の個別契約を締結の上、本件業務として甲が作成した情報システム構想

書、システム化計画書等に基づいて、甲による要件定義書の作成作業を支援するサービス（以下「要件定義作成支援業務」という。）を提供する。
2.

乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うもの
とする。

39

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、要件定義作成支援業務の実施の実務は現在においても同様と考えられるため、本条に変更はない。ただし、【条文解説】については「共通フレー
ム 2013」に準じた表現に変更した。
【条文解説】
１．趣旨（１）第 1 項
共通フレーム 2013 では｢要件定義プロセスは、定義された環境において、利用者及び他の利害関係者が必要とするサービスを提供できるシステムに対する要件を定義することを目的とする。｣
12 とされている。すなわち、要件定義はユーザがシステムで実現しようとする業務（内容、運用ルール、処理手順、関連部門の権限、決裁手続等々）を分析、整理し、システム化する範囲と当該業務を遂行する上で必要となる機能要件を明らかにし、ユーザ社内の利害関係者（エンドユー
ザ部門、経営層等の関係者）の合意を取り付けて、最終的に要件定義書というドキュメントにとりまとめる工程である。
このように要件定義はユーザの業務そのものを見直し、ユーザ自身が判断･決定して、とりまとめていかなければならない工程であるため、その実行主体はユーザとなる。これに対してベンダ
は、ユーザがこれらの作業を遂行する過程で、情報処理技術に関する専門家として技術的アドバ
イスの提供、評価の実施等の技術的な支援を行う。
第 1 項は、以上のユーザとベンダそれぞれの役割に基づき、契約という観点からユーザからベンダに委託される業務内容の主旨を明らかにするものである。
（２）第 2 項
要件定義はユーザが主体となって行い、ベンダは技術的支援をするということから、この委託関係は準委任契約を前提としており、第 2 項は、準委任契約に基づきベンダは善良なる管理者としての注意義務を負うものであることを定めている。
２．条文の背景（１）望ましい「仕様」の実現①ソフトウェア開発における「仕様」
商談の中でユーザは、システムにつき抱いている大まかなイメージを「仕様」（要求仕様レベル）としてベンダに提示し、ベンダは、この「仕様」を基に、実際にソフトウェアを開発するために十分な設計書（詳細仕様レベル）を作成して、これをベースにソフトウェアを開発するというケースが多かった。
②不十分な「仕様」に内在するリスク
そのために、開発されたソフトウェアは、要求仕様レベルから導き出される詳細仕様レベルのものが一義的でないにもかかわらず、仕事を完成したか否かを、当初の要求仕様レベル
をベースに判断されるため、ユーザの評価が一定しないリスクが内在していた。
これはユーザからすれば、思惑どおりではないソフトウェアを利用せざるをえなくなった
12『共通フレーム 2013』127 頁

40

り、思惑どおりに変更させたとしても、稼動時期を延期せざるをえなくなったり、場合によってはベンダから追加費用を請求されることとなる。
一方、ベンダからすれば、作成したものがユーザの思惑と異なった場合、変更に要する作業費用を負担すること、あるいは納期遅延の責任を追及されることとなる。
③「仕様」の明確化
上記リスクを回避するためには、ユーザがベンダに提示する「仕様」が、その後ベンダが仕様を詳細化していく上で「望ましい仕様」である必要がある。そこでユーザがベンダに提示すべき「望ましい仕様」とは何かが問題となる。
一言「仕様」といっても多義的なものであり、ソフトウェア開発では図７のように「仕様」
は「事業」領域から、「業務システム」領域⇒「IT システム領域」⇒「ソフトウェア」領域へと段階的に詳細化されていく。
図７

要件定義・仕様とテストの関係

出典：「経営者が参画する要求品質の確保～超上流から攻める IT 化の勘どころ～第 2 版」
（24 頁、独立行政法人 情報処理推進機構 ソフトウェア･エンジニアリング･センター編）「要件定義」は「業務システム」領域に属し、上記１に記載したとおり、ユーザの業務要件およびそれを実現するためにシステムに求める機能要件を「仕様」としてまとめる、まさしくユー
ザの要求を仕様化する工程である。そこで、「望ましい仕様」を作成するために、この「要件定義」
を切り出し、個別契約の一つの単位としている。
（２）準委任契約と完成責任の有無
要件定義作成支援業務におけるベンダの責任は、技術指導を通じてユーザの作業を支援することに限られ、要件定義書の作成作業を行って、要件定義書を完成させる責任はない。
要件定義作成支援業務は、ユーザがベンダに対し、ユーザが実施する要件定義書作成作業を支援するという事務の処理を委託するサービスであり、この委託契約は、法的には「委任契約」（改正前民法・改正民法第 643 条）となり、ただ委託している事務が法律行為ではなく、事実行為で41

あることから、「準委任」（改正前民法・改正民法第 656 条）と呼ばれる。準委任契約では、受任者（ベンダ）は、事務処理の過程において、受任者の業種、業務などに応じて要求される仕事を行わなければならないという責任（善管注意義務）を負う。
（要件定義作成支援業務に係る個別契約の締結）
第 15 条甲及び乙は、要件定義作成支援業務について、第 4 条第 1 項に定める取引条件を協議の上決定し、要件定義作成支援業務に係る個別契約を締結する。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、要件定義作成支援業務に係る個別契約の締結の実務は現在においても同様と考えられるため、本条に変更はない。
【適用ガイド】１．個別契約書のサンプル
個別契約書の締結に際しては、第 4 条第 1 項に定める各取引条件をユーザ･ベンダ間で十分協議しておくことが必要である。
個別契約書のサンプルは本書付録④（169 頁）を参照されたい。なお、このサンプルでは役割分担等の詳細は別表に記載される構成となっている。この別表は個別契約書に袋とじし、一体としておくことが原則である。もし、例外的に別々とする場合には、当該別表が個別契約書の別表である
ことが明らかになるよう別表の表紙に「〇年〇月〇日付要件定義作成支援業務個別契約第〇項の別表である」などと明記しておかなければならない。また、当該別表の表紙には、ユーザ･ベンダ双方の合意を明らかにするために双方の記名押印も必要となる。
２．準委任契約における委託料の決め方
個別契約では、「委託料及びその支払方法」（第 4 条第 1 項第 10 号）を定めることになっている。
要件定義作成支援業務のような準委任契約によるサービスの場合、委託料の決め方には大別して定額払と実績払の 2 種類がある。
（１）定額払例えば、金 1,000 万円というようにサービスの対価の総額をあらかじめ定めておく決め方である。
なお、ユーザが主体となって行う作業に対して技術支援を行うというサービスの場合、ユーザの作業が長引くと、それだけベンダの支援業務の量が増えることになる。そこで、定額払による場合には、当該金額に対応した業務量により制限を設けることが一般的になされる。例えば、作業期間あるいは工数などの作業量を定めるなどである。
（２）実績払例えば、時間当たりの技術支援料を定め、実際に行った技術支援の時間数に当該技術支援料を乗ずるという決め方である。
（要件定義検討会）
第 16 条

甲は、要件定義書作成のために必要となる事項の明確化又は内容の確認等を行うため、必42

要と認められる頻度で、要件定義書作成についての第 12 条所定の連絡協議会（以下、本節において「要件定義検討会」という。）を開催し、乙は、これに参加して要件定義作成支援業務を実施す
るものとする。
2.

乙も、要件定義作成支援業務の実施のために必要と認めるときは、要件定義検討会を開催することができるものとし、甲は、これに参加するものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、要件定義検討会の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨（１）第 1 項｢要件定義｣は、ユーザが情報システムにより実現したい事業や業務の内容を分析し、それらの要件をシステム化に向けて定義する工程であり、定義した内容はベンダに適切に伝わる必要がある。そのためには、｢要件定義｣の過程においてユーザとベンダの間で確実かつ円滑なコミュニケー
ションが図られる必要があることから、第 1 項は、｢要件定義｣に関する確認･検討を連絡協議会の一つの開催目的として行うこと、およびその主催者を定めている（かかる目的で開催される連絡協議会のことを本契約の中では｢要件定義検討会｣と称している）。
（２）第 2 項
要件定義検討会でのレビューの他、ユーザが主体となってまとめた要件定義書をベンダが預かって内容を確認することもある。その際、疑問点、問題点が新たに発見された場合、ユーザと協議することが必要となることがある。そのような場合に備え、本条第 2 項では、ベンダにも開催する権限が付与されている。
２．条文の背景
一般にソフトウェア開発の上流工程では、仕様内容の確認･検討のためのレビュー会等の会議が行われる。次条に基づく仕様の確定の前提として、また、その後の工程を円滑に進めていくためにも、
ユーザ･ベンダ双方がその内容を確認し合うことは非常に大切である。大きな開発トラブルに散見されることであるが、この工程で要件の漏れ、配慮漏れ等があり、後々のテスト工程等でそれが判明すると、この工程まで後戻りし、作業をやり直すことになってしまう。このようなことを防ぐためにも本条の検討会を的確に行うことが極めて重要である。
【適用ガイド】１．第 12 条の適用
要件定義検討会は第 12 条の連絡協議会の一環としての位置付けとなっており、第 12 条の規定が適用されることに注意しておく必要がある。特に次の 2 点に注意されたい。
（１）決定事項の拘束力と議事録
第 12 条第 5 項に決定事項として合意した事項の拘束力、同条第 6 項に議事録の作成について規定している。仕様のレビューは、1 次レビュー、2 次レビュー等数回行われることがある。そうし43

たとき 1 次レビュー会での決定事項が 2 次レビュー会で変更されることも生ずる。この場合、1
次レビュー会での決定事項には拘束力が生ずるため変更できないのではないかと誤解されることが推測される。しかし、法的には、ユーザ･ベンダが合意の上決定した事項であっても当該ユーザ・ベンダがそれを変更する合意も有効であり、後の合意が法的には優先することになる。
したがって、議事録の作成に当っては、変更した事項は前回の決定事項からの変更であることは分かるように記述しなければならない。
（２）出席者の範囲「要件定義」はユーザの業務そのものを扱うものであるため、この検討会には、ユーザのシス
テム部門だけでなく、エンドユーザ部門まで広げてそのニーズが的確に反映できるようにする必要がある場合がある。第 12 条第 3 項には、「協議に必要となる者の出席を相手方に求めること」
ができるようになっている。ベンダにおいて業務内容に応じて特定のエンドユーザ部門の人の出席が必要と考える場合には、契約上もその要請を行う権限が与えられていることを認識しておくべきである。
２．第 12 条の複数会議体のオプション条項案の利用
本条の規定内容は第 12 条の連絡協議会において｢要件定義｣の検討を行うこととしているが、日常的な仕様検討はこの連絡協議会の下にレビュー会などの別の会議体を設けて行い、連絡協議会では
当該レビュー会等から上がってくる重要事項について検討･決定することがある。このように複数種類の会議体を設けて運営する場合、第 12 条の【適用ガイド】にオプション条項案を用意しているので、そちらを参照されたい。
（要件定義書の確定）
第 17 条

甲が要件定義書の作成を完了した場合、甲及び乙は、個別契約において定める期間（以下「要件定義書の点検期間」という。）内に要件定義書が前条所定の要件定義検討会での決定事項に適合す
るか点検を行うものとし、適合することを確認した証として甲乙双方の責任者が要件定義書に記名押印するものとする。但し、点検の結果、要件定義書が要件定義検討会での決定事項に適合しないと判断された場合、甲は、協議の上定めた期限内に修正版を作成し、甲及び乙は再度上記の点検、確認手続を行うものとする。
2.

前項による甲乙双方の確認をもって、要件定義書は確定したものとする。

3.

第 1 項の修正に伴い作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33 条
（本契約及び個別契約内容の変更）の手続によるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、要件定義書の確定の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は「仕様の確定」手続きを明らかにするものであり、確定の前提としてユーザ･ベンダ双方で

44

要件定義書の内容を点検することとなっている。重要な点は次のとおりである。
（１）点検の観点前条により要件定義検討会において要件定義書の内容をきちんと検討することとなっているが、同書の確定の前提としてユーザ･ベンダ双方によりユーザが作成完了させた要件定義書の内容を点検しておくことが必要である。その点検の観点は、検討会で検討した結果が的確に反映されているかどうかが中心となる（第 1 項）。
（２）要件定義書の記名押印と確定
ユーザ･ベンダ双方で確認することになっており、双方が確認したことを明らかにするために双方の責任者が記名押印することになっており（第 1 項）、要件定義書の確定はこの記名押印の有無
により明確になる（第 2 項）。
（３）修正が必要となった場合の対応
点検の過程で要件定義書の内容の修正が必要となった場合には、再度、ユーザは要件定義書を見直すことができる（第 1 項但書）
。また、当該修正のために、ベンダの技術的な支援の追加が必要となることがある。この場合には個別契約の条件の変更について第 33 条に従い行うこととなる（第 3 項）。
（４）｢確定｣の意義｢確定｣はユーザ･ベンダ双方の確認によりなされる。そして、双方の確認の証拠として双方の責任者が要件定義書に記名押印することになっている。このように責任者が記名押印する｢確定｣にはどのような意味があるのか。
要件定義書は、ユーザからベンダに伝えるべきユーザの要求仕様をまとめたものであり、次の｢システム方式設計（システム外部設計）｣以降の作業のスタートポイントとなるものである。しかも現実には、要件定義書はその検討過程で案として何度も書き換えられ、複数の版の要件定義書が存在することがある。そうすると、検討会の決定事項に適合する、最終的なものがどれであるかをユーザとベンダ双方で特定しておかなければならない。しかもその特定の場に居合わせなかった人であっても、後日、｢これが確定した要件定義書である｣と客観的に分かるようにしておかなければならない。
すなわち、｢確定｣とは、ユーザとベンダの双方で、｢これが検討会の決定事項に適合する、要件定義工程の最終的なアウトプットだ｣ということを客観的に特定し、明確にすることである。なお、ベンダの責任者が記名押印することになっているが、当該記名押印があるからといって、第 14 条に定めるベンダの義務の内容および責任範囲が変わるものではない。
２．条文の背景（１）「仕様問題」
ソフトウェア開発における多くのトラブルの根本原因には「仕様問題」があるとよくいわれる。
この「仕様問題」は要するに仕様が「曖昧」であるというものであるが、「仕様の曖昧さ」に 2 つの次元のものがある。
①内容の曖昧さ仕様としての記述内容の曖昧さであり、当該仕様が多義的に解釈できるようなもの。そのため、その後の詳細仕様がユーザの本来の意図からずれてしまうことがある。
②基準となる仕様が不明
仕様は変更がつきものといわれる。これは「要件定義」以降の工程だけではなく、「要件定義」
45

の過程でも同様である。前条の要件定義検討会の過程でも、要件定義書第 0 版からレビューの結果を受けて 0.1 版になり、0.2 版、0.3 版････と更新され、どこかの時点で確定されたとしても、その後もさらに仕様変更の都度、第 1.1 版、第 1.2 版････と続くことがある。このように現
実の開発現場には要件定義書と称する複数のドキュメントが存在することがある。要件定義書の表紙に記載されている版数と日付を見て、おそらくこれが確定版であろうと推測することは可能である。しかしこれも推測でしかない。
そうした状況下で、｢仕様問題｣に起因するトラブルが生ずると、その対応において責任関係を明らかにするために、仕様の「変更」なのか、「追加」なのか、あるいは単に「詳細化」なのか、また、それはいずれの当事者の事情により生じたのかを明らかにしなければならないことがある。しかしそのいずれも「どれか」特定の要件定義書が基準となるはずである。ところが現実にはどれが当事者間で確認した要件定義書であるのか特定できないことがある。そうすると責任関係も明らかにすることができない。
以上のように要件定義書が客観的に確定されていないとトラブル対応時の障害となることがある。しかしそれ以前の問題として、仕様変更の基準となるべき要件定義書が確定されていな
いことは、仕様変更管理が適切になされないことを意味することになる。
なお、基準となる要件定義書が不明というのは更に次のような要因に分解できる。
(a) 確定の意味、基準が不明である。
(b) ユーザとベンダの誰が確定の権限があるのか不明である。
(c) 確定したことを示す方法が不明である。
（２）条文による対応
仕様内容の曖昧さについては、前条の検討会などの機会にチェックしていくことが重要である。
もう一つの「基準となる仕様が不明」という問題を解消する方法として、本条に「仕様の確定」
手続きを明記した。
【適用ガイド】１．仕様変更管理と「確定」
仕様には変更がつきものであるが、「要件定義」の過程でも、ある程度要件が固まると、実務上、仕様変更管理がなされることがある。しかし、「要件定義」の過程での仕様変更管理と「確定」後の仕様変更管理では意味合いが異なってくる。第 34 条（87 頁参照）に基づく仕様変更管理は、要件
定義書についていえば、本条により「確定」した要件定義書に記述されている仕様につき、次の工程の「システム方式設計（外部設計）」に関する個別契約が締結された後に発生する当該仕様の変更を対象とするものであり、契約条件の変更を伴う可能性があるものである。要件定義書の｢確定｣前の「要件定義」の過程で発生する仕様変更については第 34 条の適用はない。
２．｢確定｣の記名押印
ユーザ･ベンダ双方の確認の証として要件定義書に記名押印を行う場合には、当該要件定義書の表紙に、例えば、図８のような押印欄を設け、押印するとよい。
図８

確定の記名押印例

46

（業務の終了・確認）
第 18 条乙は、前条に定める要件定義書の確定又は個別契約に定める作業期間の満了若しくは個別契約に定める作業工数（作業量）分の作業実施完了のいずれか最も早く到来したときから○日以
内に、業務終了報告書を作成し、甲に提出する。
2.

甲は、個別契約に定める期間（以下「要件定義作成支援業務終了の確認期間」という。
）内に、
当該業務終了報告書の確認を行うものとする。

3.

甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、乙に交付し、要件定義作成支援業務の終了を確認するものとする。

4.

要件定義作成支援業務終了の確認期間内に、甲が書面で具体的な理由を明示して異議を述べない場合には、甲は要件定義作成支援業務終了の確認期間の満了をもって、業務の終了を確認したものとみなされる。

5 前条に基づく要件定義書の確定前に要件定義作成支援業務が終了する場合で、甲が当該確定のためになお要件定義作成支援業務が必要とするときは、甲及び乙は第 33 条に従い、追加の要件定義
作成支援業務に関して変更契約又は追加契約を締結するものとする。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、業務の終了・確認の実務は現在においても同様と考えられるため本条に変更はない。
【条文解説】
１．趣旨
本条は、ベンダによる要件定義作成支援業務の終了条件およびユーザによる終了確認の手続きを定めるものである。重要な点は次のとおりである。
（１）業務の終了条件
ベンダの要件定義作成支援業務は次の 3 つの条件のいずれか最も早く到来した時点で終了する（第 1 項）。
47

① 要件定義書の確定② 個別契約に定める作業期間の満了③ 個別契約に定める作業工数（作業量）分の作業実施完了
要件定義作成支援業務の終了条件については、「要件定義書の確定」のみとしている場合がある
が、要件定義作成支援業務のような準委任契約に基づくサービスの場合には、そのサービスの範
囲の定め方として、作業期間による定め方と作業工数（作業量）による定め方が実務上ある。
特に、委託料を一括金額により定める場合にはそうである。そこで、作業期間、作業工数（作業量）も終了条件となる旨明記した。
なお、委託料の定め方として、時間当たりの技術支援料をあらかじめ決めて実績時間を乗ずる
ように、作業量に応じて委託料も変動するような定め方もある。
このほか、委託料を一括金額により定める場合の契約で、中途解約等により業務を終了する場
合には、（第 15 条の【適用ガイド】２．準委任契約における委託料の決め方）の支払を行うこと
で業務を終了することも可能である。
（２）プロセスに対するチェック
要件定義作成支援業務に関する個別契約は準委任契約であり、要件定義作成支援業務におけるベンダの責任は、技術指導を通じてユーザを支援することに限られ、（第 15 条の【適用ガイド】
２．準委任契約における委託料の決め方）の支払方法にかかわらず、要件定義書の作成作業を行って、要件定義書を完成させる責任はない。
そのため、ベンダが個別契約どおり業務を実施したかどうかは、契約で定めた内容に合致した要件定義書が作成されたかどうかという観点から行うのではなく、ユーザの要件定義書作成作業に対して契約どおりに支援を行ったかどうかという観点から判断する。
すなわち、サービスの結果（＝ベンダ支援のもとでユーザがまとめたドキュメント等）ではな
く、サービスのプロセス（＝支援そのもの）に対するチェックである（第 2 項）。そして、そのチェックのために、実施した業務内容を記載した業務終了報告書をベンダからユーザに提出することとしている（第 1 項）。
（３）確認期間の明確化とみなし確認
詳細かつ広範囲な確認を要するとなると、確認期間の長期化を招き、いつまでも確認されないという不都合が生じる。またその結果、その後に続く工程の作業が遅れたり、確認がなされない
まま後続の工程の作業に着手したりすることは、ユーザ・ベンダ間の責任関係を曖昧にする。そこで、確認期間を明確にする（第 2 項）とともに、確認期間内に異議がなければ確認完了とみなすこととしている。なお、ここでは第 17 条の「点検」との混同を招かないよう、「確認」という用語を用いることとしている（第 4 項）。
（４）追加の要件定義作成支援業務
本条第 1 項では、要件定義書の確定前にベンダの作業期間あるいは作業工数が満了となる場合がある。この場合、ユーザが確定に向けてベンダの支援が更に必要ならば別途契約が必要となる。
本条第 1 項において、要件定義作成支援業務の終了条件として、要件定義書の確定の他、作業期間または作業工数（作業量）の満了を追加し、同業務が要件定義書の確定前に終了する場合があることから、追加の同業務が必要となる場合は、変更契約または追加契約が必要となることを確認的に定めた（第 5 項）。
２．条文の背景
48

ソフトウェア開発取引では、ベンダの作業が契約どおり完了したかどうかをめぐり、トラブルとなることがある。請負契約の場合には、ユーザの要求仕様どおりのソフトウェアが完成したかどうかという点が問題になる。他方、要件定義作成支援業務のような準委任契約に基づくベンダの技術的支援についても、契約どおりに支援を行ったかどうかで問題となることがある。たとえ成果物はユーザが作成するものであってもプロジェクト全体がスケジュールどおりに進んでいない場面でそのようなことが起こりうる。
そこで、本条のように準委任契約であっても、その作業終了の条件および確認手続きを明確にしておく必要がある。
【適用ガイド】１．｢変更契約｣と｢追加契約｣のイメージ
本条第 5 項の｢変更契約｣または｢追加契約｣とは次のようなイメージ13のものである。
①

変更契約

②

追加契約

２．実績払における業務終了報告
委託料が実績払方式（時間当たりの技術支援料を定め、実績時間数を乗ずる方式）の場合、一般
的には月単位で実績報告するとともに、業務終了時には業務終了報告書にそれまでの実績全体を記載し、ユーザとベンダ双方で確認することが行われる。なお、毎月の実績報告についても契約上明示する場合には、例えば、｢乙は要件定義作成支援業務の実施中、毎月の実施実績時間数を当月末日から〇日以内に書面により甲に報告するものとする｣等の条文を本条の第 1 項として追加することも考えられる。
３．「検収」について
契約実務上、「検収」という用語を使うことがよくある。これは法律の用語ではなく、契約上慣習
13

ここではあくまで変更あるいは追加のイメージを掴んでいただくことを目的としており、正式な契約書としての体裁には整えていない。

49

的に使用されている用語であり、請求や支払のトリガーとなるタイミングを示すものとして用いられる。売買では、検収完了時期として「受入検査合格時」、「納品時」、「出荷時」等のバリエーションが見られる。請負契約では「受入検査合格時」が多いと思われる。本条のような準委任型のサービスに関しても「検収」が用いられることがある。
そこで、契約実務上、検収完了時期を条文上明確にしたい場合、本条の現在の第 5 項を第 6 項として、第 5 項として「前各項に基づく確認をもって検収完了とする。
」あるいは「前各項に基づく確認とともに乙所定の検収通知書に甲が記名押印することをもって検収完了とする。」などの条文を追加することが考えられる。
４．「検収」の効果
本条では、本件ソフトウェアがシステム仕様書と合致しているかに関する検査がユーザによりなされ、当該検査に合格したことにより「検収完了」とする旨定めており、さらに、第 29 条において、「検収完了」は、同条に定める契約不適合責任の定めが適用されるタイミングにもなっている。このように、検収書を出す行為は、本契約においては、ユーザ・ベンダの権利関係に影響を与えるものであることを認識しておく必要がある。

第２節 外部設計書作成（⽀援業務）
準委任型（A 案）と請負型（B 案）に関する解説「外部設計」
については、
次の理由から準委任契約の A 案と請負契約の B 案の 2 案が用意されている。
外部設計は、画面･帳票などのユーザインタフェースを決定するフェーズであり、作業の実態には、次の2 つのパターンがあるからである。
（１）ユーザ主体のパターン
画面･帳票等もまさしくユーザが業務の中で日常的に使うものであり、ユーザ自身の使い勝手ある
いは企業文化、嗜好、業務ノウハウが反映されることがある。また、特にユーザとベンダが初めて取引を行うような場合には、ベンダはユーザのかかる個別の事情に精通していないことが多い。
このようなことから、ユーザ自らが主体となって、｢要件定義｣の成果物を前提にユーザインタ
フェースの内容を検討し、決定していくことがある。この場合、ベンダは、「要件定義」の場合と同様にユーザに対して技術的支援を行う。
（２）ベンダ主体のパターン
上記とは反対にユーザとベンダの取引関係が長期に亘り、ベンダがユーザの考え方等上記のような事情を把握しており、また、「要件定義」の早い段階からユーザインタフェースに関する議論が十分行われているような場合がある。
また、他の多くのユーザにも同種業務があり、ユーザの固有事情に比較的左右されないような業
務について、ベンダがこのような業務について多くの経験を有し、当該業務に係るユーザインタ
フェースに関するノウハウを蓄積していることがある。このような場合には、確定した要件定義書を前提にベンダが自らの経験等に基づいてユーザインタフェースを検討、決定していくことがある。
なお、この場合でも、ユーザは適宜、社内の要望等をまとめベンダに提供したり、あるいは設計
内容のチェックと承認を行うなど、ユーザの協力は必要となる。
50

上記（１）のパターンの場合には準委任契約（A 案）となり、（２）のパターンの場合には請負契約（B 案）となる。ユーザおよびベンダは、開発するソフトウェアの規模、開発経験、業務ノウハ
ウの蓄積等を考慮して、いずれかを選択すべきである。
A 案：51 頁～59 頁
B 案：59 頁～67 頁
なお、B 案は A 案より条数が多い。本契約の条数は A 案を前提に条数を通しているため、B 案を選択する場合は、現第 24 条以下の条文の条数がずれること、特に条文中に現第 24 条以下の条文を参照している箇所に注意いただきたい。
【A 案

準委任の場合】（51 頁～59 頁）【A 案】（外部設計書作成支援業務の実施）
第 19 条乙は、第 20 条所定の個別契約を締結の上、本件業務として甲による外部設計書作成作業を支援するサービス（以下「外部設計書作成支援業務」という。）を提供する。
2.

乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、外部設計書作成支援業務の実務は現在においても同様であると考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は外部設計をユーザが主体となって行う場合の規定であり、ベンダは、ユーザがこれらの作業を遂行する過程で、情報処理技術に関する専門家として技術的アドバイスの提供、評価の実施等の技術的な支援を行う。
本条は、以上のユーザとベンダそれぞれの役割に基づき、契約という観点からユーザからベンダに委託される業務内容の主旨を明らかにするものである。
２．条文の背景（１）準委任契約と完成責任の有無
外部設計書作成支援業務におけるベンダの責任は、技術指導を通じてユーザの作業を支援する
ことに限られ、要件定義書の作成作業を行って、要件定義書を完成させる責任はない。
外部設計書作成支援業務は、ユーザがベンダに対し、ユーザが実施する外部設計書作成作業を支援するという事務の処理を委託するサービスであり、この委託契約は、法的には「委任契約」（改正前民法・改正民法第 643 条）となり、ただ委託している事務が法律行為ではなく、事実行為であることから、「準委任」（改正前民法・改正民法第 656 条）と呼ばれる。準委任契約では、受任者（ベンダ）は、事務処理の過程において、受任者の業種、業務などに応じて要求される仕事を行わなければならないという責任（善管注意義務）を負う。

51

【A 案】（外部設計書作成支援業務に係る個別契約の締結）
第 20 条甲及び乙は、外部設計書作成支援業務について、第 4 条第 1 項に定める取引条件を協議の上決定し、外部設計書作成支援業務に係る個別契約を締結する。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本契約は「基本契約」として、複数の個別契約に共通する条件、基本となる条件を定めており、ベンダが行う作業内容、ユーザが行うべき作業内容およびそれらのスケジュールならびにユーザが支払うべき代金などの具体的な債務内容は個別契約において定められることになる。本条は、外部設計書作成支援業務に関する具体的な債務内容を特定する個別契約の必要性を明確にするものである。
【適用ガイド】１．個別契約書のサンプル
個別契約書の締結に際しては、第 4 条第 1 項に定める各取引条件をユーザ･ベンダ間で十分協議しておくことが必要である。
個別契約書のサンプルは本書付録④（169 頁）を参照されたい。なお、このサンプルでは役割分担等の詳細は別表に記載される構成となっている。この別表は個別契約書に袋とじし、一体としておくことが原則である。もし、例外的に別々とする場合には、当該別表が個別契約の別表であることが明らかになるよう別表の表紙に「〇年〇月〇日付外部設計書作成支援業務に関する個別契約第〇項の別表である」など明記しておかなければならない。また、当該別表の表紙には、ユーザ･ベン
ダ双方の合意を明らかにするために双方の記名押印も必要となる。
２．準委任契約における委託料の決め方
個別契約では、「委託料及びその支払方法」（第 4 条第 1 項第 10 号）を定めることになっている。
外部設計書作成業務のような準委任契約によるサービスの場合、委託料の決め方には大別して定額払と実績払の 2 種類がある。
（１）定額払例えば、金 1,000 万円というようにサービスの対価の総額をあらかじめ定めておく決め方である。
なお、ユーザが主体となって行う作業に対して技術支援を行うというサービスの場合、ユーザの作業が長引くと、それだけベンダの支援業務の量が増えることになる。そこで、定額払による場合には、当該金額に対応した業務量により制限を設けることが一般的になされる。例えば、作業期間あるいは工数などの作業量を定めるなどである。

52

（２）実績払
例えば、時間当たりの技術支援料を定め、実際に行った技術支援の時間数に当該技術支援料を乗ずるという決め方である。
【A 案】（外部設計検討会）
第 21 条甲は、外部設計書作成のために必要となる事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、外部設計書作成について、第 12 条所定の連絡協議会（以下、本節において「外部設計検討会」という。）を開催し、乙は、これに参加して外部設計書作成支援業務を実施するものとする。
2.

乙も、外部設計書作成支援業務の実施のために必要と認めるときは、外部設計検討会を開催することができるものとし、甲は、これに参加するものとする。

3.

外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33 条（本契約及び個別契約
内容の変更）の手続によるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨（１）第 1 項｢外部設計｣をユーザが主体となって行う場合、外部設計の内容がベンダに適切に伝わる必要がある。そのためには、｢外部設計｣の過程において、ユーザとベンダの間で確実かつ円滑なコミュ
ニケーションが図られる必要があることから、第 1 項は、｢外部設計｣に関する確認･検討を連絡協議会の一つの開催目的として行うこと、およびその主催者を定めている（かかる目的で開催される連絡協議会のことを本契約の中では｢外部設計検討会｣と称している。
）。
（２）第 2 項
外部設計検討会でのレビューの他、ユーザが主体となってまとめた外部設計書をベンダが預かって内容を確認することもある。その際、疑問点、問題点が新たに発見された場合、ユーザと協議することが必要となることがある。そのような場合に備え、本条第 2 項では、ベンダにも外部設計検討会を開催する権限が付与されている。
２．条文の背景
一般にソフトウェア開発の上流工程では、仕様内容の確認･検討のためのレビュー会等の会議が行われる。次条に基づく仕様の確定の前提として、また、その後の工程を円滑に進めていくためにも、
ユーザ･ベンダ双方がその内容を確認し合うことは非常に大切である。大きな開発トラブルに散見されることであるが、この工程で要件の漏れ、配慮漏れ等があり、後々のテスト工程等でそれが判明すると、この工程まで後戻りし、作業をやり直すことになってしまう。このようなことを防ぐため

53

にも本条の検討会を的確に行うことが極めて重要である。
【適用ガイド】１．第 12 条の適用
外部設計検討会は第 12 条の連絡協議会の一環としての位置付けとなっており、第 12 条の規定が適用されることに注意しておく必要がある。特に次の 2 点に注意されたい。
（１）決定事項の拘束力と議事録
第 12 条第 5 項に決定事項として合意した事項の拘束力、同条第 6 項に議事録の作成について規定している。仕様のレビューは、1 次レビュー、2 次レビュー等数回行われることがある。そうしたとき 1 次レビュー会での決定事項が 2 次レビュー会で変更されることも生ずる。この場合、1
次レビュー会での決定事項には拘束力が生ずるため変更できないのではないかと誤解されることが推測される。しかし、法的には、ユーザ･ベンダが合意の上決定した事項であっても当該ユーザ･ベンダがそれを変更する合意も有効であり、後の合意が法的には優先されることになる。
したがって、議事録の作成に当っては、変更した事項は前回の決定事項からの変更であることは分かるように記述しなければならない。
（２）出席者の範囲「外部設計」はユーザが業務の過程で使用する画面、帳票等を扱うものであるため、この検討会には、ユーザのシステム部門だけでなく、エンドユーザ部門まで広げてそのニーズが的確に反映できるようにする必要がある場合がある。第 12 条第 3 項には、「協議に必要となる者の出席を相手方に求めること」ができるようになっている。ベンダにおいて業務内容に応じて特定のエンドユーザ部門の人の出席が必要と考える場合には、契約上もその要請を行う権限が与えられていることを認識しておくべきである。
２．第 12 条の複数会議体のオプション条項案の利用
本条の規定内容は第 12 条の連絡協議会において｢外部設計｣の検討を行うこととしているが、日常的な仕様検討はこの連絡協議会の下にレビュー会などの別の会議体を設けて行い、連絡協議会では
当該レビュー会等から上がってくる重要事項について検討･決定することがある。このように複数種類の会議体を設けて運営する場合、第 12 条の【適用ガイド】にオプション条項案を用意しているので、そちらを参照されたい。
【A 案】（外部設計書の確定）
第 22 条甲が外部設計書の作成を完了した場合、甲及び乙は、個別契約において定める期間（以下「外部設計書の点検期間」という。）内に外部設計書が、第 17 条の規定により確定された要件定義書及び前条所定の外部設計検討会での決定事項に適合するか点検を行うものとし、適合することを確認した証として甲乙双方の責任者が外部設計書に記名押印するものとする。但し、点検の結果、外部設計
書が、第 17 条の規定により確定された要件定義書及び外部設計検討会での決定事項に適合しない部分が発見された場合、甲は、協議の上定めた期限内に修正版を作成し、甲及び乙は再度上記点検、確認手続を行うものとする。
2.

前項による甲乙双方の確認をもって、外部設計書は確定したものとする。

54

3.

第 1 項の修正に伴い作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33 条
（本契約及び個別契約内容の変更）の手続によるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は「仕様の確定」手続きを明らかにするものであり、確定の前提としてユーザ･ベンダ双方で
外部設計書の内容を点検することとなっている。重要な点は次のとおりである。
（１）点検の観点
前条の外部設計検討会において外部設計書の内容をきちんと検討することとなっているが、同書の確定の前提としてユーザ･ベンダ双方が完了した外部設計書の内容を点検しておくことが必要である。その点検の観点は、検討会で検討した結果が的確に反映されているかどうか、また、
外部設計は要件定義書が前提となるため当該要件定義書に適合するかどうか、という点が中心となる（第 1 項）。
（２）外部設計書の記名押印と確定
ユーザ･ベンダ双方で確認することになっており、双方が確認したことを明らかにするために双方の責任者が記名押印することになっており（第 1 項）、外部設計書の確定はこの記名押印の有無
により明確になる（第 2 項）。
（３）修正が必要となった場合の対応
点検の過程で外部設計書の内容の修正が必要となった場合には、再度、ユーザは外部設計書を見直すことができる（第 1 項但書）
。また、当該修正のために、ベンダの技術的な支援の追加が必要となることがある。この場合には個別契約の条件の変更について第 33 条に従い行うこととなる（第 3 項）。
（４） ｢確定｣の意義｢確定｣はユーザ･ベンダ双方の確認によりなされる。そして双方の確認の証拠として双方の責任者が外部設計書に記名押印することになっている。このように責任者が記名押印する｢確定｣にはどのような意味があるのか。
外部設計書は、インタフェースに関してユーザからベンダに伝えるべきユーザの要求仕様をまとめたものであり、次の｢システム設計（システム内部設計）｣のインプットとなるものである。
しかも現実には、外部設計書はその検討過程で案として何度も書き換えられ、複数の版の外部設計書が存在することがある。そのため、検討会の決定事項に適合する、最終的なものがどれであるかをユーザとベンダ双方で特定しておかなければならない。しかもその特定の場に居合わせなかった人であっても、後日｢これが確定した外部設計書である｣と客観的に分かるようにしておかなければならない。
すなわち、｢確定｣とは、ユーザとベンダの双方で、｢これが検討会の決定事項に適合する、外部
設計工程の最終的なアウトプットだ｣ということを客観的に特定し、明確にすることである。なお、ベンダの責任者が記名押印することになっているが、当該記名押印があるからといって、第 19 条

55に定めるベンダの義務の内容および責任範囲が変わるものではない。
【適用ガイド】１．仕様変更管理と「確定」
仕様には変更がつきものであるが、「外部設計」の過程でも、ある程度要件が固まると、実務上、仕様変更管理がなされることがある。しかし、「外部設計」の過程での仕様変更管理と「確定」後の仕様変更管理では意味合いが異なってくる。第 34 条に基づく仕様変更管理は、外部設計書についていえば、本条により「確定」した外部設計書に記述されている仕様につき、次の工程の「システム設計（内部設計）」に関する個別契約が締結された後に発生する当該仕様の変更を対象とするものであり、契約条件の変更を伴う可能性があるものである。外部設計書の｢確定｣前の「外部定義」の過程で発生する仕様変更については第 34 条の適用はない。
２．｢確定｣の記名押印
ユーザ･ベンダ双方の確認の証として外部設計書に記名押印を行う場合には、当該外部設計書の表紙に、例えば、図９のような押印欄を設け、押印するとよい。
図９

確定の記名押印例【A 案】（業務の終了・確認）
第 23 条乙は、前条に定める外部設計書の確定又は個別契約に定める作業期間の満了若しくは個別契約に定める作業工数（作業量）分の作業実施完了のいずれか最も早く到来したときから○日以内に、業務終了報告書を作成し、甲に提出する。
2.

甲は、個別契約に定める期間（以下「外部設計書作成支援業務終了の確認期間」という。）内に、
当該業務終了報告書の確認を行うものとする。

3.

甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、乙に交付し、外部設計書作成支援業務の終了を確認するものとする。

56

4.

外部設計書作成支援業務終了の確認期間内に、甲が書面で具体的な理由を明示して異議を述べない場合には、甲は外部設計書作成支援業務終了の確認期間の満了をもって、業務の終了を確認したものとみなされる。

5.

前条に基づく外部設計書の確定前に外部設計書作成支援業務が終了する場合で、甲が当該確定のためになお、外部設計書作成支援業務を必要とするときは、甲及び乙は第 33 条に従い、追加の外部設
計書作成支援業務に関して変更契約又は追加契約を締結するものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は、ベンダによる外部設計書作成支援業務の終了条件およびユーザによる終了確認の手続きを定めるものである。重要な点は次のとおりである。
（１）業務の終了条件
ベンダの外部設計書作成支援業務は次の 3 つの条件のいずれか最も早く到来した時点で終了する（第 1 項）。
① 外部設計書の確定② 個別契約に定める作業期間の満了③ 個別契約に定める作業工数（作業量）分の作業実施完了（２）プロセスに対するチェック
外部設計書作成支援業務に関する個別契約は準委任契約であり、この業務におけるベンダの責
任は、技術指導を通じてユーザを支援することに限られ、外部設計書の作成作業を行って外部設計書を完成させる責任はない。
そのため、ベンダが個別契約どおり業務を実施したかどうかは、契約で定めた内容に合致した
外部設計書が作成されたかどうかという観点から行うのではなく、ユーザの外部設計書作成作業に対して契約どおりに支援を行ったかどうかという観点から判断する。
すなわち、サービスの結果（＝ベンダ支援のもとでユーザがまとめたドキュメント等）ではな
く、サービスのプロセス（＝支援そのもの）に対するチェックである（第 2 項）。そして、そのチェックのために、実施した業務内容を記載した業務終了報告書をベンダからユーザに提出することとしている（第 1 項）。
（３）確認期間の明確化とみなし確認
詳細かつ広範囲な確認を要するとなると、確認期間の長期化を招き、いつまでも確認されないという不都合が生じる。またその結果、その後に続く工程の作業が遅れたり、確認がなされない
まま後続の工程の作業に着手することは、ユーザ・ベンダ間の責任関係を曖昧にする。そこで、確認期間を明確にする（第 2 項）とともに、確認期間内に異議がなければ確認完了とみなすこととしている（第 4 項）。
（４）追加の外部設計書作成支援業務
本条第 1 項では、外部設計書の確定前にベンダの作業期間あるいは作業工数が満了となる場合

57

がある。この場合、ユーザが外部設計書の確定に向けてベンダの支援が更に必要ならば別途契約が必要となる（第 5 項）。
２．条文の背景
ソフトウェア開発取引では、ベンダの作業が契約どおり完了したかどうかをめぐり、トラブルとなることがある。請負契約の場合には、ユーザの要求仕様どおりのソフトウェアが完成したかどうかという点が問題になる。他方、外部設計書作成支援業務のような準委任契約に基づくベンダの技術的支援についても、契約どおりに支援を行ったかどうかで問題となることがある。たとえ成果物
はユーザが作成するものであってもプロジェクト全体がスケジュールどおりに進んでいない場面でそのようなことが起こりうる。
そこで、本条のように準委任契約であっても、その作業終了の条件および確認手続きを明確にしておく必要がある。
３．補足（１）第 1 項の作業期間、作業工数
実務上、外部設計書作成支援業務のような準委任契約に基づくサービスの場合、サービスの範囲は、①作業期間により定める方法、②作業工数（作業量）により定める方法があることに鑑み、外部設計書作成支援業務の終了につき、作業期間、作業工数（作業量）もその終了条件となる旨明記した。
（２）第 2 項、第 4 項の確認
第 22 条の「点検」との混同を招かないよう、「確認」という用語を用いることとしている。
（３）第 5 項の変更契約等
本条第 1 項において、外部設計書作成支援業務の終了条件として、外部設計書の確定の他、作業期間または作業工数（作業量）の満了を追加し、同業務が外部設計書の確定前に終了する場合があることから、追加の同業務が必要となる場合は、変更契約または追加契約が必要となることを確認的に定めた。
【適用ガイド】１．｢変更契約｣と｢追加契約｣
本条第 5 項の｢変更契約｣または｢追加契約｣は次のようなイメージ14のものである。

①変更契約

14

ここではあくまで変更あるいは追加のイメージを掴んでいただくことを目的としており、正式な契約書としての体裁には整えていない。

58

②追加契約【B 案

請負の場合】（59 頁～67 頁）【B 案】（外部設計書作成業務の実施）
第〇条

乙は、第○条所定の個別契約を締結の上、本件業務として第 17 条の規定により確定された要件定義書に基づき、本件ソフトウェアの外部設計書作成業務を行う。
2.

外部設計書作成業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には、適時にこれに応ずるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、外部設計書作成の業務の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は外部設計をベンダが主体となって行う場合の規定である（第 1 項）。この場合でも、ユーザ
は適宜、社内の要望等をまとめベンダに提供したり、あるいは設計内容のチェックと承認を行うな
ど、ベンダの業務が円滑に進むよう協力しなければならない（第 2 項）。
２．条文の背景（１）請負契約におけるユーザの協力義務
請負契約によりベンダが外部設計書作成業務を受託する場合、外部設計書を作成する主体はベンダとなる。この場合であっても、ユーザの作業がない訳ではない。ユーザが業務で日常的に使用する帳票や画面などを設計するのであるから、当該帳票や画面に関するユーザ社内の要望調整
やユーザによる確認作業などが必要となる。ソフトウェア開発ではユーザの協力が不可欠であり、ソフトウェア開発がユーザとベンダの共同作業といわれるゆえんである。
【適用ガイド】59

１．マルチベンダ方式の場合の、前工程で作成された要件定義書
例えば、ユーザが工程ごとに異なるベンダに分割発注し、「要件定義」工程とその後の工程を異なるベンダが行うことがある。また、同一ベンダが行う場合であってもユーザがシステム仕様書を独自にあるいは他ベンダの協力を得て変更を加えていることがある。
外部設計書作成業務は、要件定義書に基づいて行われるものであるから、上記のような場合、ベンダは、ユーザの用意した要件定義書を精査し、その業務が遂行可能であることを確認してから外部設計書作成業務を受注すべきである。また、外部設計書作成業務の個別契約において定める委託料を見積もる上でも、要件定義書の内容の確認は必要である。
しかし、時間的に制約があるなど、受注前に精査することが難しい場合は、次のオプション条項
により、受託後に要件定義書の精査を行い、必要に応じて納期や委託料などの個別契約の条件の変更、場合によっては契約の解除ができるようにしておく。
（要件定義書の補正）
第〇条

乙は外部設計書作成業務の遂行に当って次の各号のいずれかに該当する場合、次条所定の個別契約に定める期間内に当該要件定義書の内容を精査することができる。甲は、乙の要請に基づいて、乙の精査に必要かつ十分な資料を提供し、説明を行うものとする。
① 乙が本契約及び個別契約に基づき要件定義作成支援業務を受託せず、甲の用意した要件定義書に基づいて外部設計書作成業務を行う場合② 乙が本契約及び個別契約に基づき要件定義作成支援業務を受託し、第 17 条に基づく要件定義書の確定がなされたにもかかわらず、その後外部設計書作成業務に関する個別契約が締結されるまでの間に、甲により当該要件定義書が変更され、当該変更された要件定義書に基づいて外部設計書作成業務を行う場合③ 乙が本契約及び個別契約に基づき要件定義作成支援業務を受託したにもかかわらず、
第 17 条に基づく要件定義書の確定がなされず、甲が別途用意した要件定義書に基づいて外部設計書作成業務を行う場合
2. 前項の精査の結果、当該要件定義書に不十分な事項が発見された場合、乙は甲に対し、当該要件定義書の修正を求めることができる。なお、当該修正に関して、甲が乙に要件定義作成支援業務を委託する場合は、第 15 条に基づき別途個別契約を締結するものとし、要件定義書の確定の手続きは、第 17 条によるものとする。
3.

前項における要件定義書の修正に伴い外部設計書作成業務に関する個別契約の条件に変更が生じうる場合は、第 33 条の手続きによるものとする。なお、この場合、前項にかかわらず、第 33 条に基づき変更契約を締結したときをもって、修正された要件定義書は確定したものとする。

4. 第 2 項において甲が修正に応じない場合、又は、前項における第 33 条の手続きにおいて甲乙間の協議開始後○日以内に当該協議が調わない場合は、第 38 条を準用する。
（１）ベンダが外部設計書作成業務から受託する場合のパターン（第 1 項）
あらかじめユーザが用意した要件定義書に基づきベンダが外部設計書作成業務から受託する場
合として次のパターンを想定し、それらに対応できる条文としている。

60

① 「要件定義」工程までと異なるベンダが外部設計書作成業務を行う場合② 要件定義作成支援業務を受託したベンダが外部設計書作成業務を受託するが、一旦確定した要件定義書をユーザが独自にあるいは第三者に委託して当該要件定義書を変更している場合③ 要件定義作成支援業務を受託したベンダが外部設計書作成業務を受託するが、ユーザが要件
定義書を確定せず、ユーザが独自にあるいは第三者に委託して要件定義書を用意している場
合（２）要件定義書の内容が不十分だった場合
精査の結果、要件定義書の内容が不十分であれば、ベンダはユーザに要件定義書の修正を要求できる。修正はユーザ自らが行うことが前提であるが、ユーザが当該修正に際してベンダの支援を求める場合は、必要に応じて要件定義作成支援業務に関する個別契約を締結する（第 2 項）。
また、要件定義書の修正によって、追加費用が発生したり、納期を延伸する必要が生じるなど、
外部設計書作成業務の条件を変更する必要が生じる場合は、第 33 条に従い、外部設計書作成業務に関する個別契約の変更契約を締結する。外部設計書作成業務に関する個別契約を修正する必要がない場合は、第 17 条の手続きに従って要件定義書を確定するが、個別契約を修正する場合は、変更契約が締結されない限り、修正されたシステム仕様書が確定されない点に注意を要する（第 3項）。
（３）解約権（第 4 項）
第 2 項において、外部設計書作成業務に不十分であることが判明した要件定義書について、ベンダが修正を要求してもユーザがこれに応じない場合は、ベンダは、そのような要件定義書をもとに外部設計書作成業務を実施する義務を負うことのないよう、個別解約を解除できるようにしておくことが望ましい。
また、要件定義書の修正により、外部設計書作成業務に関する個別契約の条件変更が必要となる場合は第 33 条に基づき個別契約を変更することとなるが、変更内容につきユーザ・ベンダ間で合意できない場合は、第 38 条を準用することにより、ユーザ・ベンダ双方が本契約と外部設計書作成業務に関する個別契約を解約できるものとし、ベンダはそれまでに発生した費用を請求できることとしている。
（４）システム仕様書の精査費用等
条文上では、ベンダによる要件定義書の精査にかかる費用について触れていないが、当該精査費用については、外部設計書作成業務の委託料の見積とともに、個別契約において定めておくことが望ましい。
【B 案】（外部設計書作成業務に係る個別契約の締結）
第〇条

甲及び乙は、外部設計書作成業務について、第 4 条第 1 項に定める取引条件を協議の上決定

し、外部設計書作成業務に係る個別契約を締結する。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。

61

【条文解説】
１．趣旨
本契約は「基本契約」として、複数の個別契約に共通する条件、基本となる条件を定めており、ベンダが行う作業内容、ユーザが行うべき作業内容およびそれらのスケジュールならびにユーザが支払うべき代金などの具体的な債務内容は個別契約において定められることになる。本条は、外部設計書作成業務に関する具体的な債務内容を特定する個別契約の必要性を明確にするものである。
【適用ガイド】１．個別契約書のサンプル
個別契約書の締結に際しては、第 4 条第 1 項に定める各取引条件をユーザ･ベンダ間で十分協議しておくことが必要である。
個別契約書のサンプルは本書付録④（169 頁）を参照されたい。なお、このサンプルでは役割分担等の詳細は別表に記載される構成となっている。この別表は個別契約書に袋とじし、一体としておくことが原則である。もし、例外的に別々とする場合には、当該別表が個別契約の別表であることが明らかになるよう別表の表紙に「〇〇〇〇年〇月〇日付外部設計書作成業務に関する個別契約
第〇項の別表である」など明記しておかなければならない。また、当該別表の表紙には、ユーザ･ベンダ双方の合意を明らかにするために双方の記名押印も必要となる。
【B 案】（外部設計検討会）
第〇条

乙は、外部設計書作成のために必要となる事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、外部設計書作成について第 12 条所定の連絡協議会（以下、本節において「外部設計検討会」という。
）を開催し、甲はこれに参加するものとする。
2.

甲も、外部設計書作成のために必要と認めるときは、甲が外部設計検討会を開催することができるものとし、乙はこれに参加するものとする。

3.

外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33 条（本契約及び個別契約
内容の変更）の手続によるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨（１）第 1 項｢外部設計｣をベンダが主体となって行う場合であっても、ユーザのチェック、承認が必要である。そこで、第 1 項は、｢外部設計｣に関する確認･検討を連絡協議会の一つの開催目的として行うこと、およびその主催者を定めている。
（かかる目的で開催される連絡協議会のことを本契約の中では｢外部設計検討会｣と称している。
）

62

（２）第 2 項
外部設計検討会でのレビューの他、ベンダが主体となってまとめた外部設計書をユーザが預かって内容を確認することもある。その際、疑問点、問題点が新たに発見された場合、ベンダと協議することが必要となることがある。そのような場合に備え、本条第 2 項では、ユーザにも開催する権限が付与されている。
２．条文の背景
一般にソフトウェア開発の上流工程では、仕様内容の確認･検討のためのレビュー会等の会議が行われる。次条に基づく仕様の確定の前提として、また、その後の工程を円滑に進めていくためにも、
ユーザ･ベンダ双方がその内容を確認し合うことは非常に大切である。大きな開発トラブルに散見されることであるが、この工程で要件の漏れ、配慮漏れ等があり、後々のテスト工程等でそれが判明すると、この工程まで後戻りし、作業をやり直すことになってしまう。このようなことを防ぐためにも本条の検討会を的確に行うことが極めて重要である。そこで、2008 年 JEITA モデル契約では
本条のような規定はなかったが、本条では、外部設計検討会の開催を契約条件のレベルに引き上げている。
【適用ガイド】１．第 12 条の適用
外部設計検討会は第 12 条の連絡協議会の一環としての位置付けとなっており、第 12 条の規定が適用されることに注意しておく必要がある。特に次の 2 点に注意されたい。
（１）決定事項の拘束力と議事録
第 12 条第 5 項に決定事項として合意した事項の拘束力、同条第 6 項に議事録の作成について規定している。仕様のレビューは、1 次レビュー、2 次レビュー等数回行われることがある。そうしたとき 1 次レビュー会での決定事項が 2 次レビュー会で変更されることも生ずる。この場合、1
次レビュー会での決定事項には拘束力が生ずるため変更できないのではないかと誤解されることが推測される。しかし、法的には、ユーザ･ベンダが合意の上決定した事項であっても当該ユーザ･ベンダがそれを変更する合意も有効であり、後の合意が法的には優先することになる。
したがって、議事録の作成に当っては、変更した事項は前回の決定事項からの変更であることは分かるように記述しなければならない。
（２）出席者の範囲「外部設計」はユーザが業務の過程で使用する画面、帳票等を扱うものであるため、この検討会には、ユーザのシステム部門だけでなく、エンドユーザ部門まで広げてそのニーズが的確に反映できるようにする必要がある場合がある。第 12 条第第 3 項には、「協議に必要となる者の出席を相手方に求めること」ができるようになっている。ベンダにおいて業務内容に応じて特定のエ
ンドユーザ部門の人の出席が必要と考える場合には、契約上もその要請を行う権限が与えられていることを認識しておくべきである。
２．第 12 条の複数会議体のオプション条項案の利用
本条の規定内容は第 12 条の連絡協議会において｢外部設計｣の検討を行うこととしているが、日常的な仕様検討はこの連絡協議会の下にレビュー会などの別の会議体を設けて行い、連絡協議会では
当該レビュー会等から上がってくる重要事項について検討･決定することがある。このように複数種
63

類の会議体を設けて運営する場合、第 12 条の【適用ガイド】にオプション条項案を用意しているので、そちらを参照されたい。
【B 案】（外部設計書の納入）
第〇条

乙は個別契約に定める期日までに、外部設計書を外部設計書検収依頼書（兼納品書）とともに甲に納入する。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【逐条解説】
１．趣旨
外部設計書作成業務では、ベンダが主体となって外部設計書を作成するものであることから、完成した外部設計書をユーザに納入する義務があり、本条はその旨定めるものである。
【適用ガイド】１．｢検収依頼書｣
契約実務上、「検収」という用語を使うことがよくある。これは法律の用語ではなく、契約上慣習的に使用されている用語であり、請求や支払のトリガーとなるタイミングを示すものとして用いられる。売買では、検収完了時期として「受入検査合格時」、「納品時」、「出荷時」等のバリエーションが見られる。請負契約では「受入検査合格時」が多いと思われる。
請負契約のように納入物がある場合には、納品とともに検収依頼書をユーザに提出することがある。
【B 案】（外部設計書の承認及び確定）
第〇条

甲は、個別契約において定める期間（以下「外部設計書の点検期間」という。）内に外部設計

書が、第 17 条の規定により確定された要件定義書並びに第○条所定の外部設計検討会での決定事項に適合するか、及び論理的誤りがないか点検を行うものとし、適合すること及び論理的な誤りがないことを承認した証として甲乙双方の責任者が外部設計書承認書に記名押印するものとする。但し、点検の結果、外部設計書が、第 17 条の規定により確定された要件定義書及び外部設計検討会での決定事項に適合しない部分又は論理的誤りが発見された場合、乙は、協議の上定めた期限内に修正版を作成して甲に提示し、甲は再度上記点検、承認手続を行うものとする。
2.

外部設計書の点検期間内に甲が書面で具体的な理由を明示して異議を述べない場合には、甲は外部設計書の点検期間の満了をもって、外部設計書を承認したものとみなされる。

3.

前二項による甲の承認をもって、外部設計書は確定したものとする。

【2008 年 JEITA モデル契約との相違】

64

改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条はベンダが作成した外部設計書のユーザによる承認と「仕様の確定」手続きを明らかにするものであり、確定の前提としてユーザが外部設計書の内容を点検することとなっている。重要な点は次のとおりである。
（１）点検基準の明確化
請負契約では何をもって「仕事の完成」とするかその基準を明確にすることが重要である。
前条の外部設計検討会により外部設計書の内容をきちんと検討することとなっているが、外部
設計書作成業務では請負契約に基づく納入物の受入検査として、ユーザ自身が完成した外部設計
書の内容を点検しなければならない。その点検の基準は、検討会で検討した結果が的確に反映されているかどうか、要件定義書と適合しているかどうかのみならず、設計内容に論理的誤りがな
いかどうかという点も基準となる。
（２）外部設計書承認書の記名押印と確定
ユーザが承認したことを明らかにするために双方の責任者が外部設計書承認書に記名押印することになっており（第 1 項）、外部設計書の確定はこの記名押印の有無により明確になる（第 3 項）。
（３）修正が必要となった場合の対応
点検の過程で外部設計書の内容の修正が必要となった場合には、再度、ベンダは必要な修正を行わなければならない（第 1 項但書）。
この点につき、改正民法において新たに設けられた第 412 条の 2 においては、「債務の履行が契約その他の債務の発生原因及び取引上の社会通念に照らして不能であるときは、債権者は、その債務の履行を請求することができない。」と規定され、債権者の受ける権利に比して債務の履行に過分の費用を要する場面も、この「契約その他の債務の発生原因及び取引上の社会通念に照らして不能」の概念のもとで捉えられるべきもの15と考えられている。
この考えのもと、「外部設計書に、要件定義書及び外部設計検討会での決定事項との間に不適合な部分又は論理的誤りが存在する場合であっても、当該不一致の追完・修正のためには、ベンダに過分な費用が発生するとき」は、本条に以下のような条項を追加して追完・修正請求ができない場合を定めることで、ユーザが得られる利益に比べ、ベンダの損失が大きくなりすぎることを回避することが考えられる。
4.

第 1 項の定めに関わらず、外部設計書において、要件定義書および外部設計検討会での決定事項に不適合な部分または論理的誤りがある場合、当該不適合または論理的誤りの修正に過分の費用を要するときは、甲は乙に当該不適合又は論理的誤りの修正を請求することができないものとする。

（４）みなし規定
ユーザによる承認の迅速化を図るべく、点検期間を明確にするとともに、当該点検期間の経過
15『民法（債権関係）改正法の概要』61 頁（一般社団法人金融財政事情研究会、潮見佳男、2017 年 8 月）

65

により承認があったものとする「みなし規定」を設けた。
２．条文の背景
第 1 項で設けた点検期間を過ぎても、ユーザから具体的な理由を示されることなく承認が引き延ばされると、ベンダ側は、体制維持にかかる負担が大きくなる。
そうした事態を防ぐため、第 3 項ではユーザの異議がなく点検期間が過ぎた場合は、外部設計書が承認されたものとみなすことを定めている。
【適用ガイド】１．「検収」について前条において検収依頼書が外部設計書とともにユーザに提出される。このように契約実務上、「検収」という用語を使うことがよくある。これは法律の用語ではなく、契約上慣習的に使用されている用語であり、請求や支払のトリガーとなるタイミングを示すものとして用いられる。売買では、検収完了時期として「受入検査合格時」、「納品時」、「出荷時」等のバリエーションが見られる。請負契約では「受入検査合格時」が多いと思われる。
そこで、契約実務上、検収完了時期を条文上明確にしたい場合、本条第 4 項として「前項に基づく確定をもって検収完了とする。」あるいは「前項に基づく確定とともに乙所定の検収通知書に甲が記名押印することをもって検収完了とする。」などの条文を追加することが考えられる。
２．「検収」の効果
本条では、本件ソフトウェアがシステム仕様書と合致しているかに関する検査がユーザによりなされ、当該検査に合格したことにより「検収完了」とする旨定めており、さらに、第 29 条において、「検収完了」は、同条に定める契約不適合責任の定めが適用されるタイミングにもなっている。このように、検収書を出す行為は、本契約においては、ユーザ・ベンダの権利関係に影響を与えるものであることを認識しておく必要がある。
【B 案】（契約不適合責任）
第〇条

前条の確定後、外部設計書について要件定義書及び第○条所定の外部設計検討会での決定事

項との不一致又は論理的誤り（以下「契約不適合」という。）が発見された場合、甲は乙に対して当該契約不適合の修正を請求することができ、乙は、当該契約不適合を修正するものとする。但し、乙がかかる修正責任を負うのは、乙が契約不適合を重大な過失によって知らなかった場合であっても、前条の確定後○ヶ月以内に甲から契約不適合がある旨の通知がなされた場合に限るものとする。
2.

前項にかかわらず、外部設計書の修正に過分の費用を要する場合、乙は前項所定の修正責任を負
わないものとする。

3.

第 1 項の規定は、契約不適合が甲の提供した資料等又は甲の与えた指示等乙の責に帰さない事由
によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。

4．外部設計書作成に関する契約不適合に関する乙の責任は、本条及び第 53 条（損害賠償）にて明示的に規定された責任内容がすべてであるものとする。

66

【2008 年 JEITA モデル契約との相違】
改正民法における担保責任の制度設計が変わったことに伴い以下の点を変更した。詳細は第 1 編第 2
章第 2 節（1 頁）および第 29 条の解説（77 頁）を参照されたい。
①「瑕疵」を「契約不適合」に用語変更した。なお、「契約不適合」の定義は従来の「瑕疵」と同
じく「（外部設計書と）システム仕様書との不一致又は論理的誤り」としている（第１項）。
②乙が修正責任を負う場合の要件を「（瑕疵の修正の）請求」から「契約不適合がある旨の通知」に変更し、また、「乙が契約不適合を重大な過失によって知らなかった場合であっても」と限定した（第１項）。
③乙が修正責任を負わない場合の要件である「瑕疵が軽微であって」を削除した（第 2 項）。
④乙の契約不適合責任としては、本条および第 53 条のみを負うこととしている（第 4 項（新設））。

第３節 ソフトウェア開発業務【A 案

外部設計を準委任で行う場合】（ソフトウェア開発業務の実施）
第 24 条乙は、第 25 条所定の個別契約を締結の上、本件業務として前各節により確定したシステム

仕様書に基づき、内部設計からシステム結合までのソフトウェア開発業務を行う。
2.

ソフトウェア開発業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には、適時にこれに応ずるものとする。

【B 案

外部設計を請負で行う場合】（ソフトウェア開発業務の実施）
第 24 条乙は、第 25 条所定の個別契約を締結の上、本件業務として前各節により確定したシステム

仕様書に基づき、内部設計からシステムテストまでのソフトウェア開発業務を行う。
2.

ソフトウェア開発業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には、適時にこれに応ずるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、ソフトウェア開発業務の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本節は、前節までに確定したシステム仕様書（第 1 節で確定した要件定義書および第 2 節で確定
した外部設計書）に基づき、ソフトウェア開発業務をベンダが行う場合の規定である。ソフトウェ
ア開発業務の作業形態としては、ユーザが主体となる準委任型とベンダが主体となる請負型が考えられるが、ソフトウェア開発におけるベンダの作業は、一般的に請負的作業が中心となることから、本契約では請負型を前提としている。

67

本節におけるソフトウェア開発業務には、システム方式設計（システム内部設計）、ソフトウェア
設計、プログラミング、ソフトウェアテスト、システム結合が含まれる（各フェーズの説明は本書
7 頁を参照されたい。）。システム結合後のシステムテストについては、ベンダが請負型で実施する場
合（上記で B 案を選択する場合）は本節におけるソフトウェア開発業務に含まれ、準委任型で実施する場合（上記で A 案を選択した場合）は、次節のソフトウェア運用準備・移行サービス段階（準委任型）の作業に含まれる。A 案・B 案の選択方法については、「2. 条文の背景」を参照されたい。
第 2 項は、ユーザの協力義務を定めるものである。請負型のソフトウェア開発業務においては、
ソフトウェアの作成を行い完成させる責任はベンダにあるが、満足度の高いソフトウェアを作成するためには、ユーザの積極的な協力（システム仕様の解釈の確認等）が不可欠であるため、ユーザ
はベンダから必要な協力の要請があれば適時にこれに応じなければならない。
２．条文の背景（１）システムテスト
システムテストは、ソフトウェアが外部設計の仕様どおりに作成されたかを検証する工程であり、実務上請負型で行われるケースが多いが、一部のユーザは自社でシステムテストを行うことを希望することもある。システムテストを「準委任型」とするか「請負型」とするかは、システ
ム外部設計を「準委任型」とするか、「請負型」とするか（第 19 条において規定）を踏まえて決定するのが望ましい。
本条においてはＡ案がシステムテストを準委任型で行う場合、Ｂ案がシステムテストを請負型で行う場合であり、外部設計との対応関係についての考え方は上記のとおりである。また、第 30条においても A 案または B 案を選択することとなるが、これは本条で A 案・B 案いずれを選択するかによる。これらの選択方法について表４にまとめたので参照されたい。
表４

第 24 条と第 30 条の選択関係

第 24 条（ソフトウェア開発業務）

第 30 条（運用準備・移行支援）

外部設計 A 案

A 案（内部設計～システム結合）

A 案（システムテスト～）

外部設計 B 案

B 案（内部設計～システムテスト）

B 案（導入受入支援～）【適用ガイド】１．マルチベンダ方式（工程分割発注）の場合の、前工程で作成されたシステム仕様書
ユーザが工程ごとに異なるベンダに分割発注し、システム仕様書の作成とその後のソフトウェア
開発業務を異なるベンダが行うことがある。また、同一ベンダが行う場合であってもユーザがシス
テム仕様書を独自にあるいは他ベンダの協力を得て変更を加えていることがある。
ソフトウェア開発業務は、システム仕様書に基づいて行なわれるものであるから、上記のような場合、ベンダは、ユーザの用意したシステム仕様書を精査し、その業務が遂行可能であることを確認してからソフトウェア開発業務を受注すべきである。また、ソフトウェア開発業務の個別契約において定める委託料を見積もる上でも、システム仕様書の内容の確認は必要である。
しかし、時間的な制約があるなど、受注前に精査することが難しい場合は、次のオプション条項
により、受託後にシステム仕様書の精査を行い、必要に応じて納期や委託料などの個別契約の条件の変更、場合によっては契約の解除ができるようにしておく。

68

（システム仕様書の補正）
第○条

乙は、ソフトウェア開発業務の遂行に当って次の各号のいずれかに該当する場合、第 25 条所定の個別契約書に定める期間内に当該システム仕様書の内容を精査することができる。甲は、乙の要請に基づいて、乙の精査に必要かつ十分な資料を提供し、説明を行うものとする。
①乙が本契約及び個別契約に基づき要件定義作成支援業務及び外部設計書作成支援業務を受託せず、甲の用意したシステム仕様書に基づいてソフトウェア開発業務を行う場合②乙が本契約及び個別契約に基づき要件定義作成支援業務及び外部設計書作成支援業務を受託し、第 17 条に基づく要件定義書の確定及び第 22 条に基づく外部設計書の確定がなされたにもかかわらず、その後ソフトウェア開発業務に関する個別契約が締結されるまでの間に、甲により当該システム仕様書が変更され、当該変更されたシステム仕様書に基づいてソフトウェア開発業務を行う場合③乙が本契約及び個別契約に基づき要件定義作成支援業務及び外部設計書作成支援業務を受託したにもかかわらず、第 17 条に基づく要件定義書の確定及び第 22 条に基づく外部設計書の確定がなされず、甲が別途用意したシステム仕様書に基づいてソフトウェア
開発業務を行う場合
2.

前項の精査の結果、当該システム仕様書に不十分な事項が発見された場合、乙は甲に対し、当該システム仕様書の修正を求めることができる。なお、当該修正に関して、甲が乙に要件定義作成支援業務または外部設計書作成支援業務若しくは外部設計書作成業務を委託する場合は、第 15 条または第 20 条に基づき別途個別契約を締結するものとし、シス
テム仕様書確定の手続きは、第 17 条または第 22 条によるものとする。

3.

前項におけるシステム仕様書の修正に伴いソフトウェア開発業務に関する個別契約の条件に変更が生じうる場合は、第 33 条（本契約及び個別契約内容の変更）の手続きによるものとする。なお、この場合、前項にかかわらず、第 33 条に基づき変更契約を締結したときをもって、修正されたシステム仕様書は確定したものとする。

4.

第 2 項において甲が修正に応じない場合、または前項における第 33 条の手続きにおいて甲乙間の協議開始後○日以内に当該協議が調わない場合は、第 38 条を準用する。

（１）ベンダがソフトウェア開発業務から受託する場合のパターン（第 1 項）
本オプション条項では、あらかじめユーザが用意したシステム仕様書に基づき、ベンダがソフト
ウェア開発業務から受託する場合として次のパターンを想定し、それらに対応できる条文としている。
①要件定義･外部設計までと異なるベンダがソフトウェア開発業務を行う場合②要件定義･外部設計までを受託したベンダがソフトウェア開発業務を受託するが、一旦確定したシステム仕様書をユーザが独自にあるいは第三者に委託して当該システム仕様書を変更している場合③要件定義･外部設計までを受託したベンダがソフトウェア開発業務を受託するが、ユーザがシス
テム仕様書を確定せず、ユーザが独自にあるいは第三者に委託してシステム仕様書を用意して
いる場合

69

（２）システム仕様書の内容が不十分だった場合
精査の結果、システム仕様書の内容が不十分であれば、ベンダはユーザにシステム仕様書の修正を要求できる。修正はユーザ自らが行うことが前提であるが、ユーザが当該修正に関してベンダに支援を求める場合は、必要に応じて要件定義作成支援業務または外部設計書作成支援業務の個別契約を締結する（第 2 項）。
また、システム仕様書の修正によって、追加費用が発生したり、納期を延伸する必要が生じるな
ど、ソフトウェア開発業務の条件を変更する必要が生じる場合は、第 33 条にしたがいソフトウェア
開発業務に関する個別契約の変更契約を締結する。ソフトウェア開発業務に関する個別契約を変更する必要がない場合は、第 17 条または第 22 条の手続きに従ってシステム仕様書を確定するが、個別契約を変更する場合は、変更契約が締結されない限り、修正されたシステム仕様書が確定されない点に注意を要する（第 3 項）。
（３）解約権（第 4 項）
第 2 項において、ソフトウェア開発業務に不十分であることが判明したシステム仕様書について
ベンダが修正を要求してもユーザがこれに応じない場合は、ベンダは、そのようなシステム仕様書をもとにソフトウェア開発業務を実施する義務を負うことのないよう、個別解約を解除できるようにしておくことが望ましい。
また、システム仕様書の修正により、ソフトウェア開発業務に関する個別契約の条件変更が必要となる場合は第 33 条にもとづき個別契約を変更することとなるが、変更内容につきユーザ・ベンダ
間で合意できない場合は、第 38 条を準用することにより、ユーザ・ベンダ双方が本契約とソフトウェ
ア開発業務に関する個別契約を解約できるものとし、ベンダはそれまでに発生した費用を請求できることとしている。
（４）システム仕様書の精査費用等
条文上では、ベンダによるシステム仕様書の精査にかかる費用について触れていないが、当該精査費用については、ソフトウェア開発業務の委託料の見積とともに、個別契約において定めておくことが望ましい。
（ソフトウェア開発業務に係る個別契約の締結）
第 25 条甲及び乙は、当該ソフトウェア開発業務について、第 4 条第 1 項に定める取引条件を協議の上決定し、ソフトウェア開発業務に係る個別契約を締結する。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本契約は「基本契約」として、複数の個別契約に共通する条件、基本となる条件を定めており、ベンダが行う作業内容、ユーザが行うべき作業内容およびそれらのスケジュールならびにユーザが支払うべき代金などの具体的な債務内容は個別契約において定められることになる。本条は、ソフ
トウェア開発業務に関する具体的な債務内容を特定する個別契約の必要性を明確にするものである。

70

【適用ガイド】
１．個別契約の構成
個別契約の締結に際しては、第 4 条第 1 項に定める各取引条件をユーザ・ベンダ間で協議しておくことが必要である。
個別契約のサンプルは本書付録④（169 頁）を参照されたい。なお、このサンプルでは役割分担
等の詳細は別表に記載される構成となっている。この別表は個別契約書に袋とじし、一体としておくことが原則である。もし、例外的に別々とする場合には、当該別表が個別契約の別表であることが明らかになるよう別表の表紙に「本書は〇年〇月〇日付ソフトウェア開発業務に関する個別契約
第〇項の別表である」など明記しておかなければならない。また、当該別表の表紙には、ユーザ・ベンダ双方の合意を明らかにするために双方の記名押印も必要となる。
２．改正民法による影響
民法改正により、第 29 条におけるベンダの責任は、「瑕疵担保責任」から「契約不適合責任」と変更されたものの、改正前民法の解釈においても、瑕疵担保責任における「瑕疵」は、当事者の合意、契約の趣旨に照らし、通常または特別に予定されていた品質・性能を欠く場合をいうと考えられていた。改正民法の「契約の内容に適合しない」との文言はこのような趣旨を明確にしたものと考えられることから、「瑕疵」と「契約不適合」の内容はほぼ同様であるといえこの変更については、
実務上、開発現場に大きな影響があるものではないと考えられる。
ただし、改正民法においては、ベンダは、仕事の結果が「契約の内容に合致していない」場合に契約不適合責任を負うことになり、条文上「契約への適合性」が明記されたことから、従来同様（またはそれ以上に）、契約の内容が重要視されていると考えられる。
そのため、第 4 条における取引条件の明確化および連絡協議会の開催によって、継続的にユーザ･ベンダ間の合意形成に努める必要がある。
（納入物の納入）
第 26 条乙は甲に対し、個別契約で定める期日までに、個別契約所定の納入物を検収依頼書（兼納品書）とともに納入する。
2.

甲は、納入があった場合、次条の検査仕様書に基づき、第 28 条（本件ソフトウェアの検収）の定めに従い検査を行う。

3.

乙は、納入物の納入に際し、甲に対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には、速やかにこれに応じるものとする。

4.

納入物の滅失、毀損等の危険負担は、納入前については乙が、納入後については甲が、それぞれこれを負担するものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】71

１．趣旨
本条では、完成した本件ソフトウェアを含む納入物の納入について定めている。
（１）納入物
ここで納入物とは、本件ソフトウェアのプログラムを含め、システム内部設計書、ソフトウェ
ア設計書、ソフトウェアテスト仕様書および結果報告書、システムテスト仕様書および結果報告書、システム運用マニュアル、ユーザ利用マニュアル等が挙げられるが、何を納入物とするかは、
ソフトウェア開発業務の個別契約で定められる。
これら納入物は、検収依頼書（兼納品書）とともに納入され、ユーザによる検収の対象となる。
（２）第 2 項
納入物のうち本件ソフトウェアは、ユーザが次条において作成する検査仕様書に基づき第 28 条の手続きをもって検査される。
（３）第 3 項
納入に際する乙の協力とは、ユーザの事業所内に搬入する場合あるいはユーザの事業所内に設置されているサーバシステム等にインストールするような場合を想定している。このような場合にはユーザは、ベンダによる自己の事業所への立ち入りあるいはサーバシステム等の操作を許容するなどの協力が当然必要となる。
（４）納入物の危険負担の移転時期（第 4 項）
危険負担とは、納入物がユーザ・ベンダどちらの責にも帰すことのできない事由により滅失・毀損等してしまった場合に、ユーザ・ベンダのどちらがそのリスクを負うかという問題であるが、ここでは納入前と納入後で分けている。納入物が滅失・毀損した場合に発生が想定される費用は、
ソフトウェアの記録媒体、ドキュメント類のコピー代等再作成に要する費用であり、ベンダのもとにマスターコピーが残っているのであれば、大きな負担にはならないとは思われるが、定めておくことが望ましい。
なお、納入物の所有権の移転については第 6 章の第 43 条（納入物の所有権）において定めている。
【適用ガイド】１．検収依頼書（兼納品書）
納入物とともに納入する検収依頼書には、検収依頼書の発行日、個別契約書に定められる作業内
容、納入物、納品場所、請求金額等を明記し、責任者・担当者等が記名押印しておく。なお、サンプルについては、2007 年経済産業省報告書 126 頁の参考文書 9 を参照されたい。
（検査仕様書の作成及び承認）
第 27 条甲は、乙と協議の上、システム仕様書に基づき前条の納入物のうち本件ソフトウェアの検査の基準となるテスト項目、テストデータ、テスト方法及びテスト期間等を定めた検査仕様書を作成し、乙に提出するものとし、乙の責任者はシステム仕様書に適合するかの点検を行い、適合することを承認する場合、検査仕様書に記名押印の上、甲に交付して承認するものとする。但し、点検の結果、検査仕様書にシステム仕様書に適合しない部分が発見された場合、甲は、協議の上定めた
期限内に修正版を作成して乙に提示するものとし、乙は再度上記点検、承認手続を行うものとする。
2.

乙の責任者は、個別契約で定める期間（以下「検査仕様書点検期間」という。）内に検査仕様書の72

点検を終えるものとし、乙の責任者が、検査仕様書点検期間内に書面による具体的な理由を明示した異議の申出をすることなく検査仕様書を承認しない場合、当該期間の満了をもって検査仕様書は承認されたものとする。
3.

甲は、甲が行う検査仕様書の作成についての支援（以下「検査仕様書作成支援業務」という。）を乙に委託する必要がある場合、第 25 条に定めるソフトウェア開発業務に関する個別契約を締結するときまでに、乙に検査仕様書作成支援業務の委託に関する申し込みを乙に行い、検査仕様書作成支援業務に関する個別契約を別途締結することができる。

4.

乙による検査仕様書作成支援業務については、外部設計書作成支援業務に関する第 3 章第 2 節の規定を準用するものとする。但し、「外部設計書」を「検査仕様書」に、「外部設計検討会」を「連絡協議会」に、「要件定義書及び外部設計検討会での決定事項」を「システム仕様書」に読み替える。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は、第 26 条において納入された納入物のうち、本件ソフトウェアの検収（受入検査ともいわれる）を行う際に基準となる検査仕様書の作成・承認手続きについて定めている。検査に合格し、検収が完了することにより、ソフトウェア開発業務の完了となるため、検査仕様書を適切に作成し、合格基準をあらかじめ明確に取り決めておく必要がある。
（１）検査仕様書の作成者
納入物の検収はユーザが実施すべきものであるとの観点から、第 1 項において検査仕様書の作成はユーザが行うものであることを明確にしている。そのうえで、検査仕様書作成について乙の支援が必要な場合は、第 3 項において当該支援業務に関する個別契約を別途締結することとしている。
また、ベンダに検査仕様書作成支援業務を委託する場合は、ソフトウェア開発業務に関する個別契約を締結するときまでにユーザはベンダに申し込まなければならない（第 3 項）。検査仕様書の作成は本件ソフトウェアの完成までに行われる必要があるが、本件ソフトウェア完成間近にベンダが受託することにならないように、外部設計書確定後の早い段階でユーザが単独で作成するのか、ベンダが作成を支援するのかを決めておくことが望ましいからである。検査仕様書作成の時期については、次条の条文解説の図を参照されたい。
（２）みなし承認
ベンダは当該検査仕様書の承認を行うが、承認が不必要に延びることを避けるため、点検期間を設けたうえ、みなし承認を定めている。
２．条文の背景（１）検査仕様書
従来、納入したソフトウェアの検収につき、ユーザの検査がなかなか完了せず、代金回収が遅くなる、ユーザからの要求による修正作業の工数が増加するという問題があり、「仕様」の不明確73

さとともに「検査基準」の不明確さがこの一因となっていた。
ソフトウェア開発請負は、「仕様」に合致したソフトウェアを開発することが最終目的であるため、「仕様」や検査基準があいまいであれば、ソフトウェアが仕様に合致するものであるか否かについて、ユーザ・ベンダ間で齟齬が出る。この問題への対応として、本契約は多段階契約とし、検査仕様書の作成を義務付けている。
（２）検査仕様書作成の基準となる文書についての考え方
検査仕様書については、第 1 項においてシステム仕様書に基づいて作成することとされている。
（第 1 項）
この点、本書 41 頁図７のいわゆるⅤ字モデルにおいて、ソフトウェア開発における「要件定義」、「外部設計」工程とテスト工程は、以下のように対応している。
①要件定義←→ 運用テスト②システム設計（外部設計） ←→ システムテスト③システム方式設計（内部設計） ←→システム結合（結合テスト）（３）検査仕様書とシステム仕様書の関係について
また、2007 年経済産業省報告書に「経営者は情報システムが事業に貢献しているかを見、業務部門は自らが定義した要件が実現されているかを運用テストで確認する。」16とあるとおり、要件定義の内容が適切であったかどうかは運用テストで検証されるものである。したがって、運用テ
スト以前においては、①ユーザが作成した要件定義書・外部設計書、または、②ユーザが作成した要件定義書およびその内容を受けてベンダが作成した外部設計書、つまりシステム仕様書の記
述内容のとおりに本件ソフトウェアが作成されたかどうかが検証されることになる。このとき、システムテストにおいては、本件ソフトウェアが外部設計書どおりに作成されているかどうかが検証されることになるが、ユーザによる検査も運用テスト以前に行われる以上、そこで検証されるのも、本来は外部設計書どおりに本件ソフトウェアが作成されているかどうかであると考えるのが整合的であると言える。
ただし、これは、外部設計書において要件定義の内容が完全に詳細化・具体化されていることが前提であり、実際には、要件定義から外部設計に転換されず、直接内部設計に反映される仕様もあるため、そのような要件定義の内容も検査する必要がある場合を考慮し、検査仕様書作成のベースとするものをシステム仕様書（その定義については第 2 条を参照されたい。）としている。
このように検査は、システム仕様書に基づいて作成される検査仕様書に従って行われるべきであるが、現実には、ユーザは運用テストで行うべき実際の様々な業務パターンに基づきテストを行い、要件定義で想定外のオペレーションや特殊処理が発生し（操作ミスなどとも相俟って）検収がなかなか終わらない場合もある。このような内容は、本来は要件定義が適切であったかどうかの問題であり、ユーザの業務すべてを把握することができないベンダが負うことができる責任の範囲を超えているといえよう。
検査基準を明確にしない場合には上記のような問題がしばしば起こり得るため、これを回避するためには、ユーザは、検査の基準ともなる検査仕様書をシステム仕様書に基づき作成し、ベンダは検査仕様書がシステム仕様書に基づき作成されていることを確認しなければならない。
（４）検査および検査仕様書の内容
検査仕様書の内容は、上述のとおり、内部設計に直接反映された要件定義の内容が一部加えら
16『2007 年経済産業省報告書』30 頁

74

れることがある以外は、外部設計書どおりにソフトウェアが作成されたかどうかを検証するシス
テムテストの内容を念頭において、テスト項目、テストデータ、テスト方法等を定めることとなる。
また、第 28 条における検査は、本節におけるソフトウェア開発業務の完了を確認するための手続きであり、検査仕様書に従って、①システムテストを準委任型で行う場合はソフトウェアテス
トおよび結合テストで得られた結果を踏まえて、②システムテストを請負型で行う場合はシステ
ムテストで得られた結果を踏まえて、ユーザ自らが実施するのが原則である。
【適用ガイド】１．検査仕様書作成支援業務に関する個別契約書（第 3 項）
第 3 項に基づき個別契約書を作成する場合は、本書付録④（169 頁）の個別契約書のサンプル（準委任型）を使用して作成することができる。
（本件ソフトウェアの検収）第 28 条納入物のうち本件ソフトウェアについては、甲は、個別契約に定める期間（以下「検査期間」という。）内に前条の検査仕様書に基づき検査し、システム仕様書と本件ソフトウェアが合致するか否かを点検しなければならない。
2.

甲は、本件ソフトウェアが前項の検査に適合する場合、検査合格書に記名押印の上、乙に交付す
るものとする。また、甲は、本件ソフトウェアが前項の検査に合格しない場合、乙に対し不合格となった具体的な理由を明示した書面を速やかに交付し、修正又は追完を求めるものとし、不合格理由が認められるときには、乙は、協議の上定めた期限内に無償で修正して甲に納入し、甲は必要となる範囲で、前項所定の検査を再度行うものとする。

3.

検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。

4.

本条所定の検査合格をもって、本件ソフトウェアの検収完了とする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条では、納品された本件ソフトウェアの検収手続きを定めている。
（１）検査基準・検査期間の明確化
請負契約では何をもって「仕事の完成」とするかその基準を明確にすることが重要である。本節におけるソフトウェア開発業務において仕事の完成とは、本件ソフトウェアの完成であり、その完成の基準とは、システム仕様書と本件ソフトウェアとの合致である。
第 1 項において、ユーザは、検査期間内に、検査仕様書に基づき本件ソフトウェアを検査し、システム仕様書と本件ソフトウェアが合致するか否か点検しなければならない。検査期間については、本条で定めておく方法もある。

75

（２）検査に合格しない場合
第 2 項では、本件ソフトウェアが第 1 項の検査に合格しない場合は、ユーザはベンダに具体的理由を示し、追完または修正を求めることができる。不合格理由が認められれば、ベンダは無償で本件ソフトウェアを修正しなければならない。
この点につき、改正民法において新たに設けられた第 412 条の 2 においては、「債務の履行が契約その他の債務の発生原因及び取引上の社会通念に照らして不能であるとき、債権者はその債務の履行を請求することができない」と規定され、債権者の受ける権利に比して債務の履行に過分の費用を要する場面も、この「契約その他の債務の発生原因及び取引上の社会通念に照らして不能」の概念のもとで捉えられるべきもの17と考えられている。
この考えのもと、「システム仕様書と本件ソフトウェアの不一致が存在する場合であっても、契約上本ソフトウェア全体から見た場合に、当該不一致の追完・修正のためには、ベンダに過大な費用が発生するとき」は、本条に以下のような条項を追加して、追完・修正請求ができない場合を定めることで、ユーザが得られる利益に比べ、ベンダの損失が大きくなりすぎることを回避することが考えられる。
5.

第 1 項に関わらず、本件ソフトウェアにおけるシステム仕様書との不一致につき、当該不一致の修正または追完に過分の費用を要するときは、甲は乙に当該不一致の修正を請求することができないものとする。

（３）みなし検査合格
第 1 項で設けた検査期間を過ぎても、ユーザから具体的な理由を示されることなく検収が引き延ばされると、ベンダ側も体制の維持が困難になる。そうした事態を防ぐため、第 3 項ではユー
ザの異議がなく検査期間が過ぎた場合は、検査に合格したものとみなすことを定めている。
図１０

17

検収手続き

『民法（債権関係）改正法の概要』61 頁（一般社団法人金融財政事情研究会、潮見佳男、2017 年 8 月）

76

２．条文の背景（１）検収手続きの明確化
通常のソフトウェア開発工程では、システムテストで仕様との合致を確認した後、運用テスト
で実運用に耐え得るか否かを確認する。
その一方で、運用テストとユーザの検査の時期が重複し、検査基準が不明確であった場合、本来は仕様との合致を問題とすべき検査において、運用テストで問題とされるべき改善要求や機能追加要求がなされることがあり、場合によっては、検収不合格になることがあった
上記の問題を踏まえ、本条において検収手続きの明確化を図っている。
【適用ガイド】１．「検収」について
契約実務上、「検収」という用語をよく使うことがある。これは法律の用語ではなく、契約上慣習的に使用されている用語であり、請求や支払のトリガーとなるタイミングを示すものとして用いられる。売買では、検収完了時期として「受入検査合格時」、「納品時」、「出荷時」等のバリエーションが見られる。請負契約では「受入検査合格時」が多いと思われるが、本条においても同様に、本条所定の「検査合格」をもって「検収完了」としている。
２．「検収」の効果
本条では、本件ソフトウェアがシステム仕様書と合致しているかに関する検査がユーザによりなされ、当該検査に合格したことにより「検収完了」とする旨定めており、さらに、第 29 条において、「検収完了」は、同条に定める契約不適合責任の定めが適用されるタイミングにもなっている。このように、検収書を出す行為は、本契約においては、ユーザ・ベンダの権利関係に影響を与えるものであることを認識しておく必要がある。
（契約不適合責任）第 29 条前条の検収完了後、納入物についてシステム仕様書との不一致（以下「契約不適合」という。）が発見された場合、甲は乙に対して当該契約不適合の修正を請求することができ、乙は、当該契約不適合を修正するものとする。但し、乙がかかる修正責任を負うのは、乙が契約不適合を重大な過失によって知らなかった場合であっても、前条の検収完了後○ヶ月以内に甲から契約不適合がある旨の通知がなされた場合に限るものとする。
2.

前項にかかわらず、納入物の修正に過分の費用を要する場合、乙は前項所定の修正責任を負わないものとする。

3.

第 1 項の規定は、契約不適合が甲の提供した資料等又は甲の与えた指示等乙の責に帰さない事由
によって生じたときは適用しない。但し、乙がその資料等又は指示等が不適当であることを知りながら告げなかったときはこの限りでない。

4. 契約不適合に関する乙の責任は、本条及び第 53 条（損害賠償）にて明示的に規定された責任内容がすべてであるものとする。
【2008 年 JEITA モデル契約との相違】
改正民法における担保責任の制度設計が変わったことに伴い以下の点を変更した。詳細は第 1 編第 2

77

章第 2 節（1 頁）および以下【条文解説】を参照されたい。
（１）「瑕疵」を「契約不適合」に用語変更した。なお、「契約不適合」の定義は従来の「瑕疵」と同じく「（納入物と）システム仕様書との不一致」としている（第 1 項）。
（２）乙が修正責任を負う場合の要件を「（瑕疵の修正の）請求」から「契約不適合がある旨の通知」に変更し、また、「乙が契約不適合を重大な過失によって知らなかった場合であっても」と限定した（第 1 項）。
（３）乙が修正責任を負わない場合の要件である「瑕疵が軽微であって」を削除した（第 2 項）。
（４）乙の契約不適合責任としては、本条および第 53 条のみを負うこととしている（第 4 項（新設））。
【条文解説】
１．趣旨
本条は、納入物に関する契約不適合の責任について定めている。
（１）「契約不適合」の定義（第 1 項）
第 1 編第 2 章第 2 節（1 頁）に記載の理由のとおり、「契約不適合」の定義は、2008 年 JEITA
モデル契約における「瑕疵」の定義を継承し、「（納入物と）システム仕様書との不一致」があることとしている。
改正民法における契約不適合とは、契約の性質、契約をした目的、契約締結に至る経緯その他の事情に基づき、取引通念を考慮して定まるものと考えられるが（改正前民法の「瑕疵」の概念とほぼ同様であるといえる）、実際の個々のソフトウェア開発取引における「契約不適合」の意義、判断基準は明らかではない。そのため、契約上、「契約不適合」の判断基準を明確化する必要がある。
本契約では、ベンダが開発すべきソフトウェアの仕様は、システム仕様書において定めること
としており、ベンダの責務は当該システム仕様書に合致した納入物の開発となることから、このような定義としている。
なお、ソフトウェアの不具合（バグ等）が「契約不適合」に該当するか否かについては、改正前民法の「瑕疵」に関する判断が「契約不適合」でも同様に維持されるであろうと考えられ、完成したソフトウェアに一定程度の不具合が残存することは事実上不可避であることから、引き続きソフトウェアの不具合（バグ等）が必ずしも「契約不適合」に該当することにはならないと考えられる。
この点に関しては、ベンダがプログラムにバグがあることの指摘をユーザから受けた後、遅滞なく修正を終え、またはユーザと協議の上相当と認める代替措置を講じたときは、当該バグの存在をもってプログラムの瑕疵と評価することはできないとされた裁判例（東京地裁平成 9 年 2 月
18 日判決、東京地裁平成 14 年 4 月 22 日判決）がある。
（２）契約不適合責任の期間（権利存続期間の起算点）（第 1 項）
改正民法において、契約不適合責任の期間は、「注文者（ユーザ）が契約不適合を知ったときから 1 年以内」（改正民法第 637 条第 1 項）とされたが、第 1 編第 2 章第 2 節（1 頁）に記載のとおり、2008 年 JEITA モデル契約における瑕疵担保責任の責任期間（起算点）を継承し、契約不適
合責任の期間を「検収完了後○ヶ月以内」としている。1818

担保責任期間の新旧解説は、本書付録②（166 頁）「改正民法施行後の契約における売買・請負の担保責任のあり方つ

78また、改正民法では、ベンダが契約不適合があることを知っていた場合、または重大な過失により知らなかった場合は、例外として契約不適合責任の期間が適用されないとされた（改正民法第 637 条第 2 項）が、当該ベンダの主観・過失の程度を巡り、ユーザ・ベンダが過去に遡って事実調査することはコスト面で両社の過重な負担となり得る。
この点、契約不適合があることを知っていたベンダについてまで敢えて契約不適合責任の期間を制限して保護する合理的な理由はないと考えられるため、本契約では、「乙が契約不適合を重大な過失によって知らなかった場合であっても」とベンダに重大な過失がある場合のみ特定して定め、この場合を含めた契約不適合責任の期間としている。
（３）納入物の修正に過分の費用を要する場合（第 2 項）
改正前民法第 634 条第 1 項但書では「瑕疵が重要でない場合において、その修補に過分の費用を要するとき」は修正を請求できないとされており、2008 年 JEITA モデル契約ではこのルールに沿った規定を置いていたが、改正民法ではこの規定が削除された。
なお、改正民法第 412 条の 2 第 1 項が履行不能に関する一般的な規定を置いており、『修補に過分の費用を要する場合には「契約その他の債務の発生原因及び取引上の社会通念に照らして不能である』と評価され、本条 1 項により修補請求はできないものと解される」19ため、この改正民法の解釈に沿った条件とするよう、第 2 項にて、納入物の修正に過分の費用を要する場合について
は、ベンダは修正責任を負わないこととしている。
なお、「過分の費用を要する」という要件を満たすか否かは、「修補に必要な費用と修補によって生ずる利益とを比較して判断する」20とされている。これらを比較して判断するという考え方はソフトウェア開発取引においても合理的なものと考えられる。
（４）過失責任（第 3 項）
第 3 項は、ほぼ改正民法第 636 条に準じた規定としているが、ユーザの提供資料・指示に加え、その他のベンダの責に帰さない事由に起因して生じた契約不適合についてもベンダは責任を負わない旨を定めている。これは、契約不適合の修正責任を第 53 条の損害賠償責任と同じくベンダの過失責任とするものであるが、その理由は次のとおりである。
①

情報システムは、様々なベンダから提供されるハードウェアおよびソフトウェアから構成されており、かかるシステムを稼動環境とする業務アプリケーションは、それらのハードウェ
アベンダあるいはソフトウェアベンダが提供する情報（例えば、インタフェース情報、機能説明等）を前提として開発される。
しかも、かかるソフトウェアあるいはハードウェアがブラックボックス化している現在において、ユーザがそれらを別途調達する場合はもちろん、ベンダが SIer として業務アプリケー

ションの開発を行うとともにそれらのハードウェアおよびソフトウェアを調達する場合であっても、ベンダは、自社製品以外の製品については、ハードウェアベンダあるいはソフト
ウェアベンダが提供･開示する情報に依拠せざるを得ないのが実情である。
そこで、それらのハードウェアベンダあるいはソフトウェアベンダから開示された情報に誤りあるいは一部情報の欠如がある場合、当該開示情報に依拠して作成したソフトウェアの処理結果に誤りが生ずることなどがある。このような場合にまで当該ソフトウェアの契約不いて」（2018 年 5 月 22 日付、JEITA 法務・知的財産部会 改正民法対応 TF 公表資料）に整理されているため、併せて参照されたい。
19 『実務解説
改正債権法』103 頁（弘文堂、日本弁護士連合会、2017 年 7 月）
20 『民法（債権関係）部会資料第 46』16 頁

79

適合に対する責任をベンダに課すことは過重なものと思われる。
このため、本条においては、当該契約不適合につきベンダに原因がある場合に責任が発生する内容としている。
②

近年のシステム開発は、更に大規模化・複雑化してきており、そのような中ではベンダの帰責事由によらない契約不適合が生じることもあり得る。改正民法上の契約不適合責任は、
有償契約一般の原則として整理されているところ、単純な売買や請負の場合とは異なり、システム開発においてベンダの帰責事由によらない契約不適合が生じた場合にまでベンダが責任を負うとするのは、当事者間の責任分担としてバランスを欠くと考えられる。
改正民法第 636 条において、契約不適合がユーザの指図によって生じた場合、ベンダは契③

約不適合責任を負わないとしているように、もともと一定の制限が設けられているため、ソフトウェア開発に特有の事情を鑑みて一定の制限を設けることは不合理でないと考える。
（５）契約不適合責任の内容（第 4 項）
①代金減額請求について
改正民法では、契約不適合がある場合のユーザの権利として、代金減額請求が追加された（改正民法第 559 条、第 563 条）が、第 1 編第 2 章第 2 節（1 頁）に記載の理由のとおり、契約不適合責任として代金減額請求を契約条件として定めないこととしている。
代金減額請求権は、ユーザが引き渡された納入物を、契約内容に適合したものと擬制し、その差額を代金額に反映させるという意味で、契約の改訂を行うものである21。そのため、代金減額請求を行う場合、減額する部分については履行の追完を請求しないことが前提となっており、ユーザは、代金減額請求と減額部分に関する履行追完請求は、両立して請求できない。
なお、代金減額請求と、契約不適合に起因しユーザに生じた追加コストの損害賠償請求は、両立して請求できると考えられる。
このような代金減額請求については、納入物と報酬のバランスをとるための救済手段の１つ
としては合理性のある制度設計と一般的には考えられるが、改正民法では、 代金の減額の幅は「不適合の程度」に応じるところ、ソフトウェア開発契約においては、この「不適合の程度」
を推し量ることが困難であり、潜在的な訴訟リスクを伴う。
この点、例えば、契約書において「不適合の程度」について具体的に規定することによって、納入物に契約不適合があった場合のリスクを定量化することは考えられるが、ソフトウェア開発においては、開発契約締結の時点で開発対象のソフトウェアの仕様自体を固めることすら難
しく、「不適合の程度」を契約書に具体化することは更に困難であると思われる。
仮に訴訟になった場合には、ユーザ・ベンダ間で、代金の減額の幅の根拠となる「不適合の程度」をめぐって争いになる状況は避けられないと思われ、このような状況に陥ることは両社にとって過重な負担となるため望ましくない。
よって、ソフトウェア開発取引においては、代金減額請求を採用することは難しい。
②契約解除について請負契約において仕事の目的物に「契約不適合」があった場合の責任内容については、改正
民法上、（a）履行の追完（修補、代替物・不足分引渡）、（b）代金減額、（c）損害賠償、（d）契
約解除のそれぞれが認められている。
しかし、ソフトウェア開発においては、多額の投資を伴うケースも多く、契約不適合がある
21 『一問一答

民法（債権関係）改正』278・279 頁（商事法務、筒井 健夫、村松 秀樹、2018 年 3 月）を参照されたい。

80

からといって、直ちに契約を解除していたのでは、これまでの投資が無駄になり、社会経済的にも損失が大きい。契約が解除となれば、両者が掛けた金銭的・時間的コストや労力は水泡に帰することになる。したがって、検収が完了したソフトウェアについては、契約を存続させた上で、契約不適合の修正、契約不適合に起因する損害の賠償により問題を解決する方が妥当である。
したがって、本契約では、契約不適合責任として契約解除を契約条件として定めないこととしている。
なお、上記はあくまでも契約不適合に基づく契約解除の場合であり、それ以外の債務不履行が存在すれば、第 52 条の契約解除の規定が適用される。
２．条文の背景（１）債務不履行責任の一類型としての契約不適合責任
改正前民法では、仕事の完成前は債務不履行責任、完成後は瑕疵担保責任として責任内容が整理されていた。
これに対し、改正民法では、仕事の完成前後を問わず、債務不履行責任として整理された（納入物に契約不適合があることは、ベンダの債務不履行の一場面である）。
そのため、ソフトウェア開発取引において主に問題となるのは債務不履行責任であり、その類型は、以下４つとなる。
①不完全履行
第 28 条第 2 項の場合は、一応仕事の目的物（ソフトウェア）の作成は終了したが、その内容が不完全ないし一部未完成である（外部設計書に合致していない）というケースであり、不完全履行の該当可否が問題となる。
②履行遅滞
ソフトウェアを所定の期限までに完成させられない場合は、履行遅滞への該当可否が問題と
なる。
③履行不能
仕様に合致するソフトウェアを完成させることがもはやできない（不能な）場合は、履行不能への該当可否が問題となる。
④契約不適合検収完了後、納入物についてシステム仕様書との不一致が発見された場合は、契約不適合の問題となる。
（２）契約不適合責任が適用されるタイミング
本条による契約不適合責任が適用されるタイミングは、ソフトウェアが完成し、ユーザによる検収が完了した時点である。22【適用ガイド】１．契約不適合責任の期間
本条第 1 項における契約不適合責任の期間は、情報システムの規模、特性、対価等を考慮してケー
スバイケースにより、当事者間で定めるべきであることから、本契約では具体的な期間は明示して
22

第 24 条と第 30 条の選択関係は、69 頁の表４を参照されたい。

81

いない。
改正民法第 637 条では、責任期間を「注文者がその不適合を知った時から 1 年以内」としている
が、契約不適合の責任期間は当事者間で任意に合意することが可能である。
個々の業務により異なる要素はあるが、情報システムにおいては、検収完了から 1 年あれば、1
事業年度、四季（季節的変動）等のサイクルを経験し、基本的な機能について一通り経験できると考えられることから、検収完了後 1 年程度が概ね妥当な期間と思われる。

第４節 ソフトウェア運⽤準備・移⾏⽀援業務【A 案

外部設計を準委任で行う場合】23（ソフトウェア運用準備・移行支援業務の実施）
第 30 条乙は、第 31 条所定の個別契約を締結の上、本件業務として甲が行うシステムテスト、導入・受入支援及び本件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準備･移行支援業務」という。）を行う。
2.

乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効果的に行われるよう、善良な管理者の注意をもって支援業務を行うものとする。

【B 案

外部設計を請負で行う場合】（ソフトウェア運用準備・移行支援業務の実施）
第 30 条乙は、第 31 条所定の個別契約を締結の上、本件業務として甲が行う導入・受入支援及び本件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準備･移行支援業務」という。）を行う。
2.

乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効果的に行われるよう、善良な管理者の注意をもって支援業務を行うものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本節は、実際にユーザが完成したソフトウェアを業務で運用するために必要な作業を実施する「ソフトウェア運用準備・移行支援業務」に関する規定である。
ソフトウェア運用準備・移行業務の契約類型としては、ユーザが主体となる準委任型とベンダが主体となる請負型が考えられるが、運用準備・移行における作業は、本質的にはユーザが実施すべ
23

裁判例では、ソフトウェア開発の完成の有無の判断については、システムが完成しているか否かが一つの争点となった事案において、「請負人が仕事を完成させたか否かについては、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準として判断すべき」としたものがある（東京地裁平成 14 年 4 月 22 日）。この判断基準は、元々は建築請負契約の完成有無の判断において用いられていた基準であるが、システム開発に関する多くの裁判例でも判断基準として利用されている。改正民法下においても引き続きこの判断基準が維持されると思われる。

82

き作業であることから、準委任型を前提としている（第 1 項）。
したがって、ベンダは受任者として善管注意義務を負う（第 2 項）のであり、結果（ここでは完成したソフトウェアがユーザの業務で運用できるようになること）そのものについて責任を負うものではない。
２．条文の背景（１）運用テストについて
通常のソフトウェア開発工程では、システムテストで仕様との合致を確認した後、運用テスト
で実運用に耐え得るか否かを確認する。
その一方で、検収もシステムテスト後に行われるため、運用テストとユーザの検査の時期が重複し、検査基準が不明確であった場合、本来は仕様との合致を問題とすべき検査において、運用テストで問題とされるべき改善要求や機能追加要求がなされることがあり、場合によっては、検査不合格になることがあった。
上記の問題を踏まえ、検収と運用テストを明確に切り分けるべく、運用テストをソフトウェア
開発業務とは別フェーズとなるソフトウェア運用準備・移行支援業務に含めた。
【適用ガイド】１．第 1 項の選択肢の選択方法
準委任型の契約の対象として、システムテストを含める場合には A 案を、システムテストを含めない場合には B 案を選択する。また、第 24 条との整合性を踏まえ、第 24 条において A 案を選択する場合、第 30 条においても必ず A 案を選択するなど注意が必要である。関連する第 24 条の解説を参照されたい。
（ソフトウェア運用準備・移行支援業務に係る個別契約の締結）
第 31 条甲及び乙は、当該ソフトウェア運用準備・移行支援業務について、第 4 条第 1 項に定める取引条件を協議の上決定し、ソフトウェア運用準備・移行支援業務に係る個別契約を締結する。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本契約は「基本契約」として、複数の個別契約に共通する条件、基本となる条件を定めており、ベンダが行う作業内容、ユーザが行うべき作業内容およびそれらのスケジュールならびにユーザが支払うべき代金などの具体的な債務内容は個別契約において定められることになる。本条は、ソフ
トウェア運用準備・移行支援業務に関する具体的な債務内容を特定する個別契約の必要性を明確にするものである。

83

【適用ガイド】
１．個別契約書のサンプル
個別契約の締結に際しては、第 4 条第 1 項に定める各取引条件をユーザ・ベンダ間で協議しておくことが必要である。
個別契約書のサンプルは本書付録④（169 頁）を参照されたい。なお、このサンプルでは役割分担等の詳細は別表に記載される構成となっている。この別表は個別契約書に袋とじし、一体としておくことが原則である。もし、例外的に別々とする場合には、当該別表が個別契約の別表であることが明らかになるよう別表の表紙に「〇〇〇〇年〇月〇日付ソフトウェア運用準備・移行支援業務に関する個別契約第○項の別表である」など明記しておかなければならない。また、当該別表の表
紙には、ユーザ・ベンダ双方の合意を明らかにするために双方の記名押印も必要となる。
（業務の終了・確認）
第 32 条乙は、ソフトウェア運用準備・移行支援業務の終了又は個別契約に定める作業期間の満了若

しくは作業工数（作業量）分の作業実施完了のいずれか最も早く到来したときから○日以内に、業務終了報告書を作成し、甲に提出する。
2.

甲は、個別契約に定める期間（以下「ソフトウェア運用準備・移行支援業務終了の確認期間」という。）内に、当該業務終了報告書の確認を行うものとする。

3.

甲は、当該業務終了報告書の内容に疑義がない場合、業務終了確認書に記名押印の上、乙に交付
し、ソフトウェア運用準備・移行支援業務の終了を確認するものとする。

4.

ソフトウェア運用準備・移行支援業務終了の確認期間内に甲が書面で具体的な理由を明示して異議を述べない場合には、ソフトウェア運用準備・移行支援業務終了の確認期間の満了をもって、業務の終了を確認したものとみなされる。

5.

個別契約に定める作業期間の満了又は作業工数（作業量）分の作業実施終了後も、甲が引き続き当該支援業務を必要とするときは、甲及び乙は第 33 条に従い、追加のソフトウェア運用準備・移行支援業務に関して変更契約又は追加契約を締結するものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条では、準委任型のソフトウェア運用準備・移行支援作業について、確認を行う手続を定める。
（１）業務の終了要件
ソフトウェア運用準備・移行支援業務は次のいずれか最も早く到来した時点で終了する（第 1項）。
① ソフトウェア運用準備・移行支援業務の終了② 個別契約に定める作業期間の満了③ 個別契約に定める作業工数（作業量）分の作業実施完了（２）プロセスに対するチェック84

準委任型の「ソフトウェア運用準備・移行支援業務」において、ベンダの責任は、技術指導を通じてユーザの作業を支援することに限られ、ソフトウェア運用準備・移行作業を完了し、完成したソフトウェアをユーザの業務で運用できるようにする責任自体はない。
そのため、ユーザの確認は、完成したソフトウェアが現実に運用できるかどうかの観点から行うのではなく、ユーザのソフトウェア運用準備・移行作業に対して充分な支援を行ったかどうかという観点から行う。
すなわち、サービスの結果（＝ベンダ支援のもとでユーザが行った運用準備･移行作業の結果）ではなく、サービスのプロセス（＝支援そのもの）に対するチェックである（第 2 項）。そして、
そのチェックのために、実施した業務内容を記載した業務終了報告書をベンダからユーザに提出することとしている（第 1 項）。
（３）確認期間の明確化とみなし確認
詳細かつ広範囲に確認するとなると、確認期間の長期化を招き、いつまでも確認されないという不都合が生じること、業務終了の確認が明確な形で行われないと、結局確認期間の長期化につながること等から、確認期間を明確化し（第 2 項）、確認期間内に異議がなければ業務の終了を確認したものとみなす、みなし確認を定めている（第 4 項）。
（４）追加のソフトウェア運用準備・移行支援業務
本条第 1 項では、ソフトウェア運用準備・移行支援業務の終了を、当該支援業務が終了した場
合（＝ユーザのソフトウェア運用準備・移行業務が完了した時）、またはベンダの作業期間ある
いは作業工数の満了時としている。ユーザのソフトウェア運用準備・移行業務が完了した場合は問題とならないが、個別契約に定められた作業期間あるいは作業工数のいずれかを超えてユーザが更にベンダの支援を必要とする場合は、別途契約が必要となる（第 5 項）。
２．補足（１）第 1 項の作業期間、作業工数
ソフトウェア運用準備・移行支援業務のような準委任契約に基づくサービスの場合、そのサービスの範囲の定め方として、作業期間による定め方と作業工数（作業量）による定め方が実務上ある。特に、委託料を一括金額により定める場合にはそうである。そこで、作業期間、作業工数（作業量）も終了条件となる旨明記した。
なお、委託料の定め方として、時間当たりの技術支援料をあらかじめ決めて実績時間を乗ずる
ように、作業量に応じて委託料も変動するような定め方もある。
（２）第 5 項
本条第 1 項において、ソフトウェア運用準備・移行支援業務の終了条件として、「作業期間又は作業工数（作業量）の満了」と定めており、同業務がソフトウェア運用準備・移行支援業務の終了前に終了する場合があることから、追加の支援業務が必要となる場合は、変更契約または追加契約が必要となることを確認的に定めた。
【適用ガイド】１．「検収」について
契約実務上、「検収」という用語をよく使うことがある。これは法律の用語ではなく、契約上慣習的に使用されている用語であり、経理上の売上計上あるいは請求や支払のトリガーとなるタイミン
グを示すものとして用いられる。売買では、検収完了時期として「受入検査合格時」、「納品時」、「出85

荷時」等のバリエーションが見られる。請負契約では「受入検査合格時」が多いと思われるが、本条のような準委任型のサービスに関しても「検収」が用いられることがある。
そこで、契約実務上、検収完了時期を明確にしたい場合、現在の本条第 5 項を第 6 項として、第 5
項として「前各項に基づく確認をもって検収完了とする。
」あるいは「前各項に基づく確認とともに乙所定の検収通知書に甲が記名押印することをもって検収完了とする。」などの条文を追加することが考えられる。
２．「検収」の効果
本条では、本件ソフトウェアがシステム仕様書と合致しているかに関する検査がユーザによりなされ、当該検査に合格したことにより「検収完了」とする旨定めており、さらに、第 29 条において、「検収完了」は、同条に定める契約不適合責任の定めが適用されるタイミングにもなっている。このように、検収書を出す行為は、本契約においては、ユーザ・ベンダの権利関係に影響を与えるものであることを認識しておく必要がある。

第４章 契約内容等の変更
本章では、本契約および個別契約の内容を変更する場合の基本原則、変更の手続き等について定める。
まず、第 33 条（本契約及び個別契約内容の変更）において、本契約および個別契約の内容を変更する
場合の基本原則を定める。
次に、本契約および個別契約の内容の変更につながる個々の対象について、その対象ごとに第 34 条（システム仕様書等の変更）、第 35 条（中間資料のユーザによる承認）、第 36 条（未確定事項の取扱い）において定め、それらの変更の手続きを第 37 条（変更管理手続）で定める。
第 38 条（変更の協議不調に伴う契約終了）では、本契約および個別契約の内容変更について契約当事者間で協議が調わない場合の取扱いについて定める。
（本契約及び個別契約内容の変更）
第 33 条

本契約及び個別契約の内容の変更は、当該変更内容につき事前に甲乙協議の上、別途、書面により変更契約を締結することによってのみこれを行うことができる。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条では、本契約および個別契約に関するすべての契約内容の変更は、書面による変更契約の締結によって行う旨を定める。
２．条文の背景86民法上、契約は申込みと承諾の意思表示の合致により成立するため、口約束であっても意思表示の合致があれば契約が成立する。契約の変更も同様である。
しかし、口頭による契約変更の意思表示については、契約当事者間でのトラブルを生じさせるおそれがあるため、これを避ける観点から、書面での合意が望ましい。したがって、本契約では、変更契約を締結することによってのみ契約の変更を行うことができる旨を規定している。
（システム仕様書等の変更）
第 34 条甲又は乙は、システム仕様書、検査仕様書、第 35 条により甲に承認された中間資料（以下、総称して「仕様書等」という。）の内容についての変更が必要と認める場合、その変更の内
容、理由等を明記した書面（以下「変更提案書」という。）を相手方に交付して、変更の提案を行うことができる。
2.

仕様書等の内容の変更は、第 37 条（変更管理手続）によってのみこれを行うことができるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、システム仕様書等の変更の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
システム仕様書24、検査仕様書25および中間資料26（以下「仕様書等」と総称する。）はソフトウェ
ア開発業務における最終的な目的物である納入物の仕様等であり、その変更は、仕様等の変更にとどまらず、開発スケジュールや金額に影響が及ぶ可能性があり、仕様変更に係るトラブルにつながりやすい。
そこで、本条では、仕様書等の変更について、その提案は必ず書面により行い、変更の手続きは
変更管理手続きによって変更を行う旨を定める。
（１）第 1 項
ユーザ・ベンダのいずれもが、仕様書等の変更提案を行うことができること、ただし、変更を求める当事者は変更の内容、理由等を明記した変更提案書27を提出して、変更の要求または提案を行うことができる旨を定める。
（２）第 2 項
仕様書等の内容の変更については、第 37 条（変更管理手続）によることを定める。
２．条文の背景
本モデル契約におけるソフトウェア開発業務の前提となる仕様であり（本契約第 24 条（ソフトウェア開発業務の実施）
第１項）、ソフトウェア開発業務における納入物の合否判定の根拠となるもの（本契約第 29 条（契約不適合責任）第 1
項）である。
25 システム仕様書に基づいて作成される納入物の検査の基準となるテスト項目、テストデータ、テスト方法およびテスト
期間等を定めたものであり、納入物のうち本件ソフトウェアについて、システム仕様書との合致に係る検査を行う際の元となる文書（本契約第 27 条（検査仕様書の作成及び承認））である。
26 本契約第 2 条第 1 項第 5 号
2427

変更提案書・管理書のサンプルは本書付録⑤（176 頁）を参照されたい。

87

（１）ソフトウェア開発における「仕様」とその曖昧性
一般的に開発ソフトウェアの「仕様」とは、開発すべきソフトウェアの内容そのものを指すが、ソフトウェアはハードウェア等の物品とは異なり無形であるため、その内容の特定が難しい。このため、ソフトウェア開発のユーザ・ベンダ双方において「仕様」を特定・可視化し合意しておくことが重要である。この点を前提として条文を作成している。
（２）本件ソフトウェアの「仕様」とその確定
本契約では、ユーザ・ベンダ双方により確認したシステム仕様書をソフトウェア開発業務における納入物である本件ソフトウェアの「仕様」と定義するが、「仕様」はソフトウェア開発のプロセスの中で変更、詳細化、追加されるなどして段階的に確定していくものである。ソフトウェア
開発業務の委託前においてすべて確定していない場合28や、ソフトウェア開発業務プロセスにおいて確定する場合29があるのが現状である。
（３）現状の仕様変更についての問題点と問題点への対応
現実のソフトウェア開発案件において、ベンダは当初の契約金額内で、多くの「仕様変更」による費用増加を余儀なくされ、ベンダの収益を圧迫しているという実態があり、一方、ユーザにおいては、ベンダから、仕様の詳細化を仕様変更と称し、追加費用を請求されるという実態が併存している。
上記（１）（２）のソフトウェアおよびソフトウェア開発業務の特性および上記問題点への対応のため、本条では、「仕様」の変更は、価格・納期に影響を及ぼす可能性があると位置付け、仕様
変更・確定のための契約変更プロセスの明確化とプロセスに従った履行を促すための規定を設けた。
【適用ガイド】１．仕様・価格・納期を早期に確定させるための考え方のルール化について
第 36 条（未確定事項の取扱い）において、主に未確定の仕様の確定に向けた取扱いを規定するが、確定を円滑に進める観点から、ユーザ・ベンダ間で確定のために優先すべき事項などについての考え方を可視化して合意しておくことが有益な場合がある。以下に考え方の一例を示すので、必要に応じて検討されたい。
（１）仕様変更が価格および納期のそれぞれに大幅な変更を余儀なくする場合であって、価格・納期を変更することが難しい場合
既に合意済みの価格・納期の範囲で、実現可能な仕様を開発仕様（合意済みの仕様の一部を削除し、変更仕様を追加することを含む）として再確定し、変更契約を締結する。
（２）仕様変更が価格および納期のそれぞれに大幅な変更を余儀なくする場合であって、納期を変更することが難しい場合
既に合意済みの納期の範囲で、実現可能な仕様を開発仕様（合意済みの仕様の一部を削除し、変更仕様を追加することを含む）として再確定し、そのための価格も合意した上で、変更契約を締結する。
（３）仕様変更が価格および納期のそれぞれに大幅な変更を余儀なくする場合であるが、価格・納28あらかじめ仕様として確定しておくべき事項であるがソフトウェア開発業務の前の時点において未確定事項として残した場合、あるいはあらかじめ仕様として想定できなかったため仕様として反映していない場合。
29 未確定事項を確定する場合、あらかじめ仕様として確定していた事項を変更または追加する場合、あらかじめ仕様として明示されていなかった事項を追加する場合。

88

期を変更することができる場合
仕様変更を明確化し、変更後の仕様・価格・納期についての変更契約を締結する。
（中間資料のユーザによる承認）
第 35 条乙は、中間資料のうち、乙が必要と認める部分を提示して、甲の承認を書面で求めること

ができる。
2.

甲は、前項の承認請求を乙から受けた日から○日以内（以下「中間資料の点検期間」という。）に、内容を承認するか点検を行い、その結果を書面に記名押印の上、乙に交付するものとする。

3.

甲は、中間資料の内容に不都合が認められる場合、又は次条で定める未確定事項の内容と関連性を有するため、当該時点では判断できない場合、その他これらに準ずる合理的な理由がある場合
は、その具体的な理由を明示して乙に回答することにより、承認を拒否又は留保することができる。但し、ソフトウェア開発作業を円滑に促進するため、甲は合理的理由のない限り適時に第 2
項所定の点検結果を乙に交付するものとする。

4.

甲は、中間資料の点検期間内に書面で具体的な理由を明示した異議を述べない場合、中間資料の承認を行ったものとみなされる。

5.

甲又は乙は、前各項により中間資料の承認がなされた後に、中間資料の内容の変更の必要が生じた場合は、変更提案書を相手方に交付して、変更の提案を行うことができる。

6.

甲から承認された中間資料の内容の変更は、第 37 条（変更管理手続）によってのみこれを行うことができるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、中間資料のユーザによる承認の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
ベンダはソフトウェアの開発過程で様々なアウトプットを作成する。ソフトウェア開発を効果的・効率的に行うには、手戻りの最小化が重要であり、アウトプット内容について、ユーザの承認を得て開発作業を進めることがユーザ・ベンダ双方にとって有益である。
上記の観点から、本条では、本件ソフトウェア、システム仕様書および検査仕様書に該当しない
アウトプットを中間資料と定義し、ベンダがユーザにその承認を求める手続き等について定める。
（１）第 1 項
ソフトウェア開発作業の特性として、承認対象とする中間資料をあらかじめ個別契約で定めておくことは困難であるため、ベンダが必要と判断する中間資料について、ベンダが必要と判断したときに承認を請求できる旨を定めている。
（２）第 2 項ベンダからの承認請求に対し、承認するか否かを点検する期間を定めることとなっており、点検結果は書面で回答する旨を定める。承認された中間資料の変更手続きは第６項に定めている。
（３）第 3 項
ユーザが中間資料の承認を拒否または留保できる事由を定める。承認を拒否または留保できる89

場合としては、①中間資料の内容に不都合が認められる場合、または②次条で定める未確定事項の内容と関連性を有するため、当該時点では判断できない場合、③その他①②に準ずる合理的な理由がある場合である。いずれの場合においても、承認を拒否または留保する場合には書面でその具体的な理由を明示してベンダに回答することが求められる。
（４）第 4 項
第 2 項に定めるとおり、ユーザによる中間資料の承認は書面により行うことが原則であるが、ユーザによる承認作業の省力化およびベンダによるソフトウェア開発作業を遅延させない観点か
ら、書面による承認と同等の効果を認めて良い条件をみなし承認規定として定めたものである。
ユーザが中間資料の点検期間内にベンダに対し書面で具体的な理由を明示し異議を述べない場合
も中間資料を承認したものとして扱う。
（５）第 5 項、第 6 項
第 5 項、第 6 項は、承認された中間資料の変更手続きを定める。開発作業は承認された中間資料の内容を前提に進められる。そのため、事後その内容が変更されると開発作業のやり直しにつながり、ユーザにとってはスケジュールに、ベンダにとってはコストに影響が生ずることがある。
そこで、その内容の変更には所定の変更管理手続きを要することとしている。
２．条文の背景
本契約の最終的な目的物であるソフトウェアの仕様は、ソフトウェア開発の特性上、ユーザ・ベンダ間の確認により段階的に確定していく。
ソフトウェア開発を手戻りなく効率的に行うためには、個別業務の終了の時点のみならず個別業務の遂行の過程で作成したアウトプットについても、仕様として確定できる範囲で必要に応じ順次確定し、未決事項を明らかにして進めることが重要である。この観点から、個別業務の遂行過程で生じるアウトプットを中間資料と定義し、その承認については、仕様確定に向け一定の拘束力を与えることとしている。
【適用ガイド】
１．中間資料のユーザ承認の意義
本件ソフトウェア、システム仕様書および検査仕様書（以下「本件ソフトウェア等」と総称する。）の確定/承認規定30との関係で、その確定/承認前のアウトプットである中間資料のユーザ承認の意義は次のとおりである。
（１）承認の範囲内での作業内容の確定について
中間資料は、ユーザ承認後、その承認が否定される特段の事情が存在しない限り、その承認の範囲内でその後の作業の前提として確定する。中間資料は本件ソフトウェア等の確定に向けて重要な役割を果たすことが期待されているともいえる。この点を踏まえ、事後の開発作業に影響を与えるなど、あらかじめユーザの承認を得ておくべき事項については、作業着手前にベンダ・ユー
ザ間で中間資料として明確化し、その承認時期を決めておくことや、連絡協議会もしくは定例会
議の場等を通じて、その決定に従い定期的かつ着実に中間資料のユーザ承認を求めていくなどの運用も考慮されたい。

30

要件定義書の確定（本契約第 17 条及び第 18 条）、外部設計書の確定（本契約第 22 条及び第 23 条）、納入物の納入（本契約第 26 条）、検査仕様書の承認（本契約第 27 条）、本件ソフトウェアの検収（本契約第 28 条）。

90

（２）中間資料の変更についてユーザが承認した中間資料は、その承認の範囲内でその後の作業の前提として確定するものであることから、その内容の変更については、システム仕様書の変更と同等の取扱いを行う（第 35条）。
２．中間資料の契約不適合責任について
契約不適合責任は個別契約における最終的な目的物に対して、その検査完了後の時点から生じるものであるから、最終的な目的物でない中間資料について契約不適合責任は生じない。
（未確定事項の取扱い）
第 36 条

第 17 条に基づく要件定義書又は第 22 条に基づく外部設計書の点検期間内において、甲が、当該要件定義書又は外部設計書において確定すべき事項のうち甲のやむを得ない事情により確定して提示することができない事項（以下「未確定事項」という。）がある場合、甲及び乙は、次の各号に定めることを条件として当該未確定事項を除き当該要件定義書又は外部設計書を第 17 条又は第 22 条に従い確定させることができるものとする。
① 甲が未確定事項の内容とその確定時期、未確定事項の確定により請求する追完、修正により委託
料、作業期間、納期及びその他の契約条件の変更を要する場合に甲がこれを受け入れること、その他必要となる事項を記載した変更提案書を乙に速やかに提示する。
② 前号に従い乙に変更提案書が提示された後速やかに、甲及び乙はその内容について協議し、合意できた場合には、甲乙双方の責任者が当該変更提案書に記名押印する。
2.

甲は、未確定事項を確定したときは直ちに、その内容を変更提案書により乙に通知するとともに、確定した要件定義書、外部設計書の追完、修正を請求できるものとする。なお、甲による追完又は修正の請求は、第 37 条（変更管理手続）によってのみこれを行うことができるものとする。

3.

甲が第 1 項の確定時期までに未確定事項を確定しない場合、乙は、当該未確定事項は当該要件定
義書又は外部設計書の要件として無かったもの（当該未確定事項につき選択肢が設けられており、甲がそのいずれかを選択しなかった場合は、乙が選択したものを甲が選択したもの）とみなすことができるものとする。但し、乙は、当該未確定事項が無かったものとみなした場合に、当該要件定
義書又は外部設計書の他の要件の実現に支障が生じると判断し、相当期間を設けて確定を要請したにもかかわらず、なお甲が確定しないときは、乙は第 52 条に準じ本契約の全部又は一部及び履行の完了していない個別契約を解除することができるものとする。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、未確定事項の取扱いの実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
第 17 条または第 22 条に定めるように要件定義書あるいは外部設計書を確定することは、その後の開発工程を円滑かつ確実に進めるために非常に重要である。確定がなされないならば、これらのドキュメントで規定される仕様が流動的なものとなり、内部設計以降の作業も流動的なものとなら91

ざるを得ず、品質、納期、費用等に多大な影響を及ぼすものである。
一方で、それぞれの適切なタイミングで確定しきれない事項が残ることも事実である。これらの事項がその後確定することは納期、価格等の契約条件に影響するものである。
なお、工程、個別契約のタイミング、点検期間と本条の関係は図１１のとおりである。
図１１

開発プロセスと個別契約／点検期間のタイミング【適用ガイド】１．未確定事項を最小限とすること
ソフトウェア開発を円滑かつ確実に進めるためには、確定すべき時点において要件定義書、外部設計書が確定していること（＝未確定事項が存在しないこと）が望ましい。この点、開発作業の遂行に際しては、未確定事項はやむを得ない事情がある場合であって、必要最小限の範囲とするよう、留意されたい。
（変更管理手続）第 37 条甲又は乙は、相手方から第 34 条（システム仕様書等の変更）、第 35 条（中間資料のユーザによる承認）、第 36 条（未確定事項の取扱い）に基づく変更提案書を受領した場合、当該受領日から〇日以内に、次の事項を記載した書面（以下「変更管理書」という。）を相手方に交付し、甲及び乙は、当該交付日から○日以内に、第 12 条所定の連絡協議会において当該変更の可否につき協議す
るものとする。
①

変更の名称

②

提案の責任者

③

提案年月日

④

変更の理由

⑤

変更に係る仕様を含む変更の詳細事項⑥

変更のために費用を要する場合はその額⑦

協議期間を含めた変更作業のスケジュール⑧

その他変更が本契約及び個別契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響
2.

第 1 項の協議の結果、甲及び乙が変更を可とする場合は、甲乙双方の責任者が、変更管理書の記92

載事項（なお、協議の結果、変更がある場合は変更後の記載事項とする。以下同じ。）を承認の上、記名押印するものとする。
3.

前項による甲乙双方の承認をもって、変更が確定するものとする。但し、本契約及び個別契約の条件に影響を及ぼす場合は、甲及び乙は速やかに変更管理書に従い、第 33 条（本契約及び個別契約
内容の変更）に基づき変更契約を締結するものとし、当該締結をもって変更が確定するものとする。

4.

乙は、甲から中断要請があるなどその他特段の事情がある場合、第 1 項の協議が調わない間、本件業務を中断することができる。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、変更管理手続の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
ソフトウェア開発ではその過程で、仕様の変更がなされることがよくある。ある時点で仕様が決められると、その後の開発作業は当該仕様を前提に進められる。そのため、決められた仕様がその後変更されると、それまでの作業が無駄となり、もう一度やり直す必要が生ずる。このことは、開発スケジュールや費用に多大な影響を与える可能性が高いため、むやみに仕様変更を行うことは開発プロジェクトの破綻を招きかねない。これを回避するためには、仕様変更の必要性が発生したときには、将来、スケジュールや費用などに与える影響を十分考慮に入れ、その可否を判断する必要があり、この手順を担保するために適切な手続きを定めておくべきである。また、こうした変更要請が口頭でなされると、要請の有無、その内容について、ユーザとベンダ間で認識を共有できず、両者間で仕様の理解に齟齬が生ずることになり、このことは、その後の開発作業やソフトウェアの品質などに悪影響を与えることにもなる。
本条では、システム仕様書等の変更（第 34 条）、ユーザ承認済みの中間資料の変更（第 35 条）、
未確定事項の追完または修正（第 36 条）について、必要な手続きを定めている。
２．条文の背景
ソフトウェア開発の仕様はその開発プロセスの中で段階的に確定していくものであり、また、変更も生じる可能性が高いことを踏まえ、システム仕様の機能追加や変更等種々の変更が生じることを契約の前提とし、その変更のプロセスおよび方法を可視化する規定を設けたものである。この規定により、変更が生じた際におけるユーザ・ベンダ間での認識共有、調整、変更契約の締結が適切かつ速やかに図られ、ソフトウェア開発が適正に行われることを期待している。
【適用ガイド】１．変更管理書31と変更契約の運用について
変更管理書は、ユーザ・ベンダ双方からの変更の提案を管理し、協議を促すためのツールであり、ユーザ・ベンダの責任者が変更管理書に記名押印することによって変更が確定する、と規定する。
一方、変更管理書に記載される内容が本契約および個別契約の条件に影響を及ぼす場合には、変更
31

変更提案書・管理書のサンプルは、本書付録⑤（176 頁）を参照されたい。

93

の確定のためには変更管理書による記名押印に加え、変更契約の締結が必要である旨規定する。
この点、変更管理書に記載される内容が本契約および個別契約の条件に影響を及ぼすと考えられる場合には、変更契約を締結することを要する旨を変更管理書に記載し、その内容をユーザ・ベン
ダが確認し記名押印をすることによりユーザ・ベンダ間の認識を一致させておくことが重要である。
（変更の協議不調に伴う契約終了）
第 38 条

前条第 1 項の協議期間内に協議が調わなかった場合、甲又は乙は、個別業務の未了部分に係る当該個別契約を解約することができる。
2.

前項により個別契約の一部が解約された場合、甲は、それまで乙が遂行した個別業務に係る委託料、及びその他乙の支出した費用を支払うものとする。

【2008 年 JEITA モデル契約との相違】
改正民法第 634 条において、ユーザの帰責事由なく仕事が完成できない場合または仕事の完成前に契約が解除された場合、ベンダは、その仕事の結果の可分な部分について、ユーザが受ける利益の割合に応じて出来高報酬を請求できる旨規定されたが、本契約では、個別業務の既履行部分に係る委託料、及びその他乙の支出した費用の支払いを解約に伴う清算方法として維持することとしたため、本条に変更はない。
【条文解説】
１．趣旨（１）個別契約の解約（第 1 項）
ソフトウェア開発の過程で仕様変更等が必要になったものの、変更協議が不調となった場合、ユーザにとっては、自らのニーズに沿わないソフトウェアを強いられ、また、ベンダにとっては、
その変更が例えば、合理的な理由なく自己にとって新たな負担を伴う場合や実現不可能な条件を伴う場合などがある。
このような状況下では、ユーザ・ベンダ間において、本契約または個別契約を継続するための合意形成を図ることが難しく、また、状況によってはすでに契約関係を維持する前提としての信頼関係も破綻していることも考えられることから、連絡協議会での協議が調わなかった場合の措置として、本条では、次のとおり個別契約の未了部分を対象として個別契約を解約することができるとしている。
①解約権者：ユーザだけでなくベンダからも解約が可能としている。
上述のとおり、ベンダからの解約を認めることが合理的である場合が想定されることから、ベンダからも解約ができることとしている。
なお、ベンダに解約権を付与した場合、当該ベンダが当該解約権を行使するために敢えて不必要・不合理な変更提案を行い、協議不調にもっていくという濫用を危惧する意見もある。
しかしながら、本条が適用される状況下にあっては、少なくとも契約の締結の時点においては存在していた契約を履行することに係る相手方への期待・信頼が、その後の契約履行プロセスの中で、失われた状況に陥っているといわざるを得ない場合であると考えられることから、ベンダによる解約権の行使を認めるべきであると思われる。
②解約の対象となる契約：本契約または個別契約の未了部分としている。

94

③解約を認める場合：第 37 条（変更管理手続）に定める連絡協議会で協議が調わなかった場合としている。
（２）解約時における費用清算の方法（第 2 項）
改正民法第 634 条は、仕事の結果が「可分」であることおよび「注文者が利益を受けること」
を出来高報酬請求の要件としている。
まず、「可分」であることについて、ソフトウェア開発では、検収が未完了である業務において分割検収のような分かりやすい成果の可分化が実務的に難しい場合が多い。
また、「注文者が利益を受けること」について、通常、システム開発では工程ごとに成果物が生じ、客観的には、それ自体経済的価値を有すると考えられるものの、完成していないシステムやその途中成果物について、ユーザの利益という観点での金銭評価は相当に困難であると考えられ、また、変更の協議不調によってベンダのそれまでの投下資本が無に帰するとすれば過度な不経済の結果をベンダに与えることにもなる。
上記を踏まえ、本条では、上記要件を定めることはせず、次のとおり個別契約の解約時における合理的な清算方法としている。
①ユーザはベンダに個別業務の既履行部分に係る委託料を支払うこととしている。この点、既履
行部分に関するユーザ・ベンダ間の協議においてユーザに納得感を持ってもらうためにも、ユー
ザ・ベンダは、工程のどこまで終わったかについての共通認識を、連絡協議会で醸成しておくことが重要になる。
②個別業務の既履行部分に係る委託料に加え、ユーザはベンダにその他ベンダが支出した費用を支払うこととしている。協議の過程では、ベンダは通常、（a）協議を行うための人件費、（b）
プロジェクトが再開されることを想定し、このために体制を維持するために負担するコスト（プロジェクト要員の人件費（外注費用を含む）など）を負担している。これらの費用は、ベンダに現実に発生した費用であり、請求に基づき支払いを受けることが望ましいといえる。
③損害賠償については特に定めていないが、協議不調につき、ユーザもしくはベンダの帰責事由がある場合には、第 53 条（損害賠償）に従い解決を図ることとなる。
２．条文の背景
ソフトウェア開発の過程で仕様変更等が必要になったものの、変更協議が不調となった場合には、
ユーザ・ベンダ間で新たな関係を構築した方が互いにとってよい場合があるため、本契約または個
別契約の解約などのルールをあらかじめ契約で合意しておくことが重要である。
【適用ガイド】１．解約時におけるソフトウェア等の引渡しに係る責任
個別契約の解約時、ユーザがベンダに対し、解約時点までにベンダが作成したソフトウェアやドキュメントなどの引渡しを求めることがある。当該ソフトウェアやドキュメントは、ベンダが通常の納入物に対し実施する品質検査を経た状態のものではないため、ベンダがこれらソフトウェア等について契約不適合責任を負うことは、現実的に困難であり非常に酷であるため、現状有姿（権利侵害や稼動について無保証）で引き渡すことをこれらソフトウェア等の引渡しに係る契約の条件とすることが妥当である。

95

２．清算する委託料および費用の範囲についての考え方は、次のとおりである。
①分割検収がなされる請負の場合（a）検収が完了している部分については、これに係る委託料が支払い対象となる。
（b）検収未了部分については、解約に伴いベンダが支出した費用が支払い対象となる。
②分割検収がなされない請負、または準委任の場合（a）実施済工数、完成率等の合理的な基準を用いて算出した委託料が支払い対象となる。
（b）解約に伴いベンダが支出した費用が支払い対象となる。
①②いずれも、（a）はベンダの利益を含んだ金額、（b）はベンダの利益なしの純粋な費用金額ということになる。この点、ユーザは何を請求し、ベンダは何を支払うかについては、ユーザ・ベンダ間で協議の上合意し、別途明確に定めておくべきである。

第５章 資料及び情報の取扱い（資料等の提供及び返還）
第 39 条甲は乙に対し、本契約及び各個別契約に定める条件に従い、当該個別業務遂行に必要な資料等の開示、貸与等の提供を行う。
2.

前項に定めるもののほか、乙から甲に対し、本件業務遂行に必要な資料等の提供の要請があった
場合、甲乙協議の上、各個別契約に定める条件に従い、甲は乙に対しこれらの提供を行う。

3.

本件業務遂行上、甲の事務所等で乙が作業を実施する必要がある場合、甲は当該作業実施場所（当該作業実施場所における必要な機器、設備等作業環境を含む。）を、甲乙協議の上、各個別契約に定める条件に従い、乙に提供するものとする。

4.

甲が前各項により乙に提供する資料等又は作業実施場所に関して、内容等の誤り又は甲の提供遅延によって生じた乙の本件業務の履行遅滞、納入物の契約不適合等の結果については、乙はその責を免れるものとする。

5.

甲から提供を受けた資料等（次条第 2 項による複製物及び改変物を含む。）が本件業務遂行上不要となったときは、乙は遅滞なくこれらを甲に返還又は甲の指示に従った処置を行うものとする。

6.

甲及び乙は、前各項における資料等の提供、返還その他処置等について、それぞれ第 10 条に定める主任担当者間で書面をもってこれを行うものとする。

【2008 年 JEITA モデル契約との相違】
瑕疵を契約不適合という表記に改めたほかは、改正民法を含めた近年の法改正による影響がないことや、資料等の提供および返還の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
ソフトウェア開発では、ユーザの業務に関するマニュアル、ルール集、企画書など様々な情報がユーザからベンダに提供されることが不可欠であり、ユーザはそれらの情報に関する資料等をベンダに提供することになる。また、ベンダは、ユーザに対し、支援作業あるいは開発作業に必要な資96

料等の提供を要求できることを担保しておく必要もある。そこで本条は、ユーザからベンダに提供される資料等の扱いについて定める。
（１）第 1 項
個別契約に定める条件を前提に、個別業務遂行に必要な資料等に関するユーザの提供義務を定める。
（２）第 2 項ベンダからユーザへの資料等の提供要請に対する提供義務の条件について定める。
（３）第 3 項
ユーザの事務所等にあるシステム環境を使って作業をする場合などユーザの事務所等で開発作業を行う場合、その作業場所をユーザからベンダに提供することがある。本項はそのような作業場所の提供義務について定めている。なお、第 12 条に定める連絡協議会をユーザの事務所等で行う場合も含まれる。提供する際の具体的な条件については、ユーザ・ベンダ間で協議の上、個別契約で定める。
（４）第４項ユーザが提供する資料、作業実施場所等の不具合や提供遅延が原因で、ベンダの作業に遅延等が生じた場合、それをベンダの責任とすることは酷であるので、かかる場合にはベンダは免責される。
（５）第 5 項
資料等が不要になった場合の当該資料等のユーザへの返還またはユーザの指示に基づく処置について定める。ユーザの指示に基づく処置には、例えば、ベンダ自らが廃棄し、その廃棄証明書を交付するようユーザが指示するなどである。
（６）第 6 項
資料の紛失や盗難等のトラブルを予防するために、資料等の提供、返還その他の処置等を主任担当者間で書面により行うこととしている。
２．条文の背景
ユーザがベンダに提供する資料等の提供または作業実施場所の確保については、本契約および個別契約の履行に影響するため、これらについてあらかじめ取扱いを定め、円滑な履行に資するようにした。
【適用ガイド】作業実施場所の確保のために、第三者と賃貸借契約を結ぶことが求められるような場合、その契約の締結者やその費用の取扱いについても、個別契約に定めておくことが考えられる。
（資料等の管理）第 40 条乙は甲から提供された本件業務に関する資料等を善良な管理者の注意をもって管理、保管

し、かつ、本件業務以外の用途に使用してはならない。
2.

乙は甲から提供された本件業務に関する資料等を本件業務遂行上必要な範囲内で複製又は改変できる。

97

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、資料等の管理の実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
前条の定めによりユーザからベンダに提供された資料等の管理について定めるものである。
（１）第 1 項
前条によりユーザからベンダに提供された資料等について、その管理、保管に当ってのベンダの善管注意義務を定めるとともに、目的外使用の禁止を定める。
（２）第 2 項
ソフトウェア開発作業では多くの要員が共同で作業を行っている関係から、ユーザからベンダに提供された資料等を複製したり、ドキュメント作成にあたって改変したりすることがある。このように、本件業務に必要な範囲での複製または改変を認めることとしている。
２．条文の背景
ソフトウェア開発作業の実態に即し、資料等の管理と活用が有効に図られるよう、条件を規定している。
（秘密情報の取扱い）
第 41 条甲及び乙は、本件業務遂行のため相手方より提供を受けた技術上又は営業上その他業務上の情報のうち、相手方が書面（電子的形式を含み、以下、同様とする）により秘密である旨指定して開示した情報、又は口頭により秘密である旨を示して開示した情報で開示後○日以内に書面により内容を特定した情報（以下、合わせて「秘密情報」という。）を第三者に漏洩してはならない。但し、次の各号のいずれか一つに該当する情報についてはこの限りではない。また、甲及び乙は秘密情報のうち法令の定めに基づき開示すべき情報を、当該法令の定めに基づく開示先に対し、当該法令の範囲内で秘密を保持するための措置をとることを要求の上で開示することができるものとする。
① 秘密保持義務を負うことなく既に保有している情報② 秘密保持義務を負うことなく第三者から正当に入手した情報③ 相手方から提供を受けた情報によらず、独自に開発した情報④ 本契約及び個別契約に違反することなく、かつ、受領の前後を問わず公知となった情報
2.

秘密情報の提供を受けた当事者は、当該秘密情報の管理に必要な措置を講じるものとする。

3.

甲及び乙は、秘密情報について、本契約及び個別契約の目的の範囲内でのみ使用し、本契約及び個別契約の目的の範囲を超える複製、改変が必要なときは、事前に相手方から書面による承諾を受けるものとする。

4.

甲及び乙は、秘密情報を、本契約及び個別契約の目的のために知る必要のある各自の役員及び従業員に限り開示するものとし、本契約及び個別契約に基づき甲及び乙が負担する秘密保持義務と同等の義務を、秘密情報の開示を受けた当該役員及び従業員に退職後も含め課すものとする。また、
乙は、第 7 条に基づく再委託先に対して秘密情報を開示できるものとし、乙は当該再委託先に対して本条と同等の義務を課すものとする。

98

5.

秘密情報の提供及び返却等については、第 39 条（資料等の提供及び返還）を準用する。

6.

秘密情報のうち、個人情報に該当する情報については、次条の規定が本条の規定に優先して適用されるものとする。

7.

本条の規定は、個別契約における特段の定めや当事者間で特段の合意がない限り、本契約終了後、〇年間存続する。

【2008 年 JEITA モデル契約との相違】
第 7 項における契約終了後の秘密保持義務に、「個別契約における特段の定めや当事者間で特段の合意がない限り」との条件を追加した。
【条文解説】
１．趣旨
ソフトウェア開発においては、ユーザ･ベンダが互いに自己の保有する技術上または営業上の情報を相手方に開示する。このうち、「秘密情報」についてはその重要性に鑑み、特に高い管理が求められることから、当該秘密情報を適切に取り扱うための条件を定めるものである。
（１）第 1 項
本項では、以下の点について定める。
①秘密情報の定義
本契約において秘密保持義務を負う対象となる秘密情報を次のとおり、秘密である旨の指定がされ開示された情報に限定している。
本件業務遂行のため相手方より提供を受けた技術上または営業上その他業務上の情報のう
ち、次に該当するもの。ただし、公知の情報など本項各号に該当する情報を除く。
（a）相手方が書面（電子的形式を含み、以下、同様とする）により秘密である旨指定して開示した情報、あるいは（b）口頭により秘密である旨を示して開示した情報で開示後○日以内に書面により内容を特定した情報②法令の定めに基づき開示すべき秘密情報の開示について
法令の定めに基づき開示要求を受けた秘密情報について、当該法令の定めに基づく開示先への開示について定めるものである。当該法令の範囲内で秘密を保持するための措置をとることを要求の上で開示することができる旨定める。
（２）第 2 項
秘密情報の提供を受けた当事者は、当該秘密情報の管理のために必要な措置を講ずる義務を負う旨規定する。この必要な措置は、秘密情報の秘密管理性を担保できるよう、物理的、技術的、
人的、組織的観点から実効的なものでなければならない。
（３）第 3 項
秘密情報の提供を受けた当事者の秘密情報の使用条件について定めるものである。
本契約および個別契約の目的の範囲外での秘密情報の使用を禁止すること、本契約および個別契約の目的の範囲を超える複製、改変が必要なときは、事前に秘密情報の開示先から書面による承諾を受ける旨を規定している。
（４）第４項99

秘密情報の開示先と開示の際の条件について定めるものである。
①開示先
本契約および個別契約の目的のために知る必要のある各自の役員および従業員ならびに、
第 7 条に基づく再委託先としている。
②開示の際の条件
本契約および個別契約に基づきユーザ・ベンダが負担する秘密保持義務と同等の義務を、
秘密情報の開示を受けた当該役員および従業員に対し退職後も含め課すことを規定する。また、当該役員または従業員が退職した後についても秘密保持義務を課すよう定めている。また、第 7 条に基づく再委託先に対し、本条と同等の義務を課すことをその開示の条件として規定している。
（５）第 5 項
秘密情報の提供および返却等について、第 39 条（資料等の提供及び返還）の定めを準用する旨を定める。
（６）第 6 項
秘密情報と個人情報とでは、公知性という点で異なる側面もありうるが、その扱いについて重複する部分もある。そこで、本項では、秘密情報に関する本条と個人情報に関する次条との優先関係を定める。
（７）第 7 項
秘密情報の秘密保持義務を負う期間については、情報の種類や個別の契約内容によって異なる
ので、個別契約書や授受書などで定める。なお、それら特段の定めがなされなかった場合のために、本項でも本契約終了後、当事者間で決める期間、当該義務が存続する旨の規定としている。
【適用ガイド】１．秘密情報の指定（１）指定の意義①形式秘の採用
本件業務の遂行に当って、ユーザ･ベンダ間では、大量の情報が授受される｡このような場合に、秘密情報について「実質秘」の考え方を採用すると、提供者が提供する情報のうちどの情報を秘密として取り扱うべきか、受領者である本件業務の遂行者が実質的に秘密である情報を識別して秘密として取り扱う義務を負うことになる。
一般に情報の受領者である本件業務の遂行者は、個々の情報の秘密性等について知らないことが多く、その情報が実質的に秘密であるかの判断をすることは容易でない。特に大量の情報が授受される場合は、その判断はより困難となる。その結果、遂行者が秘密情報を適切に取り扱うことができないおそれがある。
本条の趣旨に照らせば、本件業務の遂行者が取り扱う情報を適切に秘密情報と認識して取り扱うことが求められることから、取扱いに際しては、秘密情報であることが適切に認識できる
ような、客観的な表示となっていることが望ましい。したがって、「形式秘」の考え方を採用し規定した。なお、本件業務の遂行の過程で、複数の提供先からの秘密情報の提供があるような場合においては、特にその提供者からの開示であることが客観的に認識できる表示（提供者の名称＋秘密表示）としておくことが望ましい。
100

②指定表示が難しい場合の考え方
提供を受ける秘密情報の中に、書面への指定表示が難しいものが含まれる場合には、例えば、
次のようにその文書名や提供時期などを特定して、指定表示なく秘密情報として取り扱う運用とすることも考えられる。
［文書名・提供時期の特例（例）］○○○○年○○月○○日から○○○○年○○月○○日までの期間に、甲から乙へ提供した下記の情報
・○○○○サービス申込書
・△△△△契約書（２）提供する情報をすべて秘密情報として、秘密保持義務を課す場合について
上記の指定表示を行うことが難しい場合などで、提供する情報すべてを秘密情報と定義し、その管理義務をお互いが負う旨を定める場合がある。このような場合、秘密情報の授受について、
そのプロセスや運用を明確にし、本件業務の遂行者に周知徹底を図っておかなければ、秘密保持義務を適切に果たすことが難しいと思われる。一つの運用としては、本件業務の遂行責任者や主任担当者を経由して秘密情報の授受を行うこととするなど、秘密情報の授受のルートを統制することが考えられる。
２．秘密保持義務を負う期間の定める際の考え方
以下の点等を考慮し、ユーザ･ベンダ間で協議の上決定することが必要である。
①基本契約および個別契約の契約期間②秘密情報としての有用性が失われるまでの期間③授受される秘密情報の秘密性の高さ（個人情報）
第 42 条乙は、個人情報の保護に関する法律（本条において、以下「法」という。）に定める個人情報のうち、本件業務遂行に際して甲より取扱いを委託された個人データ（法第 2 条第 6 項に規定する個人データをいう。以下、同じ。）及び本件業務遂行のため、甲乙間で個人データと同等の安全管理措置（法第 20 条に規定する安全管理措置をいう。）を講じることについて、個別契約その他の契約により合意した個人情報（以下、合わせて「個人情報」という。）を第三者に漏洩してはならない。
なお、甲は、個人情報を乙に提示する際にはその旨明示するものとする。また、甲は、甲の有する個人情報を乙に提供する場合には、個人が特定できないよう加工した上で、乙に提供するよう努めるものとする。
2.

乙は、個人情報の管理に必要な措置を講じるものとする。

3.

乙は、個人情報について、本契約及び個別契約の目的の範囲内でのみ使用し、本契約及び個別契約の目的の範囲を超える複製、改変が必要なときは、事前に甲から書面による承諾を受けるものとする。

4.

個人情報の提供及び返却等については、第 39 条（資料等の提供及び返還）を準用する。

5.

第 1 項の定めにかかわらず、乙は、第 7 条第 1 項に従い再委託する第三者に対して、第 7 条第 3項の措置をとった上で、当該個人情報を開示できるものとする。

101

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、実務上の注意点は現在においても同様と考えられるため、本条に変更はない。なお、「個人情報の保護に関する法律」の改正における個人デー
タの法令項番号の変更に対応するため「法第 2 条第 4 項」を「法第 2 条第 6 項」に修正した。
【条文解説】
１．趣旨
個人情報も秘密情報も漏洩しないように管理しなければならない点は共通するが、個人情報保護法が求める安全管理措置等に鑑みると、個人情報については、秘密情報に関する前条とは異なる規定が必要となり、本条が設けられている。なお、委託者となるユーザは、同法第 22 条に基づいて委
託先監督責任を負うものであり、本条はこの責任を果たす位置付けにもなる。
（１）第 1 項①本条では次の（a）、（b）の個人情報を対象としている。
（a）個人データ（法第 2 条第 6 項に規定する個人データをいう。以下、同じ。）（b）本件業務遂行のため、甲乙間で個人データと同等の安全管理措置（法第 20 条に規定する
安全管理措置をいう。）を講ずることについて、個別契約その他の契約により合意した個
人情報②本項では、ユーザからベンダが取扱いを委託された当該個人情報の取扱いについて、次の 3 点を定める。
（a）個人情報の保護義務をベンダが負うこと。
（b）ユーザは、個人情報をベンダに提示する際にはその旨明示すること。
（c）ユーザは、ユーザの有する個人情報をベンダに提供する場合には、個人が特定できないよ
う加工した上で、ベンダに提供するよう努めること。
本項の「その他の契約」とは、本契約や個別契約とは別に、個人情報の取扱いを取り決めるた
めに別途取り交わす覚書や契約を想定している。
また、情報主体である個人に対し責任を負っているのはユーザであり、ユーザ自身がまず個人情報の取扱いに十分な配慮を払うべき立場にあるため、いたずらに個人情報を開示することにならないよう、個人情報が特定できないような開示上の工夫に努めるべきである旨を規定した。例
えば、テストデータについてはダミー化するなどである。
（２）第 2 項
ベンダに必要な安全管理措置を課すものである。
（３）第 3 項
個人情報の目的外使用を禁止し、さらにその複製、改変についてはユーザの承諾を必要とさせた。
（４）第 4 項
個人情報の提供、返却等については、第 39 条（資料等の提供及び返還）を準用する。
（５）第 5 項
個人情報の管理を適切に行うことを前提として、再委託先に対しても個人情報を開示するでき
ることができる旨規定し、これによりあらかじめユーザの承認を得る規定としている。

102

２．条文の背景「個人情報の保護に関する法律」（平成 15 年 5 月 30 日法律第 57 号）は、高度情報通信社会の進展に伴い個人情報の利用が著しく拡大していることに鑑み、個人情報の適正な取扱いに関し、個人情報の有用性に配慮しつつ、個人の権利利益を保護することを目的として制定された。
ユーザ･ベンダが同法に定める個人情報取扱事業者に該当する場合、個人情報の適正な取扱いについて、同法に定める義務を負うことになる。
なお、「個人情報の保護に関する法律及び行政手続における特定の個人を識別するための番号の利用等に関する法律の一部を改正する法律」（平成 27 年 9 月 9 日法律第 65 号）の全面施行において、個人情報取扱事業者の監督権限が主務大臣から個人情報保護委員会に一元化された。
【適用ガイド】１．ユーザの事業分野に関するガイドライン等の遵守について
個人情報の具体的な取扱い方法については、個人情報保護委員会の「個人情報の保護に関する法
律についてのガイドライン」に加え、ユーザの事業分野で適用されているガイドライン等も踏まえて十分協議の上、ユーザとベンダの責任分担を含め事前に取り決めておく必要がある。

第６章 権利帰属
ベンダが開発したソフトウェア等の納入物に関しては、特許権、著作権、ノウハウ等の知的財産権が発生する場合がある。本章は、納入物の所有権ならびに納入物の知的財産権の帰属および権利の行使の条件について定める。
（納入物の所有権）
第 43 条乙が本契約及び個別契約に従い甲に納入する納入物の所有権は、当該個別契約に定める時期をもって、乙から甲へ移転する。
【2008 年 JEITA モデル契約との相違】
改正前民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
納入物の所有権の移転時期は個別契約で定めることとしている。
２．条文の背景
納入物の納入と納入物の対価の支払いには通常タイムラグがあることから、対価の支払いをもって所有権を移転するなど、ユーザ・ベンダ間の取引リスクのバランスを確保する観点から、所有権の移転時期を定めるものである。

103

【適用ガイド】
１．受注制作ソフトウェアの収益認識時期について
受注制作のソフトウェア取引については、「企業は約束した財又はサービス（本会計基準において、顧客との契約の対象となる財又はサービスについて、以下「資産」と記載することもある。
）を顧客に移転することにより履行義務を充足したときにまたは充足するにつれて、収益を認識する。資産が移転するのは、顧客が当該資産に対する支配を獲得したとき又は獲得するにつれてである。」とされている32。この点、段階的な移転も許容されているが、実務においては移転時期を明確に定めておくことが望ましいため、個別契約において、所有権の移転時期を納入物の検収完了日と規定することとしている。
２．検収完了前の納入物の使用等について個別契約において、納入物の所有権の移転時期を納入物の検収完了日と規定した場合、納入物の所有権は、その検収完了まではベンダに留保されている。この点、検収が完了しない状況で、ユーザが検査以外の目的で納入物を使用等する場合は、ベンダの許諾を得る必要があるので、留意願いたい。
（納入物の特許権等）
第 44 条

本件業務遂行の過程で生じた発明その他の知的財産又はノウハウ等（以下、合わせて「発明等」という。）に係る特許権その他の知的財産権（特許その他の知的財産権を受ける権利を含む。但し、著作権は除く。）、ノウハウ等に関する権利（以下、特許権その他の知的財産権、ノウハウ等に関する権利を総称して「特許権等」という。）は、当該発明等を行った者が属する当事者に帰属するものとする。
2.

甲及び乙が共同で行った発明等から生じた特許権等については、甲乙共有（持分は貢献度に応じて定める。）とする。この場合、甲及び乙は、共有に係る特許権等につき、それぞれ相手方の同意及び相手方への対価の支払いなしに自ら実施し、又は第三者に対し通常実施権を実施許諾することができるものとする。

3.

乙は、第 1 項に基づき特許権等を保有することとなる場合、甲に対し、甲が本契約及び個別契約に基づき本件ソフトウェアを使用するのに必要な範囲について、当該特許権等の通常実施権を許諾するものとする。なお、本件ソフトウェアに、個別契約において一定の第三者に使用せしめる旨を
個別契約の目的として特掲した上で開発されたソフトウェア（以下「特定ソフトウェア」という。）
が含まれている場合は、当該個別契約に従った第三者による当該ソフトウェアの使用についても同様とする。なお、かかる許諾の対価は、委託料に含まれるものとする。

4.

甲及び乙は、第 2 項、第 3 項に基づき相手方と共有し、又は相手方に通常実施権を許諾する特許権等について、必要となる職務発明の承継手続（職務発明規定の整備等の職務発明制度の適切な運用、譲渡手続など）、又は法人帰属の定めを行う場合はその為に必要となる手続（契約、勤務規則その他の定めにおいてあらかじめ甲又は乙に特許を受ける権利を取得させることを定める等の適切な運用）を履践するものとする。

32『企業会計基準第 29 号「収益認識に関する会計基準」』（平成 30 年 3 月 30 日、企業会計基準委員会）参照。

104

【2008 年 JEITA モデル契約との相違】
2015 年の特許法改正に対応するため、特許権等の法人帰属を定めた企業への対応を追加した。
特許法において 2015 年に職務発明制度について改正があり、一定の手続きを踏むことにより特許を受ける権利の会社帰属を認めることが出来るようになった。
今回、職務発明における承継手続きについて、会社帰属の際の手続きを並列的に定めることにより、いずれの手続きを選択したとしても規定の通りの権利帰属および権利行使に支障が無いように当事者で対応することを明示した。
【条文解説】
１．趣旨
本条は、本件業務遂行過程で生じた特許権等の帰属と実施許諾について定めるものである。
（１）第 1 項
特許権等の帰属について定めるものであり、発明者主義（発明者が属する当事者に当該発明に係る特許権等が帰属するという考え方）に則っている。
（２）第 2 項
共同発明等については共有とする旨定める。なお、持分は貢献度に応じて定める。
（３）第 3 項
第 1 項によりベンダに帰属した特許権等につき、ユーザが本件ソフトウェアを使用するのに必要な範囲で、ベンダからユーザに通常実施権を許諾するものである。なお、ユーザが第三者に使用させることを想定し、その旨個別契約で定めた本件ソフトウェアについては、当該第三者に対しても許諾する旨を定める。なお、これらの許諾に関する対価は委託料に含まれることとしている。
（４）第 4 項
本条は、特許法第 35 条に基づく職務発明規程により職務発明について発明者から会社に特許権等が承継される場合または法人帰属とする場合に必要な手続きの履践を定める。
２．条文の背景
本件業務の遂行過程で生じた発明その他の知的財産またはノウハウ等は、ユーザ・ベンダ双方にとって有用な知的財産であり、それを適切に使いこなしていくことがソフトウェア生産性の向上、ひいては産業活力の向上に資すると考えられる。したがい、その貢献度に応じた特許等の権利の帰属および行使の条件についてあらかじめ定めるものである。
【適用ガイド】
１．従前よりベンダが有していた特許権等の実施許諾
本契約では、開発された本件ソフトウェアの使用の際に、従前よりベンダが有している特許権等を使用する場合の条件については特段定めていない。実際の案件において、このような状況が生じた場合、本契約とは別に、ベンダ保有特許権等の実施許諾の条件についてユーザ・ベンダ間で合意
されたい。

105

（納入物の著作権）
第 45 条納入物に関する著作権（著作権法第 27 条及び第 28 条の権利を含む。）は、甲又は第三者が従前から保有していた著作物の著作権を除き、乙に帰属するものとする。
2.

甲は、納入物のうちプログラムの複製物を、著作権法第 47 条の 3 及び第 47 条の 6 第 1 項第 2号に従って自己利用に必要な範囲で、複製、翻案することができるものとする。また、本件ソフ
トウェアに特定ソフトウェアが含まれている場合は、本契約及び個別契約に従い第三者に対し利用を許諾することができる。乙は、かかる利用について著作者人格権を行使しないものとする。

【2008 年 JEITA モデル契約との相違】
2018 年の著作権法改正における参照条文変更等に対応するため、本条第 2 項の「著作権法第 47 条の 2」を「第 47 条の 3 及び第 47 条の 6 第 1 項第 2 号」に変更した。
旧「著作権法第 47 条の 2 に従って」という規定は、「複製、翻案することが出来る」と規定するための理由に該当する部分である。2019 年 1 月 1 日施行の改正著作権法においては、第 47 条の 3 でプ
ログラムの複製物の所有者による複製を、第 47 条の 6 第 1 項第 2 号で翻案を可能と定めていることか
ら参照条文の変更を行った。なお、著作権法の条文変更理由は、文言整理のためであり、複製、翻案することが出来るという規定趣旨に変更はない。
また、当事者間の理解が可能であれば、「著作権法第 47 条の 3 及び第 47 条の 6 第 1 項第 2 号に従って」の文言自体を削除することでもよいと考えられる。
【条文解説】
１．趣旨
本条は、納入物の著作権の帰属と利用の条件について定める。
開発契約における著作権の帰属としては、著作権の有効活用とユーザの競争力の保持とのバラン
スから 3 案（【Ａ案】ベンダにすべての著作権を帰属、【Ｂ案】汎用的な利用が可能なプログラム等の著作権をベンダ、それ以外はユーザに帰属、【Ｃ案】汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有）が考えられるが本条は A 案を採用している。
（１）第 1 項
納入物の著作権は、ユーザまたは第三者が従前から保有していた著作権を除き、ベンダにすべて帰属するものと規定する。
（２）第 2 項
ユーザの自己使用に必要な複製または翻案について定める。なお、ユーザが第三者に使用させることを想定し、その旨個別契約で定めた本件ソフトウェアについては、当該第三者に対しても許諾する旨を定める
２．条文の背景（１）ソフトウェアの再利用の促進：日本版バイ・ドール法
2007 年の産業技術力強化法改正により、従来、国の委託研究の成果に係る特許権等33を受託者に帰属させることを可能とする｢日本版バイ･ドール法｣が同法に移管されるとともに、委託研究のみならず、国が請け負わせたソフトウェア開発の成果に係る特許権等も受託者に帰属させること
33

特許権、実用新案権、意匠権、回路配置利用権ならびにこれの登録･設定を受ける権利および著作権、育成者権106

が可能となった。この法改正を踏まえ、2007 年 8 月に経済産業省から「ソフトウェアに係る日本版バイ・ドール制度に係る運用ガイドライン」34が公表されている。
同ガイドラインによると、この法改正では、｢国等におけるソフトウェアの自由な利活用（複製、翻案又は改変等を含む）の確保と、秘密の保持ができれば、必ずしも特許権等を国等に帰属させる必要はなく、むしろ、当該特許権等を事業者に帰属させることにより、ソフトウェアの産業の技術力及び生産性が向上するとともに、当該知財の対価の分だけ発注金額が低下すること｣が期待されている。そして、国等が発注するソフトウェア開発では、従来、その成果の特許権等が国に帰属することが一般的であったが、「デジタル・ガバメント推進標準ガイドライン」（平成 30 年 3
月 30 日各府省情報化統括責任者（CIO）連絡会議決定）及び「政府情報システムの整備及び管理に関する標準ガイドライン実務手引書」（内閣官房情報通信（IT）総合戦略室 総務省行政管理局 平
成 27 年 3 月 19 日）において、「国が請け負わせたソフトウェアの開発の成果」について、国の業務に特化した汎用性のないものおよび継続的な機能改修が見込まれるものを除き、一般に、産業技術力強化法第 17 条に基づき、受注者側に知的財産権が帰属するものであることに留意するものとすることが示された。
そこで、ソフトウェア産業の技術力向上には技術の蓄積が不可欠であり、そのためには、ベンダにおいて、ユーザの秘密を保持したうえで、ソフトウェア資産を蓄積し、自由に活用できることが必要である。
他方、ユーザとしても、開発委託したソフトウェアが目的どおりに利用できることが担保されるべきことは当然である。
このような背景･観点から、本契約では、ベンダ帰属を原則とする A 案を採用している。
【適用ガイド】１．ソフトウェア著作権の有効活用の観点からの規定
創作者であるベンダにとっては、著作物に含まれうるユーザのノウハウや、ユーザの競争力の保持については、当然配慮すべきであることを前提35として、ソフトウェアの有効活用によりソフト
ウェアの生産性の向上が一層図られるような工夫をしていく必要があり、この観点から、本条は A案を採用した。
なお、B 案、C 案を用いる場合の留意点は以下のとおりである。
（１）B 案（汎用的な利用が可能なプログラム等の著作権をベンダ、それ以外はユーザに帰属）①汎用的な利用が可能なプログラムの著作権ベンダに留保されるプログラムの「汎用的な利用」、について明示（例えば、納品時に明示するなど）する必要がある。
（納入物の著作権）
第〇条

納入物に関する著作権（著作権法第 27 条及び第 28 条の権利を含む。以下、同じ。）は、乙又は第三者が従前から保有していた著作物の著作権及び汎用的な利用が可能なプログラムの著作権を除き、甲より乙へ当該個別契約に係る委託料が完済され

34
35

経済産業省平成 19 年 8 月「ソフトウェアに係る日本版バイ・ドール制度に係る運用ガイドライン」
ユーザのノウハウ流出防止には、契約上の手当てとしては秘密保持義務により可能である。

107

たときに、乙から甲へ移転する。なお、かかる乙から甲への著作権移転の対価は、委託料に含まれるものとする。
2.

甲は、著作権法第 47 条の 3 及び第 47 条の 6 第 1 項第 2 号に従って、前項により乙に著作権が留保された著作物につき、本件ソフトウェアを自己利用するために必要な範囲で、複製、翻案することができるものとし、乙は、かかる利用について著作者人
格権を行使しないものとする。また、本件ソフトウェアに特定ソフトウェアが含まれている場合は、本契約及び個別契約に従い第三者に対し利用を許諾することができるものとし、かかる許諾の対価は、委託料に含まれるものとする。

（２）C 案（汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有）①汎用的な利用について｢汎用的な利用｣についての考え方を明確にすべき点は、B 案と同様。
②共有（持分均等）について汎用的な利用が可能なプログラム以外のプログラムの著作権の共有の持分については、創作の寄与分に応じて具体的に定める考え方もある。個別案件の事情に応じて適切に規定されたい。
（納入物の著作権）
第〇条

納入物のうち本件業務によって新たに生じたプログラムに関する著作権（著作権法第 27 条及び第 28 条の権利を含む。）は、汎用的な利用が可能なプログラムの著
作権を除き、個別契約において定める時期（選択案１「当該個別契約に係る委託料が完済されたとき」、選択案２「納入物の検収完了時」）をもって、甲及び乙の共有（持分均等）とし、いずれの当事者も相手方への支払いの義務を負うことなく、第三者への利用許諾を含め、かかる共有著作権を行使することができるものとする。なお、乙から甲への著作権移転の対価は、委託料に含まれるものとする。また、乙は、甲のかかる利用について著作者人格権を行使しないものとする。
2.

甲及び乙は、前項の共有に係る著作権の行使についての法律上必要とされる共有者の合意を、あらかじめこの契約により与えられるものとする。

3.

甲及び乙は、相手方の同意を得なければ、第 1 項所定の著作権の共有持分を処分することはできないものとする。

（乙による納入物の再利用）
第 46 条乙は、第 41 条（秘密情報の取扱い）に反しない範囲において、乙が著作権を保有する本件

ソフトウェアその他の納入物を利用することができる。
2.

前項による利用には、有償無償を問わず乙が本件ソフトウェアの利用を第三者に許諾し、又はパッケージ化して複製物を販売する場合を含むものとする。

【2008 年 JEITA モデル契約との相違】
改正前民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。

108

【条文解説】
１．趣旨著作物としての本件ソフトウェアその他の納入物をベンダが再利用する際には、著作権だけでなく、第 41 条の秘密保持義務に違反しないよう、取り計らう必要がある。この点を確認的に定めたものである。
再利用には、有償無償を問わずベンダが本件ソフトウェアを第三者に許諾したり、パッケージ化
して再販売する場合を含む。
【適用ガイド】１．再利用上の工夫
ユーザの秘密情報を含む著作物を再利用する場合、ベンダはユーザとの間で当該秘密情報の利用許諾を得る必要がある。この点、納入物の再利用を予定しているような場合においては、当該再利用予定部分にはユーザの秘密情報を含まないような開発を工夫することも一案である。

第７章 保証及び責任【A 案】（知的財産権侵害の責任）
第 47 条甲が納入物に関し第三者から、日本国内における著作権、特許権その他の産業財産権（以下、本条において「知的財産権」という。）の侵害の申立を受けた場合、次の各号所定のすべての要件が充たされる場合に限り、第 53 条（損害賠償）の規定にかかわらず乙はかかる申立によって甲が支払うべきとされた損害賠償額を負担するものとする。但し、第三者からの申立が乙の責に帰すべからざる事由による場合（甲乙間で別段合意がない限り、第 48 条に定める第三者ソフトウェア又は第49 条に定める FOSS に起因する場合を含む。）にはこの限りではなく、乙は一切責任を負わないものとする。
①

甲が第三者から申立を受けた日から〇日以内に、乙に対し申立の事実及び内容を通知すること②

甲が第三者との交渉又は訴訟の遂行に関し、乙に対して実質的な参加の機会及びすべてについての決定権限を与え、並びに必要な援助をすること③

甲の敗訴判決が確定すること又は乙が訴訟遂行以外の決定を行ったときは和解などにより確定的に解決すること

2.

乙の責に帰すべき事由による知的財産権の侵害を理由として納入物の将来に向けての使用が不可
能となるおそれがある場合、乙は、乙の判断及び費用負担により、（ⅰ）権利侵害のない他の納入物との交換、（ⅱ）権利侵害している部分の変更、（ⅲ）継続使用のための権利取得のいずれかの措置を講じることができるものとする。

3.

第 1 項に基づき乙が負担することとなる損害以外の甲に生じた損害については、第 53 条（損害賠償）の規定によるものとする。

109

【B 案】（知的財産権侵害の責任）
第○条

本契約及び個別契約に従った甲による納入物の利用が、第三者の日本国内における著作権、特許権その他の産業財産権（以下、本条において「知的財産権」という。）を侵害したとき、乙は第53 条（損害賠償）所定の金額を限度として、甲に対してかかる侵害によって甲に生じた損害（侵害を回避した代替プログラムへの移行を行う場合の費用を含む。）を賠償する。但し、知的財産権の侵害が乙の責めに帰すべからざる事由による場合（甲乙間で別段合意がない限り、第 48 条に定める
第三者ソフトウェア又は第 49 条に定める FOSS に起因する場合を含む。）はこの限りでなく、乙は一切責任を負わないものとする。
2.

甲は、本契約及び個別契約に従った甲による納入物の利用に関して第三者から知的財産権の侵害の申立を受けた場合、速やかに書面でその旨を乙に通知するものとし、乙は、甲の要請に応じて甲の防御のために必要な援助を行うものとする。

【2008 年 JEITA モデル契約との相違】
改正前民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても同様と考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は、納入物が第三者の著作権、特許権等の知的財産権を侵害した場合のベンダの責任について定める。なお、A 案はベンダ主導で、B 案はユーザ主導で、それぞれ紛争の解決にあたる場合に適用されることを想定している。
２．条文の背景（１）知的財産権の侵害の責任分担等「著作権侵害についてはクリーンルーム手法等による回避の可能性もあるが、特許権は未公開中のものもあるし、公開済みの出願であっても、ベンダにおいて侵害の有無をすべてを完全に調査検証することは事実上困難であるし、海外も含め調査検証にかなりの費用を要することもある。
また、ベンダが、第三者の知的財産権に関する納入物の非侵害を保証することは現実的ではない
ため、侵害時の責任分担を定めておくことも必要となる」36ため、納入物が第三者の知的財産権を侵害した場合の責任分担を定めておく必要がある一方で、その非侵害をあらかじめベンダに保証させることは現実的でない。
また、紛争の解決をベンダ主体で行う場合とユーザ主体で行う場合に分けて責任分担のあり方を決めておくべき点についても同様と考える。
（２）弁護士費用について
弁護士費用の取扱いについては、様々なトラブルの場面で問題となりうるものであることから、本条に特に明記する必要はなく、第 3 項の規定（第 53 条の損害賠償）に基づく処理を委ねることとしている。なお、事案の性格に応じて相当と認められる額の範囲内のものであれば、弁護士費36『2007 年経済産業省報告書』99 頁。

110

用は相当因果関係の範囲内と認められ得る（最高裁昭和 44 年 2 月 27 日判決）37。また、ベンダが第三者の知的財産権侵害に関し交渉または訴訟を弁護士に委任して行う場合、これに要する費用がベンダの自弁となることは自明である。
【適用ガイド】
１．納品後に成立した第三者特許等
納品後に成立した第三者特許等については、開発時のベンダには予見不可能なものであり、その侵害責任を負うことは妥当ではないことから、このような場合の第三者特許等の侵害は、「乙の責に帰すべからざる事由」の一つと考えられる。
２．ベンダがユーザに代わって知的財産権の侵害を処理する場合の条件
ベンダが納入した成果物に知的財産権の侵害が存在した場合、原則としてベンダがその責任を負うべきであるが、一方で、ユーザにも損害軽減義務が認められるべきとも考えられる。そこで、A
案の第 1 項に「④乙が要請した場合は甲は納入物の使用を速やかに中止すること」を付け加え、ユーザの使用継続によって知的財産権の侵害による損害額が拡大するおそれがある場合に、ベンダが納入物の使用を中止するよう要請できる余地を残すことも考えられる。
３．ユーザ提供資料の第三者特許等の侵害問題
ユーザがベンダに対して提供する資料に起因する知的財産権の侵害を意識した規定を設ける場合がある。その例として、第三者特許等不侵害の保証について双務規定とする例と、第三者情報記載
資料の利用制限に関する例を以下に掲げる。
［第三者特許等非侵害の保証について双務規定とする例］（知的財産権侵害の責任）
第○条

乙は本契約及び個別契約に定める納入物の提供時において、また、甲は乙に提供した資料等の提供時において（以下、納入物と資料等を総称して本条で「提供物等」という。）、それぞれ提供物等又はその使用が第三者の日本国における著作権、特許権、実用新案権、意匠権、商標権、その他の産業財産権（以下「知的財産権」という。）を侵害していないことを保証する。但し、当該提供物等を提供した当事者の責めに帰することができない事由による場合（甲乙間で別段の合意がない限り、第 48 条に定める
第三者ソフトウェア又は第 49 条に定める FOSS に起因する場合を含む。）はこの限り
ではない。
2.

甲及び乙は、前項に定める保証に違反し、提供物等又はその使用が第三者の知的財産権を侵害し、又はそのおそれがある場合には、相手方に対しその旨速やかに通知するとともに、自己の責任と負担において処理、解決するものとする。

37

高度に専門化・技術化した訴訟追行を弁護士に委任することが常態化している実態を踏まえ、不法行為の被害者が負担のやむなきに至った弁護士費用を当該不法行為と相当因果関係に立つ損害とした。

111

［第三者情報記載資料の利用制限に関する例］（知的財産権侵害の責任）
第○条

乙が甲より貸与された資料に第三者の情報が含まれ、当該資料の乙の利用に関し制限がある場合、甲はその制限を別途書面で乙に通知するものとし、乙は当該制限を遵守して本件業務を実施するものとする。
（第三者ソフトウェアの利用）
第 48 条甲又は乙は、本件ソフトウェアが備える予定の機能、仕様の一部とするために、第三者ソフ

トウェアを利用しようとするときは、第 4 条に定める個別契約に定めるものとし、本件業務遂行の過程において第三者ソフトウェアを利用しようとするときは、第 37 条（変更管理手続）によるものとする。
2． 前項に基づき第三者ソフトウェアを利用することとなった場合、甲は、甲の費用と責任において、甲と当該第三者との間で当該第三者ソフトウェアのライセンス契約及び保守契約の締結等、必要な措置を講じるものとする。但し、乙が、当該第三者ソフトウェアを甲に利用許諾する権限を有する
場合は、甲乙間においてライセンス契約等、必要な措置を講じるものとする。
3． 乙は、第三者ソフトウェアに関して、著作権その他の権利の侵害がないこと及び不具合のないことを保証するものではなく、乙は、第 1 項に基づく利用決定時に、権利侵害又は不具合の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。但し、前項但書の場合で、甲乙間において当該第三者ソフトウェアに関するライセンス契約が締結され、当該ライセンス契約に別段の定めがあるときには、当該定めによるものとする。
【2008 年 JEITA モデル契約との相違】
本条第 1 項において、当初から第三者ソフトウェアの利用が見込まれる場合は、個別契約に定めることを明示した。
また、本条第 3 項において、改正民法で「瑕疵」という用語が用いられなくなったことや、当初 2008
年 JEITA モデル契約においても「瑕疵」を含めた不具合全般を意味していたことから「瑕疵」を「不具合」に変更した。
【条文解説】
１．趣旨
本条は、第三者ソフトウェアを利用する場合の手続きとその利用に伴うユーザ・ベンダ間のリス
ク分担について定める。
２．条文の背景情報システムの開発に第三者ソフトウェアが利用されているケースにおいて、ベンダが第三者ソフトウェアの不具合や権利侵害の有無を把握することは困難であり、第三者ソフトウェアの利用に伴うユーザ･ベンダのリスク分担を定めておくべきと考える。また、第三者ソフトウェアの採用可否の判断時点において、以下の点に注意が必要である。
① 当初から必要であると判断された場合個別契約で明示することが望まれる。

112

② 本件業務遂行の過程で必要であると判断された場合
変更管理手続き（第 37 条）を経る必要がある。
なお、選定主体がユーザとベンダのいずれの場合であっても、双方には相手方に対する説明の必要性がある。また、本件ソフトウェアが予定している機能、仕様の一部をアプリケーションパッケー
ジにより実現することは、本件業務の内容、開発するソフトウェアの仕様範囲を変更することである。選定主体がいずれの場合であっても第 37 条が予定している手続きを踏むことが妥当である。更
に、選定責任が考慮される可能性も踏まえて、ユーザ･ベンダいずれが選定した第三者ソフトウェア
であるかについては、明確にしておく必要がある。
【適用ガイド】１．第三者ソフトウェアの種類と考え方の整理
本件ソフトウェアが、ユーザの事業に応じたアプリケーションプログラム、コンテンツ、データベース等を指すことを前提とすると、第三者ソフトウェアには、次の 3 種類が考えられる。
・本件ソフトウェアが稼動するためのプラットフォームとなる、OS、ミドルウェア等
・本件ソフトウェアを開発するためのツールとなる、CASE ツール、開発ツール、移行ツール
等
・本件ソフトウェアが予定している仕様や機能を実現するためのアプリケーションパッケージ
しかしながら、再考するに、次のとおり、①および②を第三者ソフトウェアに含ませる必要はな
いと考えられ、第三者ソフトウェアとは、③のアプリケーションパッケージであると定義付けることで足りるものと考える。
① OS、ミドルウェア等
これらのソフトウェア製品は通常、アプリケーションプログラムが動作するプラット
フォームとして、アプリケーションプログラムの開発を主題とする本契約の枠外で使用許諾契約などの別途の契約により取引されるものであり、本契約の中で取り決める必要はないと考える。
また、これらのソフトウェア製品の追加、変更も、本件ソフトウェアの機能や仕様の変更を必ずしも伴うものではない。もちろんこれを伴う場合もあるが、そのような場合には、本件業務に関する条件（納期、委託料等）にも影響しうるものである。しかし、このことは、
第三者ソフトウェアに限らずベンダ保有のソフトウェアでも同様であり、第三者ソフトウェ
アの場合だけを特に規定するのは妥当ではない。
そもそも、これらは本件ソフトウェアの開発前提となっているものであり、その追加、変更がシステム仕様書の内容に影響するものであるならば、システム仕様書の変更として第 37条により処理する。なお、契約の目的が、ソフトウェア開発だけでなく、付随するミドルウェ
ア、OS も併せて納品するような場合は、これらを第三者ソフトウェアとして本契約または個
別契約で合意の上、その利用に関する責任分担を定める。
② 開発ツール等
開発ツール等は、専らベンダの作業効率化等のために、ベンダが選定し、利用するものである。したがって、その選定とそれを使った結果については基本的にベンダの裁量と責任に任せてもよいと考える。すなわち、開発ツール等を使って作成された本件ソフトウェアに関する責任（契約不適合責任）の問題として処理される。なお、開発ツール等についても、一般的には、その追加、変更が本件ソフトウェアの機能や仕様の変更を必ずしも伴うものでは
113

ないが、これに伴う場合は第 37 条により処理する。
③ アプリケーションパッケージ
本件ソフトウェアが予定している機能、仕様の一部をアプリケーションパッケージにより実現する場合には、当該アプリケーションパッケージに関する権利・責任関係の他、本契約の下でベンダが作成すべき本件ソフトウェアの範囲が変わるなど、本件業務の内容、範囲も変わることとなり、その条件も問題となる。
２．ライセンス条件
第三者ソフトウェアの使用条件については本契約の枠内では定めず、別途ライセンス契約等の締結が必要となることに注意する。
（FOSS の利用）
第 49 条甲又は乙は、本件ソフトウェアが備える予定の機能、仕様の一部を実現するために、FOSSを利用しようとするときは、第 4 条に定める個別契約に定めるものとし、本件業務遂行の過程において FOSS を利用しようとするときは、第 37 条（変更管理手続）によるものとする。なお、乙が第 37 条に従い FOSS の利用を提案する場合、第 37 条第 1 項各号の事項に加え、当該 FOSS の利
用許諾条項、機能、開発管理コミュニティの名称・特徴など FOSS の性格に関する情報、当該 FOSSの機能上の制限事項、品質レベル等に関して適切な情報を書面により提供するよう努めるものとする。
2.

前項に基づき FOSS を利用することとなった場合、甲は、甲の費用と責任において、乙又は第三者との間で FOSS の保守、障害対応支援契約の締結等、必要な措置を講じるものとする。

3.

乙は、FOSS に関して、著作権その他の権利の侵害がないこと及び不具合のないことを保証する
ものではなく、乙は、第 1 項に基づく利用決定時に、権利侵害又は不具合の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。

【2008 年 JEITA モデル契約との相違】
第 1 項において、当初から FOSS の利用が見込まれる場合は、個別契約に定めることを明示した。
また、本条第 3 項において、改正民法で「瑕疵」という用語が用いられなくなったことや、当初 2008
年 JEITA モデル契約においても「瑕疵」を含めた不具合全般を意味していたことから「瑕疵」を「不具合」に変更した。
【条文解説】
１．趣旨
本条は、FOSS の利用について、第 48 条の第三者ソフトウェアの利用に関する規定と同様の趣旨を定めるものである。
２．条文の背景
第三者ソフトウェアも FOSS も、「第三者」が開発するソフトウェアであるという点では同様であるが、FOSS の場合、製品責任や権利保障について責任を負わせる相手が存在しない（または特定できない）、使用に当って、FOSS 開発管理コミュニティのポリシーや規約から制約を受ける場合が114

ある、といった相違が挙げられる。
【適用ガイド】１．第三者ソフトウェアと FOSS の違い（１）第三者ソフトウェアでは、そのライセンス契約とサポートサービス（保守）契約を第三者とユーザで締結する場合もあれば、第三者とベンダが締結することもある。
（２）一方、FOSS の場合には、ライセンサとなる当事者は、FOSS の権利者である第三者（コミュ
ニティや個人・法人）に限られる。
また、サポートサービス（保守）を、ディストリビュータ（例えば、Linux の中核となっている
カーネルに、各種の周辺ソフトウェアを独自に追加することによって、それぞれ独自の特徴を追加したディストリビューションを開発したり配布したりする企業）が提供することがあり、サポート
サービス（保守）に関する契約関係は、次のいずれかであることが一般的である。
①ディストリビュータとユーザ間で行われる②ベンダが当該サポートサービス（保守）をユーザに提供すべくディストリビュータと契約した上で当該ベンダとユーザ間で行われる（３）さらに、製品保証、権利保証について、第三者ソフトウェアではライセンサの契約により一定範囲でなされることがあるが、FOSS では何ら保証されない。
２．ベンダによる情報の提供について
FOSS については、ベンダにおいても、関連する情報をすべて入手し、かつその正確性等を検証できるとは限らない。FOSS に関する最新情報は、一般にインターネット上で入手できることになっているとはいえ、どこにどのような情報が掲示されているのかをすべて把握できるわけでもない。
このような実態を前提とせざるを得ないことから、情報提供については努力義務としている。
３．ライセンス条件
FOSS の使用条件については、本契約の枠内では定めず、当該 FOSS の利用許諾条項によることに注意する。
（セキュリティ）
第 50 条乙が納入する本件ソフトウェアのセキュリティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定めるものとする。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、セキュリティに関する合意の実務は現在においても変更がないため、本条に変更はない。
【条文解説】
１．趣旨
本条は、本件ソフトウェアのセキュリティ対策について、ユーザ・ベンダ間で必要な事項を取り決めておくべきことを定めるものである。

115

２．条文の背景
情報システムにおけるセキュリティの重要性は説明するまでもなく、セキュリティ確保が情報シス
テムの信頼性、安全性に必須のものであることから、本条を設けている。
【適用ガイド】１．考え方の整理
本件ソフトウェアのセキュリティ要件は個別契約あるいはシステム仕様書で定めるべき事項であり、それらは本件ソフトウェアの開発費の対象となる。一方、システム全体（＝広く本件ソフトウェアの稼動環境）のセキュリティ（ウィルスソフトを活用した管理等）については、本契約および個別契約とは別の契約で定める必要がある。
２．ユーザの事業分野に関するガイドライン等の遵守について
情報セキュリティの具体的な対応については、「政府機関等の情報セキュリティ対策のための統一基準」（平成 30 年度版）に加え、ユーザの事業分野で適用されているガイドライン等も踏まえて十分協
議の上、ユーザとベンダの責任分担を含め事前に取り決めておくことが望まれる。

第８章 ⼀般条項（権利義務譲渡の禁止）
第 51 条甲及び乙は、互いに相手方の事前の書面による同意なくして、本契約上の地位を第三者に承継させ、又は本契約から生じる権利義務の全部若しくは一部を第三者に譲渡し、引き受けさせ若しくは担保に供してはならない。
【2008 年 JEITA モデル契約との相違】
改正民法において、契約上の地位の移転に関する第 539 条の 2 が新設されたことや、債権譲渡に関する第 466 条第 2 項が改正されたが、契約実務においては、本条のような権利義務の禁止特約は、当事者間の信頼関係を前提とした一般条項として引き続き定められると考えられるため、本条に変更はない。
【条文解説】
１．趣旨
本条は、契約上の地位の移転及び債権等の譲渡、担保化を禁止するものである。
２．条文の背景
本条に列挙される行為は、当事者間の契約関係を変質させるおそれがあることから、これを禁止している。
【適用ガイド】116

１．ファクタリング等
本条では、契約上の地位の移転や債権の譲渡、担保化を原則として禁じていることから、ファク
タリング等の金融サービスの利用を考慮するような場合には、相手方の事前の書面による同意が必要になることに留意されたい。
（解除）第 52 条甲又は乙は、相手方に次の各号のいずれかに該当する事由が生じた場合には、何らの催告なしに直ちに本契約の全部又は一部及び履行の完了していない個別契約を解除することができる。
①

支払いの停止があった場合、又は仮差押、差押、競売、破産手続開始、民事再生手続開始、会社更生手続開始、特別清算開始の申立があった場合②

手形交換所の取引停止処分を受けた場合③

公租公課の滞納処分を受けた場合④

その他前各号に準ずるような本契約又は個別契約を継続し難い重大な事由が発生した場合⑤

監督官庁から営業の取消・停止処分等を受けたとき又は転廃業しようとしたとき⑥

解散又は本契約及び個別契約の履行若しくは本件ソフトウェアに係る事業の全部又は重要な一部を第三者に譲渡しようとしたとき

2.

甲又は乙は、相手方の責に帰すべき事由により本契約又は個別契約のいずれかの条項に違反し、相当期間を定めてなした催告後も、相手方の債務不履行が是正されない場合は、本契約の全部又は一部及び履行の完了していない個別契約を解除することができる。但し、当該期間を経過したときにおける債務の不履行が当該契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。

3.

甲又は乙は、第１項各号のいずれかに該当する場合又は前項に定める解除がなされた場合、相手方に対し負担する一切の金銭債務につき相手方から通知催告がなくとも当然に期限の利益を喪失し、直ちに弁済しなければならない。

【2008 年 JEITA モデル契約との相違】
第 2 項において、改正民法第 541 条及び第 543 条で定められた契約解除ルールを踏まえ、債務者の帰責事由および解除の制限事由（軽微要件）を追記している。詳細およびその他の変更については、
以下【条文解説】を参照されたい。
【条文解説】
１．趣旨
本条は一般に、相手方の信用状況に急激な変化が生じた場合等に備えて置かれるものである。
２．条文の背景（１）全般
履行済みの個別契約をも解除するメリットはいずれの当事者にもないことから、解除対象となる個別契約を「履行の完了していない個別契約」と限定している。
（２）第 2 項本文
改正民法第 543 条では、契約解除の主観要件が「債務者に帰責事由があること」から、
「債権者

117

に帰責事由がないこと」に変更された。
2008 年 JEITA モデル契約は、改正前民法の規定が適用されることを前提に、債務者の帰責事
由の要件を文言で定めていなかったが、改正前民法の要件を維持するため債務者の帰責事由を定めている本条項では、ユーザ・ベンダ双方にとって不経済な状態となりうる契約解除の発動はできるだけ避けるべきである。特にシステム開発の場合には、ユーザ・ベンダ双方が相当のコストをかけているため、それが途中段階で無に帰す結果を招くことは望ましいことではない。
（３）第 2 項但書
改正民法第 541 条但書の新設により、催告解除を行う場合「軽微」な際に解除ができないとされたことに伴い、本条項ではこれを但書として定めている。なお、何が取引上の社会通念に照らして「軽微」であるか否かは、契約内容、当事者間の認識、その他周辺事情が総合的に考慮されることになるため、ユーザ・ベンダは、工程のどこまで終わったかについての共通認識を連絡協議会で醸成しておくことが重要になる。
（損害賠償）
第 53 条甲及び乙は、本契約及び個別契約の履行に関し、相手方の責に帰すべき事由により損害を被った場合、相手方に対して、損害賠償を請求することができる。但し、第 29 条に定める契約不適合責任については、当該契約不適合の修正が相当な範囲内で繰返し実施されたにもかかわらず、
当該契約不適合が乙の責に帰すべき事由により修正されないことにより損害を被った場合に限り、甲は乙に対して損害賠償を請求できるものとし、当該損害賠償請求は、当該損害賠償の請求原因となる当該個別契約に定める納入物の検収完了日から○ヶ月間が経過した後は行うことができないも
のとする。
2.

前項の損害賠償の累計総額は、債務不履行、契約不適合、不当利得、不法行為その他請求原因の如何にかかわらず、また、乙に重大な過失がある場合であっても、帰責事由の原因となった個別契約に定める委託料の金額を限度とし、また、当事者が予見すべきであったか否かを問わず特別の事情から生じた損害、逸失利益については、賠償責任を負わないものとする。

【2008 年 JEITA モデル契約との相違】①「瑕疵」を「契約不適合」に用語変更している。なお、ユーザ・ベンダの責任の考え方についての変更は無い。
②改正民法で契約不適合責任は債務不履行責任として規律されたことに伴い、当該改正民法の規律と整合させるため、本文と但書の位置を見直している（第 1 項）。
③上記改正民法による規律変更はあるものの、分かりやすさの観点から、債務不履行と契約不適合を併記している。また、改正民法の「特別事情による損害」に関する規定変更に合わせ「当事者による予見の有無」を「当事者が予見すべきであったか否か」に変更している（第 2 項）。
【条文解説】
１．趣旨
本条は、本契約および個別契約の違反あるいは本件ソフトウェアにかかる契約不適合に関する法
律上の賠償責任の内容を定めるものであり、賠償請求の根拠が債務不履行責任、不法行為責任等のいずれであっても賠償累計総額は委託料金額を上限とし、かつ特別事情から生ずる損害（システム118

の第三者への転売利益など、通常生じることが一般的に予想されない損害をいう。）および逸失利益（システムが稼動していたならば得られたであろう営業利益など、債務不履行がなければ得られたであろう利益をいう。）は賠償責任の対象外とする旨定めるものである。なお、損害賠償についての規定のあり方は、個別契約のレベルでは単に契約当事者間の利益配分の問題であるため、具体的な内容はユーザ・ベンダの交渉に委ねられる。
２．条文の背景（１）損害賠償の考え方
損害賠償の成立を帰責事由ある場合に限定している。なお、帰責事由の基準については、改正
民法第 415 条第 1 項で、「契約その他債務の発生原因及び取引上の社会通念に照らして」と新たに定められたが、改正前民法下で定着している裁判実務の明文化が趣旨と思われるため、2008 年
JEITA モデル契約から文言の変更はしていない。
（２）契約不適合における損害賠償の制限（第 1 項）
システム開発においては、遅滞なく修正を終え、または相当な代替措置を講じられなかった不具合について賠償責任が認められるというのが裁判例である（東京地裁平成 14 年 4 月 22 日判決、東京地裁平成 9 年 2 月 18 日判決）ので、システムに不具合があり、ユーザの業務に支障が生じても、ベンダがユーザから指摘を受けて遅滞なく修正して対応した場合には賠償責任までは認められていないと考えられる。
そこで、相当な範囲内で繰り返し修正を実施しても修正されない場合に賠償責任が発生する内容としている。上記裁判例は改正前民法下のものではあるが、考え方自体は、改正民法下においても変わらないものと思われる。また、契約不適合にかかる損害賠償請求期間については第 29 条に合わせている。
（３）損害賠償の上限額・範囲制限（第 2 項）システム開発という取引の特性として、ベンダはユーザの事業、業務に深く関わることがある
ため、ユーザの様々な事情に触れる可能性が高い。そのため、特別事情についても予見可能性が常にありと認められ、ユーザの事業上の利益について常に責任があるとなると、委託料に占める利益に比してベンダの責任が過大となる。そこで、一定の事項を賠償責任の対象外とするとともに、損害賠償の累計総額に上限（帰責事由の原因となった個別契約に定める委託料の金額とする。）
を設けている。
なお、2007 年経済産業省報告書にあるとおり、「損害の範囲について制限を設ける場合には、通常損害のみについて責任を負い、特別事情による損害、逸失利益についての損害や間接損害を負わないとする趣旨から、直接の結果として現実に被った通常の損害に限定して損害賠償を負う旨規定することが考えられる」38が、その場合も「直接の結果として現実に被った通常の損害に限定して損害賠償を負う」とだけ規定するのではなく、合わせて「特別の事情によって生じた損害については賠償責任を負わない」旨明記しておかなければ、特別事情による損害、逸失利益についての損害や間接損害を負わないとする趣旨が必ずしも生かされないことになるので注意が必要である。
また、特別事情による損害については、改正前民法第 416 条第 2 項では「その事情を予見し、または予見することができたとき」が、改正民法で、「その事情を予見すべきであったとき」とさ
38『2007 年経済産業省報告書』104 頁

119

れた。なお、予見の主体や時期については明文化されておらず、引き続き解釈に委ねられることになると思われる。
（４）故意・重過失の扱い（第 2 項）
一般的にベンダは、賠償上限額など一定の範囲制限が付いた損害賠償条項を前提としてトラブ
ルリスクを評価し、提供する製品・サービス内容およびその他の契約条件等を勘案して、最終的に価格や契約金額を設定している。その際には、故意、重過失、軽過失と主観的要件を区分けして考えることはしていない。なぜなら、通常の事業者がこれから行おうとしている取引について故意に契約を履行しないことをあらかじめ想定することは常識的ではないからである。
また、判例上、重過失とは「通常人に要求される程度の相当な注意をしないでも、わずかの注
意さえすれば、たやすく違法有害な結果を予見することができた場合であるのに、漫然これを見すごしたような、ほとんど故意に近い著しい注意欠如の状態」（最高裁昭和 32 年 7 月 9 日判決）をいうとされる。また、近年の裁判例では、当該判例における重過失の考え方を前提に「結果の予測が可能であり、かつ、容易であること、結果の回避が可能であり、かつ容易であることが要件となる」（東京高裁平成 25 年 7 月 24 日判決）としているものもある。
しかし、これらの基準があるとはいえ、実際に起こった事象が重過失と軽過失のどちらに該当するかという判断はきわめて法的な評価であり、通常のビジネスの場面でのリスク評価において、重過失と軽過失を区分けしてそれぞれにあたる具体的状況を想起し、感覚的であれ、それぞれの確率を想定することは極めて難しいと思われる。
近年の裁判例では、ベンダに故意または重過失がある場合に、契約で定めた損害賠償の制限規定が適用されないとされたものもある（東京地裁平成 26 年 1 月 23 日判決）が、損害賠償の制限規定が適用されない場合があるとするならば、ベンダは、製品･サービスの内容や提供条件、契約
金額、その他の契約条件などのどこかで、ベンダの計算において安全サイドに立ったリスク回避のための調整が必要となる。他方でユーザとしても、ベンダがリスク回避のために調整を行い、契約金額に転嫁されることで金額が過大になる等の事態は望ましいことではないといえる。
以上の趣旨を明確にするために、本契約では、明示的に「乙に重大な過失がある場合であっても」とベンダの重過失による場合にも損害賠償は制限される旨定めた。なお、故意のベンダについてまで敢えて損害賠償責任を制限して保護する合理的な理由はないと考えられるため、故意による場合については定めていない。
この点、重大な過失といった文言ではなく、特定の事象を列挙した上で、当該事象に対しては損害賠償の制限規定を適用しないとする条件設定も考えられる。
３．免責に関するオプション条項
契約上合意された責任以外のことからベンダを免責することをより明確に定める条項を以下のようにオプションとして用意した。
（免責）
第○条

本契約又は個別契約において明示的に合意したものを除き、甲及び乙は、品質、権原、第三者の権利非侵害、商品性、特定目的への適合性を含め、明示、黙示を問わず
その他一切の責任を負わないものとする。

120

ベンダがユーザに対して何を約束したのか、契約書と作業明細書が取り交わされていても、往々にして意見の相違が発生する。
「契約書に書かれていないから、提供する必要はないはず」と「契約書には書かれていないが、これくらいは提供してくれるはず」という双方の思い込みが、時には重大な紛争に発展してしまう場合もある。ユーザ・ベンダとも、かかる状況に陥ることは当然望ましいことではなく、必要事項はできる限り契約書に盛り込むことが大切であるのはいうまでもないが、同時に記載のない事項はベンダの契約責任の対象外であると明記することも必要である。
本モデル契約では、ベンダは契約上合意されたもの以外の責任を負わないと定めるとともに、「品
質、権原、第三者の権利非侵害、商品性、特定目的への適合性」という例示を行っている。品質、商品性、特定目的への適合性といった項目は抽象的であること、権原と第三者の権利非侵害の保証については、現在または将来存在する国や地域のあらゆる法令、すべての自然人や法人が保有する権利について精査して確認することが不可能であることから、これらを対象外とするのが適切である。
本条により契約書から不確実な部分を最小限にすることができ、また、第 3 条における完全合意
条項により契約書外での合意を排除することで、契約書を明瞭かつ唯一のユーザ・ベンダの合意とすることができる。
４．不可抗力に関するオプション条項
不可抗力により契約上の義務履行ができない状況に陥った場合において、ユーザ・ベンダの責任を免責することについて明確に定める条項を以下のようにオプションとして用意した。
（不可抗力）
第○条

甲又は乙は、自らの制御し得ない事由（以下「不可抗力」という。）により、本契約及び個別契約に基づく義務の全部又は一部の履行ができない場合でも、当該不可抗力が存在しなくなった後、当該当事者が速やかに履行を再開する限り、当該当事者は何ら責任を負わないものとする。なお、当該不可抗力が相当期間にわたり存続し、本契約又は個別契約の変更が必要と判断される場合には、甲及び乙は第 33 条に基づき別途変更契約を締結するものとする。
本条は、契約当事者の合理的な支配を超えた事態の発生により、契約上の義務の履行ができない状況に陥った場合において、条件付きで債務不履行の責任を問わないものとするものである。
今日の日本において天災の脅威は現実のものとなっている。また、社会インフラが高度にシステム化された状況においては大規模な障害の発生はありうるものと考える必要がある。そのような状況が発生し場合に、相手方に債務の履行を求めることは現実的ではない。実務上は契約外の協議と合意により不可抗力条項に準ずる対応がされる場合もあると思われるが、明示的に規定することで双方のリスクを軽減することが望ましい。
なお、ユーザ・ベンダで具体例の列挙をしたい場合には、一例として第一文冒頭を「甲又は乙は、
天災地変、戦争、内乱、法令の制定改廃、公権力による命令処分、同盟罷業その他の労働争議、輸送機関の事故、自己が本契約及び個別契約の履行のために用いる者の履行不能、感染症のパンデミッ
ク等を含む不可抗力により（以下同文）」と具体的に定めることも考えられる。実際に列挙する事由は個別に検討されたい。

121

（輸出関連法令の遵守）
第 54 条甲は、乙から納入された納入物を輸出する場合には、外国為替及び外国貿易法その他輸出関連法令を遵守し、所定の手続をとるものとする。なお、米国輸出関連法等外国の輸出関連法令の適用を受け、所定の手続が必要な場合も同様とする。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても変更がないため、本条に変更はない。
【条文解説】
１．趣旨
本条は、外国為替および外国貿易法による規制対象物資の輸出に関してユーザが所定の手続きをとるべきこと、また、米国など外国製品の再輸出に関してもユーザが所定の手続きをとるべきことを定めるものである。
２．条文の背景
外国為替および外国貿易法による規制対象物資（大量破壊兵器などの製造に寄与する関連資機材、武器および通常兵器関連汎用品ならびに関連技術）に該当する納入物を輸出する場合、ユーザは、所定の手続きを行う必要がある。これを怠ると、ユーザは制裁を科せられるので、注意喚起の意味
で関連法規の遵守を定めるものである。
（反社会的勢力の排除）
第 55 条甲及び乙は、現時点及び将来にわたって、自己が次の各号のいずれにも該当しないことを表明し、又は確約する。
①

暴力団、暴力団員、暴力団準構成員、暴力団関係企業、総会屋、社会運動等標ぼうゴロ、特殊知能暴力集団その他これらに準ずる者（以下、総称して「反社会的勢力」という。）であること
又は反社会的勢力であったこと。

②

反社会的勢力が経営を支配していること。

③

代表者、責任者又は経営に実質的に関与している者が反社会的勢力であること。

④

自己又は第三者の不正の利益を図る目的をもってする等反社会的勢力を利用していると認められる関係を有すること。

⑤

反社会的勢力に対して資金等を提供し、又は便宜を図る等反社会的勢力に利益を供与していると認められる関係を有すること。

⑥

反社会的勢力と密接に交際をする等社会的に非難されるべき関係を有すること。

⑦

暴力的又は法的な責任を超えた不当な要求行為を行うこと。

⑧

取引に関して脅迫的な言動をし、又は暴力を用いる行為を行うこと。

⑨

風説を流布し、又は偽計若しくは威力を用いて、相手方の信用を毀損し、又は相手方の業務を妨害する行為を行うこと。

2.

甲及び乙は、自己が本契約及び個別契約の履行のために用いる者（個人か法人かを問わず、数次

122

の取引先等第三者を介して用いる者を含み、以下、総称して「履行補助者」という。）が前項各号のいずれかに該当した場合、当該履行補助者との契約の解除その他の必要な措置を講じることを確約する。
3.

甲又は乙が前二項の表明又は確約のいずれかに反した場合、相手方は通知その他の手続を要しな
いで、本契約及び個別契約の全部又は一部を解除することができる。

【2008 年 JEITA モデル契約との相違】
新規に追加した。
【条文解説】
１．趣旨
本条は、2007 年 6 月 19 日に「企業が反社会的勢力による被害を防止するための指針」が犯罪対策閣僚会議幹事会申し合わせの形で公表されたことにはじまる企業の暴力団対策強化に係る取組みの流れや、全国各地で制定された暴排条例の内容を踏まえた、いわゆる暴排条項として定めるものである。
２．条文の背景東京都を例に取ると、「東京都暴力団排除条例」（平成 23 年 3 月 18 日東京都条例第 54 号）では、
その第 18 条第 1 項において、事業者は契約の相手方、代理人、媒介者が暴力団関係者でないことを確認すべきであることを求めている。
また、第 18 条第 2 項において、事業者が契約を書面により締結する場合に、導入すべき特約条項として、次の 3 点（概要）を求めている。39①契約の相手方、代理人、媒介者が暴力団関係者であることが判明した場合に、当該契約を無催
告解除できること。
②関連契約の当事者、代理人、媒介者が暴力団関係者であることが判明した場合に、契約の相手方に対して、関連契約の解除等の措置を求めることができること。
③契約の相手方に関連契約の解除等を求めたが、相手方が正当な理由なくこれを拒絶した場合は、契約を解除できること。
本条は、当該「東京都暴力団排除条例」第 18 条をはじめ、多くの条例で定められている事業者の努力義務を満たす条件を定めている。
なお、暴排条例では、暴力団等の定義を「暴力団員又は暴力団員でなくなった日から 5 年を経過しない者」とするものもあり、本条による表明・確約の範囲をこの定義に合わせることも検討の余地がある。
また、当該暴排条例で求められている事項のほか、次のように解除に伴う清算や免責条件を追加で定めることも考えられる。

39『東京弁護士会会報 LIBRA Vol.12 No.5 』3 頁参照。

123

［ベンダによる代金請求を定める場合］
X．第 3 項の定めに基づき本契約及び個別契約の全部又は一部が解除された場合、乙は、甲に対し、既に着手した個別契約に基づく業務に係る委託料の支払いを請求することができる。
［解除した当事者（ベンダまたはユーザ）への損害賠償請求を定める場合］
X．第 3 項の定めに基づき本契約及び個別契約の全部又は一部が解除された場合、解除した当事者に損害が生じたときは、相手方はその損害を賠償するものとする。
［解除した当事者（ベンダまたはユーザ）の免責を定める場合］
X．第 3 項の定めに基づき本契約及び個別契約の全部又は一部が解除された場合、解除した当事者は、相手方に損害が生じても、これを賠償することを一切要しないものとする。
（和解による紛争解決）
第 56 条本契約に関し、甲乙間に紛争が生じた場合、甲及び乙は、第 57 条所定の紛争解決手続をとる前に、紛争解決のため第 12 条に定める連絡協議会を開催し協議を十分に行うとともに、次項以下の措置をとらなければならない。
2.

前項所定の連絡協議会における協議で甲乙間の紛争を解決することができない場合、第 57 条に定める紛争解決手続をとろうとする当事者は、相手方に対し紛争解決のための権限を有する代表者又は代理権を有する役員その他の者との間の協議を申し入れ、相手方が当該通知を受領してから○日以内に（都市名）において、誠実に協議を行うことにより紛争解決を図るものとする。

3.

前項所定の甲及び乙の紛争解決のための協議で当事者間の紛争等を解決することができない場
合、甲及び乙は、裁判外紛争解決手続の利用の促進に関する法律（平成 16 年法律第 151 号）第 2
条第 3 項に定める認証紛争解決手続であって（都市名）において行われる認証紛争解決事業者を選択し、当該事業者による認証紛争解決手続を通した和解による解決を図るものとする。

4.

前項に定める認証紛争解決手続によって和解が成立する見込みがないことを理由に当該認証紛争解決手続が終了した場合、甲及び乙は、第 57 条所定の紛争解決手続をとることができる。

【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても変更がないため、本条に変更はない。
【条文解説】
１．趣旨
本条は、紛争解決を当事者間の和解により行う場合の手続き等について定めるとともに、ADR（Alternative Dispute Resolution ＝ 裁判外紛争解決）機関による和解手続きの利用について定めるものである。
２．条文の背景124

紛争の最終的な解決は、法的救済手段によることになるが、その前段において、当事者間の協議
や ADR 機関の利用による和解の努力を行うことを求めている。これは、「ソフトウェア開発のような専門的で複雑な事案については、柔軟な審理が可能であり、また、技術的知見を有する専門家の判断を仰ぐことも可能であるなど、裁判所における訴訟よりも ADR の方が適切な場合もあると考えられる」40ことによる。
【A 案】
（仲

裁）

第 57 条

本契約及び個別契約に関し、甲乙間に紛争解決の必要が生じた場合、（仲裁機関名）の仲

裁規則に従って、（都市名）において仲裁により終局的に解決されるものとする。

【B 案】（合意管轄）
第○条

本契約及び個別契約に関し、訴訟の必要が生じた場合には、○○地方裁判所を第一審の専属的合意管轄裁判所とする。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても変更がないため、本条に変更はない。
【条文解説】
１．趣旨
本条は、前条による和解への努力が行われることを前提に、紛争処理を仲裁または訴訟により解決する場合の手続きを定めるものである。
２．条文の背景「情報システム開発のような専門的で複雑な事案については、裁判所による審理より、より柔軟な制度である仲裁による解決になじみやすい面がある。例えば、当事者が仲裁人を選任できるので、技術的知見を有する専門家を選任することができるし、裁判所による判決よりも柔軟で現実に即した解決を図ることも期待できる」41ため、A 案 B 案双方を採用した。
（協議）

第 58 条

本契約及び個別契約に定めのない事項又は疑義が生じた事項については、信義誠実の原則に従い甲乙協議し、円満に解決を図るものとする。
【2008 年 JEITA モデル契約との相違】
改正民法を含めた近年の法改正による影響がないことや、本条に関連する実務は現在においても変4041『2007 年経済産業省報告書』106 頁『2007 年経済産業省報告書』106 頁

125更がないため、本条に変更はない。
【条文解説】
１．趣旨
本条は、本契約および個別契約に定めのない事項あるいはそれらの規定内容に疑義が生じた場合のユーザとベンダの対応方針を示すものであり、かかる場合には、まず協議による円満解決を図る
ことを方針としている。
２．条文の背景
信義誠実の原則とは、義務の履行などにおいて他人の信頼や期待に応えて、信義に従い誠実に行動しなければならないという原則のことをいう。これから契約関係に入ろうとする当事者間には通常、何らかの信頼関係に基づいて契約関係に入る。そして、いったん成立した契約関係の維持にも信頼関係の維持が必要であり、当該契約に関する問題の解決も、この原則に則ることを基本的な対応方針としている。
（存続条項）
第 59 条

本契約が解除その他の原因により終了した場合であっても、本契約に基づく個別契約が存続する場合、その限りにおいて本契約の規定は存続するものとする。
2.

前項に加え、本契約が解除その他の原因により終了した場合であっても、第 2 条（定義）、第 3条（適用範囲・完全合意）、【B 案】第○条（契約不適合責任）、第 29 条（契約不適合責任）、第 39条（資料等の提供及び返還）第 5 項及び第 6 項、第 40 条（資料等の管理）第 1 項、第 42 条（個人情報）（但し、第 5 項を除く。）、第 44 条（納入物の特許権等）、第 45 条（納入物の著作権）、第 46条（乙による納入物の再利用）、【A 案】第 47 条（知的財産権侵害の責任）、【B 案】第○条（知的財産権侵害の責任）、第 48 条（第三者ソフトウェアの利用）第 3 項、第 49 条（FOSS の利用）第 3
項、第 53 条（損害賠償）、第 54 条（輸出関連法令の遵守）、第 56 条（和解による紛争解決）、【A案】第 57 条（仲裁）、【B 案】第○条（合意管轄）及び第 58 条（協議）は、なお有効に存続するものとする。

【2008 年 JEITA モデル契約との相違】
新規に追加した。2008 年 JEITA モデル契約では、第 41 条（秘密情報の取扱い）のみに存続条項を定めていたが、本契約では存続条項としてその他の条項についても定めた。
【条文解説】
１．趣旨
解除を含む契約終了時であっても、例えば、損害賠償や紛争解決に関する規定など、その効力を維持する必要がある条項はある。本契約では、どの条項が存続するのか明確にするため、本条において規定している。なお、「その性質上、当然に存続すべき条項については」存続するといった包括的な規定の仕方も見受けられるが、循環論法であり、明確さを欠いて後に解釈の争いを残すおそれがあることから、個別の条項について指定する形式としている。

126

付録① 本モデル契約新旧対照表（下線が変更箇所）
2008 年 JEITA モデル契約

本モデル契約

委託者：ユーザ（以下「甲」という。）と受託者：

委託者：ユーザ（以下「甲」という。）と受託者：

ベンダ（以下「乙」という。）とは、コンピュータ

ベンダ（以下「乙」という。）とは、コンピュータ

ソフトウェアの開発に係る業務の委託に関して、次ソフトウェアの開発に係る業務の委託に関して、次のとおりこの契約（以下「本契約」という。）を締のとおりこの契約（以下「本契約」という。）を締結し、その証として本書 2 通を作成し、甲乙記名押結し、その証として本書 2 通を作成し、甲乙記名押

印のうえ各 1 通を保有するものとする。

印のうえ各 1 通を保有するものとする。

平成

年

月

日

（甲）

年

（乙）
第1章

月

日

（甲）

（乙）
第1章

総則

（契約の目的）（契約の目的）第1条

第1条

本契約は、甲が、甲の○○○システムのコ

総則

本契約は、甲が、甲の○○○システムのコ

ンピュータソフトウェアの開発にかかる業務

ンピュータソフトウェアの開発にかかる業務（以下「本件業務」という。）を乙に委託し、（以下「本件業務」という。）を乙に委託し、乙はこれを受託することに関する基本的な契約

乙はこれを受託することに関する基本的な契約事項を定めることを目的とする。

事項を定めることを目的とする。

（定義）
第2条

（定義）
本契約で用いる用語の定義は、次のとおり

第2条

とする。
①

②

③

本契約で用いる用語の定義は、次のとおりとする。

本件ソフトウェア①

本件ソフトウェア

本契約及び個別契約に基づき開発されるソ本契約及び個別契約に基づき開発されるソ

フトウェア

フトウェア

要件定義書

②

要件定義書

本件ソフトウェアの機能要件（甲の要求を本件ソフトウェアの機能要件（甲の要求を満足するために、ソフトウェアが実現しな満足するために、ソフトウェアが実現しなければならない機能に係る要件。システム

ければならない機能に係る要件。システム

機能及びデータにより定義される。）及び機能及びデータにより定義される。）及び非機能要件（機能要件以外のすべての要素

非機能要件（機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアのに係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要機能と直接的な関連性を有さない品質要件、技術要件、移行要件、運用要件及び付件、技術要件、移行要件、運用要件及び付

帯作業等から成り、それぞれに対する目標

帯作業等から成り、それぞれに対する目標

値及び具体的事項により定義される。）を値及び具体的事項により定義される。）をとりまとめた文書とりまとめた文書

外部設計書

③

外部設計書

要件定義書に基づき本件ソフトウェアの画要件定義書に基づき本件ソフトウェアの画面、帳票などのユーザインタフェース、他

面、帳票などのユーザインタフェース、他

システムとの通信やデータ入出力等のインシステムとの通信やデータ入出力等のイン

127

④

⑤

⑥

⑦

⑧

タフェースなど、本件ソフトウェアの入出

タフェースなど、本件ソフトウェアの入出力全般に関する仕様を定めた設計書

力全般に関する仕様を定めた設計書

システム仕様書④

システム仕様書

要件定義書及び外部設計書（但し、要件定

要件定義書及び外部設計書（但し、要件定

義書及び外部設計書に齟齬がある場合は、義書及び外部設計書に齟齬がある場合は、

外部設計書の定めが要件定義書に優先して

外部設計書の定めが要件定義書に優先してシステム仕様書を構成するものとする。）

システム仕様書を構成するものとする。）

中間資料

⑤

中間資料

本件ソフトウェアの開発過程で生成したも本件ソフトウェアの開発過程で生成したもので、本件ソフトウェア、システム仕様書

ので、本件ソフトウェア、システム仕様書

及び検査仕様書に該当しないすべてのもの

及び検査仕様書に該当しないすべてのもの

第三者ソフトウェア⑥

第三者ソフトウェア

第三者が権利を有するソフトウェア（但し、第三者が権利を有するソフトウェア（但し、FOSS を除く。）

FOSS を除く。）

FOSS

⑦

FOSS

フリーソフトウェア及びオープンソースソ

フリーソフトウェア及びオープンソースソ

フトウェア

フトウェア

要件定義

⑧

要件定義

共通フレーム 2007 の利害関係者要件の定

共通フレーム 2013 の利害関係者の識別、要義、利害関係者要件の確認に相当するもの

件の識別、要件の評価、要件の合意、要件の記録に相当するもの

⑨

⑩

⑪

⑫

⑬

⑨

外部設計

外部設計

共通フレーム 2007 のシステム要件定義に共通フレーム 2013 のシステム要件定義プ

相当するものロセスに相当するもの

内部設計

⑩

内部設計

共通フレーム 2007 のシステム方式設計に共通フレーム 2013 のシステム方式設計プ相当するものロセスに相当するもの

システム結合⑪

システム結合共通フレーム 2007 のシステム結合に相当

共通フレーム 2013 のシステム結合プロセ

するものスに相当するもの

システムテスト⑫

システムテスト

共通フレーム 2007 のシステム適格性確認

共通フレーム 2013 のシステム適格性確認

テストに相当するもの

テストプロセスに相当するもの

導入・受入支援⑬

導入・受入支援

共通フレーム 2007 のソフトウェア導入、ソ

共通フレーム 2013 のソフトウェア導入プ

フトウェア受け入れ支援に相当するもの

ロセス、ソフトウェア受入れ支援プロセスに相当するもの

⑭

運用テスト

⑭

運用テスト

共通フレーム 2007 の運用テスト、業務及び共通フレーム 2013 の運用テスト及びサーシステムの移行に相当するもの

ビスの提供開始、業務及びシステムの移行

128

に相当するもの（適用範囲）（適用範囲・完全合意）

第3条

第3条

本件業務は、第 14 条の要件定義作成支援

本件業務は、第 14 条の要件定義作成支援

業務、第 19 条の外部設計書作成支援業務（第業務、第 19 条の外部設計書作成支援業務（第19 条において B 案を選択する場合は「外部設計19 条において B 案を選択する場合は「外部設計書作成業務」）、第 24 条のソフトウェア開発業

書作成業務」）、第 24 条のソフトウェア開発業

務、第 30 条のソフトウェア運用準備･移行支援

務、第 30 条のソフトウェア運用準備･移行支援

業務の全部又は一部から構成され、本件業務の業務の全部又は一部から構成され、本件業務の個々の業務（以下｢個別業務｣という。）には本個々の業務（以下｢個別業務｣という。）には本契約のほか、次条に基づき締結される当該個別契約のほか、次条に基づき締結される当該個別業務に関する契約（以下「個別契約」という。）

業務に関する契約（以下「個別契約」という。）

が適用されるものとする。

が適用されるものとする。

2. 甲及び乙は、個別契約において本契約の一部の2. 甲及び乙は、個別契約において本契約の一部の適用を排除し、又は本契約と異なる事項を定め適用を排除し、又は本契約と異なる事項を定めることができる。この場合、個別契約の条項がることができる。この場合、個別契約の条項が本契約に優先するものとする。また、本契約及本契約に優先するものとする。また、本契約及び個別契約が当該個別業務の取引に関する合意

び個別契約が当該個別業務の取引に関する合意

事項のすべてであり、かかる合意事項の変更は、事項のすべてであり、かかる合意事項の変更は、第 33 条（本契約及び個別契約内容の変更）に

第 33 条（本契約及び個別契約内容の変更）に従ってのみ行うことができるものとする。

従ってのみ行うことができるものとする。

（個別契約）（個別契約）

第4条

第4条

甲及び乙は、個別業務に着手する前に、甲甲及び乙は、個別業務に着手する前に、甲から乙に提示された提案依頼書（RFP）及び乙から乙に提示された提案依頼書（RFP）及び乙から甲に提案した提案書、見積書を基礎として、から甲に提案した提案書、見積書を基礎として、

当該個別業務について以下の各号のうち必要と当該個別業務について次の各号のうち必要とななる取引条件を定め、個別契約を締結する。

る取引条件を定め、個別契約を締結する。

①

具体的作業内容（範囲、仕様等）①

具体的作業内容（範囲、仕様等）②

契約類型（請負・準委任）②

契約類型（請負・準委任）③

作業期間、作業工数（作業量）又は納期③

作業期間、作業工数（作業量）又は納期④

作業スケジュール

④

作業スケジュール

⑤

甲・乙の役割分担（第 8 条で定める作業責⑤

甲・乙の役割分担（第８条で定める作業責

任分担の詳細）任分担の詳細）⑥

連絡協議会の運営に関する事項⑥

連絡協議会の運営に関する事項⑦

甲が乙に提供する情報、資料、機器、設備⑦

甲が乙に提供する情報、資料、機器、設備等（以下「資料等」という。）

等（以下「資料等」という。）

⑧

作業環境

⑧

作業環境

⑨

乙が甲の委託に基づき作成し納入すべき物⑨

乙が甲の委託に基づき作成し納入すべき物⑩

件（以下「納入物」という。）の明細及び件（以下「納入物」という。）の明細及び

納入場所

納入場所

委託料及びその支払方法⑩

129

委託料及びその支払方法

⑪

検査又は確認に関する事項⑪

検査又は確認に関する事項⑫

その他個別業務遂行に必要な事項⑫

その他個別業務遂行に必要な事項

2. 甲及び乙は、作業スケジュールの進捗に支障を2. 甲及び乙は、作業スケジュールの進捗に支障を来すことのないように各個別契約の締結交渉に来すことのないように各個別契約の締結交渉に着手し、可能な限り早期に合意に至ることので着手し、可能な限り早期に合意に至ることのできるよう双方誠実に協議するものとする。

きるよう双方誠実に協議するものとする。

（委託料及びその支払方法）（委託料及びその支払方法）

第5条

第5条

甲は乙に対し、本件業務の対価として、各甲は乙に対し、本件業務の対価として、各個別契約で定めた委託料を当該個別契約で定め個別契約で定めた委託料を当該個別契約で定めた方法で支払う。

た方法で支払う。

（作業期間又は納期）（作業期間又は納期）

第6条

各個別業務の作業期間、作業工数（作業量） 第 6 条

各個別業務の作業期間、作業工数（作業量）

又は納期は、当該個別業務に係る当該個別契約

又は納期は、当該個別業務に係る当該個別契約

で定める。

で定める。

（再委託）

（再委託）

第7条

第7条

乙は、乙の責任において、各個別業務の全

乙は、乙の責任において、各個別業務の全部又は一部を第三者（甲が指定する再委託先も部又は一部を第三者（甲が指定する再委託先も含む。）に再委託することができる。但し、乙含む。）に再委託することができる。但し、乙は、甲が要請した場合、再委託先の名称及び住は、甲が要請した場合、再委託先の名称、住所

所等を甲に報告するものとし、甲において当該等を甲に報告するものとし、甲において当該第第三者に再委託することが不適切となる合理的

三者に再委託することが不適切となる合理的なな理由が存する場合、甲は乙に、書面により、理由が存する場合、甲は乙に、書面により、そその理由を通知することにより、当該第三者にの理由を通知することにより、当該第三者に対対する再委託の中止を請求することができる。

する再委託の中止を請求することができる。

2. 前項但書により、甲から再委託の中止の請求を

2. 前項但書により、甲から再委託の中止の請求を乙が受けた場合は、作業期間若しくは納期又は乙が受けた場合は、作業期間若しくは納期又は委託料等の個別契約の内容の変更について、第委託料等の個別契約の内容の変更について、第33 条（本契約及び個別契約内容の変更）による33 条（本契約及び個別契約内容の変更）によるものとする。また当該請求に従い乙が当該個別ものとする。また、当該請求に従い乙が当該個業務に係る当該第三者との再委託に関する契約

別業務に係る当該第三者との再委託に関する契を解除した場合（但し、前項の合理的な理由が約を解除した場合（但し、前項の合理的な理由

第 52 条第 1 項又は第 2 項に基づき甲が本契約が乙と当該第三者との再委託に関する契約の解又は個別契約を解除しうる事情に相当する場合除事由に該当する場合を除く。）、当該解除にを除く。）、当該解除に伴い当該第三者に対す伴い当該第三者に対する損害賠償費用その他解る損害賠償費用その他解除に伴い乙に発生する除に伴い乙に発生する費用を、甲は負担するも費用を、甲は負担するものとする。

のとする。

3. 乙は当該再委託先との間で、再委託に係る業務

3. 乙は当該再委託先との間で、再委託に係る業務を遂行させることについて、本契約に基づいてを遂行させることについて、本契約に基づいて乙が甲に対して負担するのと同様の義務を、再乙が甲に対して負担するのと同様の義務を、再委託先に負わせる契約を締結するものとする。

委託先に負わせる契約を締結するものとする。

130

4. 乙は、再委託先の履行について甲に帰責事由が4. 乙は、再委託先の履行について甲に帰責事由がある場合を除き、自ら業務を遂行した場合と同ある場合を除き、自ら業務を遂行した場合と同様の責任を負うものとする。但し、甲の指定し様の責任を負うものとする。但し、甲の指定した再委託先の履行については、乙に故意又は重た再委託先の履行については、乙に故意又は重過失がある場合を除き、責任を負わない。

過失がある場合を除き、責任を負わない。

第2章

第2章

本件業務の推進体制

本件業務の推進体制（協働と役割分担）（協働と役割分担）

第8条

第8条

甲及び乙は、本件業務の円滑かつ適切な遂甲及び乙は、本件業務の円滑かつ適切な遂行のためには、乙の有するソフトウェア開発に行のためには、乙の有するソフトウェア開発に関する技術及び知識の提供と甲によるシステム

関する技術及び知識の提供と甲によるシステム

仕様書の早期かつ明確な確定が重要であり、甲仕様書の早期かつ明確な確定が重要であり、甲乙双方による共同作業及び各自の分担作業が必乙双方による共同作業及び各自の分担作業が必要とされることを認識し、甲乙双方による共同要とされることを認識し、甲乙双方による共同作業及び各自の分担作業を誠実に実施するとと作業及び各自の分担作業を誠実に実施するとともに、相手方の分担作業の実施に対して誠意をもに、相手方の分担作業の実施に対して誠意をもって協力するものとする。

もって協力するものとする。

2. 甲乙双方による共同作業及び各自の分担作業

2. 甲乙双方による共同作業及び各自の分担作業

は、各個別契約においてその詳細を定めるもの

は、各個別契約においてその詳細を定めるもの

とする。

とする。
3. 甲及び乙は、本件業務の円滑かつ適切な遂行のためには、相互の協力が必要であることを認識し、乙は、本件業務の進捗管理を行うものとし、甲は誠実に協力（プロジェクトの円滑な遂行のために迅速に判断を行い、時期に遅れた仕様の変更を行わず、かつ情報、人員、施設、設備、什器の提供等）を行うものとする。
4. 甲及び乙は、前各項に定めるプロジェクトマネ
ジメント及び協力を行うにあたり必要となる事項については、速やかに第 9 条ないし第 11 条に規定する者に連絡し、必要に応じて第 12 条に規定する会議体において協議するものとする。

3. 甲及び乙は、共同作業及び各自の実施すべき分

5. 甲及び乙は、共同作業及び各自の実施すべき分担作業を遅延し又は実施しない場合、それによ

担作業を遅延し又は実施しない場合、それにより相手方に生じた損害の賠償も含め、かかる遅り相手方に生じた損害の賠償も含め、かかる遅延又は不実施について相手方に対して責任を負

延又は不実施について第 53 条（損害賠償）の規

うものとする。

定に従い相手方に対して責任を負うものとす
る。

（責任者）
第9条

（責任者）

甲及び乙は、各個別契約締結後すみやかに、 第 9 条

131

甲及び乙は、各個別契約締結後速やかに、

各個別契約における各自の責任者をそれぞれ選各個別契約における本条に定める権限及び責任

任し、互いに書面により、相手方に通知する。

を有する各自の責任者（以下「責任者」という。）

なお、当該個別契約において双方の体制図を定をそれぞれ選任し、互いに書面により、相手方

め、当該体制図に当該責任者を記載することをに通知する。なお、当該個別契約において双方

もって通知に代えることができるものとする。

の体制図を定め、当該体制図に当該責任者を記載することをもって通知に代えることができる
ものとする。

2. 甲及び乙は、事前に書面により相手方に通知す

2. 甲及び乙は、事前に書面により相手方に通知することにより、責任者を変更できるものとする。

ることにより、責任者を変更できるものとする。

3. 甲の責任者は、次の各号に定める権限及び責任3. 甲の責任者は、次の各号に定める権限及び責任を有するものとする。
①

を有するものとする。

第 17 条所定の要件定義書の確定を行う権①

第 17 条所定の要件定義書の確定②

第 22 条所定の外部設計書の確定③

第 27 条所定の検査仕様書の確定④

第 26 条及び第 28 条所定の納入物の検収⑤

第 35 条所定の中間資料の承認⑥

第 36 条所定の未確定事項の確定後、確定し

限及び責任
②

第 22 条所定の外部設計書の確定を行う権
限及び責任

③

第 27 条所定の検査仕様書の確定を行う権
限及び責任

④

第 26 条及び第 28 条所定の納入物の検収を行う権限及び責任⑤

第 35 条所定の中間資料の承認に関する権
限及び責任

⑥

第 36 条所定の未確定事項の確定後、確定した要件定義書、外部設計書の追完、修正の業た要件定義書、外部設計書の追完、修正の務を請求する権限及び責任

業務の請求

⑦

第 37 条所定の変更管理書を相手方に交付

⑦

する権限
⑧

第 37 条所定の変更管理書の相手方への交付

第 48 条及び第 49 条所定の第三者ソフト⑧

ウェア及び FOSS の採否を行う権限及び責第 48 条及び第 49 条所定の第三者ソフト
ウェア及び FOSS の採否の行為

任⑨

その他本契約及び個別契約の遂行に必要な⑨

権限及び責任4. 乙の責任者は、次の各号に定める権限及び責任権限及び責任4. 乙の責任者は、次の各号に定める権限及び責任を有するものとする。
①

その他本契約及び個別契約の遂行に必要なを有するものとする。

第 14 条の要件定義作成支援業務の実施に①

際し、甲から要請された事項の対応に関す

第 14 条の要件定義作成支援業務の実施に際し、甲から要請された事項の対応る権限及び責任②

第 19 条の外部設計書作成支援業務の実施②

に際し、甲から要請された事項の対応に関

第 19 条の外部設計書作成支援業務の実施に際し、甲から要請された事項の対応する権限及び責任③

第 27 条の検査仕様書作成支援業務の実施③

132

第 27 条の検査仕様書作成支援業務の実施

に際し、甲から要請された事項の対応に関に際し、甲から要請された事項の対応する権限及び責任④

第 26 条及び第 28 条所定の納入物の検収を

第 26 条及び第 28 条所定の納入物の検収の

④

求める権限
⑤

要請

第 35 条所定の中間資料の承認を求める権⑤

第 35 条所定の中間資料の承認の要請⑥

第 36 条所定の未確定事項の確定の際の、追限⑥

第 36 条所定の未確定事項が確定したときは、追完、修正の業務の請求を書面で受け完、修正の業務の請求の書面での受領る権限⑦

第 37 条所定の変更管理書を相手方に交付

第 37 条所定の変更管理書の相手方への交

⑦

する権限
⑧

付

その他本契約及び個別契約の遂行に必要な⑧

権限及び責任その他本契約及び個別契約の遂行に必要な権限及び責任5. 甲及び乙は責任者を複数名定める場合は、それ5. 甲及び乙は、責任者を複数名定める場合は、そぞれの権限範囲を明確にし、相手方に通知する

れぞれの権限範囲を明確にし、相手方に通知すものとする。

るものとする。

6. 責任者が複数の場合には、甲及び乙は協議の

6. 責任者が複数の場合には、甲及び乙は協議の上、総括責任者をおくことができるものとする。

上、総括責任者をおくことができるものとする。

（主任担当者）（主任担当者）

第 10 条

第 10 条甲及び乙は、各個別契約締結後すみやか

甲及び乙は、各個別契約締結後速やかに、に、本件業務を円滑に遂行するため、責任者の本件業務を円滑に遂行するため、責任者の下に下に連絡確認及び必要な調整を行う主任担当者

連絡確認及び必要な調整を行う担当者（以下「主を選任し、書面により、相手方に通知する。な

任担当者」という。）を選任し、書面により、

お、当該個別契約において双方の体制図を定め、相手方に通知する。なお、当該個別契約におい当該体制図に当該主任担当者を記載することをて双方の体制図を定め、当該体制図に当該主任もって通知に代えることができるものとする。

担当者を記載することをもって通知に代えることができるものとする。

2. 甲及び乙は、事前に書面により相手方に通知す

2. 甲及び乙は、事前に書面により相手方に通知することにより、主任担当者を変更できるものとることにより、主任担当者を変更できるものと

する。

する。

3. 甲及び乙は、本契約に定めた事項のほか、本件

3. 甲及び乙は、本契約に定めた事項のほか、本件業務遂行に関する相手方からの要請、指示等の業務遂行に関する相手方からの要請、指示等の受理及び相手方への依頼、その他日常的な相手受理及び相手方への依頼、その他日常的な相手方との連絡、確認等は原則として主任担当者を方との連絡、確認等は原則として主任担当者を通じて行うものとする。

通じて行うものとする。

4. 甲及び乙は主任担当者を複数名定める場合は、

4. 甲及び乙は、主任担当者を複数名定める場合

それぞれの権限範囲を明確にし、相手方に通知は、それぞれの権限範囲を明確にし、相手方にするものとする。

通知するものとする。

（業務従事者）（業務従事者）

第 11 条

第 11 条

本件業務に従事する乙の従業員（以下「業133

本件業務に従事する乙の従業員（以下「業務従事者」という。）の選定については、乙が務従事者」という。）の選定については、乙が

行う。

行う。

2. 乙は、労働法規その他関係法令に基づき業務従2. 乙は、労働法規その他関係法令に基づき業務従事者に対する雇用主としての一切の義務を負う事者に対する雇用主としての一切の義務を負うものとし、業務従事者に対する本件業務遂行にものとし、業務従事者に対する本件業務遂行に関する指示、労務管理、安全衛生管理等に関す関する指示、労務管理、安全衛生管理等に関する一切の指揮命令を行うものとする。

る一切の指揮命令を行うものとする。

3. 乙は、本件業務遂行上、業務従事者が甲の事務

3. 乙は、本件業務遂行上、業務従事者が甲の事務所等に立ち入る場合、甲の防犯、秩序維持等に所等に立ち入る場合、甲の防犯、秩序維持等、関する諸規則を当該業務従事者に遵守させるも甲の施設内立入りに関する諸規則を当該業務従のとする。

事者に遵守させるものとする。

（連絡協議会の設置）（連絡協議会の設置）

第 12 条

第 12 条甲及び乙は、本件業務が終了するまでの甲及び乙は、本件業務が終了するまでの間、その進捗状況、リスクの管理及び報告、甲間、その進捗状況、リスクの管理及び報告、甲乙双方による共同作業及び各自の分担作業の実乙双方による共同作業及び各自の分担作業の実

施状況、システム仕様書に盛り込むべき内容の施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議及び解決その他本件業務が確認、問題点の協議及び解決その他本件業務が円滑に遂行できるよう必要な事項を協議するた円滑に遂行できるよう必要な事項を協議するため、連絡協議会を開催するものとする。但し、め、協議会（以下「連絡協議会」という。）を本契約及び個別契約の内容の変更は第 33 条（本開催するものとする。但し、本契約及び個別契契約及び個別契約内容の変更）に従ってのみ行

約の内容の変更は第 33 条（本契約及び個別契約

うことができるものとする。

内容の変更）に従ってのみ行うことができるものとする。

2. 連絡協議会は、原則として、個別契約で定める

2. 連絡協議会は、原則として、個別契約で定める

頻度で定期的に開催するものとし、それに加え頻度で定期的に開催するものとし、それに加えて、甲又は乙が必要と認める場合に随時開催すて、甲又は乙が必要と認める場合に随時開催す

るものとする。

るものとする。

3. 連絡協議会には、甲乙双方の責任者、主任担当

3. 連絡協議会には、甲乙双方の責任者、主任担当者及び責任者が適当と認める者が出席する。ま

者及び責任者が適当と認める者が出席する。また、甲及び乙は、連絡協議会における協議に必た、甲及び乙は、連絡協議会における協議に必要となる者の出席を相手方に求めることがで要となる者の出席を相手方に求めることができ、相手方は合理的な理由がある場合を除き、き、相手方は合理的な理由がある場合を除き、これに応じるものとする。

これに応じるものとする。

4. 乙は、連絡協議会において、別途甲乙間にて取4. 乙は、連絡協議会において、別途甲乙間にて取り決めた様式による進捗管理報告を作成して提り決めた様式による進捗管理報告を作成して提出し、当該進捗管理報告に基づいて進捗状況を出し、当該進捗管理報告に基づいて進捗状況を確認するとともに、遅延事項の有無、遅延事項確認するとともに、遅延事項の有無、遅延事項があるときはその理由と対応策、本章で定めるがあるときはその理由と対応策、本章で定める推進体制の変更（人員の交代、増減、再委託先推進体制の変更（人員の交代、増減、再委託先の変更など）の要否、セキュリティ対策の履行の変更など）の要否、セキュリティ対策の履行

134

状況、個別契約の変更を必要とする事由の有無、状況、個別契約の変更を必要とする事由の有無、個別契約の変更を必要とする事由があるときは個別契約の変更を必要とする事由があるときはその内容などの事項を必要に応じて協議し、決その内容などの事項を必要に応じて協議し、決定された事項、継続検討とされた事項並びに継定された事項、継続検討とされた事項並びに継続検討事項がある場合は検討スケジュール及び続検討事項がある場合は検討スケジュール及び検討を行う当事者等を確認するものとする。

検討を行う当事者等を確認するものとする。

5. 甲及び乙は、本件業務の遂行に関し連絡協議会

5. 甲及び乙は、本件業務の遂行に関し連絡協議会

で決定された事項について、本契約及び個別契で決定された事項について、本契約及び個別契約に反しない限り、これに従わなければならな

約に反しない限り、これに従わなければならな

い。

い。

6. 乙は、連絡協議会の議事内容及び結果につい6. 乙は、連絡協議会の議事内容及び結果について、書面により議事録を作成し、これを甲に提て、書面により議事録を作成し、これを甲に提出し、その承認を得た後に、甲乙双方の責任者出し、その承認を得た後に、甲乙双方の責任者がこれに記名押印の上、それぞれ 1 部保有するがこれに記名押印の上、それぞれ 1 部保有するものとする。乙は、議事録の原案を原則としてものとする。乙は、議事録の原案を原則として連絡協議会の開催日から○日以内に作成して、連絡協議会の開催日から○日以内に作成して、これを甲に提出し、甲は、これを受領した日か

これを甲に提出し、甲は、これを受領した日から○日以内にその点検を行うこととし、当該期ら○日以内にその点検を行うこととし、当該期間内に書面により具体的な理由を明示して異議間内に書面により具体的な理由を明示して異議を述べない場合には、乙が作成した議事録を承を述べない場合には、乙が作成した議事録を承認したものとみなすものとする。

認したものとみなすものとする。但し、当該議事録の内容が、第 37 条（変更管理手続）に定
める変更管理書又は本契約若しくは個別契約の条件に影響を及ぼす場合は、同条の規定に基づく手続きを経た上で、変更が確定するものとす

7. 前項の議事録は、少なくとも当該連絡協議会にる。

おいて決定された事項、継続検討とされた事項

7. 前項の議事録は、少なくとも当該連絡協議会に並びに継続検討事項がある場合は検討スケ

おいて決定された事項、継続検討とされた事項

ジュール及び検討を行う当事者の記載を含むも並びに継続検討事項がある場合は検討スケのとする。

ジュール及び検討を行う当事者の記載を含むものとする。

（プロジェクトマネジメントの責任）（複数ベンダによる開発の場合の全体管理責任）

第 13 条

第 13 条甲が、本件ソフトウェアの開発等を全体甲が、本件ソフトウェアの開発等を全体のシステムの一部として乙に分割発注しておのシステムの一部として乙に分割発注しており、本件ソフトウェアと連携する他のソフト

り、本件ソフトウェアと連携する他のソフト

ウェアを第三者が開発している場合、当該他のウェアを第三者が開発している場合、当該他のソフトウェアと本件ソフトウェアの機能の整合

ソフトウェアと本件ソフトウェアの機能の整合性、開発スケジュールの調整並びに当該第三者性、開発スケジュールの調整並びに当該第三者と乙の開発進捗管理及び調整等のプロジェクトと乙の開発進捗管理及び調整等の全体管理に係

マネジメントに係る事項については、甲がそのる事項については、甲がその責任を負うものと135

責任を負うものとする。

する。

2. 甲が、前項のプロジェクトマネジメントを円滑

2. 甲が、前項の全体管理を円滑に遂行するために遂行するために、本件業務に関する範囲で乙に、本件業務に関する範囲で乙の協力を要請すの協力を要請する場合、必要となる条件を個別る場合、必要となる条件を個別契約で定めるも契約で定めるものとし、乙は個別契約に従い、のとし、乙は個別契約に従い、甲の全体管理に

甲のプロジェクトマネジメントに必要な協力を必要な協力を行うものとする。

行うものとする。
第3章
第1節

第3章

本件業務

第1節

要件定義作成支援業務（要件定義作成支援業務の実施）
第 14 条

本件業務要件定義作成支援業務（要件定義作成支援業務の実施）

乙は、第 15 条所定の個別契約を締結の上、 第 14 条

乙は、
第 15 条所定の個別契約を締結の上、本件業務として甲が作成した情報システム構想

本件業務として甲が作成した情報システム構想

書、システム化計画書等に基づいて、甲による書、システム化計画書等に基づいて、甲による要件定義書の作成作業を支援するサービス（以要件定義書の作成作業を支援するサービス（以下「要件定義作成支援業務」という。）を提供

下「要件定義作成支援業務」という。）を提供

する。

する。

2. 乙は、情報処理技術に関する専門的な知識及び

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行わ経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、れるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行分析、整理、提案及び助言などの支援業務を行うものとする。

うものとする。

（要件定義作成支援業務に係る個別契約の締結）（要件定義作成支援業務に係る個別契約の締結）

第 15 条

第 15 条甲及び乙は、要件定義作成支援業務につ

甲及び乙は、要件定義作成支援業務について、第 4 条第 1 項記載の取引条件を協議の上いて、第 4 条第 1 項に定める取引条件を協議の決定し、要件定義作成支援業務に係る個別契約

上決定し、要件定義作成支援業務に係る個別契を締結する。

約を締結する。

（要件定義検討会）（要件定義検討会）

第 16 条

第 16 条

甲は、要件定義書作成のために必要とな

甲は、要件定義書作成のために必要となる事項の明確化又は内容の確認等を行うため、る事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、要件定義書作成につ必要と認められる頻度で、要件定義書作成についての第 12 条所定の連絡協議会（以下本節においての第 12 条所定の連絡協議会（以下本節において「要件定義検討会」という。）を開催し、いて「要件定義検討会」という。）を開催し、乙は、これに参加して要件定義作成支援業務を

乙は、これに参加して要件定義作成支援業務を実施するものとする。

実施するものとする。

2. 乙も、要件定義作成支援業務の実施のために必2. 乙も、要件定義作成支援業務の実施のために必要と認めるときは、要件定義検討会を開催する

要と認めるときは、要件定義検討会を開催することができるものとし、甲は、これに参加することができるものとし、甲は、これに参加するものとする。

ものとする。

（要件定義書の確定）（要件定義書の確定）

第 17 条

第 17 条

甲が要件定義書の作成を完了した場合、

136

甲が要件定義書の作成を完了した場合、

甲及び乙は、個別契約において定める期間（以甲及び乙は、個別契約において定める期間（以下「要件定義書の点検期間」という。）内に要下「要件定義書の点検期間」という。）内に要件定義書が前条所定の要件定義検討会での決定

件定義書が前条所定の要件定義検討会での決定事項に適合するか点検を行うものとし、適合す事項に適合するか点検を行うものとし、適合することを確認した証として甲乙双方の責任者がることを確認した証として甲乙双方の責任者が要件定義書に記名押印するものとする。但し、要件定義書に記名押印するものとする。但し、点検の結果、要件定義書が要件定義検討会での点検の結果、要件定義書が要件定義検討会での決定事項に適合しないと判断された場合、甲は、決定事項に適合しないと判断された場合、甲は、協議の上定めた期限内に修正版を作成し、甲及協議の上定めた期限内に修正版を作成し、甲及び乙は再度上記の点検、確認手続を行うものとび乙は再度上記の点検、確認手続を行うものと

する。

する。

2. 前項による甲乙双方の確認をもって、要件定義

2. 前項による甲乙双方の確認をもって、要件定義書は確定したものとする。

書は確定したものとする。

3. 第 1 項の修正に伴い作業期間、委託料等個別契3. 第 1 項の修正に伴い作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33

約の条件を変更する必要が生じる場合は、第 33条（本契約及び個別契約内容の変更）の手続に条（本契約及び個別契約内容の変更）の手続によるものとする。

よるものとする。

（業務の終了・確認）（業務の終了・確認）

第 18 条第 18 条乙は、前条に定める要件定義書の確定又乙は、前条に定める要件定義書の確定又は個別契約に定める作業期間の満了若しくは個は個別契約に定める作業期間の満了若しくは個別契約に定める作業工数（作業量）分の作業実

別契約に定める作業工数（作業量）分の作業実施完了のいずれか最も早く到来した時から○日

施完了のいずれか最も早く到来した時から○日以内に、業務終了報告書を作成し、甲に提出す以内に、業務終了報告書を作成し、甲に提出する。

る。

2. 甲は、個別契約に定める期間（以下「要件定義2. 甲は、個別契約に定める期間（以下「要件定義作成支援業務終了の確認期間」という。）内に、作成支援業務終了の確認期間」という。）内に、

当該業務終了報告書の確認を行うものとする。

当該業務終了報告書の確認を行うものとする。

3. 甲は、当該業務終了報告書の内容に疑義がない

3. 甲は、当該業務終了報告書の内容に疑義がない

場合、業務終了確認書に記名押印の上、乙に交場合、業務終了確認書に記名押印の上、乙に交付し、要件定義作成支援業務の終了を確認する

付し、要件定義作成支援業務の終了を確認する

ものとする。

ものとする。

4. 要件定義作成支援業務終了の確認期間内に、甲4. 要件定義作成支援業務終了の確認期間内に、甲が書面で具体的な理由を明示して異議を述べなが書面で具体的な理由を明示して異議を述べない場合には、甲は要件定義作成支援業務終了のい場合には、甲は要件定義作成支援業務終了の確認期間の満了をもって、業務の終了を確認し確認期間の満了をもって、業務の終了を確認したものとみなされる。

たものとみなされる。

5. 前条に基づく要件定義書の確定前に要件定義

5．前条に基づく要件定義書の確定前に要件定義作成支援業務が終了する場合で、甲が当該確定

作成支援業務が終了する場合で、甲が当該確定のためになお要件定義作成支援業務が必要とすのためになお要件定義作成支援業務が必要とするときは、甲及び乙は第 33 条に従い、追加の要るときは、甲及び乙は第 33 条に従い、追加の要137

件定義作成支援業務に関して変更契約又は追加

件定義作成支援業務に関して変更契約又は追加契約を締結するものとする。

契約を締結するものとする。

第2節

第2節

外部設計書作成（支援）業務

外部設計書作成（支援）業務

【A 案】

【A 案】

（外部設計書作成支援業務の実施）（外部設計書作成支援業務の実施）

第 19 条乙は、第 20 条所定の個別契約を締結の上、 第 19 条

乙は、
第 20 条所定の個別契約を締結の上、本件業務として甲による外部設計書作成作業を本件業務として甲による外部設計書作成作業を支援するサービス（以下「外部設計書作成支援

支援するサービス（以下「外部設計書作成支援業務」という。）を提供する。

業務」という。）を提供する。

2. 乙は、情報処理技術に関する専門的な知識及び

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適切に行わ経験に基づき、甲の作業が円滑かつ適切に行われるよう、善良な管理者の注意をもって調査、れるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行分析、整理、提案及び助言などの支援業務を行うものとする。

うものとする。

【A 案】

【A 案】

（外部設計書作成支援業務に係る個別契約の締結） （外部設計書作成支援業務に係る個別契約の締結）
第 20 条

第 20 条甲及び乙は、外部設計書作成支援業務に

甲及び乙は、外部設計書作成支援業務について、第 4 条第 1 項記載の取引条件を協議のついて、第 4 条第 1 項に定める取引条件を協議上決定し、外部設計書作成支援業務に係る個別の上決定し、外部設計書作成支援業務に係る個契約を締結する。

別契約を締結する。

【A 案】

【A 案】

（外部設計検討会）（外部設計検討会）

第 21 条

第 21 条甲は、外部設計書作成のために必要とな甲は、外部設計書作成のために必要となる事項の明確化又は内容の確認等を行うため、る事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、外部設計書作成につ必要と認められる頻度で、外部設計書作成について第 12 条所定の連絡協議会（以下本節においいて第 12 条所定の連絡協議会（以下本節において「外部設計検討会」という。）を開催し、乙て「外部設計検討会」という。）を開催し、乙は、これに参加して外部設計書作成支援業務をは、これに参加して外部設計書作成支援業務を実施するものとする。

実施するものとする。

2. 乙も、外部設計書作成支援業務の実施のために

2. 乙も、外部設計書作成支援業務の実施のために必要と認めるときは、外部設計検討会を開催す

必要と認めるときは、外部設計検討会を開催することができるものとし、甲は、これに参加することができるものとし、甲は、これに参加す

るものとする。

るものとする。

3. 外部設計検討会における検討等により、甲が要

3. 外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合におい件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更て、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33 条（本契約及びする必要が生じる場合は、第 33 条（本契約及び個別契約内容の変更）の手続によるものとする。

個別契約内容の変更）の手続によるものとする。

【A 案】

【A 案】

（外部設計書の確定）（外部設計書の確定）

138

第 22 条

第 22 条甲が外部設計書の作成を完了した場合、甲が外部設計書の作成を完了した場合、甲及び乙は、個別契約において定める期間（以甲及び乙は、個別契約において定める期間（以下「外部設計書の点検期間」という。）内に外

下「外部設計書の点検期間」という。）内に外部設計書が、第 17 条の規定により確定された要部設計書が、第 17 条の規定により確定された要件定義書及び前条所定の外部設計検討会での決件定義書及び前条所定の外部設計検討会での決定事項に適合するか点検を行うものとし、適合定事項に適合するか点検を行うものとし、適合することを確認した証として甲乙双方の責任者することを確認した証として甲乙双方の責任者が外部設計書に記名押印するものとする。但し、が外部設計書に記名押印するものとする。但し、点検の結果、外部設計書が、第 17 条の規定によ

点検の結果、外部設計書が、第 17 条の規定により確定された要件定義書及び外部設計検討会でり確定された要件定義書及び外部設計検討会での決定事項に適合しない部分が発見された場の決定事項に適合しない部分が発見された場

合、甲は、協議の上定めた期限内に修正版を作

合、甲は、協議の上定めた期限内に修正版を作成し、甲及び乙は再度上記点検、確認手続を行成し、甲及び乙は再度上記点検、確認手続を行うものとする。

うものとする。

2. 前項による甲乙双方の確認をもって、外部設計

2. 前項による甲乙双方の確認をもって、外部設計書は確定したものとする。

書は確定したものとする。

3. 第 1 項の修正に伴い作業期間、委託料等個別契3. 第 1 項の修正に伴い作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33

約の条件を変更する必要が生じる場合は、第 33条（本契約及び個別契約内容の変更）の手続に条（本契約及び個別契約内容の変更）の手続によるものとする。

よるものとする。

【A 案】

【A 案】

（業務の終了・確認）（業務の終了・確認）

第 23 条

第 23 条乙は、前条に定める外部設計書の確定又乙は、前条に定める外部設計書の確定又は個別契約に定める作業期間の満了若しくは個は個別契約に定める作業期間の満了若しくは個別契約に定める作業工数（作業量）分の作業実

別契約に定める作業工数（作業量）分の作業実施完了のいずれか最も早く到来した時から○日

施完了のいずれか最も早く到来した時から○日以内に、業務終了報告書を作成し、甲に提出す以内に、業務終了報告書を作成し、甲に提出する。

る。

2. 甲は、個別契約に定める期間（以下「外部設計2. 甲は、個別契約に定める期間（以下「外部設計書作成支援業務終了の確認期間」という。）内

書作成支援業務終了の確認期間」という。）内に、当該業務終了報告書の確認を行うものとすに、当該業務終了報告書の確認を行うものとする。

る。

3. 甲は、当該業務終了報告書の内容に疑義がない

3. 甲は、当該業務終了報告書の内容に疑義がない

場合、業務終了確認書に記名押印の上、乙に交場合、業務終了確認書に記名押印の上、乙に交付し、外部設計書作成支援業務の終了を確認す

付し、外部設計書作成支援業務の終了を確認す

るものとする。

るものとする。

4. 外部設計書作成支援業務終了の確認期間内に、

4. 外部設計書作成支援業務終了の確認期間内に、甲が書面で具体的な理由を明示して異議を述べ甲が書面で具体的な理由を明示して異議を述べない場合には、甲は外部設計書作成支援業務終ない場合には、甲は外部設計書作成支援業務終了の確認期間の満了をもって、業務の終了を確了の確認期間の満了をもって、業務の終了を確139

認したものとみなされる。

認したものとみなされる。

5. 前条に基づく外部設計書の確定前に外部設計

5． 前条に基づく外部設計書の確定前に外部設計

書作成支援業務が終了する場合で、甲が当該確書作成支援業務が終了する場合で、甲が当該確定のためになお外部設計書作成支援業務が必要

定のためになお外部設計書作成支援業務が必要とするときは、甲及び乙は第 33 条に従い、追加とするときは、甲及び乙は第 33 条に従い、追加の外部設計書作成支援業務に関して変更契約又の外部設計書作成支援業務に関して変更契約又は追加契約を締結するものとする。

は追加契約を締結するものとする。

【B 案】

【B 案】

（外部設計書作成業務の実施）（外部設計書作成業務の実施）

第〇条

第〇条

乙は、第○条所定の個別契約を締結の上、乙は、第○条所定の個別契約を締結の上、本件業務として第 17 条の規定により確定され本件業務として第 17 条の規定により確定された要件定義書に基づき、本件ソフトウェアの外た要件定義書に基づき、本件ソフトウェアの外部設計書作成業務を行う。

部設計書作成業務を行う。

2. 外部設計書作成業務の実施に際し、乙は甲に対

2. 外部設計書作成業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は乙して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には適時に、これにから協力を要請された場合には、適時にこれに応ずるものとする。

応ずるものとする。

【B 案】

【B 案】

（外部設計書作成業務に係る個別契約の締結）（外部設計書作成業務に係る個別契約の締結）

第〇条

第〇条

甲及び乙は、外部設計書作成業務につい甲及び乙は、外部設計書作成業務について、第 4 条第 1 項記載の取引条件を協議の上決て、第 4 条第 1 項に定める取引条件を協議の上定し、外部設計書作成業務に係る個別契約を締決定し、外部設計書作成業務に係る個別契約を

結する。

締結する。

【B 案】

【B 案】

（外部設計検討会）（外部設計検討会）

第〇条

第〇条

乙は、外部設計書作成のために必要となる

乙は、外部設計書作成のために必要となる事項の明確化又は内容の確認等を行うため、必事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、外部設計書作成につい要と認められる頻度で、外部設計書作成について第 12 条所定の連絡協議会（以下本節においてて第 12 条所定の連絡協議会（以下本節において「外部設計検討会」という。）を開催し、甲は「外部設計検討会」という。）を開催し、甲はこれに参加するものとする。

これに参加するものとする。

2. 甲も、外部設計書作成のために必要と認めると

2. 甲も、外部設計書作成のために必要と認めるときは、甲が外部設計検討会を開催することができは、甲が外部設計検討会を開催することができるものとし、乙はこれに参加するものとする。

きるものとし、乙はこれに参加するものとする。

3. 外部設計検討会における検討等により、甲が要

3. 外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場合におい件定義書の内容を変更しようとする場合において、作業期間、委託料等個別契約の条件を変更て、作業期間、委託料等個別契約の条件を変更する必要が生じる場合は、第 33 条（本契約及びする必要が生じる場合は、第 33 条（本契約及び個別契約内容の変更）の手続によるものとする。

個別契約内容の変更）の手続によるものとする。

【B 案】

【B 案】

140

（外部設計書の納入）（外部設計書の納入）

第〇条

第〇条

乙は個別契約に定める期日までに、外部設

乙は個別契約に定める期日までに、外部設計書を外部設計書検収依頼書（兼納品書）とと計書を外部設計書検収依頼書（兼納品書）とともに甲に納入する。

もに甲に納入する。

【B 案】

【B 案】

（外部設計書の承認及び確定）（外部設計書の承認及び確定）

第〇条

第〇条

甲は、個別契約において定める期間（以下甲は、個別契約において定める期間（以下「外部設計書の点検期間」という。）内に外部「外部設計書の点検期間」という。）内に外部

設計書が、第 17 条の規定により確定された要件設計書が、第 17 条の規定により確定された要件

定義書並びに第○条所定の外部設計検討会での定義書並びに第○条所定の外部設計検討会での決定事項に適合するか、及び論理的誤りがない

決定事項に適合するか、及び論理的誤りがない

か点検を行うものとし、適合すること及び論理か点検を行うものとし、適合すること及び論理的な誤りがないことを承認した証として甲乙双的な誤りがないことを承認した証として甲乙双方の責任者が外部設計書承認書に記名押印する方の責ものとする。但し、点検の結果、外部設計書が、るものとする。但し、点検の結果、外部設計書

第 17 条の規定により確定された要件定義書及が、第 17 条の規定により確定された要件定義書

び外部設計検討会での決定事項に適合しない部

及び外部設計検討会での決定事項に適合しない

分又は論理的誤りが発見された場合、乙は、協部分又は論理的誤りが発見された場合、乙は、議の上定めた期限内に修正版を作成して甲に提協議の上定めた期限内に修正版を作成して甲に示し、甲は再度上記点検、承認手続を行うもの

提示し、甲は再度上記点検、承認手続を行うも

とする。

のとする。

任者が外部設計書承認書に記名押印す

2. 外部設計書の点検期間内に甲が書面で具体的

2. 外部設計書の点検期間内に甲が書面で具体的な理由を明示して異議を述べない場合には、甲な理由を明示して異議を述べない場合には、甲は外部設計書の点検期間の満了をもって、外部は外部設計書の点検期間の満了をもって、外部設計書を承認したものとみなされる。

設計書を承認したものとみなされる。

3. 前 2 項による甲の承認をもって、外部設計書は

3. 前二項による甲の承認をもって、外部設計書は確定したものとする。

確定したものとする。

【B 案】

【B 案】

（瑕疵担保責任）（契約不適合責任）

第〇条

第〇条

前条の確定後、外部設計書について要件定

前条の確定後、外部設計書について要件定

義書及び第○条所定の外部設計検討会での決定

義書及び第○条所定の外部設計検討会での決定事項との不一致又は論理的誤り（以下本条にお事項との不一致又は論理的誤り（以下「契約不いて「瑕疵」という。）が発見された場合、甲適合」という。）が発見された場合、甲は乙には乙に対して当該瑕疵の修正を請求することが対して当該契約不適合の修正を請求することができ、乙は、当該瑕疵を修正するものとする。

でき、乙は、当該契約不適合を修正するものと

但し、乙がかかる修正責任を負うのは、前条のする。但し、乙がかかる修正責任を負うのは、確定後○ヶ月以内に甲から請求がなされた場合

乙が契約不適合を重大な過失によって知らなに限るものとする。

かった場合であっても、前条の確定後○ヶ月以内に甲から契約不適合がある旨の通知がなされた場合に限るものとする。

141

2. 前項にかかわらず、瑕疵が軽微であって、外部

2. 前項にかかわらず、外部設計書の修正に過分の設計書の修正に過分の費用を要する場合、乙は費用を要する場合、乙は前項所定の修正責任を

前項所定の修正責任を負わないものとする。

負わないものとする。

3. 第 1 項の規定は、瑕疵が甲の提供した資料等又3. 第 1 項の規定は、契約不適合が甲の提供した資は甲の与えた指示によって生じたときは適用し料等又は甲の与えた指示等乙の責に帰さない事ない。但し、乙がその資料等又は指示が不適当

由によって生じたときは適用しない。但し、乙であることを知りながら告げなかったときはこがその資料等又は指示が不適当であることを知の限りでない。

りながら告げなかったときはこの限りでない。
4．外部設計書作成に関する契約不適合に関する乙の責任は、本条及び第 53 条（損害賠償）にて明示的に規定された責任内容がすべてである
ものとする。

第3節

第3節

ソフトウェア開発業務

ソフトウェア開発業務【A 案システムテストを準委任型で行う場合】【A 案システムテストを準委任型で行う場合】（ソフトウェア開発業務の実施）（ソフトウェア開発業務の実施）

第 24 条

乙は、第 25 条所定の個別契約を締結の上、 第 24 条

乙は、
第 25 条所定の個別契約を締結の上、本件業務として前各節により確定したシステム

本件業務として前各節により確定したシステム

仕様書に基づき、内部設計からシステム結合ま仕様書に基づき、内部設計からシステム結合までのソフトウェア開発業務を行う。

でのソフトウェア開発業務を行う。

2. ソフトウェア開発業務の実施に際し、乙は甲に

2. ソフトウェア開発業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には適時に、これ乙から協力を要請された場合には、適時にこれに応ずるものとする。

に応ずるものとする。

【B 案システムテストを請負型で行う場合】【B 案システムテストを請負型で行う場合】（ソフトウェア開発業務の実施）（ソフトウェア開発業務の実施）

第 24 条

乙は、第 25 条所定の個別契約を締結の上、 第 24 条

乙は、
第 25 条所定の個別契約を締結の上、本件業務として前各節により確定したシステム

本件業務として前各節により確定したシステム

仕様書に基づき、内部設計からシステムテスト

仕様書に基づき、内部設計からシステムテスト

までのソフトウェア開発業務を行う。

までのソフトウェア開発業務を行う。

2. ソフトウェア開発業務の実施に際し、乙は甲に

2. ソフトウェア開発業務の実施に際し、乙は甲に対して必要な協力を要請できるものとし、甲は対して必要な協力を要請できるものとし、甲は乙から協力を要請された場合には適時に、これ乙から協力を要請された場合には、適時にこれに応ずるものとする。

に応ずるものとする。

（ソフトウェア開発業務に係る個別契約の締結）（ソフトウェア開発業務に係る個別契約の締結）

第 25 条

第 25 条甲及び乙は、当該ソフトウェア開発業務

甲及び乙は、当該ソフトウェア開発業務について、第 4 条第 1 項記載の取引条件を協議について、第 4 条第 1 項に定める取引条件を協の上決定し、ソフトウェア開発業務に係る個別議の上決定し、ソフトウェア開発業務に係る個契約を締結する。

別契約を締結する。

（納入物の納入）（納入物の納入）

第 26 条

第 26 条乙は甲に対し、個別契約で定める期日ま142

乙は甲に対し、個別契約で定める期日までに、個別契約所定の納入物を検収依頼書（兼でに、個別契約所定の納入物を検収依頼書（兼納品書）とともに納入する。

納品書）とともに納入する。

2. 甲は、納入があった場合、次条の検査仕様書に

2. 甲は、納入があった場合、次条の検査仕様書に基づき、第 28 条（本件ソフトウェアの検収）の基づき、第 28 条（本件ソフトウェアの検収）の定めに従い検査を行う。

定めに従い検査を行う。

3. 乙は、納入物の納入に際し、甲に対して必要な

3. 乙は、納入物の納入に際し、甲に対して必要な協力を要請できるものとし、甲は乙から協力を協力を要請できるものとし、甲は乙から協力を要請された場合には、すみやかにこれに応じる要請された場合には、速やかにこれに応じるもものとする。

のとする。

4. 納入物の滅失、毀損等の危険負担は、納入前に4. 納入物の滅失、毀損等の危険負担は、納入前については乙が、納入後については甲が、それぞ

ついては乙が、納入後については甲が、それぞれこれを負担するものとする。

れこれを負担するものとする。

（検査仕様書の作成及び承認）（検査仕様書の作成及び承認）

第 27 条

第 27 条甲は、乙と協議の上、システム仕様書に

甲は、乙と協議の上、システム仕様書に基づき前条の納入物のうち本件ソフトウェアの基づき前条の納入物のうち本件ソフトウェアの検査の基準となるテスト項目、テストデータ、検査の基準となるテスト項目、テストデータ、

テスト方法及びテスト期間等を定めた検査仕様

テスト方法及びテスト期間等を定めた検査仕様書を作成し、乙に提出するものとし、乙の責任書を作成し、乙に提出するものとし、乙の責任者はシステム仕様書に適合するかの点検を行者はシステム仕様書に適合するかの点検を行い、適合することを承認する場合、検査仕様書

い、適合することを承認する場合、検査仕様書に記名押印の上、甲に交付して承認するものとに記名押印の上、甲に交付して承認するものとする。但し、点検の結果、検査仕様書にシステする。但し、点検の結果、検査仕様書にシステ

ム仕様書に適合しない部分が発見された場合、ム仕様書に適合しない部分が発見された場合、甲は、協議の上定めた期限内に修正版を作成し甲は、協議の上定めた期限内に修正版を作成して乙に提示するものとし、乙は再度上記点検、て乙に提示するものとし、乙は再度上記点検、承認手続を行うものとする。

承認手続を行うものとする。

2. 乙の責任者は、個別契約で定める期間（以下「検2. 乙の責任者は、個別契約で定める期間（以下「検査仕様書点検期間」という。）内に検査仕様書

査仕様書点検期間」という。）内に検査仕様書の点検を終えるものとし、乙の責任者が、検査の点検を終えるものとし、乙の責任者が、検査

仕様書点検期間内に書面による具体的な理由を仕様書点検期間内に書面による具体的な理由を明示した異議の申出をすることなく検査仕様書

明示した異議の申出をすることなく検査仕様書を承認しない場合、当該期間の満了をもって検を承認しない場合、当該期間の満了をもって検査仕様書は承認されたものとする。

査仕様書は承認されたものとする。

3. 甲は、甲が行う検査仕様書の作成についての支3. 甲は、甲が行う検査仕様書の作成についての支援（以下「検査仕様書作成支援業務」という。）

援（以下「検査仕様書作成支援業務」という。）

を乙に委託する必要がある場合、第 25 条に定めを乙に委託する必要がある場合、第 25 条に定めるソフトウェア開発業務に関する個別契約を締るソフトウェア開発業務に関する個別契約を締結するときまでに、乙に検査仕様書作成支援業

結するときまでに、乙に検査仕様書作成支援業

務の委託に関する申し込みを乙に行い、検査仕務の委託に関する申し込みを乙に行い、検査仕様書作成支援業務に関する個別契約を別途締結

様書作成支援業務に関する個別契約を別途締結

143

することができる。

することができる。

4. 乙による検査仕様書作成支援業務については、

4. 乙による検査仕様書作成支援業務については、

外部設計書作成支援業務に関する第 3 章第 2 節

外部設計書作成支援業務に関する第 3 章第 2 節の規定を準用するものとする。但し、「外部設の規定を準用するものとする。但し、「外部設計書」を「検査仕様書」に、「外部設計検討会」

計書」を「検査仕様書」に、「外部設計検討会」

を「連絡協議会」に、「要件定義書及び外部設

を「連絡協議会」に、「要件定義書及び外部設計検討会での決定事項」を「システム仕様書」

計検討会での決定事項」を「システム仕様書」に読み替える。

に読み替える。

（本件ソフトウェアの検収）（本件ソフトウェアの検収）第 28 条

第 28 条納入物のうち本件ソフトウェアについて納入物のうち本件ソフトウェアについて

は、甲は、個別契約に定める期間（以下、「検は、甲は、個別契約に定める期間（以下「検査査期間」という。）内に前条の検査仕様書に基期間」という。）内に前条の検査仕様書に基づづき検査し、システム仕様書と本件ソフトウェ

き検査し、システム仕様書と本件ソフトウェア

アが合致するか否かを点検しなければならなが合致するか否かを点検しなければならない。

い。
2. 甲は、本件ソフトウェアが前項の検査に適合す

2. 甲は、本件ソフトウェアが前項の検査に適合す

る場合、検査合格書に記名押印の上、乙に交付る場合、検査合格書に記名押印の上、乙に交付するものとする。また、甲は、本件ソフトウェするものとする。また、甲は、本件ソフトウェ

アが前項の検査に合格しない場合、乙に対し不アが前項の検査に合格しない場合、乙に対し不合格となった具体的な理由を明示した書面を速合格となった具体的な理由を明示した書面を速やかに交付し、修正又は追完を求めるものとし、やかに交付し、修正又は追完を求めるものとし、不合格理由が認められるときには、乙は、協議不合格理由が認められるときには、乙は、協議の上定めた期限内に無償で修正して甲に納入の上定めた期限内に無償で修正して甲に納入し、甲は必要となる範囲で、前項所定の検査をし、甲は必要となる範囲で、前項所定の検査を再度行うものとする。

再度行うものとする。

3. 検査合格書が交付されない場合であっても、検3. 検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を明示して査期間内に甲が書面で具体的な理由を明示して異議を述べない場合は、本件ソフトウェアは、異議を述べない場合は、本件ソフトウェアは、

本条所定の検査に合格したものとみなされる。

本条所定の検査に合格したものとみなされる。

4. 本条所定の検査合格をもって、本件ソフトウェ

4. 本条所定の検査合格をもって、本件ソフトウェ

アの検収完了とする。

アの検収完了とする。

（瑕疵担保責任）（契約不適合責任）第 29 条

第 29 条

前条の検査完了後、納入物についてシス

前条の検収完了後、納入物についてシス

テム仕様書との不一致（以下本条において「瑕

テム仕様書との不一致（以下「契約不適合」と疵」という。）が発見された場合、甲は乙に対いう。）が発見された場合、甲は乙に対して当して当該瑕疵の修正を請求することができ、乙該契約不適合の修正を請求することができ、乙は、当該瑕疵を修正するものとする。但し、乙は、当該契約不適合を修正するものとする。但がかかる修正責任を負うのは、前条の検収完了

し、乙がかかる修正責任を負うのは、乙が契約

後○ヶ月以内に甲から請求された場合に限るも不適合を重大な過失によって知らなかった場合のとする。

であっても、前条の検収完了後○ヶ月以内に甲144から契約不適合がある旨の通知がなされた場合に限るものとする。
2. 前項にかかわらず、瑕疵が軽微であって、納入

2. 前項にかかわらず、納入物の修正に過分の費用

物の修正に過分の費用を要する場合、乙は前項を要する場合、乙は前項所定の修正責任を負わ

所定の修正責任を負わないものとする。

ないものとする。

3. 第 1 項の規定は、瑕疵が甲の提供した資料等又3. 第 1 項の規定は、契約不適合が甲の提供した資は甲の与えた指示等乙の責に帰さない事由に料等又は甲の与えた指示等乙の責に帰さない事

よって生じたときは適用しない。但し、乙がそ由によって生じたときは適用しない。但し、乙の資料等又は指示が不適当であることを知りながその資料等又は指示等が不適当であることをがら告げなかったときはこの限りでない。

知りながら告げなかったときはこの限りでない。
4. 契約不適合に関する乙の責任は、本条及び第53 条（損害賠償）にて明示的に規定された責任
内容がすべてであるものとする。

第4節

第4節

ソフトウェア運用準備・移行支援業務

ソフトウェア運用準備・移行支援業務【A 案システムテストを準委任型で行う場合】【A 案システムテストを準委任型で行う場合】（ソフトウェア運用準備・移行支援業務の実施）（ソフトウェア運用準備・移行支援業務の実施）

第 30 条乙は、第 31 条所定の個別契約を締結の上、 第 30 条

乙は、
第 31 条所定の個別契約を締結の上、本件業務として甲が行うシステムテスト、導本件業務として甲が行うシステムテスト、導入・受入支援及び本件ソフトウェアを現実に運入・受入支援及び本件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲の用するために行う運用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準ために必要な支援（以下「ソフトウェア運用準備･移行支援業務」という。）を行う。

備･移行支援業務」という。）を行う。

2. 乙は、情報処理技術に関する専門的な知識及び

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効果的に行

経験に基づき、甲の作業が円滑かつ効果的に行

われるよう、善良な管理者の注意をもって支援

われるよう、善良な管理者の注意をもって支援業務を行うものとする。

業務を行うものとする。

【B 案システムテストを請負型で行う場合】【B 案システムテストを請負型で行う場合】（ソフトウェア運用準備・移行支援業務の実施）（ソフトウェア運用準備・移行支援業務の実施）

第 30 条乙は、第 31 条所定の個別契約を締結の上、 第 30 条

乙は、
第 31 条所定の個別契約を締結の上、本件業務として甲が行う導入・受入支援及び本本件業務として甲が行う導入・受入支援及び本件ソフトウェアを現実に運用するために行う運件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲のために必要な支援（以用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準備･移行支援業務」とい下「ソフトウェア運用準備･移行支援業務」という。）を行う。

う。）を行う。

2. 乙は、情報処理技術に関する専門的な知識及び

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効果的に行

経験に基づき、甲の作業が円滑かつ効果的に行

われるよう、善良な管理者の注意をもって支援

われるよう、善良な管理者の注意をもって支援業務を行うものとする。

業務を行うものとする。

（ソフトウェア運用準備・移行支援業務に係る個別（ソフトウェア運用準備・移行支援業務に係る個別

145

契約の締結）第 31 条契約の締結）

甲及び乙は、当該ソフトウェア運用準備・ 第 31 条

甲及び乙は、当該ソフトウェア運用準備・移行支援業務について、第 4 条第 1 項記載の取移行支援業務について、第 4 条第 1 項に定める引条件を協議の上決定し、ソフトウェア運用準

取引条件を協議の上決定し、ソフトウェア運用

備・移行支援業務に係る個別契約を締結する。

準備・移行支援業務に係る個別契約を締結する。

（業務の終了・確認）（業務の終了・確認）

第 32 条

第 32 条乙は、ソフトウェア運用準備・移行支援

乙は、ソフトウェア運用準備・移行支援

業務の終了又は個別契約に定める作業期間の満業務の終了又は個別契約に定める作業期間の満了若しくは作業工数（作業量）分の作業実施完了若しくは作業工数（作業量）分の作業実施完了のいずれか最も早く到来した時から○日以内

了のいずれか最も早く到来した時から○日以内に、業務終了報告書を作成し、甲に提出する。

に、業務終了報告書を作成し、甲に提出する。

2. 甲は、個別契約に定める期間（以下「ソフトウェ

2. 甲は、個別契約に定める期間（以下「ソフトウェ

ア運用準備・移行支援業務終了の確認期間」とア運用準備・移行支援業務終了の確認期間」という。）内に、当該業務終了報告書の確認を行いう。）内に、当該業務終了報告書の確認を行うものとする。

うものとする。

3. 甲は、当該業務終了報告書の内容に疑義がない

3. 甲は、当該業務終了報告書の内容に疑義がない

場合、業務終了確認書に記名押印の上、乙に交場合、業務終了確認書に記名押印の上、乙に交付し、ソフトウェア運用準備・移行支援業務の付し、ソフトウェア運用準備・移行支援業務の終了を確認するものとする。

終了を確認するものとする。

4. ソフトウェア運用準備・移行支援業務終了の確

4. ソフトウェア運用準備・移行支援業務終了の確

認期間内に甲が書面で具体的な理由を明示して認期間内に甲が書面で具体的な理由を明示して異議を述べない場合には、ソフトウェア運用準

異議を述べない場合には、ソフトウェア運用準備・移行支援業務終了の確認期間の満了をもっ備・移行支援業務終了の確認期間の満了をもって、業務の終了を確認したものとみなされる。

て、業務の終了を確認したものとみなされる。

5. 個別契約に定める作業期間の満了又は作業工

5.

個別契約に定める作業期間の満了又は作業工数（作業量）分の作業実施終了後も、甲が引き数（作業量）分の作業実施終了後も、甲が引き続き当該支援業務を必要とするときは、甲及び続き当該支援業務を必要とするときは、甲及び乙は第 33 条に従い、追加のソフトウェア運用準乙は第 33 条に従い、追加のソフトウェア運用準備・移行支援業務に関して変更契約又は追加契

備・移行支援業務に関して変更契約又は追加契約を締結するものとする。

約を締結するものとする。

第４章

契約内容等の変更

第４章

契約内容等の変更（本契約及び個別契約内容の変更）（本契約及び個別契約内容の変更）

第 33 条

第 33 条

本契約及び個別契約の内容の変更は、当本契約及び個別契約の内容の変更は、当該変更内容につき事前に甲乙協議の上、別途、該変更内容につき事前に甲乙協議の上、別途、書面により変更契約を締結することによっての書面により変更契約を締結することによってのみこれを行うことができる。

みこれを行うことができる。

（システム仕様書等の変更）（システム仕様書等の変更）

第 34 条

第 34 条甲又は乙は、システム仕様書、検査仕様

甲又は乙は、システム仕様書、検査仕様書、第 35 条により甲に承認された中間資料（以書、第 35 条により甲に承認された中間資料（以下総称して「仕様書等」という。）の内容につ下総称して「仕様書等」という。）の内容につ146

いての変更が必要と認める場合、その変更の内

いての変更が必要と認める場合、その変更の内

容、理由等を明記した書面（以下「変更提案書」

容、理由等を明記した書面（以下「変更提案書」という。）を相手方に交付して、変更の提案をという。）を相手方に交付して、変更の提案を行うことができる。

行うことができる。

2. 仕様書等の内容の変更は、第 37 条（変更管理

2. 仕様書等の内容の変更は、第 37 条（変更管理手続）によってのみこれを行うことができるも手続）によってのみこれを行うことができるも

のとする。

のとする。

（中間資料のユーザによる承認）（中間資料のユーザによる承認）

第 35 条

第 35 条乙は、中間資料のうち、乙が必要と認め乙は、中間資料のうち、乙が必要と認める部分を提示して、甲の承認を書面で求めるこる部分を提示して、甲の承認を書面で求めることができる。

とができる。

2. 甲は、前項の承認請求を乙から受けた日から○

2. 甲は、前項の承認請求を乙から受けた日から○日以内（以下「中間資料の点検期間」という。）

日以内（以下「中間資料の点検期間」という。）に、内容を承認するか点検を行い、その結果をに、内容を承認するか点検を行い、その結果を書面に記名押印の上、乙に交付するものとする。

書面に記名押印の上、乙に交付するものとする。

3. 甲は、中間資料の内容に不都合が認められる場

3. 甲は、中間資料の内容に不都合が認められる場

合、又は次条で定める未確定事項の内容と関連

合、又は次条で定める未確定事項の内容と関連性を有するため、当該時点では判断できない場性を有するため、当該時点では判断できない場

合、その他これらに準ずる合理的な理由がある

合、その他これらに準ずる合理的な理由がある

場合は、その具体的な理由を明示して乙に回答

場合は、その具体的な理由を明示して乙に回答することにより、承認を拒否又は留保することすることにより、承認を拒否又は留保することができる。但し、ソフトウェア開発作業を円滑ができる。但し、ソフトウェア開発作業を円滑に促進するため、甲は合理的理由のない限り適に促進するため、甲は合理的理由のない限り適時に第 2 項所定の点検結果を乙に交付するもの

時に第 2 項所定の点検結果を乙に交付するもの

とする。

とする。

4. 甲は、中間資料の点検期間内に書面で具体的な

4. 甲は、中間資料の点検期間内に書面で具体的な理由を明示した異議を述べない場合、中間資料

理由を明示した異議を述べない場合、中間資料の承認を行ったものとみなされる。

の承認を行ったものとみなされる。

5. 甲又は乙は、前各項により中間資料の承認がな

5. 甲又は乙は、前各項により中間資料の承認がなされた後に、中間資料の内容の変更の必要が生された後に、中間資料の内容の変更の必要が生じた場合は、変更提案書を相手方に交付して、じた場合は、変更提案書を相手方に交付して、変更の提案を行うことができる。

変更の提案を行うことができる。

6. 甲から承認された中間資料の内容の変更は、第6. 甲から承認された中間資料の内容の変更は、第37 条（変更管理手続）によってのみこれを行う

37 条（変更管理手続）によってのみこれを行うことができるものとする。

ことができるものとする。

（未確定事項の取扱い）（未確定事項の取扱い）

第 36 条

第 36 条

第 17 条に基づく要件定義書又は第 22 条

第 17 条に基づく要件定義書又は第 22 条に基づく外部設計書の点検期間内において、甲に基づく外部設計書の点検期間内において、甲が、当該要件定義書又は外部設計書において確が、当該要件定義書又は外部設計書において確定すべき事項のうち甲のやむを得ない事情によ定すべき事項のうち甲のやむを得ない事情によ147

り確定して提示することができない事項（以下

り確定して提示することができない事項（以下「未確定事項」という。）がある場合、甲及び「未確定事項」という。）がある場合、甲及び乙は、次の各号に定めることを条件として当該乙は、次の各号に定めることを条件として当該未確定事項を除き当該要件定義書又は外部設計

未確定事項を除き当該要件定義書又は外部設計

書を第 17 条又は第 22 条に従い確定させること

書を第 17 条又は第 22 条に従い確定させることができるものとする。

ができるものとする。

①

①

②

甲が未確定事項の内容とその確定時期、未甲が未確定事項の内容とその確定時期、未確定事項の確定により請求する追完、修正確定事項の確定により請求する追完、修正により委託料、作業期間、納期及びその他

により委託料、作業期間、納期及びその他の契約条件の変更を要する場合に甲がこの契約条件の変更を要する場合に甲がこれを受け入れること、その他必要となる事れを受け入れること、その他必要となる事項を記載した変更提案書を乙にすみやか

項を記載した変更提案書を乙に速やかにに提示する。

提示する。

前号に従い乙に変更提案書が提示された②

前号に従い乙に変更提案書が提示された

後すみやかに、甲及び乙はその内容につい後速やかに、甲及び乙はその内容についてて協議し、合意できた場合には、甲乙双方協議し、合意できた場合には、甲乙双方のの責任者が当該変更提案書に記名押印す責任者が当該変更提案書に記名押印する。

る。
2. 甲は、未確定事項を確定したときは直ちに、そ

2. 甲は、未確定事項を確定したときは直ちに、その内容を変更提案書により乙に通知するとともの内容を変更提案書により乙に通知するとともに、確定した要件定義書、外部設計書の追完、に、確定した要件定義書、外部設計書の追完、修正を請求できるものとする。なお、甲による修正を請求できるものとする。なお、甲による追完又は修正の請求は、第 37 条（変更管理手続）

追完又は修正の請求は、第 37 条（変更管理手続）

によってのみこれを行うことができるものとす

によってのみこれを行うことができるものとする。

る。

3. 甲が第 1 項の確定時期までに未確定事項を確

3．甲が第 1 項の確定時期までに未確定事項を確定しない場合、乙は、当該未確定事項は当該要定しない場合、乙は、当該未確定事項は当該要件定義書又は外部設計書の要件として無かった

件定義書又は外部設計書の要件として無かったもの（当該未確定事項につき選択肢が設けられもの（当該未確定事項につき選択肢が設けられており、甲がそのいずれかを選択しなかった場ており、甲がそのいずれかを選択しなかった場

合は、乙が選択したものを甲が選択したもの）

合は、乙が選択したものを甲が選択したもの）とみなすことができるものとする。但し、乙は、とみなすことができるものとする。但し、乙は、

当該未確定事項が無かったものとみなした場合

当該未確定事項が無かったものとみなした場合に、当該要件定義書又は外部設計書の他の要件に、当該要件定義書又は外部設計書の他の要件の実現に支障が生ずると判断し、相当期間を設の実現に支障が生じると判断し、相当期間を設けて確定を要請したにもかかわらず、なお甲がけて確定を要請したにもかかわらず、なお甲が確定しないときは、乙は第 52 条に準じ本契約及確定しないときは、乙は第 52 条に準じ本契約のび個別契約の全部又は一部を解除することがで全部又は一部及び履行の完了していない個別契きるものとする。

約を解除することができるものとする。

（変更管理手続）（変更管理手続）148

第 37 条甲又は乙は、相手方から第 34 条（システ

第 37 条甲又は乙は、相手方から第 34 条（システム仕様書等の変更）、第 35 条（中間資料のユー

ム仕様書等の変更）、第 35 条（中間資料のユー

ザによる承認）、第 36 条（未確定事項の取扱い）ザによる承認）、第 36 条（未確定事項の取扱い）に基づく変更提案書を受領した場合、当該受領に基づく変更提案書を受領した場合、当該受領日から〇日以内に、次の事項を記載した書面（以日から〇日以内に、次の事項を記載した書面（以下「変更管理書」という。）を相手方に交付し、下「変更管理書」という。）を相手方に交付し、甲及び乙は、当該交付日から○日以内に、第 12

甲及び乙は、当該交付日から○日以内に、第 12条所定の連絡協議会において当該変更の可否に条所定の連絡協議会において当該変更の可否につき協議するものとする。

つき協議するものとする。

①

変更の名称

①

変更の名称

②

提案の責任者②

提案の責任者

③

提案年月日

③

提案年月日

④

変更の理由

④

変更の理由

⑤

変更に係る仕様を含む変更の詳細事項⑤

変更に係る仕様を含む変更の詳細事項⑥

変更のために費用を要する場合はその額⑥変更のために費用を要する場合はその額⑦

協議期間を含めた変更作業のスケジュール⑦

協議期間を含めた変更作業のスケジュール⑧

その他変更が本契約及び個別契約の条件⑧

その他変更が本契約及び個別契約の条件（作業期間又は納期、委託料、契約条項等）（作業期間又は納期、委託料、契約条項等）に与える影響に与える影響2. 第 1 項の協議の結果、甲及び乙が変更を可とす

2. 第 1 項の協議の結果、甲及び乙が変更を可とす

る場合は、甲乙双方の責任者が、変更管理書のる場合は、甲乙双方の責任者が、変更管理書の記載事項（なお、協議の結果、変更がある場合

記載事項（なお、協議の結果、変更がある場合

は変更後の記載事項とする。以下同じ。）を承は変更後の記載事項とする。以下同じ。）を承認の上、記名押印するものとする。

認の上、記名押印するものとする。

3. 前項による甲乙双方の承認をもって、変更が確

3. 前項による甲乙双方の承認をもって、変更が確定するものとする。但し、本契約及び個別契約定するものとする。但し、本契約及び個別契約の条件に影響を及ぼす場合は、甲及び乙は速やの条件に影響を及ぼす場合は、甲及び乙は速やかに変更管理書に従い、第 33 条（本契約及び個かに変更管理書に従い、第 33 条（本契約及び個

別契約内容の変更）に基づき変更契約を締結す

別契約内容の変更）に基づき変更契約を締結するものとし、当該締結をもって変更が確定するるものとし、当該締結をもって変更が確定するものとする。

ものとする。

4. 乙は、甲から中断要請があるなどその他特段の4. 乙は、甲から中断要請があるなどその他特段の事情がある場合、第 1 項の協議が調わない間、事情がある場合、第 1 項の協議が調わない間、本件業務を中断することができる。

本件業務を中断することができる。

（変更の協議不調に伴う契約終了）（変更の協議不調に伴う契約終了）

第 38 条

第 38 条

前条第 1 項の協議期間内に協議が調わな

前条第 1 項の協議期間内に協議が調わなかった場合、甲及び乙は、個別業務の未了部分

かった場合、甲又は乙は、個別業務の未了部分について、本契約又は当該個別契約を解約するに係る当該個別契約の一部を解約することがでことができる。

きる。

2. 前項により個別契約が解約された場合、甲は、

149

2. 前項により個別契約の一部が解約された場合、

それまで乙が遂行した個別業務についての委託

甲は、それまで乙が遂行した個別業務に係る委料その他乙の支出した費用を支払うものとす

託料、及びその他乙の支出した費用を支払うも

る。

のとする。
第５章

資料及び情報の取扱い

第５章

資料及び情報の取扱い（資料等の提供及び返還）（資料等の提供及び返還）

第 39 条

第 39 条甲は乙に対し、本契約及び各個別契約に

甲は乙に対し、本契約及び各個別契約に定める条件に従い、当該個別業務遂行に必要な定める条件に従い、当該個別業務遂行に必要な資料等の開示、貸与等の提供を行う。

資料等の開示、貸与等の提供を行う。

2. 前項に定めるもののほか、乙から甲に対し、本

2. 前項に定めるもののほか、乙から甲に対し、本件業務遂行に必要な資料等の提供の要請があっ件業務遂行に必要な資料等の提供の要請があった場合、甲乙協議の上、各個別契約に定める条

た場合、甲乙協議の上、各個別契約に定める条件に従い、甲は乙に対しこれらの提供を行う。

件に従い、甲は乙に対しこれらの提供を行う。

3. 本件業務遂行上、甲の事務所等で乙が作業を実

3. 本件業務遂行上、甲の事務所等で乙が作業を実施する必要がある場合、甲は当該作業実施場所

施する必要がある場合、甲は当該作業実施場所（当該作業実施場所における必要な機器、設備（当該作業実施場所における必要な機器、設備等作業環境を含む。）を、甲乙協議の上、各個等作業環境を含む。）を、甲乙協議の上、各個別契約に定める条件に従い、乙に提供するもの

別契約に定める条件に従い、乙に提供するもの

とする。

とする。

4. 甲が前各項により乙に提供する資料等又は作4. 甲が前各項により乙に提供する資料等又は作業実施場所に関して、内容等の誤り又は甲の提業実施場所に関して、内容等の誤り又は甲の提供遅延によって生じた乙の本件業務の履行遅

供遅延によって生じた乙の本件業務の履行遅

滞、納入物の瑕疵等の結果については、乙はそ

滞、納入物の契約不適合等の結果については、の責を免れるものとする。

乙はその責を免れるものとする。

5. 甲から提供を受けた資料等（次条第 2 項による

5. 甲から提供を受けた資料等（次条第 2 項による複製物及び改変物を含む。）が本件業務遂行上複製物及び改変物を含む。）が本件業務遂行上不要となったときは、乙は遅滞なくこれらを甲不要となったときは、乙は遅滞なくこれらを甲に返還又は甲の指示に従った処置を行うものとに返還又は甲の指示に従った処置を行うものと

する。

する。

6. 甲及び乙は、前各項における資料等の提供、返6. 甲及び乙は、前各項における資料等の提供、返還その他処置等について、それぞれ第 10 条に定還その他処置等について、それぞれ第 10 条に定める主任担当者間で書面をもってこれを行うもめる主任担当者間で書面をもってこれを行うも

のとする。

のとする。

（資料等の管理）（資料等の管理）第 40 条

第 40 条乙は甲から提供された本件業務に関する

乙は甲から提供された本件業務に関する資料等を善良な管理者の注意をもって管理、保資料等を善良な管理者の注意をもって管理、保管し、かつ、本件業務以外の用途に使用しては管し、かつ、本件業務以外の用途に使用しては

ならない。

ならない。

2. 乙は甲から提供された本件業務に関する資料

2. 乙は甲から提供された本件業務に関する資料

等を本件業務遂行上必要な範囲内で複製又は改等を本件業務遂行上必要な範囲内で複製又は改

変できる。

変できる。

150

（秘密情報の取扱い）（秘密情報の取扱い）

第 41 条

第 41 条甲及び乙は、本件業務遂行のため相手方

甲及び乙は、本件業務遂行のため相手方より提供を受けた技術上又は営業上その他業務より提供を受けた技術上又は営業上その他業務上の情報のうち、相手方が書面（電子的形式を上の情報のうち、相手方が書面（電子的形式を含み、以下同様とする。）により秘密である旨含み、以下同様とする。）により秘密である旨指定して開示した情報、又は口頭により秘密で指定して開示した情報、又は口頭により秘密である旨を示して開示した情報で開示後○日以内ある旨を示して開示した情報で開示後○日以内に書面により内容を特定した情報（以下あわせに書面により内容を特定した情報（以下あわせて「秘密情報」という。）を第三者に漏洩してて「秘密情報」という。）を第三者に漏洩してはならない。但し、次の各号のいずれか一つにはならない。但し、次の各号のいずれか一つに該当する情報についてはこの限りではない。ま該当する情報についてはこの限りではない。また、甲及び乙は秘密情報のうち法令の定めに基た、甲及び乙は秘密情報のうち法令の定めに基づき開示すべき情報を、当該法令の定めに基づづき開示すべき情報を、当該法令の定めに基づ

く開示先に対し、当該法令の範囲内で秘密を保く開示先に対し、当該法令の範囲内で秘密を保持するための措置をとることを要求のうえで開持するための措置をとることを要求のうえで開示することができるものとする。

示することができるものとする。

①①

秘密保持義務を負うことなくすでに保有し
ている情報

②

ている情報

秘密保持義務を負うことなく第三者から正②

当に入手した情報③

秘密保持義務を負うことなく第三者から正当に入手した情報

相手方から提供を受けた情報によらず、独③

自に開発した情報④

秘密保持義務を負うことなくすでに保有し相手方から提供を受けた情報によらず、独自に開発した情報

本契約及び個別契約に違反することなく、④

本契約及び個別契約に違反することなく、かつ、受領の前後を問わず公知となった情

かつ、受領の前後を問わず公知となった情報

報

2. 秘密情報の提供を受けた当事者は、当該秘密情

2. 秘密情報の提供を受けた当事者は、当該秘密情報の管理に必要な措置を講ずるものとする。

報の管理に必要な措置を講じるものとする。

3. 甲及び乙は、秘密情報について、本契約及び個

3. 甲及び乙は、秘密情報について、本契約及び個

別契約の目的の範囲内でのみ使用し、本契約及別契約の目的の範囲内でのみ使用し、本契約及び個別契約の目的の範囲を超える複製、改変がび個別契約の目的の範囲を超える複製、改変が必要なときは、事前に相手方から書面による承必要なときは、事前に相手方から書面による承諾を受けるものとする。

諾を受けるものとする。

4. 甲及び乙は、秘密情報を、本契約及び個別契約

4. 甲及び乙は、秘密情報を、本契約及び個別契約の目的のために知る必要のある各自の役員及びの目的のために知る必要のある各自の役員及び従業員に限り開示するものとし、本契約及び個従業員に限り開示するものとし、本契約及び個別契約に基づき甲及び乙が負担する秘密保持義別契約に基づき甲及び乙が負担する秘密保持義務と同等の義務を、秘密情報の開示を受けた当務と同等の義務を、秘密情報の開示を受けた当該役員及び従業員に退職後も含め課すものとす

該役員及び従業員に退職後も含め課すものとする。また、乙は、第 7 条に基づく再委託先に対る。また、乙は、第 7 条に基づく再委託先に対して秘密情報を開示できるものとし、乙は当該して秘密情報を開示できるものとし、乙は当該

151

再委託先に対して本条と同等の義務を課すもの

再委託先に対して本条と同等の義務を課すもの

とする。

とする。

5. 秘密情報の提供及び返却等については、第 39

5. 秘密情報の提供及び返却等については、第 39条（資料等の提供及び返還）を準用する。

条（資料等の提供及び返還）を準用する。

6. 秘密情報のうち、個人情報に該当する情報につ

6. 秘密情報のうち、個人情報に該当する情報については、次条の規定が本条の規定に優先して適いては、次条の規定が本条の規定に優先して適用されるものとする。

用されるものとする。

7. 本条の規定は、本契約終了後、〇年間存続する。

7. 本条の規定は、個別契約における特段の定めや当事者間で特段の合意がない限り、本契約終了
後、〇年間存続する。

（個人情報）（個人情報）

第 42 条

第 42 条乙は、個人情報の保護に関する法律（本乙は、個人情報の保護に関する法律（本条において、以下「法」という。）に定める個条において、以下「法」という。）に定める個

人情報のうち、本件業務遂行に際して甲より取人情報のうち、本件業務遂行に際して甲より取扱いを委託された個人データ（法第 2 条第 4 項扱いを委託された個人データ（法第 2 条第 6 項に規定する個人データをいう。以下同じ。）及に規定する個人データをいう。以下同じ。）及び本件業務遂行のため、甲乙間で個人データとび本件業務遂行のため、甲乙間で個人データと同等の安全管理措置（法第 20 条に規定する安全

同等の安全管理措置（法第 20 条に規定する安全管理措置をいう。）を講ずることについて、個管理措置をいう。）を講じることについて、個別契約その他の契約により合意した個人情報

別契約その他の契約により合意した個人情報（以下あわせて「個人情報」という。）を第三（以下あわせて「個人情報」という。）を第三者に漏洩してはならない。なお、甲は、個人情者に漏洩してはならない。なお、甲は、個人情報を乙に提示する際にはその旨明示するものと報を乙に提示する際にはその旨明示するものとする。また、甲は、甲の有する個人情報を乙にする。また、甲は、甲の有する個人情報を乙に提供する場合には、個人が特定できないよう加提供する場合には、個人が特定できないよう加工した上で、乙に提供するよう努めるものとす

工した上で、乙に提供するよう努めるものとする。

る。

2. 乙は、個人情報の管理に必要な措置を講ずるも2. 乙は、個人情報の管理に必要な措置を講じるも

のとする。

のとする。

3. 乙は、個人情報について、本契約及び個別契約

3. 乙は、個人情報について、本契約及び個別契約の目的の範囲内でのみ使用し、本契約及び個別の目的の範囲内でのみ使用し、本契約及び個別契約の目的の範囲を超える複製、改変が必要な契約の目的の範囲を超える複製、改変が必要なときは、事前に甲から書面による承諾を受ける

ときは、事前に甲から書面による承諾を受ける

ものとする。

ものとする。

4. 個人情報の提供及び返却等については、第 39

4. 個人情報の提供及び返却等については、第 39条（資料等の提供及び返還）を準用する。

条（資料等の提供及び返還）を準用する。

5. 前第 1 項の定めにかかわらず、乙は、第 7 条第5．第 1 項の定めにかかわらず、乙は、第 7 条第 1

1 項に従い再委託する第三者に対して、第 7 条

項に従い再委託する第三者に対して、第 7 条第第 3 項の措置をとったうえで、当該個人情報を3 項の措置をとったうえで、当該個人情報を開開示できるものとする。

示できるものとする。

152

第６章

権利帰属

第６章

（納入物の所有権）（納入物の所有権）

第 43 条

第 43 条乙が本契約及び個別契約に従い甲に納入

権利帰属

乙が本契約及び個別契約に従い甲に納入する納入物の所有権は、当該個別契約に定めるする納入物の所有権は、当該個別契約に定める時期をもって、乙から甲へ移転する。

時期をもって、乙から甲へ移転する。

（納入物の特許権等）（納入物の特許権等）

第 44 条

第 44 条

本件業務遂行の過程で生じた発明その他

本件業務遂行の過程で生じた発明その他の知的財産又はノウハウ等（以下あわせて「発の知的財産又はノウハウ等（以下あわせて「発明等」という。）に係る特許権その他の知的財

明等」という。）に係る特許権その他の知的財

産権（特許その他の知的財産権を受ける権利を産権（特許その他の知的財産権を受ける権利を含む。但し、著作権は除く。）、ノウハウ等に含む。但し、著作権は除く。）、ノウハウ等に関する権利（以下、特許権その他の知的財産権、関する権利（以下、特許権その他の知的財産権、ノウハウ等に関する権利を総称して「特許権等」

ノウハウ等に関する権利を総称して「特許権等」という。）は、当該発明等を行った者が属するという。）は、当該発明等を行った者が属する当事者に帰属するものとする。

当事者に帰属するものとする。

2. 甲及び乙が共同で行った発明等から生じた特2. 甲及び乙が共同で行った発明等から生じた特許権等については、甲乙共有（持分は貢献度に許権等については、甲乙共有（持分は貢献度に応じて定める。）とする。この場合、甲及び乙応じて定める。）とする。この場合、甲及び乙は、共有に係る特許権等につき、それぞれ相手は、共有に係る特許権等につき、それぞれ相手方の同意及び相手方への対価の支払いなしに自方の同意及び相手方への対価の支払いなしに自ら実施し、又は第三者に対し通常実施権を実施

ら実施し、又は第三者に対し通常実施権を実施許諾することができるものとする。

許諾することができるものとする。

3. 乙は、第 1 項に基づき特許権等を保有すること

3. 乙は、第 1 項に基づき特許権等を保有することとなる場合、甲に対し、甲が本契約及び個別契となる場合、甲に対し、甲が本契約及び個別契約に基づき本件ソフトウェアを使用するのに必約に基づき本件ソフトウェアを使用するのに必要な範囲について、当該特許権等の通常実施権

要な範囲について、当該特許権等の通常実施権を許諾するものとする。なお、本件ソフトウェを許諾するものとする。なお、本件ソフトウェ

アに、個別契約において一定の第三者に使用せ

アに、個別契約において一定の第三者に使用せしめる旨を個別契約の目的として特掲した上でしめる旨を個別契約の目的として特掲した上で開発されたソフトウェア（以下「特定ソフトウェ開発されたソフトウェア（以下「特定ソフトウェ

ア」という。）が含まれている場合は、当該個ア」という。）が含まれている場合は、当該個別契約に従った第三者による当該ソフトウェア

別契約に従った第三者による当該ソフトウェアの使用についても同様とする。なお、かかる許の使用についても同様とする。なお、かかる許諾の対価は、委託料に含まれるものとする。

諾の対価は、委託料に含まれるものとする。

4. 甲及び乙は、第 2 項、第 3 項に基づき相手方と4. 甲及び乙は、第 2 項、第 3 項に基づき相手方と共有し、又は相手方に通常実施権を許諾する特共有し、又は相手方に通常実施権を許諾する特許権等について、必要となる職務発明の承継手

許権等について、必要となる職務発明の承継手

続（職務発明規定の整備等の職務発明制度の適続（職務発明規定の整備等の職務発明制度の適切な運用、譲渡手続など）を履践するものとす

切な運用、譲渡手続など）、又は法人帰属の定る。

めを行う場合はその為に必要となる手続（契約、153

勤務規則その他の定めにおいてあらかじめ甲又は乙に特許を受ける権利を取得させることを定める等の適切な運用）を履践するものとする。
（納入物の著作権）（納入物の著作権）

第 45 条

第 45 条納入物に関する著作権（著作権法第 27 条

納入物に関する著作権（著作権法第 27 条

及び第 28 条の権利を含む。）は、甲又は第三者

及び第 28 条の権利を含む。）は、甲又は第三者が従前から保有していた著作物の著作権を除が従前から保有していた著作物の著作権を除き、乙に帰属するものとする。

き、乙に帰属するものとする。

2. 甲は、納入物のうちプログラムの複製物を、著

2. 甲は、納入物のうちプログラムの複製物を、著

作権法第 47 条の 2 に従って自己利用に必要な範

作権法第 47 条の 3 及び第 47 条の 6 第 1 項第 2

囲で、複製、翻案することができるものとする。

号に従って自己利用に必要な範囲で、複製、翻また、本件ソフトウェアに特定ソフトウェアが案することができるものとする。また、本件ソ含まれている場合は、本契約及び個別契約に従フトウェアに特定ソフトウェアが含まれているい第三者に対し利用を許諾することができる。

場合は、本契約及び個別契約に従い第三者に対乙は、かかる利用について著作者人格権を行使

し利用を許諾することができる。乙は、かかるしないものとする。

利用について著作者人格権を行使しないものとする。

（乙による納入物の再利用）（乙による納入物の再利用）

第 46 条

第 46 条乙は、第 41 条（秘密情報の取扱い）に反

乙は、第 41 条（秘密情報の取扱い）に反しない範囲において、乙が著作権を保有する本しない範囲において、乙が著作権を保有する本件ソフトウェアその他の納入物を利用すること

件ソフトウェアその他の納入物を利用すること

ができる。

ができる。

2. 前項による利用には、有償無償を問わず乙が本

2. 前項による利用には、有償無償を問わず乙が本件ソフトウェアの利用を第三者に許諾し、又は件ソフトウェアの利用を第三者に許諾し、又はパッケージ化して複製物を販売する場合を含む

パッケージ化して複製物を販売する場合を含むものとする。

ものとする。

第７章

保証及び責任第７章

保証及び責任

【A 案】

【A 案】

（知的財産権侵害の責任）（知的財産権侵害の責任）

第 47 条

第 47 条甲が納入物に関し第三者から、日本国内

甲が納入物に関し第三者から、日本国内

における著作権、特許権その他の産業財産権（以における著作権、特許権その他の産業財産権（以下本条において「知的財産権」という。）の侵

下本条において「知的財産権」という。）の侵害の申立を受けた場合、次の各号所定のすべて

害の申立を受けた場合、次の各号所定のすべての要件が充たされる場合に限り、第 53 条（損害の要件が充たされる場合に限り、第 53 条（損害賠償）の規定にかかわらず乙はかかる申立に賠償）の規定にかかわらず乙はかかる申立によって甲が支払うべきとされた損害賠償額を負

よって甲が支払うべきとされた損害賠償額を負担するものとする。但し、第三者からの申立が担するものとする。但し、第三者からの申立が乙の責に帰すべからざる事由による場合（甲乙乙の責に帰すべからざる事由による場合（甲乙間で別段合意がない限り、第 48 条に定める第三間で別段合意がない限り、第 48 条に定める第三者ソフトウェア又は第 49 条に定める FOSS に者ソフトウェア又は第 49 条に定める FOSS に154

起因する場合を含む。）にはこの限りではなく、起因する場合を含む。）にはこの限りではなく、乙は一切責任を負わないものとする。

乙は一切責任を負わないものとする。

①

①

②

③

甲が第三者から申立を受けた日から〇日以甲が第三者から申立を受けた日から〇日以内に、乙に対し申立の事実及び内容を通知

内に、乙に対し申立の事実及び内容を通知

すること

すること

甲が第三者との交渉又は訴訟の遂行に関②甲が第三者との交渉又は訴訟の遂行に関し、乙に対して実質的な参加の機会及びす

し、乙に対して実質的な参加の機会及びすべてについての決定権限を与え、並びに必べてについての決定権限を与え、並びに必要な援助をすること要な援助をすること

甲の敗訴判決が確定すること又は乙が訴訟③

甲の敗訴判決が確定すること又は乙が訴訟遂行以外の決定を行ったときは和解などに遂行以外の決定を行ったときは和解などにより確定的に解決すること

より確定的に解決すること

2. 乙の責に帰すべき事由による知的財産権の侵

2. 乙の責に帰すべき事由による知的財産権の侵害を理由として納入物の将来に向けての使用が害を理由として納入物の将来に向けての使用が不可能となるおそれがある場合、乙は、乙の判不可能となるおそれがある場合、乙は、乙の判断及び費用負担により、（ⅰ）権利侵害のない

断及び費用負担により、（ⅰ）権利侵害のない

他の納入物との交換、（ⅱ）権利侵害している

他の納入物との交換、（ⅱ）権利侵害している部分の変更、（ⅲ）継続使用のための権利取得部分の変更、（ⅲ）継続使用のための権利取得のいずれかの措置を講じることができるものとのいずれかの措置を講じることができるものと

する。

する。

3. 第 1 項に基づき乙が負担することとなる損害

3. 第 1 項に基づき乙が負担することとなる損害

以外の甲に生じた損害については、第 53 条（損以外の甲に生じた損害については、第 53 条（損害賠償）の規定によるものとする。

害賠償）の規定によるものとする。

【B 案】

【B 案】

（知的財産権侵害の責任）（知的財産権侵害の責任）

第○条

第○条

本契約及び個別契約に従った甲による納本契約及び個別契約に従った甲による納入物の利用が、第三者の日本国内における著作入物の利用が、第三者の日本国内における著作権、特許権その他の産業財産権（以下本条にお権、特許権その他の産業財産権（以下本条において「知的財産権」という。）を侵害したとき、いて「知的財産権」という。）を侵害したとき、乙は第 53 条（損害賠償）所定の金額を限度とし

乙は第 53 条（損害賠償）所定の金額を限度として、甲に対してかかる侵害によって甲に生じたて、甲に対してかかる侵害によって甲に生じた損害（侵害を回避した代替プログラムへの移行

損害（侵害を回避した代替プログラムへの移行を行う場合の費用を含む。）を賠償する。但し、を行う場合の費用を含む。）を賠償する。但し、知的財産権の侵害が乙の責めに帰すべからざる

知的財産権の侵害が乙の責めに帰すべからざる事由による場合（甲乙間で別段合意がない限り、事由による場合（甲乙間で別段合意がない限り、第 48 条に定める第三者ソフトウェア又は第 49

第 48 条に定める第三者ソフトウェア又は第 49条に定める FOSS に起因する場合を含む。）は条に定める FOSS に起因する場合を含む。）はこの限りでなく、乙は一切責任を負わないもの

この限りでなく、乙は一切責任を負わないもの

とする。

とする。

2. 甲は、本契約及び個別契約に従った甲による納155

2. 甲は、本契約及び個別契約に従った甲による納入物の利用に関して第三者から知的財産権の侵

入物の利用に関して第三者から知的財産権の侵害の申立を受けた場合、すみやかに書面でその害の申立を受けた場合、速やかに書面でその旨旨を乙に通知するものとし、乙は、甲の要請にを乙に通知するものとし、乙は、甲の要請に応応じて甲の防御のために必要な援助を行うもの

じて甲の防御のために必要な援助を行うものと

とする。

する。

（第三者ソフトウェアの利用）（第三者ソフトウェアの利用）

第 48 条

第 48 条甲又は乙は、本件業務遂行の過程におい甲又は乙は、本件ソフトウェアが備えるて、本件ソフトウェアが備える予定の機能、仕予定の機能、仕様の一部とするために、第三者様の一部とするために、第三者ソフトウェアを

ソフトウェアを利用しようとするときは、第 4利用しようとするときは、第 37 条（変更管理手条に定める個別契約に定めるものとし、本件業続）によるものとする。

務遂行の過程において第三者ソフトウェアを利用しようとするときは、第 37 条（変更管理手続）によるものとする。

2. 前項に基づき第三者ソフトウェアを利用する

2．前項に基づき第三者ソフトウェアを利用することとなった場合、甲は、甲の費用と責任におこととなった場合、甲は、甲の費用と責任において、甲と当該第三者との間で当該第三者ソフ

いて、甲と当該第三者との間で当該第三者ソフ

トウェアのライセンス契約及び保守契約の締結

トウェアのライセンス契約及び保守契約の締結等、必要な措置を講じるものとする。但し、乙等、必要な措置を講じるものとする。但し、乙が、当該第三者ソフトウェアを甲に利用許諾すが、当該第三者ソフトウェアを甲に利用許諾する権限を有する場合は、甲乙間においてライセる権限を有する場合は、甲乙間においてライセンス契約等、必要な措置を講ずるものとする。

ンス契約等、必要な措置を講じるものとする。

3. 乙は、第三者ソフトウェアに関して、著作権そ

3．乙は、第三者ソフトウェアに関して、著作権の他の権利の侵害がないこと及び瑕疵のないこ

その他の権利の侵害がないこと及び不具合のなとを保証するものではなく、乙は、第 1 項に基いことを保証するものではなく、乙は、第 1 項

づく利用決定時に、権利侵害又は瑕疵の存在をに基づく利用決定時に、権利侵害又は不具合の知りながら、若しくは重大な過失により知らず

存在を知りながら、若しくは重大な過失によりに告げなかった場合を除き、何らの責任を負わ知らずに告げなかった場合を除き、何らの責任ないものとする。但し、前項但書の場合で、甲を負わないものとする。但し、前項但書の場合

乙間において当該第三者ソフトウェアに関するで、甲乙間において当該第三者ソフトウェアにライセンス契約が締結され、当該ライセンス契関するライセンス契約が締結され、当該ライセ

約に別段の定めがあるときには、当該定めによ

ンス契約に別段の定めがあるときには、当該定るものとする。

めによるものとする。

（FOSS の利用）

（FOSS の利用）

第 49 条

第 49 条甲又は乙は、本件業務遂行の過程におい甲又は乙は、本件ソフトウェアが備えるて、本件ソフトウェアが備える予定の機能、仕予定の機能、仕様の一部を実現するために、様の一部を実現するために、FOSS を利用しよ

FOSS を利用しようとするときは、第 4 条に定うとするときは、第 37 条（変更管理手続）によめる個別契約に定めるものとし、本件業務遂行るものとする。なお、乙が第 37 条に従い FOSSの過程において FOSS を利用しようとするときの利用を提案する場合、第 37 条第 1 項各号の事

は、第 37 条（変更管理手続）によるものとする。

項に加え、当該 FOSS の利用許諾条項、機能、

なお、乙が第 37 条に従い FOSS の利用を提案

156

開発管理コミュニティの名称・特徴など FOSSする場合、第 37 条第 1 項各号の事項に加え、当の性格に関する情報、当該 FOSS の機能上の制

該 FOSS の利用許諾条項、機能、開発管理コミュ

限事項、品質レベル等に関して適切な情報を書

ニティの名称・特徴など FOSS の性格に関する面により提供するよう努めるものとする。

情報、当該 FOSS の機能上の制限事項、品質レベル等に関して適切な情報を書面により提供するよう努めるものとする。

2. 前項に基づき FOSS を利用することとなった

2．前項に基づき FOSS を利用することとなった

場合、甲は、甲の費用と責任において、乙又は場合、甲は、甲の費用と責任において、乙又は第三者との間で FOSS の保守、障害対応支援契

第三者との間で FOSS の保守、障害対応支援契約の締結等、必要な措置を講じるものとする。

約の締結等、必要な措置を講じるものとする。

3. 乙は、FOSS に関して、著作権その他の権利の3．乙は、FOSS に関して、著作権その他の権利の侵害がないこと及び瑕疵のないことを保証する

侵害がないこと及び不具合のないことを保証すものではなく、乙は、第 1 項に基づく利用決定

るものではなく、乙は、第 1 項に基づく利用決時に、権利侵害又は瑕疵の存在を知りながら、

定時に、権利侵害又は不具合の存在を知りなが若しくは重大な過失により知らずに告げなかっら、若しくは重大な過失により知らずに告げなた場合を除き、何らの責任を負わないものとす

かった場合を除き、何らの責任を負わないもの

る。

とする。

（セキュリティ）（セキュリティ）

第 50 条第 50 条乙が納入する本件ソフトウェアのセキュ乙が納入する本件ソフトウェアのセキュ

リティ対策について、甲及び乙は、その具体的

リティ対策について、甲及び乙は、その具体的な機能、遵守方法、管理体制及び費用負担等をな機能、遵守方法、管理体制及び費用負担等を協議の上、別途書面により定めるものとする。

協議の上、別途書面により定めるものとする。

第8章

第8章

一般条項

（権利義務譲渡の禁止）（権利義務譲渡の禁止）

第 51 条

第 51 条甲及び乙は、互いに相手方の事前の書面

一般条項

甲及び乙は、互いに相手方の事前の書面による同意なくして、本契約上の地位を第三者による同意なくして、本契約上の地位を第三者に承継させ、又は本契約から生じる権利義務のに承継させ、又は本契約から生じる権利義務の全部若しくは一部を第三者に譲渡し、引き受け

全部若しくは一部を第三者に譲渡し、引き受けさせ若しくは担保に供してはならない。

させ若しくは担保に供してはならない。

（解除）
第 52 条（解除）
甲又は乙は、相手方に次の各号のいずれ

第 52 条甲又は乙は、相手方に次の各号のいずれかに該当する事由が生じた場合には、何らの催かに該当する事由が生じた場合には、何らの催告なしに直ちに本契約及び個別契約の全部又は告なしに直ちに本契約の全部又は一部及び履行一部を解除することができる。

の完了していない個別契約を解除することがで
きる。

①

②

支払いの停止があった場合、又は仮差押、①

支払いの停止があった場合、又は仮差押、差押、競売、破産手続開始、民事再生手続

差押、競売、破産手続開始、民事再生手続開始、会社更生手続開始、特別清算開始の開始、会社更生手続開始、特別清算開始の申立があった場合申立があった場合

手形交換所の取引停止処分を受けた場合②

157

手形交換所の取引停止処分を受けた場合

③

公租公課の滞納処分を受けた場合③

公租公課の滞納処分を受けた場合④

その他前各号に準ずるような本契約又は個④

その他前各号に準ずるような本契約又は個⑤

別契約を継続し難い重大な事由が発生した

別契約を継続し難い重大な事由が発生した

場合

場合

監督官庁から営業の取消・停止処分等を受⑤けたとき又は転廃業しようとしたとき⑥

監督官庁から営業の取消・停止処分等を受けたとき又は転廃業しようとしたとき

解散又は本契約及び個別契約の履行若しく⑥

解散又は本契約及び個別契約の履行若しくは本件ソフトウェアに係る事業の全部又はは本件ソフトウェアに係る事業の全部又は重要な一部を第三者に譲渡しようとしたと重要な一部を第三者に譲渡しようとしたときき

2. 甲又は乙は、相手方が本契約又は個別契約のい

2. 甲又は乙は、相手方の責に帰すべき事由によりずれかの条項に違反し、相当期間を定めてなし

本契約又は個別契約のいずれかの条項に違反た催告後も、相手方の債務不履行が是正されなし、相当期間を定めてなした催告後も、相手方い場合は、本契約及び個別契約の全部又は一部の債務不履行が是正されない場合は、本契約のを解除することができる。

全部又は一部及び履行の完了していない個別契約を解除することができる。但し、当該期間を経過した時における債務の不履行が当該契約及び取引上の社会通念に照らして軽微であるときは、この限りでない。

3. 甲又は乙は、第 1 項各号のいずれかに該当する

3. 甲又は乙は、第 1 項各号のいずれかに該当する

場合又は前項に定める解除がなされた場合、相場合又は前項に定める解除がなされた場合、相手方に対し負担する一切の金銭債務につき相手手方に対し負担する一切の金銭債務につき相手方から通知催告がなくとも当然に期限の利益を方から通知催告がなくとも当然に期限の利益を喪失し、直ちに弁済しなければならない。

喪失し、直ちに弁済しなければならない。

（損害賠償）（損害賠償）

第 53 条

第 53 条甲及び乙は、本契約及び個別契約の履行

甲及び乙は、本契約及び個別契約の履行に関し、相手方の責に帰すべき事由により損害に関し、相手方の責に帰すべき事由により損害を被った場合又は第 29 条に基づく瑕疵の修正を被った場合、相手方に対して、損害賠償を請が相当な範囲内で繰り返し実施されたにもかか求することができる。但し、第 29 条に定める契わらず、当該瑕疵が乙の責に帰すべき事由によ約不適合責任については、当該契約不適合の修り修正されないことにより損害を被った場合、正が相当な範囲内で繰り返し実施されたにもか

相手方に対して、損害賠償を請求することがでかわらず、当該契約不適合が乙の責に帰すべききる。但し、この瑕疵に関する損害賠償請求は、事由により修正されないことにより損害を被っ

当該損害賠償の請求原因となる当該個別契約にた場合に限り、甲は乙に対して損害賠償を請求定める納入物の検収完了日から○ヶ月間が経過できるものとし、当該損害賠償請求は、当該損した後は行うことができない。

害賠償の請求原因となる当該個別契約に定める納入物の検収完了日から○ヶ月間が経過した後は行うことができないものとする。

2. 前項の損害賠償の累計総額は、債務不履行、法2. 前項の損害賠償の累計総額は、債務不履行、契律上の瑕疵担保責任、不当利得、不法行為その約不適合、不当利得、不法行為その他請求原因

158

他請求原因の如何にかかわらず、帰責事由の原の如何にかかわらず、また、乙に重大な過失が因となった個別契約に定める委託料の金額を限ある場合であっても、帰責事由の原因となった

度とし、また、当事者の予見の有無を問わず特個別契約に定める委託料の金額を限度とし、ま別の事情から生じた損害、逸失利益については、た、当事者が予見すべきであったか否かを問わ賠償責任を負わないものとする。

ず特別の事情から生じた損害、逸失利益については、賠償責任を負わないものとする。

（輸出関連法令の遵守）（輸出関連法令の遵守）

第 54 条

第 54 条甲は、乙から納入された納入物を輸出す

甲は、乙から納入された納入物を輸出する場合には、外国為替及び外国貿易法その他輸る場合には、外国為替及び外国貿易法その他輸出関連法令を遵守し、所定の手続をとるものと出関連法令を遵守し、所定の手続をとるものとする。なお、米国輸出関連法等外国の輸出関連する。なお、米国輸出関連法等外国の輸出関連法令の適用を受け、所定の手続が必要な場合も法令の適用を受け、所定の手続が必要な場合も同様とする。

同様とする。
（反社会的勢力の排除）
第 55 条甲及び乙は、現時点及び将来にわたって、自己が次の各号のいずれにも該当しないことを表明し、又は確約する。
①

暴力団、暴力団員、暴力団準構成員、暴力
団関係企業、総会屋、社会運動等標ぼうゴ
ロ、特殊知能暴力集団その他これらに準ずる者（以下、総称して「反社会的勢力」という。）であること又は反社会的勢力であったこと。

②

反社会的勢力が経営を支配していること。

③

代表者、責任者又は経営に実質的に関与している者が反社会的勢力であること。

（新規追加）④

自己又は第三者の不正の利益を図る目的をもってする等反社会的勢力を利用していると認められる関係を有すること。

⑤

反社会的勢力に対して資金等を提供し、又は便宜を図る等反社会的勢力に利益を供与していると認められる関係を有すること。

⑥

反社会的勢力と密接に交際をする等社会的に非難されるべき関係を有すること。

⑦

暴力的又は法的な責任を超えた不当な要求行為を行うこと。

⑧

取引に関して脅迫的な言動をし、又は暴力を用いる行為を行うこと。

⑨

風説を流布し、又は偽計若しくは威力を用いて、相手方の信用を毀損し、又は相手方

159

の業務を妨害する行為を行うこと。
2．甲及び乙は、自己が本契約及び個別契約の履行のために用いる者（個人か法人かを問わず、数次の取引先等第三者を介して用いる者を含
み、以下、総称して「履行補助者」という。）
が前項各号のいずれかに該当した場合、当該履行補助者との契約の解除その他の必要な措置を講じることを確約する。
3．甲又は乙が前二項の表明又は確約のいずれかに反した場合、相手方は通知その他の手続を要しないで、本契約及び個別契約の全部又は一部を解除することができる。
（和解による紛争解決）（和解による紛争解決）

第 55 条

第 56 条本契約に関し、甲乙間に紛争が生じた場

本契約に関し、甲乙間に紛争が生じた場

合、甲及び乙は、第 56 条所定の紛争解決手続を合、甲及び乙は、第 57 条所定の紛争解決手続とる前に、紛争解決のため第 12 条に定める連絡をとる前に、紛争解決のため第 12 条に定める協議会を開催し協議を十分に行うとともに、次連絡協議会を開催し協議を十分に行うととも項以下の措置をとらなければならない。

に、次項以下の措置をとらなければならない。

2. 前項所定の連絡協議会における協議で甲乙間

2. 前項所定の連絡協議会における協議で甲乙間の紛争を解決することができない場合、第 56の紛争を解決することができない場合、第 57条に定める紛争解決手続をとろうとする当事者条に定める紛争解決手続をとろうとする当事は、相手方に対し紛争解決のための権限を有す者は、相手方に対し紛争解決のための権限を有る代表者又は代理権を有する役員その他の者とする代表者又は代理権を有する役員その他のの間の協議を申し入れ、相手方が当該通知を受者との間の協議を申し入れ、相手方が当該通知領してから○日以内に（都市名）において、誠を受領してから○日以内に（都市名）において、実に協議を行うことにより紛争解決を図るもの

誠実に協議を行うことにより紛争解決を図るとする。

ものとする。

3. 前項所定の甲及び乙の紛争解決のための協議

3. 前項所定の甲及び乙の紛争解決のための協議

で当事者間の紛争等を解決することができないで当事者間の紛争等を解決することができない

場合、甲及び乙は、裁判外紛争解決手続の利用

場合、甲及び乙は、裁判外紛争解決手続の利用の促進に関する法律（平成 16 年法律第 151 号）の促進に関する法律（平成 16 年法律第 151 号）

第 2 条第 3 号に定める認証紛争解決手続であっ第 2 条第 3 号に定める認証紛争解決手続であって（都市名）において行われる認証紛争解決事て（都市名）において行われる認証紛争解決事

業者を選択し、当該事業者による認証紛争解決

業者を選択し、当該事業者による認証紛争解決手続を通した和解による解決を図るものとす

手続を通した和解による解決を図るものとする。

る。

4. 前項に定める認証紛争解決手続によって和解

4. 前項に定める認証紛争解決手続によって和解が成立する見込みがないことを理由に当該認証が成立する見込みがないことを理由に当該認証紛争解決手続が終了した場合、甲及び乙は、第紛争解決手続が終了した場合、甲及び乙は、第56 条所定の紛争解決手続をとることができる。

57 条所定の紛争解決手続をとることができる。

160

【A 案】

【A 案】

（仲裁）

（仲裁）

第 56 条

第 57 条

本契約及び個別契約に関し、甲乙間に紛本契約及び個別契約に関し、甲乙間に紛争解決の必要が生じた場合、（仲裁機関名）の争解決の必要が生じた場合、（仲裁機関名）の仲裁規則に従って、（都市名）において仲裁に

仲裁規則に従って、（都市名）において仲裁により終局的に解決されるものとする。

より終局的に解決されるものとする。

【B 案】

【B 案】

（合意管轄）（合意管轄）

第○条

第○条

本契約及び個別契約に関し、訴訟の必要が本契約及び個別契約に関し、訴訟の必要が生じた場合には、○○地方裁判所を第一審の専生じた場合には、○○地方裁判所を第一審の専属属的合意管轄裁判所とする。

的合意管轄裁判所とする。

（協議）第 57 条（協議）
本契約及び個別契約に定めのない事項又第 58 条

本契約及び個別契約に定めのない事項又は疑義が生じた事項については、信義誠実の原は疑義が生じた事項については、信義誠実の原則に従い甲乙協議し、円満に解決を図るものと則に従い甲乙協議し、円満に解決を図るものと

する。

する。
（存続条項）
第 59 条

本契約が解除その他の原因により終了した場合であっても、本契約に基づく個別契約が存続する場合、その限りにおいて本契約の規定は存続するものとする。
2. 前項に加え、本契約が解除その他の原因により終了した場合であっても、第 2 条（定義）、
第 3 条（適用範囲・完全合意）、【B 案】第○条（契約不適合責任）、第 29 条（契約不適合責任）、第 39 条（資料等の提供及び返還）第5 項及び第 6 項、第 40 条（資料等の管理）第 1
項、第 42 条（個人情報）（但し、第 5 項を除（新規追加）く。）、第 44 条（納入物の特許権等）、第 45条（納入物の著作権）、第 46 条（乙による納入物の再利用）、【A 案】第 47 条（知的財産権侵害の責任）、【B 案】第○条（知的財産権侵害の責任）、第 48 条（第三者ソフトウェアの利用）第 3 項、第 49 条（FOSS の利用）第3 項、第 53 条（損害賠償）、第 54 条（輸出関連法令の遵守）、第 56 条（和解による紛争解決）、【A 案】第 57 条（仲裁）、【B 案】第○条（合意管轄）及び第 58 条（協議）は、な
お有効に存続するものとする。

161

付録②︓JEITA 法務・知的財産部会 改正⺠法対応 TF 公表資料
２０１８年５月２２日
ＪＥＩＴＡ

法務・知的財産部会

改正民法対応ＴＦ「改正民法施行後の契約における売買・請負の担保責任のあり方について」
ＩＴ製品・サービスに係る企業活動において、売買、請負の取引は頻繁に行われますが、２０２０年
４月 1 日施行の「民法の一部を改正する法律」（平成２９年法律第４４号、以下「改正民法」）では、売買、請負における買主・注文者（以下「発注者」）に対する売主・請負人（以下「受注者」）の責任も改正されます。
しかしながら、民法は元々、必ずしもＩＴ製品・サービスに係る企業活動・取引に適した条件と整合しない側面があり、ＩＴ製品・サービス関連取引では、民法と一部異なる条件で取引を行う慣行が成立しています。それにも関わらず、改正民法の条件をそのまま契約で用いる場合、受注者の担保責任期間が現状の企業間及び公的機関等・企業間の取引慣行に比べ大きく長期化する、「契約内容への不適合」の意義が曖昧なままとなるといった問題があります。
当協会として、改正民法を根拠に、取引慣行と著しく異なる責任・運用が受注者に要求されることは、
ＩＴ製品・サービス関連取引における発注者・受注者双方にとっての活発な企業活動、健全な企業育成の大きな阻害要因となりかねないと懸念するところであり、改正民法に優先する発注者・受注者間の担保責任に関する契約条件のあり方は現行の取引慣行が引き続き維持されるべきものとして、下記のとおり意見を表明致します。
記
１．ハードウェア等の製品売買、ソフトウェア開発等の請負における担保責任期間について受注者の担保責任期間は、以下の理由から、改正民法下での契約でも、現行の取引慣行どおり「引渡し（又は検収）時から○ヶ月」42とすることが妥当であると考えます。
【担保責任期間の比較】①取引慣行における受注者の担保責任期間（無償保証期間と位置づけられることもある）
引渡し（又は検収）時から○ヶ月（瑕疵修補請求等の権利の存続期間）②改正民法における受注者の担保責任期間（改正民法第５６６条、第６３７条第１項）43
i「種類又は品質に関して契約の内容に適合しないもの」（以下「種類・品質の不適合」）である場合：不適合がある旨を発注者が知った時から１年（当該不適合の事実の通知期限）
ii「数量又は権利移転義務に関して契約の内容に適合しないもの」（以下「数量等の不適合」）である場合

42『情報システムにおいては、１年あれば、１事業年度、四季（季節的変動）等のサイクルを経験し、基本的な機能について一通り経験できると考えられることから、１年程度がおおむね妥当な期間と思われる。』（JEITA ソリューション
サービス事業委員会「ソフトウェア開発モデル契約の解説」商事法務（２００８）、１４５頁）
43 改正民法第１６６条第１項により時効消滅するまで（権利行使することができることを知った時から５年間、又は権利を行使することができる時から１０年のいずれか早いときに時効消滅）。

162

：時効に従う
なお、本紙では「種類・品質の不適合」と「数量等の不適合」を併せ「契約内容不適合」とします。

【理由】（１）改正民法に準拠する場合、発注者が種類・品質の不適合を知った時から１年が担保責任期間となり、取引慣行よりも受注者の担保責任期間が長期化します。また、担保責任期間の起算点が「知った時」になるため、「知った」か「知らない」かという発注者側の主観に依拠することとなり、受注者の立場が長期間にわたり不安定となります。この場合、以下のような弊害が生じます。
①受注者は責任期間延長に必要なコスト（長期化する期間分の人件費・賠償リスク費等）を見積に加算せねばならず、取引対価が上昇。社会全体でコスト増となり、最終的に消費者に転嫁されうる。
・従来は引渡し（又は検収）後○ヶ月の瑕疵対応状況を鑑み見積もっていたが、開発成果物が存在しない契約時点で、引渡し（又は検収）後の長期かつ未確定要素の多い不具合への対応費用にリスク費用を含めて見積もらざるを得ない。
・受注者の担保責任期間が最大で１０年となるため、当該期間の使用に耐えうるシステムとするために、検討要素・範囲が増大し、各工程も長期化する（従来は、○ヶ月の担保責任期間・４～５年のライフサイクルを前提に設計・開発・テスト等各工程を実施）。
②ＩＴ分野の取引目的物の修補等の対応には、その開発に携わった技術者の知見が必須な場合が多く、担保責任期間が長期化する場合、受注者はその期間中当該技術者を拘束する等対策を講じねばならない。企業の人員計画上過剰な負荷になる上に、当該従業員は多様な業務に参画する機会が減り、人材育成上も障害になりうる。
③ＩＴ製品・サービス関連取引には、受注者が他ベンダから調達する製品・役務が含まれる。発注者・受注者間の担保責任期間を改正民法に準拠する場合、受注者・調達先間も同等の期間とする必要があるが、「（顧客側が）知った時」を担保責任期間の起算点とするＩＴ製品等は皆無に等しく、各当事者間の契約条件が整合しない。
（２）今回の改正により、担保責任期間を現行民法の売買のルールに合わせることになりましたが、従前から、現行民法の売買の担保責任期間は、実際の取引で採用されていません4445。法改正を契機に、契約条件を民法に合わせる必要はないと考えます。
（３）民法は消費者との取引にも適用されるものであり、消費者は通常、取引の目的物等を検査する能力が高くないこと（消費者保護の観点）等の理由で、改正民法の担保責任期間の起算点は、発注者が不適合を「知った時」にしています。これに対し、企業間の取引では、発注者は注意して検査する役割を担っており、かつ、納入後に発注者が検査するプロセスを取っています。これらにより、発注者・受注者間の取引関係の合理的期間での安定化を図っておりますので、契約においては、取引慣行通り、引渡し（又は検収）時を起算点とすることが妥当と考えます。
２．担保責任期間（引渡し（又は検収）後○ヶ月）経過後の契約内容不適合の修補は、保守契約を結び

44

現行民法上の売買の担保責任期間は発注者が瑕疵を知ってから１年（民法第５６６条第３項）。しかし、引渡し（又は検収）から数年後に担保責任を追及されることはビジネスにそぐわない（売主が長い間不安定となる）との背景で、商法は「引渡しから６か月」と短縮しており（商法第５２６条）、これを受け、売買では、民法と異なる「引渡し（又は検収）時から起算し、○ヶ月」の責任期間とすることが取引慣行になっている。
45 商人間の売買における受注者の担保責任期間は、改正民法施行後も、現行「商法」どおり引渡し時から６か月。

163

実施すべきであることについて
開発着手前の段階で将来のソフトウェアに生じる契約内容不適合への修補費用を算出することは不確定要素が多くコストが高くなることから、現行どおり上記担保責任期間経過後の修補は保守契約を結び実施すべきであると考えます。

【理由】
受注者においては、ソフトウェア開発の引渡し（又は検収）後○ヶ月の担保責任期間の中で一連の不具合対応46を発注者と協働して実施し、その収束状況から当該期間経過後の稼動状況や不具合の発生
リスク・システムのライフサイクル等も踏まえて保守費用を見積もることが一般的です。
これらを契約前の段階で行うことは、１（１）①のとおり、発注者・受注者双方にとって積極的なメリットがありません。
一方、ソフトウェアに関し後発的にセキュリティ等の課題が発生することに備え、現行、保守契約の一部として予防保守を行う場合がありますが、それらは契約内容不適合に対する担保責任に基づく修補ではありません。このように、改正民法をもって保守契約が不要となるものではなく、発注者側でソフトウェアに対策を行う必要性は引き続き残りますので、受注者と保守契約を結び適切に維持することが必要と考えます。
３．ソフトウェア開発等47の請負で担保責任対象となる「契約内容不適合」の定義について
当協会ソリューションサービス事業委員会が公表した「ソフトウェア開発基本契約書」（以下「モデル契約」）では、ソフトウェア開発等の請負における納入物の瑕疵担保責任規定において、「瑕疵」とは「システム仕様書との不一致」を指すものと定義しています。
改正民法で、「瑕疵」は「契約内容不適合」に変わりますが、以下の理由から、引き続きモデル契約
同様に「契約内容不適合」は「システム仕様書との不一致」と定義することが合理的と考えます。

【理由】
現行民法では、「瑕疵」とは具体的に何を意味するか曖昧であるという問題があります。このため、当協会モデル契約は、「瑕疵」とは「システム仕様書との不一致」を指す48旨の定義を置いています。
改正民法では、現行民法の「瑕疵」の表現自体が国民一般には分かりにくい等との趣旨から、「契約内容不適合」が担保責任の対象となりました。
しかしながら、瑕疵と同様に「契約内容不適合」の意義・判断基準はなお曖昧なため、契約で定義を置くことの合理性が認められると考えます。
以

46

上

契約内容不適合か否かの切り分け・暫定的な回避策や運用方法の策定・具体的な対策版の作成・影響範囲の調査や実装のタイミングの調整・対策版の実装等のプロセス。
47 本項ではソフトウェアの開発請負を想定しており、ハードウェア等の売買は第１項参照。
48 第２９条『…納入物についてシステム仕様書との不一致（以下本条において「瑕疵」という。
）が発見された場合…』

164

付録③︓ベンダのプロジェクトマネジメント義務・ユーザの協⼒義務に関する裁判例の概要■東京地裁平成 16 年 3 月 10 日判決○ベンダのプロジェクトマネジメント責任
ベンダは、納入期限までに本件電算システムを完成させるように、本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処すべき義務を負うものと解すべきである。
そして、システム開発は注文者と打合せを重ねて、その意向を踏まえながら行うものであるから、被告は、注文者であるユーザのシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないようユー
ザに働きかける義務を負っていたというべきである。
○ユーザの協力義務
本件電算システム開発契約は、いわゆるオーダーメイドのシステム開発契約であるところ、このよ
うなオーダーメイドのシステム開発契約では、受託者（ベンダ）のみではシステムを完成させることはできないのであって、委託者（ユーザ）が開発過程において、内部の意見調整を的確に行って見解を統一した上、どのような機能を要望するのかを明確に受託者に伝え、受託者とともに、要望する機能について検討して、最終的に機能を決定し、さらに、画面や帳票を決定し、成果物の検収をするな
どの役割を分担することが必要である。
そして、本件電算システム開発契約の契約書は、4 条 1 項において、「ベンダは、ユーザに対し、委託業務の遂行に必要な資料、情報、機器等の提供を申し入れることができる。資料等の提供の時期、方法等については、ユーザとベンダが協議して定める。」旨定め、5 条において、「ユーザの協力義務」
として、「ベンダは、4 条に定めるほか、委託業務の遂行にユーザの協力が必要な場合、ユーザに対し協力を求めることができる。この協力の時期、方法等については、ユーザとベンダが協議して定める。」
旨定めており、ユーザが協力義務を負う旨を明記している。
したがって、ユーザは、本件電算システムの開発過程において、資料等の提供その他本件電算シス
テム開発のために必要な協力をベンダから求められた場合、これに応じて必要な協力を行うべき契約上の義務（協力義務）を負っていたというべきである。
■東京高裁平成 25 年 9 月 26 日判決○ベンダのプロジェクトマネジメント責任・企画・提案段階
ベンダとしては、企画・提案段階においても、自ら提案するシステムの機能、ユーザのニーズに対する充足度、システムの開発手法、受注後の開発体制等を検討・検証し、そこから想定されるリスクについて、ユーザに説明する義務があるというべきである。このようなベンダの検証、説明等に関する義務は、契約締結に向けた交渉過程における信義則に基づく不法行為法上の義務として位置づけられ、控訴人はベンダとしてかかる義務（この段階におけるプロジェクトマネジメントに関する義務）を負うものといえる。
もっとも、ベンダは、システム開発の対象となるユーザの業務内容等に必ずしも精通しているもの
165

ではない。そのため、プロジェクトが開始され、その後の進行過程で生じてくる事情、要因等について、企画・提案段階において漏れなく予測することはもとより困難であり、この段階における検証、説明等に関する義務も、このような状況における予測可能性を前提とするものである…ユーザにもシステム開発の対象とされる業務の分析とベンダの説明を踏まえ、システム開発について自らリスク分
析をすることが求められるものというべきである。
このようなことからすると、企画・提案段階におけるシステム開発構想等は、プロジェクト遂行過程において得られるであろう情報、その過程で直面するであろう事態等に応じて、一定の修正等があることを当然に想定するものといえ、企画・提案段階の計画どおりシステム開発が進行しないこと等をもって、直ちに企画・提案段階におけるベンダのプロジェクトマネジメントに関する義務違反があったということはできない。
・システム開発段階
控訴人は、前記各契約に基づき、本件システム開発を担うベンダとして、被控訴人に対し、本件システム開発過程において、適宜得られた情報を集約・分析して、ベンダとして通常求められる専門的知見を用いてシステム構築を進め、ユーザである被控訴人に必要な説明を行い、その了解を得ながら、適宜必要とされる修正、調整等を行いつつ、本件システム完成に向けた作業を行うこと（プロジェク
ト・マネジメント）を適切に行うべき義務を負うものというべきである。
すなわち、システム開発は必ずしも当初の想定どおり進むとは限らず、当初の想定とは異なる要因が生じる等の状況の変化が明らかとなり、想定していた開発費用、開発スコープ、開発期間等について相当程度の修正を要すること、更にはその修正内容がユーザの開発目的等に照らして許容限度を超える事態が生じることもあるから、ベンダとしては、そのような局面に応じて、ユーザのシステム開発に伴うメリット、リスク等を考慮し、適時適切に、開発状況の分析、開発計画の変更の要否とその内容、更には開発計画の中止の要否とその影響等についても説明することが求められ、そのような説
明義務を負うものというべきである。（中略）これらに照らすと、控訴人は、被控訴人と本件最終合意を締結し、本件システム開発を推進する方
針を選択する以上、被控訴人に対し、ベンダとしての知識・経験、本件システムに関する状況の分析等に基づき、開発費用、開発スコープ及び開発期間のいずれか、あるいはその全部を抜本的に見直す必要があることについて説明し、適切な見直しを行わなければ、本件システム開発を進めることができないこと、その結果、従来の投入費用、更には今後の費用が無駄になることがあることを具体的に説明し、ユーザである被控訴人の適切な判断を促す義務があったというべきである。また、本件最終合意は、前記のような局面において締結されたものであるから、控訴人は、ベンダとして、この段階以降の本件システム開発の推進を図り、開発進行上の危機を回避するための適時適切な説明と提言をし、仮に回避し得ない場合には本件システム開発の中止をも提言する義務があったというべきである。
（中略）
本件システム開発においては、少なくとも、本件最終合意を締結する段階において、本件システムの抜本的な変更、又は、中止を含めた説明、提言及び具体的リスクの告知をしているとは認めがたいから、控訴人に義務違反（プロジェクトマネジメントに関する義務違反）が認められるというべきである。しかし、ベンダとして果たすべきプロジェクトマネジメントに関する義務違反につき、故意、あるいは故意と同視されるような重過失の程度のものがあったということはできない。控訴人の義務違反は、それに至らない過失の程度のものにとどまるというべきである。

166

■東京高裁平成 26 年 1 月 15 日判決○ユーザの協力義務
ユーザは、顧客であって、システム開発等についての専門的知見を備えているとは認められないのに対し、ベンダは、システム開発等の専門的知見や経験を備えた専門業者であって、本件新基幹シス
テムに多数の不具合・障害という瑕疵を発生させたのはベンダであることが認められる。外部設計後に多数の変更を行えば、本件新基幹システムにおける不具合・障害の発生の可能性を増加させ、その検収完了が遅延するおそれが生じ得ることに照らせば、ユーザがベンダに対し本件新基幹システムについて多数の変更を申し入れたことは、本件ソフトウェア開発個別契約の目的を達成できなくなった
原因の一つであると認められ、その点においてユーザに過失のあることを否定できない。
○ベンダのプロジェクトマネジメント責任
しかし、本件ソフトウェア開発個別契約においては、ユーザからベンダに対して仕様書等の変更の申入れがあった場合、その申入れから 14 日以内に、ユーザ及びベンダは変更の内容及びその可否につき協議を行い、変更の可否につき決定するものと約定されており、その期間に協議が調わない場合、ベンダは、従前の仕様書等に基づき本件業務を遂行するものし、控訴人はこれを了承する旨が約定されていることからすれば、ベンダは、ユーザの変更申入れを応諾する契約上の義務を負わず、契約上これを拒絶することができる。そして、ユーザがシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対しベンダは、システム開発等の専門的知見や経験を備えた専門業者であって、ユーザからの変更の申入れに応じることが、本件新基幹システムにおける不具合・障害の発生の可能性を増加させ、そのために検収終了時期を大幅に遅延させ、本件ソフトウェア開発個別
契約の目的を達成できなくなる場合においては、本件プロジェクトの業務委託基本契約に基づく善管
注意義務及び本件ソフトウェア開発個別契約における付随的義務として、その専門的知見、経験に照らして、これを予見した上、ユーザに対し、これを告知して説明すべき義務を負うものであって、なお、ユーザが変更を求めるときは、これを拒絶する契約上の義務があると認められるのである。そして、ベンダにおいて、これを予見することが困難であったとは認められないのであって、ベンダのこのような義務違反がユーザの上記過失の一因となっていることが否定できないのである。（中略）しかし、ユーザがシステム開発等についての専門的知見を備えているとは認められない顧客であるのに対し、ベンダは、システム開発等の専門的知見や経験を備えた専門業者であって、ユーザの上記
データ移行作業の不適切さが、本件新基幹システムにおける不具合・障害の発生の可能性を増加させ、そのためにその検収終了時期を大幅に遅延させ、本件ソフトウェア開発個別契約の目的を達成できな
くなる場合においては、本件プロジェクトの業務委託基本契約に基づく善管注意義務及び本件ソフト
ウェア開発個別契約における付随的義務として、その専門的知見、経験に照らし、これを予見した上、このような事態を回避するために、ユーザに告知し、ユーザのデータ移行作業に特段の対応が必要であるというのであれば、その旨の指摘・指導をすべき義務を負うと認められる。そして、ベンダにおいて、これを予見することが困難であったとは認められないのであって、ベンダのこのような義務違反がユーザの上記過失の一因となっていることが否定できないのである。
■東京地裁平成 28 年 4 月 28 日判決○ベンダのプロジェクトマネジメント責任
ベンダは、自らが有する専門的知識と経験に基づき、本件システム開発に係る契約の付随義務として、具体的には、被告は、原告における意思決定が必要な事項や解決すべき必要がある懸案事項等の167

発生の徴候が認められた場合には、それが本格的なものとなる前に、その予防や回避について具体的に原告に対して注意喚起をすべきであるし、懸案事項等が発生した場合は、それに対する具体的な対応策及びその実行期限を示し、対応がされない場合に生ずる支障、複数の選択肢から一つを選択すべ
き場合には、対応策の容易性などそれらの利害得失等を示した上で、必要な時期までに原告において対応することができるように導き、また、原告がシステム機能の追加や変更の要求等をした場合、当該要求が委託料や納入期限、他の機能の内容等に影響を及ぼすときには原告に対して適時にその利害得失等を具体的に説明し、要求の撤回、追加の委託料の負担や納入期限の延期等をも含め適切な判断をすることができるように配慮すべき義務を負っていたということができる。
（結論として、権限設定及び仕様自体の不適合に関するベンダの付随義務違反を肯定、プログラムの品質の問題に関するベンダの付随義務違反を否定。）■札幌高裁平成 29 年 8 月 31 日判決○ベンダのプロジェクトマネジメント責任…以後は、新たな機能の開発要望はもちろん、画面や帳票、操作性に関わるものも含め、一切の追加開発要望を出さないという合意（本件仕様凍結合意）を取り付けたものである。このように、ベンダは、プロジェクトマネジメント義務の履行として、追加開発要望に応じた場合は納期を守ることができないことを明らかにした上で、追加開発要望の拒否（本件仕様凍結合意）を含めた然るべき対応をしたものと認められる。これを越えて、ベンダにおいて、納期を守るためには更なる追加開発要望をしないようユーザを説得したり、ユーザによる不当な追加開発要望を毅然と拒否したりする義務があったということはできず、ベンダにプロジェクトマネジメント義務の違反があったとは認められない。
○ユーザの協力義務
システム開発はベンダの努力のみによってなし得るものではなく、ユーザの協力が必要不可欠であって、ユーザも、ベンダによる本件システム開発に協力すべき義務を負う。そして、この協力義務
は、本件契約上ユーザの責任とされていたもの（マスタの抽出作業など）を円滑に行うというような作為義務はもちろん、本件契約及び本件仕様凍結合意に反して大量の追加開発要望を出し、ベンダにその対応を強いることによって本件システム開発を妨害しないというような不作為義務も含まれているものというべきである。
■東京高裁平成 30 年 3 月 28 日判決○ベンダのプロジェクトマネジメント責任・ユーザの協力義務
ベンダは、納入期限までにシステムを完成させるように、契約書等において提示した開発手順や開発手法、作業工程等に従って開発作業を進めるとともに、常に進捗状況を管理し、開発作業を阻害する要因の発見に努め、これに適切に対処し、かつ、ユーザのシステム開発へのかかわりについても、適切に管理し、システム開発について専門的知識を有しないユーザによって開発作業を阻害する行為がされることのないよう注文者に働きかける義務を負い、他方、ユーザは、システムの開発過程において、資料等の提供その他システム開発のために必要な協力をベンダから求められた場合、これに応じて必要な協力を行うべき契約上の義務（協力義務）を負っているというべきである。

168

付録④︓個別契約書のサンプル
準委任型
契約番号：○○○○[要件定義作成支援業務]個別契約書
甲及び乙は、甲乙間で締結した○○○○年○○月○○日付「ソフトウェア開発委託基本契約書」第○○○号にもとづき、基本契約書記載の本件ソフトウェアに関する[要件定義作成支援業務]につき、以下の条件に従って甲が乙に委託し、乙がこれを受託することについて合意したので、本個別契約を締結する。
1. 作業内容：○○○○年○○月○○日付[「○○○○システム提案書」]にもとづく[要件定義作成
支援業務]
2. 契約類型： 準委任
3. 作業期間又は作業工数（作業量）：
年 月 日から年 月 日まで（又は「○○人月」）
4. 作業スケジュール： 添付別表○記載のとおり
5. 作業範囲の明細及び甲・乙の役割分担： 添付別表○記載のとおり
6. 作業環境： （作業場所）東京都○○区○○町 1-1-1 甲本社事務所内（使用条件）甲は上記作業場所を甲に無償で提供する。
7. 甲が乙に提供する資料等： 添付別表○記載のとおり
8. 連絡協議会の運営： （会議の名称）[要件定義検討]会（開催頻度）週○回
9. 委託料： ￥○○,○○○,○○○‐（税別）
10. 支払方法： ○○○○年○○月○○日までに前項の委託料及びこれに係る消費税等を乙の指定する銀行口座への振込みにより支払う。
11. 検査又は確認事項：①[要件定義書]の点検期間： 作成完了後○営業日以内②[要件定義作成]支援業務終了の確認期間： 業務終了報告書受領後○営業日以内③その他：
12. その他の条件：□甲・乙の体制図： 添付別表○記載のとおり□甲によるプロジェクトマネジメントに、乙が協力をする場合の条件：
添付別表○記載の通り□その他の条件
本個別契約締結の証として、本書２通を作成し、甲乙記名押印のうえ各１通を保有する。
年

月

（甲）
○○○○株式会社
情報システム部長○ ○ ○ ○

日㊞

（乙）株式会社○○○○システム
営業部長○ ○ ○ ○
㊞

169

請負型
契約番号：○○○○[ソフトウェア開発業務]個別契約書
甲及び乙は、甲乙間で締結した○○○○年○○月○○日付「ソフトウェア開発委託基本契約書」第○○○号にもとづき、基本契約書記載の本件ソフトウェアに関する[ソフトウェア開発業務]につき、以下の条件に従って甲が乙に委託し、乙がこれを受託することについて合意したので、本個別契約を締結する。
1. 作業内容：○○○○年○○月○○日付[「○○○○システム仕様書」]にもとづく[ソフトウェア開発業務]
2. 契約類型： 請負
3. 納入物の明細・納期・納入場所： 添付別表○記載のとおり
4. 作業スケジュール： 添付別表○記載のとおり
5. 作業範囲の明細及び甲・乙の役割分担： 添付別表○記載のとおり
6. 作業環境： （作業場所）東京都○○区○○町 1-1-1 乙本社事務所内
7. 甲が乙に提供する資料等： 添付別表○記載のとおり
8. 連絡協議会の運営に関する事項： （会議の名称）進捗報告会（開催頻度）週○回
9. 委託料： ￥○○,○○○,○○○‐（税別）
10. 支払方法： ○○○○年○○月○○日までに前項の委託料及びこれに係る消費税等を乙の指定する銀行口座への振込みにより支払う。
11. 検査又は確認に関する事項：①[本件ソフトウェアの検査期間]： 納入後○営業日以内②その他の事項
12. その他の条件：□甲・乙の体制図： 添付別表○のとおり□検査仕様書点検期間： 受領後○営業日以内□納入物の所有権の移転時期： 第 10 項記載の委託料が完済されたとき□甲によるプロジェクトマネジメントに、乙が協力をする場合の条件：
添付別表○記載の通り□その他の条件

本個別契約締結の証として、本書２通を作成し、甲乙記名捺印のうえ各１通を
保有する。
年

月

（甲）
○○○○株式会社
情報システム部長○ ○ ○ ○

日㊞

（乙）株式会社○○○○システム
営業部長○ ○ ○ ○㊞

170

付録⑤︓変更提案書・管理書のサンプル
変更提案書（システム仕様書、検査仕様書、中間資料の変更）（作成者 2 部作成、作成者・受領者１部ずつ保管）
No.
変更提案書
○○○○年○○月○○日付貴社・弊社締結済みの「ソフトウェア開発委託基本契約書」（契約番号：○○○○）の定めに従い、以下のとおり貴社に対し変更の提案を行いますので、同契約書第 37 条
（変更管理手続）の定めに従ってご対応をいただきますよう、よろしくお願い致します。
記
１．変更提案書・変更管理書の作成事由□ システム仕様書の変更（第 34 条関係）
□ 検査仕様書の変更（第 27 条関係）
□ 中間資料の変更（第 35 条関係）
□ 上記以外の事項の変更（ただし、未確定事項の確定（第 36 条関係）を除く）
２．変更の内容、理由等（１） 変更の内容（詳細は別紙を添付してもよい）（２） 変更の理由
３．変更提案後の対応（１） 貴社（弊社）からの弊社（貴社）への変更管理書の希望交付期限：○○○○年○○月○○日 受領日から○日以内（２） 希望連絡協議会日程：○○○○年○○月○○日

以貴社（受領者）
受領日○○○○年○○月○○日
（担当者）
部署名：
氏名：
連絡先：
（責任者）
部署名：
氏名：
（印）
連絡先：

上

弊社（作成者）
作成日：○○○○年○○月○○日
（担当者）
部署名：
氏名：
連絡先：
（責任者）
部署名：
氏名：
連絡先：

171

（印）

変更提案書（未確定事項の確定）（作成者 2 部作成、作成者・受領者１部ずつ保管）
No.
変更提案書
○○○○年○○月○○日付貴社・弊社締結済みの「ソフトウェア開発委託基本契約書」（契約番号：○○○○）第 36 条（未確定事項の取扱い）第 1 項第 1 号の定めに従い、貴社に対して、以下のとおり変更提案書の提示を行いますので、同条第 1 項第 2 号及び第 2 項並びに同契約書第 37 条（変更管理手続）の定めに従ってご対応をいただきますよう、よろしくお願い致します。なお、弊社は、未確定事項の確定により請求する追完、修正により委託料、作業期間、納期及びその他の契約条件の変更が必要となる場合、これを受け入れることを約束します。
記
１．未確定事項の概要（１） 未確定事項の内容（２） 未確定事項の確定時期（３） その他必要事項
２．協議結果□ 合意
未確定事項について、以下のとおり合意する。
① 内容（）② 未確定事項の確定時期（）□ 協議不調
今後の予定は以下のとおり。
（）
３．未確定事項の確定（追完、修正の請求は第 37 条の定めに従って行うこと）
・確定内容
（
）
・確定した要件定義書、外部設計書の追完、修正の請求 要・不要
以 上
貴社（受領者：乙）弊社（作成者：甲）
＜提示時＞
日 付：
部署名：
氏 名：
（印）
連絡先：
＜合意時＞
＜合意時＞
日 付：
日 付：
部署名：
部署名：
氏 名：
（印）
氏 名：
（印）
連絡先：
連絡先：
＜未確定事項の確定時＞
日 付：
部署名：
氏 名：
（印）
連絡先：

172

変更管理書（システム仕様書、検査仕様書、中間資料の変更、未確定事項の確定）（作成者 2 部作成、作成者・受領者１部ずつ保管）
No.
変更管理書
○○○○年○○月○○日付貴社・弊社締結済みの「ソフトウェア開発委託基本契約書」（契約番号：○○○○）の第 37 条（変更管理手続）の定めに従い、変更管理書を交付しますので、同条の定めに従ってご対応をいただきますよう、よろしくお願い致します。
記
１．変更の内容、理由等① 変更提案書（No. XXXX）（添付のこと）② 変更に係る仕様を含む変更の詳細事項③ 変更のために費用を要する場合はその額④ 協議期間を含めた変更作業のスケジュール⑤ 委託料の支払時期⑥ その他変更が本契約及び個別契約の条件（作業期間又は納期、委託料、契約条項等）に与える影響⑪ ⑦ 協議日程（
日の連絡協議会）
２．協議結果（XXXX 年 XX 月 XX 日 連絡協議会）□ 合意
・仕様の変更について、以下のとおり合意する。

・変更契約の締結要否
要 ・ 否（作業期間又は納期、委託料、契約条件等本契約及び個別契約の条件に影響を及ぼす場合は変更契約を締結のこと）□ 協議不調今後の扱い

協議継続（○日間）

・

協議終了

受領日：

以
弊社（変更提案書受領者・作成者）
作成日：＜協議結果の確認＞
日 付：
部署名：
氏名：
連絡先：

＜協議結果の確認＞
日 付：
部署名：
氏名：
連絡先：

貴社（変更提案書作成者）

（印）

173

（印）

上

ソフトウェア開発モデル契約の解説【2020 年 4 月 1 日施行 改正民法対応版】
2019 年 3 月 31 日
発行

初版 PDF 公開

一般社団法人 電子情報技術産業協会

ソリューションサービス事業委員会〒100-0004 東京都千代田区大手町 1-1-3
TEL 03-5218-1057／FAX 03-5218-1076

禁 無 断 転 載
この解説書の全部又は一部を転載しようとする場合
は、発行者の許可を得て下さい。