Contract

「情報システムの信頼性向上のための取引慣行・契約に関する研究会」

～情報システム・モデル取引・契約書～

（受託開発（一部企画を含む）、保守運用）〈第一版〉

平成１９年４月

経済産業省商務情報政策局情報処理振興課

〈 目 次 〉

１． 総 論

(1) 経 緯	………………	１
(2) 目 的	………………	２
(3) モデル取引・契約書の全体像とポイント	………………	7
(4) モデル契約書の主要条項の論点整理	………………	12
(5) 今後の検討課題及びモデル取引・契約書の活用について	………………	20

２．モデル契約プロセス

(1) モデル契約プロセス	………………	22
(2) フェーズの区切りと各々の概要・ポイント	………………	29
(3) マルチベンダ方式、分割発注に関する注意事項	………………	39
(4) ユーザとベンダの協力の重要性、役割分担	………………	42
(5) プロジェクトマネジメントの重要性	………………	43
(6) 請負と準委任	………………	44

(7)ﾊﾟｯｹｰｼﾞ活用、反復繰り返し型の開発、中小企業ﾕｰｻﾞにおける活用の留意点… 45

(8) ハ ー ド ウ ェ ア 等 x x 契 約 の 留 意 点 51

３．モデル契約書・逐条解説

(1) ソ フ ト ウ ェ ア 開 発 委 託 基 本 モ デ ル 契 約 書 53

(2) ソフトウェア開発委託基本モデル契約書ドキュメントモデル 116

※ドキュメントモデル【参考文書 1】～【参考文書 13】

(3) 仮 発 注 合 意 書 131

(4) 情 報 シ ス テ ム 保 x x 用 委 託 基 本 モ デ ル 契 約 書 134

(5) 個 別 契 約 書 ・ 仕 様 書 サ ン プ ル 152

（別紙１）信頼性向上・取引可視化のための「ﾓﾃﾞﾙ取引・契約書」の全体像… 167

（ 別 紙 ２） 提 案 x x 書 （RFP） の 詳 細 168

（ 別 紙 3） セ キ ュ リ テ ィ 要 求 仕 様 書 サ ン プ ル 178

（ 別 紙 4） 提 案 書 （ プ ロ ポ ー ザ ル ） の 詳 細 196

（ 別 紙 ５） 委 員 名 簿 201

１． 総 論

（1） 経 緯

· 現在、我が国の国民生活及び社会経済活動のＩＴ利用度は、コンピュータの処理性能の飛躍的向上やインターネットの普及等の結果、かつてないほど高まっている。このため、情報システムの障害による業務・サービスの停止や機能低下の社会的影響は、日々、深刻化してきており、システムの信頼性・安全性向上は喫緊の課題となっている。

· 他方、情報システムは企業・組織の経営の根幹に関わり、利用範囲のxx化・多様化が進んだことから、パッケージを中心としたソリューションの導入か受託開発かの違いによらず、ユーザ・ベンダの間の密接なコミュニケーションを前提とした取引の可視化、役割分担・責任関係の明確化が、適切な情報システムの構築に必要不可欠となった。また、いわゆるオープン化・モジュール化の進展により、情報システムは多様なコンポーネントの組み合わせで構築されるようになったため、かつてなかった組み合わせ等に係るリスクも包含するようになっている。そのため、エンジニアリング力の向上を前提としながらも、ユーザ・ベンダ間の取引の可視化・役割分担の明確化等を進めることでユーザ・ベンダ一体となった情報システムの信頼性・安全性向上の取り組みが必要となってきている。

· こうした情報システムの信頼性・安全性の向上のために、経済産業省において「情報システムの信頼性向上に関するガイドライン」（以下「信頼性ガイドライン」という。）を策定・公表1したところである。

· その中で、「商慣行・契約・法的要素に関する事項」として、「契約における重要事項の明確化」、「情報システム構築の分業時の役割分担及び責任関係の明確化」が重要である旨、指摘されている。

· 他方、契約方式の標準化・取引慣行をめぐる問題は、これまでも繰り返し指摘されてきたところ2であるが、（社）情報サービス産業協会（以下「JISA」という。）及び

1 「情報システムの信頼性向上に関するガイドライン」（平成 18 年 6 月 15 日）において、ガイドラインの実効性を担保するための取組みの一つとして、モデル契約の策定・活用（「情報システム利用者団体・情報システム供給者団体は、本ガイドラインの考え方を反映した標準的な契約のあり方を検討、それらを最大限尊重した契約を締結する。」）を挙げている。

（xxxx://xxx.xxxx.xx.xx/xxxxx/00000000000/00000000000.xxxx）

2 「ソフトウェア新時代（産業構造審議会情報産業部会）」（平成 5 年 2 月）において「取引に関する全ての協議事項を契約書に盛り込むこと」、「知的財産権・損害賠償・瑕疵担保責任の扱い、仕様変更の行い方等について標準的なルール形成」を提言。「複数段階契約の普及」の有益さを指摘。「ソフトウェアの適正な取引を目指して（産業構造審議会情報産業部会）」（平成 5 年 7 月）において「契約書に盛り込むべき事項」を提案、「カスタム・ソフトウェア開発のための契約書に記載すべき主要事項」（通商産業省告示第 359 号）（平成 5 年 7 月 14 日官報）として告示。「情報サービスにおける財務・会計上の諸問題と対応のあり方について」（平成 17 年 8 月）において情報サービスの「無形」と「変化」という特質から生じる 10 の課題事象をテーマに会計基準で

（社）電子情報技術産業協会（以下「JEITA」という。）においてそれぞれ、ソフトウェア開発モデル契約書を策定・公表しているが、ユーザ団体と共同でつくられたものが存在しない3、オープン化・ウェブ化の進展、モジュール化に伴うマルチベンダ化への対応が十分でないといった課題がある。

· 「情報サービス・ソフトウェア産業維新」（産業構造審議会情報経済分科会 中間のまとめ、平成 18 年 9 月）」においても、「情報システムの価値を決める諸要因（機能・信頼性・システムライフサイクルコスト等）の水準について両者が認識した上での取引がなされずに、事後的に、問題が生じた際等に紛争が生じることが多い」ことを指摘し、「ユーザ・ベンダ間の取引関係・役割分担の可視化」を提言している。

· また、取引の可視化は、2008 年 4 月以降開始する年度から適用される、いわゆる

「日本版 SOX 法」（金融商品取引法4）における内部統制の評価・監査においても求められる事項である。xxx・xxx双方にとって、これまで不透明性の高さが指摘されてきた情報システムに係る取引の可視化の向上は、こうした観点からも必要とされている。

· こうしたことを背景として、経済産業省においては、情報システムの信頼性向上のための取引慣行・契約に関する研究会及びタスクフォース（以下「研究会」という。）を設置し、情報システムの信頼性向上・取引の可視化に向けた取引・契約のあり方の検討を行ってきた。

· 本まとめは、研究会における情報システムの信頼性向上・取引の可視化に向けた取引・契約のあり方等の議論及びパブリックコメント（平成 19 年 1 月実施）を集約し、

「情報システム・モデル取引・契約書」として提示したものである。

（2） 目 的

研究会の目的は以下のとおりである。

（モデル取引・契約書の策定）

· 信頼性ガイドラインの遵守、取引関係・役割分担の可視化、いわゆる「日本版 SOX法」への対応、オープン化・モジュール化の進展への対応等を基本的な視点として、情報システムの信頼性の向上・取引可視化に資する理想的な取引・契約モデルをめざ

の対応、内部統制での対応、取引慣行・技術的な取り組みによる対応といった視点から課題への対応を提言。（xxxx://xxx.xxxx.xx.xx/xxxxx/00000000000/00000000000.xxxx）

3 なお、JISA、JEITA のモデル契約書は、前述の「ソフトウェアの適正な取引を目指して」並びに「カスタム・ソフトウェア開発のための契約書に記載すべき主要事項」に準拠して作成された。

4 金融庁企業会計審議会において、平成 19 年 2 月に「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の設定について（意見 書）」が公表されている。（xxxx://xxx.xxx.xx.xx/xxxxx/xxxxx_xxxxxx/xxxxx/00000000.xxxx）

す。

· 最終的な成果物として、①モデル契約プロセス、②モデル契約書（企画・開発、保守・運用の各フェーズの基本契約書）、③モデルドキュメントを策定する（以下総称して「モデル取引・契約書」という。）。

· なお、研究会におけるモデル取引・契約書の活用にあたっては、以下のことに留意する必要がある。

① 本研究会においては、一定の前提条件（「１．（３）モデル取引・契約書の対象範囲」にて後述）をもとに議論を行い、xxxとベンダのあるべき理想的なモデルを提示したものである。

本モデルは、情報システムのライフサイクルプロセスの中で、ユーザとベンダの間でどのようなことを決定し、どのようなことを情報共有すればよいか、についてのガイドを目指したものである。

各企業等において契約を締結する際には、多様なサービス形態・個々の企業の状況等に即して、本モデルの全部又は一部を活用して検討することが望ましい。

② ＩＴシステムが、社会インフラやユーザ企業の競争力の源泉として、その重要性を増していく中で、ユーザ自らがその責任において、ＩＴシステム化する自らの業務要件を確定する必要があるが、情報システム部門を持たないユーザ企業もあるなど、ユーザのＩＴリテラシーには格差があるのが実態である。

ユーザの発注者としての能力を高めることも必要であるが、ＩＴ業界全体のコンサルティング力（提案内容の可視化、価格構造の明確化等）やエンジニアリング力（適正なプロジェクト管理・品質管理等）の一層の強化が、ユーザに一定の役割分担を求める上での不可欠の前提である。

（モデル契約プロセス・ガイドの策定）

・ ユーザ・ベンダの双方のプラットフォームとなるように、デューデリジェンス（実態把握）の実施から、契約締結（企画・開発、保守・運用）、変更管理手続（仕様変更・契約変更）に至るまでの取引ルールについて、国際的な取引慣行との整合性に留意しながらプロセスモデルを策定した。

・ 見積り時期とリスクとの関係5を踏まえて、ユーザ・ベンダの双方のリスクアセスメントの機会を確保する観点から、多段階契約（工程ごとに個別契約を締結する。）と再見積り（曖昧さがある段階の見積りを、要件が明確になった段階で見積りなお

5 見積りにかかわるリスクについては、「ソフトウェア開発見積りガイドブック～ＩＴユーザとベンダにおける定量的見積りの実現～」（IPA-SEC）を参照のこと。

す。）の考え方を採用した6。

（モデル契約書の策定・逐条解説）

· 情報システム特有の性質、取引慣行については、これまでも指摘されてきたような以下のような課題がある。これら課題を考慮し、契約書において決定すべき事項やそれを承認・変更する手続的事項を詳細に示すことで、ユーザ・ベンダ双方のシステムライフサイクルにおけるリスクを低減させるための情報システム取引のガイド的な性格を取り込んでいる。

· なお、個別の交渉において決めるべき事項については、ユーザ、ベンダ双方の立場がわかるように、考慮すべき要素を提示した上で複数の選択肢を逐条解説等において明記した。

① 情報システム特有の性質

・ 一般の委託契約との違い7

情報システムの開発に関する委託契約では、作成すべき成果物など仕事の内容が明確となっている請負契約の場合とは異なり、ベンダによる情報処理に関する技術及び知識の提供あるいはこれらの技術及び知識に基づいて成果物を作成する前提として、ユーザによる機能要件8・非機能要件9の早期かつ明確な確定が不可欠である。また、ユーザ・ベンダの役割分担を、システムライフサイクルプロセスに応じて、詳細に決定しておくことが必要である。

そのため、まずモデル取引・契約書の策定にあたっては、現在改訂中の共通フレーム 200710による標準化されたシステム企画・要件定義段階、開発段階、運用段

6 なお、多段階契約と再見積りによる場合、契約単位のみならず情報システムの完成までの全体工程及び予算の管理が重要となることに留意が必要である。

7 請負と準委任の法的性質等については、２．（６）にて後述。

8 ユーザの要求を満足するために、ソフトウェアが実現しなければならない機能に係る要件。システム機能及びデータにより定義される。〈例〉システム機能：業務フロー、業務処理定義、システム機能（階層、体系等）等。データ：データ構造（階層、関係等）、データ項目定義等。

9 機能要件以外のすべての要素に係る要件。業務内容及びソフトウェアの機能と直接的な関連性を有さない品質要件、技術要件、移行要件、運用要件、操作性及び付帯作業等からなり、それぞれに対する目標値及び具体的事項により定義される。（例）品質要件：効率性（平均レスポンスタイム、ピーク時性能等）、信頼性（平均故障間隔、平均復旧時間等）、保守性（解析、変更等）、操作性（処理時間、処理容易性、操作理解性など）、セキュリティ要件等。技術要件：実現方式

（処理方式、通信プロトコル等）、システム構成（ネットワーク構成、ソフトウェア構成、ハードウェア構成等）、開発方式（開発言語等）等。移行要件：移行対象業務、移行対象データ、移行時期、移行体制等。運用要件：運用体制、運用形態、運用スケジュール、運用管理方式（監視、バックアップ等）、災害対策等。付帯作業：ハードウェア展開、ソフトウェア展開、ユーザ教育等。

10 共通フレーム 2007 は、現在改訂作業を実施中であり、ドラフト版を 2007 年度前半に、正式

階、保守段階の定義によるものとした。

その上で、モデル契約書の契約類型のモデルを示した。

また、作業内容レベルでユーザとベンダの果たすべき役割分担を明確化するために、これら役割分担を基本契約書において定めるべき事項とした。なお、保守・運用段階においては、個々の業務内容に応じた役割分担例を示した。

・ 超上流11工程の重要性

情報システムの要求品質を確保するためには、開発フェーズに入る前の超上流工程において、ユーザ内の役割分担（経営層、業務部門、情報システム部門）のもとに、ユーザが情報システムに求める要件（機能要件、非機能要件）を明確に定義する責任がある。

そのため、本モデル契約書においては、超上流工程の重要性を明らかにするために、「要件定義」を契約書のなかで独立したフェーズとし、契約類型を準委任型とした12。

② 取 引 慣 行

・ 契約締結前の開発作業の着手

情報システムの構築において、契約が締結される前に開発作業に着手する例が少なくないことが指摘された。覚書を交わしていても費用負担の取決めがない場合や、口頭での発注に基づいて作業を行う場合など、リスクへの認識が不十分なまま開発を続けていると、本契約の締結に至る前にトラブルに発展するケースもある。また、そうしたプロジェクトが成功する確率は低いことも指摘された。

そのため、本モデル契約書の全部又は一部を活用することで、契約手続が円滑にかつ早期に完了することが望まれる。なお、逐条解説において各条項を設ける必要性、複数の選択肢がある場合はそれぞれが依拠する考え方を敷衍しており、契約当事者による具体的な取引形態の状況に応じた選択を可能とした。（主要条項

版を 2007 年度後半に公開予定である。

11 「超上流」（「システム化の方向性」、「システム化計画」、「要件定義」）工程の重要性、ユーザ・ベンダの役割分担等については、「経営者が参画する要求品質の確保」を参照のこと。なお、共通フレーム 2007 において「超上流」工程は、「企画プロセス」及び「要件定義プロセス」に位置づけられる予定である。

12 実際の契約において、準委任型とするか、請負型とするかは、成果物の特定についての当事者同士の経験や役割分担の遂行能力等に基づき、成果物についての共通理解が事前に十分に成立しているかによるが、準委任型としなかった場合、ユーザ自身のシステム化計画や要件定義におけるステークホルダとの調整を行う責任等が曖昧になる傾向にある。その結果、ユーザの対応不足を補完するために、ベンダが、ユーザ内のステークホルダとのコンタクトを取り始め、さらにユーザの自律的な調整機能が発揮されずに、要件定義上の見落としも生じやすくなるとの指摘が多い。

の論点整理については後述）

また、オープン化・ウェブ化の進展に伴い、情報システム取引におけるマルチベンダ形態、フェーズ毎の分割発注に対応する規定を設けた。

なお、激変するビジネス環境に対応するため、正式な契約書を締結しないままに、情報システム構築が開始されるやむを得ない場合の措置として、仮発注合意書（Letter Of Intent：LOI）のモデルを策定しているが、契約内容について基本的に合意に達したものの詳細まで含めた最終合意には達しておらず、契約締結手続等形式的手続に時間を要する場合など、極めて限られた場合にのみ使用すべきものであり、仮発注合意書のプロセスを設けることを推奨するものではない。本来的には、正式な契約書を締結し業務を開始することが基本のプロセスである。

・ 契約書の内容の不十分さ

契約書において、合意事項を明示することは当然であるが、情報サービスにおいては「無形」のソフトウェアを取引対象とし、かつ、仕様が「変化」する特質をもつため、取引の開始にあたっての合意事項や未決事項、情報システム構築中における合意事項の変化（仕様の変更・詳細化・追加の判断など）、想定外事項の発生の取扱い等13について、多くの場合が「本契約書に記載なき事項は、契約当事者は双方誠意を持って協議を行う」というxxに依拠し、契約書の記載事項としては、不十分かつ曖昧さを残したままで締結されていることが非常に問題であることが指摘された。

そのため、研究会においては、我が国で取り交わされている契約書における問題点の整理、海外・オフショア開発における契約書を参考にした上で、情報システムの価値を決める諸要因の水準について、両者が同一の認識の上で取引が行われるように、あらかじめ契約内容に定めるべき事項、役割分担の規定を詳細に盛り込むとともに、仕様変更等についての変更管理手続を導入した。

（モデルドキュメントの例示）

· 上記のモデル契約書に添付される関連ドキュメントについて、ユーザ・ベンダ双方が、契約締結時点において具体的なイメージを認識し、各工程で実際にどんなことを決めなければならないか、イメージを共有できるように可能な限り詳細なドキュメントを例示した14。

13 外部設計から内部設計にかけてのいわゆる仕様の「深化」「詳細化」に伴い、外部設計の想定していた機能の枝葉や前提条件が変動し、大幅な工数増につながることもある。

14 IPA/SEC において、各工程において作成するドキュメントサンプル、フォーム（様式）、各社の資料（開発工程・標準書・会議体・プロジェクトの運用）など多彩なドキュメントのダウンロ

· また、国際的な取引慣行を参考に、デューデリジェンスのための標準的な RFI／RFPを策定できるように、具体的な記載事項、ユーザ内の役割分担（業務部門・ＩＴ部門）を明示した。

· こうした取引全般におけるドキュメントをモデルとして添付、解説を加えることにより、モデル契約プロセス及びモデル契約書が実用性に資するように考慮した。

（3）モデル取引・契約書の全体像とポイント

（モデル取引・契約書の対象範囲）

・契約当事者：対等に交渉力のあるxxx・xxxを想定

(例) 委託者（ユーザ）：民間大手企業、受託者（ベンダ）：情報サービス企業

＊中小企業ユーザとの取引・契約に活用する場合は、｢2.(7)パッケージ活用、反復繰り返し型の開発、中小企業ユーザにおける活用の留意点｣を参照。

・開発モデル：ウォーターフォールモデル15

＊反復繰り返し型の開発を実施する場合は、｢2.(7)パッケージ活用、反復繰り返し型の開発、中小企業ユーザにおける活用の留意点｣を参照。

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

保守・運用

＊パッケージのカスタマイズを前提とした開発契約に活用する場合は、｢2.(7)パッケージ活用、反復繰り返し型の開発、中小企業ユーザにおける活用の留意点｣を参照。

・プロセス：共通フレーム 2007（現在改訂中）による標準化されたシステムの企画・

要件定義段階、開発段階、運用段階、保守段階による

・一括発注の場合に加え、マルチベンダ形態、工程分割発注に対応

研究会におけるモデル取引・契約書の策定にあたっては、以下のような前提条件をおいている。

（モデル取引・契約書の全体像）

研究会において策定したモデル取引・契約書の全体像は別紙 1 のとおりである。

ードが可能な「事例検索システム」を提供している。

（xxxxx://xxx.xxx.xx.xx/xxxxxxxxxx/xxxxx.xxx）

15 モデル契約書（開発）では、完全に前工程への手戻りを否定するものではなく、変更管理手続を通じて、情報システムの信頼性確保に必要な手戻りと応分の負担について協議するプロセスを設けたところに特長がある。すなわち、第 36 条（未確定事項の取扱い）においてシステム仕様書を追完又は修正できるものとし、また契約書における役割分担（第 4 条・第 8 条関係）の明確化、同役割分担にユーザのレビュー項目を設けるなど、ウォーターフォールモデルの適用に工夫を加えている。なお、（社）日本情報システム・ユーザー協会（以下、JUAS）では、ウォーターフォール法とイテレーション法のメリットを取り込んだＵ字型開発法を提唱している。（「システム・リファレンス・マニュアル」（IPA-JUAS）を参照）。

16 「信頼性ガイドライン」の分類である(A)重要インフラ等システム、(B)企業基幹システムを対象としている。

（モデル取引・契約書のポイント）

研究会において策定したモデル取引・契約書の特長は以下のとおりである。

・ ソフトウェアの企画・開発フェーズのみならず、情報システムの保守・運用を含めた基本契約書のモデルを示した。

これまで各業界団体等において、「ソフトウェア開発モデル契約」を作成していたが、保守・運用フェーズにおけるモデルは存在していなかった。なお、保守・運用においては、多様なサービス形態が存在するため、全てのパターンを網羅した一律的な雛形を作成することができないため、情報システム保守運用委託基本モデル契約書においては、各サービスモデルに共通的な事項についてのみ示し、仕様書のサンプルを示した。

（ 参 考 ）

本モデル取引・契約書と、これまでのソフトウェア開発モデル契約におけるフェーズの分け方と契約類型の違いをまとめると、下図のとおりである。

・ 上流工程におけるシステム化実現のための仕様の曖昧さが、下流工程の混乱を招きシステムの品質の低下、開発遅延等の重大な結果を生じさせる。このような事態を回避するため、また、研究会における検討対象が主として社会あるいは事業経営に大きな影響を与えるシステムであることも鑑み、要件定義工程を含めた超上流工程は、ユーザが責任を負うべきフェーズであることを明確にした17。

共通フレーム （基本プロセス群）	取引・契約モデルにおけるフェーズ分け	モデル契約書雛形における個別業務と契約類型		（ＪＩＳＡ）ソフトウェア開発委託モデル契約 （平成６年１２月）	（ＪＥＩＴＡ）ソフトウェア開発モデル契約 （平成６年７月）
１．４ 企画プロセス	システム化の方向性 システム化計画	（対象外）		企画支援業務 【準委任型】	（対象外）
１．５ 要件定義 プロセス	要件定義	ソフトウェア開発委託基本モデル契約書	要件定義作成支援業務 【準委任型】	基本設計業務 【請負型】	要件定義・設計サービス 【準委任型】【請負型】の選択
１．６ 開発プロセス	システム設計（システム外部設計）		外部設計書作成（支援）業務 【準委任型】【請負型】の選択
	システム方式設計（システム内部設計） ソフトウェア設計 プログラミング ソフトウェアテスト システム結合		ソフトウェア開発業務 ＊ハードウェア等の調達の留意点は別途整理。 【請負型】
				ソフトウェア作成業務 【請負型】	構築サービス 【請負型】
	システムテスト		【準委任型】【請負型】の選択
	導入・受入支援		ソフトウェア運用準備・移行支援業務 【準委任型】	移行・運用準備支援業務 【準委任型】	移行・運用準備支援業務 【準委任型】
１．７ 運用プロセス	運用テスト
	運用	情報システム保守運用委託基本モデル契約書	システム運用業務システム保守業務	（対象外）	（対象外）
１．８ 保守プロセス	保守			（対象外）	（対象外）

17 要件定義工程を含めた超上流工程での重要な課題は、ユーザの IT システムに対するニーズすなわち業務要件を確定することである。

・ 基本契約において、共通フレームに準拠した各工程の作業内容レベルまで分解したユーザ・ベンダの役割分担を示し、個別契約においてその詳細を定めることとした。

（例）作業責任分担表（第 4 条・第 8 条関係）のサンプル

・ 外部設計工程終了までに合意した仕様18の変更（仕様の変更・詳細化・追加の判断など）、開発プロセスの進展に伴う未決事項の確定、あるいは当初想定がない事項が発生したケース等について、口頭での合意による曖昧さを排除し、その必要性、スケジュール・費用への影響をユーザ・ベンダ双方が協議するプロセスとして、詳細な変更管理手続を導入した。

（例）第 37 条（変更管理手続）、第 34 条（システム仕様書等の変更）、

第 35 条（中間資料のユーザによる承認）、第 36 条（未確定事項の取扱い）

多段階契約（例）

・ 開発段階において、前工程の遂行の結果、後工程の見積前提条件に影響が生じた場合に、各工程の開始のタイミングで、再度見積りを可能とするために、工程毎に委託料を個別契約書において定める多段階契約と再見積りのプロセスモデルを採用した。

（ソフトウェア開発委託基本モデル契約書）

システム化

の方向性

システム化

計 画

ソフトウェア設計

要件定義

外部

設計

内部

設計

ソフトウェアテス

プログラミング

ト

…

契約

個別契約

個別契約

個別契約

コ ン サ ル 契 約 要 件 定 義 契 約

【 準 委 任 】 【 準 委 任 】

外部設計契約

【準委任】または【請負型】

ソフトウェア開発契約

【請負型】

情報システム開発の見積精度

試算

概算

確定

追加・再見積

＊ 上記の例では、「システム化の方向性～システム化計画」「要件定義」「外部設計」「内部設計

以降」を別々の契約として締結する場合を示している。契約のタイミングは、情報システムの性質・規模によって任意に設定することができるが、いわゆる「超上流」工程では、例えば、BPR（business process re-engineering）による組織やビジネスモデルを再構築しながら、ＩＴ化すべき業務範囲・内容を検討している場合など、最終的な成果物の完成状態が明確に定義しづらい場合が多く、ユーザ・ベンダ間の役割分担の合意が取りづらい。そのような場合、契約作業の手間は増大するが、多段階契約を採用することで、開発途中で発生する仕様変更の影響を極力抑えることができる。また、工程ごとに異なるベンダに分割発注することも可能と

なる。

多段階契約（例）

18 例えば、要件定義工程における業務システム要件などの仕様、外部設計工程におけるユーザインターフェース設計などの仕様、ユーザの検査の合否の判断基準となる検査仕様書など。

