挿 入 - コンピュータソフトウェア協会

Download Report

Transcript 挿 入 - コンピュータソフトウェア協会 

第6章 利用方法に関するポイント
～
ユーザ視点でのポイント
～
本章では、モデル取引・契約書追補版を導入・利用する
際の、ユーザ側及びベンダ側の双方におけるポイントを
解説します。
画面左下のスタートボタン（
）を押してスライドを進めます。
はじめに
(1)
2
挿 入
 情報システムは、私たちの生活に深く浸透しています。銀行やコンビ
ニエンスストアのATM、鉄道や航空会社の予約システム、インター
ネットを通じた株式取引や通信販売など、情報システムは、豊かな
生活と便利な社会を作るために必要な社会インフラになったと言って
よいでしょう。
 しかし、ひとたび情報システムにトラブルが起きれば、個人、企業を
問わず、様々な弊害を招く社会になったと言う事もできます。オンラ
インシステムや決済システムの不具合だけでなく、企業システムのト
ラブルは、企業活動に深刻な打撃を与えます。金銭的な損害はもと
より、顧客の信頼を損ねたり、企業活動の停滞を招きかねません。
 情報システムの信頼性の向上は、社会的な要望であり、私たち情報
サービス産業に従事するものにとっての使命とも言える重要な課題
になっています。
はじめに
(2)
3
挿 入
 しかし、ITや契約・法務に詳しい人材がいない中小・中堅企業にとっては、高
度化・複雑化する情報技術を利用した業務システムを導入することは決して
容易なことではありません。
 また、中小・中堅企業の多くは、システム導入にあたってパッケージソフト
ウェアを中核に、モディファイ、アドオン開発を行うのが一般的です。業務に
よっては、パッケージソフトウェアを変更せず業務形態を改善する導入方法
も多数、見受けられます。
 こうした、ITや契約・法務の専門家を配置できない中小・中堅企業、学校、病
院、地方自治体、公的機関を対象に、パッケージソフトウェアを活用したシス
テム構築のための判りやすい契約書の策定が求められました。
 2008年4月にモデル取引・契約書＜追補版＞が策定され、中小企業の取引
の多数を占めるパッケージソフトウェアを活用した業務システムを想定し、対
等の交渉力を有しないユーザとベンダのための契約書が公表されました。
情報システム
取引の特徴
4
挿 入
 情報システム取引は様々な業務の集合体
 情報システム取引は、業務分析などのコンサルティング業務から、プログラム制
作などの知識集約型の専門業務、保守、運用などのサービス業務と、まったく
性質の異なる取引が、積み重なった複合取引です。それぞれの業務は、深い専
門性と変化が激しいという特徴があります。
 ユーザの興味と価値観
 ユーザは、ITの専門性や、難易度について興味を持っている訳ではありません。
 ITを含めた業務システム全体が正しく運用され、その結果として、仕事の負荷
が減ったり、無駄なコストが削減されることを価値として認めています。そして、
雇用を守り、利益を出し、成長していく事がもっとも重要なことなのです。あくま
でITやコンピュータシステムは、その手段でしかありません。
ユーザとの関係
5
挿 入
 情報システムのプロとして Win-Winの関係作り
 私たちは、情報システムに携わるプロフェッショナルとして、ユーザの期
待に正しく応え、その結果として利益を上げなくてはなりません。
 そして、プロフェッショナルとしての知見を高め、より高度なソリューショ
ンの提供を提供し続けなければなりません。
 ユーザの視線と期待
 ユーザは情報システムの専門家ではなく、かつ、情報システム取引の
経験が豊富な訳ではありません。
 情報システムに関連する業務に従事している私たちは、ユーザからみ
れば、ITやコンピュータシステムの専門家です。
 病気にかかれば医師に、税金で判らない事があれば税理士に相談す
るように、ユーザは、ITについて専門家である私たちの助言や、手助け
を必要としています。
情報システム取引の勘
所
上流工程(1)
6
挿 入
 要件定義
 新たに構築する（あるいは再構築する）業務、システムの仕様を明確化し、それをベースにIT化範囲とその
機能を具体的に明示すること。
 関連する組織およびシステムに対する制約条件を明確にし、定義された内容について取得者側の利害関
係者間で合意することである。
 言い換えれば以下のようにまとめることができます。
①業務の流れ（人・モノ・金・データ）の動きを明確化して、②その中でIT化すべき範囲と、③ITで実現される
各種機能・性能を、④具体的に分かりやすく文書化する、⑤「ITで出来ること、出来ないこと」「人が作業する
こと」「例外的な措置」などをまとめ、⑥それらをユーザ関係者全員が理解し納得すること。
 ユーザは上流工程に不慣れ
 本来、要件定義はユーザの責任です。しかし、情報システム構築に不慣れなユーザは、コンピュータシステ
ムを導入してしまえば「何もかもが自動化され人は煩わしい業務からすべて解放される」と考えがちです。ま
た、コンピュータシステムは「何でもできる」、「素早くできる」という漠然とした期待があります。
 また、ユーザは「こうしてほしい」、「こんな風に」という漠然とした要望はあっても、具体的にシステムの仕様
を明確化したり、IT化の範囲を設定することはできません。さらに、仕様変更がコストや納期に及ぼす影響
について知識がありません。
 要件定義はもっとも重要
 要件定義が完成しないと、①適合性の高いパッケージソフトウェアの選定ができない、②カスタマイズが発
生する際の、設計・開発以降の費用見積や納期算定が正確にできない、③設計・開発工程で大幅な仕様変
更が発生する可能性が高まる、などの問題を引き起こします。
 コスト、納期、信頼性を確保するためには、要件定義をしっかり行なうことがもっとも重要です。
情報システム取引の勘
所
上流工程(2)
7
挿 入
 ユーザの責任
 ユーザはパッケージの選定や仕様の最終決定に責任を負います。ベンダにす




べてを委ねるのではなく、ベンダと一緒に自社のシステムを構築しなければなり
ません。
要件定義は現状の業務フローの見直しであり、業務合理化のチャンスです。反
面、現場の作業は大幅な変更が求められたり、負担が増える場合もあります。
担当者のみならず、システムに関わる利害関係者の参加と調整が必須です。
不明な点や、判らない用語をそのままにせず、納得のいく説明を求めるとともに、
決定事項、未決事項などをまとめた議事録を点検、承認し、プロジェクトの進行
に努めなければなりません。
要件定義後の仕様変更は、①選定したパッケージが使えなくなる、②カスタマイ
ズ工数に多大な影響を及ぼす、③信頼性の低下の原因になる、などの悪影響
があり、納期の延長や増大する費用の負担をしなければなりません。
このため、要件定義の最終決定に際しては、未決事項の先送りを避けるととも
に、社内の利害関係者の十分な合意を得ておかなければなりません。
情報システム取引の勘
所設計・開発・移行(1)
8
挿 入
 開発・設計・構築の重要ポイント
 一旦、設計・開発業務がスタートすると、仕様変更や新たな要望追加はコス
トや納期に多大な影響を与え、トラブル発生の原因になります。
■要件定義の合意不足
×検収段階で「こんなつもりではなかった」、「使い勝手が悪い」などのクレームが出た
○要件定義は、ユーザとベンダだけでなく、ユーザの利用者全員の合意が重要です。
■要件抽出の不足
×設計のために詳細な打ち合わせを実施したら、大幅な変更と新たな要望が追加された
○要件の変更、追加については、事前に費用、納期の見直しを定めておくことが重要です。
■記述レベルのばらつき
×一般的な作業量で見積もったが、実際の作業量は格段に多くコストが増大した
○要件定義の内容をユーザ、ベンダ双方でしっかりと確認することが重要です。
情報システム取引の勘
所設計・開発・移行(2)
9
挿 入
 トラブルを未然に防ぐ
 設計・開発以降のトラブルの原因の大半は、作業着手前に解決できる
ことといっても過言ではないでしょう。しかし、一旦、契約を交わしてしま
うとベンダにはシステムを完成させる責任が発生します。
 RFP（Request For Proposal：提案依頼書、見積依頼書）を入手した
ら、疑問点や不明な点をとりまとめ、ユーザに疑義解消を求めます。要
件定義が曖昧だったり、不正確と思われる場合は、ユーザにその旨を
報告し、要件定義を行ったベンダを交えて打ち合わせを行い、疑義解消
に努める必要があります。
 ユーザは上流工程を担当したベンダの協力を得て、設計・開発・構築を
担当するベンダにRFPを説明する責任があります。
 RFPの提示から見積・提案書提出の期間が短い場合、ベンダ側の検討
が不十分なまま見切り発車的に見積が提出される可能性があります。
予算執行やプロジェクトゴールの都合を優先するなどのしわ寄せは、後
工程の信頼性に大きく影響を及ぼします。
情報システム取引の勘
所設計・開発・移行(3)
10
挿 入
 ユーザの責任
 要件定義書の決定者はユーザであることから、要件定義に疑義がある
場合は、要件定義を担当したベンダとともにその解消に努めなければ
なりません。
 万一、要件の変更を行なう場合は必要最小限に止めるとともに、再見
積に伴う費用の追加や、納期の延長を受入れなければなりません。
 未決事項がある場合は、その費用、納期の取扱いについて、ベンダと
事前に十分な合意をする必要があります。
 不明な点や、判らない用語をそのままにせず、納得のいく説明を求める
とともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プ
ロジェクトの進行に努めなければなりません。
情報システム取引の勘
所設計・開発・移行(4)
11
挿 入
 ユーザの責任
 要件定義書の決定者はユーザであることから、要件定義に疑義がある
場合は、要件定義を担当したベンダとともにその解消に努めなければ
なりません。
 万一、要件の変更を行なう場合は必要最小限に止めるとともに、再見
積に伴う費用の追加や、納期の延長を受入れなければなりません。
 未決事項がある場合は、その費用、納期の取扱いについて、ベンダと
事前に十分な合意をする必要があります。
 不明な点や、判らない用語をそのままにせず、納得のいく説明を求める
とともに、決定事項、未決事項などをまとめた議事録を点検、承認し、プ
ロジェクトの進行に努めなければなりません。
パッケージ利用 追補版では、パッケージソフトを利用して、業務システムを導12
における
入する場合起こりうる現実の問題への必要な対応を示して
挿 入
トラブル要因 おります。
パッケージ利用における主たるトラブル要因
不十分なRFP（提案要求書）
過大なモデファイ・アドオン
パッケージソフトの機能・サービスレベルの不足
開発途上の仕様外の要求
検収時点での要求不一致
「重要事項説明書活用型」
モデル取引・契約書＜追補版＞
（平成20年4月公表）
既存・追加ソフトウェアとの不整合
優越的地位の利用
知的財産の帰属
開発中止時の精算
パッケージソフト間のインタフェースに起因する問題
システム内における障害が切り分けられない問題
パッケージソフトのバージョンアップに起因する問題
パッケージソフトのサポート期間切れの問題
 ユーザ・ベンダ間における
役割・責任分担の明確化
合意プロセス
追補版の
ポイント
追補版では、パッケージソフトを利用して、業務システムを導 13
入するケースにおける。ユーザ・ベンダ間の役割・責任分担
挿 入
の明確化および合意プロセスがポイントとなります。
契約のポイント
ポイント
 協働
 連絡協議会
 再委託
 パッケージ選定における善管注意義務
 瑕疵担保
概要
・ユーザのベンダ丸投げの防止
⇒システムの内容確定はユーザ権限・責任
⇒ユーザ・ベンダの役割責任の明確化
・口頭での変更を防止
⇒変更規定、議事録、承認プロセスを義務化
・ベンダの原則自由
⇒ユーザ要求が基づき、再委託先を開示
⇒情報漏洩については、秘密保持契約にて対応
⇒品質については、瑕疵担保にて対応
・ベンダに業界における一般的に要求される善管注
意義務を課す
⇒パッケージの選定＝仕様、制限事項の決定
開発、運用、保守全般に重要な影響を与える事
を明確化
・帰責事由のある場合に限定
⇒逸失利益や間接損害は負わず、現実に被った
損害に限定
⇒損害賠償額は個別契約ごとに上限を設定
⇒仕様書、マニュアルとプログラムの不一致を瑕
疵と認定
⇒ユーザの資料が誤っていた場合は瑕疵とはなら
ないが、ベンダが不適切と知りつつ指摘しない
場合は、担保責任を免れない。
追補版の
ポイント
追補版では、パッケージソフトを利用して、業務システムを導 14
入するケースにおける。ユーザ・ベンダ間の役割・責任分担
挿 入
の明確化および合意プロセスがポイントとなります。
契約のポイント
ポイント
 ベンダの善管注意義務
 著作権
 知財侵害
 保守
概要
・業界一般的に要求される専門知識・ノウハウに基
づく注意義務を課す
⇒準委任契約ではベンダの専門家の責任を規定
⇒ユーザ・ベンダの役割責任の明確化
・ベンダに帰属
⇒プログラムの再利用による生産性向上、パッ
ケージ利用によるコスト削減、普及に資する
⇒プログラムにおける営業上の機密は秘密保持
契約で保護
・ユーザが申し立てする際は、ベンダに対応指揮権
を委ねる
⇒使用不可能となった場合は、交換・変更・権利取
得
⇒ユーザ指示やハード等に起因する場合は免責
・保守範囲を限定（明確化）し、ベンダは老朽装置等
の交換請求権を持つ
⇒ベンダは原則不良、不具合の修正（是正保守）
のみ対応（環境適応・性能改善・潜在的不具合
対応は範囲外）
⇒遠隔地サポートの規定
⇒メーカからの製造打切り、代替部品提供打切り、
老朽化装置の場合、ベンダはユーザに対して対
象製品の交換請求権を規定
追補版の
ポイント
追補版では、パッケージソフトを利用して、業務システムを導 15
入するケースにおける。ユーザ・ベンダ間の役割・責任分担
挿 入
の明確化および合意プロセスがポイントとなります。
契約のポイント
ポイント
 保守
 共通フレームの準拠
「共通フレーム2007」
編者: 独立行政法人 情報処理推進機構
ソフトウェア・エンジニアリング・センター
発行所: オーム社
概要
⇒ソフトウェアサポート中止の際の保守契約見直し
を規定
⇒交換部品の所有権のベンダ移転
⇒設置場所整備はユーザ責任
⇒不具合調査で調査ベンダ以外のシステムが起因
する場合は、ユーザが調査費用を負担する
・システム開発作業の役割を「プロセス」としてまとめ、
定義・標準化したものです。
⇒ユーザとベンダの用語の取違や、前提とする業務
内容の思い違いを防ぎ、要件定義、開発、保守、
運用、契約等において何がなされるべきかが詳述
⇒追補版において、各取引プロセスは「共通フレー
ム2007」を準用、ユーザとベンダ間でそれぞれの
役割や目的について共有・確認する際、共通フ
レームを参照することによって、より深い認識の統
一をはかることが可能です。
16
契約の種類
挿 入
 契約類型
 民法では、13種類の契約が規定されており、これらは、典型契約と呼ばれて
います。
 典型契約以外の契約でも、自由に定めることができます（契約自由の原則）。
たとえば、ソフトウェアの使用許諾契約などがあります。
 情報システム取引でよく用いられる典型契約には、売買、請負、準委任など
があります。
分類
民法が定めた典型契約
財産を移転する
贈与
交換
売買
財産を利用する
消費貸借
使用貸借
賃貸借
労務を提供する
雇用
請負
（準）委任
その他の契約
組合
終身定期金
和解
寄託
17
契約の種類
挿 入
 取引で利用される契約
 情報システム取引でよく使われる契約は、売買、請負、準委任、ソフト
ウェア使用許諾の4種類です。
契約
関係する法律
利用される状況
売買契約
民法、商法
ハードウェア、消耗品の販売
請負契約
民法
プログラムの設計・制作
準委任契約
民法
コンサルティングなど
ソフトウェア使用許諾契約
著作権法
ソフトウェアの使用、複写など
売買契約の特徴
構築業務などの際に行われる機器
の販売などが売買契約に当ります。
18
挿 入
 契約の目的
 ハードウェアや消耗品を売買する際に適用する契約です。ベンダは商品を引き渡
しと、ユーザは代金を支払うことを約束します。
 ベンダは、正しく動作するものを引き渡す義務があります。
 債務不履行
 ベンダは、期日までに納品を行わない場合などは、債務不履行として損害賠償請
求を受けたり、さらに契約が解除されたりすることがあります。
 瑕疵担保責任
 「カタログや仕様書に書いてある機能が存在しない」ことなどが瑕疵に当たり、ベン
ダは瑕疵担保責任を負います。
 企業同士の取引において、ユーザが引渡しを受けたときは、すぐに瑕疵がないか
を検査しなければなりません。
 引渡後にユーザが瑕疵を発見した場合、ユーザから損害賠償を請求されたり、契
約を解除されたりすることがあります。企業同士の取引では、瑕疵担保期間を引き
渡し後６ヶ月とする特約のある場合が多く、この場合、引渡後６か月間は、ユーザ
から瑕疵を理由に損害賠償を請求されることがあります。
請負契約の
特徴①
重要事項説明書のEソフトウェア設計・制作業務契
約及びF構築契約が請負契約に当ります。
19
挿 入
 契約の目的
 一方が仕事を完成させることを請負い、その相手方が完成した仕事に
対して報酬を支払う際に適用します。請負契約の対象となる仕事として
は、プログラムの設計・制作、Networkの構築などがあります。
 完成が目的ですので、情報システム取引では、何をもって完成とするか
を明確にするため、詳細な仕様書、設計図、指図書などが必要となりま
す。
あいまいな仕様書、設計図では、正しい
完成状態が分かりません。正確、緻密な
文書による合意が必要になります。
請負契約の
特徴②
20
挿 入
 代金支払債務の発生時期
 代金の支払債務は、仕事が完成した後でないと発生しません。
 債務不履行
 ベンダは、期日までに仕事を完成させない場合などは、債務不履行とし
て、損害賠償請求を受けたり、さらに契約を解除されたりすることがあり
ます。
 瑕疵担保責任
 仕事の目的物に瑕疵がある場合、ベンダは瑕疵を直すなどの対応をし
なければなりません。
 瑕疵が、ユーザの提供した資料等又はユーザの与えた指示によって生
じたときは瑕疵担保責任は問われません。しかし、ユーザの資料や指
示が不適当であることを知りながら、ベンダがそのことを告げなかったと
きはこの限りではありません。
 また、瑕疵が見つかった場合、ベンダは、瑕疵担保責任としてユーザか
ら損害賠償を請求されたり、契約を解除されたりすることがあります。
準委任契約の
特徴①
21
重要事項説明書のA、B、C、D、G、H、I、J、K
が準委任契約に当ります。
挿 入
 契約の目的
 事務処理を目的とする契約です。請負と異なり仕事の完成を目的として
いません。
 コンサルティング業務などで、ベンダがアイディアや知識を提供し、ユー
ザと共同して仕様書を策定する契約などが準委任に当たります。
 保守契約や運用支援業務なども仕事の完成義務がないことから、準委
任契約と位置付けられます。
請負は仕事を完成させることが契約の
目的ですが、準委任は委託された事務
を適切に処理することが目的です。
準委任契約の
特徴②
22
挿 入
 特徴
 ベンダは、善良な管理者の注意をもって、委任事務を処理する義務（善管




注意義務）を負います。この善管注意義務は、社会一般の取引上要求さ
れる程度の注意を払っているかという基準で判断されます。
善管注意義務違反があった場合、ベンダは、ユーザから品質不良等に
よって生じた損害につき賠償請求を受けることがあります。
ベンダは、ユーザから請求があったときと、仕事が終わったときには、処
理の状況をユーザに報告する義務があります。
ベンダが業務で受け取った物や金銭、得た権利などは、ユーザに引き渡
す義務があります。
ユーザの義務としては、費用や契約で定めた報酬の支払義務などがあり
ます。
23
ソフトウェア使用
許諾契約の特徴①
挿 入
 契約の目的
 ソフトウェアに関する権利の売買はせず、ソフトウェアの使用権や複製権
をユーザに与える（許諾する）ことを目的とした契約です。
 ソフトウェアに関する権利は、ソフト会社にあり、ユーザは使用権などの
一部の権利を許諾してもらいます。
 契約は、ソフト会社とユーザが直接結ぶものが一般的です。
