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

第1章 全体概要、第3章 全体像
本章では、情報システム取引者育成プログラムや、
モデル取引・契約書の作成に至った
経緯・目的について解説します。
システム基本契約書、重要事項説明書、
別紙1・2、モデルドキュメントを
手元に用意してください。
情報システム取引者育成プログラムとは
 概要
 信頼性の高い情報システムの構築を実現するため、経済
産業省モデル契約をもとに、情報システム取引のリス
ク・法務知識を有する者を育成するものです。
 狙い
 情報システム取引者はユーザとベンダのシステム取引の
リスクを管理し、取引の透明性を高め、契約の観点から
信頼性確保に従事します。
契約が情報システムの信頼性にどのように関わるのか？
本章で学んでいきましょう
情報システム取引者
育成プログラム策定に至る経緯(1)
3
 2005年秋、東京証券取引所のシステムトラブルに端を発し、
わが国の情報システムは信頼性、安定性に欠けるのではないか、
という批判が国際社会からも巻き起こりました。
 そこで、日本の産業構造の問題点を検討する経済産業省産業構
造審議会は、こうした情報システムの信頼性について強い危惧
を抱き、「情報システムの信頼性向上のためのガイドライン」
を2006年4月に発表しました。
 ガイドラインでは、特に商慣行・契約・法的要素に関する事項
として「利用者及び供給者は、両者の協力が重要である」との
認識に立ち、①契約における重要事項の明確化、②情報システ
ム構築の分業時の役割分担及び責任関係の明確化を指摘しまし
た。
情報システム取引者
育成プログラム策定に至る経緯(2)
4
 契約における重要事項の例（抜粋）
システムライフサイクルプロセス全体における重要事項の規定
仕様変更の取扱に関する規定
障害発生時の対応手順等の規定
障害発生時の責任関係に関する規定
複数のシステム供給者間での責任
 さらに、実効性に関する担保措置として、ユーザ団体と業界団
体が協力して「標準的な契約」のあり方を検討するように求め
ました。
 そこで、2007年4月に経済産業省「情報システム・モデル取
引・契約書＜第一版＞」が策定され、公表に至りました。
この＜第一版＞は、社会インフラ・大企業基幹システムの受託
開発を対象に、対等の交渉力を有するユーザとベンダを想定し
て策定されています。
情報システム取引者
育成プログラム策定に至る経緯(3)
5
 しかし、ITや契約・法務に詳しい人材がいない中小・中堅企業にとっ
ては、高度化・複雑化する情報技術を利用した業務システムを導入す
ることは決して容易なことではありません。
 また、中小・中堅企業の多くは、システム導入にあたってパッケージ
ソフトウェアを中核に、モディファイ、アドオン開発を行うのが一般
的です。業務によっては、パッケージソフトウェアを変更せず業務形
態を改善する導入方法も多数、見受けられます。
 こうした、ITや契約・法務の専門家を配置できない中小・中堅企業、
学校、病院、地方自治体、公的機関を対象に、パッケージソフトウェ
アを活用したシステム構築のための、判りやすい契約書の策定が求め
られました。
 2008年4月にモデル取引・契約書＜追補版＞が策定され、中小企業の
取引の多数を占めるパッケージソフトウェアを活用した業務システム
を想定し、対等の交渉力を有しないユーザとベンダのための契約書が
公表されました。
6
情報システム取引者
育成プログラム策定に至る経緯(3)
 さらに2008年に、業界団体、ユーザ団体、弁護士によってこのモデ
ル契約の普及を促進する「情報システム取引高度化コンソーシアム」
が結成され、情報システムトラブルの分析や、モデル取引のセミナー
など、様々な活動を開始しました。
 情報システム取引者育成プログラムは、リスクの高い中小企業等への
情報システム取引を円滑に行うため、コンソーシアムのメンバーであ
る社団法人コンピュータソフトウェア協会と社団法人日本システム販
売店協会が、育成協議会を結成し、一定の知識を有する人を認定して
います。
モデル契約第一版
モデル契約追補版
公表
2007年4月
2008年4月
適用
受託開発
パッケージ/SaaS/ASP、
カスタマイズ、オプション
利用者
対等の交渉力を有するユーザと
ベンダ
中小企業等で、ITの専門知識を有しないユーザ
と、業として情報サービスを提供するベンダ
システム 社会インフラ、大企業基幹系
業務システム、グループウェア
7
実際の判例はどのように判断しているのか？
情報システム取引でのトラブル事例
や判例からみる反省点
情報システム取引高度化コンソーシアムの
トラブル事例の判例分析
8
 2010年に公表された「情報システム・ソフトウェア取引トラブ
ル事例集」によると、情報システム取引のトラブル原因は、大
きく次の3つに分類されています。
 正式契約書を締結していないのに作業を開始してしまう
 作業にあった契約形態になっていない
 契約に不備がある
 これらのトラブルに対して、裁判所はどのように判断
