第1章 全体概要 本章では、モデル取引・契約書の作成に至った経緯・目的について解説します。 第1章　全体概要 本章では、モデル取引・契約書の作成に至った経緯・目的について解説します。 システム基本契約書、重要事項説明書、 別紙1・2、モデルドキュメントを 手元に用意してください。

はじめに (1) 2 情報システムは、私たちの生活に深く浸透しています。銀行やコンビニエンスストアのATM、鉄道や航空会社の予約システム、インターネットを通じた株式取引や通信販売など、情報システムは、豊かな生活と便利な社会を作るために必要な社会インフラになったと言ってよいでしょう。 しかし、ひとたび情報システムにトラブルが起きれば、個人、企業を問わず、様々な弊害を招く社会になったと言う事もできます。オンラインシステムや決済システムの不具合だけでなく、企業システムのトラブルは、企業活動に深刻な打撃を与えます。金銭的な損害はもとより、顧客の信頼を損ねたり、企業活動の停滞を招きかねません。 情報システムの信頼性の向上は、社会的な要望であり、私たち情報サービス産業に従事するものにとっての使命とも言える重要な課題になっています。

はじめに (2) 3 2005年秋、東京証券取引所のシステムトラブルに端を発し、わが国の情報システムは信頼性、安定性に欠けるのではないか、という批判が国際社会からも巻き起こりました。 そこで、日本の産業構造の問題点を検討する経済産業省産業構造審議会は、こうした情報システムの信頼性について強い危惧を抱き、「情報システムの信頼性向上のためのガイドライン」を2006年4月に発表しました。 ガイドラインは、①契約における重要事項の明確化、②情報システム構築の分業時の役割分担及び責任関係の明確化を指摘し、ユーザ団体と業界団体が協力して標準的な契約のあり方を検討するように求めました。 そこで、2007年4月に経済産業省「情報システム・モデル取引・契約書＜第一版＞」が策定され、公表されました。＜第一版＞は、社会インフラ・大企業基幹システムの受託開発を対象に、対等の交渉力を有するユーザとベンダを想定して策定されています。

はじめに (3) しかし、ITや契約・法務に詳しい人材がいない中小・中堅企業にとっては、高度化・複雑化する情報技術を利用した業務システムを導入することは決して容易なことではありません。 また、中小・中堅企業の多くは、システム導入にあたってパッケージソフトウェアを中核に、モディファイ、アドオン開発を行うのが一般的です。業務によっては、パッケージソフトウェアを変更せず業務形態を改善する導入方法も多数、見受けられます。 こうした、ITや契約・法務の専門家を配置できない中小・中堅企業、学校、病院、地方自治体、公的機関を対象に、パッケージソフトウェアを活用したシステム構築のための判りやすい契約書の策定が求められました。 2008年4月にモデル取引・契約書＜追補版＞が策定され、中小企業の取引の多数を占めるパッケージソフトウェアを活用した業務システムを想定し、対等の交渉力を有しないユーザとベンダのための契約書が公表されました。

5 5 情報システム 取引の特徴 情報システム取引は様々な業務の集合体 ユーザの興味と価値観 情報システム取引は、業務分析などのコンサルティング業務から、プログラム制作などの知識集約型の専門業務、保守、運用などのサービス業務と、まったく性質の異なる取引が、積み重なった複合取引です。それぞれの業務は、深い専門性と変化が激しいという特徴があります。 ユーザの興味と価値観 ユーザは、ITの専門性や、難易度について興味を持っている訳ではありません。 ITを含めた業務システム全体が正しく運用され、その結果として、仕事の負荷が減ったり、無駄なコストが削減されることを価値として認めています。そして、雇用を守り、利益を出し、成長していく事がもっとも重要なことなのです。あくまでITやコンピュータシステムは、その手段でしかありません。