ソフト会社
ユーザ
使う権利、複写する権利を許諾します
ユーザ
ソフトウェア使用
許諾契約の特徴②
24
挿 入
 特徴
 ソフトウェア会社の考え方によって、ユーザに与える権利が異なるので、
注意が必要です。
 多くのソフトウェアが、ソフトウェアの変更、リバースエンジニアリング（解
読）を禁止しています。
 また、許可無く第三者にソフトウェアの権利を販売したり、無償でソフトを
配布することなどを禁止しています。
 多くのソフトウェアが、著作者は一切の責任を負わないとしており、ソフト
ウェアの使用によって生じた損害は賠償せず、また、不具合があったとし
ても損害を賠償しない（修正を保証しない）としています。
 不具合の修正は、ソフトウェア会社とユーザとの間で別途、保守契約を結
ぶなどの措置が必要な場合もあります。
システム開発
モデル契約
モデル取引・契約書では、どのようにして契
約が成立するのでしょうか。
25
挿 入
 基本契約書と重要事項説明書
 モデル契約書は、基本契約書と重要事項説明書から成り立っています。
 ベンダ・ユーザの作業内容や代金額など契約条件の多くが、重要事項説明書で定
められます。
 基本契約書では、すべてのプロセスに共通する基本事項を定めています。
 契約の締結
 ベンダとユーザがシステム開発契約を締結する場合、基本契約書と重要事項説明




書の両方を作成して、押印する必要があります。
これらのうち、重要事項説明書は、各取引のプロセスの始めに、その 都度作成し
ます。一括受注であっても、プロセスごとに作成します。
重要事項説明書の押印に際しては、内容をベンダがすべて読み上げ、
ユーザの疑問点の解消に努めなければなりません。
ユーザは、重要事項説明書の内容に不明な点がある場合は、ベンダに
説明を求め、十分に納得した上で押印をしなければなりません。
基本契約書の方は、同一ベンダ・ユーザ間では最初のプロセスを
始めるときに１通だけ作成します。
システム
基本契約書
26
挿 入
 何故、基本契約と個別契約に分けたのか？
 契約書が複数になると、手続きが煩雑で面倒に思えます。しかし、すべ




てを一つの契約書にまとめてしまうと、長大になり内容が分かりにくく読
むのも大変になります。
結果として、契約書の中身をよく検討しないで契約を締結してしまい、問
題が発生したときに「そんな事は聞いていない」「契約の時に聞いていな
い」といったトラブルが発生しやすくなります。
契約書を短くすることで、内容が理解され、もめ事が起きても契約書に
定めた通りに解決する事ができるようになります。こうすることで、ユー
ザとベンダの無用な争いや、行き違いを防ぎ、公平で正しい取引を実現
するのです。
それでは、システム基本契約書の内容を学びましょう。
これ以降は、必ずシステム基本契約書、重要事項説明書を
手元で参考しながら進めてください。
パッケージソフトウェア利用
コンピュータシステム構築委託モデル契約
書
（システム基本契約書）
27
挿 入
 パッケージソフトウェア利用コンピュータシステム構築委託モデル
契約書（システム基本契約書）
 大変長い名称ですが、「システム基本契約書」という略称を覚えてください。
 情報システム取引は様々な取引がありますが、すべての取引に共通して
必要とされる条項をとりまとめた契約書です。
 個別契約は「重要事項説明書」という契約書を用い、「システム基本契約
書」と一緒に使用します。片方だけでは、正しく機能しません。
システム基本契約書
重要事項説明書
情報システム取引に共通する部分を取り決め
個別の取引の内容、条件などを取り決め
本契約の構造、契約内容の変更、協働と役割
分担、連絡協議会、ユーザがベンダに提供す
る資料等及びその返還、再委託、秘密情報の
取扱い、個人情報、報告書の著作権、損害賠
償、解除、権利義務譲渡の禁止、協議、合意
管轄
業務分析、パッケージソフト選定、外部設計、
プログラム制作、システム構築、データ移行、
テスト支援、導入教育、保守、運用支援
必ずペアで使用
28
重要事項説明書の
使われ方(総論１)
挿 入
 重要事項説明書（個別契約）
 情報システムの取引に際し、取引のプロセスの各段階で共通する項目が「システム基本契約
書」であるのに対し、取引のプロセス毎に個別に必要となる具体的な取り決め、すなわち個別
契約を「重要事項説明書」と称します。
 「重要事項説明書」は、取引のプロセスの段階に応じて「システム基本契約書」と一緒に使用
します。両者は一体として契約の内容となりますので、片方だけでは、正しく機能しません。
 重要事項説明書の内容は、すべて、ベンダがユーザに読み上げて説明し、契約内容に誤り
や誤解がないことを確認する仕組みになっています。ユーザは重要事項説明書の内容を確
認し、重要事項説明書を受領するとともに、契約条件を承認して押印します。
システム基本契約書
重要事項説明書
情報システム取引に共通する部分を取り決め
個別の取引の内容、条件などを取り決め
本契約の構造、契約内容の変更、協働と役割
分担、連絡協議会、ユーザがベンダに提供す
る資料等及びその返還、再委託、秘密情報の
取扱い、個人情報、報告書の著作権、損害賠
償、解除、権利義務譲渡の禁止、協議、合意
管轄
業務分析、業務要件定義、パッケージソフト
選定、外部設計、プログラム制作、システム
構築、データ移行、テスト支援、導入教育、
保守、運用支援
必ずペアで使用
29
重要事項説明書の
使われ方(総論２)
挿 入
 重要事項説明書の鑑（基本部分）
 いわゆる重要事項説明書の表紙にあたる部分で、複数の個別契約に共通な部分を一つ
の書式に取りまとめています。
 契約するユーザ、ベンダの名称や住所、個別契約の一覧や支払条件などを記入します。
 取引のプロセスの各段階に応じて、 A（要件定義）からK（運用支援）までの個別契約と組
み合わせて使用します。
 重要事項説明書の個別契約部分
 取引のプロセスの各段階に応じて（後述するパッケージカスタマイズモデルでは、３つの
契約段階に分かれます）、受託する業務に該当する個別契約を抜き出し、個別業務ごと
の必要事項と、連絡協議会の実施要項、特約条項、付帯事項、納期、支払方法等を重要
事項説明書の該当する部分に記入します。
重
要
事
項
説
明
書
鑑（基本部分）
個別契約
委託者
受託者
契約の一覧その他本件業務に必
要な事項
添付図書
個別業務内容の記述
連絡協議会の実施要項、未決事項
特約条項、付帯事項、納期、点検期間、
受託金額、支払期限、支払方法、
損害賠償限度額
パッケージソフトウェア利用コンピュータシステム構築委託モデル契約書
（システム基本契約書）
業務全体の流れ
30
ここでは、＜パッケージカスタマイズモデル＞を例に、業務の流れと
利用方法に関するポイントを解説します。
 契約する領域を把握する
 システム開発では、「要件定義」、「設計開発と移行・運用準備」、「保守・運用」の3つの
フェーズに分けることができます。ユーザはフエーズ毎に分割してベンダに委託する事が出
来ますが、委託したベンダに対して、前後の業務との関係をしっかりと把握するように要求
しましょう。
 下の図のように、上流の工程はそれ以降の工程に重大な影響を及ぼすことから、ユーザは
自社の業務をしっかりと把握することが必要です。ベンダは担当する工程での仕様の変更
や、未決事項は必ずそれ以降の工程に引き継がなければなりません。
ⅰ
要件定義
設計開発
ⅱ
ⅲ
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
準委任
D 外部設計支援業務契約
請負
E ソフトウェア設計・制作業務契約F 構築業務契約
移行・運用
準備
準委任
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
31
ⅰ 要件定義を担う
ベンダの役割
差換え
 要件定義におけるユーザの役割は、以下のようにまとめることができます。
 ①事業要件をまとめる
 ②ベンダよりプロジェクト全体に関わる全体の工程の説明を得て理解する
 ③ベンダへ現状の業務を把握、分析できる資料を提示し課題抽出を共に行いＩＴ






ⅰ
化によって実現したいものを明確にする
④プロジェクトゴールを定める
⑤ベンダより業務改革となる合理的な業務フロー、システム化の範囲、パッケー
ジ候補の選定、運用、保守の提案を得て、それぞれの内容を十分に理解する
⑥ベンダより提示されたパッケージ候補の中から、パッケージソフトウェアの選
定をおこなう
⑦設計開発～保守・運用・廃棄までを含んだ、全体の必要投資額（償却額）を
ベンダより得て、費用対効果を検討し、投資額をベンダと合意する
⑧設計開発を担当するベンダの選定方法を協議し、ベンダを選定する
開発以降を担当するべンダの要件定義に対する疑義解消に努める
要件定義
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
Cパッケージソフトウェア選定支援及び要件定義支援業務契約
ⅱ 設計開発、移
行・運用準備にお
ける
ユーザの役割
32
ここでは、設計開発、移行・運用準備フェーズにおけるユーザの義
務・確認・精査・最終判断が含まれる大まかな作業項目について、
ポイントを解説します。
 設計開発、移行・運用準備におけるユーザの  ④仕様の変更がある場合は、変更規程に
基づき設定等変更合意書を得て合意し、
役割は、以下のようにまとめることができま
後工程、マニュアル作成等に支障をきた
す。
さないようにベンダに求める
いての検討経て、問題点、疑義がある場合はベ  ⑤前項の仕様変更等を勘案し、現況に即
したデータ移行、テスト支援、導入教育を
ンダに改訂を求め、要件定義書、RFPを確定す
実施し、文書化及び作業品質についてベ
る
ンダに保証を求める
 ②確定した要件定義書、RFPに基づき、設計開
 ⑥保守・運用実施に必要な文書にてベン
発以降の要求された業務範囲の見積を得る
ダよりとりまとめの報告を受け、整合性を
 ③要件定義書、RFP及び依頼事項に基づき、外
確保し、文書化する
部設計、プログラム作成、構築作業
の確認を行い、文章化及び作業品質についてベ
ンダに保証を求める
 ①ベンダの要件定義書、RFPの実現可能性につ
設計開発
ⅱ
移行・運用
準備
準委任
請負
準委任
D 外部設計支援業務契約
E ソフトウェア設計・制作業務契約F 構築業務契約
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
ⅲ 保守・運用におけ
るユーザの役割
33
ここでは、保守・運用フェーズにおけるユーザの義務・確認・精査・最
終判断が含まれる大まかな作業項目について、ポイントを解説しま
す。
 保守・運用支援におけるユーザの役割は、以下のようにまとめることができ
ます。
 ①保守・運用支援に関連する要件定義書、仕様書等の作成と自社の要求に対
する実現可能性をベンダへ検討依頼し、問題点、疑義がある場合は、ベンダに
改訂を求め、要件定義書、仕様書、SLAについて承認する
 ②確定した要件定義書、仕様書、SLAに基づき、ユーザより要求された業務範
囲の見積をベンダより得る
 ③要件定義書、仕様書、SLAに基づき、ベンダへ保守・運用支援を得て、文書
化及び作業品質について保証を求める
 ④重要なシステムの変更（セキュリティ、バージョンアップ）、サポートの打ち切り
等を決断した場合、業務への影響についてベンダに検討の依頼を行い、ベンダ
と協議を行う、協議の内容については必要に応じて、文書化をベンダに求める
ⅲ
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
34
要件定義は、プロジェクト全体を通して、重要な役割を果たします。ここ
では、特に要件定義段階での注意すべきポイントを解説します。
要件定義における留意点
要件定義の
範囲と契約
 当モデル契約で想定する要件定義を担当するコンサ 35
ルタントにはＩＴコーディネータも含まれますが、当モデ
ル契約が適用できる場合と、できない場合があります。
差換え
 要件定義を担当するコンサルタントの業務範囲
 当モデル契約でのベンダには、要件定義を担当するコンサルタントやＩＴコーディネータが
含まれており、特にモデル契約書(A), (B), (C)の業務は、共通フレームでの企画、要件定
義プロセス、いわゆる上流工程に対応しており、コンサルタントやＩＴコーディネータが、要
件定義業務を支援することを想定しています。
 同一のベンダが要件定義から保守・運用支援までを一貫して受託した場合でも、各契約
ごとに報告書が提出されるものとしています。
 ＩＴコーディネータの留意点
 ＩＴコーディネータは、「ユーザの経営戦略策定プロセス」～「ＩＴ導入後の経営戦略実行プロ
セス」まで幅広くユーザの支援を行うことから、このような一貫した支援業務は、共通フ
レームでの想定外であり当モデル契約では扱っていません。
 このようなケースでは、ＩＴコーディネータは、ＩＴコーディネータ協会が公開している「ＩＴコー
ディネータ業務委任契約書（見本）」を参考にしてください。
 ＩＴコーディネータが、すでにＩＴコーディネータ業務委任契約に基づいて業務受託している
場合、パッケージを前提とした要件定義の策定に関わる場合は、該当業務に当モデル契
約を、別途締結することが相応しいケースも考えられます。
 ＩＴコーディネータが、パッケージを前提とした要件定義の策定のみに関わる場合は、当モ
デル契約を使用すると、当モデル契約を使用する後工程のベンダ契約との親和性が高く
なります。
 ユーザは、パッケージ導入を安易に考えずに、単に 36
パッケージ導入にお
パッケージを導入するだけで事業目的を達成できると
けるユーザの期待
は限らないことを理解する必要があります。
 ユーザの期待




パッケージソフトウェアの持つ機能や業務の流れを利活用する事で、自社の業務改革を実施する機
会としたい。
導入期間とコストを削減することができる。
導入のための専門要員を確保しなくても、システムを導入する事ができる。
導入後、即座にシステムを稼働する事ができる。
 現実の問題（安易な検討によるパッケージ導入が起因する問題点）





パッケージソフトウェア設計意図に反する不足部分（アドオン、外部プログラム）を追加開発した場合、
大幅なパフォーマンスの低下や制限事項の増加を招く場合がある。
要件そぐわないパッケージソフトウェアの導入や無理に不足部分（アドオン、外部プログラム）を追加
開発した場合、膨大な費用が発生するケースがある。
パッケージソフトウェア標準部分は完成しているが、ユーザの目的を達成する業務システムとしての
導入及び開発期間は短いとは限らない。
パッケージソフトウェアに既存システムで実現していた機能を付加する場合、コストの増大や使い勝手
の劣化を招いたり、また既存システムとのデータ連携を行った場合、既存システム側の改造が必要と
なり、追加費用が発生するケースもある。
パッケージソフトウェアに不足部分（アドオン、外部プログラム）を追加開発した場合、バージョンアップ
が困難になる場合や不具合回収などの保守サポートが受けられない、または割高になるなどのケー
スもある。
要件定義における
ユーザの成熟度
 ユーザは自社の経営の成熟度、ＩＴ化の成熟度にあわ37
せたＩＴ化を行いましょう。過度に高度なシステム導入は
企業の信頼性を損ない、経済的な損失を招きます。
 成熟度とは
 ＩＴ導入の検討に当たって、ユーザは自社の「ＩＴ経営化の成熟度」をベンダの支
援を得て、判断する必要があります。
 ＩＴ経営化の成熟度は、ＩＴ導入が担当部署の効率化の道具としてしか活かされ
ていないレベル1から、企業間取引の戦略レベルまで活用できているレベル4ま
で、経済産業省が策定した4段階モデルがあります。
 コンサルタント利用における留意点
 企業の成熟度レベルが不明な場合は、コンサルタントに経済産業省の「ユーザ
ＩＴ成熟度チェックリスト」などを活用して、自社の状況の診断支援をしてもらい、
ユーザ自身が現状のレベルを正しく認識する必要があります。
 そのうえで、到達可能なあるべき姿の成熟度の目標設定の支援をコンサルタン
トに求めるようにしましょう。
 ユーザ経営層は自社の担当者の思い込みや、コンサルタントの思い込みで、ＩＴ
化進めようとすることは極めて危険ですので、十分に留意をしましょう。
 ユーザが中小企業の場合、経営者の考えをコンサルタントに伝え、コンサルタ
ントの認識度合いを十分に確認し、全社一丸となって事業改革を成し遂げるた
めの支援（コンサルタントの経験を含め）を得ることがことが重要です。
38
要件定義における
が脅かされることにもなりかねません。専門家であるベ
セキュリティ要件の決定ンダの意見を基に十分に検討することを心がけましょう。
 ユーザにとってセキュリティ対策を怠ると事業の継続
 セキュリティ要件
 ユーザは業務システムの初期提案内容に、セキュリティ対策が含まれているこ
とを確認する必要があります。実際に対策を行うセキュリティ要件は、ユーザの
システムやポリシー、予算額によって大きく異なります。また、ユーザの多くは、
予算を抑えるためにセキュリティ対策を削減することを考えがちです。しかしな
がら、セキュリティ対策は安易に削減して良いものではなく、セキュリティチェック
シートを活用し、何の対策をどの程度行うのかをベンダ（コンサル）より十分に説
明を受け、納得の上、 必ず重要事項説明書に承認を行う必要があります。
 セキュリティチェックシートの活用
 セキュリティチェックシートは、セキュリティ対策の概念を記載しています。そこで、
担当するベンダが提供可能な製品・サービスをマッピングしてもらい、ユーザ自
身が示した要求レベルに応じたセキュリティ要件の説明・提案を得て、専門家で
あるベンダと十分に検討することが重要です。
要件定義における
 上流工程である要件定義プロセスにおいて、シ
移行・運用準備に対す
ステム構築後のプロセスについても留意してお
る
く必要があります。
留意点

39
システム設計開発後の留意点（移行、運用準備等）





既設システムからのデータ移行は、システム開発業務において最も難しいとさ
れている業務です。データの連続性を確保した上で、業務停止を最小限にとど
め、新しいシステムを滞りなく稼働させなくてはなりません。
移行要件として、データの種類（マスタ、トランザクション等）、データの範囲（期
間等）、変換が必要な場合の処理と仕様、データの移行、データの精査、稼働
の確認及びバックアップ、業務停止、業務手順の変更等について、詳細な検討
が要件定義段階で必要です。
テスト支援業務は、ユーザデータを使用し、本番環境でのテストが信頼性確保
には欠かせません。データの精度や合否はユーザでないと判断できない場合
が多いことから、ユーザとベンダの役割を明確にした上で、要件定義でその仕
様、手順等を定めておけば、実稼働後のトラブル防止に寄与します。
一般にユーザは、設計開発以降は黙っていても完成度の高いシステムが納品
されると考えがちです。ユーザの関与が信頼性向上のポイントであることの理
解を得て、データ移行要件、テスト要件を定めておきます。
導入教育は、実際の操作担当者の、IT知識、実務経験、知識レベルを十分に
把握した上で、要件として定めておくべきです。
要件定義における
保守・運用に対する
留意点

 上流工程である要件定義プロセスにおいて、後工 40
程であるシステム構築後の保守・運用プロセスにつ
いて重要な事であり、十分な理解が必要です。
システム構築後の留意点（運用・保守等）





ユーザ企業におけるＩＴの安定稼働、信頼性の確保は、事業継続性にも大きく関わり、特
に運用に携わる要員のリテラシの確保のための教育やベンダの提供する保守及び運用
支援体制の重要性は論をまちません。
ところが、情報システム構築においては、業務のシステム化や高度化に関心が集中し、
運用や保守に関する仕様検討が十分になされず、あるいは構築費用の確保を優先する
ことから検討自体を先送りをすることが多く、これらに起因した業務と運用・保守の不一
致や障害解消を困難とする原因となり信頼性を大きく損なっています。
本来、情報システムは一定期間、安定稼働することによって企業の業績に寄与するもの
であって、運用と保守・運用支援体制が要件として確立されなければならないものであ
る。ユーザとしては要員教育、保守、運用支援といったシステム構築後のプロセスに対
する要件の定義は非常に重要なものです。
例えば、データの復旧について、直前のトランザクションまで復旧するのか、前日のデー
タまでの復旧でよいのかによって、システムの構成や可用性に関する考え方は大きく異
なります。
さらに、保守、運用支援については、ハードウェア、OS、ミドルウェア等の構成要素別に
保守契約を締結するのではなく、一次的なサポートの窓口が設定されることを前提に、
障害の切り分けや問題のエスカレーションがなされることに関する確認が必要です。
ユーザ自身が障害切り分けを行なうことができないことから、一次的な窓口は、ソフト
ウェア設計・制作業務及び構築・設定業務を行ったベンダ、またはその再委託先とし、下
流工程からの一貫性を維持することで、信頼性、安定性を確保する必要があります。
要件定義の
契約の留意点
 ユーザとして認識しておかなければいけないこととし41
