Transcript 「情報システムの信頼性向上のための取引慣行・契約

第6章 利用方法に関するポイント
本章では、モデル取引・契約書追補版を導入・利用する
際の、ベンダ側のポイントを解説します。
2
要件定義は、プロジェクト全体を通して、重要な役割を果たしま
す。ここでは、特に要件定義段階での注意すべきポイントを解説
します。
要件定義における留意点
要件定義の
範囲と契約
当モデル契約で想定する要件定義を担当するコンサルタントに
はＩＴコーディネータも含まれますが、当モデル契約が適用できる
場合と、できない場合があります。
3
 要件定義を担当するコンサルタントの業務範囲
当モデル契約でのベンダには、要件定義を担当するコンサルタントやＩＴコーディネータが含まれており、
特にモデル契約書(A), (B), (C)の業務は、共通フレームでの企画、要件定義プロセス、いわゆる上流
工程に対応しており、コンサルタントやＩＴコーディネータが、要件定義業務を支援することを想定してい
ます。
 同一のベンダが要件定義から保守・運用支援までを一貫して受託した場合でも、各契約ごとに報告書
が提出されるものとしています。

 ＩＴコーディネータの留意点
ＩＴコーディネータは、「ユーザの経営戦略策定プロセス」～「ＩＴ導入後の経営戦略実行プロセス」まで幅
広くユーザの支援を行うことから、このような一貫した支援業務は、共通フレームでの想定外であり当
モデル契約では扱っていません。
 このようなケースでは、ＩＴコーディネータは、ＩＴコーディネータ協会が公開している「ＩＴコーディネータ業
務委任契約書（見本）」を参考にしてください。
 ＩＴコーディネータが、すでにＩＴコーディネータ業務委任契約に基づいて業務受託している場合、パッ
ケージを前提とした要件定義の策定に関わる場合は、該当業務に当モデル契約を、別途締結すること
が相応しいケースも考えられます。
 ＩＴコーディネータが、パッケージを前提とした要件定義の策定のみに関わる場合は、当モデル契約を
使用すると、当モデル契約を使用する後工程のベンダ契約との親和性が高くなります。

 コンサルティング会社選定のためのチェックリスト

モデル契約ではユーザ向けに「コンサルティング会社選定のためのチェックリスト」を公表しています。
コンサルタントの実績、専門性、コミュニケーション力、論理性、アウトプットイメージなどのチェック項目
を参考に、ユーザに分かりやすい提案を行う事に留意して下さい。
パッケージ導入に
おけるユーザの期
待
当モデル契約で想定する要件定義を担当するコンサルタントに
はＩＴコーディネータも含まれますが、当モデル契約が適用できる
場合と、できない場合があります。
4
 ユーザの期待




パッケージソフトウェアの持つ機能や業務の流れを利用する事で、自社の業務改革を実
施する事ができる。
導入期間とコストを削減することができる。
導入のための専門要員を確保しなくても、システムを導入する事ができる。
導入後、即座にシステムを稼働する事ができる。
 留意点（コンサルタントの心得）




パッケージソフトウェアをベースに開発したとしても、しっかりとした要件定義が重要であ
ることは、受託開発と何ら変わる事がありません。
ユーザの経営者、管理職、IT担当者が、自社の業務フローを詳細に把握していないケー
スが多いため、ユーザ自らが業務フローを把握し、協働して課題抽出、あるべき業務フ
ローを確定する努力が必要です。
反面、パッケージソフトウェアとして完成しているが故に、要件との適合性評価は、ユーザ
の要件と評価するパッケージソフトウェアをいかに熟知しているかにかかってきます。
また、評価の範囲はパッケージソフトウェアの機能、カスタマイズの実現性と難易度の評
価、開発会社のサポート体制、使用許諾契約の内容、将来のバージョンアップの動向な
ど、個々に専門性が高く、幅が広いことに留意します。
要件定義における
ユーザの成熟度の判
定
5
ユーザ企業のＩＴ経営化の成熟度にあわせた支援が必要です。
過度に高度なシステム導入は失敗を招きます。身の丈にあっ
たＩＴ化を心がけましょう。
 成熟度とは
 ＩＴ導入の検討に当たって、ユーザ企業の「ＩＴ経営化の成熟度」を調査する必要
があります。
 ＩＴ経営化の成熟度は、ＩＴ導入が担当部署の効率化の道具としてしか活かされ
ていないレベル1から、企業間取引の戦略レベルまで活用できているレベル4ま
で、経済産業省が策定した4段階モデルの「ＩＴ経営力指標」があります。
 留意点（コンサルタントの心得）
 企業の成熟度レベルが不明な場合は、「IT経営力指標」（当モデル契約＜追補
版＞で提示している「ユーザＩＴ成熟度チェックリスト」と同じ）などを活用し、ユー
ザ自身に診断をしてもらい、ユーザ自身に現状のレベルを理解してもらう必要
があります。
 そのうえで、到達可能なあるべき姿の成熟度を目標とするようユーザに指導す
ることが大切です。
 ユーザの担当者の思いや、コンサルタントの思いで、ＩＴ化を進めようとすること
は極めて危険です。
 ユーザが中小企業の場合、経営者の思いを必ず確認し、全社一丸となって業
務改革を成し遂げることへの合意を得ることが重要です。
要件定義における
セキュリティ要件の決
定
6
 セキュリティ要件
 業務システムの初期提案内容に、あらかじめセキュリティ対策も必要で
