第 1 章　全体概要、第 3 章　全体像

本章では、情報システム取引者育成プログラムや、モデル取引・契約書の作成に至った経緯・目的について解説します。

システム基本契約書、重要事項説明書、別紙 1 ・ 2 、モデルドキュメントを

手元に用意してください。

情報システム取引者育成プログラムとは

概要信頼性の高い情報システムの構築を実現するため、経済産業省モデル契約をもとに、情報システム取引のリスク・法務知識を有する者を育成するものです。

狙い情報システム取引者はユーザとベンダのシステム取引のリスクを管理し、取引の透明性を高め、契約の観点から信頼性確保に従事します。

契約が情報システムの信頼性にどのように関わるのか？本章で学んでいきましょう

3情報システム取引者育成プログラム策定に至る経緯(1)

2005年秋、東京証券取引所のシステムトラブルに端を発し、わが国の情報システムは信頼性、安定性に欠けるのではないか、という批判が国際社会からも巻き起こりました。

そこで、日本の産業構造の問題点を検討する経済産業省産業構造審議会は、こうした情報システムの信頼性について強い危惧を抱き、「情報システムの信頼性向上のためのガイドライン」を 2006年4 月に発表しました。

ガイドラインでは、特に商慣行・契約・法的要素に関する事項として「利用者及び供給者は、両者の協力が重要である」との認識に立ち、①契約における重要事項の明確化、②情報システム構築の分業時の役割分担及び責任関係の明確化を指摘しました。

3

情報システム取引者育成プログラム策定に至る経緯 (2)

契約における重要事項の例（抜粋）システムライフサイクルプロセス全体における重要事項の規定仕様変更の取扱に関する規定障害発生時の対応手順等の規定障害発生時の責任関係に関する規定複数のシステム供給者間での責任

さらに、実効性に関する担保措置として、ユーザ団体と業界団体が協力して「標準的な契約」のあり方を検討するように求めました。

そこで、 2007年4 月に経済産業省「情報システム・モデル取引・契約書＜第一版＞」が策定され、公表に至りました。この＜第一版＞は、社会インフラ・大企業基幹システムの受託開発を対象に、対等の交渉力を有するユーザとベンダを想定して策定されています。

4

5情報システム取引者育成プログラム策定に至る経緯 (3)

しかし、 ITや契約・法務に詳しい人材がいない中小・中堅企業にとっては、高度化・複雑化する情報技術を利用した業務システムを導入することは決して容易なことではありません。

また、中小・中堅企業の多くは、システム導入にあたってパッケージソフトウェアを中核に、モディファイ、アドオン開発を行うのが一般的です。業務によっては、パッケージソフトウェアを変更せず業務形態を改善する導入方法も多数、見受けられます。

こうした、 ITや契約・法務の専門家を配置できない中小・中堅企業、学校、病院、地方自治体、公的機関を対象に、パッケージソフトウェアを活用したシステム構築のための、判りやすい契約書の策定が求められました。

2008年 4 月にモデル取引・契約書＜追補版＞が策定され、中小企業の取引の多数を占めるパッケージソフトウェアを活用した業務システムを想定し、対等の交渉力を有しないユーザとベンダのための契約書が公表されました。

情報システム取引者育成プログラム策定に至る経緯 (3)

さらに 2008年に、業界団体、ユーザ団体、弁護士によってこのモデル契約の普及を促進する「情報システム取引高度化コンソーシアム」が結成され、情報システムトラブルの分析や、モデル取引のセミナーなど、様々な活動を開始しました。

情報システム取引者育成プログラムは、リスクの高い中小企業等への情報システム取引を円滑に行うため、コンソーシアムのメンバーである社団法人コンピュータソフトウェア協会と社団法人日本システム販売店協会が、育成協議会を結成し、一定の知識を有する人を認定しています。

6

モデル契約第一版 モデル契約追補版公表 2007年4 月 2008年4 月

適用 受託開発 パッケージ /SaaS/ASP、カスタマイズ、オプション

利用者 対等の交渉力を有するユーザとベンダ

中小企業等で、 ITの専門知識を有しないユーザと、業として情報サービスを提供するベンダ

システム 社会インフラ、大企業基幹系 業務システム、グループウェア

情報システム取引でのトラブル事例や判例からみる反省点

実際の判例はどのように判断しているのか？

7

情報システム取引高度化コンソーシアムのトラブル事例の判例分析

2010年に公表された「情報システム・ソフトウェア取引トラブル事例集」によると、情報システム取引のトラブル原因は、大きく次の3つに分類されています。

正式契約書を締結していないのに作業を開始してしまう作業にあった契約形態になっていない契約に不備がある

これらのトラブルに対して、裁判所はどのように判断したか、実際の判例をもとにその内容を確認してみましょう。

8

トラブル事例 1契約締結前に作業着手し裁判になった事件 経緯

経緯：インターネット接続会社の代理店であるユーザは、二次代理店への手数料の支払いや二次代理店、顧客の管理等を行うシステムの導入を検討し、ベンダを含む 3 社に見積書の提出を求めて、主にベンダとの交渉を開始した。最終的に、ベンダ提案の見積額についてユーザ社内の稟議が通らず、システム導入が延期された。ベンダは既に請負契約は成立しておりユーザが一方的に契約解除したとしてユーザに損害賠償を請求した。

損害賠償請求の概要：約 1,935 万円

内訳：カスタマイズ費用 790 万円 SE 費用 645 万円