て、要件定義業務におけるコンサルタントの法的な
裏づけは「準委任」契約です。
 契約
 要件定義におけるコンサルタントに委託する業務は、ものの完成を確約する「請
負」契約ではありません。ものの完成責任はユーザ側にあります。コンサルタン
トはベンダのものの完成に関して「支援」を行うものです。
 従って対価は、完成した成果物に対して支払われるべきものではなく、支援する
業務の内容（範囲、専門性、複雑性、規模、期間など）等のサービスに対して支
払うべきものです。 ↑↓従っての意味がつながるように順番を変更しました
 ユーザ業務の調査、分析、提案活動なども、支援の一形態であり、コンサルタン
トには専門家として善良なる注意をもって、契約に定められた期限の中で契約
に基づいた業務を遂行する義務を負います。
 ユーザ、ベンダ共通認識として用語の留意
 「開発」「作成」「成果物」「納期」といった言葉は、一般的に請負契約の業務での、
ものの完成を請け負ったとき使われるものです。
 準委任契約はユーザ支援が業務ですから、成果物や開発されたものはありま
せん。ユーザの求めに応じ、もしくは作業終了時には、ユーザ支援の「作業報告
書」を「提出」し、ユーザから作業報告に書かれた業務が適正かどうかの検収を
ユーザは行う必要があります。
42
モデル契約を利用する上での法律的な責任や注意点を解説します。
モデル契約利用のポイント
モデル契約
利用のポイント(1)
43
 モデル契約の目的
 ITベンダーへの丸投げや口頭合意によるあいまいさ（気が変わった、聞いていない、
やっぱりあれもこれも….）を排除するため、ユーザとベンダの責任範囲を明確にし、
健全かつ安全に情報システムの安定利用を促進することが目的です。
 パッケージソフトウェアの利用が未定の場合
 業務システムの導入を検討する際、パッケージソフトウェアを利用するか、オリジナ
ルのシステムを新規開発するのか未定の場合があります。このような場合、パッ
ケージソフトウェアの利用が決定した段階以降で、モデル取引・契約書追補版の活
用が可能となります。
 契約書・サンプルドキュメントの変更について
 モデル取引・契約書によって提供する契約書やドキュメントは、あくまでも「案」です
ので、取引の実情に合わせ、部分的に変更することは可能です。ただし、契約書全
体の整合性を確保するため、法律の専門家の助言を必ず得るようにして下さい。
 また、一方の当事者だけに都合のいいように書き換えることを推奨するものではあ
りません。 ユーザとベンダの協働によるシステム構築がスムーズに実施されるよう
に、双方の認識の違いによるトラブルを防止することを十分に理解した上で活用し
てください。
モデル契約
利用のポイント(2)
44
削 除
 損害賠償について
 ユーザ、ベンダともに相手方が契約上の約束を守らず、そのため損害を被った場合
に、損害賠償を請求できます。ただし、重要事項説明書で、賠償の範囲、賠償金額
の上限、請求できる期間を定めることができます。上限金額や請求期間を定めない
ことも可能です。ユーザとベンダは相互に利害の対立するところなので、慎重な検
討が必要です。
 損害賠償の上限金額
 複数の個別契約を締結した場合には、次の考え方のいずれかを選択する必要があ
ります。取り決めは、すべての個別契約の特約条項に記載しなければなりません。
①上限合算型：損害賠償金額の上限は、ユーザ、ベンダが締結したすべての個別
契約（重要事項説明書）の上限金額を合算したものとします
②上限個別型：損害賠償金額の上限は、個別契約（重要事項説明書）ごとに独立し
て定め、他の個別契約の上限金額と合算をしたり、他の個別契約と一体の責任と
みなしません
③特定合算型：損害賠償金額の上限は、ユーザ、ベンダが締結した、XX契約とYY
契約の上限金額を合算したものとしますが、ZZ契約は独立して定め、他の個別契
約の上限金額と合算をしたり、他の個別契約と一体の責任とみなしません。
モデル契約
利用のポイント(3)
45
 準委任契約においてベンダが負う責任
 準委任契約では、ベンダは専門家としての善管注意義務を負っています。<モデル契約：
追補版>ではこの善管注意義務を「情報処理技術に関する業界の一般的な専門知識及
びノウハウに基づき、ユーザの作業が円滑かつ適切に行われるよう支援業務を行う」と
具体的に定めています。
 債務不履行は契約違反であり、ユーザは損害賠償をベンダに請求することができます。
 上流工程を担当するベンダが負う善管注意義務
 要件定義が不足している、矛盾している、記述が曖昧、処理の細分化にムラ等による結
果として要件不足となり、設計・開発工程・移行を担うベンダから「業界の一般的な専門
知識に基づいておらず、実現が不可能であったり疑義が多数ある」という指摘がなされた
場合、上流工程を担当したベンダは善管注意義務を果たしていなかった（債務不履行）可
能性が高いといえます。
 パッケージソフトウェア選定支援業務で、業務要件を満たせない、カスタマイズが実現で
きない等のパッケージソフトが選定された場合、ベンダの善管注意義務違反（債務不履
行）となる可能性が高いといえます。 適合するパッケージソフトがなかったり、予算を大幅
に超えてしまうなどの場合は、「該当するパッケージがない」ことを報告しなければなりま
せん。
 但し，ベンダに善管注意義務違反の責任を負わせるためには，前提として，ユーザにお
いても，ベンダに対し必要な情報提供等をしておく必要があることにご留意下さい。
モデル契約
利用のポイント(4)
46
 請負契約においてベンダが負う責任について
 請負契約では、ベンダは重要事項説明書で指定された要件定義書、仕様書に
基づきプログラム、マニュアルなどの成果物を完成させ、もしくは、設定作業な
どを完了させて、納期までにユーザに納める義務があります。ユーザは、ベンダ
から、納期までに成果物を納めたり作業が完了できないとの連絡を受けた場合、
その原因と責任の所在を確認すると共に、必要な場合、ベンダと協議を行い、
納期の変更等を改めて定めることとなります。
 一般に請負契約では、納期までに仕様通りの成果物を完成させれば、作業の
進め方や再委託などは請負側の自由な裁量で行えるとされています。しかし、
情報システム構築は、ユーザとベンダの協働が基本で、システム基本契約書、
重要事項説明書で定められた、連絡協議会での進捗報告・確認を怠ってはなり
ません。
 ユーザは、請負だからといって、すべてをベンダに丸投げせず、ベンダは勝手
気ままに作業を進めることが無いように、密接な連絡を基本にしなければなりま
せん。
モデル契約
利用のポイント(5)
47
 ベンダのプロジェクトマネジメントについて
 ベンダは専門家の立場で業務をユーザから委託されています。従って、契約した業務の進捗
や成果の達成には責任があります。例え、ユーザがITの知識がなく、必要な資料をまとめるこ
とができない場合は、質問したり、適切なひな形を提供したり、提案をするなどして、業務が合
理的な範囲で進捗するようにユーザを支援しなければなりません。
 もっとも、ユーザの都合で、プロジェクトが遅延する場合はベンダの責任とは言えません。
ユーザに専門知識がない場合であっても、ベンダは工程表やマイルストンを示す等により、適
切なアドバイスや支援を行い、契約で定めた期限内に業務を成功に導くプロジェクトマネジメ
ント義務がありますが、この義務を尽くす責任はベンダが一方的に負うものではなく，ユーザ
においても、ベンダの業務遂行に必要な情報を適宜提供する必要があります。
 プロジェクトの進行を管理する
 契約締結前に、契約で実施される業務全体の流れについて、取引契約モデルの全体像＜別
紙1＞＜別紙2＞を利用してもらうなどして、適宜説明を受けるようにしましょう。 別紙は、業界
の標準的な取引の流れをモデル化したもので、業務の流れや相互の役割を明確にするため
に役立つものです。
 相互に何をやるかが明らかになる
 業務の進捗や達成状況のチェックができる
 未決事項や業務遅延が発生した場合に、後工程への影響などを確認できる
モデル契約
利用のポイント(6)
（パッケージ、SaaS/ASP活用、保守・運用）＜追補版＞
要件定義段階が、2つの契約で構成されています。A契約で業務
要件定義書が提出され、それに基づいて、パッケージの選定
（フィット&ギャップ、カスタマイズの実現性の検討）を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) 業務運用
※ベンダ主体
モデル契約
利用のポイント(7)
（パッケージ、SaaS/ASP活用、保守・運用）＜追補版＞
要件定義段階が、1つの契約で構成されています。業務
要件定義とパッケージ選定を同じ契約で行います。パッ
ケージを比較しながら、要件を固めていくのが特徴です。
別紙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) 業務運用
※ベンダ主体
モデル契約
利用のポイント(8)
50
 契約書以外の合意事項について
 契約内容は、すべてシステム基本契約書及び重要事項説明書に記載
します。また、この契約内容を変更するには、書面を作成して記名押印
するなどの手続が必要であり、変更を口頭やＥメール等で行うことはで
きません。
 ただし、契約内容の解釈上、契約交渉の際の説明やユーザに交付した
資料の内容が、ベンダの契約上の義務であると扱われる場合がありま
す。
 また、営業担当者等が事前に説明した内容とシステム基本契約書や重
要事項説明書に記載された内容が異なる場合には、トラブルを生じか
ねません。
 無用のトラブルを避けるため、交渉等の際に、「契約内容の確定や変更
はすべて権限のある者が書面をもって行う必要がある。」と説明し、また
、ユーザに交付する資料にはそれが契約内容となることはない旨を記
載しておく必要があります。
モデル契約
利用のポイント(9)
51
 損害賠償請求
 作業の完了が納期に遅れた場合や障害が発生した場合、ベンダとユーザが協議しても決着し
なければ、損害賠償が問題とならざるをえません。損害賠償の可否・範囲については、事前の
契約内容が重要になります。
 相手方が契約上の義務を履行しなかった場合や、納品されたソフトウェアに瑕疵があった場
合、それにより損害を被った当事者は、損害賠償を請求することができます。
例① 要件定義段階の支援業務に義務違反のあるケース
要件定義支援を委託されたベンダの業務についての理解不足およびスキル不足から、
重要な部署へのインタビューが行われなかった。その結果、優先順位の高い業務が要
件定義から漏れてしまった。
例② システムに瑕疵があるケース
開発業務を行ったベンダが設計書の記述を見落として、そのまま開発、納品が行われ
た。瑕疵の修正には、データベースの大幅な変更が必要で、新たな追加費用が発生す
ることが判明した。
例③ 設計・開発段階でベンダが負う責任を果たさないケース
外部設計支援業務から参画したベンダは、ユーザの要件定義が不完全であること、
データ運用に問題があることをすぐに気づきながら、これを指摘しなかった。その後、シ
ステムのバックアップが業務停止時間内に終了せずに、ハードウェアの追加調達が必
要で、新たに費用がかかることが判明した。
モデル契約
利用のポイント(10)
52
差替
 ベンダの負う責任
 既述の通り、ベンダは、要件定義フェーズ、移行・運用フェーズでは、要件定義・
パッケージソフト選定の支援、新システムへの移行・運用のために必要な業務
を、委託された者として忠実に行う義務を有しています。
 「請負契約」においては、善管注意義務で規律される「委任契約」と異なり、ベン
ダは仕事の「完成義務」を負っています。ユーザの要望事項の増加は往々にあ
ることですが、「専門家の責務」として、適切にスケジュール管理を行い、納期ま
での完成に努めなければなりません。
 また請負契約においては、納品が済んだ後でも、納品物が通常備えなければ
ならない性質・性能を有していない場合、ベンダは請負人の担保責任として「瑕
疵」の修補や損害賠償を求められることがあります。
 地方裁判所のベンダの責任に関連した判断の例＊
請負契約か委任契約かは、既払い金があればその金員の性質や、工程表の規定振
り、システムの規模などの事情から判断される。請負契約の場合、ベンダは成果物
の完成義務を負う
 機能に軽微でない支障が生じ、遅滞無く補修がされないと、そのシステムには「瑕
疵」があることになる
 ベンダは、ユーザの要望増加やデータの運用方法の仕様未定といったプロジェクト
の阻害要因を認識した場合、これを指摘して改善を求める注意義務を有する

＊ 裁判は個別の事件ごとに判断が下されますので、似た事実関係ならば常にまったく同じ結論が出るというわけではありません
モデル契約
利用のポイント(11-1)
53
差替
 損害賠償額の上限
 システム開発の特殊性として、情報システムは、企業の基幹業務に関連するた




め、その瑕疵などに関連して生じる損害は、多額になりうることが挙げられます。
ベンダは、原則として債務不履行や瑕疵と相当因果関係にある損害を賠償する
ことになりますが、これはベンダに過重な負担を課することになります。特に瑕
疵担保責任の場合は、過失の有無にかかわらず多額の損害賠償責任が生じる
ことになります。
また、第三者が上流工程を担当していた場合など、リスクとその範囲を予想す
ることは困難です。
しかし、ベンダが多額の損害賠償リスクを想定して契約金額を算定することにな
れば、その分契約金額が上がる可能性があります。
そこで、合理的なリスク計算のため、賠償金額の上限や範囲、請求期間を予定
することが必要となります。これにより、ベンダは、リスクに萎縮することなく業務
を行うことが出来るようになります。これこそが損害賠償額の上限規定が重要と
される理由です。
モデル契約
利用のポイント(11-2)
54
 損害賠償の予定とは
 損害賠償については、予め重要事項説明書で、
①賠償金額の上限、②賠償の範囲、③請求できる期間を定めることができます。
①の例
「損害額の上限を、委託料250万円とする」（委託契約が解除され、委託料が
支払い済みの場合、この例であれば、委託料の返還に加えて、250万円を上
限とする損害賠償請求がされうる）
②の例
「損害賠償責任の範囲は、直接の結果としてユーザが現実に被った通常の損
害に限定する」
③の例
「ユーザがベンダに対して損害賠償請求を行うことの出来る期間は、業務完
了確認書兼検収確認書をベンダに交付してから、1年以内とする」
モデル契約
利用のポイント(11-3)
55
 損害賠償の上限金額の算定方式
 システム開発を進める段階毎に、複数の個別契約を締結する場合に上限金額を定めると
きは、以下の損害賠償の算定方式を参考に、いずれかを選択しなければなりません。こ
の選択は、ユーザと合意し、全ての個別契約で特約条項として記載しなければなりません。
 3種類の算定方式
① 全部合算型： １個の基本契約に対応するすべての個別契約（重要事項説明書）に基づく損害賠償金額
の合計は、それらの個別契約に定める上限金額を合算したものを上限とする方式。
同一のベンダが複数の工程を受託する場合は、個別契約を締結するごとに上限額が加算されることに
なります。しかし、別のベンダが個別契約を締結しても上限額は変わりません。
② 一部合算型： 当事者が指定した複数の個別契約（重要事項説明書）に基づく損害賠償金額の合計は、
それらの個別契約に定める上限金額を合算したものを上限とする方式（指定されていない個別契約の
上限金額は合算に含めない。）
③ 独立型： 損害賠償金額の上限は、複数の個別契約（重要事項説明書）の上限金額を合算することなく、
個別契約ごとに独立して定める方式
 合算型と独立型の違い
 例えば、要件定義に問題はないが、設計段階で致命的なミスがあり、その後の開発で
まったく業務に使えないシステムができた場合、独立型ではユーザは使えないシステムの
ため投資した金額のうち、設計段階の契約の上限金額のみしか請求できなくなります。こ
れに比べて全部・一部合算型の算定方式の方が、同じベンダが上流部分を担当している
場合、ユーザにとって有利となります。
56
契約書記載、締結にあたっての注意点を解説します。
システム基本契約書、
重要事項説明書の注意事項
基本契約書の
注意事項
57
 再委託について
 再委託先の開示
ベンダはユーザから委託された業務を、契約で特に禁止していない限り、他の
ベンダに再委託することができます。しかし、ベンダはユーザから請求があった
場合は、再委託するベンダの住所、会社名等を開示しなければなりません。
 再委託の中止
ユーザは、再委託先が競合状態であったり、セキュリティが不完全であるなどの
正当な理由がある場合は、理由を書面にしてベンダに通知すれば、ベンダに再
委託を中止させることができます。
 作業の開始後に再委託の中止があった場合
作業が再委託先で進んでいるにも関わらず、ユーザの請求で再委託が中止と
なった場合は、受託金額、作業期間、納期などの変更があり得ます。この場合
には、契約変更手続（システム基本契約書第2条⑥）にそって、契約条件の変更
の協議を行い、ユーザ及びベンダは、合理的な範囲での変更合意を行う義務が
あります。
重要事項説明書の
注意事項(1)
58
 契約ごとに作成し説明する
 要件定義から保守・運用までのすべてのプロセスの流れに沿って、業務契約を締
結する時々に利用されるものです。一度に、すべての項目を記載して１回で説明を
行い契約するというものではありません。個別契約ごとに説明が実施され、ユーザ、
ベンダともに業務の内容を詳しく確認した上で契約するということに注意して下さい。
 一方で、例えば外部設計からソフトウェア設計、構築、データ移行、テスト支援、導
入教育と一貫して同一のベンダに業務を発注する場合は、将来、締結するであろう
個別契約に「予約」と記入しておきます。当然ですが、未定の内容は未定と記入し
ておきます。
 「予約」とした個別契約は、そのままでは効力は発揮しませんが、①事前にユーザ
において業務内容の説明を受け流れを理解するのに資する、②未決事項や業務
の途中で仕様変更が発生した場合に、後工程にどのような影響がでるのかについ
て説明を受けることができる、③変更が発生した場合に、都度、納期や費用の見直
しができる、といったメリットがあります。
 上流工程から保守・運用まで一括で同一のベンダに発注する場合
 初期段階では、内容部分が空白となることが通常です。作業の段階に従い、順を
追って決定事項が明記されていき、都度確認していくものであることをユーザは認
識しておく必要があります。
重要事項説明書の
注意事項(2)
59
差替
 連絡協議会
 連絡協議会の実施要項では、会議体の主宰者、議長、議事録作成などの役割のほ
か、日程や場所についてもできる限り具体的に記載しておく必要があります。
 未決事項、付帯事項、特約条項
 未決事項については、該当の重要事項説明を受ける時点で決まっていないが業務
終了までに決めるべき事項について記載をします。
 付帯事項については、作業項目として記載できなかった他の決め事を記載します。
 特約条項には、当事者間での約束事について記載します。付帯事項とは異なり、契
約事項や賠償について記載が必要な場合に使用します。
 受託金額
 受託金額及びその決定基準には、当該フェーズの受託金額を記載します。ただし、
金額が確定しない場合は、何が確定したら受託金額を決定できるのかを明記して
おく必要があります。
 損害賠償
 損害賠償については、その上限金額を定めることができます。この場合、上限金額だけでな
く、その算定方式（全部合算型、一部合算型、独立型等）も記載しておく必要があります。
60
具体的な例に沿って各契約締結にあたっての注意点を解説します。
モデルケースを利用した
各契約段階での役割と責任
要件定義の
業務の流れと責任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
61
 要件定義業務の重大性
 要件定義は、後工程を担当するベンダの見積根拠となります。要件定義を担当
するベンダは、ユーザの求めに応じて、後工程を担うベンダに説明を行う責任
があり、要件定義の疑義解消に努めなければなりません。
 ユーザは、要件定義の重要性、後工程への影響度を確実に理解するとともに、
要件定義書、RFP等の内容をユーザ、ベンダで十分に精査し、要件の漏れや
未決事項の先送りがないように、ベンダに要求する必要があります。
ⅰ
要件定義
設計開発
ⅱ
ⅲ
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
準委任
D 外部設計支援業務契約
請負
E ソフトウェア設計・制作業務契約F 構築業務契約
移行・運用
準備
準委任
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
モデルケースＡ社
の概要①
62
ここでは、ユーザにモデル契約書（重要事項説明書）の活用
の理解を深めてもらう為に、現実に即したモデルケースを示
し、ポイントを解説します。
 会社名：A社