6 6 ユーザとの関係 情報システムのプロとして Win-Winの関係作り 私たちは、情報システムに携わるプロフェッショナルとして、ユーザの期待に正しく応え、その結果として利益を上げなくてはなりません。 そして、プロフェッショナルとしての知見を高め、より高度なソリューションを提供し続けなければなりません。 ユーザの視線と期待 ユーザは情報システムの専門家ではなく、かつ、情報システム取引の経験が豊富な訳ではありません。 情報システムに関連する業務に従事している私たちは、ユーザからみれば、ITやコンピュータシステムの専門家です。 病気にかかれば医師に、税金で判らない事があれば税理士に相談するように、ユーザは、ITについて専門家である私たちの助言や、手助けを必要としています。

情報システム 取引の課題 7 7 情報の量 私たちは、日常生活で買い物をする際に、様々な知識や経験を活かして買い物をしています。例えば、「事務用のボールペンを買う」という事は難しい事ではありません。 では、「仕事用のパソコンを買う」という場合は、どうでしょうか？ 私たちは、日常の業務の中でパソコンの販売やシステムの構築を通じて、様々な専門知識を有しており、「仕事用のパソコンを買う」ことについて、必要な条件や問題を検討する事が可能です。CPUの性能、メモリの容量、OS、アプリケーション、通信環境、デザイン、セキュリティ、そしてこれらの機能に対する価格の妥当性は、比較的簡単に決める事ができるでしょう。 一方で、中小企業のユーザにとって、「仕事用のパソコンを買う」という行為は、決して簡単なものではありません。自分の業務に適合するノートパソコンの要件をまとめ、価格の妥当性を検討するための、知識と情報量が圧倒的に少ないのです。 ? ?! ？ ？ 7 7

8 8 情報システム 取引の課題 情報の非対称性 専門家としての説明責任義務 情報ギャップのない正しい契約 専門的な知識と情報量が少ないという事は、何が妥当かという判断基準を持っていない、と言い換える事ができます。判断基準が無ければ、要件の優先順位をつける事も困難ですし、価格が適正であるかも判断しにくいと言えます。 こうした、情報システムに関わる専門的な知識と情報量は、私たちベンダとユーザに大きな違いがあります。 専門家としての説明責任義務 知識を豊富に持つ専門家として私たちは、ユーザとの間にある知識や情報の溝を埋めていかなくてはなりません。専門家として分かりやすい説明をする責任義務があるのです。 情報ギャップのない正しい契約 こうしたことから、ユーザとベンダの思い違いや、ボタンの掛け違いが起きない正しい契約が求められています。 ベンダの説明責任を果たすためにも、取引の可視化、重要事項や互いの責任が明らかとなるモデル取引・契約書を活用した取引が望まれています。

第一版策定の 経緯 9 9 「情報システムの信頼性向上に関するガイドライン」で、契約書の策定が指摘され、2007年4月「情報システム・モデル取引・契約書＜第一版＞」が公表されました。 証券取引所におけるシステム障害など、社会インフラを担う情報システムの障害が我が国の経済活動に大きな影響 2005年秋 産業構造審議会情報サービス・ ソフトウェア小委員会 情報システムの信頼性向上に関する ガイドラインの策定 2006年6月 2006年9月 情報サービス・ソフトウェア産業維新 ■モデル契約の策定・活用 情報システム利用者団体及び情報システム供給者団体は、協力して本ガイドラインの考え方を反映した標準的な契約のあり方を検討する。 ■「ユーザ・ベンダ間の取引関係・役割分担」の可視化 情報システムベンダと情報システムユーザの間で協同してモデル契約・契約プロセスを策定する。 モデル取引・契約書（第一版）　 2007年4月 http://www.meti.go.jp/policy/it_policy/keiyaku/index.html 対象： 社会インフラ、大企業基幹系のウォーターフォール型の受託開発 対等の交渉力を有するユーザとベンダ、共通フレーム2007準拠 一括発注、マルチベンダ、工程分割発注に対応 9