・ マルチベンダ形態19において、情報システムの全体統合リスクは、最終的にユーザ側が負うべきものであることを明確にした。なお、ユーザの全体統合リスクを軽減する方策として、ユーザの全体管理、調整業務を事業者に委託することによって確保することができる。但し、当該業務の契約形態は準委任契約とすべきである。

（例）第 13 条（プロジェクトマネジメントの責任）

・ 異なるベンダによる工程分割発注方式20において、受託ベンダが前工程のアウトプットを精査して受注することが望ましいが、現実的には、時間的制限等から完全な精査を事前に行うことは困難であることが多い。この場合、前提となる知識の不足を補うため、受託後に、当該アウトプットの十分なレビュー期間を設けて、必要な場合には補正を行うことも必要となる。

そこで、前工程と後工程の責任の切り分け手続き規定、ベンダからの契約解除

（中止）規定等を設けた。

（例）要件定義書の精査・修正、変更の協議不調に伴う契約終了

・ 情報システムの信頼性・安全性を確保21するためには、機能要件及び非機能要件の取込と文書化、事後的に発生するセキュリティ問題の予測的評価と保守・運用体制・コストの想定、システムの中核となるアーキテクチャの選択や接続されるクライアント環境等の内部・外部環境評価等が重要である。

そのため、RFP に記載すべき項目として、機能要件だけでなく、非機能要件も明示するとともに、モデル契約書において、セキュリティ対策に関する規定を設けた22。なお、ユーザが調達に際して作成するセキュリティ要求仕様書の記載事項等

19 大規模システムでは、構成する複数のシステムを異なるベンダがそれぞれ分担する形態で開 発するマルチベンダ形態となることがある（例えば、複数のベンダが相互に連携するシステムを 並行して開発をする場合、他ベンダが開発し、既に運用に入っている別システムと連携するシス テムを開発する場合など）。この形態も、①ユーザが単独で、又はコンサルタント等の支援を得 て全ベンダをまとめる場合と、②一つのプライムベンダが他のベンダをとりまとめる場合がある。

「情報サービス・ソフトウェア産業維新」において提言されているように、「個別機能の内容を明確にユーザ・ベンダ間で認識した上で、これを同一のベンダが包括的に実施すること自体は否定されるものではない。但し、その場合であっても、従来のように各機能の内容を曖昧にした一括請負という形態ではなく、個々の内容を分節化するというプロセスが盛り込まれることが必要」である。

20 工程毎に別契約として発注する場合を指す。

21 システムライフサイクル全般における情報システムの信頼性・安全性の実現に向けた留意事項については、「信頼性ガイドライン」を参照のこと。

22 「政府機関の情報セキュリティ対策のための統一基準（2005 年 12 月 13 日情報セキュリティ政策会議決定）」、「ソフトウェア開発における情報セキュリティ対策実施規程（雛形）（2006 年 2月、内閣官房情報セキュリティセンター）」、「外部委託における情報セキュリティ対策実施規程雛形（2006 年 3 月、同上）」、「機器等の購入における情報セキュリティ対策実施規程雛形（2006年 3 月、同上）」等の関連文書を参照のこと。

（xxxx://xxx.xxxx.xx.xx/xxxxxx/xxxxxxx/xxxxx_xxx.xxxx）

ついては、「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書」（内閣官房情報セキュリティセンター、平成 18 年 6 月）を参考にすること23。

・ 保守・運用段階において要求されるサービス品質の確保を、定量的に可視化することが重要である。ISO/IEC20000・ITIL24においてサービス提供プロセスの一つとして、サービスレベル管理(Service Level Management：SLM)を規定している25。サービスレベル契約(Service Level Agreement：SLA)の導入にあたっては、信頼できる客観的な評価の可能性、評価項目の妥当性／要求水準の達成可能性、時間の経過に沿った見直し、管理に係るコスト（測定方法／監視体制）の合理性等に留意すべきである。

また、契約書においては、サービスレベル達成・不達の結果に対する対応措置

（協議手続、解約権、ペナルティ・ボーナス）、ベンダの報告条件等を定めることが必要である26。

なお、本モデル契約書における構成では、SLA 条項は、ユーザ毎に作成される「仕様書」の中でサンプルとして規定している。

・ 情報システム障害を最低限に抑制するためには、信頼性・安全性向上に向けた ユーザ・ベンダの責務（「信頼性ガイドライン」を参照）に基づき、障害発生時の対応手順・責任関係の明確化27、事業継続計画（Business Continuity Plan：BCP）の策定を行うことが必要である。

23 IPA において、地方公共団体システム調達におけるセキュリティ要件の検討支援ツールを提供しており、企業間取引においても参考にできる。

（xxxx://xxx.xxx.xx.xx/xxxxxxxx/xx00/xxxxxxxxxxx/xxxxxxxx/xx_xxxxxxx_xxx.xxxx）

24 ITIL は、英国 OGC（Office of Government Commerce）が開発した IT サービスに関するベストプラティクスであり、世界的に活用されている。日本では、itSMF Japan(IT Service Management Forum Japan)により普及活動が行われてきた、ITIL においては、サービスレベル管理の基盤として SLA を位置づけている。ITIL をもとに、英国規格 BS15000 がつくられ、さらに、2005 年 12月には ISO/IEC20000 として国際規格になった。ITIL がベストプラクティスであり、プロセスを定義しているのに対し、ISO/IEC20000 はプロセスが組織に導入されているかを判断する。

25 政府調達等における SLA については、「情報システムに係る政府調達への SLA 導入ガイドライン」（経済産業省）、「公共 IT アウトソーシングに関するガイドライン」（総務省）を参照のこと。

26 民間向けの SLA に関するガイドとして、「民間向け IT システムの SLA ガイドライン（第三版）」

（JEITA）がある。

27 障害対応に関する留意事項については、「信頼性ガイドライン」を参照のこと。

（4）モデル契約書の主要条項の論点整理

（フェーズの分類と契約類型……準委任／請負）

・ 本モデル取引・契約書では、情報システムの企画・開発・保守・運用段階の分類と契約類型について、以下のパターンを一つのモデルとして提示する28。

・ 企画段階は、準委任契約とする。企画段階は、ユーザ側の業務要件が具体的に 確定しておらず、ユーザ自身にとってもフェーズの開始時点では成果物が具体的 に想定できないものであるから、ベンダにとっても成果物の内容を具体的に特定 することは通常不可能である。そのため、仕事の完成を目的とし予め成果物のx xが具体的に特定できることを前提とする契約類型である請負には馴染みにくく、準委任が適切と考えられるからである。

・ これに対して、開発段階は実務上、準委任と請負の両方があり得る。請負に馴染むのは、業務に着手する前の段階でベンダにとって成果物の内容が具体的に特定できる場合であるが、内部設計やソフトウェア設計などのフェーズはこうしたことが可能であり、請負で行うことができる。特に論点となっているのは、システム外部設計・内部設計業務29及び当該外部設計の妥当性を検証するシステムテスト業務である。システム外部設計とシステムテスト業務はユーザ側の業務要件に関わる部分が多く、その点では準委任に馴染むが、従来の実務では請負で行われている場合も多い30。

・ 契約類型が注目されるのは、その法的責任の帰着にとどまらず、請負型をとると、ユーザ側の心理として「丸投げ」「ベンダにすべてお任せ」という意識が強くなる点が議論となった（請負と準委任については後述）。

・ あるべき分担モデルとしては、ユーザが、企画段階において業務要件及びシス

28 実際の契約において、準委任型とするか、請負型とするかは、成果物の特定についての当事者同士の経験や役割分担の遂行能力等に基づき、成果物についての共通理解が事前に十分に成立しているかによるため、各企業等において契約を締結する際には、多様なサービス形態・個々の企業の状況等に即して、本モデルの全部又は一部を活用して検討することが望ましい。

29 外部設計は、画面や帳票など、インターフェースを決定する工程。内部設計は、上位レベルのシステム方式を決定する工程。

30 システムテストは、外部設計の仕様どおりに制作されたかを検証する工程である。外部設計書の作成をユーザが主体的に行い、ベンダはその支援業務を準委任で行う場合は、その決定内容を確認するシステムテストの主体もユーザとなることが適切であるとの意見が多くあった。すなわち、システムレベルでは、システム設計（システム外部設計）とシステムテストが、またシステム方式設計（システム内部設計）とシステム結合が対となる。ソフトウェアレベルではソフトウェア設計とソフトウェアテストが対応する（詳細は、２．（２）フェーズの区切りと各々の概要・ポイントを参照のこと）。分業という意味で委託を行う場合、この品質保証の視点では設計とテストが対になることから、水平方向の対を委託範囲（準委任、請負）とした契約類型を考えると論理的である。なお、システムテストは、ユーザのビジネスプロセスを含めたテストにまで及ぶものであることから、請負契約とする場合には、ユーザは、ベンダが実施するテスト仕様（例えば、テスト項目、内容、方法、判断基準等）を明確に提示する必要がある。

テム要件（外部設計に対するインプット）を主体的に決定・明確化する。その上で、開発段階において、ベンダが主体となって業務全体に対する利害関係者（ステークホルダ31）の要件のうち、システムに関する部分（システム要件）についての仕様化を行う。また、外部設計がユーザによる承認を受けた後の要件追加、仕様変更、未決事項等は変更管理手続に則り、委託料・納期等の協議を実施することが望ましい。

・ 上記のモデルを実現するために、以下の契約類型を基本としながら、各フェーズにおけるユーザ・ベンダの責任分担を詳細に規定することにする。

モデル契約におけるフェーズの分類と契約類型

企画・要件定義段階

・システム化の方向性 【準委任型】

・システム化計画 【準委任型】 「超上流32」

・ 要 件 定 義 【 準 委 任 型 】

開発段階

・システム設計（システム外部設計） 【準委任型・請負型】

・システム方式設計（システム内部設計） 【請負型】

	・ソフトウェア設計	【請負型】
	・プログラミング ・ソフトウェアテスト	【請負型】 【請負型】
	・システム結合 ・システムテスト	【請負型】 【準委任型・請負型】
	・受入・導入支援	【準委任型】
運用段階	・運用テスト	【準委任型】
	・運用	【準委任型・請負型】
保守段階	・保守	【準委任型・請負型】

（再委託におけるユーザの承諾の要否／第 7 条）

・ 開発プロセスにおいて、プライムベンダ（元請）は、自己の責任において、対象システムに関わるスキル、経験、実績等を踏まえて再委託先（履行補助者）を選定している。そのため、再委託におけるユーザの承諾の要否については、再委

31 ステークホルダの間の合意確認の重要性については、「経営者が参画する要求品質の確保」

（IPA-SEC）を参照のこと。

32 共通フレーム 2007 においては、「企画プロセス」「要件定義プロセス」として位置づけられる予定である。

託先に対して、プライムベンダと同様の法令遵守、秘密保持33等について必要な措置を講じる義務を課すことで、ベンダに一任されるべきとする意見があった34。

・ 一方で、特に大規模システム開発の場合、委託先の決定がプロジェクト成功の成否・品質に大きな影響がでること、情報セキュリティ対策の適切な実施を確保する必要性35、従業員管理、多重下請36などコンプライアンスの観点からも、ユーザの事前承諾を条件とすべきとの意見があった。

・ そのため、モデル契約書（第 7 条）において再委託におけるユーザの事前承諾を設ける場合（【A 案】）と再委託先の選定について原則としてベンダの裁量（但し、ユーザの中止請求が可能）とする場合（【B 案】）の規定を用意するとともに、両案共通にモデル取引・契約書において下記の措置を講じた。

① 再委託先の選定は、情報システムの品質を担保するためにユーザに与えられるべき重要な情報であることから、契約書締結前のプロジェクトのプロポーザル・見積段階において、基本的なxx再委託先やオフショア利用等、プロジェクトの推進体制を事前に提案・見積条件として説明する。

② 再委託先との間で、契約に基づいてプライムベンダがユーザに対して負担するのと同様の義務を、当該再委託先に負わせる契約を締結する。

③ ユーザ指定の再委託先との責任関係については、ベンダに故意又は重過失がある場合を除き、再委託先の履行についての責任を負わない。

④ ユーザが再委託先に異議がある場合は、具体的な理由37を書面で明示する。

33 企業と従業者・退職者、企業間との適切な秘密保持契約のあり方については、「営業秘密管理指針」（平成 17 年 10 月改訂、経済産業省）を参照のこと。

34 請負型の契約形態の場合、法律上は、仕事の完成のためにどのような履行補助者を使用するかは請負人（ベンダ）の裁量であることも理由の一つとして挙げられている

35 「政府機関の情報セキュリティ対策のための統一基準」（2005 年 12 月版）においては、「外部委託を実施する際に、委託先に請け負わせる業務における情報セキュリティ対策、機密保持（情報の目的外利用の禁止を含む）、情報セキュリティ侵害発生時の対処手順及び情報セキュリティ対策の履行が不十分である場合の対処手順を含む外部委託に伴う契約を取り交わすこと」とし、また、「委託先がその請負内容の全部又は一部を第三者に再請負させることを禁止すること。但し、委託先からの申請を受け、再請負させることにより生ずる脅威に対して情報セキュリティが十分に確保できる措置が担保されると（中略）判断する場合は、その限りではない」としている。具体的な規定については、外部委託における情報セキュリティ対策実施規程雛形（2006 年 3 月、内閣官房情報セキュリティセンター）を参照のこと。

36 「情報サービス・ソフトウェア産業維新」において、「下請を通じたリスクの分散機能を維 持しつつ、付加価値のない派遣的な関係については多重化を制限する（二重派遣の禁止規定を活用）ことにより、請負と派遣の機能を分化・明確化する（但し、派遣的なビジネスモデルを否定するものではなく、そのようなビジネスモデルを行うに当たっては派遣法の枠組みの中で行うべき。）。また、委託取引等については、「情報サービス業界における下請法遵守のためのガイドライン」を参考にして、下請法を遵守し、中小ベンダが不利な状況におかれないように留意する」と指摘している。

37 再委託を実施することが不適切な事由には、現にユーザと競合する企業のソフトウェア開発

（損害賠償責任について……範囲・限度額・期間／第 53 条ほか）

・ 損害賠償責任の範囲、限度額について、民法の原則に従い相当因果関係の範囲

（通常損害及び予見可能な特別事情から生じた特別損害）とすべきか、情報システム構築の特殊性を考慮すべきかについて、議論が分かれた。

・ 情報システム構築の特殊性に関しては、以下のような意見がでた。

① オープン化の進展により、多数の製造者が提供するハードウェア、ソフトウェアを組み合わせることが一般的となっている情報システムを構築・運用する上で、それらの整合性等を完全に検証する手段がなく、予防手段が限られている。

② 情報システムは、ユーザの業務プロセスの変化への対応など、内部的・外部的要因38により、構成するハードウェア、ソフトウェアの軽微な変更（例えば、機器部品の交換、バージョンアップ、セキュリティ上の脆弱性に対するパッチ等）が加えられていくが、それらをベンダが管理・支配できる要素が他の物品や役務の提供に比べて限定的である。

③ 一定の委託料と納期の範囲で、通常要求される注意義務を越えてリスクを負担することには限界があり、情報システムの障害を極小化するためのコスト（例えば、あらゆるパターンを想定したテストを実施するための費用・期間）とのトレードオフの関係にある。

④ 海外の取引慣行（米国・英国）でも責任の範囲・上限を契約書で設定していることが多い。また、海外製品を導入している場合、海外製品の瑕疵によって生じる損害のリスクをベンダがライセンサー（海外製品の供給者）に転嫁することができず、ベンダ自身が負わざるを得ないのが実態である。

・ 一方、「情報システムが、企業活動の本質である「競争優位」を得るためのシステムに移行しており、企業の営業活動に必要不可欠なインフラとなってきていることから、システム開発の中止、稼働開始時期の遅延あるいは障害等による稼働停止の被害のリスクは、民法の原則に則るべきである。実際の紛争においては、特別損害の立証は困難であり、また過失相殺により賠償額は減額されるなど、損害賠償責任は適切な範囲に限局される。本当に上限設定を設けないとベンダ側が無制限のリスクを負うのか」といった意見がでた。

業務に関与し、ユーザ独自の業務ノウハウが競合先に流出しかねない危険があること、情報セキュリティの確保のための十分な措置が講じられない状況などが考えられる。

38 内部的要因とは、情報システム利用者の要請によって自律的に行われるシステムの変更や保守の過程で実施される補修、改善、改良、是正等。外部的要因とは、法令等の改廃などの社会的要因、情報システムと接続する他の情報システムや基盤として利用するハードウェアやプラットフォームソフト等の変更などの技術的要因に伴い、他律的に生じる変更。

・ 情報システムの信頼性の向上の観点からは、「障害の種別・当初合意されていた信頼性・安全性水準によって、情報システム利用者及び情報システム供給者の責任の度合いが大きく異なる」ことを前提に、「損害賠償の範囲・賠償上限額等の損害の負担のあり方」等を規定することが重要である（「信頼性ガイドライン」を参照）。

・ この前提となっているのは、信頼性の向上のためには、ユーザとベンダの双方が、リスクの性質・規模を的確に認識し、管理の仕方を検討することが重要であるということである。両者が責任の負担を検討することにより、リスクを軽減するための具体的な対策（例えば、十分なテスト期間の確保、データの二重化、運用回避策等）や、保険制度等によるリスクヘッジの必要性・コストを十分に検討することが期待される。

・ そのため、モデル取引・契約書において下記の措置を講じた。

① 損害賠償責任については、契約書締結前のプロポーザル・見積段階において、事前に提案・見積条件として説明する。

② 具体的な損害賠償の上限額、瑕疵担保期間、債務不履行責任による損害賠償請求の期間39については、個々の情報システムの特性等に応じて定められるものであるため、モデル契約書においては、具体的な範囲・限度額・期間を個別に決定できるように記述する。

（著作権の帰属40／第 45 条）

・ xxxxx作権の譲渡を受ける理由としては、次のような意見がでた。

① 成果物において、開発作業に協力したユーザ情報が含まれており、ユーザのノウハウの流出を防止（特に、ユーザの競合他社）する必要がある。

② 開発費用をユーザが負担している。

③ ベンダが倒産した場合、破産管財人によりソフトウェア著作権のライセンス契約が解除されるおそれがある41。解除された場合、ユーザはソフトウェアの使用を中止し、新たにソフトウェアを開発し直さなければならなくなる。

・ 他方、ベンダに著作権を帰属させる理由としては、次のような意見がでた。

39 民法に定める請負契約の担保責任（634 条～638 条）は、民法 415 条（債務不履行による損害賠償）債務不履行の特則であって、仕事の完成物の瑕疵に関しては、債務不履行の規定ではなく、上記の担保責任の規定が適用されると解釈されている（判例・学説）。

40 モデル契約書では、著作権を除く特許その他の知的財産xxは発明者主義で統一している。

41 現行倒産法制では、破産管財人はベンダが締結していたライセンス契約が双方未履行の状態にある場合には、ベンダが締結していたライセンス契約を解除（破産法 53 条）して、著作権を第三者に譲渡することが認められているが、ソフトウェア著作権については対抗要件制度を備えていないため、ユーザ（ライセンシー）には第三者に許諾権を対抗する手段が設けられていない。

① ベンダに著作権を帰属させることにより、社会的な生産効率の向上（ベンダの横展開（パッケージ化、共通モジュールの再利用等））とともに、プログラムの部品化、標準化等により情報システムの信頼性向上を図ることが可能となる42。

② ベンダに秘密保持義務を課すことでユーザのノウハウ流出防止を図ることが可能であり、“ノウハウ流出防止＝著作権のユーザ帰属”ではない。

③ xx取引委員会の役務取引ガイドライン43に基づき、著作権の譲渡に関する対価を含めた譲渡契約が成立すれば理論的には対等な取引条件といえるが、通常は、情報システム構築の委託契約において、明示的に権利移転の対価は含まれていないので対等な取引条件とはいいがたい。

④ プログラムの著作物についての一定の改変、複製・翻案は、複製物の所有者に対しても著作xx44により許容されており、著作権を有しないユーザが情報システム子会社その他アウトソーシングベンダに保守運用を委託することは可能である。倒産における著作権の帰趨については、対抗要件を具備する制度は存在しないものの、ソースコードや付帯するドキュメントの開示・交付を受けることは、納入物にソースコードを明記するか、エスクロウ制度の活用45により対応可能である。

・ そのため、著作権の有効活用とユーザの競争力の保持とのバランスから、モデル契約書（第45 条）において、ベンダにすべての著作権を帰属させる場合（【A 案】）、汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外をユーザに権利を帰属させる場合（【B 案】）、汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有とする場合（【C 案】）の規定を用意するとともに、両案共通にモデル取引・契約書において下記の措置を講じた。

42 ソフトウェアの開発技法は、オブジェクト指向型に代表されるように、あらかじめ再利用可能な部品を用意しそれらを活用して開発する傾向にある。再利用の形態として、①汎用化させる場合と、②カスタマイズするベースとして利用する場合がある。

43 「役務の委託取引における優越的地位の濫用に関する独占禁止法上の指針」（H10.3.17、

16.3.31 改定、xx取引委員会） 「第２ 委託者による優越的地位の濫用行為 ７．情報成果物に係る権利等の一方的取扱い」を参照のこと。

44 著作xx第 20 条第 2 項第 3 号（同一性保持権が適用されない改変の例）「特定の電子計算機においては利用し得ないプログラムの著作物を当該電子計算機において利用し得るようにするため、又はプログラムの著作物を電子計算機においてより効果的に利用し得るようにするために必要な改変」、著作xx第 47 条の 2（プログラムの著作物の複製物の所有者による複製等） 「プログラムの著作物の複製物の所有者は、自ら当該著作物を電子計算機において利用するために必要と認められる限度において、当該著作物の複製又は翻案（これにより創作した二次的著作物の複製を含む。）をすることができる。」

45 (財)ソフトウェア情報センターにおいて、ソフトウェア・エスクロウ・エージェント業務を 実施している。預託物についての対抗要件を具備するものではないが、ライセンサーの倒産時に、ソースコード、関連ドキュメントの開示・交付が可能となる。

① 著作権を含む知的財産権の帰属について、契約書締結前のプロポーザル・見積段階において、事前に提案・見積条件として説明する。

② プログラムに関する著作権について、ベンダが将来のソフトウェア開発に再利用できるように、同種のプログラムに共通に利用することが可能であるプログラムに関する権利（ベンダが従前より権利を有していたもの及び本件業務により新たに取得したものを含む。）及びベンダが従前から保有していたプログラムに関する権利は、ベンダに留保されるものとする。ベンダは、契約に定める秘密保持義務に反しない限り、他のソフトウェア開発においても汎用プログラム等を第三者に許諾し、又はパッケージ化して販売することを可能とする。

③ ユーザは、秘密保持義務の及ぶ範囲を明確化する。

④ ベンダの秘密保持義務は、情報システム構築後の関連プログラムの権利の再利用にまで及ぶものであり、秘密保持義務が優先されるものであることを明確化する。

・ ソフトウェアの有効活用を推進するためには、著作権の経済的価値に見合う対価を踏まえて取引条件を決定することが必要である。例えば【B 案】による場合、著作権の移転（同種のプログラムに共通に利用することが可能であるプログラムに関する権利を除く。）に見合う対価を別途支払う、あるいは当該対価を委託料に含ませることとして、ベンダに著作権を留保する場合に比べて委託料を高く設定するといった形態が考えられる。

（第三者ソフトウェア・FOSS の利用／第 48・49 条関係）

・ 第三者ソフト（商用パッケージソフト等）及び FOSS（フリーソフトウェア及びオープンソースソフトウェア）の利用については、①当該ソフトウェアそのものの瑕疵に起因するリスク及び②システムとの組み合わせに起因するリスクが存在する。

・ ベンダが第三者ソフト及び FOSS の瑕疵の有無を管理することは非常に困難である場合が多いが、取引のパターンとして、ユーザが特定の製品を予め指定する場合、価格・機能の条件を指定しその中からベンダが選定する場合、ベンダが自ら選定する場合があり、それぞれの場合でベンダの責任の範囲が異なってくる。

・ ①第三者ソフト及び FOSS 自体の瑕疵に起因するリスクは、当該第三者とユーザとの契約で対処すべき問題である。但し、商用パッケージについて、ベンダがサブライセンサーとなる権利を得て、ベンダ自身の商品ラインナップの一つとしてユーザにサブライセンスする場合は、ベンダは当該ソフトウェアの瑕疵についても一定の範囲で責任を負うべき場合がある。

・ 他方、ユーザに第三者ソフト及び FOSS の選定の知見等がなく、ベンダがユーザ に導入の可否について判断機会及び判断を行うために、合理的に必要とされる情 報を与えることなく自主的判断で選択した場合については、ベンダも一定の責任 を負う（特に、ベンダは当該ソフトの選定（利用方法、機能上・利用上の制限、 保証期間等）について、専門家としての情報提供義務を契約上の責任として負う。）。

・ なお、ベンダが自らパッケージソリューションのコアとなるパッケージ製品である第三者ソフトウェアを選定する場合は、契約締結前のプロポーザル・見積条件の提示段階において、その利用の有無を明らかにする必要がある。他方、内部設計の過程で必要となった機能を充足するために、契約締結後に限定的な機能を有する第三者ソフトウェアを選定する場合もあるが、この場合も当該ソフトウェアの利用を決定する前にユーザとの協議を行う必要がある。

・ ②他のシステムとの組み合わせに起因するリスクは、システムインテグレーションを担当するベンダが負うべきであるが、原因の特定が困難であることが多く、トラブル原因の切り分けを含めた原因究明の手続きを定めておく必要がある。なお、当該リスクを最小化するためには、システムインテグレーションベンダが、第三者ソフトウェアの選定に際して他のシステムのベンダにも懸案事項の有無を聴取するなど、ベンダ間の連携及び相互調整が不可欠である。

（5）今後の検討課題及びモデル取引・契約書の活用について

（今後の検討課題）

・ システムライフサイクルプロセスの体系化46

経済産業省及び IPA（独立行政法人 情報処理推進機構）/SEC（ソフトウェア・エンジニアリング・センター）は、ユーザ・ベンダ間のシステムライフサイクルプロセスの共有化に向けて、研究会の成果を踏まえつつ、保守・運用プロセスの可視化を含めた共通フレームの体系化を行うことが望まれる。

・ モデル取引・契約書の定期的な見直し・多様な契約のあり方についての検討