業 種 ：和菓子の製造・販売・小売業
規 模 ：年商50億円 従業員150名（内社員50名、パート・アルバイト100名）
事業内容：和菓子を自社工場（２ヶ所）で製造（材料生産協力会社は８社であり、一部製品仕入も有る）、
全国有名百貨店（28店舗）に売場を出店し直接販売を行っている。
また、量販店３社に贈答用和菓子詰合せを卸している。
※次年度より、新規事業として、コンビニ１社（250店舗）へ少量パックの和菓子を１日３回納め
る事と販売エリア外のリピータ獲得の為、通信販売事業として季節商品のインターネット販売
を計画している。
 既存システム内容
生産管理システム：既存ＩＴベンダのオフコンパッケージをカスタマイズして利用している。
販売管理システム：ＩＴの展示会で見つけたオープン系パッケージに、各百貨店からの売上データ取込み
システムや量販店各社からの受発注システム（専用伝票発行含む）および物流シス
テムを個別開発し、販売管理パッケージと相互で処理したデータを活用している。
 財務会計システム：会計事務所より紹介されたパッケージに生産管理および販売管理から必要なデータ
を取り込み管理会計に利用している。
 人事給与システム：市販パッケージシステムをノンモディファイ（パッケージ標準）で利用している。
他システムとのデータ連携等は行っていない。


モデルケースＡ社
の次期システム構
築
概況②
63
 次期システム構築プロジェクト体制
生産管理システム：それぞれの工場に１名、中心となってシステムを運用している担当者（生産管理部
との兼務者）がいる。
 販売管理システム：百貨店事業部２名・量販店営業部１名・物流倉庫１名の運用担当者がいる。
 財務会計システム：経理部に２名運用担当者がいる。
 人事給与システム：人事総務部に１名運用担当者いる。

次期システム構築におけるプロジェクト責任者は社長であり、補佐するのは取締役経理部長（管理部
門責任者）である。両者ともシステム構築の経験はなく、既存ベンダに相談をしたが、提案されたシス
テムが自社に適合
しているかどうかの判断に迷い、既存ベンダ以外の複数ベンダから提案を受
け、良いとこ取り的な判断（価格性能比が良さそうなものを選ぶ）を行えば良いと考えていた。
 既存システムの運用において、従来、電算部門は設置せずに、それぞれの既存ベンダから、それぞれ
の担当者が困った時に、必要と思うサポートを運用支援契約により得て、稼働状態を維持してきたが、
今回の次期システム構築に当たっては、インターネットやオンライン取引が増えることもあり、専任者が
必要と考え、電算部門の新設がおこなわれた。
電算部門には、１名のシステム構築経験者を中途採用し、他１名を管理部門スタッフから異動させ、
２名体制で進めることとなった。
 企業規模から管理部門は全員で８名であり、ＩＴおよび契約法務に精通した担当者は不在である。
 取引先からのＩＴ関連の要請に関しては、取引先から資料を営業部門が受領し、既存ＩＴベンダに検討を
依頼するか、打合せが必要な場合は、ベンダに営業部門が同行することで対応を行っていた。

64
モデルケースＡ社
次期システム全体像
フェーズ Ａ ①
全体システム体系図
モデルケースＡ社
次期販売財務システ
ム
フェーズＡでの概況
65
【目的】このフェーズでは、システム導入を通して実現したい事を明確にします。
システム構築のための基本方針を定め、事業要件定義、業務要件定義
を策定し、パッケージソフトウェアの最終候補を決定します。
 企画（業務の新全体像、業務モデル、システム方式、付帯機能の方針、サービスレベルと品質に対する




方針の策定）
【経営課題】
 次年度より新規に取引を開始するコンビニとの事業に対応できる体制の整備（ＩＴ含む）が必要。
 新ビジネスモデルとして計画しているインターネット通販に対応できる体制の整備（ＩＴ含む）が必要。
 次年度（約８ヶ月後）には、次期システム（販売・財務）を稼働させ事業部門別損益管理を行いたい。
【現状の業務課題】
 百貨店事業の課題：百貨店に納品した商品は預け在庫として管理を行う必要があるが、店頭ロス
や試食品対応等から棚卸差異が大きく、併せて、百貨店からの売上データ
と手元管理している売上数量の差が度々発生し、事業利益を圧迫している。
 量販店事業の課題：量販店からオンラインで送られてくる支払案内データと自社の売上データとの
差異が発生しており、また売上・返品の月ズレも発生し、期間損益管理が正
しく掴めていない事業となっている。
 財務会計の課題：期末最終月の売上の月ズレおよび実棚が正しく把握できないことから、在庫の
評価損の精度に問題が生じており、年度事業損益の正確性が危ぶまれている。
【将来構想】
 第１Ｓｔｅｐ（販売管理と財務会計のレベルアップ）稼働後、生産管理と人事給与の レベルアップに
ついては、別プロジェクトとして検討を行いたい。
【要求品質】
 既存システムよりは新しいシステムなので、処理速度や使い勝手は当然良いものであるはず。
 通販事業等で個人情報を取扱うことは事は理解していたが、セキュリティに関する仕様は示せて
いない。
 電算部門は新設部門で自社のビジネスモデルを整理した経験もなく、業務の全体像が明確に把
握できていない。
モデルケースＡ社
次期販売財務システ
ム
66
【目的】新システムの検討が暗礁に乗り上げたことから、コンサルタントとして
ＩＴコーディネータと支援契約を締結し、システム導入を通して実現したい
事を明確にして、大まかな全体けいさくの策定と経営課題および業務課
題の整理および改善（案）の策定およびパッケージソフトウェアの最終候
補の決定を行うこととした。
フェーズＡコンサル支援内容
①
 企画におけるコンサル（ベンダ）の支援業務の内容
 ベンダは、ユーザの経営課題や現状業務とその課題などを整理するためにユーザから必要情報の提供を
受けます。例えば、現状の業務で物流コストをどのように削減するか、事業拡張のために新たにコンビニと
の取引開始の計画がある、市場を拡げるために消費者との直接取引を検討している、などです。
 会社概要、事業内容、取引先と取引形態、商品（製品）分類、組織とその機能に関する情報を把握し整理し
た後、インタビューが必要となる経営者・組織（管理者と社員）を検討し、実施計画にまとめユーザの承認を
受けます。
 ベンダはインタビューを通しユーザの経営課題や現状業務とその課題などを整理すると同時に、現行の業
務で使用される定型・非定型の資料収集、現行システムに関する資料収集も行います。現行システムの調
査では、システムで利用されていない部分についてもなぜ利用されていないかを確認することが重要です。
ベンダは以下の点に注意してインタビューを実施します。
 経営者が認識しない経営課題や業務課題もあるので業界動向や競合先、製品の市場動向、法的規制などについても確認す
る必要があります。例えば、取扱商品に関わるネット販売環境は現在どうなっているか、その販売規制は無いか、コンビニで
の販売を予定している商品のポジションはどうなっているか、その場合の競合メーカーはどこか、などです。
 ユーザの常識とベンダの常識は異なることもあるので、必ず具体的な内容を確認する必要があります。例えば、言葉が同じで
も業務内容や計算方法などが異なる場合があるので注意が必要です。またこれらの認識を、後の工程を担当するベンダにも
的確に伝えるようにしなければなりません。
 現行のシステムの重要な部分の仕様を確認する必要があります。例えば、現行システムで個別開発した「専用伝票対応を含
む各百貨店や量販店との受発注システム」や「物流システム」を新たに構築するシステムでも利用しようと考えている場合など
は、現行システムでパッケージ部分とのインタフェースがどのようにとられているかの確認などが必要になります。特にパッケ
ージソフトウェアと蜜結合している場合など、この後選定されるパッケージソフトウェアとの連携が困難であったり、または現行
システムの個別開発部分に変更が必要になったりすることが考えられます。
モデルケースＡ社
次期販売財務システ
ム
67
フェーズＡコンサル支援内容
②
 ユーザの先にある取引先の提示する条件を確認する必要があります。例えば、百貨店やコンビニとの間で行うＥＤＩ等の取引
に関わるルール及び制限やペナルティ、使用する専用伝票、戻入や値引の扱いなど。特に，百貨店との取引では，百貨店に
開設した店舗における一日の売上が百貨店側に入金され，あらかじめ決められた締め日に経費を引いた残額が精算される等
，百貨店側の独自のルールにあわせた業務要件の策定が必要となる場合があります。
 商品（製品）の特性を確認する必要があります。例えば、鮮度管理が必要なもの、季節性のあるもの、売買単位、物流単位、
在庫管理単位、ロスの発生、歩留りなど。
 売上や仕入の計上基準、入金や支払の形態など。
 これまでは直販と卸しかなかった事業に今後はネット通販も検討している場合、ネット通販ではWEBサーバ上の在庫データと
パッケージソフトでの在庫管理との連動が必須となるため，連動のアルゴリズムや制約に関して，ユーザと充分な協議が必要
となります。特に在庫連動ではパッケージソフトウェアでの在庫交信の結果をWEBサーバ上の在庫データにリアルタイムで反
映するのか、あるいはWEBサーバ上には在庫データを持たずにパッケージソフトウェアの在庫情報を参照させることは可能か
、といった部分の確認が重要となります。
 百貨店と量販店しかなかった取引先に今後はコンビニへの展開も検討している場合、多品種少量出荷への対応や一日数回
の出荷など物流機能をはじめとして構築するシステムへの影響も考慮が必要となります。
 中長期計画に基づく事業展開の内容を確認する必要があります。例えば将来、原価管理の精度を上げるために生産管理シス
テムをレベルアップし個別原価計算を行う予定がある場合など、現状不足している必要なデータは何か、それらが必要となる
タイミングはいつでどのように確保する予定かといった点を確認しておく必要があります。
 ベンダは整理された経営課題、業務課題をもとに業務改善提案をまとめ、新しい業務モデル全体像と情報
システム全体像、それに必要な組織や体制、予算などがユーザに理解できるように報告します。また、改善
の優先順位や改善による効果についても具体的に示す必要があります。ベンダは以下の点に注意して報告
を実施します。



一般的に用いるフロー図などの資料は、ユーザが理解しているかの確認を行いながら説明する必要があります。
予算の前提となる開発、運用、保守の方針を具体的に説明する必要があります。
期待効果は、予算との関係で費用対効果を明確にするとともに、このあとのシステム要件を明確にする上でポイントとな
るため、具体的かつ明確にしておく必要があります。
モデルケースＡ社
次期販売財務システ
ム
68
フェーズＡコンサル支援内容
③
 業務要件定義（機能要件、非機能要件、セキュリティを含む）
 ベンダは承認された新しい業務モデル全体像と情報システム全体像をもとに、業務要件定義を行います。
 ベンダはシステム化目的をもとにシステム化範囲や対象を明確にします。
 ベンダは明確になったシステム化範囲についての入出力やその画面遷移を明確にします。例えば、新たに
検討している、コンビニとの取引で必要となる専用伝票や管理帳票、WEB受注で使用する顧客が注文に使
う画面や注文内容の管理帳票など、を具体的に挙げそれらの関連を明確にする必要があります。入出力に
ついては、以下の点に注意します。
 ピーク時にどの程度のトランザクションを処理しなければならないか、またそれに要する処理時間はどの程度か。例えば、新







たにコンビニと取引を開始するようなケースでは、出荷が日に数回あるケースもありトランザクション数が急増します。それによ
りデータの送受信時間、処理時間、出力時間などが影響を受けます。
ネット販売のようなケースでは、対象が不特定のため受注量が予測しにくく、取扱商品などから対象となる市場を仮定し、受注
量を想定しておく必要があります。実際に稼動した後、これらの想定と実際の受注量を検証し、場合によっては構築されたシ
ステムに拡張などの検討が必要になるからです。
システム使用年数とその間に拡大するデータ量、またそれに要する処理時間はどの程度か。取引先件数の伸びや取扱商品（
製品）件数の増加、店舗や工場などの在庫場所の拡大など、管理する対象によっては相乗的にデータが増加する場合があり
ます。
利用タイミングと出力可能なタイミングに相違は無いか。
クリティカルな処理のレスポンスや応答スピードに問題は無いか。例えば、顧客が直接WEBサーバに直接アクセスするネット
通販の画面レスポンスやパッケージソフトウェアで管理している月末の在庫更新時間、出荷指示データの作成時間など。
通常業務に影響させないバックアップ方式、さらに復旧をも考慮したタイムスケジュール。
現行システムとのインタフェースをどのように実現するか、その場合のタイミングや再計算可能な範囲はどこまでか。
インタフェースに人手が入る場合のリスクやミスがあった場合のリトライ方法。
モデルケースＡ社
次期販売管理システ
ム
69
フェーズＡコンサル支援内容
④
 ベンダは以上のような主機能についてセキュリティ要件を明確にします。この場合、セキュリティレベルとセキ
ュリティ対策コストはトレードオフの関係にあるので、業務要件に最適なセキュリティレベルを提案します。特
に、ネット通販などインターネット上で動作するシステムの場合、ハッカー等の攻撃も年々高度化しており、攻
撃パターンとその対策、及びそのコストを明確にし、ユーザが採るべき対策やWEBサーバ上におくデータの
範囲を明確にして、ユーザがリスクを判断できるようにしておく必要があります。
 ベンダは以上のような主機能を提供するためのハードウェア、ソフトウェア、物理的環境や設備、ネットワー
ク環境などを検討します。要件定義を支援するベンダは、この後の開発・構築・運用・保守についても具体的
なプロジェクト体制や社内体制、委託先を検討し提案する必要があります。また、新情報システムの前提とな
るＯＳやＯＡソフトウェアのバージョンを明確にし、現行のものからのバージョンアップが必要な場合は、その
コストも明確にする必要があります。
 パッケージソフトウェア候補選定支援（使用許諾契約、保守性、業務要件に対する機能適合評価）
 ベンダは業務要件の定義に基づき、市場で該当するパッケージソフトウェアを候補として取り上げます。この
場合、一般的にカスタマイズに関わる開発は、パッケージソフトウェアのメーカーもしくはそのメーカーが推奨
するベンダが担当します。これは、これらのベンダ等がパッケージソフトウェアの仕様の詳細を把握している
為です。したがって要件定義を支援するベンダは、これらの候補となるパッケージソフトウェアの開発以降を
担当するベンダからのカスタマイズ部分を含む提案書に基づき、比較表の作成を行います。
 比較表ではパッケージソフトウェアの機能範囲とコスト、カスタマイズ時のソフトウェアの保守性や使用許諾
契約の制限及び著作権、パッケージソフトウェアとカスタマイズ部分の連携の容易さ、無償保守の範囲と有
償保守の費用、セキュリティ機能のレベル、不足機能、ベンダの支援体制などがわかるように報告をまとめ
ユーザに説明します。特に不足機能の影響やセキュリティ機能のリスクについてはユーザに十分に理解して
もらいます。
モデルケースＡ社
次期販売管理システ
ム
フェーズＡユーザ側のポイン
ト①
 企画段階
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。
70
 コンサルより報告された経営課題、業務課題に対する改善（案）提案に対して、それぞれの業務に係る社員
の評価を通して、最終的に経営者（プロジェクトオーナ）が実施の判断を行いましょう。
 ソフトウェアを企画するにあたって、システム化する業務の明確化と業務をＩＴ化する全体像を作成します。
 費用対効果、開発期間・体制、経営の要求との整合性をはかる必要があります。
 多くの要件を盛り込むと膨大な費用と時間がかかりますので、ＩＴ化することにより業務の効率化が進むかを検討して要件の取
捨取得を行いましょう。

業務要件定義段階
 機能要件だけでなく、セキュリティ要件などの直接業務に関わらない要件の定義を行います。操作画面や処
理の流れも想定してベンダーに伝え業務の流れシステムの動きを決めましょう。
 ここで決定した内容がRFP（提案依頼書、見積依頼書）になります。RFPが不十分ですと、設計開発段階で
悪影響が出ますので、要求事項はすべてベンダに伝えましょう。
 業界の特性などが伴う業務について、コンサルが十分に理解をしているかを確認するために説明を求め、不
十分であれば理解に必要な資料やインタビューの機会などを提供するようにしましょう。
 ユーザはベンダに対して、システム及び業務を実現するために必要な、開発、移行、運用、保守、教育など
の方針と個別業務の報告（案）を作成させ、十分な検討を行った上で、承認するようにしましょう。
 ここでは、報告（案）の個別業務とシステム化の方針の整合が取れていることを確認した上で、それぞれの業
務に係る社員に、現実の運用段階において業務に支障をきたさないか等を評価させ、経営者（プロジェクトオ
ーナ）は承認を行うようにしましょう。
 パッケージソフトウェア候補の選定段階
 ベンダが作成したパッケージソフトウェア候補の比較について、十分に理解した上で、総合評価をもとに、自
ら最終的な候補の選択を行わなければならない。
モデルケースＡ社
次期販売管理システ
ム
フェーズＡユーザ側のポイン
ト②
 企画段階
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。
71
青文字部分
挿 入
 コンサルより報告された経営課題、業務課題に対する改善（案）提案に対して、それぞれの業務に係る社員
の評価を通して、最終的に経営者（プロジェクトオーナ）が実施の判断を行いましょう。
 ソフトウェアを企画するにあたって、システム化する業務の明確化と業務をＩＴ化する全体像を作成します。
 費用対効果、開発期間・体制、経営の要求との整合性をはかる必要があります。
 多くの要件を盛り込むと膨大な費用と時間がかかりますので、ＩＴ化することにより業務の効率化が進むかを検討して要件の取
捨取得を行いましょう。
 将来的な計画（ex.コンビニ事業・インターネット通販）も、ユーザーがどの様な想定を思い描いているかをベンダに詳しく説明し
ましょう。その際、システム的なことだけでなく、業界状況や法規制などの情報も伝える必要があります。
 企画段階でベンダより情報収集のためのインタビューがあるので、各部門に精通した担当者を前もって選任しておきましょう。
 現在使用している定型・非定型の資料や使用している帳票等を提供する準備をしてください。
 ベンダからは整理された経営課題、業務課題をもとに業務改善提案をまとめ、新しい業務モデル全体像と情
報システム全体像、それに必要な組織や体制、予算をユーザーに報告します。ユーザーは以下の点に注意
して承認します。
 記載された専門用語に気を付けましょう。ユーザーとベンダで内容が違う場合が往々にしてありますので、少しでも不明な点が
あったら両者で確認しましょう。
 予算を算定する必要上、フェーズＣ以下の開発・保守・運用の方針もこの時点でベンダと協議して決定しましょう。

業務要件定義段階
 機能要件だけでなく、セキュリティ要件などの直接業務に関わらない要件の定義を行います。操作画面や処
理の流れも想定してベンダーに伝え業務の流れシステムの動きを決めましょう。
 ここで決定した内容がRFP（提案依頼書、見積依頼書）になります。RFPが不十分ですと、設計開発段階で
悪影響が出ますので、要求事項はすべてベンダに伝えましょう。
モデルケースＡ社
次期販売管理システ
ム
72
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。 青文字部分
フェーズＡユーザ側のポイン
挿 入
ト③
 業界の特性などが伴う業務について、コンサルが十分に理解をしているかを確認するために説明を求め、不
十分であれば理解に必要な資料やインタビューの機会などを提供するようにしましょう。
 業務システム検討の初期段階から、業種パッケージの種類ごとに、取引や契約締結の流れを説明する提案
テンプレートを作成・活用してもらうように要求することが望ましいといえます。
 テンプレートは、第三者にとって前提条件が明確で客観的になるようなものにしてもらう必要があります。結
果として数値的記述が増えるように構成してもらう方が望ましい場合が多いです。
 「業界の常識」や「暗黙の了解」があっても、すべて文書化してもらう必要があります。さらに「～に留意する」
「なるべく～」等の曖昧な表現を避け、要望を具体化するように要請する必要があります。
 また、別紙：取引契約の全体像に、作業の納期や相互の実施項目などを書き加えれば、全体の進捗確認用
紙として活用できます。重要事項説明書で定められたトピックを別紙に当てはめ、現状の作業が、後工程で
どのように使わるか（いつ、誰が、何のために）などの説明を要求し、より分かりやすく疑義のない要件定義
書を策定してもらうようにします。
 「業務要件定義」段階では、要件定義の重要性はもちろんのこと、導入、運用・保守までの流れと、要件定義
が保守・運用に至るまでの全体の仕様に影響を与えることを十分に理解するとともに、ベンダに対しては、要
件定義の内容に誤りや、不足がないように必要な説明を求めて下さい。ユーザの業務要件定義に対する理
解が不十分であると、業務要件定義が確定後の安易な仕様の変更や、それに伴う手戻りの発生し、システ
ムの信頼性が損われる原因ともなります。
 ユーザは、ベンダはシステム導入に関するプロであるからと思って、必要な情報を提供することなく、結論の