ハードウェア費用 500 万円

トラブル事例 1契約締結前に作業着手し裁判になった事件 主張と判決

ベンダの主張：キックオフミーティングを開催し、その際の議事録にユーザが押印している。有償作業へ移行したことをユーザは了解していた。

ユーザの主張：議題が「キックオフミーティング」となっているだけで、単なる打合せである。ベンダには契約締結の3条件を提示したが、当該ミーティング時点になっても、ベンダはその条件が満たされたのかについて、ユーザに確認しなかった。ベンダが一方的に有償作業を開始したに過ぎず、ユーザは何ら明確な説明を受けていない。

判決：ベンダの請求を棄却。請負契約は成立していないと認定。

参考：東京地方裁判所　平成 17年3 月 28日判決（平成 15年（ワ）第 2334 号）

トラブル事例 1契約締結前に作業着手し裁判になった事件 反省点

本件に限らず裁判では、契約書がない状況では、たとえ諸般の事情が考慮されても契約成立が認められる可能性は低い。キックオフミーティングやセレモニーを経ても契約が成立したことにはならない。開発対象物、金額、作業内容、完成時期等の契約の内容について、書面で合意すべきであった。

紛争の原因は、契約締結に基づく正式な発注がない段階で、ベンダが契約は成立したものと一方的に解釈し、有償作業を進めた点にある。ハードウェアも、ユーザに見積書を送ってその後返答がなかったが、ベンダはユーザの意思を確認することなく当該見積書に異議がないものと解釈して購入している。

契約書を締結しないままベンダが一方的に作業を進めた場合、当該作業に掛けた費用は全てベンダの責任となるリスクがある。なお、契約書さえ締結しなければ、ユーザがベンダに対しいかなる要求を行っても、ユーザはベンダの作業費用を負担するリスクを負わなくてよいということにはならない点に留意する必要がある。

11

トラブル事例 2 （契約形態）プロジェクトマネージメント義務違反、協力義務違反があった事例 経緯と主張

経緯：健保組合のシステムが納入期限までに完成しなかったため、ユーザはベンダに対し、債務不履行による契約解除をし、支払済の委託料の返還を求め訴訟。

既払い委託料返還請求2億 5200 万円

ユーザの主張ベンダにはプロジェクトを推進するプロジェクトマネジメント（ PM）義務がある。ユーザが協力義務を負うのは例外的な場合のみで、完成遅れはベンダの技術不足、 PM 能力不足が原因である。

ベンダの主張オーダーメイドのシステム開発には、ユーザの主体的関与が不可欠であり、また契約書にも協力義務が定められている。ユーザの協力義務違反が遅延の原因である。

判決ベンダは、契約書・提案書で提示した開発手順・手法で開発を進め、進捗状況を管理し、開発を阻害する要因を発見し、（適時・適切に）対処すべき義務を負い、さらに、ユーザによって作業を阻害される行為がないよう働きかける義務を負う（プロジェクトマネージメント義務）。具体的には、ユーザが機能の追加等の要求をした場合、当該要求が委託料や納入期限等に影響を及ぼすものであった場合にユーザに対し適時その旨説明して、要求の撤回や追加の委託料の負担等を求めるなどの義務である。（続く）

トラブル事例 2 （契約形態）プロジェクトマネージメント義務違反、協力義務違反があった事例 経緯と主張

判決（続き）他方で、オーダーメイドのシステム開発はベンダのみでは完成できず、ユーザは、開発過程において、どのような機能を要望するのかを明確に伝え、ベンダとともに検討し、画面や帳票を決定し、成果物の検収をするなどの協力義務がある。具体的には、ベンダから求められた際に、ユーザが適時適切な意思決定をしてない点が協力義務違反であるとされた。ベンダのプロジェクトマネージメント義務違反、ユーザの協力義務違反があり、完成しなかったことについてはどちらかの責任とはいえず、債務不履行は認められない。債務不履行解除は認められなかったが、民法641 条によるユーザからの解除（請負契約の仕事が完成するまでは、ベンダの損害を賠償してユーザがいつでも契約を解除できる旨の規定）が認められ、ベンダの過失を差し引き1億 1340 万円につき認容された。

参考：東京地方裁判所　平成 16年3 月 10日判決（地裁平成 12年（ワ）第 20378 号、平成 13年第 1739 号）

トラブル事例 2 （契約形態）プロジェクトマネージメント義務違反、協力義務違反があった事例 経緯と主張

トラブル事例 2 （契約形態）プロジェクトマネージメント義務違反、協力義務違反があった事例 反省点

ベンダは、開発を成功させるために、問題点を発見し、ユーザに対して問題点について協力を求める義務があることに留意すべきである。

ユーザは、ベンダから協力を求められた場合、適時に適切な意思決定をしなければ、協力義務違反に問われることとなる。

本件では、工程単位で納期を決めておきながら、委託料は一括して定めており、基本設計が未確定のまま、次の工程を進めている。そこでユーザが機能について追加の要望したことにより混乱をきたした事例であると評価できる。工程別に委託料を定める多段階契約を締結しておけば、問題が生じることを防止できた可能性が高い。

15

トラブル事例 3 （契約の不備）工数増加分の費用負担が問題となった事例事件 経緯と主張経緯：元請業者の説明では、約 35,000ステップ、工数は 35～ 40 人月程度との見込みであったため、下請業者はこれを元に見積りを作成。しかし、当初予定の工数では足りず、結果的には大幅な赤字となったため、下請業者は当初予定を超える工数分の委託代金支払を求め、訴訟。