経済産業省は、研究会で策定されたモデル契約プロセス、モデル契約書、モデルドキュメントの定期的な見直しを行う。また、保守・運用プロセスの体系化を踏まえた保守・運用サービスのモデル取引・契約書、パッケージ活用型開発の契約のあり方、中小企業ユーザとの契約のあり方、ソフトウェアモジュールの再利用を促進する契約のあり方及びパフォーマンスベース契約等の多様な契約のあり方についても検討を行う。

・ 多様な開発モデルにおける契約のあり方についての検討

経済産業省は、ウォーターフォールモデル以外の開発モデルが活用されている実態を踏まえて、反復繰り返し型等の開発モデルに基づいた契約のあり方について、信頼性の向上・取引の可視化の観点から検討を行う。

・ ADR（裁判外紛争処理）の活用47

ユーザ・ベンダの責任分担とその履行等について、専門的・技術的視点による詳細な事実認定、並びに当事者間の話し合い及び調整といった機能・プロセスが必要となる場合、紛争処理を迅速かつ柔軟に行うことが可能である ADR の活用・促進が望まれる。なお、モデル契約書においては、紛争処理方法について、仲裁によることを原則としている。

（モデル契約書の活用方策）

・ 政府調達における活用48

経済産業省は、研究会の成果を踏まえて、積極的に調達に活用することに加え、

46 共通フレームについては、超上流プロセスの可視化等の IPA/SEC 成果の反映、信頼性ガイドライン要素の取入れ等の観点から、共通フレーム 2007 として改訂作業を行っている。

47 情報システム取引に係る紛争解決における ADR の活用促進策については、ADR のスキーム・体制、ADR の有効性に関する認知度向上策についての検討を行っている。

48 総務省では、各府省における情報システム調達について、競争促進等によりコスト低減や透明性の確保を図るための統一的なルールとして「情報システムに係る政府調達指針の基本指針」

（平成 19 年 3 月）を公開している。（xxxx://xxx.xxxxx.xx.xx/x-xxxx/0000/000000_0.xxxx）

政府調達における活用方策を検討する。

・ 信頼性評価指標への活用

経済産業省及び IPA/SEC は、現在策定中の情報システムの信頼性評価指標において、モデル契約書に定める主要事項の準拠に対する取組レベルを診断し、可視化することが望まれる。

・ 保険制度の創設の検討49

モデル契約の活用・普及によるユーザ・ベンダの情報システムに関するリスク認識の向上50、顕在化するリスクへの対応のために、モデル契約書及び前述の信頼性評価指標等を被保険者の個別審査に活用した保険商品が設計されることが望まれる。

・業界団体等における普及・啓発

ユーザ・ベンダを代表する各業界団体においては、信頼性ガイドラインにおいて定められた対策及び留意事項の実施、研究会での議論を最大限尊重した取引慣行の確立に向けて、啓発活動を行うことが望まれる。

また、パッケージを中心としたシステム導入の場合や反復繰り返し型の開発の場合、中小企業ユーザにおける活用の場合等、本モデル取引・契約書で十分カバーできていない論点について、業界団体を中心としてさらに議論が深められることが望まれる。

49 現在、情報システムに不具合が生じた場合のベンダに対する損害賠償責任保険等が一部の保険会社から提供されているものの、保証上限が低いこと、法律上の賠償責任しか対象にならないこと等により十分に普及していない。

50 独立行政法人情報処理推進機構（IPA）においては、プロジェクト定量データの収集・分析に引き続き努めるとともに、定量データベースの一般公開あるいは定量データを基にしたプロジェクト診断ツールなどの開発にも着手している。また、IPA では定量データの収集・分析に関して、各業界団体との連携を強化していく。

２．モデル契約プロセス

· 企画・要件定義段階において、ユーザ・ベンダ間の明確な責任と役割分担のないままに、ユーザがベンダに依存して要求事項を伝達して仕様を策定し、情報システム開発を行うことは、情報システムの信頼性、安全性を損なう。

· 信頼性及び安全性の高い情報システムを構築するためには、事業、業務システム及び情報システムの必要性を最もよく知るユーザが、その責任において事業、業務システム及び情報システム要件を的確に洗い出し、システム設計及び開発に反映させることが必要である。

· そのためには、情報システム開発に向けて適切に区切られたフェーズ毎に、取り扱うべき主題、すなわち、実現すべき成果やベンダからユーザに供給されるべきサービス、ユーザとベンダの役割分担と責任を整理し、明確にして、ユーザとベンダの権利義務関係として、構築することが不可欠である。

· また、保守・運用段階においても、ユーザの参画は必要不可欠である51。情報システム障害による事業、業務システムへの影響を極小化するためには、事業、業務システムと運用サービス提供者側との認識ギャップを解消するユーザ・ベンダの役割分担の整理52、未然防止と事後対策の両側面からの対策の実施等が必要である。また、開発段階からの信頼性・安全性を含めた運用コスト意識の醸成が不可欠である。

· そこでモデル契約プロセスでは、デューデリジェンス（実態把握）の実施から、契約締結、変更管理手続に至るまでの取引ルール、そこでのユーザとベンダの役割分担と責任、多段階見積や分割発注などのプロセスを明らかにする。また、マルチベンダ方式・分割発注に関する注意事項、ユーザとベンダの協力の重要性・役割分担、プロジェクトマネジメントの重要性等について論じることとする。

（1）モデル契約プロセス

（デューデリジェンス～RFI、RFP～契約締結～変更管理手続）

· ユーザが情報システムの構築をするか否かの検討に着手してから、ベンダとの契約締結に至るまでの最初のステップは、デューデリジェンス（実態把握）の実施である。この段階は、ユーザが候補となるベンダを複数社リストアップし、各社が情報シス

51 特に、情報システム利用者側の経営層は、変化の予測と改善活動の必要性を十分理解し、それらを行う保守・運用段階の重要性を認識しなければならない（「信頼性ガイドライン」）。

52 「信頼性ガイドライン」においては、「保守・運用の重要性の認識」として、「情報システムが提供する業務・サービスに対するビジネスニーズ及び取り巻く環境は常に変化」するものであるため、「情報システムが変化に対応し、常に最適な状態を保つためには、変化の予測と恒常的な改善が不可欠である」としているが、本研究会において、マルチベンダ化・オープン化が進展していく中で、全体統制の責任、複数ベンダ間の責任関係の明確化の重要性があらためて指摘された。

テム開発を適切に開発する能力があるかを、技術力や経営の健全性53などの観点から分析・検討する。

ユーザは、これらの分析・検討の前提として、ベンダに対してシステム開発の提案を求める。これが後述の提案依頼書（Request For Proposal：RFP）である。ユーザは、各社から提出された提案書及びその他の情報を総合的に判断してベンダを選定することになる。ユーザは、RFP の作成に先だって、情報提供依頼書（Request For Information：RFI）をベンダに提示し、必要な情報の提供を求める場合がある。なお、ベンダ選定上の留意点については、本契約モデルの対象外であるが、単に入札価格の安いベンダを採用するということではなく、履行体制等にも配慮の上、TCO（Total Cost of Ownership）に基づいて判断を行うべきである。特に、極端な安値の場合には注意が必要である。

· ユーザがベンダを決定した後は、そのベンダが提出した提案書などを基にして、より具体的な開発規模の検討や、委託料、開発スケジュールなどの検討に入るとともに、契約条件の交渉を行い、契約を締結することになる。後述のモデル契約書が、ここで締結されるものとして想定されている契約書である。

但し、この段階では業務要件や開発規模が完全に明確になっていることは少なく、開発工程の途中段階で種々の変更が必要になることが多い。こうした変更は、しばしば口頭でなされることがあり、それがユーザとベンダ間の役割分担や責任範囲を曖昧にし、品質面に悪影響を与える一因になっている。こうした問題を防ぐためには、契約条件に影響を与える変更に関する手続を明確にし、その手続を履践した場合にのみ変更が認められるものとする必要がある。モデル契約書の変更管理手続は、この手続を定めたものである。

（多段階契約）

· 上記のモデル契約プロセスでは、必要に応じて、ユーザがベンダ等との間でコンサルティング契約を締結し、ユーザ自らの責任において、情報システムに対する要件を確定することが想定されている。

· また、ユーザの仕様が固まるまでの要件定義作成の業務は、ユーザ自らの責任においてなされるものであり、ベンダは、これを準委任契約として支援することが想定されている。

· これは、情報システム開発の「無から有を生じさせる」といわれる特性を反映して、

53 大規模なシステム開発の場合は、開発期間が数年間にわたる場合もある。その途中でベンダの経営状況が悪化した場合、開発業務の遂行にも悪影響が生じる可能性が大きい。もしそのような事態になれば、品質が低下したり、スケジュールの遅延を招くことになる。こうした問題を未然に防止するために、ベンダの選定にあたっては、技術力だけでなく財務状況などの経営面からの検討も必要である。

ユーザとベンダが、各フェーズで実現すべき成果とサービス、ユーザとベンダの役割分担、それぞれの責任などを明確化した契約を多段階で締結して、情報システム開発を進めることが、ユーザ・ベンダ双方にとって合理的であり、信頼性・安全性の高い情報システムを構築に資すると考えられることによる。

（多段階契約モデルの汎用性）

· モデル契約プロセスは、フェーズに応じた契約によって、そのフェーズで実現すべき成果やサービス、ユーザとベンダの役割分担と責任を明確にして展開される結果、実際に開発されるシステムの特性に応じて、この契約プロセスの一部をさらに細分化し、あるいは逆に結合して契約プロセスを構築することにより、ウォーターフォール型のみならず、多様な開発形態への転用が可能なベースとなるものである。なお、反復繰り返し型やパッケージインテグレーション等において、このモデルを活用する際の留意点については後述する。

（RFI の概要と記載項目）

①情報提供依頼書（Request For Information：RFI）の概要

RFI は、ユーザが RFP の作成に必要な情報提供、例えば、ＩＴ技術動向、ソフトウェアパッケージ情報、開発方法論、価格情報等をベンダに依頼するものである。ベンダだけでなくユーザの関係先、業界団体等に依頼する場合もある。

外部の先行事例、成功事例、失敗事例、法律・制度上の規制や緩和、JIS などの標準化規約、業界団体の自主ルール、特許などの情報収集も対象となる。

②RFI の記載事項

ユーザはベンダに対して、情報提供依頼に関する条件を明確にしておく必要がある。例えば、ユーザの情報収集活動の一環であること、ユーザはベンダに RFI の発行に

際して、事前に RFI の依頼先が必ずしも RFP の提出先とはならないこと、ベンダが RFIの返答するためにかかったコストはベンダが持つこと、ベンダが RFI に関してアナウンスをすることを禁止すること、提供情報の利用に関するユーザ・ベンダの対応（自由な利用か、守秘義務の有無）等についても説明し、書面に記載するなどして明確にしておく必要がある。

ユーザにとって有益な情報収集のために、「情報提供を依頼する項目」だけでなく、場合によっては、何故、その情報の提供依頼をするのかを明確にするため、ユーザのプロジェクトの簡単な説明、ユーザがプロジェクトに期待している効果、ユーザの現在のＩＴビジネス環境に関する説明等を記載する。

また、RFP の発行先選定のために、ベンダのバックグランド情報に関するリクエスト、

ベンダの他のクライアント（ユーザ）の情報、ベンダの財務状況に関する情報、組織図等をリクエストすることもある。

（RFP の概要と記載項目）

①提案依頼書（Request For Proposal：RFP）の概要

RFP は、大きく分けて、①システム化の方向性、システム化計画を実施するためのものと、②要件定義以降に実施するものの 2 つに分類される。

RFP に記載すべき基本項目については、以下のような事例が掲げられる。

①システム化の方向性、システム化計画を実施するための RFP では、未確定の事項があるかもしれないが、②要件定義以降に実施するものでは、ユーザがどのようなシステム、何ができるシステムを作りたいかを明確にした要件定義を RFP に表現する必要があり、表現されていない要件はシステムとして実現されない。オープンな調達においてはユーザの責任において要件定義を明確化すべきであり、ベンダは提案に際して、不明の点があれば文書による質問等を行い疑義が残らないようにしなければならない。

また、RFP の作成に関して、「ユーザ企業の現況及び環境」を、きちんとベンダに伝えなければ、適切なシステム構築にはつながらない。

対象システムが、本研究会の対象としているような複雑で大規模な企業基幹システム等である場合は、ユーザ企業の経営戦略、情報戦略に関連して、ユーザ企業がベースとしている全体最適化（Enterprise Architecture：EA）、ＩＴガバナンスの方針、情報セキュリティ基本方針、組織体制（情報システム化委員会、ＩＴ部門等）、情報化投資、情報資産管理の方針、事業継続計画（Business Continuity Plan：BCP）、コンプライアンス方針等の中から、当該システム構築の前提として、必要と思われる部分をベンダに開示する必要がある。

②RFP の記載事項54（詳細は別紙 2 を参照） (1)システムの概要（基本方針）

ユーザがシステムを構築する上でグランドコンセプトとなる開発の経緯、基本方針、狙いとする効果等を明らかにする。

(2)提案依頼手続き

ベンダが提案書を提示するときに必要な事務手続き等に関し、ユーザが各種条件を指定する。

(3)依頼事項55

54 「共通フレーム 98」（通産資料調査会）における付属資料 3-3 をベースに加筆・修正を行っている。

RFP の中核をなすもので、ベンダが責任を持って見積りを出すのに十分な要件として、機能要件だけでなく非機能要件も明らかにする必要がある。

(4)開発体制・開発環境

開発作業時の作業にかかわる環境条件について、ユーザ・ベンダ双方の役割分担について明示する。

(5)保証要件

提案書の提出を受ける際に明らかにしておきたい情報システムの保証要件を明示する。なお、セキュリティについては、「情報システムの構築等におけるセキュリティ要件及びセキュリティ機能の検討に関する解説書」（内閣官房情報セキュリティセンター）が参考になる。（詳細は別紙 3 を参照）

(6)契約事項

契約書の中に盛り込むべき重要事項を抽出し、それらの条件、あるいは要求について、予め明らかにしておく。特に、契約類型（準委任／請負）、再委託、損害賠償責任（範囲・限度額・期間）、知的財産権の帰属、第三者ソフトウェアの利用、検収・支払い条件等について、これらの条件、あるいは要求について予め明らかにしておく必要がある。

(7)その他

必要に応じ、要求すべき特記事項を記載する。また、RFI と同様に、RFP の返答するためにかかったコスト負担、提供情報の利用に関するユーザ・ベンダの対応（自由な利用か、守秘義務の有無）等についても説明する必要がある。

なお、上記基本項目の内容を具体化した RFP の個別項目については、その項目内容を別紙 2 付表-1「提案依頼書に記載すべき項目一覧」に示した。

また、ユーザ企業内の業務部門、ＩＴ部門が提案依頼書に記載すべき項目一覧のどの部分を分担すべきかを、別紙 2 付表-2「提案依頼書の作成分担」に示した56。

（提案書・見積書）

①提案書の概要

提案書は原則的に、ユーザからベンダへの提案依頼事項が記載された RFP に基づいて、ベンダによって作成されるものであり、ベンダ選定にかかわる最も重要な提出文書である。

55 ユーザの要求（ニーズ）の仕様化に関するノウハウ・内容・書き方、仕様管理の方法の体系化、関連ドキュメントの対応関係の整理、当該ドキュメント類の作成にあたっての使用容易性（ユーザビリティ）への配慮等についての検討を行っている。

56 「システム・リファレンス・マニュアル」（IPA-JUAS）をベースに加筆・修正を行っている。

提案書に記載される主な内容は下記のとおりであるが、ユーザのニーズ等に応じて項目を取捨選択し提案する必要がある。すなわち、ベンダは、RFP に記載された依頼事項の実現可能性等について的確に応じるものとし、提案手続きを通じて、情報システムの価値を決める諸要因の水準についての十分な認識の共有が図られる必要がある。

このプロセスにおいて、RFP に記載された契約条件等の取引条件についても、十分にユーザ・ベンダ間で協議、確認を行う必要がある。また、RFP に記載された契約条件等について補正が必要となる場合、ベンダがその理由を示して変更の申入れを行う場合は、書面によることが望ましい。なお、海外の取引慣行では、重要な条項に関する共通した理解を得るとともに、問題点やギャップの洗い出しを可能とする「タームシート（Term Sheet）57」が活用されることがある。

②提案書の記載事項58（詳細は別紙 4 を参照） (1)はじめに

ベンダは、提案内容を要約し、その要点を明確にする。 (2)システム構想

提案するシステムの概要、システムの機能を要約し、提案システムの特筆すべき特徴等について記述する。

(3)システム構成

提案するシステムのソフトウェア構成、ハードウェア構成、ネットワーク構成等について、利用者別、設置場所別・業務別にシステム構成を記述する。

(4)システムの性能予測

システムの運用時におけるソフトウェア、ハードウェアの業務別の応答性、信頼性、障害対応等の性能について予測する。

(5)システム拡張性

ユーザ環境の変化・技術革新等に起因するシステムの改善や拡張の可能性、システム運用の留意事項について記述する。

(6)システムの信頼性

提案システムの信頼性・安全性及び運用時における操作性について記述する。 (7)開発計画

システムの開発計画に伴う、人、物、金、時間、工程等に関する作業量を見積り、システム全体のスケジュールや計画、実行上の課題等について記述する。特に、業

57 ユーザの提示した契約要件について、ベンダの対応（承諾、コメント等）と現在の進捗状況

（解決、未解決）を一覧にまとめたもの。

58 「共通フレーム 98」（通産資料調査会）における付属資料 3-3 をベースに加筆・修正を行っている。

務詳細設計等でユーザが自らの責任で主体的に承認しなければ、次の工程に進めない部分を明確に記述する。なお、本項目には、スケジュール、見積条件、契約条件等を含む。

(8)推進体制

システム開発計画推進に必要な技術・資格・経験等を含めたシステムの人的推進体制や責任体制について記述する。また、当該体制には、予定されている再委託先も記述する。

(9)期待効果分析

システム化による定量的、定性的な効果やメリットについて記述する。 (10)今後の課題

未決の懸案事項、次期計画に関する課題について記述する。 (11)関連する実績

ベンダが過去に実施した本システムと類似の実績や、ベンダ企業の組織、業績、特質等について記述、又は資料を添付する。

なお、別紙 4 付表-1 の「提案書に記載すべき項目一覧」を示した。

③開発見積

システム化方針の決定及びシステム化計画の立案の工程では、ユーザはＩＴ戦略の計画立案のために、必要に応じてベンダ等とコンサルタント契約を締結してその能力を補充し、ベンダに RFP（記載すべき事項については、別紙 2 付表-1）を提示し、システム化方針の決定段階ではベンダから「仮試算見積」を、システム化計画の立案の段階では仮試算見積より精度の高い「試算見積」による見積提案を受ける59。この段階の見積は、ユーザ内における中期的な予算計画の立案等を目的としたものなど、見積の対象となる最終的な成果物の完成状態が明確に定義しづらい場合が多いため、参考値として取り扱われるべきものである。

要件定義の工程では、ユーザは、要件定義の作成支援を内容とする準委任契約を締結してその能力を補充し作成された要件定義書をベースに、ベンダに RFP（記載すべき事項については、別紙 2 付表-1）を提示し、「概算見積」を内容とする見積を受ける。

この「概算見積」の段階においては、システム化の目的や範囲は明確となっているが、実際に開発するソフトウェアの詳細部分について固まっていない部分もある。特

59 RFQ（業務システム構築見積照会書）によるシステム調達の詳細については、「エンドユーザによるビジネスシステム定義の進め方」（JUAS、平成 16 年 4 月)が詳論している。なお、同様の視点から RFP の詳細化と利用者側の RFP 作成による調達を論じるものとして、「システム・リファレンス・マニュアル」（IPA-JUAS)がある。

に、「非機能要件」では、ユーザが提示した要件定義をベンダが外部設計を行っている段階で発生する要件もあることに注意しなければならない。例えば、運用・操作要件、移行要件等がユーザから提示されていたが、性能要件、運用のSLA要求事項の詳細をユーザに確認し、設計を行っていく過程で、セキュリティ・障害対策、技術的な専門事項に関する要件が、新たに出てくる場合がある。

したがって、システム化の方向性、システム化計画、要件定義の各工程におけるシステム開発の見積は、「確定見積」ではない。

研究会では、画面や帳票などのインターフェースを決定する外部設計の工程で「確定見積」が可能と考え、外部設計がユーザにより承認を受けた後のソフトウェア開発業務における要件追加、仕様変更、未確定事項の確定などが生じた場合は、変更管理手続に則り、「追加・再見積」を含む仕様変更・契約変更が行われるものとした。

なお、ユーザにおいては、できるだけ早期に要件を確定することが正確な見積を算出するために必要であることを認識する一方で、ベンダにおいては、見積精度を高める取り組みと見積に対する十分な説明責任を果たすことが不可欠である。

（2）フェーズの区切りと各々の概要・ポイント

フェーズを分ける目的は、フェーズごとにシステム開発のために行うべき主題を明確化すること、そして、主題ごとにユーザとベンダの責務と役割、相互協力関係、権利義務関係を明確にすることにある。

契約プロセスを分けるフェーズは、この目的に則し、かつ、ユーザとベンダの相互に理解が容易なものでなければならない。

・ 全 体 像

研究会の検討にあたっては、共通フレーム 2007 に基づいた標準化されたシステムライフサイクルプロセスの定義をもとに、以下のようにフェーズを分割した。なお、共通フレームについては現在改訂中であるが、本モデル取引・契約書において使用している工程の定義と共通フレーム 2007 のアクティビティとの関係を示した60。

システム化 システム化

の 方 向 性 計 画

要件 システム設計 システム方式設計

定義 （システム外部設計） （システム内部設計）

ソフトウェア設計プログラミング

ソフトウェアテスト

システム結合

システム 導入・

テスト

受入支援

運用テスト

運用

保守

① ② ③ ④ ⑤ ⑥⑦⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭

60 システム、ソフトウェア製品又はサービスを得るために、企画、開発、運用、保守段階において供給者に委託する場合、共通フレームでは、取得者の作業を定めた「取得プロセス」と、供給者の作業を定めた「供給プロセス」がある。これらは二者間での契約プロセスを定めたものであり、「取得プロセス」には提案依頼書の準備、契約準備及び更新、供給者の監視、受入・検収・完了などが含まれ、「供給プロセス」には提案書の準備、契約締結、計画立案、実行・管理、レビュー評価、納入及び完了などが含まれる。

（参考）モデル契約の工程と共通フレーム 2007 での主たる作業一覧との対応関係

システム化の方向性

システム化計画

要件定義

システム設計

（システム外部設計）

システム方式設計

（システム内部設計）

ソフトウェア設計

企画プロセス

プロセス開始の準備システム化構想の立案システム化計画の立案

要件定義プロセスプロセス開始の準備

利害関係者要件の定義利害関係者要件の確認

ソフトウェア設計

システム方式設計

（システム内部設計）

システム設計

（システム外部設計）

要件定義

システム化計画

システム化の方向性

企画・要件定義段階

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

共通フレーム2007での主たる作業一覧

システム結合

システムテスト

運用

プログラミング

導入・受入支援

運用テスト

ソフトウェアテスト

開発プロセス

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

ソフトウェアコード作成及びテストソフトウェア結合

ソフトウェア適格性確認テストシステム結合

システム適格性確認テストソフトウェア導入

ソフトウェア受入れ支援

運用プロセスプロセス開始の準備

運用テスト

業務及びシステムの移行システム運用

（ ～ 略 ～ ）

導入・受入支援

運用

運用テスト

システムテスト

システム結合

ソフトウェアテスト

プログラミング

開発段階

運用段階

また、品質保証の観点から、設計とテストが対になる考え方を示したものが、次頁の図である。

図は、「ソフトウェア」を取り巻く「情報システム（いわゆるＩＴシステム）」、その外に業務部門が情報システムを使って運用する「業務」、そしてその外に経営層が行う「事業」からなる 4 つの層を示し、これに上流から運用までの流れを企画し作りこむフェーズとその正しさを確認するフェーズを対応させたものである。

経営者は情報システムが事業に貢献しているかを見、業務部門は自らが定義した要件

が実現されているかを運用テスト61で確認する。システムレベルでは、システム設計（システム外部設計）とシステムテストが、またシステム方式設計（システム内部設計）とシステム結合が対となる。ソフトウェアレベルでは図のようにソフトウェア設計とソフトウェアテストが対応する（脚注 30 参照のこと）。

システム設計

要件定義

システムテスト

運用テスﾄ

システム方式設計

システム結合

品質保証の観点からの設計とテストとの対応関係

システム設計

システムレベル

の設計

システム結合

システムレベル

のテスト

情

報

シ

業

事

ス

テム

務

業

ソフトウェア

ソフトテスト

ソフトウェア設計

プログラミング

システム方式設計

システムテスト

運用テスﾄ

要件定義

運用・評価

システム化の方向性・システム化計画

プログラミング

ソフトウェア設計

ソフトテスト

（企画・要件定義段階）

情報システムの企画・要件定義段階は、「システム化の方向性」の決定によって開始され、「システム化計画の立案」、「要件定義」の順に進行（これらのフェーズは「超上流工程」といわれる。）し、開発段階に進むためのシステム設計を可能とする程度に具体化した要件定義書が作成されて終了する。

「企画・要件定義段階」の概要は以下のとおりである62。

① システム化の方向性

「システム化の方向性」、業務部門が、システム開発の前に、経営層が定めた経営方針、全体最適化計画63に従い、事業上の目的、システム化の対象業務、システム化のニ

61 本図における「運用テスト」は、最終的に業務要件、システム要件を満足しているか利用者や運用者が行う確認テストを意味している。

62 「超上流」工程の重要性、ユーザ・ベンダの役割分担等については、「経営者が参画する要求品質の確保」を参照のこと。なお、共通フレーム 2007 において「超上流」工程は、「企画・要件定義プロセス」として位置づけられる予定である。

63 「システム管理基準Ⅰ.情報戦略 1.全体最適化」を参照。

ーズと課題、予算、事業環境を分析し、利害関係者からの要請やその数や役割に応じた規模などに配慮しつつ、システム化するビジネスモデルにつき十分な検討を繰り返し、取締役会等経営層による承認を受けてシステム化の方向性を決定するフェーズである。