みを急いではいけません。プロといえども必要な情報なしに業務やシステムの要件をまとめることはできま
せん。情報の提供はユーザの義務であることを理解し、必要な情報を提供する必要があります。
 ユーザは、システム導入に起因するトラブルやリスクについて正しく理解しておく必要があります。そのため
には、早合点せず、トラブル等について十分な説明を受けるようにしてください。
モデルケースＡ社
次期販売管理システ
ム
73
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。 青文字部分
フェーズＡユーザ側のポイン
ト④
 セキュリティ要件については、レベルを上げればそれだけコストも上昇します。ユーザは、
挿 入
その点を理解した
上で、本当に必要とされるべきセキュリティレベルを選択するようにしてください。
 ここでは、報告（案）の個別業務とシステム化の方針の整合が取れていることを確認した上で、それぞれの業
務に係る社員に、現実の運用段階において業務に支障をきたさないか等を評価させ、経営者（プロジェクトオ
ーナ）は承認を行うようにしましょう。
 パッケージソフトウェア候補の選定段階
 ベンダが作成したパッケージソフトウェア候補の比較について、十分に理解した上で、総合評価をもとに、自
らが候補の中からベンダの決定を最終に行なければならない。
 文書の品質
 時刻や季節、決算などの時期要因によるピーク時と、平常時とでは求める性能が異なります。システムの利
用者も、消費者、取引先、社員などによって、セキュリティや操作性は大きく異なります。
 作成される文書の品質は、前述のように第三者にとって前提条件が明確で客観的なものでなければなりま
せん。数値的記述に努め、「～に留意する」「なるべく～」等の曖昧な表現はしないようにしましょう。（ベンダ
に求めるようにしましょう）
重要事項説明書
フエーズＡサンプ
ル①
A
A 要件定義支援及びパッケージソフトウェア候補選定支74
援業務契約 （パッケージカスタマイズモデルの場合）の
重要事項の例
要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）の重要事項
作業項目
■企画（業務の新全体像、業務モデル、システム方式、付帯機能の方針、サービ
スレベルと品質に対する方針の策定支援）
現行業務フロー及び情報システムモデルの作成
個別業務問題及び情報システムの問題ヒヤリング
経営戦略ヒヤリング
業務間連携及び情報システムの課題抽出
(2)具体的作業内容
作業内容及び作業実施担当
ユーザ
ベンダ
情報システム部門資料（帳票、
伝票、管理諸表、システムフ
ロー、機器構成等）の提出、 現行業務・情報システムの調
報告書(案)のご承認
査、インタビューの実施計画
実施計画のご承認、各部門担
当者、管理職、経営者インタ
ビュー日程ご調整と報告書
(案)のご承認
の策定、実施、報告書(案)の
取りまとめ
報告書(案)の社内評価と経営
者ご承認
課題抽出、テーマ、モデル案
の取りまとめと報告書(案)作
成
情報システム中期開発計画策定
経営戦略、経営課題、情報システム全体像、優先順位、整備計画、開発・運
用・保守方針、予算
中期開発計画書(案)の社内評
価と経営者ご承認
中期開発計画の策定と計画書
(案)の作成
今次業務の新全体像の策定
経営戦略、経営課題、業務モデル全体像、情報システム全体像、期待効果、優
先順位、影響を受ける業務・人的体制、開発・運用・保守方針、予算
業務の新全体像報告書(案)の
社内評価、経営者ご承認
業務の新全体像の策定と報告
書(案)の作成
情報システム開発テーマ・業務モデル案の策定
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
重要事項説明書
フエーズＡサンプ
ル②
A 要件定義支援及びパッケージソフトウェア候補選定支75
援業務契約 （パッケージカスタマイズモデルの場合）の
重要事項の例
作業項目
■業務要件定義（機能要件、非機能要件、セキュリティを含む）
業務システム個別計画書の策定
システム化目的・目標、システム化範囲・対象、主機能（入出力、画面遷移）、
応答性能（ピーク時、平常時）、データモデル、業務フロー、情報処理フロー、
既存システムインターフェース、人的インターフェース、セキュリティ要件、開
発方針、移行方針、運用方針、保守方針（復旧等を含む）、教育方針、採用可能
なテクノロジ、ハード、ソフトウェア、ネットワーク構成方針及び概略構成、設
備・建物概略構成、開発スケジュール、プロジェクト推進概略設計（開発管理、
品質管理、組織管理、費用管理、アウトソーシング管理）、法規制・内部統制等
制限事項一覧
セキュリティ仕様の策定
作業内容及び作業実施担当
ユーザ
ベンダ
各部門ご担当者、管理職、経
営者における、業務システム
個別計画書の評価及びご承認
今次開発する業務システムの
個別計画の策定及び報告書
(案)の作成
セキュリティ仕様書(案)の評
価及びご承認
セキュリティ仕様の策定及び
報告書（案）の作成
計画書に基づくRFI（適合パッケージ、ハードウェア・ネットワーク構成、開発方 RFI(案）のご承認とRFIの配布、RFI(案)作成、RFI対象ベンダ
ベンダ提案書の取りまとめ
候補案作成
式等の提案要求）の作成と配布
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
作業項目
■パッケージソフトウェア候補の選定支援（使用許諾契約、保守性、業務要件に対す
る機能適合評価、SaaS/ASPにおいてはSLAの評価を含みます）
作業内容及び作業実施担当
ユーザ
ベンダ
ベンダ提案書に基づく比較表の作成
使用許諾契約書（制限事項、カスタマイズ成果物著作権等）
保守（費用、期間、カスタマイズ成果物等）
機能適合評価（主機能、不足機能、性能、セキュリティ、運用及び保守性）
価格及び総合評価
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
比較表(案)ご承認
業務要件定義並びにパッケー 比較表(案)作成
ジ候補選定報告書の評価及び 業務要件定義並びにパッケー
ご承認
ジ候補選定報告書案作成
重要事項説明書
フエーズＡサンプ
ル③
A 要件定義支援及びパッケージソフトウェア候補選定支76
援業務契約 （パッケージカスタマイズモデルの場合）の
重要事項の例
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・α社責任者： 開発部 丁野部長、 主任担当者： 開発部 丙山マネージャ
未決事項：
・既設、生産管理システムのファイルフォーマット及びI/FについてはA社資料未詳のため、
XX月XX日をもって本件業務の対象とするかを連絡協議会の開催をもって決定する。
付帯事項（作業を実施する場合の場所・期限等、要件の合意、承認ルールを含みます。）：
・個別業務問題及び情報システムの問題ヒヤリング、経営戦略ヒヤリング、業務間連携及び情報システムの課題抽出については、
専用作業場所としてA社本社1F第3会議室にてXXXX年XX月XX日～XX月XX日まで実施する。
・連絡協議会は、毎月第2水曜日、第4水曜日、午後3時からA社にて実施する。
・個別報告書の承認は、A社戊山取締役の記名押印を持って承認とする。
特約条項：
・報告書案については、電子メール等での提出とし、案承認後は、各5部を印刷したものと、CD-ROM2枚をあわせて提出する。
・業務完了報告の承認はA社取締役会承認事項とし、点検期間を提出日直近のA社取締役会開催後、1週間とする。
・作業遅延もしくはその恐れがある場合は、上記に関わらず速やかに連絡協議会を開催し、対策を講じるものとする。
業務完了報告書の提出期限：○○○○年○○月○○日
上記各報告書に係る点検期間：提出日から○日間
受託金額(税抜)もしくは受託金額の決定基準：￥X,XXX,XXX.-（消費税等を含む ）
（ α社XXXX年XX月XX日付け見積の通り）
損害賠償限度額：
支払期限：○○○○年○○月○○日
支払方法：口座振込
モデルケースＡ社
次期財務会計システ
ム
フェーズＢでの概況
77
【目的】このフェーズでは、要件定義に基づきパッケージ候補を評価し、パッケ
ージの決定を行うフェーズですが、機能要件の明確化が十分で無く、
また、既存システムのソフトウェア資産管理が出来ていなかった事が
発覚し、移行時の役割、運用時の実現性などは検討されていなかった。
 機能要件の定義

ユーザはパッケージソフトウェアの不足部分（アドオン、外部プログラム）および外部インターフェース）
として、以下の要件を示した。
 販売管理：百貨店から売上データ取込み（日次・夜間バッチ）
量販店とのＥＤＩ対応（受注取込み・受注取消取込み・専用伝票発行・支払案内照合）
百貨店および量販店の店舗別事業管理帳票
物流システム（入出庫指図・ピッキングリスト・伝票発行・棚卸）
コンビニＥＤＩ対応（受注取込み・受注取消取込み・専用伝票発行・支払案内照合）
通信販売Ｗｅｂ対応（在庫照会・購買履歴・受注・宅配便伝票発行・送品案内・決済）
 財務会計：販売管理および生産管理から自動仕分データの取込み
百貨店および量販店の月ズレ処理に対応できる月次決算の遡及処理

財務会計については、ユーザの担当責任者が財務会計業務を熟知している取締役経理部長であるこ
とから、また、既存システムは会計事務所が導入支援を行ったことから、Ｐ／Ｌ・Ｂ／Ｓの階層やマスタ
等の整備に関しても明確に定義されており、新業務の全体像も具体的に示すことが出来た。
＊しかしながら、既存システムの資産管理はなされておらず、情報システムに関する各種ドキュメントも未
整備（未整理）で、また、新設の電算部門も単独の業務システムであれば対応可能なスキルはあるも
のの、今回の様な業務連携システムにおける構築経験は無く、新規事業への対応もあることから、何
から整理をして良いのか皆目見当がつかない状況であった。
モデルケースＡ社
次期販売管理システ
ム
78
【目的】コンサルタントの支援を得て、パッケージソフトウェア候補からシステム要
件評価および既存システムとの接続性の評価を経てパッケージソフトウェ
アを決定します。
併せて、ハードウェア構成およびテスト仕様書の作成を行います。
フェーズＢコンサル支援内容
①
 パッケージ候補のシステム要件評価（移行要件を含みます。）
 要件定義を支援するベンダは、ベンダの支援の下でユーザが選定したパッケージソフトウェアについて、さら
に詳細な評価を行いユーザに提案を行います。特に移行については、必要な作業とその対応を行うのがユ
ーザかベンダかを明確にする必要があります。この場合の検討事項は以下のとおりです。
 機能要件の適合及び充足度、不足する機能要件、（カスタマイズ部分の機能要件）
 非機能要件の適合及び充足度、不足する非機能要件
 セキュリティ要件の適合及び充足度、不足するセキュリティ要件とそのリスク
 ハードウェア、ネットワーク構成方針との適合及び充足度
 既存システムインターフェース要件との適合及び充足度、実現困難性
 運用・保守方針適合及び充足度、実現困難性
 データ移行の整合性、実現困難性、移行に伴う制限事項
 法規制・内部統制等制限事項適合性
 パッケージ候補費用概算見積
 以上の検討の際、パッケージソフトウェアのブラックボックス部分（パッケージソフトウェアメーカでなくてはわ
からない部分）がある場合は、それによる不確定要素を明確にした上で、ユーザに承認を受けます。

APIの実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価）
 ベンダは不足する要件や他のシステムとの接続について、その実現方法を提案します。カスタマイズにより
実現する場合は、その部分については新規開発と同様に開発工数とコストがかかるので、概算のコストと開
発完了時期を提示する必要があります。またその他の手段で実現する場合は、その内容をより具体的にユ
ーザに説明する必要があります。ここでは以下の点に注意します。
 論理的な接続だけではなく、そのタイミングや頻度についても要件を満たしているか。例えば、販売管理では日々データを出
力できるが財務管理では月に一度しか取込みができないようなケースで、財務管理側で日々の進捗確認は困難となります。
 また、返品等の取引があったとき出力先のシステムでそれらのデータをどのように扱うかの確認も必要となります。
モデルケースＡ社
次期販売管理システ
ム
79
フェーズＢコンサル支援内容
②
 またベンダはSLAの評価が必要な場合には、より具体的な指標によりサービスレベルを提示するとともに、
そのレベルが維持されない場合のリスク等についても報告します。機能要件の適合及び充足度、不足する
機能要件、（カスタマイズ部分の機能要件）

パッケージソフトウェアの選定（ソフトウェア要件定義と評価）
 ベンダはこれまでの承認された報告内容に基づき、パッケージソフトウェアにおけるソフトウェア要件を入出
力画面や画面遷移を含む用件としてまとめ、ユーザの承認を受けます。

推奨ハードウェア構成の概要
 ベンダは、ハードウェアやネットワークの構成の詳細、既存システムとの物理的接続について報告し、ユー
ザの承認を受けます。この場合、ソフトウェアメーカーと開発ベンダが異なったり、構成に特殊なハードウェ
アがあると、開発時にソフトウェアやハードウェアが必要となるケースがあります。これらについても、必要な
タイミングも合わせてユーザに報告する必要があります。

システム全体のテスト仕様書作成
 ベンダはユーザから要求がある場合、システム全体のテスト仕様書作成を支援します。
 その場合、主に他のシステムとのインタフェースに問題が無いことやカスタマイズ対応した部分が要件どお
りであることの確認が中心となりますが、機能面だけではなく運用の側面から問題の無いことが確認できる
テストを提案する必要があります。さらに通常時の運用だけではなく、ピーク時の負荷への耐性やエラー時
や障害時の運用の切換えやシステムの復旧についても確認する必要があります。
 ベンダは、以上のテスト内容とあわせテスト環境をどのように確保するか、場合によっては必要コストについ
ても説明する必要があります。
モデルケースＡ社
次期販売管理システ
ム
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。
80
フェーズBユーザ側のポイン
ト
 パッケージソフトウェア候補のシステム要件評価段階
 ベンダに対して報告（案）の説明を十分に求め、特に移行時の役割、運用面の実現性などについて、コスト面
、人的ソース面、物理的設備についても問題がないか確認を行い、承認を行いましょう。
 業務要件定義の基づいて、機能要件の定義や使用予定のパッケージソフトウェアの比較を行います。
 APIの実現性の確認段階
 実現方法はもとより、人的側面、費用的側面、時期などに問題が無いことを十分に確認の上で承認します。
またSLAの評価が必要な場合には、特にリスクについて十分な検討が必要です。例えば、システムがダウン
したことにより取引先からペナルティを要求されるようなケースでは、許容できるダウンタイムやペナルティが
与える影響などの考慮も必要になります。
 パッケージソフトウェアの選定段階
 パッケージソフトウェアとカスタマイズ部分、それらと他のシステムとのインターフェースについての報告から
、これまでの個々の報告と全体の整合性が取れていることを確認し、承認します。
 パッケージソフトウェアの不足部分や変更部分は、この段階で明確化させておきましょう。
 推奨ハードウェア構成の概要段階
 これまでに承認した運用方針やバックアップ方法など、また非機能要件などを満足する構成であることを確
認し、承認します。
 選定したパッケージソフトウェアに合わせて実際に使用する推奨ハードウェア構成などのシステム要件をベ
ンダに要求して報告させて決定します。作成するシステムで、現在は使用していないハードウェアやソフトウ
ェアなどがある場合は、必要になる可能性があるので確認しておきましょう。
 システム全体のテスト使用書作成段階
 網羅的なテスト内容になっていることを確認した上で、承認します。
重要事項説明書 B パッケージソフトウェア選定支援及び要件定義支援業務
フエーズＢサンプ （パッケージカスタマイズモデルの場合）の重要事項の例
ル①
B
パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）の重要事項
81
(2)具体的作業内容
本件業務にあたって使用する業務要件定義書 ： 改訂版業務要件定義並びにパッケージ候補選定報告書
作業項目
作業内容及び作業実施担当
ユーザ
■パッケージ候補のシステム要件評価（移行要件を含みます。）
ベンダ
機能要件の適合及び充足度
不足する機能要件、実現困難性
非機能要件の適合及び充足度、実現困難性
セキュリティ要件との適合及び充足度、実現困難性
ハードウェア、ネットワーク構成方針との適合及び充足度
既存システムインターフェース要件との適合及び充足度、実現困難性
運用・保守方針適合及び充足度、実現困難性
詳細比較項目(案)の評価及び
ご承認
パッケージ候補システム要件
詳細比較報告書(案)の評価及
びご承認
詳細比較項目(案)の策定
パッケージ候補システム詳細
比較の実施と報告書(案)の作
成
ユーザ
ベンダ
パッケージ候補APIの実現性
確認報告書(案)の評価及びご
承認
パッケージ候補APIの実現性確
認の実施と報告書(案)の作成
パッケージ候補と既存システ
ム接続性評価報告書(案)の評
価及びご承認
パッケージ候補と既存システ
ム接続性評価の実施と報告書
(案)の作成
データ移行の整合性、実現困難性、移行に伴う制限事項
法規制・内部統制等制限事項適合性
パッケージ候補費用概算見積
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
■APIの実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価、
SaaS/ASPにおいてはSLAの評価）
不足する要件の実現方法
開発もしくは実現方法及び困難性評価
開発工数の概算見積、実現方法の概算見積
既存システムとの接続性評価
開発方法
開発工数の概算見積
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
重要事項説明書 B パッケージソフトウェア選定支援及び要件定義支援業務
フエーズＢサンプ （パッケージカスタマイズモデルの場合）の重要事項の例
ル②
作業項目
■パッケージソフトウェアの選定（ソフトウェア要件定義と評価）
82
作業内容及び作業実施担当
ユーザ
ベンダ
業務システム個別計画書、パッケージ候補システム要件詳細比較報告書及びパッ
総合評価報告書(案)の評価及 総合評価の実施と報告書(案)
ケージ候補APIの実現性確認報告書に基づく総合評価（セキュリティ要件及び運用・
びご承認
の作成
保守方針適合を含む）
カスタマイズ開発仕様及び概算見積
カスタマイズ開発仕様（画面
カスタマイズ開発仕様書
構成、画面遷移を含む）の策
（案）の評価及びご承認
定と仕様書（案）の作成
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
■推奨ハードウェア構成の概要
ハードウェア詳細構成及びネットワーク詳細構成
既存システムインターフェス詳細
ユーザ
ベンダ
ハードウェア・ネットワー
ク・既存システムインター
フェース詳細構成報告書(案)
の評価及びご承認
ハードウェア・ネットワー
ク・既存システムインター
フェース詳細構成の策定と報
告書(案)の作成
ユーザ
ベンダ
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
■システム全体のテスト仕様書作成（○実施する・実施しない）
業務システム個別計画書、総合評価報告書及びハードウェア・ネットワーク・既存
システムインターフェース詳細構成報告書に基づく業務システムテスト仕様
実施する場合、以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
テスト仕様書（案）の評価及 テ ス ト 仕 様 の 策 定 と 仕 様 書
びご承認
（案）の作成
重要事項説明書 B パッケージソフトウェア選定支援及び要件定義支援業務
フエーズＢサンプ （パッケージカスタマイズモデルの場合）の重要事項の例
ル③
83
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・α社責任者： 開発部 丁野部長、 主任担当者： 開発部 丙山マネージャ
未決事項
・業務要件定義並びにパッケージ候補選定報告書のセキュリティ要件については 、A社本社工場改修設計書（XXXXX年XX月XX日版）に基づき、
全項目を改訂するものとし、同要件は未決事項とする。
・セキュリティ要件修正作業及び改訂版業務要件定義並びにパッケージ候補選定報告書の提出期限については、α社より別途、連絡協議会にて報告
するものとする。
付帯事項（作業を実施する場合の場所・期限等、要件の合意、承認ルールを含みます。）：
・連絡協議会は、毎月第2水曜日、第4水曜日、午後3時からA社にて実施する。
・個別報告書の承認は、A社戊山取締役の記名押印を持って承認とする。
特約条項：
・セキュリティ要件改訂作業を含み、改訂版業務要件定義並びにパッケージ候補選定報告書を作業期間中に提出し承認を得るものとする。
・本件業務は前項改訂版業務要件定義並びにパッケージ候補選定報告書に基づき実施されるものとする。
・報告書案については、電子メール等での提出とし、案承認後は、各5部を印刷したものと、CD-ROM2枚をあわせて提出する。
・業務完了報告の承認はA社取締役会承認事項とし、点検期間を提出日直近のA社取締役会開催後、1週間とする。
・作業遅延もしくはその恐れがある場合は、上記に関わらず速やかに連絡協議会を開催し、対策を講じるものとする。
業務完了報告書の提出期限：○○○○年○○月○○日（RFP作成を含む・含まない）
上記各報告書に係る点検期間：提出日から○日間
受託金額(税抜)もしくは受託金額の決定基準：
損害賠償限度額：
支払条件
支払方法：
支払期限：
現金・口座振込
モデルケースＡ社
次期販売財務システ
ム
サンプル ＲＦＰ項目一
覧
Ⅰ．システム化要件概要
Ⅰ-１． A社（弊社）の概要
Ⅰ-２． システム再構築の目的
Ⅰ- 2.1 経営戦略の概要
Ⅰ- 2.2 本RFPの位置付け
Ⅰ-３． 業務改革及びシステム化の狙いと効果
Ⅰ- 3.1 システム更改の目的・方針
Ⅰ- 3.2 解決したい課題
Ⅰ- 3.3 狙いとする効果
Ⅰ-４． 現行システムの概要
Ⅰ-4.1 現行システム構成
Ⅰ-4.2 EDIの概要
Ⅰ-4.3 現行システム機能構成
Ⅰ-4.4 現行インタフェース
Ⅱ．提案依頼事項
Ⅱ-1． 業務要件
Ⅱ-1.1 全体システムの概要
Ⅱ-1.2 必要な機能とシステム更改範囲
Ⅱ-1.3 EDIのシステム更改範囲
Ⅱ-1.4 想定する外部インタフェース
Ⅱ-2.1. システム要件
Ⅱ-2.2 システム化の考慮点
Ⅱ-2.3 アプリケーションソフトウェア
Ⅱ-2.4 ハードウェア
Ⅱ-2.5 ネットワークアーキテクチャ
Ⅱ-2.6 システム利用時間帯
84
Ⅱ-3 納期およびスケジュール
Ⅱ-4 納品条件
Ⅱ-5 プロジェクト及びプロジェクト推進体制
Ⅱ-6 移行方法
Ⅱ-7 教育・トレーニング計画
Ⅱ-8 保守・運用サービス
Ⅱ-9 費用見積
Ⅱ-10 セキュリティ対策
Ⅲ．提案手続きについて
Ⅲ-1 提案手続き・スケジュール
Ⅲ-2 提案依頼書の対応窓口
Ⅳ．開発に関する条件
Ⅴ．契約に関する事項（契約形態・検収・費用）
Ⅵ．貴社に関する事項
Ⅵ-1 会社概要
Ⅵ-2 実績の紹介
添付資料1
Ⅵ-3 類似システムリプレース実績
添付資料2
Ⅵ-4 オプションサービス説明資料
添付資料3
Ⅶ．用語集
添付資料4
組織図
業務規程
EOS,EDI取引先一覧
現行ネットワーク構成図
添付資料5 現行トランザクション量
別冊1 業務定義・システム機能要件
（基幹系業務編)
別冊2 業務定義・システム機能要件
（情報系業務編)
別冊3 業務定義・システム機能要件
（マスタ管理業務編）
モデルケースＡ社
次期販売管理システ
ム
サンプル 要件仕様書
要件定義書サンプル 別紙
85
設計開発、移行・
運用準備の
流れと責任
D 外部設計支援業務契約、E ソフトウェア設計・制作業務契約、F 構築
業務契約、G データ移行支援業務契約、H テスト支援業務契約、I 導入
教育支援業務契約
86
 仕様変更への対応
 設計開発、移行・運用準備段階では、確定した要件定義に対して、修正や変更