あることをユーザに認識いただくことが必要です。そして、実際に対策を
行うセキュリティ要件は、ユーザ側のシステムやポリシー、予算額によっ
て大きく異なります。また、予算を抑えるためにセキュリティ対策を削減
することも考えられます。そこで、セキュリティチェックシートを活用し、何
の対策をどの程度行うのかをユーザに説明し、重要事項説明書を利用
して同意を得ることが重要です。
 セキュリティチェックシートの活用
 セキュリティチェックシートは、セキュリティ対策の概念を記載しています。
そこで、ベンダが提供可能な製品・サービスをマッピングしておくことに
より、ユーザのレベルに応じたセキュリティ要件を説明・提案することが
可能となるでしょう。
要件定義における
移行・運用準備に対する
留意点

上流工程である要件定義プロセスにおいて、システム構
築後のプロセスについても留意しておく必要があります。
7
システム設計開発後の留意点（移行、運用準備等）





既設システムからのデータ移行は、システム開発業務において最も難しいとさ
れている業務です。データの連続性を確保した上で、業務停止を最小限にとど
め、新しいシステムを滞りなく稼働させなくてはなりません。
移行要件として、データの種類（マスタ、トランザクション等）、データの範囲（期
間等）、変換が必要な場合の処理と仕様、データの移行、データの精査、稼働
の確認及びバックアップ、業務停止、業務手順の変更等について、詳細な検討
が要件定義段階で必要です。
テスト支援業務は、ユーザデータを使用し、本番環境でのテストが信頼性確保
には欠かせません。データの精度や合否はユーザでないと判断できない場合
が多いことから、ユーザとベンダの役割を明確にした上で、要件定義でその仕
様、手順等を定めておけば、実稼働後のトラブル防止に寄与します。
一般にユーザは、設計開発以降は黙っていても完成度の高いシステムが納品
されると考えがちです。ユーザの関与が信頼性向上のポイントであることの理
解を得て、データ移行要件、テスト要件を定めておきます。
導入教育は、実際の操作担当者の、IT知識、実務経験、知識レベルを十分に
把握した上で、要件として定めておくべきです。
要件定義における
移行・運用準備に対する
留意点

上流工程である要件定義プロセスにおいて、システム構
築後のプロセスについても留意しておく必要があります。
8
システム構築後の留意点（運用・保守等）





企業における情報システムの安定稼働、信頼性の確保は、事業継続性にも大きく関わる
ことであり、特に運用に携わる要員のリテラシの確保や、保守体制の重要性は論をまち
ません。
ところが、情報システム構築においては、業務のシステム化や高度化に関心が集中し、
運用や保守からの仕様検討がなされず、あるいは構築費用の確保を優先することから
先送りが多く、これらが業務との不一致や運用上の障害解消を困難とする原因となり信
頼性を大きく損なっています。
本来、情報システムは一定期間、安定稼働することによって企業の業績に寄与するので
あって、運用と保守体制が要件として確立されなければならない点に着目し、要員教育、
保守、運用支援といったシステム構築後のプロセスも配慮が必要です。例えば、データ
の復旧について、直前のトランザクションまで復旧するか、前日のデータまで復旧するか
によって、システムの構成や可用性に関する考え方は大きく異なります。
さらに、保守、運用支援については、ハードウェア、OS、ミドルウェア等の構成要素別に
保守契約を締結するのではなく、一次的なサポートの窓口が設定されることを前提に、
障害の切り分けや問題のエスカレーションがなされることが必要です。
ユーザ自身が障害切り分けを行なうことができないことから、一次的な窓口は、ソフト
ウェア設計・制作業務及び構築・設定業務を行ったベンダ、またはその再委託先とし、下
流工程からの一貫性を維持することで、信頼性、安定性を確保する必要があります。
要件定義の
契約の留意点
要件定義業務におけるコンサルタントの法的な裏
づけは「準委任」契約です。
9
 契約
 要件定義業務でのコンサルタントの業務は、ものの完成を確約する「請負」契約
ではありません。ものの完成責任はユーザ側にあって、コンサルタントは完成の
「支援」を行うものです。
 調査、分析、提案活動などは、支援の一形態であり、コンサルタントは専門家と
して善良なる注意をもって、契約に定められた期限の中で契約に基づいた業務
を遂行します。
 従って対価は、完成した成果物に対して支払われるべきものではなく、支援する
業務の内容（範囲、専門性、複雑性、規模、期間など）に対して支払われるべき
ものです。
 用語の留意
 「開発」「作成」「成果物」「納期」といった言葉は、一般的に請負契約の業務での、
ものの完成を請け負ったとき使われるものです。
 準委任契約はユーザ支援が業務ですから、成果物や開発されたものはありま
せん。ユーザの求めに応じ、もしくは作業終了時には、ユーザ支援の「作業報告
書」を「提出」し、ユーザから作業報告に書かれた業務が適正かどうかの検収を
受けることに留意する必要があります。
10
モデル契約を利用する上での法律的な責任や注意点を解説します。
モデル契約及びシステム基本契約
書利用のポイント
モデル契約における
ベンダの責任について
(1)
11
 準委任契約のベンダの負う責任
 準委任契約では、ベンダは専門家としての善管注意義務を負っています。<モ