したか、実際の判例をもとにその内容を確認してみま
しょう。
トラブル事例1
契約締結前に作業着手し裁判になった事件 経緯
経緯：
インターネット接続会社の代理店であるユーザは、二次代理店への手数
料の支払いや二次代理店、顧客の管理等を行うシステムの導入を検討
し、ベンダを含む3社に見積書の提出を求めて、主にベンダとの交渉を
開始した。最終的に、ベンダ提案の見積額についてユーザ社内の稟議が
通らず、システム導入が延期された。ベンダは既に請負契約は成立して
おりユーザが一方的に契約解除したとしてユーザに損害賠償を請求し
た。
損害賠償請求の概要：
約1,935万円
内訳：カスタマイズ費用
SE費用
ハードウェア費用
790万円
645万円
500万円
トラブル事例1
契約締結前に作業着手し裁判になった事件 主張と判決
ベンダの主張：
キックオフミーティングを開催し、その際の議事録にユーザが押印して
いる。有償作業へ移行したことをユーザは了解していた。
ユーザの主張：
議題が「キックオフミーティング」となっているだけで、単なる打合せ
である。
ベンダには契約締結の3条件を提示したが、当該ミーティング時点に
なっても、ベンダはその条件が満たされたのかについて、ユーザに確認
しなかった。ベンダが一方的に有償作業を開始したに過ぎず、ユーザは
何ら明確な説明を受けていない。
判決：
ベンダの請求を棄却。請負契約は成立していないと認定。
参考：東京地方裁判所
平成17年3月28日判決（平成15年（ワ）第2334号）
トラブル事例1
契約締結前に作業着手し裁判になった事件 反省点
11
 本件に限らず裁判では、契約書がない状況では、たとえ諸般の事情が
考慮されても契約成立が認められる可能性は低い。キックオフミー
ティングやセレモニーを経ても契約が成立したことにはならない。開
発対象物、金額、作業内容、完成時期等の契約の内容について、書面
で合意すべきであった。
 紛争の原因は、契約締結に基づく正式な発注がない段階で、ベンダが
契約は成立したものと一方的に解釈し、有償作業を進めた点にある。
ハードウェアも、ユーザに見積書を送ってその後返答がなかったが、
ベンダはユーザの意思を確認することなく当該見積書に異議がないも
のと解釈して購入している。
 契約書を締結しないままベンダが一方的に作業を進めた場合、当該作
業に掛けた費用は全てベンダの責任となるリスクがある。なお、契約
書さえ締結しなければ、ユーザがベンダに対しいかなる要求を行って
も、ユーザはベンダの作業費用を負担するリスクを負わなくてよいと
いうことにはならない点に留意する必要がある。
トラブル事例2 （契約形態）
プロジェクトマネージメント義務違反、協力義務違反があった事例
経緯と主張
経緯：
健保組合のシステムが納入期限までに完成しなかったため、ユーザはベ
ンダに対し、債務不履行による契約解除をし、支払済の委託料の返還を
求め訴訟。
既払い委託料返還請求
2億5200万円
ユーザの主張
ベンダにはプロジェクトを推進するプロジェクトマネジメント（PM）
義務がある。ユーザが協力義務を負うのは例外的な場合のみで、完成遅
れはベンダの技術不足、PM能力不足が原因である。
ベンダの主張
オーダーメイドのシステム開発には、ユーザの主体的関与が不可欠であ
り、また契約書にも協力義務が定められている。ユーザの協力義務違反
が遅延の原因である。
トラブル事例2 （契約形態）
プロジェクトマネージメント義務違反、協力義務違反があった事例
経緯と主張
判決
ベンダは、契約書・提案書で提示した開発手順・手法で開発を進め、進
捗状況を管理し、開発を阻害する要因を発見し、（適時・適切に）対処
すべき義務を負い、さらに、ユーザによって作業を阻害される行為がな
いよう働きかける義務を負う（プロジェクトマネージメント義務）。具
体的には、ユーザが機能の追加等の要求をした場合、当該要求が委託料
や納入期限等に影響を及ぼすものであった場合にユーザに対し適時その
旨説明して、要求の撤回や追加の委託料の負担等を求めるなどの義務で
ある。（続く）
トラブル事例2 （契約形態）
プロジェクトマネージメント義務違反、協力義務違反があった事例
経緯と主張
判決（続き）
他方で、オーダーメイドのシステム開発はベンダのみでは完成できず、
ユーザは、開発過程において、どのような機能を要望するのかを明確に
伝え、ベンダとともに検討し、画面や帳票を決定し、成果物の検収をす
るなどの協力義務がある。具体的には、ベンダから求められた際に、
ユーザが適時適切な意思決定をしてない点が協力義務違反であるとされ
た。
ベンダのプロジェクトマネージメント義務違反、ユーザの協力義務違反
があり、完成しなかったことについてはどちらかの責任とはいえず、債
務不履行は認められない。債務不履行解除は認められなかったが、民法
641条によるユーザからの解除（請負契約の仕事が完成するまでは、ベ
ンダの損害を賠償してユーザがいつでも契約を解除できる旨の規定）が
認められ、ベンダの過失を差し引き1億1340万円につき認容された。
参考：東京地方裁判所
13年第1739号）
平成16年3月10日判決（地裁平成12年（ワ）第20378号、平成
トラブル事例2 （契約形態）
プロジェクトマネージメント義務違反、協力義務違反があった事例
反省点
15
 ベンダは、開発を成功させるために、問題点を発見し、ユーザに対し
て問題点について協力を求める義務があることに留意すべきである。
 ユーザは、ベンダから協力を求められた場合、適時に適切な意思決定
をしなければ、協力義務違反に問われることとなる。
 本件では、工程単位で納期を決めておきながら、委託料は一括して定