ユーザは、ベンダに対し、このフェーズの成果を生かして RFP を発し、ベンダ等から「仮試算見積レベル」の見積提案を受け、これに検討評価を加えて、システム化計画に移行する。

ユーザは、必要に応じて、ベンダ、ＩＴ技術者、ＩＴコーディネータ64、システム監査人、情報セキュリティ監査人、公認会計士、弁護士等の専門家との間で支援業務を内容とする準委任契約としてのコンサルティング契約を締結し、これらの作業のための支援を受ける。

（共通フレームのアクティビティ）概ね「システム化構想の立案」に相当する。

② システム化計画

「システム化計画」は、業務部門が、システム化の方向性を具体化するために、開発体制、予算、スケジュール、システム化する事業上の要求（例えば、システム化すべき新規事業、社外連携、組織改編、部門間業務分掌変更、法令・契約等のコンプライアンス要件、セキュリティ、個人情報保護、環境など）や対象業務上の要求（例えば、業務内容、業務形態、業務品質、性能目標、運用、移行要件、法令・契約等のコンプライアンス要件、セキュリティ、個人情報保護、事業継続性、環境など）を考慮して、業務範囲や業務分掌、関係者の教育及び訓練計画65を定めたシステム化計画書を作成し、ステークホルダの合意を得てから経営層の方針稟議を求め、経営層による承認を受けて、業務部門及び情報システム部門における要件定義に進むフェーズである。

ユーザは、部門間の検討の後、システム化計画を作成して、レビューを繰り返して検討を加え、ベンダに対して RFP を発し、ベンダ等から「試算見積レベル」の見積提案を受ける。これを検討評価して要件定義フェーズに移行する。

ユーザは、システム化の方向性決定フェーズ同様、必要に応じて、ベンダ、ＩＴ技術者、ＩＴコーディネータ、システム監査人、情報セキュリティ監査人、公認会計士、弁護士等の専門家との間で支援業務を内容とする準委任契約としてのコンサルティング契約を締結し、作業のための支援を受ける。

64 1999 年の通商産業省（現：経済産業省）における産業構造審議会情報産業部会情報化人材対策小委員会の中間報告（～戦略的情報化投資による経済再生を支える人材育成～）において提案された、経営者側に立って経営とＩＴの橋渡しを行い、戦略的な情報化投資の成功を支援する専門家のこと。

65 「システム管理基準Ⅱ.企画業務 2.開発計画 (4)、「システム管理基準Ⅳ.共通業務 4.人的資源管理 4.3 教育・訓練」を参照。

（共通フレームのアクティビティ）概ね「システム化計画の立案」に相当する。

③ 要件定義

「要件定義」は、事業要件を反映したシステム化計画を受けて、業務部門が、業務上の要求を業務要件に、情報システム部門が、システムに実装すべきシステムの機能要件・非機能要件を定義し、経営層による実行稟議、承認を受けるフェーズである。ここでは、ユーザは、業務要件及びシステム要件を検討して、要件定義書にまとめ、 ベンダに RFP を発して「概算見積レベル」の見積提案を受け、これに点検評価を加え

て、システム設計に移行する。

そのために、ユーザは必要に応じて、ベンダ、ＩＴ技術者、ＩＴコーディネータ、システム監査人、情報セキュリティ監査人、公認会計士、弁護士等の専門家との間で、準委任契約を内容とする要件定義支援契約、仕様書作成支援契約を締結し、作業のための支援を受ける。

このフェーズの内容の妥当性の検証が、「⑨運用テストフェーズ」である。

（共通フレームのアクティビティ）共通フレーム 2007 で新設される「利害関係者要件の定義」、「利害関係者要件の確認」に相当する。

（補論）情報システム開発における信頼性・安全性の確保と評価

情報システム開発のプロセスが、超上流から開発プロセスまでに及ぶとき、情報システムの信頼性・安全性はどのように評価されるか。事業要件、業務要件については、仕様決定前に決定される内容であり、仕様に関するチェックでは、これらを評価することはできないことに留意すべきである。

そもそも、これらのチェックをなすに足る能力を有するのは、ユーザであって、ベンダではないことに留意する必要がある。そこで、ユーザがこれらを評価するには、各フェーズの区切りにおける経営層を含めた関係者・ステークホルダの評価を受けるための

「レビューの実施」はもとより、システム監査やセキュリティ監査、法規や契約などの規制要求事項への適合性を確保するためには、システム監査人、情報セキュリティ監査人、弁護士や公認会計士等による支援を受けて行う必要がある。

そのため、超上流プロセスにおいては、これらの評価に適するように、システム管理基準、情報セキュリティ管理基準66などに準拠すべきことを考慮し、少なくとも下記の点

66 システム管理基準は、組織体が主体的に経営戦略に沿って効果的な情報システム戦略を立案し、その戦略に基づき情報システムの企画、開発、運用、保守というライフサイクルの中で、効果的な情報システム投資のための、またリスクを提言するためのコントロールを適切に整備・運用するための実践規範である。システム管理基準は、本管理基準と姉妹編をなすシステム監査基準に従って監査を行う場合、原則として、監査人が監査上の判断の尺度として用いる基準となる。なお、情報セキュリティの確保の観点から監査を実施する場合には、情報セキュリティ監査制度

に留意する必要がある。

（1）システム化の方向性、システム化計画の実施においてユーザが留意すべき点

1) システム化の方向、システム化計画の内容は、組織体の長が承認しなければならない67。取締役会設置会社の場合は代表取締役、委員会設置会社では代表執行役の承認を要することになる。

2) システム化の方向及びシステム化計画は、全体最適化計画との整合性を考慮して策定されなければならない68。

3) システム化計画にあたり、組織体制を構築する際には、ユーザ部門（業務部門など）及び情報システム部門の役割分担を明確にする必要がある69。

4) システム化の費用の検討にあたっては、開発、運用及び保守の費用の算出基礎を明確にする70必要がある。

5) 情報システムの目的を達成する実現可能な代替案を作成し検討する71必要がある。

6) システム化計画を策定するにあたっては、システムライフサイクルを設定する条件を明確にし72、システム特性及び開発規模を考慮して形態及び開発方法を決定する

73必要がある。

7) システム化計画において要求事項を特定するにあたっては、ユーザのうち、システムユーザだけでなく開発、運用及び保守の責任者が承認する必要がある74。

8) システム化計画のためのユーザニーズの調査は、実務に精通しているユーザ、開発、運用及び保守の担当者が参画し、対象、範囲及び方法を明確にして現状分析を行い75、文書化し、ユーザ部門が確認する必要がある76。

9) システム化計画を策定するにあたっては、情報システムの導入に伴って発生する可能性のあるリスク分析を実施する77必要がある。

に基づく情報セキュリティ監査を行うことが要請される。一方で、システム管理基準においても情報セキュリティの確保に関連する項目が挙げられているが、それぞれの項目について、情報セキュリティ管理基準を活用して監査を実施することが望ましい。

（xxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xxxxx/0000000/0/000000xxxxxx.xxx）

67 「システム管理基準Ⅱ.企画業務 1.開発計画 (1)」を参照。

68 「システム管理基準Ⅱ.企画業務 1.開発計画 (2)」を参照

69 「システム監査基準Ⅱ.企画業務 1.開発計画 (5)」を参照

70 「システム管理基準Ⅱ.企画業務 1.開発計画 (6)」を参照

71 「システム管理基準Ⅱ.企画業務 1.開発計画 (9)」を参照

72 「システム管理基準Ⅱ.企画業務 1.開発計画 (7)」を参照

73 「システム管理基準Ⅱ.企画業務 1.開発計画 (8)」を参照。

74 「システム管理基準Ⅱ.企画業務 2.分析 (1)」を参照。

75 「システム管理基準Ⅱ.企画業務 2.分析 (2)、(3)」を参照。

76 「システム管理基準Ⅱ.企画業務 2.分析 (4)」を参照。

77 「システム管理基準Ⅱ.企画業務 2.分析 (5)」を参照。

10) 情報システムの導入によって影響を受ける業務、管理体制、諸規程等の見直し等の検討を行うとともに78、情報システムの導入効果の定量的及び定性的評価を行う79必要がある。

11) パッケージソフトウェアの使用にあたっては、ユーザニーズとの適合性を検討する必要がある80。

（2）要件定義における信頼性向上の視点

企画・要件定義段階では、ユーザとベンダは、情報システムの重要性に応じて、求められる信頼性・安全性の水準を正しく認識し、決定しなければならない。また、信頼性・安全性を実現するため、特に、以下の点に留意してシステムの機能要件及び非機能要件を整理、確認及び決定しなければならない。

1) 信頼性・安全性水準のユーザ・ベンダ間での合意

ユーザ及びベンダは、情報システムが具備すべき信頼性・安全性の水準及び目標とする品質基準等について定め、両者で合意すること。

2) 発注仕様への機能要件及び非機能要件の取込と文書化

ユーザは、ベンダに対し、情報システムに求める機能要件及び非機能要件並びにそれぞれに対する前提条件及び運用環境等を明らかにした上で、発注仕様を明確化及び文書化すること。

3) ユーザは、経営層を含めて、非機能要件について十分に検討を行うこと。この時、ベンダは、ユーザに、専門家として必要な情報提供等を行い、意思決定を積極的に支援すること。ユーザは、ベンダのみならず、ＩＴ技術者、ＩＴコーディネータ、システム監査人、情報セキュリティ監査人、公認会計士、弁護士等を利用して助言、支援を受けること。

（開発段階）

企画・要件定義段階を経て、ベンダが、ユーザとの間でソフトウェア開発契約に基づいて81情報システム開発を展開する段階である。システム設計（システム外部設計）、シ

78 「システム管理基準Ⅱ.企画業務 2.分析 (6)」を参照。

79 「システム管理基準Ⅱ.企画業務 2.分析 (7)」を参照。

80 「システム管理基準Ⅱ.企画業務 2.分析 (8)」を参照。

81 請負契約は仕事の完成を約する契約形態であるため、完成状態が明確に定義しづらい場合（下記①～③）、完成状態に到達するための不確定要素が多く完成までの工数が見積もれないなど、一定金額で請け負うことのリスクが高い場合（下記④～⑥）当事者関係における役割分担が明確でない場合（下記⑦）などは、開発プロセスであっても、請負型以外の契約形態があり得る。

① プログラムの性能テスト結果をチューニングする場合など、現存するプログラムの評価作業が役務の中心となるとき。

② ユーザの要求仕様がドキュメント等の形で確定しておらず、プロトタイプ等を示すこと

ステム方式設計（システム内部設計）、ソフトウェア設計、プログラミング、ソフトウェアテスト、システム結合、システムテスト、導入・受入支援を経てシステム開発は終了する。

ウォーターフォール型の開発モデルでは、要件定義、外部設計、内部設計、プログラミング等の各工程を明確に区切り、xx実行される。

他方、反復型では、開発対象を小さな機能単位に分割、機能ごとに各フェーズを繰り返し適用して開発される。プロトタイプモデルでは、工程を区分せずに、ユーザの要望から試作品を作成・提示・評価していくことで開発される。パッケージ導入の場合は、要件定義はフィット＆ギャップ評価、システム設計・プログラミングはカスタマイズ（いわゆるアドオンも含む。）に置き換えられる。

しかしながら、どのような開発モデルにおいても、要件定義がそのシステムの挙動を定めること、要件定義にはユーザの参画が不可欠であることに変わりはない。

④ システム設計（システム外部設計）

⑤ システム方式設計（システム内部設計）

企画・要件定義段階の後工程として展開される、ベンダがユーザから提出された要件定義書をもとにシステム設計を実施するフェーズである。

画面や帳票などのインターフェースを決定するシステム設計（システム外部設計）

（以下「外部設計」という。）とシステムの上位レベルでの方式を確立するシステム方式設計（システム内部設計）（以下「内部設計」という。）に分かれる。

ここでは、ユーザは、ベンダとのシステム設計契約に基づいて、ベンダから外部設計及び内部設計の設計書を成果物として受け取り、必要に応じて、ＩＴ技術者、ＩＴコーディネータ、システム監査人、情報セキュリティ監査人、公認会計士、弁護士等の専門家からの支援を受けて、これを検討・評価し、作成ベンダからの内部設計以降の開発フェーズに関する確定見積を得て、システム投資効果を確認する。

によって、ユーザの要求仕様を確定しながら、開発作業を進めていく工法をとるとき。

③ プログラムの保守作業などユーザの改善要求が具体的な仕様の形で確定しておらず、日々相談しながらxx作業を進めるとき。

④ はじめて使うパッケージのカスタマイズ作業など、フィット＆ギャップに伴う作業内容が不明確なとき。

⑤ 開発フェーズの途中から参画することとなったベンダがドキュメントを見ただけでは、完成に至るまでの確定料金を見積ることが困難であるとき。

⑥ 保守段階に入ったプログラムの追加開発作業など、過去のプログラム資産との整合性をとるための作業について、本当にプログラムの完成を請け負えるかどうか確信が持てないとき。

⑦ 自社チームにＰＭが不存在で多数の会社の混成チームでそれぞれの得意技術を持ち寄って共同作業を実施するとき。

なお、外部設計の検証が「⑩システムテスト」、内部設計の検証が「⑨システム結合」で行われる。

（共通フレームのアクティビティ）外部設計：概ね「システム要件定義82」、に相当する。内部設計：概ね「システム方式設計」に相当する。

⑥ ソフトウェア設計

「ソフトウェア設計」は、ベンダにおいてソフトウェアのコンポーネント、インターフェース、データベースの詳細設計をするフェーズである。

（共通フレームのアクティビティ）概ね「ソフトウェア要件定義」「ソフトウェア方式設計」「ソフトウェア詳細設計」に相当する。

⑦ プログラミング

「プログラミング」は、内部設計で指定された個々のモジュールを実装するフェーズである。

（共通フレームのアクティビティ）概ね「ソフトウェアコード作成及びテスト」に相当する。

⑧ ソフトウェアテスト

「ソフトウェアテスト」は、ソフトウェア設計の仕様どおりに制作されたかをベンダの責任において検証するフェーズである。

（共通フレームのアクティビティ）概ね「ソフトウェア結合」「ソフトウェア適格性確認テスト」に相当する。

⑨ システム結合

「システム結合」は、内部設計の仕様どおりに制作されたかをベンダの責任において検証するフェーズである。

（共通フレームのアクティビティ）概ね「システム結合」に相当する。

⑩ システムテスト

「システムテスト」は、外部設計の仕様どおりに制作されたかを検証するフェーズである。

82 「システム要件定義」は、現在改訂中の共通フレーム 2007 においては、ベンダが、ユーザの要件定義をもとに、ベンダの主体・責任のもとに、システムに関する部分について、求められているシステムを実現する技術的視点へと変換するシステム要件の仕様化を行うフェーズに位置づけられる予定である。

外部設計書の作成をユーザが主体的に行い、ベンダはその支援業務を準委任で行う場合は、その決定内容を確認するシステムテストの主体もユーザとなることが適切であるとの意見が多くあった。システムテストは、ユーザのビジネスプロセスを含めたテストにまで及ぶものであることから、請負契約とする場合には、ユーザは、ベンダが実施するテスト仕様（例えば、テスト項目、内容、方法、判断基準等）を明確に提示する必要がある。

（共通フレームのアクティビティ）概ね「システム適格性確認テスト」に相当する。

⑪ 導入・受入支援83

「導入・受入支援」は、疑似環境又は実環境にソフトウェアを導入し、ユーザのソフトウェア受入れレビュー及びテストを支援するフェーズである。

（共通フレームのアクティビティ）概ね「ソフトウェア導入」「ソフトウェア受け入れ支援」に相当する。

（保守・運用段階）

保守・運用フェーズにおいて要求されるサービス品質の確保を、定量的に可視化するために、サービスレベル契約(Service Level Agreement：SLA)を導入することが考えられる。SLA の導入にあたっては、信頼できる客観的な評価の可能性、評価項目の妥当性／要求水準の達成可能性、時間の経過に沿った見直し、管理に係るコスト（測定方法／監視体制）の合理性等に留意すべきである84。契約書においては、サービスレベル達成・不達の結果に対する対応措置（協議手続、解約権、ペナルティ・ボーナス）、ベンダの報告条件等を定める85。

情報システム障害を最低限に抑制するためには、信頼性・安全性向上に向けたユーザ・ベンダの責務（「信頼性ガイドライン」を参照）に基づき、障害発生時の対応手順・責任関係の明確化86、BCP の策定を行うことが必要である。

⑫ 運用テスト

「運用テスト」は、疑似運用環境等での運用テストの実施と実運用環境に移行を

83 このフェーズでの導入・受入支援作業は、システムテスト完了後だけではなく、ソフトウェアテスト完了後、又はシステム結合完了後でも（契約に取決めがあれば）行われる。代表的な例としては、システムテスト後に実施される運用テストのための作業項目として位置づけられる。

84 「民間向け IT システムの SLA ガイドライン」（JEITA）においては、ソフトウェアサービスの価値を「IT サービス」、「IT プロセスマネジメント」、「IT リソース」の３つのカテゴリに分類し、 480 項目の SLA 項目を設定、さらにその測定方法、測定単位、選択基準、サービスレベル（参考値）など、具体的な内容を解説している。

85 SLA 条項については、サンプル例のように仕様書の一部とする場合や、更新頻度を考慮して、別途「SLA 合意書」として別書面に定める方法も考えられる。

86 障害対応に関する留意事項については、「信頼性ガイドライン」を参照のこと。

実施するフェーズである。

（共通フレームのアクティビティ）概ね「運用テスト」「業務及びシステムの移行

87」に相当する。

⑬ 運 用

「運用」は、業務運用環境で情報システムを稼働して、業務を円滑に遂行するフェーズである。システムの起動／終了や監視、ファイルメンテナンスなどが含まれる。

（共通フレームのアクティビティ）概ね「システム運用」、「業務運用と利用者支援」等に相当する。

⑭ 保 守

「保守」は、情報システムやソフトウェアの現状を業務及び環境に適合するように維持管理を行う工程である。

（共通フレームのアクティビティ）概ね「保守プロセス」に相当する。

（3）マルチベンダ方式、分割発注に関する注意事項

（マルチベンダ方式の必要性）

情報システムが多くの世代にわたるシステム言語、技術の集積であるために、システム開発にはそれぞれの専門技術を有するベンダの連携が求められる。また、ユーザは、自社内やグループ内にベンダ機能を保有する場合があり、ベンダに対して、これらのベンダ機能とのジョイントを求めるときがある。こうして情報システム開発の多くが、マルチベンダ方式を求められることになっている。

（マルチベンダ方式の類型）

複数のベンダが連携する方式としては、①サブシステム毎の分割、②フェーズ毎の分割（要件定義／システム設計等）が存在する。

①の場合でも、サブシステム毎の開発が並列的に同時進行する場合ばかりではなく、システムの一部の改訂や再構築等に際して、既に保守フェーズ又は運用フェーズに入った他のシステムとの連携が必要となる場合もある。

（マルチベンダ方式採用時のユーザの責任範囲の考え方）

シングルベンダ方式とマルチベンダ方式のいずれであっても、開発プロセスそれ自

87 運用テストフェーズにおける「業務及びシステムの移行」作業が大がかりとなるものは開発段階と並行して行われることが多い。

体に変更を必要とするものではない。しかし、マルチベンダ方式を採用するときは、ユーザは、システム開発の目的を確立し、参加ベンダによる開発にむけた体制を構築し、これを統制し、業務の効率性確保・リスク管理・コンプライアンスの確保等を行いつつ、目的実現にむけた参加ベンダの活動を整序する必要がある。

マルチベンダ方式採用時のユーザの責任範囲には、シングルベンダ方式の場合に必要とされるシステム構築にむけたベンダの作業範囲の明確化に加えて、参加ベンダの体制を構築し、役割と責任を整理し、複数ベンダの活動を統制する責任が含まれる。ユーザは、これらのプロジェクトマネジメント業務の支援を特定のベンダに依頼し て行うこともできる。（プロジェクトマネジメントの重要性については後述）なお、ソフトウェア開発委託基本モデル契約書においては、ユーザのプロジェクトマネジメントに対するベンダの協力規定を置いている。当該協力義務の内容は、プロジェクトマ

ネジメントの支援そのものを受託するベンダが行う支援業務とは区別される。

（契約書の規定で考慮すべき事項）

マルチベンダ方式を採用する際には、ユーザは、マルチベンダ方式によるシステム開発の目的及びこれを実現するに足りる各ベンダによる開発体制を明確に規定する。

ユーザは、各ベンダがそれぞれのフェーズにおいてなすべき作業範囲を明確に定め、ユーザとベンダ間の責任範囲を明確にする必要がある。そのうえで、例えば、作業工程、作業の分配、スケジューリング、ベンダ間の責任配分、全体の統制、効率化の確保、規制条件へのコンプライアンス確保、情報流通の確保と統制などを個別契約等において規定する。

マルチベンダ方式の場合、連携するベンダの仕事のとりまとめを特定のプライムベンダに依頼する場合は、当該プライムベンダにおいては、プライムベンダのもとで連携する他のベンダの体制を構築し、役割と責任を整理し、複数ベンダの活動を統制するプロジェクトマネジメント業務に係る責任も生じることから、当該プロジェクトマネジメント業務が委託範囲に含まれることを明記した契約を締結する。なお、当該業務の契約形態は準委任契約である。また、特別なインターフェースソフトの開発が必要となる場合についても、個別の契約が必要となる。

特定のベンダに委託する場合、ユーザは、当該ベンダとの間で、単一ベンダとの契約に際して必要とされる契約内容とともに、当該ベンダと他のベンダとの責任範囲を明確にする必要がある。

マルチベンダ方式がサブシステム毎の分割の場合は、分割されたシステムを単位として契約範囲を定め、各ベンダは、担当した範囲の作業についてのみ責任を負うことになる。

マルチベンダ方式が開発フェーズ毎の分割の場合には、これに加え、前のフェーズ

が後のフェーズの作業内容を規定することになることから、前のフェーズを担当するベンダの責任によって後のフェーズの仕事の内容に生じた瑕疵については、原則として、後のフェーズのベンダがユーザに対して責任を負わないことを定める必要がある。

（4）ユーザとベンダの協力の重要性、役割分担

・ 情報システム構築・運用は、ユーザとベンダの共同プロジェクトである。「情報サービス・ソフトウェア産業維新」においても、「ユーザとベンダが、課題解決のための具体的使命の内容を共有し、その実現に向かってベンダが提供する具体的サービス内容及びその品質レベル、コスト、構成技術、リスク等について明確な合意を持つことが必要」であり、「さらにビジネス改革やビジネスアウトソーシングの場合には、ユーザ業務の一面をベンダが担うことになり、情報システムの構築・運用は経営・業務そのものを含めた共同開発・共同作業としての性格を強く帯びることになり、パートナーシップの認識を両者が持つことが必要になる。そして、その合意内容に従って、情報システム構築・運用で応分の役割と責任を担うことを徹底すべきである。」ことを指摘している。

・ ユーザとベンダは、プロジェクトの開始に先立って、以下の役割分担を行うことを認識し、具体的な役割分担について、契約書において明確に規定すべきである。

企画・要件定義段階、開発段階、運用段階の役割分担（全体像概略）

○：主担当 △：支援

１．機能要件

①機能要件（プロセス）

②機能要件（データ）

③機能要件（インターフェイス）

２．非機能要件

①品質要件

②技術要件

③運用・操作要件

④移行要件

⑤付帯作業

⑥その他

システム設計（システム外部設計）

システム方式設計（システム内部設計）

ソフトウェア設計

プログラミング

ソフトウェアテスト

システム結合

システムテスト

導入・受入支援

機能情報関連図			ユーザ		ベンダ
			業務部門	ＩＴ部門
業務流れ図
			業務処理定義書		○
システム機能階層図				○	○
概念ＥＲ図
データ項目定義書			○	○	△
システム間関連図 システム間インターフェイス定義書			○	○	（ 契約に基づく支援 ）
画面・帳票一覧			○
画面・帳票レイアウト	等		○	○
システム設計書画面処理仕様書			○（外部設計：準委任型）		△ （契約に基づく支援、機能要件・非機能要件の最終確認）
帳票処理仕様書			△（ユーザ確認）		○
業務処理仕様書
データベース設計書 ソフトウェア構成図					○
コンポーネント仕様書
			ソースプログラム		○
単体テスト仕様書・テスト結果報告書
			ソフトウェア適格性確認テスト仕様書 ・テスト結果報告書		○
システム適合性確認テスト仕様書					○
・テスト結果報告書 システム運用マニュアル			○ （システムテスト：準委任型）		△ （契約に基づく支援）
ユーザ利用マニュアル 等			○		△ （契約に基づく支援）
○			△ （契約に基づく支援）
ユーザ：○業務運用ベンダ：○システム運用

（共通フレームによる）

企画プロセス要件定義プロセス	システム化構想
	システム化計画
	要件定義

開 発 プ ロ セ ス	システム要件定義
	システム方式設計
	ソフトウェア要件定義
	ソフトウェア方式設計
	ソフトウェア詳細設計
	ソフトウェアコード作成及びテスト
	ソフトウェア結合
	ソフトウェア適格性確認テスト
	システム結合
	システム適格性確認テスト
	ソフトウェア導入
	ソフトウェア受け入れ支援

システム運用

業務及びシステムの移行

運用テスト

業務運用 システム運用

運用テスト

運 用 プロセス

（ ～ 略 ～ ）

（5）プロジェクトマネジメントの重要性

・ 前述のとおり、情報システム開発プロジェクトは、ユーザとベンダの共同作業であり、プロジェクトの進行にあたっては、プロジェクトマネジメント88が不可欠である。したがって、情報システム開発契約にあたっては、ユーザがプロジェクトマネジメントのプロフェッショナルに対し、必要に応じて、別途プロジェクトマネジメントの支援に関する契約を行うことが望ましい。その契約の性質は、準委任契約である。

・ 適切なプロジェクトマネジメントは、質の高いプロジェクトマネージャーによって可能となる。適切なプロジェクトマネージャーを欠くときには、システムの欠陥率の高まり、仕様確定時期の遅延、要求仕様の変更の多発などを招きやすい。したがって、プロジェクトマネジメント契約にあたっては、プロジェクトマネージャーの技術レベルを契約することが望ましい。また、契約にあたっては、ユーザ・ベンダ双方がプロジェクトマネージャーを設け、プロジェクト進行計画を合意することが必要である。