デル契約：追補版>ではこの義務を「情報処理技術に関する業界の一般的な専
門知識及びノウハウに基づき、ユーザの作業が円滑かつ適切に行われるよう
支援業務を行う」と具体的に定めています。
 上流工程を担当するベンダが善管注意義務を期待される場面
 ベンダは特に次の2点について善管注意義務を果たすことが期待されています。
① 要件定義の完成度
要件定義の完成度が低く、当然あるべき業務要件が抜けている、記述が曖昧
でシステム化できない、処理の細分化が不十分で結果として要件不足となった
などの基本的な問題が起きると、「業界の一般的専門知識に基づき、支援業務
をしなかった」として、善管注意義務違反（債務不履行）が問題となります。
② パッケージのフィット＆ギャップ分析
パッケージソフトウェア選定支援業務で、業務要件を満たせない、カスタマイズ
が実現できない等のパッケージソフトを選定すれば、やはり善管注意義務違反
となりえます。大幅に業務の方を変更する必要があったり、カスタマイズすると
予算を大幅に超える可能性がある場合は、その旨もユーザーに報告しましょう。
モデル契約における
ベンダの責任について
(2)
12
 請負契約におけるベンダの義務
 設計開発段階又は移行・運用段階を担当するベンダは、請負契約に基づき仕
事の完成義務を負います。請負契約は仕事の完成そのものを約束する契約で
あり、この点で、事務処理を約束する準委任契約とは異なります。
 請負契約では、ベンダは重要事項説明書で指定された要件定義書、仕様書に
基づきプログラム、マニュアルなどの成果物を完成させ、もしくは、設定作業な
どを完了させて、納期までにユーザに納める義務があります。納期までに成果
物を納めたり作業が完了できない場合は、ユーザに協議を求め、納期の変更
等を改めて定めなくてはなりません。
 一般に請負契約では、納期までに仕様通りの成果物を完成させれば、作業の
進め方や再委託などは請負側の自由な裁量で行えるとされています。しかし、
情報システム構築は、ユーザとベンダの協働が基本で、システム基本契約書、
重要事項説明書で定められた、連絡協議会での進捗報告・確認を怠ってはなり
ません。
 ユーザは、請負だからといって、すべてをベンダに丸投げせず、ベンダは勝手
気ままに作業を進めることが無いように、密接な連絡を基本にしなければなりま
せん。
モデル契約における
ベンダの責任について
(3)
13
 ベンダのプロジェクトマネジメントについて
 ベンダは専門家の立場で業務をユーザから委託されています。従って、契約した業
務の進捗や成果の達成には責任があります。例えば、ユーザにはITの知識がなく、
必要な資料をまとめることができない場合は、質問したり、適切なひな形を提供した
り、提案をするなどして、業務が合理的な範囲で進捗するようにユーザを支援しな
ければなりません。
 ユーザの都合で、プロジェクトが遅延する場合はベンダの責任とは言えませんが、
専門知識のないユーザに対して、ベンダは工程表やマイルストンを示して、常に適
切なアドバイスや支援を行い、契約で定めた期限内に業務を成功に導くプロジェクト
マネジメント義務があります。
提案書や説明資料と
契約書の関係について
契約前に提出した文書と契約書の内容が
異なるとトラブルの原因になります。
14
 契約書以外の合意事項について
 契約内容は、すべてシステム基本契約書及び重要事項説明書に記載
します。また、この契約内容を変更するには、書面を作成して記名押印
するなどの手続が必要であり、変更を口頭やＥメール等で行うことはで
きません。
 ただし、契約内容の解釈上、契約交渉の際の説明やユーザに交付した
資料の内容が、ベンダの契約上の義務であると扱われる場合がありま
す。
 また、営業担当者等が事前に説明した内容とシステム基本契約書や重
要事項説明書に記載された内容が異なる場合には、トラブルを生じか
ねません。
 無用のトラブルを避けるため、交渉等の際に、「契約内容の確定や変更
はすべて権限のある者が書面をもって行う必要がある。」と説明し、また、
ユーザに交付する資料にはそれが契約内容となることはない旨を記載
しておく必要があります。
誠実な営業行為
契約前であっても、虚偽の説明をしたり、重要な事実を告げ
ずに営業する行為は損害賠償請求の対象になります。
15
 ユーザは、ベンダを専門家として信用して交渉を行なっています。ユーザの信用
を裏切る次のような行為は厳に慎まなければなりません。
 他の競合するベンダとの交渉を打ち切らせる目的で、不当に安い価格を提示して契約
し、その後、高額の保守料金を提示する。
 重要な事実を告げないで交渉する。
 意図的に異なる説明をして契約締結を迫る。
 ユーザは、ベンダの説明を信用し、他のベンダとの交渉を打ち切ったり、導入を
前提に準備を行なう場合があります。従って、万一、間違った情報を提供したり、
資料を提出した際は、速やかに、訂正を申し出なければなりません。新旧製品の
切り替えや、サポート期間の打ち切りなど、ユーザにとって不利となる情報は、速
やかに提供するように心がけましょう。
 虚偽や意図的に重要な事実をユーザに伝えない、著しい説明不足があった場合
は、例え契約を締結していなくても、製品やシステムが納品されていなくても、ユ
ーザから損害賠償を請求されることがあります。誠実な営業姿勢を守りましょう。
ベンダの責任
判例から(1)
16
 ベンダの負う責任
 既述の通り、ベンダは、要件定義フェーズ、移行・運用フェーズでは、要件定義・