委託代金等請求 訴額　 1 億 3876 万 5000 円

下請業者の主張：元請業者が説明した当初見込み規模・工数を前提に算出したので、委託代金もその規模・工数が前提である。予定を上回る工数分は、契約範囲外であり、元請業者が費用負担すべきである。

元請業者の主張：下請業者に委託したのは、システム完成までの開発業務で、委託代金は、その業務全体の対価である。当初見積りより費用増加のリスクは下請業者が引き受けるべきである。

トラブル事例 3 （契約の不備）工数増加分の費用負担が問題となった事例事件 判決

判決下請けの請求棄却。下請業者はシステム開発業者としての専門的知識・能力を有し、契約締結前に元請業者から十分説明を受けていたのだから、本件システム完成までの委託代金を正しく見積もれたはずである。契約書にはシステムの見込み規模・工数などの記載はない。よって、契約の委託代金は、当初見込みの規模・工数を前提としたものではなく、システム開発業務全体の対価である。

参考：東京地方裁判所　平成 7年 6月 12日判決（昭和 63年（ワ）第 10976 号

トラブル事例 3 （契約の不備）工数増加分の費用負担が問題となった事例事件 反省点

本件では、当初見込みの規模・工数について、見積書には記載があったものの、契約書には記載されなかった。下請業者が、業務範囲の前提条件とする規模・工数を契約書に明記するか、または見込み規模・工数が記載された見積書を契約書に添付するなどしていれば、下請業者に何ら落ち度がないのに当初見込みを超える工数が必要となってしまった場合に、増加工数分は契約の範囲外として扱われる可能性がある。 

前提条件を契約書に明記しておくことは一つの方法だが、実際に増加工数・費用が発生した際には、元請業者と下請業者のいずれがそれを負担すべきか、やはり争われることになり、根本的なトラブル予防とはならない。契約締結当時にシステム規模・仕様等の変更・修正が予想される場合には、契約対象とする業務範囲を詳細に定めた上で、仕様等が変動する場合の変更管理手続を規定しておくべきである

18

示唆に富む判例

判例は、ユーザ、ベンダ双方が協力してシステムを作るべきとしています。一方で、ベンダは専門家として ITの知識に乏しいユーザを、システム開発成功に向けて導く様々な義務を課しています。ユーザシステムを構築するための協力義務

ベンダベンダは専門家としての説明責任、善良なる管理者の注意義務様々な要件や仕様確定を導くプロジェクトマネジメント義務

また、別の判例では、「ソフトウェアにはバグがある」としながら、ベンダには速やかなバグの改修義務があるとしています。もちろん、改修しない、多数のバグがある、著しい性能低下や性能などの非機能要件を満たしていないとなければ、欠陥として契約解除の対象となってしまいます。

判例からみるシステム取引契約の課題

情報システム取引契約はもっとも難しい契約正しく整えられた契約をせずに、高額の契約が破棄されたり、超過分の費用を取得することができなくなることが多くあります。一方でシステム取引契約は、他の取引契約に比べても、もっとも難しいという弁護士の指摘があります。一括契約

完成するシステムの詳細が契約締結時に判らないのに、納期と金額を確約してしまう。

契約類型の不適合、不明瞭な契約類型ユーザの仕事を支援するコンサル業務と、仕様に基づきプログラムを開発する業務では、適応すべき契約類型が異なってくる（前者は準委任契約、後者は請負契約）。ところが、これを一つの契約で締結してしまうと、その場面にそぐわなくなり、トラブルとなる。

詳細を定めていない契約完成基準、役割分担、知的財産権、変更管理などの定めがなく、結果としてトラブルが発生してしまう。

2121ユーザから見た情報システム取引とは

頻度が少ない契約ユーザにとって基幹システムの構築に関わる取引は、数年に一回程度です。技術的な内容がわかり、かつ、契約上のポイントとなる点を理解し、ベンダと協働しながらシステム構築・契約に望むユーザは少ないと言わざるを得ません。

専門性が高く内容が判りにくい契約ベンダに比べ、ユーザは自社の業務フローを把握し、その業務に適合するシステムの要件をまとめ、価格の妥当性を検討するための、「知識と情報量」が圧倒的に少ないのです。専門用語が多い契約の内容を理解することは、なかなか大変な事です。

21

情報システム取引でのベンダの責務とモデル契約

情報の非対称性専門的な知識と情報量が少なく、情報の非対称性があるという事から、ユーザは「何が妥当なのかの判断基準を持っていない」と言い換える事ができます。判断基準が無ければ、要件の優先順位をつける事も困難ですし、価格が適正であるかも判断しにくいと言えます。ベンダには無謀な要望であっても、ユーザにしてみると素朴な要求であったり、疑問であったりする訳です。

専門家としての説明責任義務知識を豊富に持つ専門家として私たちは、ユーザとの間にある知識や情報の溝を埋めていかなくてはなりません。ユーザとベンダの思い違いや、ボタンの掛け違いを起こさないために、専門家として分かりやすい説明をする責任義務があるのです。モデル契約は、説明すべき点が整理された、情報の溝を埋めるツールということができます。

222222

トラブル回避をするためには

法的な責任を正しく果たし、かつ、トラブルを回避するには、適切な形態の契約の選択と、情報の非対称性などの特有の問題に対応できる契約手順が重要です。