めており、基本設計が未確定のまま、次の工程を進めている。そこで
ユーザが機能について追加の要望したことにより混乱をきたした事例
であると評価できる。工程別に委託料を定める多段階契約を締結して
おけば、問題が生じることを防止できた可能性が高い。
トラブル事例3 （契約の不備）
工数増加分の費用負担が問題となった事例事件 経緯と主張
経緯：
元請業者の説明では、約35,000ステップ、工数は35～40人月程度との
見込みであったため、下請業者はこれを元に見積りを作成。しかし、当
初予定の工数では足りず、結果的には大幅な赤字となったため、下請業
者は当初予定を超える工数分の委託代金支払を求め、訴訟。
委託代金等請求
訴額 1億3876万5000円
下請業者の主張：
元請業者が説明した当初見込み規模・工数を前提に算出したので、委託
代金もその規模・工数が前提である。予定を上回る工数分は、契約範囲
外であり、元請業者が費用負担すべきである。
元請業者の主張：
下請業者に委託したのは、システム完成までの開発業務で、委託代金
は、その業務全体の対価である。当初見積りより費用増加のリスクは下
請業者が引き受けるべきである。
トラブル事例3 （契約の不備）
工数増加分の費用負担が問題となった事例事件 判決
判決
下請けの請求棄却。
下請業者はシステム開発業者としての専門的知識・能力を有し、契約締
結前に元請業者から十分説明を受けていたのだから、本件システム完成
までの委託代金を正しく見積もれたはずである。
契約書にはシステムの見込み規模・工数などの記載はない。よって、契
約の委託代金は、当初見込みの規模・工数を前提としたものではなく、
システム開発業務全体の対価である。
参考：東京地方裁判所
平成7年6月12日判決（昭和63年（ワ）第10976号
トラブル事例3 （契約の不備）
工数増加分の費用負担が問題となった事例事件 反省点
18
 本件では、当初見込みの規模・工数について、見積書には記載があっ
たものの、契約書には記載されなかった。下請業者が、業務範囲の前
提条件とする規模・工数を契約書に明記するか、または見込み規模・
工数が記載された見積書を契約書に添付するなどしていれば、下請業
者に何ら落ち度がないのに当初見込みを超える工数が必要となってし
まった場合に、増加工数分は契約の範囲外として扱われる可能性があ
る。
 前提条件を契約書に明記しておくことは一つの方法だが、実際に増加
工数・費用が発生した際には、元請業者と下請業者のいずれがそれを
負担すべきか、やはり争われることになり、根本的なトラブル予防と
はならない。契約締結当時にシステム規模・仕様等の変更・修正が予
想される場合には、契約対象とする業務範囲を詳細に定めた上で、仕
様等が変動する場合の変更管理手続を規定しておくべきである
示唆に富む判例
 判例は、ユーザ、ベンダ双方が協力してシステムを作るべきと
しています。一方で、ベンダは専門家としてITの知識に乏しい
ユーザを、システム開発成功に向けて導く様々な義務を課して
います。
 ユーザ
システムを構築するための協力義務
 ベンダ
ベンダは専門家としての説明責任、善良なる管理者の注意義務
様々な要件や仕様確定を導くプロジェクトマネジメント義務
 また、別の判例では、「ソフトウェアにはバグがある」としな
がら、ベンダには速やかなバグの改修義務があるとしていま
す。もちろん、改修しない、多数のバグがある、著しい性能低
下や性能などの非機能要件を満たしていないとなければ、欠陥
として契約解除の対象となってしまいます。
判例からみるシステム取引契約の課題
 情報システム取引契約はもっとも難しい契約
正しく整えられた契約をせずに、高額の契約が破棄された
り、超過分の費用を取得することができなくなることが多く
あります。一方でシステム取引契約は、他の取引契約に比べ
ても、もっとも難しいという弁護士の指摘があります。
 一括契約
完成するシステムの詳細が契約締結時に判らないのに、納期と金額を
確約してしまう。
 契約類型の不適合、不明瞭な契約類型
ユーザの仕事を支援するコンサル業務と、仕様に基づきプログラムを
開発する業務では、適応すべき契約類型が異なってくる（前者は準委
任契約、後者は請負契約）。ところが、これを一つの契約で締結して
しまうと、その場面にそぐわなくなり、トラブルとなる。
 詳細を定めていない契約
完成基準、役割分担、知的財産権、変更管理などの定めがなく、結果
としてトラブルが発生してしまう。
ユーザから見た情報システム取引とは
21
 頻度が少ない契約
ユーザにとって基幹システムの構築に関わる取引は、数年に一回
程度です。技術的な内容がわかり、かつ、契約上のポイントとな
る点を理解し、ベンダと協働しながらシステム構築・契約に望む
ユーザは少ないと言わざるを得ません。
 専門性が高く内容が判りにくい契約
ベンダに比べ、ユーザは自社の業務フローを把握し、その業務に
適合するシステムの要件をまとめ、価格の妥当性を検討するため
の、「知識と情報量」が圧倒的に少ないのです。専門用語が多い
契約の内容を理解することは、なかなか大変な事です。
情報システム取引でのベンダの責務とモデル契約
22
 情報の非対称性
専門的な知識と情報量が少なく、情報の非対称性があるという
事から、ユーザは「何が妥当なのかの判断基準を持っていな
い」と言い換える事ができます。判断基準が無ければ、要件の
優先順位をつける事も困難ですし、価格が適正であるかも判断
しにくいと言えます。
ベンダには無謀な要望であっても、ユーザにしてみると素朴な
要求であったり、疑問であったりする訳です。
 専門家としての説明責任義務
知識を豊富に持つ専門家として私たちは、ユーザとの間にある
知識や情報の溝を埋めていかなくてはなりません。ユーザとベ
ンダの思い違いや、ボタンの掛け違いを起こさないために、専
門家として分かりやすい説明をする責任義務があるのです。
モデル契約は、説明すべき点が整理された、情報の溝を埋める
ツールということができます。
トラブル回避をするためには
 法的な責任を正しく果たし、かつ、トラブルを回避するに
は、適切な形態の契約の選択と、情報の非対称性などの特有
の問題に対応できる契約手順が重要です。
 経済産業省モデル契約の活用には、次のメリットがあり、時
間とコストを節約しトラブルによる機会損失を防ぎます。
 ユーザ、ベンダの役割と論点が整理されている