が発生する場合があります。修正や変更の原因を正しく把握し、対処することが
重要です。
 仕様と異なる実装がなされた場合は、変更規程に基づきユーザの承認を得て、
報告書を作成しなければなりません。
ⅰ
要件定義
設計開発
ⅱ
ⅲ
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
準委任
D 外部設計支援業務契約
請負
E ソフトウェア設計・制作業務契約F 構築業務契約
移行・運用
準備
準委任
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
モデルケースＡ社
次期販売・財務システ
ム
フェーズＤでの概況
87
【目的】本フェーズは要件定義書を基に、画面・帳票・インタフェース等の外部
設計書に対する検討会をユーザとベンダで行い、承認を行う段階です
が、本段階において追加・変更をせざる得なく状況となるに至った。
速やかに、連絡協議会が開催され要件変更手続きがとられた。
 外部設計書の承認段階での問題点
 コンビニ事業部は新規事業部門であることから、電算部門が中心となり、業務要件の集約を行っ
たが、事業の運営方針も不明確な点も多く、電算部門も新設で自社の業務知識が十分でないこ
とから、要件定義段階では見逃されていた、画面・帳票の不足が発生した。
 コンビニ事業における物流は共同配送センターを利用することで、物流部門は自部門の業務運
営上の問題点については、十分な打ち合わせを行っていたが、ＩＴに関しては、電算部門が別途
打ち合わせを行っているとの認識で、物流部門の要件から共同配送センター対応システムの要
件が欠落していた。
 百貨店からの売上データ取込みのインターフェース変更が百貨店事業部へ通知されていたが、
電算部門へ通知の連絡が滞っており、外部設計書の変更が必要となった。
 量販店事業部より来年から予定されている指定伝票の様式変更が反映させていないとの指摘が
なされた。
 要件定義段階への手戻りと外部設計書の修正（連絡協議会による要件変更手続）
 要件定義支援をおこなったコンサルタントであるＩＴコーディネータと外部設計支援をおこなったベ
ンダおよびユーザにて、連絡協議会が開催され、要件定義段階への前戻り作業の要因分析を
行ったところ、ユーザ電算部門と利用部門との連携が上手くいっていない点がクローズアップされ、
ユーザ社長はこの問題を重要視し、利用部門より新たにプロジェクトメンバーが追加アサインされ
た。
 ユーザ経営層からはコンサルタントであるＩＴコーディネータの債務不履行ではないのか、無償で
要件定義を再度 実施して欲しいとの要望が出されたが、コンサルタントの見解は、ユーザからの
情報提供の不足と報告書の確認不足である旨の説明とベンダも同様の所見であることから、自
社の問題が起因したものと納得が得られた。（準委任契約における責任範囲外）
 要件定義段階と外部設計の手戻り作業がスケジュール化され、プロジェクト全体のスケジュール
遅延とコスト増加について、ベンダより報告がなされ、コストについてはユーザとの合意が得られ
たが、スケジュールについては、当初スケジュールでの稼働に対する努力要請がベンダに対して
出され、ベンダは要請を受け入れるに至った。
モデルケースＡ社
次期販売財務システ
ム
88
フェーズDベンダ支援内容
 推奨ハードウェア構成
 ベンダは、外部設計段階で将来の処理増大に伴うスーケルアップ、スケールアウトの拡張構成などの柔軟
性の確保と稼働時点で過少、過剰設備とならないハードウェア構成とし、ユーザと合意を行う。
 外部設計支援業務段階における支援業務
 具体的作業内容で、要件定義書、作業体制、外部設計検討会の開催、委託先などについて、ユーザの合意
を得なければならない。
 パッケージソフトウェアの表示では、バージョン、リビジョン、保守やサポート体制について明らかにし、また、
その時点で判明している不具合などがあれば、併せてユーザの確認を得ておく必要がある。
 外部設計書、付属文章一覧で業務フロー、システム構成、実態関連図を作成する必要がある。
 外部設計検討会の開催支援
 ベンダは外部設計段階で作成した上記文章をユーザに十分に説明し、ユーザ、ベンダ合同で検討評価する
場であり、ベンダは事前にユーザに何を決定するのかなどの成果と品質について合意を得ておく必要があ
る。
 外部設計支援業務での要件の多大な追加、変更が生じた場合、その原因がベンダ、ユーザのいずれにあ
るのか、ベンダに説明を求めた上、重要事項説明書の記載と照らして判断する必要があります。
モデルケースＡ社
次期販売・財務システム
フェーズＤにおけるユーザポイ
ント①
 ユーザ側におけるポイント
 要件定義書などの仕様に基づいた、画面や帳票、
インターフェース、他のシステムと遣り取りすること
を前提としたデータ方式などの外部設計書の承認
を行います。
 外部設計支援業務はインタフェースや帳票、データ
種類のフォーマットなどを外部設計書を作成支援す
る契約です。いずれも使い勝手や他とのデータやり
取りにかかわる部分ですので注意してください。な
お画面設計などは要件定義書で基にすれば作成で
きるはずですので想定していません。セキュリティ
についてRFPに該当項目ない場合は、ここで設定し
ます。その際はセキュリティチェックシートを利用し
てください。
 実際のインタフェースに関わる部分ですので、実際
に業務を運用している部門のスタッフにも内容を確
認させましょう。
 帳票は現在の使用している様式が使用可能可を確
認しましょう。
 データのフォーマット形式を確認しましょう。外部と
データの遣り取りをする場合は相手方の形式を確
認しましょう。
89
 ベンダ側からの要請されるポイント
 外部設計支援から担当するベンダが異なる時は、
外部設計支援を担当するベンダは要件定義を前提
に開発を行うので、要件定義が不十分だと、それを
十分なものとすることを求めてきます。この場合、
三者間で連絡協議会などを通して十分に状況・問
題点・課題の共有を図り、行うべき作業の分担と責
任を明確にする必要があります。
 要件定義支援担当のベンダが担当する作業例
•
•
•
•
コンビニ事業に必要な画面・帳票の洗い出し
百貨店売上データ取込みのインターフェース
量販店指定伝票の様式変更
これらをもとにした要件定義の見直しと改版
 外部設計担当のベンダが担当する作業例
•
•
新たな要件定義を前提とした開発体制の確保
これらをもとにした開発計画
 この場合、要件定義の見直しをしたうえで、外部設
計支援担当ベンダからあらためて外部設計以降の
重要事項説明書の説明を受け、確認後、承認をする
ことになります。ユーザがやるべきことを確認する必要があ
ります。
 尚、ひとつのベンダに全てをお願いする場合でも、
要件定義が不十分な場合は上記と同じステップを
踏む必要があります。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＤにおけるユーザポイ
ント②
 ユーザ側におけるポイント
 この段階で変更や追加事項が生じた場合は要件定
義が不十分と言うことになるので、連絡協議会等を
開催して要件定義を見直して、新たな外部設計の
重要事項説明書を提出を受けます。
 ユーザー側に責任のある変更の場合は、新たに作
業を行う必要や追加費用の発生もあります。作業
の進捗状況のスケジュール、報告については作業
体制に基づいた窓口より、どのような形式と区切り
で報告を受けるかを確認します。
 設計段階において、ベンダより設計環境の貸与や
借用を求められる場合もあるので、その際は費用
や期間などの明確化も行う必要があります。
90
重要事項説明書
フエーズＤサンプル
91
D 外部設計支援業務
重要事項説明書の例
D 外部設計支援業務契約の重要事項 (2) 具体的作業内容
１．要件定義
○○○○年○○月○○日付け「A社 次期販売・財務システム」要件定義書
第×版に基づく
２．設計作業の体制及び方法
（１） 作業体制（受託者の体制、責任者、主任担当者、連絡窓口等）
・責任者：
β社開発部 部長 甲野太郎
・主任担当者： β社開発部 開発マネージャー 乙山次郎
・連絡窓口： β社業務部 主任 丙川三郎
（２） 設計方法（設計工程、進捗管理及び報告、設計環境の貸与・借用等）
・進捗管理： β社にて管理。週1回、A社に進捗報告
・設計環境： β社にて準備（貸与なし）
（３）外部設計検討会（日程、場所、参加者、内容、変更管理手続等）
・○○○○年○○月○○日、A社本社にて実施
・A社、β社の責任者、主任担当者、α社（要件定義担当社）担当者が出席
・画面・帳票の過不足、インタフェース仕様の確認を行う。
（４）委託先
・なし
（５）期間： ○○○○年○○月○○日～ ○○○○年○○月○○日
３．未決事項
・生産管理システム（既存）とのネットワーク接続仕様
４．付帯事項
・帳票の過不足等、業務要件定義の不備による要求定義の改定はα社に
て行う。
・上記の改定によるβ社の作業量増加等が発生した場合は、提出期限等
の条件見直しについて、A社とβ社で協議する。
５．特約事項
業務完了報告書及び外部設計書の提出期限：○○○○年○○月○○日
上記報告書及び外部設計書に係る点検期間： 提出日から１０日間
受託金額（税抜）： ○百万円
損害賠償限度額： ○百万円
支払期限： ○○○○年○○月○○日
支払方法： 口座振り込み
モデルケースＡ社
次期販売・財務システ
ム
フェーズＥでの概況
92
【目的】請負契約であることからユーザはベンダへの丸投げ意識が強く、テスト
データの準備に関する利用部門の意識は低く、また、既存システムから
のテストデータ準備に関して、既存ベンダとの調整が難航し、作業遅延
をきたし、これらの問題をベンダの支援にて解決を図った。
 ベンダの適格性テスト
ユーザとしては、ソフトウェアの開発段階であり、また請負契約でもあることから、ベンダへの丸投げ意
識が強く、ベンダテストに対する関心は低くなりがちであった。
 ベンダの出荷テストである適格性テストについては、テスト体制・合格基準・ユーザデータの使用の有
無について、ユーザ電算部門はきちんと理解していたが、プロジェクト全体での周知までには至らず、
既存データがないコンビニ事業部（新規事業部門）については、テストデータの提供を行わず、ベンダ
が単独で仮想データを作成し、結果、想定される取引データが十分に反映されていないデータでの、
適格性テストをベンダが実施してしまった。
 通販事業部が取りまとめたテストデータには、各店舗で収集した個人情報が多数含まれていた。これ
らのデータがベンダ側と個人情報に関する取扱および保管に関する取り決めもないままに、無造作に
ベンダへ渡され使用されていた事が、ベンダのプロジェクト管理者が発見し、ベンダ側よりユーザ社長
に対して報告（謝罪）がなされた。
ユーザ社長は個人情報保護について認識を新たにし、個人情報を取扱う百貨店事業部と通販事業部
に対して、重点的に再発防止策の検討と徹底が指示された。（謝罪のおり、ベンダからセキュリティと個
人情報に関する社員教育の必要性について、提案が出されたがユーザの関心は低かった。）
 テストデータ作成のため、既存システムのベンダへ協力してもらいたい内容が、ベンダより示された、こ
れを受けて、ユーザ電算部門は、既存ベンダに協力要請とコスト交渉を行った。
既存ベンダより提示された、既存システムからテストデータ抽出プログラム開発費および立会作業費
は、ユーザの認識を大きく超えるもので、ユーザ社長の認識としては、立会作業は既存システムの運
用支援契約反中ではないのかとの疑問も既存ベンダに投げかけられ、既存ベンダも積極的に作業を
行う事由もなく、テストデータ準備作業は大幅に遅延するに至った。

モデルケースＡ社
次期販売・財務システ
ム
フェーズＥにおけるユーザポ
イント
 ユーザ側におけるポイント






ベンダの出荷テストである適格性テストについ
ては、テスト体制・合格基準・ユーザデータの
仕様の有無についてのベンダの説明について、
十分に納得の上、承諾する必要があります。
ベンダの出荷テストである適格性テストについ
ては、テスト体制・合格基準・ユーザデータの
使用の有無について、ベンダへ説明を求める
必要があります。
制作されたソフトウェアは納入前にベンダ適格
性テストを行います。これはソフトウェアが的
確に動作するかを出荷前にベンダ内でテスト
を行うものです。
適格性テストについては、テスト体制・テスト内
容・テストに使用するデータについてベンダと
取り決めます。
テストの内容について、その結果が運用に耐
える内容かどうかを判断できるスタッフもベン
ダとの取り決め時に入ってもらい合格基準を
決定しましょう。
テストに使うデータについて実際のデータを使
う場合は、個人情報・機密情報などが含まれ
ている場合もあるため、ベンダとの間に取り扱
いの規定を決める必要もあります。
93
 ベンダ側からの要請されるポイント
 テスト体制にはベンダ要員だけではなくユー
ザからも結果の妥当性について確認ができる
人が求められます。
 ベンダはどのようなテストをするかを説明して
くれますがそれで十分かどうかの判断はユー
ザが行う必要があります。判断がつかない場
合は、IT化の範囲と照らし十分なテスト範囲で
あることを確認できるように、ベンダに対して
説明を求める必要があります。
 その上で、適合性テストの合格基準を確認し
ます。
 また、テストデータは条件を網羅していること
が重要となります。そのためユーザデータを使
用する場合、以下の点に注意しましょう。
 ユーザデータは必要な条件を網羅していること
をどのように確認するか。
 不足がある場合、ベンダとユーザどちらがテス
トデータを作成するか。
 ユーザデータに個人情報や機密情報を含む場
合、ベンダの取り扱いはどうなっているのか。ベ
ンダに取扱規定があればその規定を確認。無
ければ、授受の方法・手段、管理方法、返却や
廃棄に関する手続き、等に問題が無いことを確
認します。
重要事項説明書
フエーズＥサンプ
ル
E ソフトウェア設計・制作業務
契約
重要事項説明書の例
E ソフトウェア設計・制作業務契約の重要事項
(2) 具体的作業内容
１．システム要件、プログラム仕様
○○○○年○○月○○日付け「A社 次期販売・財務システム」要件定義書
第×版及び○○○○年○○月○○日付け「A社 次期販売・財務システム」外部
設計書に基づく。
２．設計作業の体制及び方法
（１） 作業体制（受託者の体制、責任者、主任担当者、連絡窓口等
・責任者：
β社開発部 部長 甲野太郎
・主任担当者： β社開発部 開発マネージャー 乙山次郎
・連絡窓口： β社業務部 主任 丙川三郎
（２） 開発方法（開発工程、進捗管理及び報告、設計環境の貸与・借用等）
・進捗管理： β社にて管理。週1回、A社に進捗報告
・開発環境： β社
（３）委託先（委託先の概要、管理体制等）
・百貨店からの売上データ取込機能について、Ω社に製造を委託する。
・Ω社の概要： 従業員30人。Β社から、年10件程度を製造委託
・委託責任者： β社開発部 部長 甲野太郎
・委託担当者： β社開発部 開発マネージャー 乙山次郎
（４）期間： ○○○○年○○月○○日～ ○○○○年○○月○○日
94
３．ベンダにおける適格性（出荷）テスト条件
（１）テスト体制（出荷合格の体制（テスト実施主体、環境、責任者等）
・適格性テストは、β社品質管理部が行う（責任者：丁島四郎 品質管理部長）
（２）テスト内容、方法（出荷合格とする条件）
・適格性テスト仕様書にて定める。
（３）テストデータ（テストで使用するデータの詳細および作成主体等）
・テストデータは、A社にて、実データをもとに作成し、β社に提供する
（４）期間： ○○○○年○○月○○日～ ○○○○年○○月○○日
４．運用テスト仕様書（運用テスト計画、運用テスト仕様）の作成
・β社開発部にて作成する。
・○○○○年○○月○○日に運用仕様検討会議をA社本社にて行う。
５．連絡協議会の実施要領及びユーザ・ベンダの責任者、主任担当者
・○○○○年○○月○○日、A社本社にて実施
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
６．未決事項
７．付帯事項
８．特約事項
納期： ○○年○月○日
テスト期間： ○○年○月○日～○月○日
瑕疵担保期間： 1年間
受託金額（税抜）： ○○百万円
損害賠償限度額 ○○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
モデルケースＡ社
次期販売・財務システ
ム
フェーズＦでの概況
95
【目的】このフェーズでは、要件定義および外部設計に基づき、指定されたハードウェ
・ソフトウェア・ネットワークが要求通り動作するように設定されたことを受入検査
します。既存システムとの併設（結合）についても同様です。
 構築仕様書の承認
 電算部門を中心に次期販売・財務システムにて使用するハードウェア・ソフトウェア・ネットワークの構築内
容について、ベンダより構築仕様書に基づいて説明が行われた。承認についてはユーザ社長より電算部門
に権限委譲がなされていたこともあり、構築仕様書の作成および承認については、スムーズに合意形成が
おこなわれた。
 併設する既存システムである生産管理システムとのネットワーク接続に対する接続使用に関しては、ベンダ