経済産業省モデル契約の活用には、次のメリットがあり、時間とコストを節約しトラブルによる機会損失を防ぎます。ユーザ、ベンダの役割と論点が整理されている

何について交渉すべきか何を書けばよいか

特有の問題を回避する手順を包含している多段階契約変更規定と再見積そのまま使える付属ドキュメント

モデル契約＜追補版＞の概要と情報システム取引の勘所

ユーザとベンダはどのような関係にあるべきなのでしょうか？

24

2525ユーザとベンダのあるべき関係

ユーザの視線と期待ユーザは情報システムの専門家ではなく、かつ、情報システム取引の経験が豊富な訳ではありません。

情報システムに関連する業務に従事している私たちは、ユーザからみれば、 ITやコンピュータシステムの専門家です。

病気にかかれば医師に、税金で判らない事があれば税理士に相談するように、ユーザは、 ITについて専門家である私たちの助言や、手助けを必要としています。

情報システムのプロとして Win-Winの関係作り私たちは、情報システムに携わるプロフェッショナルとして、ユーザの期待に正しく応え、その結果として利益を上げなくてはなりません。

そして、プロフェッショナルとしての知見を高め、より高度なソリューションを提供し続けなければなりません。

25

2626パッケージ利用におけるトラブル要因

追補版では、パッケージソフトを利用して、業務システムを導入する場合起こりうる現実の問題への必要な対応を示しております。

不十分な RFP（提案要求書）　　　　　　　　　　　　過大なモディファイ・アドオン　　　　　　　　　　　　　 パッケージソフトの機能・サービスレベルの不足 開発途上の仕様外の要求 　　　　　　　　　　　　　検収時点での要求不一致　　　　　　 　　　　　　既存・追加ソフトウェアとの不整合　　　 　　　　　　優越的地位の利用　　

知的財産の帰属

開発中止時の精算

パッケージソフト間のインタフェースに起因する問題システム内における障害が切り分けられない問題パッケージソフトのバージョンアップに起因する問題パッケージソフトのサポート期間切れの問題

パッケージ利用における主たるトラブル要因

ユーザ・ベンダ間における　　役割・責任分担の明確化

　　合意プロセス

「重要事項説明書活用型」モデル取引・契約書＜追補版＞（平成 20年 4月公表）

27追補版の役割と定義 (1)

追補版の役割ユーザとベンダの理想的かつ実践的なモデルを提示したもので、

パッケージソフトウェアを活用した情報システム構築において、ユーザとベンダが相互に参照し、円滑な取引のためのガイドライン的な役割も果たします。

定義「中小企業」：従業員数、資本金の大小ではなく、「ベンダと対等の交渉力を有しない」、 ITや情報システム取引・法務の専門家、専従者を設置することの困難な団体、法人、企業としました。

「パッケージソフトウェア」、「 SaaS/ASP」：特定の業種または業務を想定し、その中で汎用的に使用されることを前提とした市販ソフトウェアとしました。パッケージソフトウェアの使用許諾契約、保守契約は、ユーザとパッケージソフトウェアメーカーとの間で交わされるものとしています。

28追補版の役割と定義 (2)

定義（続き）協働：信頼性の高い情報システム構築には、ユーザとベンダの緊密な協力が必要です。ユーザ自身が自分の役割を理解し、ベンダと緊密に協働し構築するものとしています。

ベンダ：業として情報サービスを提供する専門家であり、専門家としての十分な配慮と注意を払う必要と一定の責任を負っています。また、コンサルティング・エンジニアリング能力は当然のこと、ユーザ業務に精通する努力、最新テクノロジーを平易に説明する能力、プロジェクトマネジメントや品質管理能力の強化に留意しているものとしています。

29追補版の特長

第一版の踏襲第一版が示した、デューデリジェンス、契約締結、品質管理手続きに至る取引ルールと国際取引慣行との整合性、多段階契約、再見積の考え方を踏襲。また、ユーザの「ベンダ丸投げ」を排除するため、上流工程から保守に至る取引の透明性を確保しています。

取引モデルの策定複雑なカスタマイズが発生する場合と、簡易なパッケージの導入を想定し、取引に応じた複数の上流工程をモデル化。要件定義、パッケージソフトウェアの選定、カスタマイズ開発、データ移行、運用、保守、要員教育を含めたパッケージソフトウェア活用のシステム構築を想定し構成しています。

ドキュメント企業規模を問わず、 IT、法務の専門家以外でも、情報システム取引の

内容を正確に理解でき、かつ、使いやすい契約書、重要事項説明書、ユーザ、ベンダが相互に利用できるチェックリストが用意されています。

3030第1 版との相違点

追補版の特徴は、「パッケージソフトウェア利用（ SaaS、 ASPを含む）」を前提とし、「重要事項説明書」によるユーザ、ベンダの合意プロセスにあります。

モデル取引・契約書＜第一版＞（平成 19年 4月公表）

「重要事項説明書活用型」モデル取引・契約書＜追補版＞

（平成 20年 4月公表）契約当事者 対等に交渉力のあるユーザ・ベンダ ITの専門知識を有しないユーザと、

業として情報サービスを提供するベンダ対象モデル スクラッチ型 パッケージ＋カスタマイズ型

パッケージ＋オプション型 対象システム 重要インフラ・企業基幹システムの受託