何について交渉すべきか
何を書けばよいか
 特有の問題を回避する手順を包含している
多段階契約
変更規定と再見積
そのまま使える付属ドキュメント
24
ユーザとベンダはどのような関係にあるべきなのでしょうか？
モデル契約＜追補版＞の概要と
情報システム取引の勘所
ユーザとベンダのあるべき関係
25
 ユーザの視線と期待
 ユーザは情報システムの専門家ではなく、かつ、情報システム取
引の経験が豊富な訳ではありません。
 情報システムに関連する業務に従事している私たちは、ユーザか
らみれば、ITやコンピュータシステムの専門家です。
 病気にかかれば医師に、税金で判らない事があれば税理士に相談
するように、ユーザは、ITについて専門家である私たちの助言や、
手助けを必要としています。
 情報システムのプロとして Win-Winの関係作り
 私たちは、情報システムに携わるプロフェッショナルとして、
ユーザの期待に正しく応え、その結果として利益を上げなくては
なりません。
 そして、プロフェッショナルとしての知見を高め、より高度なソ
リューションを提供し続けなければなりません。
パッケージ利用
追補版では、パッケージソフトを利用して、業務システムを導
26
における
入する場合起こりうる現実の問題への必要な対応を示して
トラブル要因 おります。
パッケージ利用における主たるトラブル要因
不十分なRFP（提案要求書）
過大なモディファイ・アドオン
パッケージソフトの機能・サービスレベルの不足
開発途上の仕様外の要求
検収時点での要求不一致
「重要事項説明書活用型」
モデル取引・契約書＜追補版＞
（平成20年4月公表）
既存・追加ソフトウェアとの不整合
優越的地位の利用
知的財産の帰属
開発中止時の精算
パッケージソフト間のインタフェースに起因する問題
システム内における障害が切り分けられない問題
パッケージソフトのバージョンアップに起因する問題
パッケージソフトのサポート期間切れの問題
 ユーザ・ベンダ間における
役割・責任分担の明確化
合意プロセス
追補版の役割と定義(1)
27
 追補版の役割
 ユーザとベンダの理想的かつ実践的なモデルを提示したもので、
パッケージソフトウェアを活用した情報システム構築において、
ユーザとベンダが相互に参照し、円滑な取引のためのガイドライ
ン的な役割も果たします。
 定義
 「中小企業」：従業員数、資本金の大小ではなく、「ベンダと対
等の交渉力を有しない」、ITや情報システム取引・法務の専門家、
専従者を設置することの困難な団体、法人、企業としました。
 「パッケージソフトウェア」、「SaaS/ASP」：特定の業種また
は業務を想定し、その中で汎用的に使用されることを前提とした
市販ソフトウェアとしました。パッケージソフトウェアの使用許
諾契約、保守契約は、ユーザとパッケージソフトウェアメーカー
との間で交わされるものとしています。
追補版の役割と定義(2)
28
 定義（続き）
 協働：信頼性の高い情報システム構築には、ユーザとベンダの緊
密な協力が必要です。ユーザ自身が自分の役割を理解し、ベンダ
と緊密に協働し構築するものとしています。
 ベンダ：業として情報サービスを提供する専門家であり、専門家
としての十分な配慮と注意を払う必要と一定の責任を負っていま
す。また、コンサルティング・エンジニアリング能力は当然のこ
と、ユーザ業務に精通する努力、最新テクノロジーを平易に説明
する能力、プロジェクトマネジメントや品質管理能力の強化に留
意しているものとしています。
追補版の特長
29
 第一版の踏襲
 第一版が示した、デューデリジェンス、契約締結、品質管理手続
きに至る取引ルールと国際取引慣行との整合性、多段階契約、再
見積の考え方を踏襲。また、ユーザの「ベンダ丸投げ」を排除す
るため、上流工程から保守に至る取引の透明性を確保しています。
 取引モデルの策定
 複雑なカスタマイズが発生する場合と、簡易なパッケージの導入
を想定し、取引に応じた複数の上流工程をモデル化。要件定義、
パッケージソフトウェアの選定、カスタマイズ開発、データ移行、
運用、保守、要員教育を含めたパッケージソフトウェア活用のシ
ステム構築を想定し構成しています。
 ドキュメント
 企業規模を問わず、IT、法務の専門家以外でも、情報システム取
引の内容を正確に理解でき、かつ、使いやすい契約書、重要事項
説明書、ユーザ、ベンダが相互に利用できるチェックリストが用
意されています。
第1版との
相違点
追補版では、ITや情報システム取引、法務の専門家の人材
のいない中小企業がパッケージソフトを利用して、業務シス
テムを導入するケースを前提としています。
モデル取引・契約書＜第一版＞
（平成19年4月公表）
30
「重要事項説明書活用型」モデル取引・契約書
＜追補版＞
（平成20年4月公表）
契約当事者
対等に交渉力のあるユーザ・ベンダ
ITの専門知識を有しないユーザと、
業として情報サービスを提供するベンダ
対象モデル
スクラッチ型
パッケージ＋カスタマイズ型
パッケージ＋オプション型
対象システム
重要インフラ・企業基幹システムの受託開発
（一部企画を含む）、保守・運用
一般業務システム
特徴
 初のユーザ・ベンダ双方が議論の上策定
 フェーズ毎のユーザ・ベンダ間の責任の
明確化（準委任・請負）
 共通フレーム2007準拠（共通プロセス）
 仕様の変更管理手続きの明確化
 マルチベンダ・工程分割発注への対応
 重要事項説明書を用いた契約合意
 ITコーディネータや中小企業診断士を始めとする外