・ ユーザ側プロジェクトマネージャーとベンダ側のプロジェクトマネージャーは、フェーズ毎に行われる契約に基づき、役割を分担する89。

・ 各フェーズにおけるプロジェクトマネジメント契約においては、プロジェクト運営組織・統制方法・情報伝達の方法などの環境、開発環境の障害、プロジェクトの停止や成果物の破壊に備えた対策と手順、要件の追加・変更に対応した仕様変更と変更管理の工程と手順を予め明確にすることが重要である。

特にマルチベンダ方式による開発の場合は、それぞれのベンダの成果物の検証・評価、ベンダ間・部門間の調整、統制のあり方を明確にすることが不可欠である。

・ また、採用するプロジェクトマネジメントのスキームをプロジェクトマネジメント契約において明確にすることも重要である。

採用するスキームの明確化には、例えば EVM、PMBOK、CMMI など、プロジェクト管理に関する共通スキームを採用することが有効である。特に、マルチベンダ方式による開発では、ユーザ、ベンダ相互間のインテグレーション業務が特に重要であることから、この共通管理スキームの採用は有効である。

・ 成果物の品質と生産性を管理するには、予め開発手順及びその手順を行ったときのレビューを含む生産性を厳密に定義し、開発プロセスで細かく検証する方法が採用されることがあるが、その設計に際しては、予め例外措置や手順違反の際の回復手順も想定しておくことが現実的である。

88 ISO1006 品質マネジメント「PM における品質の指針」があり、これを JIS 化したものとして、 JISQ10006 がある。また、標準知識体系として PMBOK がある。

89 具体的な役割分担については、「システム・リファレンス・マニュアル」（IPA-JUAS）が参考になる。

（6）請負と準委任

・ フェーズ毎に、契約類型として請負と準委任のどちらとするかを選択しなければならない。

・ 請負と準委任の民法上の主たる相違点は以下のとおりである。 a） 仕事の完成義務

請負ではxxxは仕事（受託業務）の完成の義務を負うのに対し、準委任ではベンダは善良な管理者の注意をもって委任事務を処理する義務90を負うものの、仕事の完成についての義務は負わない。別の観点からいえば、請負に馴染むのは、業務に着手する前の段階でベンダにとって成果物の内容が具体的に特定できる場合ということになる。したがって、内部設計やソフトウェア設計などのフェーズは、請負で行うことが可能である。

これに対して、システム化計画や要件定義のフェーズは、ユーザ側の業務要件が具体的に確定しておらず、ユーザ自身にとってもフェーズの開始時点では成果物が具体的に想定できないものであるから、ベンダにとっても成果物の内容を具体的に想定することは通常不可能である。そのため、請負には馴染みにくく、準委任が適切ということになる。

b） 瑕疵担保責任

請負では、仕事の完成義務を負うので、例えばユーザに完成されたものとして引き渡された成果物に瑕疵があった場合、無過失責任としての瑕疵担保責任を負う91。すなわち、このような場合民法（第 634 条乃至第 640 条）によれば、注文者であるユーザは修補や損害賠償を請求することができる。また、瑕疵により契約の目的を達成することができないときは契約を解除することができる。

これに対して、準委任の場合、仕事の完成義務はないので、請負のような瑕疵担保責任を負うことはない。但し、事務処理に関して善管注意義務違反があった場合には、債務不履行責任（例えば不完全な履行を完全なものにすること92や損害賠償責任など）を負うこととなる

・ このように、請負と準委任には法律上の重要な相違点がある。但し、契約書において規定を設けることで、具体的な取引・契約プロセスに合致するように民法や商法の

90 善管注意義務とは、「債務者の職業・地位・知識等において一般的に要求される平均人の注意義務を指す点で抽象的であるが、しかし各具体的な場合の取引の通念に従い相当と認むべき人がなすべき注意の程度」をいう。（「新版注釈民法（16）債権（7）」）

91 契約で過失責任とすること、すなわち過失がある場合にのみ責任を負う場合を限定することも可能である。

92 例えば外部設計書作成支援業務で出来上がった設計書に不備があった場合、xxxが受任者 の善管注意義務を果たしていなかったといえるときは、ベンダは善管注意義務に基づき、不完全 であった債務の履行を完全な履行とするためにユーザにおける設計書の修正に必要な調査、分析、整理、提案及び助言などの支援を行うことになる場合もあろう。

規定を修正することは原則として可能な場合が多い。

・ 上記の違いに加え、契約類型が注目されるのは、請負型をとると、ユーザ側の心理として「丸投げ」「ベンダにすべてお任せ」という意識が強くなる場合があることが指摘された。実際の契約において、準委任型とするか、請負型とするかは、成果物の特定についての当事者同士の経験や役割分担の遂行能力等に基づき、成果物についての共通理解が事前に十分に成立しているかによるが、準委任型としなかった場合、ユーザ自身のシステム化計画や要件定義におけるステークホルダとの調整を行う責任等が曖昧になる傾向にある。その結果、ユーザの対応不足を補完するために、ベンダが、ユーザ内のステークホルダとのコンタクトを取り始め、さらにユーザの自律的な調整機能が発揮されずに、要件定義上の見落としも生じやすくなるとの指摘が多い。

・ あるべき分担モデルとしては、ユーザが、企画プロセスにおいてシステム要件（外部設計に対するインプット）を主体的に決定・明確化する。その上で、開発プロセスにおいて、xxxの責任のもとに要件の仕様化を行う。また、外部設計がユーザにより承認を受けた後は、要件追加、仕様変更、未決事項等は変更管理手続に則り、委託料・納期等の協議を実施することが望ましい。

（7）パッケージ活用型、反復繰り返し型の開発、中小企業ユーザにおける活用の留意点

本モデル取引・契約書は、前述のように、一定の前提をおいて議論されたものである。

再掲）

・ 契約当事者：対等に交渉力のあるxxx・xxxを想定。

(例) 委託者（ユーザ）：民間大手企業、受託者（ベンダ）：情報サービス企業

・ 開発モデル：ウォーターフォールモデル93。

・ 対象システム：重要インフラ・企業基幹システムの受託開発、保守・運用。

そのため、パッケージソフトウェアをビジネスモデル構築のための骨格、構造とするパッケージインテグレーション取引にみられるような自社業務に適合したパッケージの選定（BPR、工数削減等の実現）、フィット＆ギャップの評価、各フェーズやフェーズでのダイナミックな手戻り・反復というプロセスを明記していない。

また、企業規模、ユーザのリテラシーの成熟度によって情報システムの導入形態、契約のあり方も異なってくるところがあると考えられる。

そのため、こうしたケースにおいて、本モデルを活用する場合には以下の点を十分に留意すべきであり、今後、包括的に検討する必要がある。

93 フェーズ内の手順化については詳細に言及していない。

（パッケージ活用を中心としたソリューション提供に本モデルを活用する場合の留意点）

①事業要件定義

②プロジェクトゴールの策定

③要求品質の明確化

④パッケージを利用して実現するBPRの策定

⑤RFI

⑥ベンダ情報

⑦業務要件定義

⑧RFP

⑩フィット＆ギャップ評価

⑨ベンダ提案

①事業要件定義

a. システム化の方向性

⑦業務要件定義

企画・要件定義段階

b. システム化計画

⑫システム要件定義

⑪パッケージ選定

c. 要件定義

⑫システム要件定義

⑬カスタマイズ、アドオンの設計、開発

開発段階

⑭受入・検収

⑮運用

運用段階

①企画・要件定義段階 ａ．システム化の方向性

システム開発の方法としては、一から開発をする「スクラッチ開発」もあれば、ベンダなどが提供する既成の業務パッケージを利用したり、ASP（Application Service Provider）のような社外サービスを利用する場合等があるが、いずれの方法であれ、事前に「a.システム化の方向性」や「b.システム化計画」が明確になっている必要がある。

パッケージ活用を中心としたソリューション提供に本モデルを活用する場合、「a.システム化の方向性」の段階で、「ビジネスモデル」の検討を行い、「①事業要件定義」を確定させ、経営層（社長、担当役員等）の承認を得ておき、基本的なシステム化の軸がぶれないようにしておくことが必要である。

ｂ．システム化計画

「a.システム化の方向性」フェーズで明確にされた「①事業要件定義」を基に、「b.システム化計画」の段階では、「業務モデル」の検討を行い、「⑦業務要件定義」の確定に着手することになる。

パッケージ活用を中心としたソリューションを考慮する場合は、この段階からパッケージの持つ知見やアイデアを調査し、現状の業務体系を見直し、プロジェクトゴール（システム導入の成果）を検討、策定する必要がある。「⑦業務要件定義」の内容は、業務内容（手順、責任、権限など）、業務形態、業務品質、性能目標、運用、移行要件、セキュリティなどである。

②～⑥におけるプロセスは、仮説設定、検証を目的としており、それぞれが独立したプロセスではなく、同時並行的、一体的に推移する場合もあり、大幅な手戻りや見直しが許容される。この時点からコンサルタントやベンダの参画を得る場合もある。

RFI で入手したベンダからのパッケージに関する情報によって、より詳細なプロジェクトゴールや運用形態、BPR が検討される。「⑦業務要件定義」を確定し、RFP をベンダに提示することで、より具体的な情報の収集と検討がなされる。フィット&ギャップ評価では、機能要件と非機能要件の双方の観点からのパッケージの適合性、カスタマイズやアドオンの必要性、既存システムからの移行、要員教育、将来的な拡張性などとともに、保守運用体制、償却期間におけるトータルコストと得られる効果を、パッケージごとに評価する。ここでも、フィット＆ギャップ評価に基づき、プロジェクトゴールや BPR の見直しなど、変更管理の手続をとることにより、上流工程にさかのぼって変更を行うことができる。

最低限確保されるべき応答時間や処理時間などの操作性に代表される品質要件は、 BPR に密接に関連し、技術要件にも大きな影響を及ぼすため、早期に優先度と重要度を明確にすることが望ましい。また、セキュリティ、既存システムからの移行、運用・要員教育、保守・運用等において特段に配慮すべき項目もあわせて抽出しておくことが望ましい。特に、「⑦業務要件定義」が確定した以降は、現場で運用に携わるオペレータ、その他の利害関係者と間で、プロジェクトゴールを共有することが必要である。あわせて、「⑦業務要件定義」を周知し、その同意を得ておくことが重要で、プロジェクトチームと BPR に直面する現場の調整に留意すべきである。

・ パッケージに対するカスタマイズについては、そもそもパッケージが想定していない運用を求めることによって、パッケージの構造そのものの変更などがありえるため、カスタマイズやアドオンの要否を判断する際には、機能の工数と実現性について詳しく評価を行うべきである。

・ フィット＆ギャップ評価においてベンダの参加を求める際、当該作業の内容と責任の所在を決めることが重要である。また、複数ベンダからの提案書及びフィット

＆ギャップ評価を求める場合は、書式の統一、用語の定義等に配慮し、相互理解に十分な時間をかけることが信頼性確保につながることに留意すべきである。

・ パッケージベンダとシステムインテグレーションベンダが異なる場合、システムインテグレーションベンダで解決できない不具合や仕様変更が想定される。ベンダ間の協力体制、パッケージベンダとユーザにおける保守契約も合わせて選定評価の基準とすることが望まれる。

・ パッケージの保守期間は、前提となる OS やハードウェアの世代交代、保守打ち切りに影響される場合がある。パッケージの保守期間、ハードウェアの保守期間とともに OS の動向、保守打ち切りの際の移行、費用についても事前に調査、想定することが望まれる。

ｃ．要件定義

「b.システム化計画」で明確にされた「⑦業務要件定義」を基に、「c.要件定義」の段階では、「システムモデル」の検討を行い、「⑫システム要件定義」の確定に着手することになる。「⑫システム要件定義」の内容は、システム構成、業務アプリケーション（構造、ＤＢ・ファイル構造など）、運用、移行要件、セキュリティ、機密情報保護対策などである。

フィット＆ギャップ評価を得て、パッケージを選定し、必要なアドオン、カスタマイズ、システム構成等を決定し、「⑫システム要件定義」とする。パッケージソフトウェアは一定の開発思想と経済合理性をもって設計されているため、ユーザ仕様に適合しない部分を無理にカスタマイズすることで、一部性能の大幅な低下や、将来の拡張に制限を招く場合があるため、カスタマイズによる制限事項や影響評価を含めた「⑫システム要件定義」に留意する。

・ パッケージ選定によって主要な要件が定義されるため、これ以降の要件追加、変更は大幅なコスト負担又は運用上の制限が加わることが考えられる。将来にわたる外的環境変化に対応するための配慮として、データベースに対する柔軟なインターフェースの確保や異なるアプリケーションソフトウェアとのデータ連携などを視野に入れておくことが望ましい。

・ 最終仕様の決定においては、画面の遷移や帳票の形式、運用手順等を、現場オペレータの参画と承認を得るとともに、導入に備えた教育計画が必須である。導入後の手直しや変更を最低限に留めることは、信頼性向上とコストに重大な影響を及ぼすため、十分に留意する。

・ パッケージに対するカスタマイズによって、基本機能に制限が加わるなどの他の機能に及ぼす影響と、非機能要件に及ぼす影響について確認し、要件定義とする。

・ ハードウェア、ネットワークの高性能化、低価格化に伴い、データ量の増大とデータの分散が顕著である。信頼性要件、セキュリティ要件の観点から、要件定義の最終評価を行うとともに、これらが付随的要件でないことに留意する必要がある。

②開発段階

開発段階は、パッケージベンダ、システムインテグレーションベンダ、それぞれの再委託先など多数のベンダが関与することが想定されるため、ユーザとベンダ間の役割分担のみならず、関係するベンダ間の役割分担についても、十分な事前合意が必要である。加えて、パッケージの品質劣化を招かないため、カスタマイズ及びアドオンを含む開発工程の全体像並びに受入・検収に至る一連のフェーズについて、パッケージベンダにおける確認が可能となるように、パッケージベンダ又はシステムインテグレーションベンダ（あるいはその双方）に情報が集約される仕組みを整備する必要がある。

対象となるパッケージのプログラムは、(1)パッケージの基本機能部分、(2)画面、帳票などのカスタマイズを前提としている部分、(3)新たに開発されるアドオン部分に分類される。プログラム変更、改修が(1)に係る場合は、信頼性に多大な影響を及ぼすとともに、パッケージのバージョンアップやアップデートに際して、アドオン部分の改訂が不可避となり、多大な工数を要する場合など将来に渡る保守可能性を阻害するおそれがある。パッケージベンダと開発ベンダ、ユーザとの十分な相互理解と承認を得た上で、プログラム変更、改修を実施する必要がある。

ユーザが行う受入・検収については、実際の運用を想定したシナリオテストをパッケージベンダを含め、ベンダとユーザにおいて事前に十分検討する必要がある。シナリオテストに使用するデータによってテストの信頼性が大きく異なることから、使用データについては、パッケージベンダを含めて十分な協議が望まれる。

（反復繰り返し型の開発に本モデルを活用する場合の留意点）

・ 反復繰り返し型の開発となる場合には、実現が必要な機能のプライオリティの設定と量的制限（当初見積に対して、どの程度費用がかかったかを確認しながら作業を実施し、当初見積を越えたところで契約内容の見直しを行う。）を契約書において明記しておく必要がある。なお、その際には、当初見積と実績についてのユーザ・ベンダ双方の理解となる見積手法と作業結果の評価方法、反復回数を事前に合意しておくことが重要と考

えられる94。

（中小企業ユーザとの取引において本モデルを活用する場合の留意点）

・ 情報システム開発における超上流工程の重要性は、いかなるケースにおいても変わりはない。そのため、中小企業ユーザのように、ユーザ側の体制が充実していないようなケースにおいても、自社で超上流工程を固めることができない場合には、情報システム開発契約の前提としてコンサルティングを活用すること、あるいは企画・要件定義段階と開発段階とは別契約として契約を締結することが望ましい。

・ ユーザの側では、情報システム構築にかかわる開発コストを早期に確定したいことから、上流工程から一括で発注することが多いことも事実であるが、企画・要件定義段階についてはユーザ側は十分な検討を行い、その内容について責任を持って決定するという前提で、保守運用コストのバランスを考慮したシステムライフサイクル全般の投資対効果を見据えた開発を進める必要がある。

コストの算定にあたっては、上述のモデル取引で示したように、見積条件について、ユーザ・ベンダ間の十分なコミュニケーションが不可欠である。

・ 契約書の重要事項について、前述の「タームシート」等のユーザ・ベンダ間のチェックリストによる確認を行うなど、取引・契約内容について、双方がスムースに理解・共有することができるプロセスを設けることも考えられる。

・ 中小企業に限らないが、特に中小企業の場合には、ユーザに RFP の作成能力がなく、コンサルタントが作成したり、既存システムを構築したベンダが RFP をユーザに代わって作成する場合が多い。

この場合、RFP を記述したベンダしか分からないブラックボックスが機能や要求として存在することがあり、異なるベンダが RFP に基づきシステム開発を請け負った場合に、作業の遅延、費用の大幅な増大といった問題が発生する。このように RFP の作成ベンダと RFP に基づきシステム開発を行うベンダが異なるときには、RFP に重大な瑕疵があった場合も含めユーザは RFP 作成ベンダと後工程を請け負ったベンダとの責任関係を明確にしておく必要がある。

・ また、同様に、上流工程や RFP を担当したベンダ、コンサルタントと、開発工程を担当するベンダが異なる場合は、上流工程担当者をプロジェクトマネジメント・オフィス（PMO）に参画させ、上流工程における不具合や、開発工程での齟齬を防ぐことを目的とした契約を検討するべきである。

94 「信頼性ガイドライン」では、「求められる信頼性・安全性の水準を満たす情報システムの開発にかかる価格の見積値を、その算出根拠（必要なソフトウェア、ハードウェブ及び諸設備費用、要因、工数、工期、リスク等）とともに説明すること」としている。

（8）ハードウェア等調達契約の留意点

ソフトウェア開発委託基本モデル契約書では、以下の理由から、ハードウェア等他の取引を盛り込んでいない。

・ 情報システム構築においては、業務アプリケーションの開発のみならず、ハードウェア、OS、ミドルウェア、ネットワーク基盤、あるいはそれらに関する保守等、様々な取引が発生することが多い。

・ 実際の取引のタイミングも開発プロセス95、運用形態96、調達方法97との関係から、一律ではないことから、こうした全ての取引を一つの契約書に盛り込むことは実務的に馴染まない。

そのため、ソフトウェア開発委託基本モデル契約書においては、これら機器等の調達取引を盛り込んでいないが、情報システムの信頼性xxxの視点から、必要な留意点を以下に示す。

・ 機器等自体の瑕疵に起因するリスクは、当該製造者等とユーザとの契約で対処すべき問題である。

・ 情報システムの非機能要件が明確に定まらないと機器構成等の調達要件を確定できない。非機能要件が曖昧な時点での本番用機器の早期調達は望ましくない98。機器構成等を含めたインフラ設計・運用設計などを行い、完成時の保守・運用体制等の全体像が把握できてから、調達を行うことが望ましい。

・ また、機器等そのものの性能・機能にとどまらず、保証期間、サポート体制（常時・非常時）の充実度などの調達契約の内容も、調達者は十分に留意する必要がある。

・ ネットワーク環境、周辺機器等の接続テストについては、想定できるパターンをテストすることが望ましい。

・ インフラ設計の業務は、ソフトウェアを開発するベンダが担う場合が多いが、この場合、ユーザは、実際のエンドユーザの利用態様等をソフトウェアの要件定義のフェーズなどで早期に明確化することが信頼性確保につながる。

95 通常の情報システム開発の場合、外部設計時点でおおよそのハードウェア、ミドルウェアの 構成を決定するが、非機能要件が精緻化されるのは、内部設計以降の工程となる。そのため、ど の開発プロセスにおいてハードウェア等を調達するかによって、取り決める事項が変わってくる。

96 機器等の調達においても、その後の運用段階の形態によって機器構成や契約のあり方が変わる。例えば、ベンダのデータセンター内にユーザの専用機器をハウジングする場合、ベンダの共用機にホスティングする場合、第三者ベンダのデータセンター内のユーザの専用機器をリモート監視する場合など多様な形態がある。

97 リース会社等を介したリースあるいはレンタルなどの調達形態がある。これらの場合、ユーザとの直接の契約相手はソフトウェア開発ベンダではないため、ユーザ、機器等の保守業者、ソフトウェア開発ベンダとの役割分担を明確にする必要がある。

98 例えば、平均レスポンスタイムの確認について、ソフトウェア、ハードウェアを含めて一括契約した場合とハードウェアを別契約した場合では大きく異なる場合がある。

・ ハードウェアの寿命を越えて利用される可能性が高い情報システムにおいては、ソフトウェア設計・開発時点において、将来の拡張性等を含めた検討を行う必要がある。

・ 当該情報システムと関連し、データを共有する他の情報システムのハード導入時期との兼ね合いにも配慮する必要があるなど、プロジェクトマネジメントの重要性は、前述したとおりである。

・ セキュリティの観点から、機密性、完全性及び可用性99を損なわれることがないように、納入時の確認・検査手順の整備、納入後の保守・点検等の必要性の有無の検討（必要と認めた場合は、機器等の購入先等との保守契約の締結）が必要である100。

99 情報セキュリティは、情報システムの機密性、完全性、可用性を維持することと定義される。 (1)機密性：情報にアクセスすることが認可されたものだけがアクセスできることの保障、(2)完全性：情報及び処理方法の正確さ及び完全である状態を安全に保護すること、(3)可用性：認可されたユーザが、必要な時に情報及び関連財産にアクセスできることを保障すること JIS X 5080）。

100 「政府機関の情報セキュリティ対策のための統一基準（2005 年 12 月 13 日情報セキュリティ政策会議決定）」参照のこと。具体的な規定については、機器等の購入における情報セキュリティ対策実施規程雛形（2006 年 3 月、内閣官房情報セキュリティセンター）を参照のこと。

３．モデル契約書・逐条解説

（１）ソフトウェア開発委託基本モデル契約書

【対象・前提】

・ 契約当事者：対等に交渉力のあるユーザ・ベンダを想定。

(例) 委託者（ユーザ）：民間大手企業、受託者（ベンダ）：情報サービス企業

※中小企業ユーザとの契約のケースは、別途論点を整理。

・ 開発モデル：ウォーターフォールモデル。

※反復繰り返し型等への対応は、別途論点を整理。

・ 対象システム：重要インフラ・企業基幹システムの受託開発。

※パッケージのカスタマイズを前提とした取引は、別途論点を整理。

・ プロセス：共通フレーム 2007（現在改訂中）による標準化されたシステム企画・要件定義段階、開発段階、運用段階、保守段階の定義による。

・ マルチベンダ形態に対応。（プロジェクトマネジメントの条項：第 13 条）

・ 工程分割発注方式において、前工程と当該工程とで受託するベンダが異なる場合、【別紙】記載の条項を追加することで対応可。

・ ハードウェア取引については、本ソフトウェア開発委託契約の対象としない。本モデル契約書とは別途論点を整理。

・ 運用段階、保守段階は別契約書とする（但し、開発契約には「運用テスト」を含む）。

・ 基本契約書は原則としてプロジェクトごとに締結。個別性のある条件（第４条参照） は個別契約書を締結。

ソフトウェア開発委託基本モデル契約書

委託者：ユーザ（以下「甲」という。）と 受託者：ベンダ（以下「乙」という。）とは、コンピュータソフトウェアの開発に係る業務の委託に関して、次のとおりこの契約（以下

「本契約」という。）を締結する。

第 1 章 x x

（契約の目的）

第 1 条 本契約は、甲が、甲の○○○システムのコンピュータソフトウェアの開発にか

かる業務（以下「本件業務」という。）を乙に委託し、乙はこれを受託することに関する基本的な契約事項を定めることを目的とする。

本モデル契約書は、企画フェーズ（要件定義）から開発フェーズまで共通して適用することができる基本契約を想定している（契約プロセスに関しては２．モデル契約プロセスを参照）。

本条では、委託者が甲、受託者が乙、委託対象業務がコンピュータソフトウェアの開発であることを規定する。システム化の対象業務の詳細は、個別業務に関する各個別契約に委ねている。

（定義）

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

① 本件ソフトウェア

本契約及び個別契約に基づき開発されるソフトウェアであって、プログラム、コンテンツ、データベース類及び関連資料など個別契約において定めるもの

② 要件定義書

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

③ 外部設計書

要件定義書に基づき本件ソフトウェアの画面、帳票などのユーザインターフェース、他システムとの通信やデータ入出力等のインターフェースなど、本件ソフトウェ

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

④ システム仕様書

要件定義書及び外部設計書

⑤ x x x 料

本件ソフトウェアの開発過程で生成したもので、本件ソフトウェア、システム仕様書及び検査仕様書に該当しないすべてのもの

⑥ 第三者ソフトウェア

第三者が権利を保有するソフトウェア（サーバ用 OS、クライアント用 OS、ケースツール、開発ツール、通信ツール、コンパイラ、RDB などを含む。）であって、本件ソフトウェアを構成する一部として利用するため、第三者からライセンスを受けるもの（但し、FOSS を除く。）

⑦ FOSS

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

⑧ 要 件 定 義

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

⑨ 外 部 設 計

共通フレーム 2007 のシステム要件定義に相当するもの

⑩ 内 部 設 計

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

⑪ システム結合

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

⑫ システムテスト

共通フレーム 2007 のシステム適格性確認テストに相当するもの

⑬ 導入・受入支援

共通フレーム 2007 のソフトウェア導入、ソフトウェア受け入れ支援に相当するもの

⑭ 運用テスト

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

本条では、ユーザ、ベンダ、その他本契約に関係する第三者に誤解が生じないよう、本契約で使用する用語を明確に定義する。

情報システムやソフトウェア開発に関連する専門用語の多くは明確な定義が存在しておらず、また同一の概念を異なる用語で表す場合も多く、これがユーザ・ベンダ間の共通認識の形成の妨げになっている。例えば、ソフトウェア開発業務の上流工程を「概要設計→基本設計→詳細設計

→論理設計」と区分する場合もあるし、本モデル契約のように「要件定義→外部設計→内部設計」のように区分する場合もある。業務のフェーズを表現する言葉や区分が多様であるということは、それぞれのフェーズにおいてどのような業務を行い、何が成果物であるかについての明確な共通 認識が必ずしも形成されていないことを意味している。これがユーザとベンダの間で各フェーズ においてそれぞれがどのような役割と責任を分担しているのかという認識を曖昧にしている大 きな原因の一つになっている。