開発（一部企画を含む）、保守・運用一般業務システム

特徴 初のユーザ・ベンダ双方が議論の上策定

フェーズ毎のユーザ・ベンダ間の責任の明確化（準委任・請負）

共通フレーム 2007準拠（共通プロセス）

仕様の変更管理手続きの明確化 マルチベンダ・工程分割発注への対応

重要事項説明書を用いた契約合意 IT コーディネータや中小企業診断士を始めとする外部専門家やコンサルタントの参画を前提

システム構築後のプロセスの重視（保守、運用等）

パッケージソフトウェアの取扱についてのベンダの責任明確化

著作権のベンダへの帰属※ フェーズごとのユーザ・ベンダ間の責任の明確化や仕様の変更管理手続の明確化など、上記以外の点について第一版の特徴は原則追補版でも踏襲

追補版では、 ITや情報システム取引、法務の専門家の人材のいない中小企業がパッケージソフトを利用して、業務システムを導入するケースを前提としています。

3131追補版のポイント

契約のポイント 概要ポイント 協働 ・ユーザのベンダ丸投げの防止

　⇒システムの内容確定はユーザ権限・責任　⇒ユーザ・ベンダの役割責任の明確化

連絡協議会 ・口頭での変更を防止　⇒変更規定、議事録、承認プロセスを義務化

再委託 ・ベンダの原則自由　⇒ユーザ要求が基づき、再委託先を開示　⇒情報漏洩については、秘密保持契約にて対応　⇒品質については、瑕疵担保にて対応

パッケージ選定における善管注意義務

・ベンダに業界における一般的に要求される善管注意義務を課す　⇒パッケージの選定＝仕様、制限事項の決定　　　開発、運用、保守全般に重要な影響を与える事を明確化

瑕疵担保 ・帰責事由のある場合に限定　⇒逸失利益や間接損害は負わず、現実に被った損害に限定　⇒損害賠償額は個別契約ごとに上限を設定　⇒仕様書、マニュアルとプログラムの不一致を瑕疵と認定　⇒ユーザの資料が誤っていた場合は瑕疵とはならないが、ベンダが不適切と知りつつ指摘しない場合は、担保責任を免れない

追補版では、パッケージソフトを利用して業務システムを導入するケースにおける、ユーザ・ベンダ間の役割・責任分担の明確化および合意プロセスがポイントとなります。

3232追補版のポイント

契約のポイント 概要ポイント ベンダの善管注意義務 ・業界で一般的に要求される専門知識・ノウハウに基づく注意

義務を課す　⇒準委任契約ではベンダの専門家の責任を規定　⇒ユーザ・ベンダの役割責任の明確化

著作権 ・ベンダに帰属　⇒プログラムの再利用による生産性向上、パッケージ利用によるコスト削減、普及に資する　⇒プログラムにおける営業上の機密は秘密保持契約で保護

知財侵害 ・ユーザが申し立てする際は、ベンダに対応指揮権を委ねる　⇒使用不可能となった場合は、交換・変更・権利取得　⇒ユーザ指示やハード等に起因する場合は免責

保守 ・保守範囲を限定（明確化）し、ベンダは老朽装置等の交換請求権を持つ　⇒ベンダは原則不良、不具合の修正（是正保守）のみ対応（環境適応・性能改善・潜在的不具合対応は範囲外）　⇒遠隔地サポートの規定　⇒メーカからの製造打切り、代替部品提供打切り、老朽化装置の場合、ベンダはユーザに対して対象製品の交換請求権を規定

追補版では、パッケージソフトを利用して業務システムを導入するケースにおける、ユーザ・ベンダ間の役割・責任分担の明確化および合意プロセスがポイントとなります。

3333追補版のポイント

契約のポイント 概要ポイント 保守 　⇒ソフトウェアサポート中止の際の保守契約

見直しを規定　⇒交換部品の所有権のベンダ移転　⇒設置場所整備はユーザ責任　⇒不具合調査で調査ベンダ以外のシステムが起因する場合は、ユーザが調査費用を負担する

共通フレームの準拠「共通フレーム 2007」編者 : 独立行政法人 情報処理推進機構 　　　　　ソフトウェア・エンジニアリング・センター発行所 : オーム社

・システム開発作業の役割を「プロセス」としてまとめ、定義・標準化したもの

⇒ユーザとベンダの用語の取違や、前提とする業務内容の思い違いを防ぎ、要件定義、開発、保守、運用、契約等において何がなされるべきかが詳述

⇒追補版において、各取引プロセスは「共通フレーム 2007」を準用、ユーザとベンダ間でそれぞれの役割や目的について共有・確認する際、共通フレームを参照することによって、より深い認識の統一をはかることが可能

追補版では、パッケージソフトを利用して業務システムを導入するケースにおける、ユーザ・ベンダ間の役割・責任分担の明確化および合意プロセスがポイントとなります。

＜追補版＞が対象とならない業務

中小・中堅企業が、パッケージを利用せず、ゼロから独自システムを構築する際の、要件定義・開発・構築を委託する業務には、＜追補版＞は適合しません。第一版を参考に、 IT法務に詳しい弁護士の助言を得て策定することをお勧めします。

34

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

対象システム

対象顧客（契約当事者）

「ベンダと対等の交渉能力を有しない」、 ITや情報システム取引、法務の専門家、専従者を設置することが困難な団体、法人、企業等とする。