パッケージソフト選定の支援、新システムへの移行・運用のために必要な業務
を、委託された者として忠実に行う義務を有しています。
 「請負契約」においては、善管注意義務で規律される「委任契約」と異なり、ベン
ダは仕事の「完成義務」を負っています。ユーザの要望事項の増加は往々にあ
ることですが、「専門家の責務」として、適切にスケジュール管理を行い、納期ま
での完成に努めなければなりません。
 また請負契約においては、納品が済んだ後でも、納品物が通常備えなければ
ならない性質・性能を有していない場合、ベンダは請負人の担保責任として「瑕
疵」の修補や損害賠償を求められることがあります。
 以上のように抽象的に「請負契約」、「委任契約」、「完成義務」、「瑕疵」、「専門
家の責務」といってもイメージが沸きにくいと思いますので、以下3つほど実際の
事件を例としてあげて、その中で裁判所が具体的にどのように考えているかを
紹介します。裁判は個別の事件ごとに判断が下されますので、似た事実関係な
らば常にまったく同じ結論が出るというわけではありません。しかし裁判所はベ
ンダの責任についてどのように考えているか考察する一助には十分なります。
ベンダの責任
判例から(2)
17
具体例①
「請負契約か委任契約か」、「請負人の義務」についての例*1
 ポイント
 ユーザからの必要な資料提出が遅延していても、ベンダは仕事完成しないと代金の請求
はできない
 争点*2
本件契約は、請負契約か準委任契約か。
 元請会社が、設計書・仕様書を提出しなかった場合、下請会社は、プログラムを完成させなくても、指示
に従って作業をすれば債務を履行したことになるか。

 事実の関係
 ユーザーからシステム開発の依頼を受けた元請会社は、下請会社に一括してこのプログラム開発を発
注した。しかし納期を過ぎてもプログラムは完成されなかった。なお元請会社は、その前に代金の一部を
支払っている。
 下請会社は、①契約は準委任契約であり、プログラム完成は条件ではなかった、②仮に請負契約でも元
請会社から設計書、仕様書が随時に提出されなかったので完成できなかったのであり、指示に従って作
業した分の請求はできると報酬代金を請求した。
 参考となる判断部分
 すでに支払われた金員は前渡金である。下請会社の作成した開発工程表が下請会社がプログラムの完
成義務を負っていることを前提に引かれていること、下請会社の規模でも十分に完成させることができる
ことなどから、契約は請負契約である。
 請負契約なので、下請会社はプログラム完成義務を負っており、債務不履行の責任を負うことはあって
も、請負代金の支払の請求は出来ない。仕様書の提出が遅れたり、指示が変わったため作成が遅延し
たとしても、これらは遅延についての責任免除の理由とはなっても、プログラムの完成義務自体を免除す
る根拠にはならない。
＊１ 東京地判平成3年2月22日民事第12部 ＊２争点は他にもあるが、説明に必要な争点、およびそれに関連する事実、結論のみ抜粋
ベンダの責任
判例から(3)
具体例②
「瑕疵」についての例*1
18
 ポイント
 機能に軽微でない支障が生じ、遅滞無く補修がされないと、「瑕疵」になる。
 争点*2


事実の関係


どのようなバグが存在すると、プログラムの欠陥（瑕疵）となるか。ユーザの指摘を受けて協議の上、代替
措置を講じたときでも、瑕疵があるといえるか。
貨物運送業を営むユーザは、車両の管理、受注発注などの業務をシステム化するため、システム開発委
託契約をベンダと締結。しかしユーザは、納入されたシステムにつき、月次更新処理に10時間もの時間が
かかる、運賃の修正結果が売上元帳に計上されない、運行キャンセル、荷主・車両・乗務員の変更に不具
合があるなどの欠陥があると主張し、プログラム開発代金および運用のためにかけたリース代金をベンダ
に対して請求をした。
参考となる判断部分




ユーザも、既成ソフトの無い分野につきシステムを構築する場合、システムの規模及び内容によっては、一
定のバグ混入も承知しなければならない。
バグがあっても、不具合発生の指摘を受けた後、遅滞なく補修を終え、又はユーザーと協議の上相当と認
める代替措置を講じたときは、瑕疵と評価することはできない。
逆に機能に軽微とはいえない支障が生じる上、遅滞無い補修が不可能であり、又はその数が著しく多く、し
かも順次発現してシステム稼動に支障が生じる場合、瑕疵にあたる。
以上の基準により、裁判所は、全てのバグにつき、補修が行われて不具合は解消されたか、業務に支障を
きたすものでないか、そのような機能を設ける旨の合意がユーザ・ベンダ間でなかったと判断し、瑕疵があ
るというユーザの主張については理由がないとした。
＊１ 東京地判平成9年2月18日民事第26部 ＊２ 争点は他にもあるが、説明に必要な争点、およびそれに関連する事実、結論のみ抜粋
ベンダの責任
判例から(4)
具体例③
「瑕疵」およびベンダが「専門家として負う義務」につ
いての例*1
19
 ポイント


争点*2