部専門家やコンサルタントの参画を前提
 システム構築後のプロセスの重視（保守、運用等）
 パッケージソフトウェアの取扱についてのベンダの
責任明確化
 著作権のベンダへの帰属
※ フェーズごとのユーザ・ベンダ間の責任の明確化や
仕様の変更管理手続の明確化など、上記以外の点
について第一版の特徴は原則追補版でも踏襲
 追補版の特徴は、「パッケージソフトウェア利用（SaaS、ASPを含む）」を前提とし、
「重要事項説明書」によるユーザ、ベンダの合意プロセスにあります。
追補版の
ポイント
追補版では、パッケージソフトを利用して業務システムを導
入するケースにおける、ユーザ・ベンダ間の役割・責任分担
の明確化および合意プロセスがポイントとなります。
契約のポイント
ポイント
31
概要
 協働
・ユーザのベンダ丸投げの防止
⇒システムの内容確定はユーザ権限・責任
⇒ユーザ・ベンダの役割責任の明確化
 連絡協議会
・口頭での変更を防止
⇒変更規定、議事録、承認プロセスを義務化
 再委託
・ベンダの原則自由
⇒ユーザ要求が基づき、再委託先を開示
⇒情報漏洩については、秘密保持契約にて対応
⇒品質については、瑕疵担保にて対応
 パッケージ選定における善管
注意義務
・ベンダに業界における一般的に要求される善管注意義務を課す
⇒パッケージの選定＝仕様、制限事項の決定
開発、運用、保守全般に重要な影響を与える事を明確化
 瑕疵担保
・帰責事由のある場合に限定
⇒逸失利益や間接損害は負わず、現実に被った損害に限定
⇒損害賠償額は個別契約ごとに上限を設定
⇒仕様書、マニュアルとプログラムの不一致を瑕疵と認定
⇒ユーザの資料が誤っていた場合は瑕疵とはならないが、ベンダ
が不適切と知りつつ指摘しない場合は、担保責任を免れない
追補版の
ポイント
追補版では、パッケージソフトを利用して業務システムを導
入するケースにおける、ユーザ・ベンダ間の役割・責任分担
の明確化および合意プロセスがポイントとなります。
契約のポイント
ポイント
32
概要
 ベンダの善管注意義務
・業界で一般的に要求される専門知識・ノウハウに基づく注意義務を
課す
⇒準委任契約ではベンダの専門家の責任を規定
⇒ユーザ・ベンダの役割責任の明確化
 著作権
・ベンダに帰属
⇒プログラムの再利用による生産性向上、パッケージ利用によるコ
スト削減、普及に資する
⇒プログラムにおける営業上の機密は秘密保持契約で保護
 知財侵害
・ユーザが申し立てする際は、ベンダに対応指揮権を委ねる
⇒使用不可能となった場合は、交換・変更・権利取得
⇒ユーザ指示やハード等に起因する場合は免責
 保守
・保守範囲を限定（明確化）し、ベンダは老朽装置等の交換請求権を
持つ
⇒ベンダは原則不良、不具合の修正（是正保守）のみ対応（環境適
応・性能改善・潜在的不具合対応は範囲外）
⇒遠隔地サポートの規定
⇒メーカからの製造打切り、代替部品提供打切り、老朽化装置の
場合、ベンダはユーザに対して対象製品の交換請求権を規定
追補版の
ポイント
追補版では、パッケージソフトを利用して業務システムを導
入するケースにおける、ユーザ・ベンダ間の役割・責任分担
の明確化および合意プロセスがポイントとなります。
契約のポイント
ポイント
 保守
 共通フレームの準拠
「共通フレーム2007」
編者: 独立行政法人 情報処理推進機構
ソフトウェア・エンジニアリング・センター
発行所: オーム社
33
概要
⇒ソフトウェアサポート中止の際の保守契約見直し
を規定
⇒交換部品の所有権のベンダ移転
⇒設置場所整備はユーザ責任
⇒不具合調査で調査ベンダ以外のシステムが起
因する場合は、ユーザが調査費用を負担する
・システム開発作業の役割を「プロセス」としてまとめ、
定義・標準化したもの
⇒ユーザとベンダの用語の取違や、前提とする業務
内容の思い違いを防ぎ、要件定義、開発、保守、
運用、契約等において何がなされるべきかが詳
述
⇒追補版において、各取引プロセスは「共通フレー
ム2007」を準用、ユーザとベンダ間でそれぞれの
役割や目的について共有・確認する際、共通フ
レームを参照することによって、より深い認識の
統一をはかることが可能
＜追補版＞が対象とならない業務
34
 中小・中堅企業が、パッケージを利用せず、ゼロから独自
システムを構築する際の、要件定義・開発・構築を委託す
る業務には、＜追補版＞は適合しません。第一版を参考
に、IT法務に詳しい弁護士の助言を得て策定することをお
勧めします。
モデル取引・
契約書の全体像
対象顧客
（契約当事者）
「ベンダと対等な交渉能力を有しない」ユーザを
対象とし、パッケージソフトウェアを前提とするこ
とが、追補版の特徴です。
35
 「ベンダと対等の交渉能力を有しない」、ITや情報システム取