「ベンダと対等の交渉能力を有しない」、 ITや情報システム取引、法務の専門家、専従者を設置することが困難な団体、法人、企業等とする。例） 委託者（ユーザ）：民間中小・中堅企業、地方自治体、独立行政法人等

受託者（ベンダ）：情報サービス企業（ SIer、ソフト会社、 IT コーディネータ等）

対象モデル

◆◆

「パッケージソフトウェア」、「 SaaS/ASP」については、特定の業種又は業務を想定し、その中で汎用的に使用されることを前提とした市販ソフトウェアとする。

注）「中小企業」と表記するが、従業員数、資本金の大小による分類ではない。

「ベンダと対等な交渉能力を有しない」ユーザを対象とし、パッケージソフトウェアを前提とすることが、追補版の特徴です。

「パッケージソフトウェア（ SaaS、 ASP利用を含む）を活用した業務システムの構築を対象とする。

◆◆財務会計システム、販売管理システム、電子メール、グループウェア、Webシステム等の導入、構築、カスタマイズ開発、移行、教育、保守、運用支援を対象システムとする。

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

モデル取引 カスタマイズモデル オプションモデル

業務

対象システムの例 生産管理、管理会計等 制度会計、青色申告等

対象業務の汎用性 低い 高い

業務、システムの移行 ある ある

カスタマイズ

検討範囲 比較的広い 比較的狭い

パッケージ本体のモディファイ

ありうる ない（オプションソフトウェアの選定、パラメータ設定、外部プログラ

ムで対応）

関連ソフトウェアとの結合 密結合、疎結合 疎結合

既存ソフトウェア側の変更 小 小 もしくは無し

既存システムとの統合工数 小 軽微 もしくは無し

多様な上流工程に対応 パッケージソフトウェア導入時のカスタマイズ開発がある場合「パッケージ＋カスタマイズモデル」

パッケージソフトウェア導入時のオプション設定やオプションソフトの導入がある場合「パッケージ＋オプションモデル」

パッケージソフトウェア導入の多様性に対応するため、上流工程は 2種類のモデルが用意されています。

保守運用

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

業務要件定義

パッケージ候補選定

システム要件定義

システムの見積

システム外部設計

内部設計・システム開発

データ移行

運用テスト、教育

保守・運用支援

A 要件定義支援及びパッケージソフトウェア候補選定支援契約

B パッケージソフトウェア選定支援及び要件定義支援契約

F 構築業務契約

D 外部設計支援契約

E ソフトウェア設計・制作契約

G データ移行支援契約 H テスト支援契約 I 導入教育支援契約

J 保守契約

K 運用支援契約

： 準委任契約書： 請負契約書

「カスタマイズモデル」 における取引の流れと対応する契約書

カスタマイズモデルにおいては、要件定義段階における契約書は２種類となります。※オプションモデルでは１種類です。

要件定義

設計・開発・移行

取引の流れと、取引のプロセスに対応する契約書は以下の通りとなります。契約のタイプが「準委任」と「請負」に分かれることがポイントです。本スライドは「カスタマイズモデル」における取引の流れについて記載します。

「オプションモデル」 における取引の流れと対応する契約書

3838

要件定義

保守運用

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

業務要件定義

パッケージ候補選定

システム要件定義

システムの見積

運用テスト、教育

保守・運用支援

C　パッケージソフトウェア選定支援及び要件定義支援業務契約

設計・開発・移行

J 保守契約

K 運用支援契約

： 準委任契約書： 請負契約書

オプションモデルにおいては、要件定義段階における契約書は１種類となります。※カスタマイズモデルでは２種類の契約書に分かれます。

システム外部設計

内部設計・システム開発

データ移行

F 構築業務契約

D 外部設計支援契約

E ソフトウェア設計・制作契約

G データ移行支援契約 H テスト支援契約 I 導入教育支援契約

オプションモデルにおける取引の流れと対応する契約書について記載します。

39＜追補版＞の内容・成果物 (1)

モデル取引・契約書追補版は、モデル契約書、契約書に関連するモデルドキュメントと業務の進捗や内容を確認するためのチェックリストで構成されています。

モデル契約書契約書の本体です。以下の2 つの契約書を必ずペアで利用します。 パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書（システム基本契約書）

重要事項説明書 システム基本契約書は秘密保持や個人情報などの一般的な規程をまとめています。

重要事項説明書は、要件定義から開発、保守、運用支援など、個々の業務の実態に即した規程を定めた契約書です。

＜追補版＞の内容・成果物 (2)

モデルドキュメント議事録や検収依頼書のひな形です。個別契約書に記載されている事項を網羅しています。 （議事録、変更規程用）プロジェクト連絡協議会議事録、設定等合意書

（準委任契約用）業務完了報告書兼検収依頼書（ベンダ→ユーザ）業務完了確認書兼検収書（ユーザ→ベンダ）

（外部設計支援業務契約用）業務完了報告書兼外部設計書承認依頼書（ベンダ→ユーザ） 業務完了確認書兼外部設計書承認書（ユーザ→ベンダ）

（構築・設定業務契約用）システム構築・設定業務完了報告書兼検収依頼書（ベンダ→ユーザ） 検査合格通知書兼検収書（ユーザ→ベンダ）

（ソフトウェア設計・制作業務契約用）納品書兼検収依頼書（ベンダ→ユーザ） 検査合格通知書兼検収書（ユーザ→ベンダ）

40

＜追補版＞の内容・成果物 (3)

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