処理速度が、どの程度遅ければ、瑕疵となるか
ユーザの要望事項の増加や、データ運用方法の仕様が未確定で、これらが処理の迅速化を阻害する要因
であると認識していた場合、ベンダはどのような義務を負うか（請負の担保責任に基づく解除は、ユーザの
指図に起因する場合認められないため争点となる）
事実の関係


ベンダは、プロジェクトの阻害要因を認識した場合、これを指摘して改善を求める注意義務を有する。
石材の加工・販売をするユーザは、ベンダと商品の販売管理、製造管理などのシステム開発業務の請負
契約を締結した。何度かの遅延、補修ののち、ようやく本稼動したシステムにつき、ベンダは、請負代金を
請求したが、ユーザは、処理速度の増大など多数の瑕疵を指摘して、契約の解除して既払い金の返還な
どを請求した。
参考となる判断部分


裁判所は、30分程度かかっていた月次処理が4時間に増加したこと、在庫照会の検索処理も30分以上要
する場合があるなどの不具合につき、販売管理システムには迅速化合理化が求められているので、こうし
た処理速度が遅いことは瑕疵にあたり、それに伴う通信費増大も瑕疵にあたると認めた。
本件の事実関係下では、ベンダは専門家として、有する高度の専門的知識経験に基づき、処理の迅速化
という目的の実現に務めるべき責務を負っており、ユーザの要望事項増加やデータ運用方法の仕様未確
定など、処理の迅速化を阻害する要因を認識した場合、指摘し改善を求めるべき注意義務がある。
＊１ 東京地判平成14年4月22日民事第36部 ＊２ 争点は他にもあるが、説明に必要な争点、およびそれに関連する事実、結論のみ抜粋
損害賠償につい
て
(1)
20
 損害賠償請求
 作業の完了が納期に遅れた場合や障害が発生した場合、ベンダとユーザが協議しても決着し
なければ、損害賠償が問題とならざるをえません。損害賠償の可否・範囲については、事前の
契約内容が重要になります。
 相手方が契約上の義務を履行しなかった場合や、納品されたソフトウェアに瑕疵があった場
合、それにより損害を被った当事者は、損害賠償を請求することができます。
例① 要件定義段階の支援業務に義務違反のあるケース
要件定義支援を委託されたベンダの業務についての理解不足およびスキル不足から、
重要な部署へのインタビューが行われなかった。その結果、優先順位の高い業務が要
件定義から漏れてしまった。
例② システムに瑕疵があるケース
開発業務を行ったベンダが設計書の記述を見落として、そのまま開発、納品が行われ
た。瑕疵の修正には、データベースの大幅な変更が必要で、新たな追加費用が発生す
ることが判明した。
例③ 設計・開発段階でベンダが負う責任を果たさないケース
外部設計支援業務から参画したベンダは、ユーザの要件定義が不完全であること、
データ運用に問題があることをすぐに気づきながら、これを指摘しなかった。その後、シ
ステムのバックアップが業務停止時間内に終了せずに、ハードウェアの追加調達が必
要で、新たに費用がかかることが判明した。
損害賠償につい
て
(2)
21
 損害賠償額の上限
 システム開発の特殊性として、情報システムは、企業の基幹業務に関連するた





め、その瑕疵などに関連して生じる損害は、多額になりうることが挙げられます。
ベンダは、原則として債務不履行や瑕疵と相当因果関係にある損害を賠償する
ことになりますが、これはベンダに過重な負担を課することになります。特に瑕
疵担保責任の場合は、過失の有無にかかわらず多額の損害賠償責任が生じる
ことになります。
また、第三者が上流工程を担当していた場合など、リスクとその範囲を予想す
ることは困難です。
しかし、ベンダが多額の損害賠償リスクを想定して契約金額を算定することにな
れば、その分契約金額が上がる可能性があります。
そこで、合理的なリスク計算のため、賠償金額の上限や範囲、請求期間を予定
することが必要となります。これにより、ベンダは、リスクに萎縮することなく業務
を行うことが出来るようになります。これこそが損害賠償額の上限規定が重要と
される理由です。
ベンダはなぜ損害賠償金額を決める必要があるのかを、事前にユーザに説明
する必要があります。
損害賠償につい
て
(3)
22
 損害賠償の予定とは
 損害賠償の額については、予め重要事項説明書で、
①賠償金額の上限、②賠償の範囲、③請求できる期間を定めることができます。
①の例
「損害額の上限を、委託料250万円とする」（委託契約が解除され、委託料が
支払い済みの場合、この例であれば、委託料の返還に加えて、250万円を上
限とする損害賠償請求がされうる）
②の例
「損害賠償責任の範囲は、直接の結果としてユーザが現実に被った通常の損
害に限定する」
③の例
「ユーザがベンダに対して損害賠償請求を行うことの出来る期間は、業務完
了確認書兼検収確認書をベンダに交付してから、1年以内とする」
損害賠償につい
て
(4)
23
 損害賠償の上限金額の算定方式
 システム開発を進める段階毎に、複数の個別契約を締結する場合に上限金額を定めると
きは、以下の損害賠償の算定方式を参考に、いずれかを選択しなければなりません。こ
の選択は、ユーザと合意し、全ての個別契約で特約条項として記載しなければなりません。
 3種類の算定方式