モデル取引・契約書（追補版） ～重要事項を中心とした中小企業の取引の多数を占めるパッケージ活用型のモデル取引・契約書～ 追補版策定の 経緯 10 第一版では「中小企業・パッケージ活用型のモデル取引・契約書」の検討が指摘され、第一版をベースに2008年4月に「追補版」として策定・公表されました。 2007年4月 モデル取引・契約書（第一版）　 http://www.meti.go.jp/policy/it_policy/keiyaku/index.html ■今後の検討課題（第一版） 経済産業省は、研究会で策定されたモデル契約プロセス、モデル契約書、モデルドキュメントの定期的な見直しを行う。また、保守・運用プロセスの体系化を踏まえた保守・運用サービスのモデル取引・契約書、パッケージ活用型開発の契約のあり方、中小企業ユーザとの契約のあり方、ソフトウェアモジュールの再利用を促進する契約のあり方及びパフォーマンスベース契約等の多様な契約のあり方についても検討を行う。 モデル取引・契約書（追補版） ～重要事項を中心とした中小企業の取引の多数を占めるパッケージ活用型のモデル取引・契約書～ 2008年4月 対象： パッケージ/SaaS/ASP活用、カスタマイズ、オプション ITの専門知識を有しないユーザと、業として情報サービスを提供するベンダ 共通フレーム2007準拠、一括発注、マルチベンダ、工程分割発注に対応

追補版の役割 (1) ユーザとベンダの理想的かつ実践的なモデルを提示したもので、パッケージソフトウェアを活用した情報システム構築において、ユーザとベンダが相互に参照し、円滑な取引のためのガイドライン的な役割も果たします。 追補版の前提条件 「中小企業」を従業員数、資本金の大小ではなく、「ベンダと対等の交渉力を有しない」、ITや情報システム取引・法務の専門家、専従者を設置することの困難な団体、法人、企業としました。 「パッケージソフトウェア」「SaaS/ASP」は、特定の業種または業務を想定し、その中で汎用的に使用されることを前提とした市販ソフトウェアとしました。パッケージソフトウェアの使用許諾契約、保守契約は、ユーザとパッケージソフトウェアメーカーとの間で交わされるものとしています。 信頼性の高い情報システム構築には、ユーザとベンダの緊密な協力が必要です。ユーザ自身が役割を理解し、ベンダと緊密な協働を行なうものとしています。 ベンダは、業として情報サービスを提供する専門家としての十分な配慮と注意を払う必要と一定の責任があります。 ベンダは専門家として、コンサルティング・エンジニアリング能力は当然のこと、ユーザ業務に精通する努力、最新テクノロジーを平易に説明する能力、プロジェクトマネジメントや品質管理能力の強化に留意しているものとしています。

追補版の役割 (2) モデル取引・契約書第一版が示した、デューデリジェンス、契約締結、品質管理手続きに至る取引ルールと国際取引慣行との整合性、多段階契約、再見積の考え方を踏襲しています。 ユーザの「ベンダ丸投げ」を排除するため、上流工程から保守に至る取引の透明性を確保しています。 要件定義、パッケージソフトウェアの選定、カスタマイズ開発の有無、データ移行、運用、保守、要員教育を含めたパッケージソフトウェア活用のシステム構築を想定し構成しています。 企業規模を問わず、IT、法務の専門家以外でも、情報システム取引の内容を正確に理解でき使いやすい契約書、重要事項説明書、ユーザ、ベンダが相互に利用できるチェックリストを用意しました。 注意：＜追補版＞が対象とならない業務 中小・中堅企業が、パッケージを利用せず、ゼロから独自システムを構築する際の、企画・開発等を委託する業務には、＜追補版＞は適合しません。第一版を参考に、IT法務に詳しい弁護士の助言を得て策定することをお勧めします。

＜追補版＞の 内容・成果物(1) モデル取引・契約書追補版は、モデル契約書、契約書に関連するモデルドキュメントと業務の進捗や内容を確認するためのチェックリストで構成されています。 モデル契約書 契約書の本体です。以下の2つの契約書を必ずペアで利用します。 パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書（システム基本契約書） 重要事項説明書 システム基本契約書は秘密保持や個人情報などの一般的な規程をまとめています。 重要事項説明書は、要件定義から開発、保守、運用支援など、個々の業務の実態に即した規程を定めた契約書です。