41

情報システム取引の勘所　上流工程 (1)

上流工程の重要ポイント 情報システム取引では、「情報システムはどうあるべきか」、「情報システムに備えるべき機能や性能は何か」という「要件定義」が、最も重要なポイントと言えます。「共通フレーム 2007」では、要件定義を次のように解説しています。

要件定義 新たに構築する（あるいは再構築する）業務、システムの仕様を明確化し、それをベースに IT化範囲とその機能を具体的に明示すること。

関連する組織およびシステムに対する制約条件を明確にし、定義された内容について取得者側の利害関係者間で合意することである。

言い換えれば以下のようにまとめることができます。①業務の流れ（人・モノ・金・データ）の動きを明確化して、②その中で IT化すべき範囲と、③ ITで実現される各種機能・性能を、④具体的に分かりやすく文書化する、⑤「 ITで出来ること、出来ないこと」「人が作業すること」「例外的な措置」などをまとめ、⑥それらをユーザ関係者全員が理解し納得すること。

42

ユーザは上流工程に不慣れ 本来、要件定義はユーザの責任です。しかし、情報システム構築に不慣れなユーザは、コンピュータシステムを導入してしまえば「何もかもが自動化され人は煩わしい業務からすべて解放される」と考えがちです。また、コンピュータシステムは「何でもできる」、「素早くできる」という漠然とした期待があります。

また、ユーザは「こうしてほしい」、「こんな風に」という漠然とした要望はあっても、具体的にシステムの仕様を明確化したり、 IT化の範囲を設定することはできません。さらに、仕様変更がコストや納期に及ぼす影響について知識がありません。

要件定義はもっとも重要 要件定義は、①業務の新全体像、②適合性の高いパッケージソフトウェ

アの選定、③カスタマイズ開発や構築、④システム移行や保守・運用などの要件、⑤納期とコストのバランス、などが含まれたシステム全体の基本設計図といえます。

コストと納期を満たし、信頼性を確保するためには、要件定義がもっとも重要です。

43情報システム取引の勘所　上流工程 (2)

情報システム取引の勘所　上流工程 (3)

要件定義を担当するベンダの責任要件定義を担当するベンダは、専門家として、設計・開発以降のすべての工程、作業に対しても、重大な責任を負っています。

特に、パッケージの選定は、機能、性能、使い勝手、カスタマイズの難易度に多大な影響を及ぼします。

ベンダは、ユーザに対して上流工程の作業が設計・開発以降のすべての工程に影響を及ぼす重要性とその責任を説明し、ユーザの理解を得なければなりません。

誰が・何を・どのようにして・いつまでに・決定するかをユーザとあらかじめ取り決めて、作業実施にあたる必要があります。

定期的なミーティングを実施し進捗を報告するとともに、その都度、議事録を作成し、ユーザの承認を得なければなりません。

ベンダは、要件定義に関してユーザが正しい判断を行うための材料を、業界の一般的な知識、ノウハウをもとに提供しなければなりません。

44

情報システム取引の勘所　上流工程 (4)

ユーザの責任 ユーザはパッケージの選定や仕様の最終決定に責任を負います。ベンダにすべてを委ねるのではなく、ベンダと一緒に自社のシステムを構築しなければなりません。

要件定義は現状の業務フローの見直しであり、業務合理化のチャンスです。反面、現場の作業は大幅な変更が求められたり、負担が増える場合もあります。担当者のみならず、システムに関わる利害関係者の参加と調整が必須です。

不明な点や、判らない用語をそのままにせず、納得のいく説明を求めるとともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プロジェクトの進行に努めなければなりません。

要件定義後の仕様変更は、①選定したパッケージが使えなくなる、②カスタマイズ工数に多大な影響を及ぼす、③信頼性の低下の原因になる、などの悪影響があり、納期の延長や増大する費用の負担をしなければなりません。

このため、要件定義の最終決定に際しては、未決事項の先送りを避けるとともに、社内の利害関係者の十分な合意を得ておかなければなりません。

45

モデル取引の企画・要件定義プロセス

46

(16) APIの実現性の確認（候補パッケージの API、既存システムとの接続性等の評価）

(1) 事業要件定義

(2) プロジェクトゴールの策定

(3) 要求品質の明確化

(4) パッケージを利用し実現する業務の新全体像の作成

(5) ベンダに対しシステム、パッケージ等の情報提供要求、

試算見積依頼 (RFI)

(6) ユーザに対し RFIに基づくシステム、パッケージ等の情報の提供、試算見積の提示

(7) 業務要件定義

(8) ベンダに対しパッケージ候補選定のための情報提供依頼

(RFI)

(9) ユーザに対し RFIに基づくパッケージ関連情報の提供、概

算見積の提示

(15) パッケージ候補のシステム要件評価

(17) パッケージソフトウェアの

選定と要件定義システム要件定義と評価

(19) ベンダへの見積要求

(20) ユーザへの見積提出

A 要件定義支援及びパッケージソフトウェア候補選定支援

契約

(10) パッケージの機能要件、非機能要件、使用許諾契約（利用

条件、保守等）の検討

(11) パッケージ候補の選定

(12) 業務要件及び適合するパッケージ候補の報告書の提出

(13) 受入れ

(18) 受入れ

B パッケージソフトウェア選定支援及び要件定義支援契約

(14) 使用許諾によってはパッケージ、 OS、ハードの導入及び保守の開始（一部保守開始）