① 全部合算型： １個の基本契約に対応するすべての個別契約（重要事項説明書）に基づく損害賠償金額
の合計は、それらの個別契約に定める上限金額を合算したものを上限とする方式。
同一のベンダが複数の工程を受託する場合は、個別契約を締結するごとに上限額が加算されることに
なります。しかし、別のベンダが個別契約を締結しても上限額は変わりません。
② 一部合算型： 当事者が指定した複数の個別契約（重要事項説明書）に基づく損害賠償金額の合計は、
それらの個別契約に定める上限金額を合算したものを上限とする方式（指定されていない個別契約の
上限金額は合算に含めない。）
③ 独立型： 損害賠償金額の上限は、複数の個別契約（重要事項説明書）の上限金額を合算することなく、
個別契約ごとに独立して定める方式
 合算型と独立型の違い
 例えば、要件定義に問題はないが、設計段階で致命的なミスがあり、その後の開発で
まったく業務に使えないシステムができた場合、独立型ではユーザは使えないシステムの
ため投資した金額のうち、設計段階の契約の上限金額のみしか請求できなくなります。こ
れに比べて全部・一部合算型の算定方式の方が、同じベンダが上流部分を担当している
場合、ユーザにとって有利となります。
再委託について
24
 再委託先の開示
 ベンダはユーザから委託された業務を、他のベンダに再委託することができま
す。しかし、ベンダはユーザから請求があった場合は、再委託するベンダの住
所、会社名等を開示しなければなりません。
 再委託の中止
 ユーザは、再委託先と競合状態であったり、セキュリティが不完全であるなどの
正当な理由がある場合は、理由を書面にしてベンダに通知すれば、ベンダに再
委託を中止させることができます。
 作業の開始後に再委託の中止があった場合
作業が再委託先で進んでいるにも関わらず、ユーザの請求で再委託が中止と
なった場合は、受託金額、作業期間、納期などを変更する必要があり得ます。こ
の場合には、契約変更手続（システム基本契約書第2条⑥）にそって、契約条件
の変更の協議を行い、ユーザ及びベンダは、合理的な範囲での変更合意を行う
義務があります。
25
取引・契約モデル
の
全体像(1)
 プロジェクトの進行を管理する
 判例にもあるように、ベンダは専門家として負う義務があり、プロジェクトのス
ムーズな進行には、一定の責任があります。
 ユーザに、重要となる工程や、スケジュールを理解させるためにも、契約締結
前に、契約で実施される業務全体の流れをユーザに説明しましょう。
 「取引契約モデルの全体像」を活用する
 全体像は、業界の標準的な取引の流れをモデル化したもので、業務の流れ
や相互の役割を明確にするものです。
 相互に何をやるかが明らかになる
 業務の進捗や達成状況のチェックができる
 未決事項や業務遅延が発生した場合に、後工程への影響などを確認できる
 取引契約モデルの全体像を利用し、工程の内容とスケジュールを説明しま
しょう。全体像は、上流工程の進め方で以下のように分かれています。
 ＜別紙1＞
 ＜別紙2＞
カスタマイズモデル用
オプションモデル用
 必要に応じて適宜変更して、活用しましょう。