引、法務の専門家、専従者を設置することが困難な団体、法
人、企業等とする。
例） 委託者（ユーザ）：民間中小・中堅企業、地方自治体、独立行政法人等
受託者（ベンダ）：情報サービス企業（SIer、ソフト会社、ITコーディネータ等）
注）「中小企業」と表記するが、従業員数、資本金の大小による分類ではない。
対象モデル
対象システム
◆ 「パッケージソフトウェア（SaaS、ASP利用を含む）を活用し
た業務システムの構築を対象とする。
「パッケージソフトウェア」、「SaaS/ASP」については、特定の業種又は業務
を想定し、その中で汎用的に使用されることを前提とした市販ソフトウェアと
する。
◆ 財務会計システム、販売管理システム、電子メール、グルー
プウェア、Webシステム等の導入、構築、カスタマイズ開発、
移行、教育、保守、運用支援を対象システムとする。
モデル取引・
契約書の全体像
パッケージソフトウェア導入の多様性に対応するた
め、上流工程は2種類のモデルが用意されています。
36
 多様な上流工程に対応
 パッケージソフトウェア導入時のカスタマイズ開発がある場合
「パッケージ＋カスタマイズモデル」
 パッケージソフトウェア導入時のオプション設定やオプションソフトの導入が
ある場合
「パッケージ＋オプションモデル」
モデル取引
業
務
カ
ス
タ
マ
イ
ズ
カスタマイズモデル
オプションモデル
対象システムの例
生産管理、管理会計等
制度会計、青色申告等
対象業務の汎用性
低い
高い
業務、システムの移行
ある
ある
比較的広い
比較的狭い
ありうる
ない（オプションソフトウェアの選定、パ
ラメータ設定、外部プログラムで対応）
関連ソフトウェアとの結合
密結合、疎結合
疎結合
既存ソフトウェア側の変更
小
小 もしくは無し
既存システムとの統合工数
小
軽微 もしくは無し
検討範囲
パッケージ本体のモディファイ
モデル取引・
契約書の全体像
取引の流れと、取引のプロセスに対応する契約書は以下
の通りとなります。契約のタイプが「準委任」と「請負」に分
かれることがポイントです。本スライドは「カスタマイズモデ
ル」における取引の流れについて記載します。
37
 「カスタマイズモデル」 における取引の流れと対応する契約書
要
件
定
義
業務要件定義
パッケージ候補選定
システム要件定義
システムの見積
設
計
・
開
発
・
移
行
運保
用守
システム外部設計
内部設計・システム開発
： 準委任契約書
： 請負契約書
A 要件定義支援及びパッケージ
ソフトウェア候補選定支援契約
カスタマイズモデルにおいては、
要件定義段階における契約書
は２種類となります。
※オプションモデルでは１種類
です。
B パッケージソフトウェア選定支援
及び要件定義支援契約
D 外部設計支援契約
E ソフトウェア設計・制作契約
データ移行
G データ移行支援契約
運用テスト、教育
J 保守契約
保守・運用支援
K 運用支援契約
F 構築業務契約
H テスト支援契約
I 導入教育支援契約
モデル取引・
契約書の全体像
オプションモデルにおける取引の流れと対応する
契約書について記載します。
38
 「オプションモデル」 における取引の流れと対応する契約書
要
件
定
義
業務要件定義
パッケージ候補選定
システム要件定義
： 準委任契約書
： 請負契約書
C パッケージソフトウェア選定支援
及び要件定義支援業務契約
オプションモデルにおいては、
要件定義段階における契約書
は１種類となります。
※カスタマイズモデルでは２種
類の契約書に分かれます。
システムの見積
設
計
・
開
発
・
移
行
運保
用守
システム外部設計
内部設計・システム開発
D 外部設計支援契約
E ソフトウェア設計・制作契約
データ移行
G データ移行支援契約
運用テスト、教育
J 保守契約
保守・運用支援
K 運用支援契約
F 構築業務契約
H テスト支援契約
I 導入教育支援契約
＜追補版＞の内容・成果物(1)


モデル取引・契約書追補版は、モデル契約書、契約書に関連するモ
デルドキュメントと業務の進捗や内容を確認するためのチェックリ
ストで構成されています。
モデル契約書
契約書の本体です。以下の2つの契約書を必ずペアで利用します。




39
パッケージソフトウェア利用コンピュータシステム構築委託モデル契約
書（システム基本契約書）
重要事項説明書
システム基本契約書は秘密保持や個人情報などの一般的な規程をま
とめています。
重要事項説明書は、要件定義から開発、保守、運用支援など、個々
の業務の実態に即した規程を定めた契約書です。
＜追補版＞の内容・成果物(2)

40
モデルドキュメント
議事録や検収依頼書のひな形です。個別契約書に記載されている事
項を網羅しています。





（議事録、変更規程用）
プロジェクト連絡協議会議事録、設定等合意書
（準委任契約用）
業務完了報告書兼検収依頼書（ベンダ→ユーザ）
業務完了確認書兼検収書（ユーザ→ベンダ）
（外部設計支援業務契約用）
業務完了報告書兼外部設計書承認依頼書（ベンダ→ユーザ）
業務完了確認書兼外部設計書承認書（ユーザ→ベンダ）
（構築・設定業務契約用）
システム構築・設定業務完了報告書兼検収依頼書（ベンダ→ユーザ）
検査合格通知書兼検収書（ユーザ→ベンダ）
（ソフトウェア設計・制作業務契約用）
納品書兼検収依頼書（ベンダ→ユーザ）
検査合格通知書兼検収書（ユーザ→ベンダ）
＜追補版＞の内容・成果物(3)

41
チェックリスト
システム取引に不慣れなユーザのために、業務の内容や進捗状況を確
認するためのチェックリストです。
 コンサルティング会社選定のためのチェックリスト
 提案依頼書(RFP)のチェックリスト
 業務システム仕様書の記述レベル（JUAS）
 ユーザIT成熟度チェックリスト
 パッケージソフトウェア選定のためのチェックリスト
 SaaS/ASP選定のためのチェックリスト
 検収事前チェックリスト
 検収チェックリスト
 セキュリティチェックシート 一般版

セキュリティチェックシート Webアプリケーション版

