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