とユーザ電算部門が協力して作成した既存システム接続仕様（案）が、工場担当者より既存ベンダに示され、
既存ベンダは協力要請については、生産管理システムが今回の新システムの対象外で併設であることもか
らも、事前確認、立会作業および保守作業の作業分担等積極的な協力が得られる事となった。
 人事給与システムに関しては、市販されているパッケージソフトを購入し、ユーザが構築したこともあり、既
存システムに関する運用支援をおこなっているベンダがいないことから、新システム構築ベンダがパッケー
ジメーカに問合せを行い、併設環境を構築することになった。
しかしながら、人事給与システムに起因する不具合が発生した場合については、ベンダ側は責任を負わな
い旨の申し入れが出され、これを作業の条件にすることでユーザとベンダで合意がなされた。

構築、設定作業の受入れ
 生産管理システムの工場担当者4名は、新システムのプロジェクトメンバであったが、自部門システムが対
象でないことも有り、プロジェクトへの参画意識は低く、ベンダと電算部門にてスケジュールされた生産管理
システムと新システムとのネットワーク接続テスト実施時間帯でのシステム停止が出来ずに、作業者および
立会者が約半日待ちが発生し、追加費用の請求がベンダおよび既存ベンダよりユーザへ提示されるに至っ
た。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＦにおけるユーザポ
イント
 ユーザ側におけるポイント
ベンダから提供を受ける構築業務設定報告書
の内容について十分に説明を受け、内容につ
いて十分に理解してから承認する必要があり
ます。
 構築仕様書の内容について、十分にベンダへ
説明を求め、同意する必要があります。
 構築仕様書と実作業が異なる場合には、構築
業務設定報告書においてベンダへ説明を求
め、その内容について承認をしなければなり
ません。
 ベンダの出荷テストである適格性テストについ
ては、テスト体制・合格基準・ユーザデータの
仕様の有無について、ユーザにきちんと説明
を求める必要があります。

96
 ベンダ側からの要請されるポイント
 構築にあたり最も注意を要するのは、稼働中
のシステムに対する影響です。ベンダは構築
するシステムについての説明は行いますが、
それでは十分ではありません。説明が不足し
ている場合は、稼働中システムへの影響をど
のように確認したかの説明を受ける必要があ
ります。その場合、ベンダから以下のような点
を求められることがあるのでユーザは関係者
への確認と調整を行います。
 構築作業時、生産管理システムや人事給与シ
ステムの稼動停止、または稼動したままの構築
が問題が無いことの確認
 ハードウェアベンダが異なる場合、構築に必要
なハードウェアの手配状況の確認
 既存システムのデータ等のバックアップ（ベンダ
は未知の部分については責任を負いかねるこ
とになるので、万一を考え必ず必要となります）
 これらについて既存ベンダとの調整
重要事項説明書
フエーズＦサンプ
ル
97
F 構築業務契約
重要事項説明書の例
F 構築・設定業務契約の重要事項 （2）具体的作業内容
項番
名称・型番
設置場所
仕様もしくは仕様書名
（設定内容、他システムとの結合の有無、障害発生時の切り分け作業、受入テスト条件等）
期間
１
通販システムサーバ
A社本社 712号室
通販システム設定仕様書。DMZを介してインターネットに接続
○月○日～○月○日
２
通販ネットワーク
A社本社
通販ネットワーク設定仕様書。DMZ、多重化の設定等
○月○日～○月○日
：
：
：
：
：
：
：
：
：
：
関連するシステム、ネットワークの停止等の条件
・生産管理システム、人事給与システムの稼働停止がないこと
連絡協議会の実施要領及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
委託先（委託先の概要、管理体制等）
・なし
付帯事項：
特約事項：
構築・設定業務完了報告書提出期限（構築・設定業務報告書を含む）： ○○○○年○○月○○日
受託金額： ○○百万円（税抜） 受託金額はソフトウエア設計製作業務の受託金額に含んでいます。
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
テスト期間： ○○○○年○○月○○日～○○月○○日
瑕疵担保期間： 1年間
損害賠償限度額： ○○百万円
モデルケースＡ社
次期販売・財務システ
ム
フェーズＧでの概況
【目的】このフェーズでは、既存システムのデータを新システムへ移行する
作業をおこないます。既存システムベンダに対する協力要請と作
業実施に関してはユーザ責任で実施する必要があります。
98
 要件定義書に基づくデータ移行作業
既存販売管理システムからのデータ移行作業については、全体コストが増加していることから、既存ベ
ンダへ作業依頼することなく、電算部門が既存システムからデータ抽出を行い、新システムベンダが移
行データの取込み作業を行う事で、移行作業が進められたが、利用したプログラムはテストデータ抽
出時に既存ベンダが開発したもので、ユーザ側より開発費の削減要求が強かった事もあり、繰り返し
利用時の変更データ部分の差分抽出機能等がカットされており、全てのマスタおよびトランザクション
データを繰り返し移行作業するのは、困難である事が明らかとなった。
再度、ユーザおよび既存ベンダと新システムベンダデータにて、データ移行に関する協議の場がもた
れ、データ移行作業の詳細仕様について追加作成が行われ、データ移行作業の役割分担とユーザ側
の当該事業部門における移行確認作業について、合意が形成された。
 しかしながら、ユーザとしては移行に関するコストは、テストデータ移行費用と二重投資を招くことにな
り、結果として全体費用を押し上げることとなった。
 新規事業であるコンビニ事業および通販事業に関しては、あらかじめ事業部門で用意したエクセル
シートから、次期システムへ取込み作業を行って欲しいとの要請が出され、ベンダが作業を行ったが欠
落データや仕様外のデータが多数存在し、移行作業が暗礁に乗り上げる事となった、電算部門とベン
ダにて作成データのチェックを行う事で、移行作業を終えることができたが、スケジュールの遅延が発
生するに至った。
 財務会計システムからのデータ移行は、要件定義書作成時に、詳細項目、移行タイミングおよび作業
分担まで明確に取り決めがなされていた事と、これらに対する認知度が高く、スムーズに移行作業が
完了した。

モデルケースＡ社
次期販売財務システ
ム
99
挿 入
フェーズＧベンダ支援内容
 データ移行支援作業
 データ移行支援業務は、既に決定している要件定義の仕様に基づき、ベンダの作業は実施されます。
 ベンダにて移行データの仕様が記述できない場合、相当するシステム要件定義書等を指定がなされます。

重要事項説明書記載内容における留意点
 受託金額及びその決定基準並びに損害賠償限度額は、移行するデータの範囲、移行のための抽出作業、
移行のための変換作業及び新システムへの移行のそれぞれに記載するようになっています。
 特にユーザの業務に影響のある、既存システムの停止やネットワーク上の機器に対する注意事項がある場
合は、ベンダより必ず記載内容に基づく説明を求める必要があります。

双方における合意形成
 他のフェーズも同じですが、このフェーズでは特に作業をスムーズに進めるために、ユーザとベンダの役割
分担と対応期日を明確にしておく必要があります。
 他のベンダが構築した稼働中のシステムがある場合は、そのシステムへの影響や、結合について、問い合
わせ等が発生することがあります。そのため、問い合わせの窓口担当を決めておきます。また、ベンダの倒
産や資料散逸などで、情報が確認ができない場合に発生する、調査費用等の追加費用、納期変更につい
ては、十分な説明と合意が必要です。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＧにおけるユーザポ
イント
 ユーザ側におけるポイント





要件定義の仕様に基づいた作業が行われて
いるかについて確認し、不明な点については
ベンダに説明を求めるようにしてください。
事業運営に影響を与える、既存システムの停
止やネットワーク上の機器に対する注意事項
の有無について、ベンダに事前確認を行い説
明を得る必要があります。
既存ベンダに対する協力要請および協力体制
の整備はユーザの責任と役割です。
ユーザとベンダおよび既存システムベンダ等
それぞれの役割分担と期日管理を明確に行う
必要があります。
ベンダが作業中に既存システムのデータ等を
誤消去する事も想定されますので、バックアッ
プの実施および復旧方法の検討等について
事前確認が必要です。
100
 ベンダ側からの要請されるポイント
 移行作業では構築作業以上に既存システム
への影響等に注意が必要となります。
 ベンダと合意する作業記述書の確認では、作
業項目が十分であることに加え、具体的に
ユーザ側の対応を行う社員をイメージし、日程
に問題が無いことや万一予定していた社員が
対応できない場合のことなどを考えておきま
す。また、移行データの整合性を確認する具
体的な方法なども検討しておく必要があります。
 さらにベンダからは万一、移行が何らかの不
測事態により中断しなければならなくなった場
合、どうするかを相談されます。これについて
も、起こったときに考えるのではなく、重要事
項説明書を確認する時点で十分に協議してお
く必要があります。このとき考慮すべきこととし
ては以下のような事項があります。
 必要なバックアップデータ等の準備
 協力が必要な場合、既存ベンダへの要請
 現行システムに戻すための時間はどの程度の
余裕があるか、戻す手順と手続きはどうするか。
重要事項説明書
フエーズＧサンプ
ル
101
G データ移行支援業務契約
重要事項説明書の例
G データ移行支援業務の重要事項 （3）具体的作業内容
移
行
の
た
め
の
変
換
作
業
ユ
ー
ザ
管
理
者
期間
項番
１
会社名
A社
所属
コンピューターセンター
氏名
己田 五郎
連絡先
03-○○○○-○○○○
○○○○年○○月○○日～ ○○月○○日
ベ
ン
ダ
担
当
者
会社名
β社
所属
開発部
氏名
乙山次郎
連絡先
03-○○○○-○○○○
業務完了報告書提出日並びにその点検期間： ○○○○年○○月○○日（点検期間７日間）
作業内容（ユーザ、ベンダの役割分担を含みます。）
既存販売管理システムの履歴データを、新規システム用に変換（β社担当）
作業仕様書名、実施詳細
販売履歴データ変換仕様書
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、
主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
付帯事項： （作業を実施する場合の場所・期限等、要件の合意、承認ルールを含みます）
・変換作業はA社コンピュータセンターにて行う。
特約事項：
受託金額（税抜）もしくは受託金額の決定基準
○百万円
損害賠償限度額：
○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
モデルケースＡ社
102
次期販売・財務システ 【目的】このフェーズでは、運用にかかわる作業手順の策定および作業手順に
基づくテスト仕様書を作成します。テスト仕様書に基づき、プログラムが
正常に動作しているかの合否判定をおこないます。
ム
追加要望については、原則凍結し、別途改善プロジェクトへ先送りした
フェーズＨでの概況
 運用（作業）手順書の作成
 電算部門が運用手順書の作成をおこない、利用部門にて作業手順書を作成し、電算部門にて運用手順書
と作業手順書の整合性のチェックがおこなわれないまま、テスト仕様書の作成段階で不整合が発覚した。
不整合のポイントとしては、作業手順書のコンビニＥＤＩ自動実行の実施時間帯が、運用手順書の自動バッ
クアップの実行時間帯と重複するといったもので、べンダの指摘を受け、電算部門にて事業部門毎のシステ
ム稼働時間帯の再整理により、バックアップ自動実行可能時間はAM2：00～6：00の4時間であることが明
確になった。
 ベンダのアドバイスでシステム等のメンテナンスもあることから、バックアップ自動実行時間をAM2:00～4：
00までの２時間とすることで決定し、電算部門とベンダでバックアップ仕様の日常バックアップのカバレッジ
範囲の縮小がユーザ内で決定された。
 ベンダより想定されるシステム障害に対する復旧時間の目安について、ユーザに提示された。
 テスト仕様書の作成
 ベンダよりテストをすべきポイントについての提案がなされ、ユーザ電算部門の確認の上、利用部門に説明
がなされたが、実際の負荷を想定したテストについて、データボリュームが大きいコンビニ事業部と百貨店
事業部が難色を示し、電算部門は社長の判断を得て、計画通りのテストが実行された。
 電算部門が中心となり全システム利用部門が参加してテストが実施された。量販店事業部のプロジェクトメ
ンバから自部門へのテスト計画の周知が不十分で、テスト実行に対する要員確保が十分でなく混乱したが、
予定のテストは完了できた。

テストの合否判定責任
 日常のシステム利用については、大きな問題点は発生せずに、テストとしては合格と判定された。
しかしながら、一部の問合せ画面の操作性について、利用部門より要望が出されが凍結とした。
モデルケースＡ社
次期販売財務システ
ム
103
挿 入
フェーズＨベンダ支援内容
 データ移行支援作業
ユーザが主体となって行うフェーズのため、ユーザと計画を立て、それに従って作業を進めるように支
援する必要があります。計画において、場所や必要人員、時間などについてできるだけ詳しく検討が行
行われるように導きます。
 ベンダは専門家の立場で、どのようなテストをすべきかのポイントを整理し、ユーザに説明します。特に、
実際の負荷を想定したテストでシステムに問題が起きないことや、利用者に混乱が起きないことなどを
確認できるようにします。
 要件定義書、外部設計書、構築設定報告書等の文書を検討の上、実際に運用するための文書を作成
し、その文書を基にテスト仕様書を策定するように支援します。
 最も大事なのは、最終確認の責任はユーザにあることを理解して、ユーザが作業に取り掛かるように
促すことです。

モデルケースＡ社
次期販売・財務システ
ム
フェーズＨにおけるユーザポ
イント
 ユーザ側におけるポイント





策定されたテスト仕様書に従って、実運用環
境において、ユーザ内の実際の利用者にて作
業をおこなってください。
ユーザが主体となって、場所や必要人員、所
要時間などに詳細に計画を策定し、実行しな
ければなりません。
テストは現業業務と併行して実施されることか
ら、杜撰な計画や混乱は避けなければなりま
せん。ついては、ベンダからテストに関する説
明を十分に得て、テストの実施計画の策定お
よび社内への周知を図ることが重要です。
システムの稼働時間帯とバックアップおよび
保守等の要する時間等を具体的に検証し、シ
ステムの運用計画を最終確定する必要があり
ます。
利用部門の担当者から要望等が発生した場
合は、要件定義に立ち返り、追加、修正を実
施すべきかの可否について検討し、業務遂行
上、重大な問題でない限り、原則は意見集約
に止めるのが望ましい。
104
 ベンダ側からの要請されるポイント
 テスト仕様書に基づきテストを実施する際、
ユーザからの質問や問題が発生した時の対
応について、ベンダからユーザ側の連絡窓口
を一本化するよう求められます。
 この時、考慮すべき点は以下のようなことが
考えられます。
 ユーザ側で誰が窓口を行うか。この担当は新旧
システムの理解が十分な社員が行い、質問と
問題点の切り分けや問題点の影響度や重要性
の判断を行える社員とします。また、各業務担
当とこの窓口担当の連絡方法についても決め
ておく必要があります。
 通常時及び緊急時の連絡や回答の方法とベン
ダ側の連絡先の確保。一般的には、連絡票の
ようなものを使い、その中に問題点・原因・対応
方法・対応結果等を記録し共有します。口頭で
のやり取りは、後々問題の原因になるので避け
ましょう。
 また、この段階で要件定義に関わる問題点が
出ると要件定義担当ベンダへの確認や調整
が必要となります。
重要事項説明書
フエーズＨサンプ
ル
105
H テスト支援業務契約
H 運用テスト支援業務契約の重要事項 （2）具体的作業内容
ユ
ー
ザ
管
理
者
会社名
A社
所属
コンピューターセンター
氏名
己田 五郎
連絡先
03-○○○○-○○○○
ベ
ン
ダ
担
当
者
会社名
β社
所属
開発部
氏名
乙山次郎
連絡先
03-○○○○-○○○○
■運用にかかわる作業手順の策定（作業内容及びユーザとベンダの役割分担）
・A社電算機担当部門にて運用手順書の作成を行う。
報告書の提出期限並びに報告書の点検期間
■テスト仕様書の策定（作業内容及びユーザとベンダの役割分担）
・β社がテストすべきポイントを示し、これに基づいて、A社にてテスト仕様書を策定する。
報告書の提出期限並びに報告書の点検期間
運
用
テ
ス
ト
支
援
概
要
項番
１
：
システム名称
財務システム
：
作業場所
A社本社
：
期間
支援内容
（ユーザとベンダの役割分担）
テスト仕様書
（日付、作成者、版等）
○月○日～○月○日
β社担当者が常駐し、ガイダンス、
質問対応を行う。
○月○日付「財務システム テスト仕
様書」
：
：
：
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、
主任担当者： コンピューターセンター 己田課長。
β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
付帯事項： （作業を実施する場合の場所・期限等、要件の合意、承認ルールを含みます）
特約事項：
業務完了報告書提出期限： ○○○○年○○月○○日
受託金額（税抜もしくは受託金額の決定基準）： ○百万円
左記報告書の点検期間： 提出日から10日間
損害賠償限度額： ○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
モデルケースＡ社
次期販売・財務システ
ム
フェーズＩでの概況
106
【目的】導入教育実施内容に基づき、操作・運用方法等の教育を行います。
バックアップ等の運用に関しても同様です。
 導入教育としての操作・運用教育
 電算部門が中心となって、利用部門と検討をおこない、教育方法、対象、期間、場所、使用設備、等につい
て明確な導入教育計画が作成され、ベンダの協力も得て実施されました。
 本稼働後の、利用部門担当者の退職や休職による再教育について、導入教育計画として定める必要があ
ると、ベンダより指導されましたが、利用部門の人材が十分でないことから、再教育については電算部門に
て、運用の肩代わりと併行して教育することとなった。

バックアップの必要性について（復旧要件の最終確定）
 ベンダよりユーザにバックアップの目的について、万一の障害発生時に失ったデータやシステムを復旧する
ために、ＩＴを利用するうえで、必要不可欠な作業であり、「どのような障害に対して」は「何を」「どれくらいの
時間で」「どれくらいの期間を対象に」が明示されなければ、どのような方法（装置および手段）でバックアッ
プを実施するのか計画できないといった指摘がなされた。
 ベンダの協力を得て、電算部門と利用部門との間で、復旧要件の最終確定作業が行われた。利用部門は
日常的に利用するシステムについては理解をしていたが、無人で自動実行されているプログラムや顧客と
のデータ連携における留意事項等の説明を受け、システム全体に対する理解を深める機会となった。
 復旧要件については以下の内容となった。
 百貨店部門：百貨店から売上データ受信後の日時更新の前後の日次バックアップとし、復旧についても
日次ベースでの復旧とする。
 量販店部門：百貨店同様
 コンビニ部門：リアルタイムバックアップが必要であり、復旧については、共同配送センターへの出荷を第
一とした復旧とする。
 通販部門：リアルタイムバックアップが必要であり、障害発生時は通販サイト一時停止が必要。
モデルケースＡ社
次期販売財務システ
ム
107
挿 入
フェーズＩベンダ支援内容
 導入教育支援作業
 ユーザにデータのバックアップや現行システムの停止に関する運用上の重要な事項の決定が漏れないよう
に、専門家として十分な助言を与え指導します。
 特に追加でコストが発生するような場合がありますので、教育方法、対象、期間、場所、使用設備等につい
て明確にし、ユーザと合意を形成する必要があります。
 ユーザ担当者の退職や休職により再教育を求められることがあります。このような場合に備え、どこまでが
受託金額の範囲でどこからが新たなコストとなるかをユーザに理解してもらうことが重要です。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＩにおけるユーザポ
イント
 ユーザ側におけるポイント





どのような導入教育支援が必要であるかを判
断するために、従業員の構成（組織別人員数
）や能力（ＩＴスキル概要）等の情報をベンダに
提供してください。
ユーザは付帯事項（データのバックアップ等）
、特記事項（現行システムの停止）の記載につ
いて十分に理解する必要があります。ベンダ
へ事前に説明を求めてください。
ＩＴに関連する法令等（個人情報保護法）が必
要な場合は、ベンダと協議の上、教育計画を
拡充する必要があります。
バックアップ等システム運用上の知識が不足
している場合、ベンダに相談の上、必要な教
育を実施しましょう。
クライアントＰＣおよびプリンタ等の操作指導
についても、ベンダと相談の上、実施計画を策
定するようにしましょう。
108
 ベンダ側からの要請されるポイント
 ベンダからは教育の準備と講師についてコス
トがかかる旨の説明があるのが一般的です。
その際、初期導入教育について、どこまでが
無償でどこからが有償なのかを事前に合意し
ておく必要があります。
 またシステム稼動後の問合せについても、度
が過ぎると再教育が必要になります。この場
合も、どこまでが問合せで対応可能か、再教
育にかかる費用はどうなっているのかを確認
しておく必要があります。
 教育対象やそのレベルにより効果的な教育内