SaaS向けSLAにおけるサービスレベル項目のモデルケース
情報システム取引の勘所
上流工程(1)
42
 上流工程の重要ポイント
 情報システム取引では、「情報システムはどうあるべきか」、「情報シス
テムに備えるべき機能や性能は何か」という「要件定義」が、最も重要な
ポイントと言えます。「共通フレーム2007」では、要件定義を次のように
解説しています。
 要件定義
 新たに構築する（あるいは再構築する）業務、システムの仕様を明確化し、
それをベースにIT化範囲とその機能を具体的に明示すること。
 関連する組織およびシステムに対する制約条件を明確にし、定義された内
容について取得者側の利害関係者間で合意することである。
 言い換えれば以下のようにまとめることができます。
①業務の流れ（人・モノ・金・データ）の動きを明確化して、②そ
の中でIT化すべき範囲と、③ITで実現される各種機能・性能を、
④具体的に分かりやすく文書化する、⑤「ITで出来ること、出来な
いこと」「人が作業すること」「例外的な措置」などをまとめ、⑥
それらをユーザ関係者全員が理解し納得すること。
情報システム取引の勘所
上流工程(2)
43
 ユーザは上流工程に不慣れ
 本来、要件定義はユーザの責任です。しかし、情報システム構築に不慣れ
なユーザは、コンピュータシステムを導入してしまえば「何もかもが自動
化され人は煩わしい業務からすべて解放される」と考えがちです。また、
コンピュータシステムは「何でもできる」、「素早くできる」という漠然
とした期待があります。
 また、ユーザは「こうしてほしい」、「こんな風に」という漠然とした要
望はあっても、具体的にシステムの仕様を明確化したり、IT化の範囲を設
定することはできません。さらに、仕様変更がコストや納期に及ぼす影響
について知識がありません。
 要件定義はもっとも重要
 要件定義は、①業務の新全体像、②適合性の高いパッケージソフトウェア
の選定、③カスタマイズ開発や構築、④システム移行や保守・運用などの
要件、⑤納期とコストのバランス、などが含まれたシステム全体の基本設
計図といえます。
 コストと納期を満たし、信頼性を確保するためには、要件定義がもっとも
重要です。
情報システム取引の勘所
上流工程(3)
44
 要件定義を担当するベンダの責任
 要件定義を担当するベンダは、専門家として、設計・開発以降の





すべての工程、作業に対しても、重大な責任を負っています。
特に、パッケージの選定は、機能、性能、使い勝手、カスタマイ
ズの難易度に多大な影響を及ぼします。
ベンダは、ユーザに対して上流工程の作業が設計・開発以降のす
べての工程に影響を及ぼす重要性とその責任を説明し、ユーザの
理解を得なければなりません。
誰が・何を・どのようにして・いつまでに・決定するかをユーザ
とあらかじめ取り決めて、作業実施にあたる必要があります。
定期的なミーティングを実施し進捗を報告するとともに、その都
度、議事録を作成し、ユーザの承認を得なければなりません。
ベンダは、要件定義に関してユーザが正しい判断を行うための材
料を、業界の一般的な知識、ノウハウをもとに提供しなければな
りません。
情報システム取引の勘所
上流工程(4)
45
 ユーザの責任
 ユーザはパッケージの選定や仕様の最終決定に責任を負います。ベンダに




すべてを委ねるのではなく、ベンダと一緒に自社のシステムを構築しなけ
ればなりません。
要件定義は現状の業務フローの見直しであり、業務合理化のチャンスです。
反面、現場の作業は大幅な変更が求められたり、負担が増える場合もあり
ます。担当者のみならず、システムに関わる利害関係者の参加と調整が必
須です。
不明な点や、判らない用語をそのままにせず、納得のいく説明を求めると
ともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プロ
ジェクトの進行に努めなければなりません。
要件定義後の仕様変更は、①選定したパッケージが使えなくなる、②カス
タマイズ工数に多大な影響を及ぼす、③信頼性の低下の原因になる、など
の悪影響があり、納期の延長や増大する費用の負担をしなければなりませ
ん。
このため、要件定義の最終決定に際しては、未決事項の先送りを避けると
ともに、社内の利害関係者の十分な合意を得ておかなければなりません。
モデル取引の
企画・要件定義
プロセス
＜追補版＞では、パッケージソフトウェアを活用したシステム導入の＜取引・契約モデルの全体像
＞を想定し、上流工程の作業内容を定めました。全体像をユーザ、ベンダが共有することで、実際
に何をなすべきか、何を決めなければならないかが明らかになり、実際の作業に対する理解が深ま
ります。他方、既存システムとの密結合があるERP導入と、小規模な会計システム導入では、上流
工程の作業内容が異なるため、 ＜取引・契約モデルの全体像＞は規模、目的によって別紙1・2の
2つのモデルに分けています。下図は別紙1の上流工程をクローズアップしたものです。
46
A 要件定義支援及びパッケージ
ソフトウェア候補選定支援契約
(1) 事業要件定義
(8) ベンダに対しパッケージ候補選
定のための情報提供依頼 (RFI)
(15) パッケージ候補の
システム要件評価
(16) APIの実現性の確認（候補
(2) プロジェクトゴールの策定
(3) 要求品質の明確化
(4) パッケージを利用し実現する
業務の新全体像の作成
(5) ベンダに対しシステム、パッ
ケージ等の情報提供要求、試算
見積依頼(RFI)
(6) ユーザに対しRFIに基づくシ
ステム、パッケージ等の情報の
提供、試算見積の提示
(9) ユーザに対しRFIに基づくパッ
ケージ関連情報の提供、概算見積
の提示
(10) パッケージの機能要件、非機
能要件、使用許諾契約（利用条件、
保守等）の検討
(11) パッケージ候補の選定
(12) 業務要件及び適合するパッ
ケージ候補の報告書の提出
(13) 受入れ
(7) 業務要件定義
Bパッケージソフトウェア選定支援
及び要件定義支援契約
パッケージのAPI、既存システムとの接
続性等の評価）
(17) パッケージソフトウェアの
選定と要件定義
システム要件定義と評価
(18) 受入れ
D 外部設計支援契約
(19) ベンダへの見積要求
(20) ユーザへの見積提出
E ソフトウェア設計・制作契約
F 構築・設定業務契約
G データ移行支援契約
H 運用テスト支援契約
I 導入教育支援契約
(14) 使用許諾によってはパッケー
ジ、OS、ハードの導入及び保守の
開始（一部保守開始）
J 保守契約
K 運用支援契約
情報システム取引の勘所
設計・開発・構築(1)
47
 開発・設計・構築の重要ポイント