本モデル契約では、この問題に対処するため、共通フレーム 2007 に準拠した用語を使用する

こととしている。共通フレーム 2007 とは、ソフトウェアを中心としたシステム開発及び取引のための共通フレームであり、ソフトウェア又はシステムの構想からその廃棄にxxxまでのソフトウェアライフサイクルプロセスを可視化し、共通の枠組みを規定したものである。

（適用範囲）

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

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

ことができるものとする。

本モデル契約では、基本契約たる本契約に基づき、各工程別に、ユーザとベンダの責任と役割分担を明確にした個別契約を締結するという多段階契約方式を採用している。

第 1 項は、本契約の適用範囲を特定し、各工程においては、基本契約となる本契約のほかに、個別契約が適用されることを定めている。

第 2 項は、本契約と個別契約の優先関係を明確にし、個別契約を優先させることを定めている。さらに、本契約及び個別契約がユーザ・ベンダ間の当該個別業務の取引に関する合意のすべてであり（完全合意）、例えばユーザから提示された RFP の内容であっても本契約及び個別契約において規定されていない場合、当事者間の契約内容とはならない。したがって、本契約及び個別契約以外の口頭、書面による合意は効力を有さず、本契約及び個別契約の合意事項の変更は、第 33 条の書面による変更契約の締結によってのみ行われる。

（個別契約）

第 4 条 甲及び乙は、個別業務に着手する前に、甲から乙に提示された提案依頼書（RFP） 及び乙から甲に提案した提案書、見積書を基礎として、当該個別業務について以下の各号のうち必要となる取引条件を定め、個別契約を締結する。

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

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

③ 作業期間又は納期

④ 作業スケジュール

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

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

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

⑧ 作 業 環 x

⑨ 乙が甲の委託に基づき作成し納入すべき物件（以下「納入物」という。）の明細及び納入場所

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

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

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

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

のとする。

本条では、各工程で必要に応じて締結する個別契約において定めておくべき内容を列挙している（各工程に応じて、個別契約で定めるべき内容は異なる。）。

本契約では、本契約締結に先立ち、ユーザからベンダに契約書の中に盛り込むべき重要事項の条件又は要求について記載した提案依頼書（RFP）、ベンダからユーザに提出された提案書、見積書を基礎として締結することになる。RFP に記載すべき基本項目等については、提案依頼書（RFP）の詳細（別紙 2）を、提案書に記載すべき基本項目等については、提案書（プロポーザル）の詳細（別紙 4）を参照。

第 1 号 ベンダの業務の範囲、業務の内容を明確にする（「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 1 を参照）。

第 2 号 個別契約において契約類型を選択する場合、いずれを選択するか定める。本契約において、フェーズの契約類型を定める場合は、当該フェーズに係る個別契約では本号は不

101 例えば、システム設計（外部設計）については、委任、請負双方の可能性があり（本モデル取引・契約書においては両論併記）、個別契約でどちらの契約類型を選択するかを決定することになる。

要となる。

第 3 号 準委任型の場合は作業期間、請負型の場合は成果物の納期を定める。なお、準委任の場合には、作業期間の他、工数等により作業量を取り決める場合がある。請負は特定の仕事を完成させることを目的とするので、通常納期や代金を契約で確定的に定めることが可能となる。他方、準委任ではシステム化計画や要件定義のフェーズのように、委託者から要請される期間について業務を提供することが多いので、工数の実績に基づき算出される方法がとられることが多い。（「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 1 を参照）

第 4 号 作業期間又は納期以外に、業務の遂行に関するスケジュールを定める。

第 5 号 ユーザ・ベンダがそれぞれ担当する役割分担（第 8 条で定める作業責任分担の詳細）を定める。基本的な役割分担について、共通フレームに準拠するなどして、本契約において双方の合意を得ることが重要である（「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 2 を参照）。

第 6 号 連絡協議会の開催頻度（第 12 条第 2 項）等について個別契約で定める。

第 7 号 ユーザからベンダに提供されるソフトウェア開発に必要となる資料、機器、設備等について定める（第 39 条第 1 項、第 2 項、（「３．（２）ソフトウェア開発委託基本モデル契

約書ドキュメントモデル」の参考文書 1 を参照）。

第 8 号 特にユーザの環境において開発作業を行わざるを得ない場合には、個別契約において作業場所等の作業環境の使用条件などについて定める（第 39 条第 3 項）。

第 9 号 納入物の明細、ユーザの事業所など納入場所について定める。

第 10 号 委託料とその支払方法（一括・分割払、工程単価等）を記載する。

第 11 号 納入したソフトウェアの検査期間又は要件定義書及び外部設計書、業務終了報告書の点検期間等について定める。例えば、要件定義書の点検期間（第 17 条）、要件定義書作

成 支援業務終了の点検期間（第 18 条）、外部設計書の点検期間（第 22 条）、外部設計書

作成支援業務終了の点検期間（第 23 条）、本件ソフトウェアの検査期間（第 28 条）等について個別契約で定める。

第 12 号 その他、本契約において定めのない事項や本契約と異なる事項については、個別契約で定めておく。例えば、ユーザ・ベンダが選任すべき責任者の人数（第 9 条第 5 項）、

xx担当者の 人数（第 10 条第 4 項）、プロジェクトマネジメントに対する協力に必要と

なる条件（第 13 条第 2 項）、ソフトウェアを一定の第三者に使用せしめる旨の契約の目的

の特掲（第 44 条第 3 項）等について個別契約で定める。

第 2 項は、個別契約の締結に関する誠実交渉義務を定める。

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

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

本契約では、工程毎の多段階契約と再見積りの考え方を採用していることから、基本契約において委託料及びその支払方法については定めず、各個別契約で定めることとした。

再見積りにおいては、全体予算が決まっている場合に、後工程にしわ寄せが起こり、重要な開発が完遂できないことにならないように、全体の予算管理に留意が必要である。

（作業期間又は納期）

第 6 条 各個別業務の作業期間又は納期は、当該個別業務に係る当該個別契約で定める。

本契約は工程毎の多段階契約を前提としていることから、各個別業務の作業期間・納期については個別契約で定めることとした。

多段階契約においては、発注単位である前工程と後工程の間に空白期間が生ずることにより、全体の工期が事実上短縮されてしまうこと、適正に能力のあるベンダを選定できないリスクが生じることに配慮し、契約単位はもちろん全体工程（完成まで）管理をすることが必要である。

※再委託におけるユーザの事前承諾を設ける場合は A 案、再委託先の選定について原則としてベンダの裁量とする場合は B 案を採用

【A 案 再委託におけるユーザの事前承諾を設ける場合】

（再委託）

第 7 条 乙は、事前に甲の承諾を書面で得た場合又は甲が指定した再委託先に再委託する場合、各個別業務の一部を第三者に再委託することができるものとする。なお、甲が上記の承諾を拒否するには、合理的な理由を要するものとする。

2. 乙が、前項の承諾に関して、甲に対して再委託開始時期の○日前までに当該再委託先の名称及び住所等を記載した書面による再委託承諾申請を通知し、甲から当該通知受領後○ 日以内に具体的理由を明記した書面による承諾拒否の通知がない場合、甲は当該再委託を承諾したものとみなす。

3. 甲の承諾拒否により、乙が他の再委託先を選定することが必要になった場合は、作業期間若しくは納期又は委託料等の個別契約の内容の変更について、第 33 条（本契約及び個別契約内容の変更）によるものとする。

4. 乙は当該再委託先との間で、再委託に係る業務を遂行させることについて、本契約

に基づいて乙が甲に対して負担するのと同様の義務を、再委託先に負わせる契約を締結するものとする。

5. 乙は、再委託先の履行について甲に帰責事由がある場合を除き、自ら業務を遂行した

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

（再委託）

第○条 乙は、乙の責任において、各個別業務の一部を第三者（甲が指定する再委託先も含む。）に再委託することができる。但し、乙は、甲が要請した場合、再委託先の名称及び住所等を甲に報告するものとし、甲において当該第三者に再委託することが不適切となる合理的な理由が存する場合、甲は乙に、書面により、その理由を通知することにより、当該第三者に対する再委託の中止を請求することができる。

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

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

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

は、乙に故意又は重過失がある場合を除き、責任を負わない。

【B 案 再委託先の選定について原則としてベンダの裁量（但し、ユーザの中止請求が可能）とする場合】

インターネット関連やオープンソースなどソフトウェア開発技術の裾野の拡大とスピードアップのため、単一のベンダが大規模なソフトウェア開発を行うことは非現実的であり、多数の再委託先を起用している実態がある。請負の場合、ベンダは仕事の完成、すなわちソフトウェアの完成について責任を負っており、その観点からはベンダが再委託先の選定について責任を負うとともに広汎な裁量を有している（請負契約においては、受注した仕事を受注者が第三者に再委託することは本来自由である。）。また、ユーザの意向によって当初予定していた再委託先の選定ができない場合、当初の見積りよりも開発費用が膨らんだり、開発スケジュールを延長せざるを得なくなる場合もある。

一方で、ユーザにとっても、再委託先が適切な技術力を持っているか、適切なセキュリティ対策を履行しているか否かはソフトウェアの品質や開発スケジュールの遵守に大きな影響を及ぼす重要な事項で、重大な利害を有している。また、実際の開発業務においては、再委託先の従業

員がユーザの施設内で作業を行う場合も多く、セキュリティ対策の問題もある。さらには、再委託先が同時に同業他社の案件にも携わっている場合は、企業秘密の漏洩のリスクが生じるため、そのような再委託先を排除する必要性がある。準委任契約においては、原則として再委託は禁止されるが、システム開発を準委任で行う場合、再委託を一切禁止することは現実的ではない。

そこで、本契約では、再委託について 2 案を用意している。なお、丸投げ禁止の趣旨から、本契約ではベンダが個別業務の全部を再委託することは認めないこととする。

本モデル契約の A 案では、情報システムの品質確保、コンプライアンスを考慮して、再委託はユーザの事前承諾を要件としている。

A 案は、本件業務を第三者に再委託することを、ユーザの承諾を要するものとし、原則として再委託を制限することとしている。しかし、大規模なソフトウェア開発では、プライムベンダがパートナーや下請を使用する実態を踏まえ、ユーザは合理的な理由がない限り承諾を拒めないとすることで、ユーザが不合理な理由で承諾を拒絶することがないように配慮している。ここでいう「合理的な理由」とは、例えば、現に再委託先がユーザと競合する企業のソフトウェア開発業務に関与し、ユーザ独自の業務ノウハウが競合先に流出しかねない危険があること、再委託先の情報セキュリティ確保の措置（「政府機関の情報セキュリティ対策のための政府統一基準」（2005年12 月版）、「外部委託における情報セキュリティ対策実施規定雛形（2006 年 3 月、内閣官房セキュリティセンター）」を参照。）が不十分であること、以前に当該再委託先に業務を委託したが適切に業務が遂行されなかった実績があること、再委託先の経営権に関する紛争の存在、再委託先の財務状況が不健全であること、ユーザにおいて制定している委託先選定基準への不適合102等の状況が想定される。

第 2 項は、ユーザが再委託先を把握した上でその選定を判断するため、ベンダが再委託先の情報をユーザに提供することを義務づけている。また、ユーザが承諾拒否を通知しない場合のみなし承諾を定める。

第 3 項は、ユーザの承諾拒否により新たな再委託先を選定することが必要になった場合には、

作業期間や納期、委託料等に影響がありうることから、本契約及び個別契約内容の変更（第 33条）によるものとする。

第 4 項は、ユーザの承諾ある場合にも、ユーザとベンダ間の本契約に基づくベンダの義務を、再委託先にも負わせることを義務づけている。

第 5 項は、ユーザが再委託について承諾した場合でも、ベンダは自ら業務を遂行した場合と同様の責任を負うものとする。但し、ユーザが指定した再委託先に再委託する場合についてまで、ベンダに責任を負わせることは酷なので、ベンダに故意又は重過失がある場合を除き、再委託先の履行についての責任を負うものではないとする。

102 「金融分野における個人情報保護に関するガイドライン」第 12 条第 3 項第１号では、「委託先の監督」について、委託先選定基準を定め、当該基準に従って委託先を選定するとされており、ユーザの委託先選定基準への不適合による拒絶も考えられる。

B 案は、本件業務を第三者に再委託することを原則として許容している。但し、上記 A 案と同様の「合理的な理由」がある場合、ユーザはベンダが選定した再委託の中止を請求することができるとしている。

第 1 項は、ユーザからの要請がある場合、ベンダは再委託先についてユーザに報告することを義務づけている。

第 2 項は、ユーザの再委託の中止請求を受けた場合には、再委託先の変更により作業期間や納

期、委託料等に影響がありうることから、本契約及び個別契約内容の変更（第 33 条）によるものとする。

第 3 項及び第 4 項は、A 案と同様である。

なお、プライムベンダは、再委託先との間の情報成果物作成委託・役務提供委託の下請取引に関して、下請代金支払遅延等防止法が適用される場合には、契約の締結にあたり、同法を遵守する必要がある。

第 2 章 本件業務の推進体制

（協働と役割分担）

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

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

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

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

「信頼性ガイドライン」において、「商慣行・契約・法的要素に関する事項」として、「情報システム構築の分業時の役割分担及び責任関係の明確化」が重要である旨指摘されている。

これは、情報システム構築の特徴を反映したものである。すなわち、ソフトウェア開発は、ユーザの業務をコンピュータで処理可能にするものである。この業務はユーザ毎に異なり、ユーザこそがその内容の確定についての権限と責任を負っている。但し、「ユーザの業務」といっても、システム開発業務の着手段階ではユーザの責任者自身も完成形をイメージできていないものである。この点で、よくたとえられる建物の建築とは大きな違いがある。ソフトウェア開発業務は

建物の建築とは似て非なるものであることを十分理解しておく必要がある103。

こうした理由から、ソフトウェア開発は、ユーザとベンダが意思の疎通を図りつつ共同作業及び分担作業を適切に行うことが重要である。しかし、その対象となる業務の範囲は広汎で多様なため、しばしば作業項目自体の漏れが生じるし、「この業務は相手方の責任範囲である」という思惑違いも生じる。これがシステム開発におけるトラブルの原因となる場合も多い。そのため、本モデル契約には、ユーザ・ベンダの役割分担を具体的に文書化することとしている。

第 1 項は、システム開発は、ユーザとベンダの共同作業であるという基本認識を確認している。ソフトウェア開発に関する紛争は、このような基本認識の欠如に起因するところが大きい。

第 2 項で定める具体的なユーザとベンダの役割分担の例については、「３．（２）ソフトウェア

開発委託基本モデル契約書ドキュメントモデル」の参考文書 2 を参照。適宜カスタマイズして利用することで、ユーザ・ベンダの役割分担を明確にし、双方の認識を合致させることに役立てることができる。なお、より詳細な役割分担については、個別契約において定めることとしている。第 3 項は、各当事者が実施すべき共同作業又は分担作業を怠った場合には、それぞれ責任を負 うことになることを確認している。例えば、ユーザが実施すべき共同作業又は分担作業に関して債務不履行があった場合には、結果としてソフトウェアが完成しなかったとしてもベンダの帰責事由を認めないことや、ベンダの債務不履行責任に関する損害賠償請求においてユーザ側の過失

相殺事由として考慮することなどが考えられる。

（責任者）

第 9 条 甲及び乙は、各個別契約締結後すみやかに、各個別契約における各自の責任者をそれぞれ選任し、互いに書面により、相手方に通知する。なお、当該個別契約において双方の体制図を定め、当該体制図に当該責任者を記載することをもって通知に代えることができるものとする。

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

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

① 第 17 条所定の要件定義書の確定を行う権限及び責任

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

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

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

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

⑥ 第 36 条所定の未確定事項の確定後、確定した要件定義書、外部設計書の追完、x

103 なお、ＩＴ業界全体のコンサルティング力やエンジニア力の一層の強化が必要不可欠であることは、前述したとおりである。

正の業務を請求する権限及び責任

⑦ 第 37 条所定の変更管理書を相手方に交付する権限

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

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

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

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

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

（③ 第 27 条の検査仕様書作成支援業務の実施に際し、甲から要請された事項の対応に関する権限及び責任）

④ 第 26 条及び第 28 条所定の納入物の検収を求める権限

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

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

⑦ 第 37 条所定の変更管理書を相手方に交付する権限

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

5. 甲及び乙が選任すべき責任者の人数は、各個別契約において定めるものとする。

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

前条で確認したように、情報システム開発は、ユーザとベンダの共同作業であり、それぞれが分担した役割を実施する必要がある。ユーザが開発過程において、内部のステークホルダの意見調整を行って見解を統一した上、どのような機能を要望するのか明確にベンダに伝え、ベンダとともに要望する機能について検討して最終的に機能、画面や帳票を決定し、成果物のレビュー、検収を行うなどの役割を分担することが必要である。

ところで、一般に日本企業は欧米企業と比較して権限と責任の意識が明確でなく、暗黙の了解や信頼関係を基礎として仕事を遂行する傾向がある。そのため、本来通知すべき者とは異なる者に通知して済ませたり、明確なかたちでの通知を行わない場合もある。こうしたことが後々ユーザ・ベンダ間で「言った、言わない」の問題が生じる一因になっている。

そこで、本条では、ユーザ・ベンダ双方において、プロジェクトを管理遂行する責任者（いわゆるプロジェクトマネージャー）として、社内におけるプロジェクトに関する権限を有し、業務知識を有する者を任命する旨を定めている。

第 1 項及び第 2 項では、プロジェクトマネージャーの設置について、相手方に書面をもって報

告することを義務づけている。なお、第 1 項で定めるプロジェクト推進体制図の例については、

「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 3 を参照。

第 3 項及び第 4 項では、本契約で規定するユーザ・ベンダの役割分担について、責任者の権限及び責任を明確化している。ユーザは、必要に応じて、別のベンダと別途ユーザの行うべきプロジェクトマネジメントについての支援に関する契約を締結することを選択できる。なお、第 4

項第 3 号は検査仕様書作成支援業務をユーザがベンダに委託する場合の規定であり、支援業務を委託しない場合は不要となるため括弧を付記している。

（xx担当者）

第 10 条 甲及び乙は、各個別契約締結後すみやかに、本件業務を円滑に遂行するため、責任者の下に連絡確認及び必要な調整を行うxx担当者を選任し、書面により、相手方に通知する。なお、当該個別契約において双方の体制図を定め、当該体制図に当該xx担当者を記載することをもって通知に代えることができるものとする。

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

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

4. 甲及び乙が選任すべきxx担当者の人数は、各個別契約において定めるものとする。

ソフトウェア開発においては、ユーザとベンダが緊密に報告、連絡、質問、回答等を行い、開発を進捗していくことになる。

本条では、ユーザとベンダの円滑な意思疎通を図るため、連絡の窓口を一元化し、互いにxx担当者（いわゆるプロジェクトリーダー）を設置することとしている。

第 1 項で定めるプロジェクト推進体制図の例については、「３．（２）ソフトウェア開発委託基

本モデル契約書ドキュメントモデル」の参考文書 3 を参照。

第 3 項は、xx担当者の権限を、連絡協議会への出席（第 12 条第 3 項）、資料等の提供・返還

その他の処置（第 39 条第 6 項）のほか、本件業務遂行に関する相手方からの要請、指示等の受理及び相手方への依頼、その他日常的な相手方との連絡、確認等とする。

但し、本契約及び個別契約の変更・解除等契約に関する重要な事項については、本条のxx担当者ではなく、前条の責任者が行う。

（業務従事者）

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

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

3. 乙は、本件業務遂行上、業務従事者が甲の事務所等に立ち入る場合、甲の防犯、秩序

維持等に関する諸規則を当該業務従事者に遵守させるものとする。

本条では、ベンダの従業員については、あくまでベンダが指揮命令を行うものであることを規定し、労働者派遣事業の適正な運営の確保及び派遣労働者の就業条件の整備等に関する法律（労働者派遣事業法）に抵触しないことを明確にしている。請負契約でありながら開発担当者を実質的に派遣として働かせて利益を得る偽装請負については、労働者派遣事業法又は職業安定法上問題とされるおそれあるので、プライムベンダは十分注意する必要がある（「派遣と請負により行われる事業の区分基準」（昭和 61 年労働省告示第 37 号）及び職業安定法施行規則第 4 条、xxx労働局「情報サービス業に於ける請負の適正化のための自主点検表」を参照）。

（連絡協議会の設置）

第 12 条 甲及び乙は、本件業務が終了するまでの間、その進捗状況、リスクの管理及び報告、甲乙双方による共同作業及び各自の分担作業の実施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議及び解決その他本件業務が円滑に遂行できるよう必要な事項を協議するため、連絡協議会を開催するものとする。但し、本契約及び個別契約の内容の変更は第 33 条（本契約及び個別契約内容の変更）に従ってのみ行うことができるものとする。

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

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

4. 乙は、連絡協議会において、別途甲乙間にて取り決めた様式による進捗管理報告を作成して提出し、当該進捗管理報告に基づいて進捗状況を確認するとともに、遅延事項の有無、遅延事項があるときはその理由と対応策、本章で定める推進体制の変更（人員の交代、増減、再委託先の変更など）の要否、セキュリティ対策の履行状況、個別契約の

変更を必要とする事由の有無、個別契約の変更を必要とする事由があるときはその内容

などの事項を必要に応じて協議し、決定された事項、継続検討とされた事項並びに継続検討事項がある場合は検討スケジュール及び検討を行う当事者等を確認するものとする。

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

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

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

記載を含むものとする。

システム開発では、xx担当者間のコミュニケーションだけではなく、責任者やエンドユーザや開発担当者等を含めた関係者による会合が必要である。本条は、ユーザ・ベンダによる連絡協議会の開催を定期的に開催することを定める。

連絡協議会はプロジェクトの重要事項を検討し、決定していく重要な場であり、ほとんどのソフトウェア開発プロジェクトで設けられている。こうした会議体の運営で重要なことは、その場で議論された内容を明確に記録に残しておくことである。具体的には議事録を作成し、それに必要な事項を明確に記載することが求められる。しかし、上手くいかないプロジェクトでは、こうした運用が適切になされていない場合がしばしばある。そこで、本モデル契約では、第 12 条第

6 項で議事録の作成手順を明確化した。

なお、各フェーズにおける具体的な連絡協議会（要件定義検討会、外部設計検討会等）については、各条項（第 16 条、第 21 条等）を参照されたい。

第 1 項は、協議会で協議すべき事項について定めた。本モデル契約では、進捗状況・リスクの管理及び報告、ユーザ、ベンダ双方による共同作業及び各自の分担作業の実施状況、システム仕様書に盛り込むべき内容の確認、問題点の協議・解決その他本件業務が円滑に遂行できるよう必要な事項について協議会を開催することとした。

第 2 項は、連絡協議会の開催頻度について、個別契約に基づくことを定める。

第 3 項は、ユーザ、ベンダの責任者及びxx担当者以外の者、例えば、開発担当者やユーザ内の従業員等の出席を認め、相手方の出席要請に応じる義務も明記している。

第 4 項は、ベンダの責任者が、連絡協議会の席上、「進捗管理報告」に基づいて報告を定期的に行う進捗管理を義務づけている。進捗管理報告の事例については「３．（２）ソフトウェア開

発委託基本モデル契約書ドキュメントモデル」の参考文書 4 を参照。

第 5 項は、連絡協議会で決定した事項が当事者により遵守されなければ無意味であるので、これに従うことを義務づけている。

第 6 項は、協議会の議事録の作成をベンダに義務づけるとともに、ユーザが記名押印を怠る場合に備えてみなし承認規定を設けている。

第 7 項は、議事録の必要的記載事項として、連絡協議会において決定された事項、継続検討とされた事項、継続検討事項がある場合は検討スケジュールと検討を行う当事者の記載を義務づける。

（プロジェクトマネジメントの責任）

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

2. 甲が、前項のプロジェクトマネジメントを円滑に遂行するために、本件業務に関する範囲で乙の協力を要請する場合、必要となる条件を個別契約で定めるものとし、乙は個

別契約に従い、甲のプロジェクトマネジメントに必要な協力を行うものとする。

第 1 項は、マルチベンダ形態を採用する場合、情報システムの全体統合リスクは、最終的にユーザ側が負うべきものであることを明確にしている。

マルチベンダ方式採用時のユーザの責任範囲には、シングルベンダ方式の場合に必要とされるシステム構築にむけたベンダの作業範囲の明確化に加えて、参加ベンダの体制を構築し、役割と責任を整理し、複数ベンダの活動を統制する責任が含まれる。

複数ベンダの活動を統制する能力がユーザ側に十分ない場合のユーザのリスクを軽減する方策としては、ユーザの全体管理、調整業務をベンダに委託（準委任契約）することによって確保することが考えられる。このような業務を受託するベンダとしては、マルチベンダとは別のベンダの場合とマルチベンダを構成する一社の場合とがあり得る。例えば、ユーザと契約するプライムベンダが更に他の開発ベンダに再委託する形態において、マルチベンダの一社が当該全体管理・調整業務を担う場合、当該ベンダには、連携する他のベンダの体制を構築し、役割と責任を整理し、複数ベンダの活動を統制するプロジェクトマネジメント業務に係る責任も生じる。この場合、ユーザは、当該プロジェクトマネジメント業務が委託範囲に含まれることを明記した契約を当該ベンダと締結することになる。

第 2 項は、マルチベンダ形態において、ユーザが行うべきプロジェクトマネジメントに対するベンダの協力について必要となる条件を個別契約で定めるものとしている。

第 3 章 本 件 業 務

第 1 節 要件定義作成支援業務

（要件定義作成支援業務の実施）

第 14 条 乙は、第 15 条所定の個別契約を締結の上、本件業務として甲が作成した情報システム構想書104、システム化計画書105等に基づいて、甲による要件定義書の作成作業を支援するサービス（以下「要件定義作成支援業務」という。）を提供する。

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ適

切に行われるよう、善良な管理者の注意をもって調査、分析、整理、提案及び助言などの支援業務を行うものとする。