容は異なります。対象となる社員と現時点で
のITレベルと到達させたいレベルを具体的に
説明する必要があります。（例：現在のレベル
はワープロや表計算ソフトを使用したことが無
いレベル。到達レベルは、日常業務がマニュ
アルを見て一人で行えるレベル。等々）
 対象となる社員の情報以外にも、使用設備は、
教育期間は、どこで実施するのか等、ほとん
どが費用を必要とするものになるので十分に
確認が必要です。
重要事項説明書
フエーズＩサンプ
ル
109
Ｉ 導入教育支援業務契約
重要事項説明書の例
Ｉ 導入教育支援業務契約の重要事項 (2) 具体的作業内容
概要
日程
販売・財務システムにつき、全体像を把握するとともに、各人員
が必要とする具体的な利用法について習得するための導入教
育を実施する。
全体説明：
○○年○月○日○時○○分～○○時○○分
販売システム： ○○年○月○日○時○○分～○○時○○分
財務システム： ○○年○月○日○時○○分～○○時○○分
付帯事項
・Ａ社は、各対象者のコンピュータ利用経験につき、事前にβ社に通知する。
連絡協議会の実施要領及びユーザ・ベンダの責任者、主任担当者
・○○○○年○○月○○日、A社本社にて実施
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
実施場所
全体説明： Ａ社 本社大会議室
販売システム： Ａ社 本社214会議室
財務システム： Ａ社 本社213会議室
特約事項
・導入教育完了後40日以内の問い合わせには、β社が無償で対応する。
・40日経過後については、別途協議する。
実施対象
人員
コンピュータセンター： ２名
販売部： 15名
財務部： 8名
業務完了報告書提出期限：○○○○年○○月○○日
実施方法及
び実施内容
目指すべき
水準
いずれも集合教育で実施。
全体説明は、対象者全員参加とし、新システムの全体像示す。
販売部の対象者は販売システムの、財務部の対象者は財務シ
ステムの説明にも参加する。ここでは、各システムの具体的な
使い方について実例を交えて説明する。
コンピュータセンターの対象者は全日程に参加する。
マニュアルを見ながらシステムの利用ができる程度を目標とす
る。
上記報告書の点検期間： 提出日から１０日間
受託金額（税抜）： ○百万円
損害賠償限度額： ○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
保守・運用支援の
流れと責任
Ｊ 保守業務契約、K 運用支援業務契約
110
 サービスの対象
 保守・運用は、実稼働するシステムに対するサービスの提供ですから、見積・契
約にあたっては、実際のシステムに基づいてサービスが提供されなければなり
ません。
 要件定義書、RFP、プログラム設計書、構築報告書等の文書の管理、メンテナ
ンスの記録など、システムに関する文書の管理について、相互の役割を明確に
します。
ⅰ
要件定義
設計開発
ⅱ
ⅲ
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
準委任
D 外部設計支援業務契約
請負
E ソフトウェア設計・制作業務契約F 構築業務契約
移行・運用
準備
準委任
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
モデルケースＡ社
次期販売・財務システ
ム
フェーズＪでの概況
111
【目的】このフェーズでは、保守に関してユーザとベンダ双方の合意を形成する
ためのＳＬＡおよび保守に関するその他留意事項について、ベンダより
説明を受け、システム運用時の障害発生に対する備えを行います。
 保守に関する合意形成
 電算部門の保守に対する要望は過大なものであり、ベンダから保守の分類について説明が行われた。
 是正保守：引き渡し後、発見された問題を訂正するために行う修正作業
 予防保守：引き渡し後、潜在的な場外が運用障害となる前に発見して是正作業
 適応保守：引き渡し後、変化している環境に順応するため、環境変化に歩調を合わせて行う改良作業
 完全化保守：引き渡し後、潜在的な障害が故障として現れる前に、検出し修正作業
 ユーザの事業と利用目的および必要コストから、是正保守をベースにSLAが策定された。また、ベンダより
サービスの範囲と別途有償となるか範囲が明確化され、保守業務内容の合意がおこなわれた。
 ネットワークや既存システムを含むシステム全体の障害切り分けについては、それぞれのベンダの保守業
務の範囲とともに不具合の調査費用についても明確に取り決めがおこなわれた。
 リモートアクセスでのサポートおよび現地サポートにおける、ユーザデータのアクセス関して、事前承認ルー
ルの策定がベンダより要請され、ユーザ電算部門で策定のうえ、双方で承認されました。

データ復旧に関する留意事項
 ハードウェア故障修理における原則は、導入当初の初期状態であり、データバックアップに関してはユーザ
責任であることと、データ復旧要件については、別途に運用支援契約の締結が必要である。

事前停止の考慮に関する留意事項
 保守のためにシステムの一部、全部に停止が発生します。これら事前停止（定期保守のための計画停止、
障害復旧のための緊急停止）の決定へのユーザ内承認ルールと通知方法の検討がベンダより要請され、
ユーザプロジェクトにて策定された。
モデルケースＡ社
次期販売財務システ
ム
112
挿 入
フェーズＪベンダ支援内容
 SLAに基づく事前合意
 要件定義、設計開発、移行・運用準備を経て、当初の要件定義に対して、様々な修正や変更が加えられて
いる場合があります。ユーザから提供された仕様書、設定等変更報告書だけでなく、実際に稼働するシステ
ムを調査、確認し、現状に適合したSLAに基づく保守業務内容の事前合意が重要です。
 サービスの提供は、SLA（サービスレベル合意書）に基づき、提供方法や対応時間などが具体的に示される
ため、業務や取引の都合で運用方法が変更されれば、SLAに影響を及ぼす場合があります。セキュリティ
や法的規制は、後発的に発生するものですから、どのような場合にSLAの見直しがあるか、ユーザ、ベンダ
ともに十分な事前の想定が必要です。
 保守の打ち切り、バージョンアップ、アップデート
 保守部品やソフトなどがメーカの都合で提供中止になることがあります。その場合の取扱いについても明確
にして、ユーザに説明しておくことが大切です。
 後発的に発生し、かつ、システムに影響を及ぼす、OSのバージョンアップや、セキュリティアップデートなど
の取り扱いについては、事前の合意が必要です。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＪにおけるユーザポ
イント
 ユーザ側におけるポイント





保守業務で交換される故障部品は製造会社
に戻されるのが一般的であるため、個人情報
を含んだハードディスクの取り扱いなどについ
ては、個人情報保護規定と保守業務契約の
関係に留意してください。
個人情報保護、内部統制等の社内規定で、ベ
ンダの保守業務でのデータアクセスに制限が
ある場合は、事前承認のルールを明確化して
おいてください。
SLAに基づく保守業務内容の事前合意が重
要となります。
ネットワークを含むシステム全体の障害切り
分けをベンダへ委託する場合、保守業務の範
囲とともに不具合の調査費用についても明確
に取り決めておく必要があります。
リモートアクセスでのサポート、現地サポート
を問わず、ユーザデータにアクセスする場合
の、事前承認ルールを明確化する必要があり
ます。
113
 ベンダ側からの要請されるポイント
 個人情報や機密情報に関して、ベンダからは
対象範囲を明確にすることを求められます。し
たがって、事前に対象となる情報の範囲を明
確にし、対象となる情報の取り扱いについて
決めておく必要があります。
 また、障害の切り分けをベンダに委託する場
合でも、自社で誰が連絡をするのか障害内容
に応じて決めておく必要があります。したがっ
て、ベンダと協力し障害範囲や対象に応じて
ユーザ側の窓口担当（電算部門担当、各業務
のシステム運用担当など）とベンダ連絡先等
を表などにまとめ関係部署に周知徹底するこ
とが必要です。
 合わせて、ハードウェア引上げやリモート保守
時の承認者、オンサイト保守時の立会い、ソフ
トウェアの入換え手続き、作業完了の確認方
法等についても明確にしておく必要があります。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＫでの概況
114
【目的】このフェーズでは、運用支援に関してユーザとベンダ双方の合意を形成
するためのサービス仕様書およびＳＬＡ合意書を作成し、システム運用
後に想定される問題に対して、ベンダから支援について合意を得ます。
 システム運用に関する支援内容の合意形成
 電算部門は新設であり、またシステムの利用規模に対して２名の脆弱な体制であることから、ベンダの提供
する運用支援に対する期待は大きく、ユーザ経営者は新システムの稼働後に発生するもの全てが支援業
務の対象と考えていた。
 このような過度な期待と誤解の無いよう、ベンダから事業と利用目的とコストおよび電算部門が作成した
SLAにて、支援業務の範囲とどこからが有償となるかを明確にして、ＳＬＡに基づくサービス内容の提供に
関して、事前合意おこなわれた。
 セキュリティ監視サービスとして、不正アクセス検知報告、ログアイカーブ、ログ分析およびセキュリティイ
ンシデント発生時の緊急対応サービス
 サーバ運用支援サービスとして、稼働監視サービス、障害自動通報サービス、サーバ運用問合せサービ
ス
 バックアップデータ復旧支援サービス
 上記サービスに関して、ベンダよりサービス仕様書が作成され、ＳＬＡ合意書とともに、ユーザとベンダにて
合意が行われ、上記運用支援契約が締結された。

既存システムの廃棄
 ユーザは既存システムが産業廃棄物である認識に欠けており、ベンダより紹介を受けた産業廃棄物業者に
電算部門が連絡を取り、リサイクル処理に関する見積およびマニフェストを入手する手順の説明を受けた、
しかしながら、ユーザ社長および取締役経理部長が理解を示さなかったため、ベンダに依頼して、法令の説
明を社長および取締役経理部長に行い、廃棄コストの必要性について理解を得た。
モデルケースＡ社
次期販売財務システ
ム
115
挿 入
フェーズＫベンダ支援内容
 SLAに基づく事前合意
 要件定義、設計開発、移行・運用準備を経て、当初の要件定義に対して、様々な修正や変更が加えられて
いる場合があります。ユーザから提供された仕様書、設定等変更報告書だけでなく、実際に稼働するシステ
ムを調査、確認し、現状に適合したSLAに基づく保守業務内容の事前合意が重要です。
 サービスの提供は、SLA（サービスレベル合意書）に基づき、提供方法や対応時間などが具体的に示される
ため、業務や取引の都合で運用方法が変更されれば、SLAに影響を及ぼす場合があります。セキュリティ
や法的規制は、後発的に発生するものですから、どのような場合にSLAの見直しがあるか、ユーザ、ベンダ
ともに十分な事前の想定が必要です。
 後発的に発生するサポートの打ち切り、バージョンアップ、アップデート
 後発的に発生し、かつ、システムに影響を及ぼす、OSのバージョンアップや、セキュリティアップデートなど
は、パッケージソフトウェア自体のライフサイクルを縮めるケースもあります。これらの取り扱いについては、
事前にケース毎の対処について、ユーザ、ベンダともに十分な事前の想定が必要です。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＫにおけるユーザポ
イント
 ユーザ側におけるポイント
支援業務サービスの具体的内容について、ベ
ンダ側との認識に齟齬がないか十分な確認が
重要です。
 ベンダよりサービス仕様書が作成され、ＳＬＡ
合意書とともに、ユーザとベンダにて合意を行
い、支援業務のサービス提供の具体的内容を
ベンダと取り決めます。

116
 ベンダ側からの要請されるポイント
 ベンダからSLA（サービスレベル合意書）の内
容について説明があり同意を求められます。
この際、理解できない点があれば理解できる
まで説明を求め確認をします。特に各サービ
ス項目のレベルが確認でき誰が判断しても同
じ結果が得られるような内容になっている必
要があります。
＜サービスレベルの例＞
 平日のダウンタイム MAX○時間
 ハードウェア、ソフトウェアの入換えは原則休日
 給与変動項目の入力完了後、○時間で銀行へ
の振込み依頼完了
 月次の締め後、翌日午後に財務諸表出力可能
 サービス時間帯は、平日○時～○時、土曜日
曜祝日○時～○時
117
重要事項説明書
フエーズJ・Kサンプ
ル①
重要事項説明書の記入例
J
項
番
1
保守業務契約の重要事項 (2)ハードウェア保守＜記入例＞
保守サービス名称
業務内容
添付図書名
SLA合
意書
有無
○○○○年
○○月○○日
有り
保守対象機器
明細一覧表
有り
○○○○年
○○月○○日
○○○○年
○○月○○日
無し
保守対象機器
明細一覧表
有り
○○○○年
○○月○○日
○○○○年
○○月○○日
有り
保守対象機器
明細一覧表
有り
開始日
終了日
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
○○○○年
○○月○○日
東京都千代田区
￥○○○,○○○
○○-○○
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
ハードウェア保守サービス 東京都千代田区
￥○○○,○○○
（ネットワーク機器保守） ○○-○○
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
請求方法及
（円／年、税抜） び支払方法
サービス料金
ハードウェア保守サービス 東京都千代田区
￥○○○,○○○
（サーバ保守）
○○-○○
ハードウェア保守サービス
2 （クライアントPC及び周
辺機器保守）
3
遠隔操
作保守
の有無
サービス期間
請求開始
年月日
設置場所
受託金額合計（税抜）
損害賠償限度額：（項番ごとに記載）
付帯事項：（作業実施にあたりユーザが担当する作業）
電源及びハードウェア設置環境の維持・整備については、お客様が実施
するものとします。
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者：戊山取締役
主任担当者：コンピューターセンター 己田課長
・β社責任者：開発部 甲野部長
主任担当者： 開発部 乙山マネージャ
特約条項：
遠隔操作保守の内容：（項番ごとに記載）
項番1：遠隔操作保守はユーザデータへのアクセスを要する場合、原則、
接続毎にお客様の許可を得て実施します。夜間等で緊急の措置が必要な場
合の対応については、SLA合意書で定めます。
項番3：ルーター、ファイアウォールの状態監視は1時間毎とし、異常発生
時は、お客様の事前の許可無く外部接続で、障害範囲及び原因の特定調査、
復旧操作などの1次保守を実施します。遠隔操作保守で対応できない場合
は、SLA合意書に基づきオンサイト保守を実施します。
再委託先の表示：
118
重要事項説明書
フエーズJ・Kサンプ
ル②
重要事項説明書の記入例
J
保守業務契約の重要事項
保守サービス名称
項
業務内容
番
1
アプリケーションソフト
保守サービス
（XX社販売管理システム
保守）
(3)アプリケーションソフト保守＜記入例＞
設置場所
東京都千代田区
○○-○○
サービス料金
（円／年、税抜）
￥○○○,○○○
サービス期間
請求方法及
び支払方法
請求開始
年月日
開始日
終了日
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
○○○○年
○○月○○日
○○○○年
○○月○○日
遠隔操
SLA合意書
作保守 添付図書名
有無
の有無
有り
ｘｘ社販売
管理システ
ム保守仕様
書
有り
2
受託金額合計（税抜）
損害賠償限度額：（項番ごとに記載）
付帯事項：（作業実施にあたりユーザが担当する作業）
遠隔操作保守の内容：（項番ごとに記載）＜例＞
バックアップはお客様が実施するものとし、データ復旧にあたっては、 項番1：遠隔操作保守はユーザデータへのアクセスを要する場合、原則、接続
都度、状況に応じてお客様と協議の上、復旧方法を定めるものとします。毎にお客様の許可を得て、作業内容についてご承認の上、実施します。マスタ
およびデータファイルについては、お客様の責任によるバックアップをお願い
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
申し上げます。夜間及び緊急時の対応については、SLA合意書で定めます。リ
・A社責任者：戊山取締役
モート保守で対応できない場合は、SLA合意書に基づきオンサイト保守を実施
主任担当者：コンピューターセンター 己田課長
します。
・β社責任者：開発部 甲野部長
主任担当者： 開発部 乙山マネージャ
特約条項：
再委託先の表示：
119
重要事項説明書
フエーズJ・Kサンプ
ル③
SLA合意書（記入例）
項
番
保守・運用
サービス名称
SLA/SLM
項目名
項目の説明
1
電話受付時間
2 ハードウェア保守
サービス
（サーバ・ルー
タ：製品名）
3
平均出動時間
サービ
ス提供
時間
平均復旧時間
4
定期点検
5
電話受付時間
6 ハードウェア保守
サービス
（クライアント・
7 プリンタ：製品
名）
出動時間
8
サービ
ス提供
時間 平均復旧時間
定期点検
測定条件又は方法
コールセンターでの電話受付時間
電話を受けてから技術者が現地に到
着するまでの時間（遠隔地は除
く。）
技術者が訪問してからハードウェア
が工場出荷状態に戻るまでの四半期
平均時間
定期点検月に障害が発生し訪問した
ときは、同時に定期点検を行うこと
がある。
コールセンターでの電話受付時間
電話を受けてから技術者が現地に到
着するまでの時間（遠隔地は除
く。）
技術者が訪問してからハードウェア
が工場出荷状態に戻るまでの平均時
間
定期点検月に障害が発生し訪問した
ときは、同時に定期点検を行うこと
があります。
測定単位
目標／
保証
値
時間
目標
平日：9時～19時、
土：9時～17時、日・
祝日：休み
月平均
目標
2時間
四半期平均時間
目標
12時間
回数
保証
年2回
時間
目標
平日：9時～17時、土
日・祝日：休み
四半期平均時間
目標
24時間
四半期平均時間
目標
48時間
回数
保証
なし
保守対象機器
明細項番
120
重要事項説明書
フエーズJ・Kサンプ
ル④
SLA合意書（記入例）
項番
保守・運用
サービス名称
SLA/SLM項
目名
項目の説明
電話受付時間
9
即応率
コールセ
放棄率
ンター
10
測定条件又は方法
コールセンターでの電話受付時間
電話が鳴ってから基準時間内に応答
した率
着信電話に出られなかった率
測定単位
目標／
保証
値
時間
目標
平日：9時～17時、土
日・祝日：休み
月平均
目標
90％以上
月平均
目標
10％未満
月平均
目標
10％未満
月平均
目標
20％未満
年
目標
1回／年
11
電話ビジー率
電話がビジー（話中）でつながらな
かった率
12
コールバック率
即答できずに折り返しをした率
13
バージョンアップサイ
クル
バージョンアップ回数を規定
14
バージョンアップ範囲
当該アプリケーション保守範囲での
バージョンアップ
保証
マイナーバージョン
アップ
バージョンアップ媒体の要求方法
目標
ユーザからのリクエス
ト
目標
3時間以内
15
16
アプリケーショ
ン保守サービス
（製品名）
ライセン 媒体要求
ス保守
着手時間(瑕疵時）
障害の報告を受けてからメーカーに
報告するまでの時間
月平均時間
17
復旧時間
障害報告を受けてから障害が回復す
るまでの時間。（データ復旧は含ま
ない）
18
応答時間
障害報告を受けてから着手するかの
有無を決定し回答するまでの時間
月平均時間
目標
24時間以内
19
カスタマ 復旧時間
イズ保守
障害報告を受けてから障害が回復す
るまでの時間。（データ復旧は含ま
ない）
月平均時間
目標
3営業日以内
障害の報告を受けてから作業を開始
するまでの時間
月平均時間
目標
3時間以内
20
着手時間(瑕疵時）
21
着手時間(追加要望時） 連絡協議会で対応を決定する
メーカーとの保守契約
による
保守対象機器
明細項番
121
重要事項説明書
フエーズJ・Kサンプ
ル⑤
SLA合意書（記入例）
項番
22
保守・運用
サービス名称
SLM
SLA/SLM項
目名
連絡協議
会
23
測定条件又は方法
測定単位
目標／
保証
値
開催サイクル
連絡協議会を開催するサイクルを規
定
四半期単位
回数
目標
1回／四半期
開催時間
1回当りの開催時間
平均時間
目標
2時間以内
参加人数
ユーザとベンダの最大参加人数を規
定
１回平均
目標
ユーザ：5名ベンダ：5
名
SLA報告サイクル
SLA報告書の作成サイクルを規定
四半期
目標
1回／四半期
SLA見直しサイクル
SLAの見直しのサイクルを規定
年
目標
1回／年
承認方法
SLA実績、見直しなどをどの機関で承
認するかを規定
項目の説明
24
25
26
SLA
27
連絡協議会
保守対象機器
明細項番
122
以上で第6章の解説は終了です。
e-ラーニングメニューに戻り、
「第7章 セルフチェック」をご覧ください。