F 構築・設定業務契約

E ソフトウェア設計・制作契約

G データ移行支援契約

I 導入教育支援契約

H 運用テスト支援契約

J 保守契約

K 運用支援契約

D 外部設計支援契約

＜追補版＞では、パッケージソフトウェアを活用したシステム導入の＜取引・契約モデルの全体像＞を想定し、上流工程の作業内容を定めました。全体像をユーザ、ベンダが共有することで、実際に何をなすべきか、何を決めなければならないかが明らかになり、実際の作業に対する理解が深まります。他方、既存システムとの密結合がある ERP 導入と、小規模な会計システム導入では、上流工程の作業内容が異なるため、 ＜取引・契約モデルの全体像＞は規模、目的によって別紙 1 ・ 2 の 2 つのモデルに分けています。下図は別紙 1 の上流工程をクローズアップしたものです。

情報システム取引の勘所　設計・開発・構築(1)

開発・設計・構築の重要ポイント一旦、設計・開発業務がスタートすると、仕様変更や新たな要望追加はコストや納期に多大な影響を与え、トラブル発生の原因になります。

47

■要件定義の合意不足検収段階で「こんなはずでなかった」「使い勝手が悪い」などのクレームが出た→要件定義は、ユーザとベンダだけでなく、ユーザの利用者全員の合意が重要です。

■要件抽出の不足開発の詳細な打ち合わせを実施したら、新たな要望追加と仕様変更がされた→要件の変更、追加については、事前に費用、納期の見直しを定めておくことが重要です。

■記述レベルのばらつき一般的な作業量で見積もったが、実際の作業量は格段に多くコストが増大した→要件定義の内容をユーザ、ベンダ双方でしっかりと確認することが重要です。

情報システム取引の勘所　設計・開発・構築 (2)

ベンダはトラブルを未然に防ぐ トラブルの原因の大半は、作業着手前に解決できるといっても過言ではありません。 RFP（ Request For Proposal ：提案依頼書、見積依頼書）を入手したら、疑問点や不明な点をとりまとめ、契約前に、ユーザに文書で疑義解消を求めます。

要件定義が曖昧だったり、不正確と思われる場合は、ユーザにその旨を報告し、要件定義を行ったベンダを交えて打ち合わせを行い、疑義解消に努める必要があります。

ユーザは RFPの説明に努め、適切な見積期間を設定する ユーザは要件定義の決定者であることから、上流工程を担当したベンダの協力を得て、設計・開発・構築を担当するベンダに RFPを説明する責任があります。また、設計以降に要件の追加が発生しないように注意します。

RFPの提示から見積・提案書提出の期間が短い場合、ベンダ側の検討が不十分なまま見切り発車的に見積が提出される可能性があります。適切な見積期間を設定します。

共通の注意事項 契約前でも、口頭でのやりとりを文書にし議事録として交わしましょう。

48

情報システム取引の勘所　設計・開発・構築 (3)

設計・開発・構築を担当するベンダの責任 ベンダは納期までに、請け負った金額で完成させ、納品する義務があります。（完成義務）

何をもって完成とするかを明らかにするためにも、設計・開発に着手する前に、要件定義書の疑義は解消して契約にあたらなければなりません。

要件定義書の疑義解消がユーザだけで困難と思われる場合は、ユーザに要請して、要件定義を実施したベンダに質問し、問題点の改善を求める必要があります。

移行を担当するベンダの責任 ベンダは移行を受託した以上、準委任契約に基づき、要件定義書と開発・構築後の現況を精査し、正しい移行に向けユーザを支援しなければなりません。（善管注意義務）

共通の注意事項 仕様の変更や追加は、納期、費用に重大な影響を及ぼします。口頭での

合意は避け、契約に基づき必ず、文書化をしましょう。 ミーティングの議事録の作成と報告承認を得なければなりません。

49

情報システム取引の勘所　設計・開発・構築 (4)

ユーザの責任（まとめ）要件定義書の決定者はユーザであることから、要件定義に疑義がある場合は、要件定義を担当したベンダとともにその解消に努めなければなりません。

万一、要件の変更を行なう場合は必要最小限に止めるとともに、再見積に伴う費用の追加や、納期の延長を受入れなければなりません。

移行におけるデータ精査は、ユーザの責任です。すべてをベンダに任せることなく、システムの信頼性を十分にチェックしましょう。

未決事項がある場合は、その費用、納期の取扱いについて、ベンダと事前に十分な合意をする必要があります。

不明な点や、判らない用語をそのままにせず、納得のいく説明を求めるとともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プロジェクトの進行に努めなければなりません。

50

まとめ

情報システムの社会的重要性と責任は極めて重大になっています。 そのために、経済産業省は情報システムの信頼性確保の観点から、責任の所在と重要事項が明らかになる契約書策定に取り組み、モデル契約書＜第一版＞＜追補版＞を公表ました。

情報システム構築は、専門性の異なる業務の集合であり、また、ユーザとベンダは情報量が大きく異なります。

ユーザとベンダは協働してシステム構築にあたらなくてはなりません。

ユーザは業務の専門家として、ベンダは ITの専門家の立場で業務に当たる責任があります。

パッケージソフトウェアの選定を含めた「要件定義」が重要です。 モデル契約書は、ユーザとベンダが協働して、しっかりとした「要

件定義」を策定することを重要視しています。

51

52

以上で第 1 章、第 3 章の解説は終了です。