＜追補版＞の 内容・成果物(2) モデルドキュメント 議事録や検収依頼書のひな形です。個別契約書に記載されている事項を網羅しています。 （議事録、変更規程用） プロジェクト連絡協議会議事録、設定等合意書 （準委任契約用） 業務完了報告書兼検収依頼書（ベンダ→ユーザ） 業務完了確認書兼検収書（ユーザ→ベンダ） （外部設計支援業務契約用） 業務完了報告書兼外部設計書承認依頼書（ベンダ→ユーザ） 業務完了確認書兼外部設計書承認書（ユーザ→ベンダ） （構築・設定業務契約用） システム構築・設定業務完了報告書兼検収依頼書（ベンダ→ユーザ） 検査合格通知書兼検収書（ユーザ→ベンダ） （ソフトウェア設計・制作業務契約用） 納品書兼検収依頼書（ベンダ→ユーザ） 検査合格通知書兼検収書（ユーザ→ベンダ）

＜追補版＞の 内容・成果物(3) チェックリスト システム取引に不慣れなユーザのために、業務の内容や進捗状況を確認するためのチェックリストです。 コンサルティング会社選定のためのチェックリスト 提案依頼書(RFP)のチェックリスト 業務システム仕様書の記述レベル（JUAS） ユーザIT成熟度チェックリスト パッケージソフトウェア選定のためのチェックリスト SaaS/ASP選定のためのチェックリスト 検収事前チェックリスト 検収チェックリスト セキュリティチェックシート 一般版 セキュリティチェックシート Webアプリケーション版 SaaS向けSLAにおけるサービスレベル項目のモデルケース

情報システム取引の勘所 上流工程(1) 上流工程の重要ポイント 要件定義 情報システム取引では、「情報システムはどうあるべきか」、「情報システムに備えるべき機能や性能は何か」という「要件定義」が、最も重要なポイントと言えます。「共通フレーム2007」では、要件定義を次のように解説しています。 要件定義 新たに構築する（あるいは再構築する）業務、システムの仕様を明確化し、それをベースにIT化範囲とその機能を具体的に明示すること。 関連する組織およびシステムに対する制約条件を明確にし、定義された内容について取得者側の利害関係者間で合意することである。 言い換えれば以下のようにまとめることができます。 ①業務の流れ（人・モノ・金・データ）の動きを明確化して、②その中でIT化すべき範囲と、③ITで実現される各種機能・性能を、④具体的に分かりやすく文書化する、⑤「ITで出来ること、出来ないこと」「人が作業すること」「例外的な措置」などをまとめ、⑥それらをユーザ関係者全員が理解し納得すること。

情報システム取引の勘所 上流工程(2) ユーザは上流工程に不慣れ 要件定義はもっとも重要 本来、要件定義はユーザの責任です。しかし、情報システム構築に不慣れなユーザは、コンピュータシステムを導入してしまえば「何もかもが自動化され人は煩わしい業務からすべて解放される」と考えがちです。また、コンピュータシステムは「何でもできる」、「素早くできる」という漠然とした期待があります。 また、ユーザは「こうしてほしい」、「こんな風に」という漠然とした要望はあっても、具体的にシステムの仕様を明確化したり、IT化の範囲を設定することはできません。さらに、仕様変更がコストや納期に及ぼす影響について知識がありません。 要件定義はもっとも重要 要件定義が完成しないと、①適合性の高いパッケージソフトウェアの選定ができない、②カスタマイズが発生する際の、設計・開発以降の費用見積や納期算定が正確にできない、③設計・開発工程で大幅な仕様変更が発生する可能性が高まる、などの問題を引き起こします。 コスト、納期、信頼性を確保するためには、要件定義をしっかり行なうことがもっとも重要です。