取引・契約モデル
の
全体像(2)
（パッケージ、SaaS/ASP活用、保守・運用）＜追補版＞
要件定義段階が、2つの契約で構成されています。A契約で業
務要件定義書が提出され、それに基づいて、パッケージの選
定（フィット&ギャップ、カスタマイズの実現性の検討）をB契約で
実施します。
別紙1
パッケージカスタマイズ取引・契約モデルの全体像
※数字は共通フレーム2007 該当項番
1.4 企画
26
1.6 開発
1.7 運用 1.8 保守
1.5 要件定義
設計・制作・テスト・移行
運用準備
パッケージソフトウェア利用コンピュータシステム構築委託契約書
( カスタマイ
重要事項 説明書 A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
ズモデル )：準委任 、 (1)～ (13) 適用、 B パッケージソフトウェア選定支援及び要件定義支援業務契
約 (カスタマイズモデル )：準委任、 (14) ～ (18) 適用
重要事項説明書 D 外部設計支援業務契約：準委任・ (21) ～ (23) 適用、 E ソフトウェア設計・制作契約：請負・ (25) ～
(29)適用、 F 構築・設定業務契約：請負・ (30) ～ (32) 適用、 G データ移行支援契約：準委任・ (33) ～ (34) 適用、 H運用テ
スト支援契約：準委任・ (35)～ (37) 適用、 I導入教育支援契約：準委任・ (38) ～ (39) 適用
D 外部設計支援契約
A 要件定義支援及びパッケージ
ソフトウェア候補選定支援契約
(1) 事業要件定義
G データ移行支援契約
(8) ベンダに対しパッケージ候補選
定のための情報提供依頼(RFI)
(21) 使用許諾によってはパッケージ、
OS、ハードの導入及び保守の開始
（一部保守開始*1）
(15) パッケージ候補の
システム要件評価
(16) APIの実現性の確認（候補
(2) プロジェクトゴールの策定
(3) 要求品質の明確化
(4) パッケージを利用し実現する
業務の新全体像の作成
(5) ベンダに対しシステム、パッ
ケージ等の情報提供要求、試算
見積依頼(RFI)
(6) ユーザに対しRFIに基づくシ
ステム、パッケージ等の情報の
提供、試算見積の提示
重要事項説明書 J 保守契
約：準委任・ (14)(21)
(25)(41)適用、 K 運用支援契
約 ：準委任、 (42)適用 )
(9) ユーザに対しRFIに基づくパッ
ケージ関連情報の提供、概算見積
の提示*2
(10) パッケージの機能要件、非機
能要件、使用許諾契約（利用条件、
保守等）の検討
(11) パッケージ候補の選定
(12) 業務要件及び適合するパッ
ケージ候補の報告書の提出
(22) モディファイ、アドオンの範囲の
確定、及びそれに伴うユーザI/F・他
システムI/F設計*3
パッケージの API、既存システムとの接
続性等の評価）
(34) 完了報告 (受入れ）
K 運用支援契約
(23) 外部設計書の承認(受入れ)
(24) ユーザへの見積提出
(18) 受入れ
E ソフトウェア設計・制作契約
(19) ベンダへの見積要求*2
(25) ソフトウェア設計*1
(42) 運用支援
(35) 運用に関わる作業手
順の確立
(43) システム運用評価
及び業務運用評価
(36) 運用テスト
(37) 完了報告(受入れ）
(43) 投資効果及び業務
効果の評価
(20) ユーザへの見積提出
(
29
29
)
検
迎
収
枝
毳
（
(
礼
受
枝
党
入
・
れ
±
黨
）
j
(26) モディファイ、アドオンの設計、
プログラミング、ソフトウェアテスト
)
Bパッケージソフトウェア選定支援
及び要件定義支援契約
(30) 構築業務
（機器・ OS 等の設定、納品）
(
F 構築・設定業務契約
(14) 使用許諾によってはパッケー
ジ、OS、ハードの導入及び保守の
開始（一部保守開始*1）
(41) ハード保守、カスタ
マイズ部分保守開始
H 運用テスト支援契約
(17) パッケージソフトウェアの
選定と要件定義
システム要件定義と評価
(13) 受入れ
(7) 業務要件定義
(33)データ移行
J 保守契約
(31) システム結合、テスト
(32) 検収 (受入れ）
(27) 適格性確認テスト、監査、
ソフトウェア導入
I 導入教育支援契約
(45) 廃棄
(38) 利用者導入教育
※ ユーザ主体／ベンダ支援
(39) 完了報告（受入れ）
※ ベンダ主体
(28) 納品
(40) 業務運用
取引・契約モデルの
全体像(3)
（パッケージ、SaaS/ASP活用、保守・運用）＜追補版＞
要件定義段階が、1つの契約で構成されています。業務要件
定義とパッケージ選定を同じ契約で行います。パッケージを
比較しながら、要件を固めていくのが特徴です。
別紙2
パッケージオプション取引・契約モデルの全体像
※数字は共通フレーム2007 該当項番
1.4 企画
27
1.6 開発
1.7 運用 1.8 保守
1.5 要件定義
設計・制作・テスト・移行
運用準備
パッケージソフトウェア利用コンピュータシステム構築委託契約書
重要事項 説明書 Cパッケージソフトウェア選定支援及び要件定義支援業務契約
ル ) ：準委任 、 (1)～ (18) 適用
重要事項説明書 D 外部設計支援業務契約：準委任・ (21) ～ (23) 適用、 E ソフトウェア設計・制作契約：請負・ (25) ～
(29)適用、 F 構築・設定業務契約：請負・ (30) ～ (32) 適用、 G データ移行支援契約：準委任・ (33) ～ (34) 適用、 H運用テ
スト支援契約：準委任・ (35)～ (37) 適用、 I導入教育支援契約：準委任・ (38) ～ (39) 適用
)
Cパッケージソフトウェア選定支
援及び要件定義支援契約
(
(
(21) 使用許諾によってはパッケージ、
OS、ハードの導入及び保守の開始
（一部保守開始*2）
(33)データ移行
(16) APIの実現性の確認（候補
パッケージの API、既存システムとの接
続性等の評価）
(22) 外部プログラムの範囲の確定、
及びそれに伴うユーザI/F・他システ
ムI/F設計*3
(17) パッケージソフトウェアの
選定と要件定義
システム要件定義と評価*2
(
(
K 運用支援契約
(24) ユーザへの見積提出
(18) 受入れ
(42) 運用支援
(35) 運用に関わる作業手
順の確立
(
E ソフトウェア設計・制作契約
(19) ベンダへの見積要求*3
)
(30) 構築業務
（機器・ OS 等の設定、納品）
(31) システム結合、テスト
(14) 使用許諾によってはパッ
ケージ、OS、ハードの導入及び
保守の開始（一部保守開始*2）
29
(
29
検
)
収迎
枝
毳
（
受(枝
礼
入党
れ・
）黨
±
)
(11) パッケージ候補の選定
F 構築・設定業務契約
(
(10) パッケージの機能要件、非
機能要件、使用許諾契約（利用
条件、保守等）の検討*1
(25) ソフトウェア設計
（一部保守開始*2）
(20) ユーザへの見積提出
j
(32) 検収 (受入れ）
(26)外部プログラムの設計、プログ
ラミング、ソフトウェアテスト
(43) システム運用評価
及び業務運用評価
(36) 運用テスト
(
(7) 業務要件定義
)
(6) ユーザに対しRFIに基づくシ
ステム、パッケージ等の情報の
提供、試算見積の提示
(41) ハード保守、外部プ
ログラム等保守開始
(34) 完了報告 (受入れ）
(23) 外部設計書の承認(受入れ)
)
)
(5) ベンダに対しシステム、パッ
ケージ等の情報提供要求、試算
見積依頼(RFI)
J 保守契約
H 運用テスト支援契約
)
(4) パッケージを利用し実現する
業務の新全体像の作成
G データ移行支援契約
(15) パッケージ候補の
システム要件評価
)
(3) 要求品質の明確化
)
(2) プロジェクトゴールの策定
(
(1) 事業要件定義
重要事項説明書 J 保守契
約：準委任・ (14)(21)
(25)(41)適用、 K 運用支援契
約 ：準委任、 (42)適用 )
D 外部設計支援契約
(
提 要 別 12 パ
・紙
扶( ッ
マ
供マ
マに
X
ﾉ厭 ﾊ
pマ
枝 12
ケ
～
)
bマ
タN
１
・応
±
・ ・
栲
ー
±
P
(
ス迎じ
・を
ｶ
`
1 13 ジ
・
[マ
ﾄ( 参
クJ・ て
枝 13
) オ
マ
・
扶5)5 照
はW
を閘
殉
Q
Iマ
殉プ
ﾍ
・ 殉す
省
繰ﾔ
vマ
・
ﾆ
扶 ﾈ
蕓
抑シ
・情
略
りｵ
る
マ
V
・
ｷ
筑 ｪ・ ョ
ﾄ・ 報
・マ
・ さ
驀
返諳
・提
・ ン
ｳ
急こ
マ
党
・
ｱ
とれ
し｢±
モ
・
黨
抑
毳
± ﾄ・ ・マ
ﾆ
てB 供
( てデ
B
fマ
v急。
｢・ ル
よ要
い
・
急
±2
)2 驀
±で
・
い求
(` ± る
扶ﾅ
B
`( 。 は
±
～
。～
抑ﾍ
K
6
(
A
)殉
必
14
)・ v・ 、
14
6蕓
)88
要
扶ﾅ
・ ﾉ厭 ±
・で
・ `(
栲
±に
ﾍ
情
筑は
ﾌ
扶応
A
・ ～
ｶ
9
報
急、
ﾄ± ±
抑じ
K
A j±
の
マ必
毳
v て A9
^
、、
(オプションモデ
(37) 完了報告(受入れ）
I 導入教育支援契約
(43) 投資効果及び業務
効果の評価
(45) 廃棄
(38) 利用者導入教育
(27) 適格性確認テスト、監査、
ソフトウェア導入
※ ユーザ主体／ベンダ支援
(39) 完了報告（受入れ）
※ ベンダ主体
(28) 納品
(40) 業務運用
重要事項説明書の
注意事項(1)
28
 上流工程を受注するベンダの説明責任

要件定義の内容が後工程を担うベンダにとって、曖昧だったり不明確であったりすると、その業務の信頼
性が著しく低下する可能性があります。上流工程を担うベンダには、後工程を担当するベンダへの説明責
任があることを十分に認識して契約を締結して下さい。
 契約ごとに作成し説明する
要件定義から保守・運用までのすべてのプロセスの流れに沿って、業務契約を締結する時々に利用され
るものです。一度に、すべての項目を記載して１回で説明を行い契約するというものではありません。個
別契約ごとに説明が実施され、ユーザ、ベンダともに業務の内容を詳しく確認した上で契約するということ
に注意して下さい。
 一方で、例えば外部設計からソフトウェア設計、構築、データ移行、テスト支援、導入教育と一貫して業務
を受注する場合は、将来、締結するであろう個別契約に「予約」と記入しておきます。当然ですが、未定の
内容は未定と記入しておきます。
 「予約」として記入した個別契約は、そのままでは効力は発揮しませんが、将来締結する契約内容を予め
明示することにより、①事前にユーザに業務内容の説明を行い流れを理解してもらう、②要件の先送りや
仕様変更が発生した際に、それ以降の工程への影響を予見できる、③変更が発生した場合に、都度、納
期や費用の見直しができる、といったメリットがあります。

 上流工程から保守・運用まで一括で受注する場合

業務開始の初期段階では､取引の流れと必要となる契約書類の締結のタイミングについて説明が必要で
す。特に、重要事項説明書は、初期段階では内容部分が空白になることがありますが、順を追って決定
事項を明記し確認していくことをユーザに認識していただくことが必要です。
重要事項説明書の
注意事項(2)
29
 連絡協議会の実施要項では、会議体の主宰者、議長、議事録作成などの役割
のほか、日程や場所についてもできる限り具体的に記載しておく必要がありま
す。
 未決事項については、該当の重要事項説明をする時点で決まっていないが業
務終了までに決めるべき事項について記載をします。
 付帯事項については、作業項目として記載できなかった他の決め事を記載しま
す。
 特約事項には、当事者間での約束事について記載します。付帯事項とは異な
り、契約事項や賠償について記載が必要な場合に使用します。
 受託金額及びその決定基準には、原則として当該フェーズの受託金額を記載
します。ただし、予め金額が確定できない場合は、何が確定したら受託金額を
決定できるのかを明記しておく必要があります。
 損害賠償については、その上限金額を定めることができます。この場合、上限
金額だけでなく、その算定方式（全部合算型、一部合算型、独立型等）も記載し
ておく必要があります。
30
以上で第6章の解説は終了です。
eラーニングメニューに戻り 「第6章のセルフチェック」を選択して、
理解度の確認テストを受けてください。