要件定義は、ユーザが構築しようとするシステムの要求仕様（ソフトウェアで実現すべき機能）をまとめる作業であり、ユーザの業務内容に大きく依存する作業である。そこで、本節では、要件定義作業はユーザが行い、ベンダがこれをサポートする形態の準委任契約を前提として規定する。但し、準委任だからといってベンダが責任を一切負わないわけではなく、受任者として善管注意義務を負っている。この善管注意義務を怠った結果、要件定義作成支援が適切になされなかった場合は、善管注意義務違反として債務不履行責任を負うことになる。

（要件定義作成支援業務に係る個別契約の締結）

第 15 条 甲及び乙は、要件定義作成支援業務について、第 4 条第 1 項記載の

取引条件を協議の上決定し、要件定義作成支援業務に係る個別契約を締結する。

要件定義作成支援業務の範囲等については、第 4 条に従い個別契約で取り決めるものとする。

（要件定義検討会）

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

104 ユーザが、本件ソフトウェアに関してビジネスモデルの検討等を行い、新規事業、社外連携、組織改編、部門間業務分掌変更、セキュリティ等の内容をまとめたもの。

105 ユーザが、ユーザの業務モデルの検討等を行い、業務内容（手順、責任、権限など）、業務形態（ピークなど）、業務品質、性能目標、運用、移行要件、セキュリティ等の内容をまとめたもの。

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

2. 乙も、要件定義作成支援業務の実施のために必要と認めるときは、要件定義検討会を

開催することができるものとし、甲は、これに参加するものとする。

業務上の要求やシステムの機能要件・非機能要件を定義する要件定義書作成のためには、ユーザの業務部門と情報システム部門やベンダとの協働作業が必要となる。

本工程が準委任型であることから、第 1 項は、開催の主体はユーザとし、支援を行うベンダがこれに参加するというかたちで規定している。要件定義書作成のために必要となる事項の明確化又は内容の確認等は、すべて要件定義検討会で行われ、ユーザ及びベンダは検討会での検討結果に拘束される。要件定義検討会での検討結果は、第 12 条に従い、議事録に記録される。

第 2 項は、ベンダも要件定義支援業務の実施のために必要な場合に、要件定義検討会を開催できることを定める。

（要件定義書の確定）

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

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

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

要件定義は、ベンダに RFP を発して概算見積レベルの見積提案を受け、システム設計等を実施するために必要な要件を確定するフェーズである。要件が曖昧なままでは、ベンダによる正確な見積りが困難になり、その後の開発フェーズにおいて問題が生じるおそれがある。

本条は、その後の開発作業の前提となる要件定義書をユーザ・ベンダが確認し、責任者が記名押印により確定させる手続を規定している。

要件定義書の確定のための点検において修正が必要と判断される場合もある。第 1 項但書は、この場合の手続を規定している。

第 2 項は、ユーザ、ベンダ双方の確認をもって要件定義書を確定することを明確にしている。

第 3 項は、第 1 項但書により要件定義書を修正して再点検を行う作業により、当初の想定によりもベンダの作業量が増大したり、スケジュールの延長が必要になる場合など、個別契約の条件に変更が生じる可能性がある場合に、第 33 条に従って必要な変更を行うべきことを規定している。

（業務の終了・確認）

第 18 条 乙は、前条に定める要件定義書の確定後○日以内に、業務終了報告書を作成し、甲に提出する。

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

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

4. 要件定義作成支援業務終了の点検期間内に、甲が書面で具体的な理由を明示して異議

を述べない場合には、甲は要件定義作成支援業務終了の点検期間の満了をもって、業務の終了を確認したものとみなされる。

本工程が準委任型であることから、本条は、ベンダが善管注意義務に基づき適切に支援作業を実施したかを確認するため、作業内容を記録した業務終了報告書により確認を行う手続を規定する。

第 1 項の業務終了報告書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書

ドキュメントモデル」の参考文書 5 を参照。

第 2 項は、報告書の確認が延びることを避けるため、点検期間を明確にする。

第 3 項は、業務終了確認書へのユーザの記名押印によって要件定義書作成支援業務の終了を確認することを定める。業務終了確認書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 6 を参照。

第 4 項は、点検期間内に、ユーザから書面による異議が出されなかった場合のみなし終了確認について規定する。この規定は、ユーザが何らかの理由で適時に確認の手続をとらない場合、後続の作業の遅延をもたらしたり、あるいは確認の有無を明確にしないまま後続の作業に着手することはユーザ・ベンダ間の責任関係を曖昧にするおそれがあることを考慮したものである。

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

※第 2 節においては、外部設計を準委任とする場合は A 案（第 19 条乃至第 23 条）を、請負とする場合は B 案の条文群を採用

【A 案 準委任の場合】

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

第 19 条 乙は、第 20 条所定の個別契約を締結の上、本件業務として甲による外部設計書作成作業を支援するサービス（以下「外部設計書作成支援業務」という。）を提供する。

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

の支援業務を行うものとする。

外部設計書作成は、画面・帳票等、インターフェースに関わる部分の仕様を策定する業務である。これには、ユーザインターフェースや他のシステムとの間のデータ種類やフォーマットの確定が含まれる。外部設計書には、原則として、それに基づいてベンダがプログラムを開発できる情報がすべて記載されている必要がある。外部設計書は要求仕様を詳細化した内容を含むものであるが、要求仕様を決定できるのは、業務内容を決定するユーザである。

そこで、A 案は、外部設計書については、ユーザが責任をもって完成させ、ベンダは、準委任契約における受任者として外部設計書の完成を支援する立場にあることを前提とするものである。但し、準委任だからといってベンダが責任を一切負わないわけではなく、受任者として善管注意義務を負っている。この善管注意義務を怠った結果、外部設計書の作成支援が適切になされなかった場合は、善管注意義務違反として債務不履行責任を負うことになる。

（外部設計書作成支援業務に係る個別契約の締結）

第 20 条 甲及び乙は、外部設計書作成支援業務について、第 4 条第 1 項記載

の取引条件を協議の上決定し、外部設計書作成支援業務に係る個別契約を締結する。

外部設計書作成支援業務の範囲等については、第 4 条に従い個別契約で取り決めるものとする。

（外部設計検討会）

第 21 条 甲は、外部設計書作成のために必要となる事項の明確化又は内容の確認等を行うため、必要と認められる頻度で、外部設計書作成について第 12 条所定の連絡協議会

（以下本節において「外部設計検討会」という。）を開催し、乙は、これに参加して外部設計書作成支援業務を実施するものとする。

2. 乙も、外部設計支援業務の実施のために必要と認めるときは、外部設計検討会を開催

することができるものとし、甲は、これに参加するものとする。

3. 外部設計検討会における検討等により、甲が要件定義書の内容を変更しようとする場

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

画面や帳票などのインターフェースを決定する外部設計書作成のためは、ユーザの業務部門と情報システム部門やベンダとの協働作業が必要となる。

本工程が準委任型であることから、第 1 項は、開催の主体はユーザとし、支援を行うベンダが参加するというかたちで規定している。外部設計書作成のために必要となる事項の明確化又は内容の確認等は、すべて外部設計検討会で行われ、ベンダ及びユーザは検討会での検討結果に拘束される。外部設計検討会での検討結果は、第 12 条に従い、議事録に記録される。

第 2 項は、ベンダも外部設計支援業務の実施のために必要な場合に、外部設計検討会を開催できることを定める。

第 3 項は、外部設計検討会における検討等により、ユーザが要件定義書の内容を変更する場合、個別契約所定の作業期間、委託料等に影響を及ぼす可能性があるため、本契約及び個別契約内容の変更（第 33 条）の手続によることとしている。

（外部設計書の確定）

第 22 条 甲が外部設計書の作成を完了した場合、甲及び乙は、個別契約において定める期間（以下「外部設計書の点検期間」という。）内に外部設計書が、第 17 条の規定により確定された要件定義書及び前条所定の外部設計検討会での決定事項に適合するか点検を行うものとし、適合することを確認した証として甲乙双方の責任者が外部設計書に記名押印するものとする。但し、点検の結果、外部設計書が、第 17 条の規定により確定された要件定義書及び外部設計検討会での決定事項に適合しない部分が発見さ

れた場合、甲は、協議の上定めた期限内に修正版を作成し、甲及び乙は再度上記点検、確認手続を行うものとする。

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

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

本条は、xxxが作成した外部設計書をxxx・xxxが確認し、責任者が記名押印により確定させる手続を規定している。

外部設計書の確定のための点検において修正が必要と判断される場合もある。第 1 項但書は、この場合の手続を規定している。

第 2 項は、ユーザ、ベンダ双方の確認をもって外部設計書を確定することを明確にしている。

第 3 項は、第 1 項但書により外部設計書を修正して再確認を行う作業により、当初の想定によ

りもベンダの作業量が増大したり、スケジュールの延期が必要になるなど、個別契約の条件を変更する必要が生じる場合に、第 33 条に従って個別契約の変更を行うべきことを規定している。

（業務の終了・確認）

第 23 条 乙は、前条に定める外部設計書の確定後○日以内に、業務終了報告書を作成し、甲に提出する。

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

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

4. 外部設計書作成支援業務終了の点検期間内に、甲が書面で具体的な理由を明示して異

議を述べない場合には、甲は外部設計書作成支援業務終了の点検期間の満了をもって、業務の終了を確認したものとみなされる。

本工程が準委任型であることから、本条は、ベンダが善管注意義務に基づき適切に支援作業を実施したかを確認するため、作業内容を記録した業務終了報告書により確認を行う手続を規定する。

第 1 項の業務終了報告書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書

ドキュメントモデル」の参考文書 5 を参照。

第 2 項は、報告書の確認が延びることを避けるため、点検期間を明確にする。

第 3 項は、業務終了確認書へのユーザの記名押印によって外部設計書作成支援業務の終了を確認することを定める。業務終了確認書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 6 を参照。

第 4 項は、点検期間内に、ユーザから書面による異議が出されなかった場合のみなし終了確認について規定する。この規定は、ユーザが何らかの理由で適時に確認の手続をとらない場合、後続の作業の遅延をもたらしたり、あるいは確認の有無を明確にしないまま後続の作業に着手することはユーザ・ベンダ間の責任関係を曖昧にするおそれがあることを考慮したものである。

【B 案 請負の場合】

（外部設計書作成業務の実施）

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

2. 外部設計書作成業務の実施に際し、乙は甲に対して必要な協力を要請できるものと

し、甲は乙から協力を要請された場合には適時に、これに応ずるものとする。

Ｂ案では、外部設計書作成をxxxが請負契約で行う場合の条項について規定する。前フェーズの成果である要件定義書が帳票・画面などユーザの需要を明確に定義できており、ベンダが完成させる仕事の内容が明確になっている場合を想定している。

本工程が請負型であることから、第 1 項は、ベンダが業務遂行の主体として規定している。請負形態の場合であっても、外部設計はユーザの業務内容の確定に関わる部分が大きいことからユーザの積極的関与が重要である。そこで、第2 項は、ベンダはユーザに対しシステム仕様の検討・決定に必要な協力を要請することができ、ユーザは適時にこれに応するものとし、システム仕様の検討はベンダとユーザの共同作業であることを明確にしている。

（外部設計書作成業務に係る個別契約の締結）

第○条 甲及び乙は、外部設計書作成業務について、第 4 条第 1 項記載の取引条件を協議の上決定し、外部設計書作成業務に係る個別契約を締結する。

外部設計書作成業務の範囲等については、第 4 条に従い個別契約で取り決めるものとする。

（外部設計検討会）

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

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

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

33 条（本契約及び個別契約内容の変更）の手続によるものとする。

本工程が請負型であることから、第 1 項は、開催の主体はベンダとし、ユーザがこれに参加するというかたちで規定している。外部設計書作成のために必要となる事項の明確化又は内容の確認等は、すべて外部設計検討会で行われ、ベンダ及びユーザは検討会での検討結果に拘束される。外部設計検討会での検討結果は、第 12 条に従い、議事録に記録される。

第 2 項は、ユーザも外部設計書作成業務の実施のために必要な場合に、外部設計検討会を開催できることを定める。

第 3 項は、外部設計検討会における検討等により、ユーザが要件定義書の内容を変更する場合、個別契約所定の作業期間、委託料等に影響を及ぼす可能性があるため、本契約及び個別契約内容の変更（第 33 条）によることとしている。

（外部設計書の納入）

第○x xは個別契約に定める期日までに、外部設計書及び外部設計書検収依頼書（兼納品書）を甲に納入する。

本工程が請負型であることから、ベンダは外部設計書等を成果物として納入する。

外部設計書検収依頼書（兼納品書）の例については、「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 7 を参照。

（外部設計書の承認及び確定）

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

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

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

外部設計工程では、その後の内部設計書の作成等を実施するために必要な要件を確定する。要件の確定が曖昧なままでは、その後の開発において問題が生じるおそれがある。

本条では、その後の開発作業の前提となる外部設計書をユーザが点検し、ユーザの承認により確定させる手続を規定している。外部設計書承認書の例は「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 8 を参照。

第 1 項は、xxxは、外部設計書について、第 17 条で確定された要件定義書及び外部設計検討会での検討結果との適合性並びに論理的誤りがないかを点検する。外部設計書の承認のための点検において修正が必要と判断される場合もある。第 1 項但書は、この場合の手続を規定している。

第 2 項は、仮に承認の記名押印が未了でも一定期間内にユーザから異議が述べられなければ、ユーザによる承認がなされたものとみなす規定である。ユーザからの承認の有無が曖昧なまま内部設計に入ることは、後になって「言った、言わない」の問題を引き起こすおそれがある。本項

はこうした問題を防止することを意図したものである。

第 3 項は、ユーザの承認をもって外部設計書は確定することを定める。

（瑕疵担保責任）

第○条 前条の確定後、外部設計書について要件定義書及び第○条所定の外部設計検討会での決定事項との不一致又は論理的誤り（以下本条において「瑕疵」という。）が発見された場合、甲は乙に対して当該瑕疵の修正を請求することができ、乙は、当該瑕疵を修正するものとする。但し、乙がかかる修正責任を負うのは、前条の確定後○ヶ月以内に甲から請求がなされた場合に限るものとする。

2. 前項にかかわらず、瑕疵が軽微であって、外部設計書の修正に過分の費用を要する場合、乙は前項所定の修正責任を負わないものとする。

3. 第 1 項の規定は、瑕疵が甲の提供した資料等又は甲の与えた指示によって生じたときは適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げ

なかったときはこの限りでない。

本条は、外部設計書に関する瑕疵担保責任について定める。

瑕疵担保期間は、情報システムの規模や対価等を考慮してケースバイケースにより、当事者間で定めるべきであることから、本契約では具体的な期間は明示しない。

第 1 項は、外部設計書と要件定義書及び外部設計検討会での決定事項との不一致又は外部設計書の論理的誤りを瑕疵とする。

第 2 項では、瑕疵が軽微であっても、納入物の修正に過分の費用を要する場合に無償での修正

をベンダに求めるのは酷であるので、民法第 634 条第 1 項但書に準じた規定を設けている。該当するケースとしては、以下のような例が考えられる。

（例 1）画面変更

画面上のある入力項目の位置を変更する場合だけであっても、他の画面デザインに大きな影響

（例えば、スペースの関係から他の表示等の位置も色々変えなければならないような場合）が発生することがある。このような場合、画面定義体を大幅に変更すると当該画面と連携している他の画面あるいはプログラム等の呼び出しを変更するなど、実質的に多くの作業が伴い費用が膨らむ場合がある。

（例 2）プルダウンメニューへの項目追加

あるプルダウンメニューに項目を一つ追加するだけであっても、当該プルダウンメニューでの選択項目と関連するプログラムあるいは DB 全てについて調査、修正、検証などに多くの費用が必要な場合がある。

第 3 項は、民法第 636 条但書に準じ、瑕疵がユーザの指示や提供した資料等に起因する場合にはベンダは担保責任を負わず、ベンダが資料等又はユーザの指示が不適当であることを知って指

摘しない場合には担保責任を免れないとする規定である。

瑕疵担保責任に基づく損害賠償については、第 53 条を参照。

第 3 節 ソフトウェア開発業務

（ソフトウェア開発業務の実施）

第 24 条 乙は、第 25 条所定の個別契約を締結の上、本件業務として前各節により確定したシステム仕様書に基づき、［【選択案１：システムテスト・準委任型】内部設計からシステム結合まで 【選択案２：システムテスト・請負型】 内部設計からシステムテストまで］のソフトウェア開発業務を行う。

2. ソフトウェア開発業務の実施に際し、乙は甲に対して必要な協力を要請できるものと

し、甲は乙から協力を要請された場合には適時に、これに応ずるものとする。

本節では、ソフトウェア開発をベンダが請負型で行う場合の条項について規定する。

このフェーズにおいても、システム仕様の解釈等についてユーザに確認が必要な場合があるので、第 2 項は、ベンダはユーザに対し必要な協力を要請することができ、ユーザは適時にこれに応ずるものとしている。

システムテスト工程を【準委任型】とするか、【請負型】とするかは、システム外部設計を【準委任型】とするか【請負型】とするか（第 19 条において規定）を踏まえて決定するのが望ましく、品質保証の視点ではシステムテスト工程とシステム外部設計の契約類型は同じであることが論理的である（１．（４）（フェーズの分類と契約類型）注 30 参照）。

（外部設計を【準委任型】とし）内部設計からシステム結合までを【請負型】、システムテストを【準委任型】とする場合には、本条（第 24 条）及び第 30 条において【選択案１：システムテスト・準委任型】を選択する必要がある。

また、（外部設計を【請負型】とし）内部設計からシステム結合に加えてシステムテストまでを【請負型】とする場合には、本条（第 24 条）及び第 30 条において【選択案２：システムテスト・請負型】を選択する必要がある。

（ソフトウェア開発業務に係る個別契約の締結）

第 25 条 甲及び乙は、当該ソフトウェア開発業務について、第 4 条第 1 項記載の取引条件を協議の上決定し、ソフトウェア開発業務に係る個別契約を締結する

ソフトウェア開発業務の範囲等については、第 4 条に従い個別契約で取り決めるものとする。

（納入物の納入）

第 26 条 乙は甲に対し、個別契約で定める期日までに、個別契約所定の納入物を検収依頼書（兼納品書）とともに納入する。

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

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

4. 納入物の滅失、毀損等の危険負担は、納入前については乙が、納入後については甲が、

それぞれこれを負担するものとする。

本工程が請負型であることから、完成したソフトウェア等を検査の対象となる成果物として納入する。

第 1 項は、納入物を検収依頼書（兼納品書）とともに納入することを定める。検収依頼書（兼納品書）の例については「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 9 を参照のこと。

第 2 項は、ユーザによる検査の実施について定める。

第 3 項は、個別契約で定めた納入場所への納入については、ユーザの協力を要する場合（ユーザの事務所に搬入して納入する場合、ユーザの実運用環境に稼動可能な状態で納入する場合等）もありうることから、ユーザの協力義務を定める。

第 4 項は、納入物に生じた滅失・毀損の危険負担に関する条項であり、物理的な支配の移転により危険負担の移転時期を分けた。

（検査仕様書の作成及び承認）

第 27 条 甲は、乙と協議の上、システム仕様書に基づき前条の納入物の検査の基準となるテスト項目、テストデータ、テスト方法及びテスト期間等を定めた検査仕様書を作成し、乙に提出するものとし、乙の責任者はシステム仕様書に適合するかの点検を行い、適合することを承認する場合、検査仕様書に記名押印の上、甲に交付して承認するものとする。但し、点検の結果、検査仕様書にシステム仕様書に適合しない部分が発見さ れた場合、甲は、協議の上定めた期限内に修正版を作成して乙に提示するものとし、乙は再度上記点検、承認手続を行うものとする。

2. 乙の責任者は、個別契約で定める期間（以下「検査仕様書点検期間」という。）内に検査仕様書の点検を終えるものとし、乙の責任者が、検査仕様書点検期間内に書面による具体的な理由を明示した異議の申出をすることなく検査仕様書を承認しない場合、当

該期間の満了をもって検査仕様書は承認されたものとする。

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

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

る。

本条では、第 28 条の検収に先立ち、検収における基準となる検査仕様書の作成・承認について定める。検査仕様書はシステム仕様書に基づき、仕様書、テスト項目、テストデータ、テスト方法及びテスト期間等を定めるものとする。

検収はユーザが中心となって実施するものであることから、検査仕様書作成は原則としてユーザが行う。

第 1 項は、ユーザがベンダと協議の上、検査仕様書を作成することとし、xxxとともにこれを確定することとしている。

第 2 項は、検査仕様書の点検が延びることを避けるため点検期間を明確にし、ベンダが検査仕様書についての点検結果に基づく対応を怠る場合についてのみなし承認を定める。

第 3 項・第 4 項は、ユーザは、ソフトウェア開発業務に関する個別契約締結までに、ベンダに検査仕様書の作成支援業務を別途委託することもできる。検査仕様書の策定にはソフトウェア開発業務を実際に行ったベンダの積極的関与が不可欠な場合が多いことを考慮したものである。

（本件ソフトウェアの検収）

第 28 条 納入物のうち本件ソフトウェアについては、甲は、個別契約に定める期間（以下、「検査期間」という。）内に前条の検査仕様書に基づき検査し、システム仕様書と本件ソフトウェアが合致するか否かを点検しなければならない。

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

3. 検査合格書が交付されない場合であっても、検査期間内に甲が書面で具体的な理由を

明示して異議を述べない場合は、本件ソフトウェアは、本条所定の検査に合格したものとみなされる。

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

本条では、納品されたソフトウェアに関する検収を行う手続について定める。

第 1 項は、本件ソフトウェアについて、検査期間内に検査仕様書に基づき検査し、システム仕様書と本件ソフトウェアが合致するかを点検することを規定する。

第 2 項は、本件ソフトウェアがシステム仕様書に適合しないことが判明した場合、xxxはこれを修正して、修正版をユーザに納入することを義務づけている。検収合格書の例については、

「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 10 を参照のこと。

第 3 項は、みなし検査合格に関する規定を定めることにより、ユーザの都合により検収が引き延ばされることを防ぐものである。

第 4 項は、検査合格をもって本件ソフトウェアの検収完了とすることを明記する。

（瑕疵担保責任）

第 29 条 前条の検査完了後、納入物についてシステム仕様書との不一致（バグも含む。以下本条において「瑕疵」という。）が発見された場合、甲は乙に対して当該瑕疵の修正を請求することができ、乙は、当該瑕疵を修正するものとする。但し、乙がかかる修正責任を負うのは、前条の検収完了後○ヶ月以内に甲から請求された場合に限るものとする。

2. 前項にかかわらず、瑕疵が軽微であって、納入物の修正に過分の費用を要する場合、乙は前項所定の修正責任を負わないものとする。

3. 第 1 項の規定は、瑕疵が甲の提供した資料等又は甲の与えた指示によって生じたとき

は適用しない。但し、乙がその資料等又は指示が不適当であることを知りながら告げなかったときはこの限りでない。

x条は、納入物に関する瑕疵担保責任について定める。

履行がなされていない(仕事が完成していない)場面での債務不履行責任と履行が一応完了した(仕事が完成した)後の場面での瑕疵担保責任の境界は実務上判断が難しいところがある。システム開発についてシステムを完成させたと認められるか否かは、仕事が当初の請負契約で予定していた最後の工程まで終えているか否かを基準とすべきであるとする裁判例（東京地判平成 14

年 4 月 22 日）がある。ソフトウェアを予定されている最後の工程まで終えて納品及び検査合格後、瑕疵が発見された場合には、原則として瑕疵担保責任が適用されることになると考えられる。

第 1 項は、ソフトウェア開発業務において生じた「システム仕様書との不一致（バグも含む。）」

を瑕疵とする。外部設計段階で生じた機能不足などについては、本条ではなく、外部設計段階における瑕疵担保責任などの規定により責任の所在が決まる。なお、本件ソフトウェアに関するセキュリティ対策については、具体的な機能、遵守方法、管理体制及び費用負担等を別途書面により定めることとしている（第 50 条参照）。セキュリティ要件をシステム仕様としている場合には、

「システム仕様書との不一致」に該当し、本条の「瑕疵」に含まれる。

ソフトウェアの瑕疵については、「情報処理システムの開発に当たっては、作成したプログラムに不具合が生じることは不可避であり、プログラムに関する不具合は、納品及び検収等の過程における補修が当然に予定されているものというべきである。（中略）システムの納品及び検収後についても、注文者から不具合が発生したとの指摘を受けた後、請負人が遅滞なく補修を終えるか、注文者と協議した上で相当な代替措置を講じたと認められるときは、システムの瑕疵には当たらないものと解するのが相当である。」と判断している裁判例がある（東京地判平成 14 年 4月 22 日等）。

瑕疵担保期間は、情報システムの規模や対価等を考慮してケースバイケースにより、当事者間で定めるべきであることから、本モデル契約では具体的な期間は明示しない。

第 2 項では、瑕疵が軽微であっても、納入物の修正に過分の費用を要する場合に無償での修正

をベンダに求めるのは酷であるので、民法第 634 条第 1 項但書に準じた規定を設けている。

第 3 項は、民法第 636 条但書に準じ、瑕疵がユーザの指示や提供した資料等に起因する場合にはxxxは担保責任を負わないが、ベンダがかかる資料等又はユーザの指示が不適当であることを知って指摘しない場合には担保責任を免れないとする規定である。

瑕疵担保責任に基づく損害賠償については、第 53 条を参照。

第 4 節 ソフトウェア運用準備・移行支援業務

（ソフトウェア運用準備・移行支援業務の実施）

第 30 条 乙は、第 31 条所定の個別契約を締結の上、本件業務として甲が行う［【選

択案１：システムテスト・準委任型】システムテスト、導入・受入支援及び本件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準備･移行支援業務」という。） 【選択案２：システムテスト・請負型】導入・受入支援及び本件ソフトウェアを現実に運用するために行う運用テスト業務につき、甲のために必要な支援（以下「ソフトウェア運用準備･移行支援業務」という。）］を行う。

2. 乙は、情報処理技術に関する専門的な知識及び経験に基づき、甲の作業が円滑かつ効

果的に行われるよう、善良な管理者の注意をもって支援業務を行うものとする。

本節は、ソフトウェア運用準備・移行についてユーザが主体となって行い、ベンダがこれを支援する形態の準委任型とする規定である。

第 2 項は、xxxは、受任者として善管注意義務を負うことを定める。

準委任型の契約の対象として、システムテストを含める場合には選択案１を、システムテストを含めない場合には選択案２を選択することになる。選択肢の決定にあたっては、第 24 条と整合的である必要があり