情報システム取引の勘所 上流工程(3) 要件定義を担当するベンダの責任 要件定義を担当するベンダは、設計・開発以降のすべての工程、作業に対しても、重大な責任を負っています。 ベンダは、ユーザに対して上流工程の作業が設計・開発以降のすべての工程に影響を及ぼす重要性とその責任を説明し、ユーザの理解を得なければなりません。 誰が・何を・どのようにして・いつまでに・決定するかをユーザとあらかじめ取り決めて、作業実施にあたる必要があります。 定期的なミーティングを実施し進捗を報告するとともに、その都度、議事録を作成し、ユーザの承認を得なければなりません。 ベンダは、要件定義に関してユーザが正しい判断を行うための材料を、業界の一般的な知識、ノウハウをもとに提供しなければなりません。

19 情報システム取引の勘所 上流工程(4) ユーザの責任 ユーザはパッケージの選定や仕様の最終決定に責任を負います。ベンダにすべてを委ねるのではなく、ベンダと一緒に自社のシステムを構築しなければなりません。 要件定義は現状の業務フローの見直しであり、業務合理化のチャンスです。反面、現場の作業は大幅な変更が求められたり、負担が増える場合もあります。担当者のみならず、システムに関わる利害関係者の参加と調整が必須です。 不明な点や、判らない用語をそのままにせず、納得のいく説明を求めるとともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プロジェクトの進行に努めなければなりません。 要件定義後の仕様変更は、①選定したパッケージが使えなくなる、②カスタマイズ工数に多大な影響を及ぼす、③信頼性の低下の原因になる、などの悪影響があり、納期の延長や増大する費用の負担をしなければなりません。 このため、要件定義の最終決定に際しては、未決事項の先送りを避けるとともに、社内の利害関係者の十分な合意を得ておかなければなりません。

＜追補版＞では、パッケージソフトウェアを活用したシステム導入の＜取引・契約モデルの全体像＞を想定し、上流工程の作業内容を定めました。全体像をユーザ、ベンダが共有することで、実際に何をなすべきか、何を決めなければならないかが明らかになり、実際の作業に対する理解が深まります。他方、既存システムとの密結合があるERP導入と、小規模な会計システム導入では、上流工程の作業内容が異なるため、 ＜取引・契約モデルの全体像＞は規模、目的によって別紙1・2の2つのモデルに分けています。下図は別紙1の上流工程をクローズアップしたものです。 モデル取引の 企画・要件定義 プロセス A 要件定義支援及びパッケージソフトウェア候補選定支援契約 (15) パッケージ候補の システム要件評価 (8) ベンダに対しパッケージ候補選定のための情報提供依頼 (RFI) (1) 事業要件定義 (16)　APIの実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価） (2) プロジェクトゴールの策定 (9) ユーザに対しRFIに基づくパッケージ関連情報の提供、概算見積の提示 (3) 要求品質の明確化 (17) パッケージソフトウェアの 選定と要件定義 システム要件定義と評価 (4) パッケージを利用し実現する業務の新全体像の作成 (10) パッケージの機能要件、非機能要件、使用許諾契約（利用条件、保守等）の検討 (18) 受入れ (5) ベンダに対しシステム、パッケージ等の情報提供要求、試算見積依頼(RFI) D 外部設計支援契約 (11) パッケージ候補の選定 (19) ベンダへの見積要求 E ソフトウェア設計・制作契約 (12) 業務要件及び適合するパッケージ候補の報告書の提出 (6) ユーザに対しRFIに基づくシステム、パッケージ等の情報の提供、試算見積の提示 (20) ユーザへの見積提出 F 構築・設定業務契約 (13) 受入れ G データ移行支援契約 (7) 業務要件定義 H 運用テスト支援契約 Bパッケージソフトウェア選定支援及び要件定義支援契約 I 導入教育支援契約 (14) 使用許諾によってはパッケージ、OS、ハードの導入及び保守の開始（一部保守開始） J 保守契約 K 運用支援契約