一旦、設計・開発業務がスタートすると、仕様変更や新たな要望追加は
コストや納期に多大な影響を与え、トラブル発生の原因になります。
■要件定義の合意不足
検収段階で「こんなはずでなかった」「使い勝手が悪い」などのクレームが出た
→要件定義は、ユーザとベンダだけでなく、ユーザの利用者全員の合意が重要です。
■要件抽出の不足
開発の詳細な打ち合わせを実施したら、新たな要望追加と仕様変更がされた
→要件の変更、追加については、事前に費用、納期の見直しを定めておくことが重
要です。
■記述レベルのばらつき
一般的な作業量で見積もったが、実際の作業量は格段に多くコストが増大した
→要件定義の内容をユーザ、ベンダ双方でしっかりと確認することが重要です。
情報システム取引の勘所
設計・開発・構築(2)
48
 ベンダはトラブルを未然に防ぐ
 トラブルの原因の大半は、作業着手前に解決できるといっても過言ではあ
りません。RFP（Request For Proposal：提案依頼書、見積依頼書）を入
手したら、疑問点や不明な点をとりまとめ、契約前に、ユーザに文書で疑
義解消を求めます。
 要件定義が曖昧だったり、不正確と思われる場合は、ユーザにその旨を報
告し、要件定義を行ったベンダを交えて打ち合わせを行い、疑義解消に努
める必要があります。
 ユーザはRFPの説明に努め、適切な見積期間を設定する
 ユーザは要件定義の決定者であることから、上流工程を担当したベンダの
協力を得て、設計・開発・構築を担当するベンダにRFPを説明する責任が
あります。また、設計以降に要件の追加が発生しないように注意します。
 RFPの提示から見積・提案書提出の期間が短い場合、ベンダ側の検討が不
十分なまま見切り発車的に見積が提出される可能性があります。適切な見
積期間を設定します。
 共通の注意事項
 契約前でも、口頭でのやりとりを文書にし議事録として交わしましょう。
情報システム取引の勘所
設計・開発・構築(3)
49
 設計・開発・構築を担当するベンダの責任
 ベンダは納期までに、請け負った金額で完成させ、納品する義務がありま
す。（完成義務）
 何をもって完成とするかを明らかにするためにも、設計・開発に着手する
前に、要件定義書の疑義は解消して契約にあたらなければなりません。
 要件定義書の疑義解消がユーザだけで困難と思われる場合は、ユーザに要
請して、要件定義を実施したベンダに質問し、問題点の改善を求める必要
があります。
 移行を担当するベンダの責任
 ベンダは移行を受託した以上、準委任契約に基づき、要件定義書と開発・
構築後の現況を精査し、正しい移行に向けユーザを支援しなければなりま
せん。（善管注意義務）
 共通の注意事項
 仕様の変更や追加は、納期、費用に重大な影響を及ぼします。口頭での合
意は避け、契約に基づき必ず、文書化をしましょう。
 ミーティングの議事録の作成と報告承認を得なければなりません。
情報システム取引の勘所
設計・開発・構築(4)
50
 ユーザの責任（まとめ）
 要件定義書の決定者はユーザであることから、要件定義に疑義が
ある場合は、要件定義を担当したベンダとともにその解消に努め
なければなりません。
 万一、要件の変更を行なう場合は必要最小限に止めるとともに、
再見積に伴う費用の追加や、納期の延長を受入れなければなりま
せん。
 移行におけるデータ精査は、ユーザの責任です。すべてをベンダ
に任せることなく、システムの信頼性を十分にチェックしましょ
う。
 未決事項がある場合は、その費用、納期の取扱いについて、ベン
ダと事前に十分な合意をする必要があります。
 不明な点や、判らない用語をそのままにせず、納得のいく説明を
求めるとともに、決定事項、未決事項などをまとめた議事録を点
検、承認し、プロジェクトの進行に努めなければなりません。
まとめ
51
 情報システムの社会的重要性と責任は極めて重大になっています。
 そのために、経済産業省は情報システムの信頼性確保の観点から、責
任の所在と重要事項が明らかになる契約書策定に取り組み、モデル契
約書＜第一版＞＜追補版＞を公表ました。
 情報システム構築は、専門性の異なる業務の集合であり、また、ユー
ザとベンダは情報量が大きく異なります。
 ユーザとベンダは協働してシステム構築にあたらなくてはなりません。
 ユーザは業務の専門家として、ベンダはITの専門家の立場で業務に当
たる責任があります。
 パッケージソフトウェアの選定を含めた「要件定義」が重要です。
 モデル契約書は、ユーザとベンダが協働して、しっかりとした「要件
定義」を策定することを重要視しています。
52
以上で第1章、第3章の解説は終了です。