（外部設計を【準委任型】とし）内部設計からシステム結合までを【請負型】、システムテストを【準委任型】とする場合（第 24 条において【選択案１：システムテスト・準委任型】を選

択する場合）、第 30 条においては必ず【選択案１：システムテスト・準委任型】を選択する必要がある。

また、（外部設計を【請負型】とし）内部設計からシステム結合に加えてシステムテストまでを【請負型】とする場合（第 24 条において【選択案１：システムテスト・請負型】を選択する

場合）、第 30 条においては【選択案２：システムテスト・請負型】を選択する必要がある。

（ソフトウェア運用準備・移行支援業務に係る個別契約の締結）

第 31 条 甲及び乙は、当該ソフトウェア運用準備・移行支援業務について、第 4 条第 1 項記載の取引条件を協議の上決定し、ソフトウェア運用準備・移行支援業務に係る個別

契約を締結する。

ソフトウェア運用準備・移行支援業務の範囲等については、第 4 条に従い個別契約で取り決めるものとする。

（業務の終了・確認）

第 32 条 乙は、ソフトウェア運用準備・移行支援業務の終了後○日以内に、業務終了報告書を作成し、甲に提出する。

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

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

4. ソフトウェア運用準備・移行支援業務終了の点検期間内に甲が書面で具体的な理由を

明示して異議を述べない場合には、ソフトウェア運用準備・移行支援業務終了の点検期間の満了をもって、業務の終了を確認したものとみなされる。

本条では、準委任型として、ソフトウェア運用準備・移行支援作業を、ベンダが善管注意義務に基づき適切に行ったかどうかの確認を行う手続を定める。

第 1 項は、xxxはユーザに対し、業務終了後所定の期間内に業務終了報告書を提出することとする。業務終了報告書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 11 を参照。

第 2 項は、点検期間を明確にした上で、ユーザが業務終了報告書の確認を行うことを定める。

第 3 項の業務終了確認書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書

ドキュメントモデル」の参考文書 12 を参照。

第 4 項は、ユーザが業務終了確認を怠る場合のみなし確認を定める。

第 4 章 契約内容等の変更

（本契約及び個別契約内容の変更）

第 33 条 本契約及び個別契約の内容の変更は、当該変更内容につき事前に甲乙協議の上、別途、書面により変更契約を締結することよってのみこれを行うことができる。

口頭による契約変更はトラブル発生の原因となるため、本条では、本契約及び個別契約に関するすべての契約内容の変更は、書面による変更契約の締結によるものとしている。

（システム仕様書等の変更）

第 34 条 甲又は乙は、システム仕様書、検査仕様書、第 35 条により甲に承認された中間資料（以下総称して「仕様書等」という。）の内容についての変更が必要と認める場合、その変更の内容、理由等を明記した書面（以下「変更提案書」という。）を相手方に交付して、変更の提案を行うことができる。

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

できるものとする。

ソフトウェア開発においては、一旦確定した仕様を追加変更しようとする場合、納期、コストや情報システムの性能・品質等に影響が及ぶ可能性があり、仕様変更に関わるトラブル（ベンダがユーザに仕様変更に伴う追加代金を請求するケースや、ユーザからは「瑕疵がある」「納期を遅延している」などの主張がされるケース等では、仕様変更の有無や対価、納期の変更の必要性をめぐってユーザ・ベンダ間で対立がしばしば生じる。）が発生しやすい。

そこで、本契約では、仕様変更については、ユーザ・ベンダ間においてスケジュール、コストや情報システムに対する影響を考慮した上で、当事者間のやりとりを全て文書化しておくことが紛争発生の予防として有効であるとの前提に立ち、本条では、変更の対象を明らかにした上で、変更の要求・提案は必ず書面により行うことを定める。

第 1 項では、システム仕様書、検査仕様書、第 35 条によりユーザに承認された中間資料について、変更を求める当事者は変更の内容、理由等を明記した変更提案書を提出して、変更の要求又は提案を行うことを義務づける。変更提案書の例については、「３．（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 13 を参照。

第 2 項は、仕様書等の内容の変更については、第 37 条の変更管理手続によることを定める。

（中間資料のユーザによる承認）

第 35 条 乙は、中間資料のうち、乙が必要と認める部分を提示して、甲の承認を書面で求めることができる。

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

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

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

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

ができる。

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

各個別業務の途中段階において、システム仕様の細部やユーザインターフェース等のユーザによる仕様について、ベンダが中間資料の確認のためユーザに承認を求めることが必要な場合がある。本条では、ベンダがソフトウェア開発の過程で作成した中間資料について、ベンダがユーザに承認を求める手続について定める。

適切なスケジュール管理や品質管理のためには、中間資料の承認は重要であるが、あらかじめ個別契約で承認が必要な中間資料を特定して定めることは困難であるため、本条では、ベンダが中間資料の承認が必要と認める部分について、ユーザの責任者の承認を書面で求めることができることとした。

第 2 項は、承認された中間資料も変更管理手続（第 37 条）の対象となることから、ユーザは記名押印の上、点検結果をベンダに交付することとしている。

第 3 項は、ユーザが中間資料の承認を拒否又は留保できる場合について定める。

第 4 項は、ユーザが中間資料の点検を怠る場合のみなし承認を定める。

第 5 項・第 6 項は、ユーザが承認した中間資料の変更については、変更提案書を交付したうえで、変更管理手続によって行うことを定める。承認した中間資料については、その内容の変更には変更管理手続を要するとして、ユーザ承認に一定の拘束力を認めることとしたものである。

（未確定事項の取扱い）

第 36 条 甲は、乙が本件業務を遂行するのに必要な事項を、甲のやむを得ない事情により確定して提示することができない場合、甲は、当該未確定事項の内容とその確定予定時期、未確定事項の確定により請求する追完、修正により委託料、作業期間、納期及びその他の契約条件の変更を要する場合に甲がこれを受け入れること、その他必要となる事項を甲が確認の上．甲乙記名押印した書面を作成することにより、甲は、当該未確定事項の確定後、乙に対して確定した要件定義書、外部設計書の追完、修正の業務を請求することができるものとする。この場合、甲は未確定事項が確定したときは直ちに乙にその内容を書面で提示するとともに、必要となる要件定義書又は外部設計書の追完又は修正の業務をすみやかに乙に請求するものとする。

2. 甲による追完又は修正の請求は、第 37 条（変更管理手続）によってのみこれを行う

ことができるものとする。。

本モデル契約では、システム仕様書について、ユーザの承認により確定することとしているが、やむを得ない事情により未決事項が残される場合もありうる。また、実際のプロジェクトでは、ある程度の積み残し事項を残したまま、次のフェーズに進まざるを得ないことが多いという実態がある。

そこで本条は、未確定事項の取扱いを曖昧にすることのないように、ユーザ・ベンダ間において、将来未確定事項の確定に伴いあり得べき追完修正を明確に予測しつつ、開発プロセスにおける要件や仕様の未確定事項の取扱いについて定めている。

第 1 項では、ユーザは、事前に、ユーザ・ベンダ間において未確定事項、確定の予定時期等を書面で確認していれば、要件定義書又は外部設計書の確定後であっても要件定義書、外部設計書の追完、修正を請求できることとしている。そして、ユーザがかかる請求を行う場合、未確定事項確定後直ちに確定した事項の内容をベンダに直ちに提示し、要件定義書、外部設計書の追完．修正をすみやかに請求することとする。

第 2 項は、要件定義書、外部設計書の追完又は修正の請求は、変更管理手続によることとする。

（変更管理手続）

第 37 条 甲又は乙は、相手方から第 34 条（システム仕様書等の変更）、第 35 条（中間資料のユーザによる承認）、第 36 条（未確定事項の取扱い）に基づく変更提案書を受領した場合、当該受領日から○日以内に、次の事項を記載した書面（以下「変更管理書」という。）を相手方に交付し、甲及び乙は、第 12 条所定の連絡協議会において当該変更の可否につき協議するものとする。

① 変更の名称

② 提案の責任者

③ 年 月 日

④ 変更の理由

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

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

⑦ 検討期間を含めた変更作業のスケジュール

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

2. 第 1 項の協議の結果、甲及び乙が変更を可とする場合は、甲乙双方の責任者が、変更管理書の記載事項（なお、協議の結果、変更がある場合は変更後の記載事項とする。以下同じ。）を承認の上、記名押印するものとする。

3. 前項による甲乙双方の承認をもって、変更が確定するものとする。但し、本

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

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

ソフトウェア開発プロセスの途中段階では、システム仕様の機能追加や変更等種々の変更がしばしばなされる。こうした変更は、開発作業のスケジュール、費用に影響を与える可能性が高いことから、厳格な手続で行われるべきである。また、こうした変更が口頭でなされると、仕様変更の有無、内容について認識がユーザとベンダ間で共有できず、ひいては役割分担や責任範囲を曖昧にし、ソフトウェアの品質に悪影響を与える一因にもなる。

本条では、開発プロセスの進展に伴う、システム仕様書等の変更（第 34 条）、ユーザ承認済み

の中間資料の変更（第 35 条）、未確定事項の追完又は修正（第 36 条）について、口頭での合意による曖昧さを排除し、その必要性、スケジュール・費用への影響をユーザ・ベンダ双方が協議するプロセスを定めている。

第 1 項は、当事者から変更提案書による変更要請があった場合、相手方は所定の事項を記載し

た変更管理書を作成した上で協議を行うことを定める。変更提案書・管理書の例については「３．

（２）ソフトウェア開発委託基本モデル契約書ドキュメントモデル」の参考文書 13 を参照。

第 2 項は、協議の結果、変更を可とする場合には、双方の責任者の記名押印を要求し手続を厳格に行うことにしている。変更協議が不調に終わった場合については次条参照。

第 3 項は、仕様書等の変更は、開発の範囲やスケジュール、費用に影響を及ぼす場合があるた

め、その場合には、第 33 条の定めに従い、変更契約を締結することが変更確定の条件となっている。

第 4 項は、変更の可否を協議している間の開発の進捗に関する対応を定める。協議期間中は、契約変更がなされているわけではないので、原則ベンダは、本契約及びその時点の個別契約の条件に従って開発作業を進めるべきこととなる。しかし、ユーザ・ベンダの意見の隔たりが大きく協議が整わないことが確実視されるようなときで、ユーザから中断要請がある場合など「特段の事情」がある場合は、ベンダが業務を継続しても無駄になることが確実なので、業務を中断することができることを規定した。

（変更の協議不調に伴う契約終了）

第 38 条 前条の協議の結果、変更の内容が作業期間又は納期、委託料及びその他の契約条件に影響を及ぼす等の理由により、甲が個別契約の続行を中止しようとするときは、甲は乙に対し、中止時点まで乙が遂行した個別業務についての委託料の支払い及び次項の損害を賠償した上、個別業務の未了部分について個別契約を解約することができる。

2. 甲は、前項により個別業務の未了部分について解約しようとする場合、解約により乙

が出捐すべきこととなる費用その他乙に生じた損害を賠償しなければならない。

連絡協議会において変更の可否につき協議した結果、コストや納期の変更等についてユーザが受け入れることができない場合には、本条により個別契約の解約を選択することができる。システム開発の途中段階で、変更が必要になったものの変更協議が不調に終わった場合に、ユーザのニーズに沿わない情報システムの完成を強いることは無意味である。また、ベンダにとっても、途中解約による損害が民法第 641 条の趣旨（仕事が未完成の間になされた注文者の契約解除に伴う損害賠償義務）に従い、確実に賠償されれば、これを認めても不利益はない。重要なのは、変更管理に関するユーザの意思決定が速やかになされることである。

本条は、当該個別契約が請負型であれ準委任型であれ、ユーザは、ベンダに、仕事の出来高に応じた報酬を支払い、発生した損害を賠償しなければならないこととしてベンダの保護を図っている。

なお、ベンダによる解約権を規定していないのは、ベンダとしては変更協議の合意が成立しない限り従前の条件で業務を遂行すればそれで債務を履行したことになることから、特に解約権を認める必要性がないと考えられるためである。ユーザ・ベンダの意見の隔たりが大きく協議が整

わないことが確実視されるようなときで、ユーザから中断要請がある場合は、前条の解説で述べたように、業務を中断することができる。

第 5 章 資料及び情報の取扱い

（資料等の提供及び返還）

第 39 条 甲は乙に対し、本契約及び各個別契約に定める条件に従い、当該個別業務遂行に必要な資料等の開示、貸与等の提供を行う。

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

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

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

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

6. 甲及び乙は、前各項における資料等の提供、返還その他処置等について、それぞれ第

10 条に定めるxx担当者間で書面をもってこれを行うものとする。

ソフトウェア開発においては、ユーザからベンダへの情報提供が不可欠であり、ユーザはベンダにさまざまな資料等を提供することになる。また、ベンダは、ユーザに対し、必要な資料等の提供を要求できることを明確に規定しておく必要がある。

本条では、ユーザからベンダに提供される資料等の提供、保管、使用、返還について定める。第 1 項は、ユーザは、ベンダに対し、個別業務遂行に必要な資料等の開示、貸与等の提供を行

うことを定める。

第 2 項は、ベンダから、ユーザに対して、本件業務遂行に必要な資料等の提供の要請を行う場合について定める。

第 3 項は、ベンダが自社内の作業環境では作業できず、ユーザの事務所等で作業をする場合に、

ユーザは作業環境を含む実施場所を提供することを定める。第 12 条に定める連絡協議会をユーザの事務所等で行う場合も含む。

第 4 項は、ユーザが提供する資料等又は作業実施場所に関して、資料等の内容等の誤り又はユーザの提供遅延等ベンダの責に帰すべからざる事由によって履行遅滞、納入物の瑕疵等の債務不履行が生じた場合に、ベンダに責任を負わせるのは酷であり、これを免責することとしている。

第 5 項では、資料等が不要になった後の取扱いについて規定する。ユーザは、ベンダに対して、 契約終了を待たずして、資料等が不要になったと判断した場合には返還等を求めることができる。資料に関する「処置」としては、ベンダが廃棄した上、ユーザに廃棄証明書を交付すること等が 想定される。

第 6 項は、本条で定める資料等の提供、返還その他の処置はxx担当者間で書面によって行うものとし、紛失や盗難等のトラブル予防を図ることとしている。

（資料等の管理）

第 40 条 乙は甲から提供された本件業務に関する資料等を善良な管理者の注意をもって管理、保管し、かつ、本件業務以外の用途に使用してはならない。

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

製又は改変できる。

本条第 1 項では、前条により提供を受けた資料の管理、保管について、ベンダは善管注意義務を負うこととし、目的外使用を禁じている。

第 2 項は、ソフトウェア開発作業に当たる者については、当該資料を利用する必要があるため、ユーザの承諾を得ずして、ベンダに必要な範囲内での複製又は改変を認めることとしている。

（秘密情報の取扱い）

第 41 条 甲及び乙は、本件業務遂行のため相手方より提供を受けた技術上又は営業上その他業務上の情報のうち、相手方が書面により秘密である旨指定して開示した情報、又は口頭により秘密である旨を示して開示した情報で開示後○日以内に書面により内容 を特定した情報（以下あわせて「秘密情報」という。）を第三者に漏洩してはならな い。但し、次の各号のいずれか一つに該当する情報についてはこの限りではない。また、甲及び乙は秘密情報のうち法令の定めに基づき開示すべき情報を、当該法令の定めに基づく開示先に対し開示することができるものとする。

① 秘密保持義務を負うことなくすでに保有している情報

② 秘密保持義務を負うことなく第三者から正当に入手した情報

③ 相手方から提供を受けた情報によらず、独自に開発した情報

④ 本契約及び個別契約に違反することなく、かつ、受領の前後を問わず公知となった情報

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

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

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

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

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

7. 本条の規定は、本契約終了後、○年間存続する。

ソフトウェア開発においては、ユーザ、ベンダが互いに相手方の秘密情報に接することが想定されることから、本条では、それぞれの秘密保持義務を定める。

第 1 項では、秘密保持義務の対象となる情報の範囲について特定している。本条の目的と無関 係な情報を対象としないため、相手方が書面により秘密である旨指定して開示した情報とともに、口頭により秘密である旨通知して開示した情報は、開示後○日以内に書面により内容を特定する ことを必要としている。第 1 号から第 4 号は、秘密情報の例外規定である。

第 2 項は、秘密情報の提供を受けた当事者は、秘密情報の管理に必要な措置を講ずることとしている。秘密情報の秘密管理性及び非公知性を維持するためには、提供を受けた当事者に秘密情報を適正に保護する体制の構築を義務づけておく必要がある。秘密情報の管理については、物理的・技術的、人的、組織的管理措置を実効的に構築しなければならない。

第 3 項は、秘密情報の目的外使用を禁止し、複製、改変については相手方の承諾を要件としている。

第 4 項は、本契約及び個別契約に基づき乙が再委託する場合の再委託先も含め、秘密情報の開示を受けた役員、従業員、退職者へも秘密保持義務を負わせるよう求めている。開示を受けた者が退職してしまった場合に、第三者に秘密情報が出て行くことのないよう退職者についても秘密保持義務を課すことを義務づけている。秘密情報の開示を受ける担当者等に秘密保持の誓約書を義務づけるなど、より具体的な方策を定めておくことも考えられる。退職者に対して秘密保持義務を課す場合には、一般的に秘密保持契約を締結する必要がある。特に、現職の従業者等及び退職者と秘密保持契約を締結する際には、秘密保持義務が必要性や合理性の点で公序良俗違反（民

法第 90 条）とならないよう、その立場の違いに配慮しながら、両者がコンセンサスを形成でき

るようにすることが重要である（「営業秘密管理指針」（平成 15 年 1 月 30 日、平成 17 年 10 月

12 日改訂、経済産業省）参照）。

本条で定める秘密情報と次条で定める個人情報は、公知情報でない個人情報について適用が重複する場合もありうるので、第 6 項でその優先関係について取り決めている。

第 7 項は、秘密保持義務は通常契約期間より長期の存続が必要であるため、本契約終了後一定期間（秘密情報の性質から鑑みて合理的な期間）、存続させるものとしている。

（個人情報）

第 42 条 乙は、個人情報の保護に関する法律（本条において、以下「法」という。）に定める個人情報のうち、本件業務遂行に際して甲より取扱いを委託された個人データ（法第 2 条第 4 項に規定する個人データをいう。以下同じ。）及び本件業務遂行のため、

甲乙間で個人データと同等の安全管理措置（法第 20 条に規定する安全管理措置をい う。）を講ずることについて、個別契約その他の契約により合意した個人情報（以下 あわせて「個人情報」という。）を第三者に漏洩してはならない。なお、甲は、個人情報を乙に提示する際にはその旨明示するものとする。また、甲は、甲の有する個人情報を乙に提供する場合には、個人が特定できないよう加工した上で、乙に提供するよう努めるものとする。

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

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

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

5. 【第 7 条について B 案を選択した場合】第 7 条第 1 項の規定にかかわらず、乙は甲より委託を受けた個人情報の取扱いを再委託してはならない。但し、当該再委託につき、甲の事前の承諾を受けた場合はこの限りではない。

個人情報保護法第 22 条に基づいて委託者は、委託先監督の責任を負うことから、ソフトウェア開発委託契約においても、委託先の監督について取り決めておく必要がある（個人データの取扱いを委託する場合に契約に盛り込むことが望まれる事項については、「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン106」等を参照）。また、個人情報につ

106 個人データの取扱いを委託する場合に契約書への記載が望まれる事項について、「個人情報の保護に関する法律についての経済産業分野を対象とするガイドライン」（平成 16 年 6 月、経済産業省）（以下、「個人情報ガイドライン」という。）において、委託者及び受託者の責任の明確

いては、秘密保持義務の対象となる秘密情報とは、対象、契約で定めることが望まれる事項が異なるので、個人情報保護に関する条項を秘密保持とは別途規定しておくべきである。

第 1 項は、ベンダに個人情報保護を義務づける。「その他の契約」とは、本契約及び個別契約以外に、個人情報の取扱いに関する委託契約を別途締結するケースを想定している。また、ユーザ保有の個人情報については、当該個人に対し責任を持っているユーザ自身がより安全な取り扱いにつき配慮すべきである。例えば、テスト時に使用するデータをユーザ側がダミー化する等してベンダに渡す等の配慮を行う必要がある。

第 2 項は、ベンダに必要な安全管理措置を義務づける。

第 3 項は、ベンダに個人情報の目的外の使用を禁止し、複製、改変についてはユーザの承諾を要件としている。

第 4 項は、個人データの提供、返還・消去・廃棄に関する事項については、第 39 条（資料等の提供及び返還）を準用する。

第 5 項は、再委託がベンダの裁量で可能な場合にも、個人情報の取扱いの再委託についてはユーザの事前承諾を要するものとしている。前記ガイドラインに、再委託を行う際に委託者への文書による報告を契約上規定すべきとされている趣旨に対応する107。

個人情報をどのように取り扱うのかについては、ユーザの事業分野に関するガイドライン等を踏まえた上で、事前に具体的内容について十分協議して、委託者と受託者の責任分担を明確にしておく必要がある。

第 6 章 x x 帰 属

（納入物の所有権）

第 43 条 乙が本契約及び個別契約に従い甲に納入する納入物の所有権は、当該個別契約に定める時期をもって、乙から甲へ移転する。

本条は、納入する納入物の所有権の移転時期について個別契約で定める旨を規定している108。

化、個人データの安全管理に関する事項、再委託に関する事項、個人データの取扱状況に関する委託者への報告の内容及び頻度、契約内容が遵守されていることの確認、契約内容が遵守されなかった場合の措置、セキュリティ事件・事故が発生した場合の報告・連絡に関する事項が挙げられている。

107 委託者が受託者について「必要かつ適切な監督」を行っていない場合で、受託者が再委託した際に、再委託先が適切とはいえない取扱いを行ったことにより、何らかの問題が生じた場合は、元の委託者がその責めを負うことがあり得るので、再委託する場合は注意を要する。（「個人情 報ガイドライン」参照）

108 受注制作のソフトウェア取引の収益認識については、「契約上の取引相手との間で取り決めた成果物の内容（例えば、顧客との間の取引において、単に制作するだけでなく、契約において定

なお、著作権の譲渡については、後記「納入物の著作権」B 案参照。

（納入物の特許xx）

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

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

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

4. 甲及び乙は、第 2 項、第 3 項に基づき相手方と共有し、又は相手方に通常実施権を許諾する特許xxについて、必要となる職務発明の承継手続（職務発明規定の整備等の職務発明制度の適切な運用、譲渡手続など）を履践するものとする。

ベンダが開発したソフトウェア等の納入物に関しては、特許権、著作権、ノウハウ等の知的財産権が発生する場合がある。知的財産権の帰属については、ユーザ、ベンダ双方の利害が対立することから、契約で明確に規定しておくべきである。

本条は、本件業務の遂行過程で生じる特許xxに関する権利の帰属及び実施権について定める。第 1 項は、発明者主義に従い、当事者のいずれか一方の発明者が単独で発明考案した場合には、

特許xxは当該当事者に帰属し、第 2 項はベンダ、ユーザが共同で発明考案した場合には特許xxはベンダ、ユーザでその貢献度に応じて共有することとしている。

第 3 項では、ベンダが特許xxを保有する場合でも、ユーザが本件ソフトウェアを使用するの

められた機能を有する状態にすること）に応じて、一般的には検収等何らかの形でその成果物の提供の完了を確認することにより、収益を認識することになる（但し、完成基準を適用する場合）」

（「実務対応報告第 17 号ソフトウェア取引の収益の会計処理に関する実務上の取扱い」（平成 18

年 3 月 30 日、企業会計基準委員会参照）。

に必要な範囲では、特許xxを使用する必要があるため、通常実施権を許諾するものとしている。また、一定の第三者に使用せしめる旨を個別契約の目的として特掲したうえで開発された特定ソフトウェアについては、当該第三者に対しても許諾するものとする。なお、かかる許諾についての対価は委託料に含まれることを明記してある。

第 4 項では、ベンダ又はユーザは、特許法第 35 条に基づく職務発明規程により発明者から職

務発明について特許xxを承継することが本条第 1 項乃至第 3 項の前提となっているので、その旨規定する。

※ベンダにすべての著作権を帰属させる場合は A 案を、汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外をユーザに帰属させる場合は B 案を、汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有とする場合は C 案を採用

【A 案】（ベンダにすべての著作権を帰属させる場合）

（納入物の著作権）

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

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

する。

（納入物の著作権）

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

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

契約に従い第三者に対し利用を許諾することができるものとし、かかる許諾の対価は、

【B 案】（汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外をユーザに権利を帰属させる場合）

委託料に含まれるものとする。

（納入物の著作権）

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

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

3. 甲及び乙は、相手方の同意を得なければ、第 1 項所定の著作権の共有持分を処分す

ることはできないものとする。

【C 案】（汎用的な利用が可能なプログラム等の著作権をベンダへ、それ以外を共有とする場合）

本条では、納入物の著作権の権利帰属及び利用について規定する。

本モデル契約では、ソフトウェアの再利用を促進するため、原則としてベンダに著作権を帰属させる規定を A 案としている。ベンダに著作権を帰属させたとしても、秘密保持義務を課すことで、ユーザのノウハウ流出防止を図ることが可能である。

第 45 条 A 案は、納入物に関する著作物の著作権については、ユーザ又は第三者が従前から保有していた著作権を除き、ベンダにすべての著作権を帰属させるものとする。

第 2 項は、本件ソフトウェアに関して、著作xx第 47 条の 2 に基づきユーザが行う自己使用のための複製又は翻案について定める。また、一定の第三者に使用せしめる旨を個別契約の目的として特掲した上で開発された特定ソフトウェアについては、当該第三者に対しても利用許諾できるものとする。

B案では、ベンダ単独で作成した著作物の著作権についてユーザに譲渡することとし、原則としてユーザに権利を帰属させる。但し、ベンダが将来のソフトウェア開発に再利用できるように、同種のプログラムに共通に利用することが可能であるプログラムに関する権利（ベンダが従前より権利を有していたもの及び本件業務により新たに取得したものを含む。）及びベンダが従前から保有していたプログラムに関する権利は、ベンダに留保されるものとする。ベンダは、本契約の秘密保持義務に反しない限り、他のソフトウェア開発においても汎用プログラム等を利用することが可能となる。なお、著作xx第27条（翻訳権、翻案xx）及び第28条(二次的著作物の利