情報システム取引の勘所設計・開発・移行(1) 開発・設計・構築の重要ポイント 一旦、設計・開発業務がスタートすると、仕様変更や新たな要望追加はコストや納期に多大な影響を与え、トラブル発生の原因になります。 ■要件定義の合意不足 ×検収段階で「こんなつもりではなかった」、「使い勝手が悪い」などのクレームが出た ○要件定義は、ユーザとベンダだけでなく、ユーザの利用者全員の合意が重要です。 ■要件抽出の不足 ×設計のために詳細な打ち合わせを実施したら、大幅な変更と新たな要望が追加された ○要件の変更、追加については、事前に費用、納期の見直しを定めておくことが重要です。 ■記述レベルのばらつき ×一般的な作業量で見積もったが、実際の作業量は格段に多くコストが増大した ○要件定義の内容をユーザ、ベンダ双方でしっかりと確認することが重要です。

情報システム取引の勘所設計・開発・移行(2) トラブルを未然に防ぐ 設計・開発以降のトラブルの原因の大半は、作業着手前に解決できることといっても過言ではないでしょう。しかし、一旦、契約を交わしてしまうとベンダにはシステムを完成させる責任が発生します。 RFP（Request For Proposal：提案依頼書、見積依頼書）を入手したら、疑問点や不明な点をとりまとめ、ユーザに疑義解消を求めます。要件定義が曖昧だったり、不正確と思われる場合は、ユーザにその旨を報告し、要件定義を行ったベンダを交えて打ち合わせを行い、疑義解消に努める必要があります。 ユーザは上流工程を担当したベンダの協力を得て、設計・開発・構築を担当するベンダにRFPを説明する責任があります。 RFPの提示から見積・提案書提出の期間が短い場合、ベンダ側の検討が不十分なまま見切り発車的に見積が提出される可能性があります。予算執行やプロジェクトゴールの都合を優先するなどのしわ寄せは、後工程の信頼性に大きく影響を及ぼします。

情報システム取引の勘所設計・開発・移行(3) 設計・開発・移行を担当するベンダの責任 ベンダは設計・開発・移行を請け負った以上、見積通りに完成し、納品する義務があります。（完成義務） 何をもって完成とするかを明らかにするためにも、設計・開発に着手する前に、要件定義書の疑義は解消して契約にあたらなければなりません。 要件定義書の疑義解消がユーザだけで困難と思われる場合は、ユーザに要請して、要件定義を実施したベンダに質問し、問題点の改善を求める必要があります。 仕様の変更や追加は、納期、費用に重大な影響を及ぼします。口頭での合意は避け、必ず、文書化しなければなりません。 ミーティングの議事録の作成と報告承認を得なければなりません。

情報システム取引の勘所設計・開発・移行(4) 24 ユーザの責任 要件定義書の決定者はユーザであることから、要件定義に疑義がある場合は、要件定義を担当したベンダとともにその解消に努めなければなりません。 万一、要件の変更を行なう場合は必要最小限に止めるとともに、再見積に伴う費用の追加や、納期の延長を受入れなければなりません。 未決事項がある場合は、その費用、納期の取扱いについて、ベンダと事前に十分な合意をする必要があります。 不明な点や、判らない用語をそのままにせず、納得のいく説明を求めるとともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プロジェクトの進行に努めなければなりません。

まとめ 情報システムの社会的重要性と責任は極めて重大になっています。 そのために、経済産業省は情報システムの信頼性確保の観点から、責任の所在と重要事項が明らかになる契約書策定に取り組み、モデル契約書＜第一版＞＜追補版＞を公表ました。 情報システム構築は、専門性の異なる業務の集合であり、また、ユーザとベンダは情報量が大きく異なります。 ユーザとベンダは協働してシステム構築にあたらなくてはなりません。 ユーザは業務の専門家として、ベンダはITの専門家の立場で業務に当たる責任があります。 パッケージソフトウェアを選定にあたる前の「要件定義」が重要です。 モデル契約書は、ユーザとベンダが協働して、しっかりとした「要件定義」を策定することを重要視しています。

eラーニングメニューに戻り 「第１章のセルフチェック」を選択して、 理解度の確認テストを受けてください。 以上で第1章の解説は終了です。 eラーニングメニューに戻り 「第１章のセルフチェック」を選択して、 理解度の確認テストを受けてください。