Transcript パッケージソフトウェアの活用と保守・運用を含めた情報システム構築の

ITシステム構築の実際
事例をもとに、
販売管理システムと財務会計システムを刷新する
企業とベンダの契約におけるポイントを解説します。
 和菓子の製造・販売を行なう吾妻屋は創業100年の老舗で
す。全国の有名百貨店に出店しており、従業員150名を抱える
業界の中堅企業として有名です。
 しかし、コンビニエンスストアの台頭によって洋菓子が市場で
は圧倒的なシェアを持っており、和菓子のコアな顧客は高齢化
しています。
 老舗吾妻屋の経営者は四代目で、一昨年、亡くなった三代目
の後を継いで、45歳という若さでバイタリティあふれる経営を目
指しています。四代目の夢は、コンビニエンスストアとの取引の
拡大と、Web通販事業の立ち上げです。先細りを受入れるの
ではなく、健康でヘルシーな和菓子の良さを、若い世代にア
ピールして売上を上げ、借金依存体質からの脱却を目指して
います。
モデルケースＡ社の
概要①
3
 吾妻屋の概要
業 種：
 和菓子の製造・販売・小売業（創業100年）
 規 模
 年商50億円
 従業員150名（内社員50名、パート・アルバイト100名）
 事業内容
 和菓子を本社工場、所沢工場の2拠点で製造
 材料生産協力会社は8社であり、一部、干菓子などの製品仕入を行っている
 全国有名百貨店（28店舗）に売場を出店し直接販売を行っている
 量販店3社に贈答用和菓子詰合せを卸している

 主な資産
 本社店舗・工場（東京都中央区日本橋、土地150坪、ビル7階建て）
 所沢工場（埼玉県所沢市、土地500坪、平屋工場150坪）
モデルケースＡ社
の概要②
4
 吾妻屋のコンピュータシステム（既設）
 生産管理システム
 本社工場と所沢工場で、95年に導入したオフィスコンピュータとパッケージ
ソフトウェアをカスタマイズして利用しています
 販売管理システム
 ITの展示会で見つけたオープン系パッケージに、各百貨店からの売上デー
タ取込み、システムや量販店各社からの受発注システム（専用伝票発行含
む）および物流システムを個別開発し、販売管理パッケージと相互で処理し
たデータを活用しています
 財務会計システム
 会計事務所より紹介されたパッケージに生産管理および販売管理から必要
なデータを取り込み管理会計に利用しています
 人事給与システム
 市販パッケージシステムをノンモディファイ（パッケージ標準）で利用しており、
他システムとのデータ連携等は行っていません
モデルケースＡ社の
概況③
5
 現状の体制
 情報処理部門等の専任部門はありません。
 運用管理は、現場の担当者がITベンダの支援を得ながら実施しています。
 取引先とのオンライン取引などについては、営業担当者が取引先から資料を受
領し、既存ＩＴベンダに検討を依頼していました。打合せが必要な場合は、ベンダ
と取引先に出向き打ち合わせを行ない対応しています。
 システム運用担当体制
 生産管理システム
 本社工場：生産管理部兼務 1名
 所沢工場：同上
 販売管理システム
 百貨店事業部：2名 量販店営業部：1名 物流倉庫：1名
 財務会計システム
 経理部：
2名
 人事給与システム
 人事総務部：
1名
モデルケースＡ社の
次期システム構築
要件定義支援契約に至る経緯
6
 次期システム構築の理由
 現在使用している販売管理システムと財務会計システムのサポートが打ち切りとなるとい
う通知がパッケージソフトベンダからありました。新しいバージョンに切り替えて欲しいとい
う提案です。現在のシステムに大きな不満はありませんが、サポートが打ち切りになるの
では仕方がありません。コンビニとの取引やWeb通販を始めたいこともあり、社長とプロ
ジェクト責任者とし、取締役の脇坂経理部長を補佐にして、次期システム構築の検討を開
始しました。
 次期システム構築に関する経営陣の当初の考え方
 両者ともシステム構築の経験がないため、最初は、取引のあるベンダに相談をしましたが、
提案されたシステムが自社に適合しているかどうかの判断つきませんでした。ERP、Web、
CRM、といった3文字言葉が並ぶ提案書の内容が、良く判らず不安に思ったためです。
 百貨店に出店している企業の親睦会でも、コンピュータシステムの刷新は悩みの種で、い
つも話題に上がります。同じ老舗仲間の山縣屋の社長からは、コンサルをいれて良い結
果が出たと聞いていましたが、コンサルタントを依頼するほどの規模でもなく、最終的には
既存ベンダを含めた複数ベンダから提案を受け、価格性能比が良さそうなものを選べば
良いと考えていました。
 しかし、他のベンダの説明を聞いても、どうも腑に落ちません。先方が話す言葉も良く理解
できず、「ご予算の範囲でしっかりやります」「お任せ下さい」と言われるばかりです。
 次期システム構築プロジェクト体制を構築
 どうも、やり方が間違っていると思い、山縣屋の社長に相談したところ、自分の会社の情
報処理担当者を紹介してくれました。
 ベンダ選定にあたっては、以下の点に注意するようアドバイスを受けました。
①今後、インターネットやオンライン取引が主流となるので、拡張性を重視すること
②Web販売は商圏・顧客を拡大できるよいチャンスであるが、ホームページをこまめに更
新しないと、すぐにお客に飽きられ、売上が落ちてしまうこと
③クレジットカード情報などは個人情報なので法律の規制があること
④オンラインデータの授受にトラブルがあると、コンビニ等からペナルティが請求される事
があり、運用・保守はある程度自社で対応できる体制が必要であること
⑤判りやすく、得心のいく説明をしてくれるベンダを選定すること、判らないことを判らない
ままにせず、決して他人任せにしないこと
⑥オンライン取引をやっている百貨店の担当者は情報も多いことからからアドバイスをう
けること
 そこで、百貨店の情報システム部門を訪ね、いろいろとアドバイスを受けると、ほぼ同様
のアドバイスがあり、かつ、Webやコンビニとの取引を考えているなら専任者を置いた方
が良いとの強い助言を得ました。
8
 情報システムの専任部門を設置
 ITに詳しい専任者とのアドバイスを受けて、専任者の採用を考えましたが、どのようなス
キルが必要か、四代目には今ひとつ判然としません。そこで、業務担当で社内でPCに一
番詳しい下平君を情報システム担当として任命し、新しいコンピュータシステム導入のた
めの情報の収集にあたらせました。
 情報システム担当の下平君は、経理と業務を兼任していたので、管理帳票の不足や、業
務課題はある程度把握しています。社長からの指示は、①コンビニ取引による売上拡大、
②業務のムダを管理する、③Web取引の開始、この3点が最優先との指示を受けていま
す。オンライン取引は従来でもやっていたので、システムの概略は想像つくのですが、
Web取引はまったく初めてでシステム構成や、Webページの作り方などは皆目分かりま
せん。また、業務のムダを管理するといっても、仕入、生産から店舗管理、入金消し込み、
手形管理と課題は幅広く、どこから手を付けて良いか、課題は山積みです。
 既存ベンダの提案
 付き合いのあるベンダの営業の話を聞いたりしてみますが、和菓子や食品業界について
の知識が乏しく、コンビニ取引の経験もあまりないような口ぶりです。改めて、システムの
概要提案を依頼すると、既存のシステムの改造による対応と、Webサイト用のコンテンツ
マネジメントシステムの提案を受けました。社長が要求している②業務のムダを管理す
る、ための管理指標、帳票の提案がないことを指摘すると「レイアウトを頂ければ見積しま
す」との対応で、積極的な提案がありません。概算予算は、社長から提示された予算を大
幅に超えるものでした。
9
 他のベンダの提案
 たまたま、ITの展示会の招待状をもらったことから、展示会に出かけ、いくつかのベンダと
名刺交換をしました。その中の1社からアプローチがあり、概要を伝え提案を依頼しました
が、コンビニ取引の実績はありません。ただし、Web通販サイトの構築は非常に詳しい説明
で、およその予算や、システム構築状のポイントは参考になりました。予め予想していたと
おり、コンテンツの更新が重要であること、生産－在庫更新のタイミングに気を付けないと
機会損失が発生することなどです。とはいえ、このベンダに吾妻屋のシステムをすべてを任
すことは難しい状況です。
 コンサルタントの紹介
 下平君の窮状を見かねた脇坂経理部長が顧問税理士の木下先生に相談したところ、洋菓
子メーカーの情報システム部門のOBで、食品業界向けにIT化のコンサルティングをやって
いる人を紹介してくれるとのことです。早速、社長の許可をとって紹介を依頼しました。
 税理士の木下先生がコンサルタントの安達さんを紹介してくれたのは、コンビニ取引の開
始と目される新年度まであと7ヶ月という時期でした。木下先生は、社長、脇坂部長、下平
君に安達さんを紹介しつつ、顧問税理士の立場から吾妻屋のIT化の狙いについて、資金
繰りと在庫の明確化につながるような工夫をするように指摘されました。年度末から夏の賞
与支給時期までの資金繰りについては、社長同様、木下先生も心配していたのです。
 一方で、木下先生は下平君に次の言葉を残して帰られました。「売上拡大は資金需要と表
裏一体だ。バランスを考えた投資と売上計画を立てられるようになりなさい。」
モデルケースＡ社の
次期システム構築
要件定義支援契約に至る経緯
10
 外部コンサルによる要件定義支援
 経営陣はコンサルタントの提案を受け、要件定義に関する支援契約を締結し、中期システ
ム化計画からRFP作成までを、具体的に推進することとなった。
 契約内容は、システム導入を通して実現したい事の明確化、大まかな全体計画の策定、
その上で、経営課題及び業務課題の整理、改善（案）の策定、IT化の範囲の決定、パッ
ケージソフトウェアの最終候補の決定、RFPの作成を行うものである。
11
 コンサルタント安達氏の提案
 安達氏は、新規システムの稼働時期を新年度としたい社長に対して、システム化の範囲




や複雑さが決まっていない段階で、時期だけを確定するのは危険だとして、次の3つの
フェーズを提示しました。
①現行業務の課題を抽出する
今の業務の問題点や課題を分析し、作業手順の改善点やシステム化によって合理化でき
る課題を洗い出す
コンビニ取引の具体的な規模、システム化の詳細な仕様を明らかにする
②改善方法を決める
改善点、課題に対して、コンピュータ化すべきものと、人の手順を変更して改善すべきもの
を分け、それぞれ、費用対効果と改善に至る期間を検討する
規模からしてすべてを手作りとせず、既製のパッケージソフトを検討し、場合によってはソ
フトに業務をあわせることも検討する
③優先順位を決め、新しい業務スタイルを従業員全員で検討する
コンピュータ化には時間のかかるものもあることから、着手の優先順位を明らかにし、そ
れに伴い業務手順や仕事の変更について、全従業員と検討する
その上で、パッケージソフトに不足する部分の作り込み、データの移行、稼働テスト、従業
員の教育など、必要な要件を定め、複数のコンピュータベンダから見積を取得し、システ
ムを構築するベンダを選定する
12
 提案に対する社長の決断
 四代目は、安達氏の経歴と、フェーズごとにやるべき事を明確にするスタイルが気に入
り、およその費用を確認した上で、すぐに契約をしたいとその場で言い出しました。安達氏
の提案は理屈としては納得いくのですが、最終的に出来上がったシステムを運用する立
場の下平君は、フェーズ毎の作業の確認や、レポートについてどのようになるのか不安で
す。
 下平君の不安を察したのか安達氏は、まだ詳細については今後細かな詰めが必要です
が、と断った上で、「経済産業省がコンピュータシステムの構築のためのモデル契約書を
策定しています。このモデル契約書は、コンサルタントやベンダとユーザの、お互いの役
割を明確にした上で、相互の責任者を定める、進捗報告のための連絡協議会を定期開催
する、報告書の提出期限、費用などを定める形式になっています。」
 「お互いの役割を明確にするというのは、どういう意味ですか？」思わず下平君が質問し
ました。
 「プログラムの作成に入ってしまえば、ベンダがすべて請け負うことができますが、業務の
内容を分析したり、実際に業務の手順を変更するということになると私たちコンサルだけ
では作業が進みません。皆さんに資料を作ってもらったり、ご判断頂くことがたくさん出て
きます。もちろん、資料作成のためのフォームや、データの分析方法はご提案しますし、お
手伝いもします。しかし、最終的にシステムを使うのは皆さんですから、すべてを他人任せ
にせず、自分の業務をどのように改善するかを一緒に考えて頂きたいのです。」
13
 経理部長の不安
 「改善しなければならないと考えているポイントはたくさんあります。でも、私たちは業務分
析やシステム構築の経験がありません。実際にできるのでしょうか？」社長の顔色を伺い
ながらも経理部長も思わず口を挟みます。
 「皆さんのご自宅の洗面所を思い浮かべてみて下さい。同じ洗面所でも人それぞれに要
求する内容が異なります。例えば若い女性ならシャンプーをしやすいようにシャワー栓を
望むでしょうし、男性ならばそんなことより拡大鏡と電気カミソリの電源コンセントが欲し
い。私ならば、カミソリでひげを剃るので、何よりも熱いお湯が出て欲しいですね。洗面所
といっても、当事者の要求はこれほど異なります。同様に、企業の情報システムは使う人
の立場によって欲しい機能が異なってきます。それを私たちコンサルタントやコンピュータ
ベンダが一律にお仕着せを提案するのは危険なことがあるのです。」
 「でも、うちの財務会計ソフトはパッケージをそのまま使っていますよ。そういうものではな
いのですか？」
 「部長さんのご指摘はよく分かります。確かに企業財務というのはパッケージソフトウェア
を導入することで大半の企業は満足できると言えるでしょう。しかし、生産管理や販売管
理はどうでしょう。吾妻屋さんの業務のやり方と、他の和菓子屋さんはみんな同じです
か？デパートに出ていれば受注があって生産、そして配送があり、委託在庫となる。自社
店舗だけなら見込みを生産して在庫だけです。同じ商品を作っていても業務の内容は大
きく異なります。」
14
 吾妻屋全員の納得
 「つまり、吾妻屋の業態をはっきりさせて、それに合ったソフトウェアを作るということです






か？」
「いえ、それだけではありません。業態をはっきりさせて、改善すべき所をご一緒に考え
る。その上で、お金のかかることですから、コンピュータ化して費用対効果が見合うところ
はパッケージソフトを選んでコンピュータ化する、一方で人手の作業を改善した方が確実
だったり、安い場合は人手の作業を直します。ベースとなるパッケージソフトウェアは、カ
スタマイズやアドオンを最小限にするようにしたいと考えています。」
「人手の作業は大幅に変わることもあるのでしょうか？」
「それはこれから分析してみないと判りません。場合によっては、ソフトウェアに仕事のや
り方をあわせてもらうこともあります。」
「仕事をソフトにあわせるのですか？」
「吾妻屋さんのように老舗の仕事というのは、それなりに歴史があって合理性がある部分
がたくさんあると思います。大切な職人の仕事を変えろと言うのではありません。業務の
ムリ・ムラ・ムダを排除するために、皆さんにとって一番仕事のやりやすいソフトを選べば
問題は起こりません。従業員の皆さんと新しい業務手順を考え、システムを創るのです。」
最後の言葉に社長以下、みんなが納得したのは言うまでもありません。
15
 作業はここまでです。
 以下を「ですます」に変更しなければなりません
 およそですが、延べ4日くらいの作業ではないでしょうか？
モデルケースＡ社
次期販売財務システム
16
フェーズＡコンサル支援内
容①
 企画におけるコンサルタントの支援業務の内容
 ユーザの経営課題や現状業務とその課題などを整理するために、会社概要、事業内容、取引
先と取引形態、商品（製品）分類、組織とその機能に関する情報を把握し整理を実施した。併
せて、現行の業務で使用される定型・非定型の資料収集、現行システムに関する資料収集、
およそのデータの流れの聴き取りを行った。
 さらに、組織のキーとなる経営者・組織（管理者と社員）を検討し、インタビューの実施計画をま
とめユーザの承認を受け実施した。最初のインタビューの視点は、現状の組織の実態（運営・
管理）の把握である。
 経営陣のインタビューでは、以下の現状認識が明らかになった
 ①老舗であり製品品質の維持は絶対である、②仕入先は零細が多くコスト圧縮は仕入先
の経営に大きな影響を与える、③そのため内部経費の全般の見直しを優先したい、④和
菓子は全体に顧客が高齢化している、⑤若年層へのブランド定着を狙ったコンビニ取引
が具体化しており受注・生産体制の見直しが急務である、⑥オンライン取引でのシステム
の信頼性が重要であること、⑦決算に時間がかかっており短縮したいこと、⑧決算後は売
上は閑散期となり、納税、ボーナス資金需要から借入が発生するため内部留保を高める
意味でも利益確保が重要である、⑩贈答品が先細り傾向にあることから、新規需要の開
拓が重要であり、顧客のニーズが分析できるシステムが欲しい、⑪現状規模であれば、
管理帳票などはなくても十分に回っていくが、先細りが不安である、⑫主立った資産はな
いため借入余力は乏しい
モデルケースＡ社
次期販売財務システム
17
フェーズＡコンサル支援内
容②
 現場のインタビューからは、以下の現状認識が明らかになった
 ①季節に応じた少量多品種で、昔ながらの丁寧な仕事が老舗の誇りである、②近
年、量販店向け詰め合わせの受注から出荷までの時間が短縮されており困惑してい
る、③見込みで仕込みをせざるを得なく残業が増え、ロスが発生している、経営陣は
改善を指摘するが具体的な方策を示してくれない、④百貨店は主力売れ筋だけは安
定した売上を見込めるが、季節商品は売上が落ち込んでいる、⑤地方百貨店は繁忙
期と閑散期の差が大きく赤字の月もあり、ならすと収支トントンであると思われる、⑥
繁忙期の欠品がクレームとなっている、⑦このような現状でコンビニ取引が加わるこ
とは大いに不安である、⑧仕入先は長年の付き合いで品質もしっかりしているが、一
方で高齢化問題を抱えているため、コンピュータ化などはとうていムリである、⑨コン
ピュータ化は時代の流れであろうが、職人や顧客とのつながりはコンピュータではで
きないであろう、⑩Web販売で若い人が和菓子に関心を持ってくれることには興味が
あるが、配送などでトラブルが起きるのではないかと心配である、⑪百貨店は違算が
大きく経理処理に手間がかかっている、⑫違算は現場の検品ミスや試食分が計上さ
れていないためだが、そもそも人手不足が解消されればこのようなことは起きない、
⑬百貨店は営業時間が長く早番、遅番で社員、パート混成で対応している、⑭工場
は2カ所だが、規模も小さく販売、生産ともに意思の疎通はとれている
モデルケースＡ社
次期販売財務システム
18
フェーズＡコンサル支援内
容③
 現状認識に対する分析
 労使ともに、仕入先の経営と品質維持に腐心しているが、生産性の向上という視点
がなく、具体的な方法論も欠如している
 経営陣は内部コストに問題意識があるものの、実際の課題を把握しておらず、指示
も具体的でない、資産が乏しく借入余力が少ないことから、売上拡大を志向してい
る
 従業員は量販店ビジネス、百貨店ビジネスの課題を感じているが、原因を単純な
人手不足と捉えている、新規ビジネスに対しては懐疑的である
 およそのデータの流れ
 百貨店店舗は、在庫がすべて預かり在庫のため、店舗ごとに商品別売上集計表を
手書きで作成しFAXで送信し、翌日、本社で販売管理システムに入力している
 販売管理システム入力後、財務管理システムに店舗別売上合計を入力している
 百貨店POSデータを受領後、販売管理で付け合わせをし、違算発生の場合は、取
引先に応じて伝票取り消し後、再入力（差異はサンプル扱いで処理）、又は請求時
に値引き処理で対応している
 工場は、仕入、仕掛、出荷の日計を毎日17時に締め、18時に本社にFAXで送信
し、翌日、本社で財務管理システムに入力している
モデルケースＡ社
次期販売財務システム
19
フェーズＡコンサル支援内
容④
 現状分析から課題を抽出した
 違算処理が取引先ごとに異なっているが、違算の本来の原因は
①出荷検品ミス、②輸送時毀損、③受入検品ミス、④試食サンプル消
費、⑤日計表の集計ミス、⑥販売管理システムへの入力ミス、のいずれ
かであり、現状の処理は単なる請求金額のつじつま合わせでしかない
 会計仕分処理上問題があり、放置すべき問題ではない
 改善可能な人為的ミスが原因か、商慣習上やむを得ないものなのかを明
確にしてIT化の対象とすべきか検討する
 地方百貨店はならす収支とんとん、とのことであるが、店舗別の損益、
商品別の損益の把握ができていない
 経営陣は内部コスト削減を要求しているが、そもそもコスト分析の仕組みが
ないため、たまたま黒字なだけと言うべき状況にある
 かかる状況でコンビニ取引をした場合、規模が拡大するため、万一、赤字と
なると被害が拡大する恐れがある
 店舗別、商品別の損益分析が可能か、有効かを検討する
20
モデルケースＡ社
次期販売財務システム
フェーズＡコンサル支援内容②
 経営者が認識していない経営課題・業務課題
 業界動向、競合先、法的規制などについて確認する必要があ
ります。例えば、取扱商品に関わるWeb販売環境は現在どう
なっているか、規制や法律は無いか、コンビニでの販売を予定
している商品のポジションやライフサイクル（製品寿命）、競合
メーカーの状況などです。
 ユーザの常識とベンダの常識
 双方の常識は異なることもあるので、必ず具体的な内容を確
認する必要があります。例えば、言葉が同じでも業務内容や
計算方法などが異なる場合があるので注意が必要です。また
これらの認識を、後の工程を担当するベンダにも的確に伝え
るようにしなければなりません。
 取引条件の把握
 ユーザの取引先の取引条件を確認する必要があります。この
場合では、百貨店やコンビニとの間で行うEDI等の取引に関
わるルール及び制限やペナルティ、使用する専用伝票、戻入
や値引の扱いなどがあります。特に、百貨店との取引では、百
貨店に開設した店舗における一日の売上が百貨店側に入金
され、あらかじめ決められた締め日に経費を引いた残額が精
算される等、百貨店側の独自のルールにあわせた業務要件
の策定が必要となる場合があります。
 商品特性と計上基準
 例えば、鮮度管理が必要なもの、季節性のあるもの、冷蔵
保存や倉庫環境が特殊なもの、売買単位、物流単位、在庫
管理単位、ロスの発生、歩留りなどが上げられます。また、
倉庫を借りている場合は、入出庫の費用や借入期間、倉庫
の課金の単位、輸送費用なども把握します。
 売上、仕入、在庫、戻入、廃棄の計上基準、入金や支払の
形態は商品特性と密接な関係にあります。計上基準規則が
ない場合には、基準の策定を求め、基準に則ったシステムを
検討しなければなりません。戻入で在庫が増える商品（機
械・工具等）、戻入で破棄となる商品（生鮮食品等）では、同
じ戻入でもデータの性質が変わってきます。
 物流
 百貨店と量販店しかなかった取引先に加えて、新たにコンビ
ニへの展開も検討している場合、多品種少量出荷への対応
や一日数回の出荷など、受注・物流機能をはじめとして構築
するシステムへの影響も考慮が必要となります。自社物流だ
けだった場合、指定物流業者への納入などでは、独特の
ルールがある場合があります。
モデルケースＡ社
次期販売財務システム
21
フェーズＡコンサル支援内
容③
 Web通販と在庫
 新たにネット通販を展開するような場合、Webサーバ上の在
 中長期計画
 将来の事業展開の内容を確認する必要があります。例え
庫データと、販売管理システムの在庫データとの連動が必須
ば将来、原価管理の精度を上げるために生産管理シス
となります。
テムをレベルアップし個別原価計算を行う予定がある場
合など、現状不足している必要なデータは何か、それら
 特に在庫連動ではパッケージソフトウェアでの在庫交信の結
が必要となるタイミングはいつでどのように確保する予定
果をWEBサーバ上の在庫データにリアルタイムで反映するの
かといった点を確認しておく必要があります。
か、あるいはWEBサーバ上には在庫データを持たずにパッ
ケージソフトウェアの在庫情報を参照させることは可能か、と
 現行システムの重要部分の確認
いった部分の確認が重要となります。
 例えば、現行システムで個別開発した「専用伝票対応を
 Web通販では、ユーザが24時間利用できることから、夕方か
含む各百貨店や量販店との受発注システム」や「物流シ
ら夜間の利用が急増する場合がありますが、在庫の更新を午
ステム」を、新たに構築するシステムでも利用しようと考
前中に設定すると機会損失を起こす場合があります。一方で、
えている場合などは、現行システムでパッケージ部分と
夜間にシステムのメンテナンスやバックアップを取るといった
のインタフェースが、どのように実現されているかの確認
運用上の制限が加わることもあります。
などが必要になります。特にパッケージソフトウェアと密
 このように、Web通販はあらたなバーチャルな店舗を出店する
結合している場合などは、この後、選定されるパッケージ
というだけでなく、システムの運用に大きな影響を与えます。
ソフトウェアとの連携が困難であったり、または現行シス
データベースが分散する場合、十分なビジネスケースの検討
テムの個別開発部分に変更が必要となる等が考えられ
ます。
をもとに、在庫の補充、引き落としのタイミングを決定しなけれ
ばならず、また、機会損失削減の観点からは、生産管理との
連動も十分に検討しなければなりません。
モデルケースＡ社
次期販売財務システ
ム
フェーズＡコンサル
支援内容②
22
 ベンダは整理された経営課題、業務課題をもとに業務改善提案をまとめ、
新しい業務モデル全体像と情報システム全体像、それに必要な組織や体
制、予算などがユーザに理解できるように報告します。また、改善の優先順
位や改善による効果についても具体的に示す必要があります。ベンダは以
下の点に注意して報告を実施します。
 一般的に用いるフロー図などの資料は、ユーザが理解しているかを確認しなが
ら、詳しく説明する必要があります。
 予算の前提となる開発、運用、保守の方針を具体的に説明する必要がありま
す。
 期待効果は、システム要件に重大が関連があるため、具体的かつ明確にし、
ユーザが正しい投資の決断を行えるように配慮します。
①優先順位を明確に示す
②費用及び納期を例示する
③機能同士の関連や人的処理との関わりを分かりやすく例示する
④既存システムの改修や人的処理の変更を具体的に例示する
モデルケースＡ社
次期販売財務システ
ム
フェーズＡコンサル
支援内容③
23
 業務要件定義（機能要件、非機能要件、セキュリティを含む）
 ベンダは承認された新しい業務モデル全体像と情報システム全体像を
もとに、業務要件定義を行います。
 ベンダはシステム化の目的をもとに、システム化の範囲や対象を明確
にします。
 ベンダは明確になったシステム化範囲についての入出力やその画面遷
移を明確にします。
例えば、受注画面、管理帳票、コンビニとの取引で必要となる専用伝
票、 Web通販で顧客が注文に使う画面、クレジット決済の管理画面、
注文内容の管理帳票など、すべての画面および帳票を具体的に挙げ、
それらの遷移や関連、使用されるタイミング、前提条件などを明確にす
る必要があります。
モデルケースＡ社
次期販売財務システ
ム
フェーズＡコンサル
支援内容④
要件定義における
入出力についての注意点 1
24
 ピーク時のトランザクション処理数と処理時間はどの程度か。
 例えば、新たにコンビニと取引を開始するようなケースでは、出荷が日に数回あ
るケースもありトランザクション数が急増します。それによりデータの送受信時
間、処理時間、出力時間などが影響を受けます。
 商品別市場規模の想定・検証と拡張性の確保
 Web販売では対象が不特定のため受注量が予測しにくいという特性がありま
す。商品特性から市場規模、受注特性（時刻、月次、年次のピークの変化）を想
定し、最大受注処理量の上限は余裕をもって想定しておく必要があります。実
稼動後、想定と実際の受注特性を検証できるようにしておき、合理的かつ計画
的なシステム拡張ができる配慮が求められます。
 システム使用年数とその間に拡大するデータ量とデータ処理時間はどの程
度か
 取引先件数の伸びや取扱商品（製品）件数の増加、店舗や工場などの在庫場
所の拡大など、管理する対象によっては相乗的にデータが増加する場合があり
ます。
モデルケースＡ社
次期販売財務システ
ム
フェーズＡコンサル
支援内容⑤
要件定義における
入出力についての注意点 2
25
 利用タイミングと出力可能なタイミングに相違は無いか
 バックアップなどの日常的な運用処理に加えて、繁忙期、月次処理、年次処理を
含めて検討します。
 クリティカルな処理のレスポンスや応答スピードに問題は無いか
 例えば、顧客が直接Webサーバに直接アクセスするネット通販の画面レスポンス
や、パッケージソフトウェアで管理している月末の在庫更新時間、出荷指示データ
の作成時間などを検討します。
 通常業務に影響を与えないバックアップ、復旧を考慮したタイムスケジュール
 前日までのデータを復旧するか、定めた時刻、もしくは、直前の取引までを復旧す
るかによって、システムの構成は大きく変わります。
 誤入力に対応するためのロールバックや世代管理、取引履歴の分析など管理
データの必要性を含めて、データのバックアップを検討します。
 インタフェースに人手が入る場合のリスクやミスがあった場合のリトライ方法
 データの誤入力、操作ミスによる一括更新などで、データ復旧が不可能、もしくは
再入力などで多大な費用がかかる、一定期間システムの機能が失われる、等の
人為的なリスクを検討し排除しておきます。
モデルケースＡ社
次期販売管理システ
ム
フェーズＡコンサル支援内容
④
 入出力についての注意点 3
要件定義における
入出力についての注意点 1
26
 ベンダは以上のような主機能についてセキュリティ要件を明確にします。この場合、セキュリティレベルとセキュリティ対策コストはトレードオフの
関係にあるので、業務要件に最適なセキュリティレベルを提案します。特に、ネット通販などインターネット上で動作するシステムの場合、ハッ
カー等の攻撃も年々高度化しており、攻撃パターンとその対策、及びそのコストを明確にし、ユーザが採るべき対策やWEBサーバ上におくデー
タの範囲を明確にして、ユーザがリスクを判断できるようにしておく必要があります。
 ベンダは以上のような主機能を提供するためのハードウェア、ソフトウェア、物理的環境や設備、ネットワーク
環境などを検討します。要件定義を支援するベンダは、この後の開発・構築・運用・保守についても具体的な
プロジェクト体制や社内体制、委託先を検討し提案する必要があります。また、新情報システムの前提となる
ＯＳやＯＡソフトウェアのバージョンを明確にし、現行のものからのバージョンアップが必要な場合は、そのコ
ストも明確にする必要があります。
モデルケースＡ社
次期販売財務システム
フェーズＡでの概況
【目的】このフェーズでは、システム導入を通して実現したい事を明確にします。
システム構築のための基本方針を定め、事業要件定義、業務要件定義
を策定し、パッケージソフトウェアの最終候補を決定します。
27
 企画（業務の新全体像、業務モデル、システム方式、付帯機能の方針、サービスレ
ベルと品質に対する方針の策定）
 経営課題
 決算後、季節要因で売上の落ち込みがあり、かつ、納税、賞与支払が重なるため運転資金の借
入があり、正確かつ迅速な決算処理体制の整備が急務
 次年度より新規取引を開始するコンビニとの事業に対応できるITを含む体制の整備が必須
 ヒット商品がありながら、インターネット通販等に未着手であることから、ITを含む体制を強化・整
備し、機会損失を最小限にする必要
 個別事業・業務の課題
 百貨店事業の課題：
百貨店に納品した商品は預け在庫として管理を行う必要があるが、繁忙期には人手不足から毀損ロスや試食品
の処理が正しくなされない事が度々発生している
結果として、百貨店POSからの売上データと手元管理している日報（売上数量）の差異が発生し、経理部門での
処理負担の増大を招いている
売れ筋商品の生産見込みの精度低下を招き機会損失、ロスの増大によって事業利益が圧迫されている
 量販店事業の課題：
返品受入処理がずさんなため、量販店からオンラインで送られてくる支払案内データと、自社の売上データとの差
異が発生しており、また売上・返品の月ズレも発生し、期間損益管理が正しく掴めていない
 財務会計の課題：
個別事業の課題から、期末最終月の売上の月ズレおよび実在在庫が正しく把握できず、在庫の評価損の精度が
低く、決算の正確性が危ぶまれている
このため、納税、資金繰りに多大な影響を及ぼしている可能性がある
モデルケースＡ社
次期販売財務システム
フェーズＡでの概況
28
【目的】このフェーズでは、システム導入を通して実現したい事を明確にします。
システム構築のための基本方針を定め、事業要件定義、業務要件定義を策定し、
パッケージソフトウェアの最終候補を決定します。
 企画（業務の新全体像、業務モデル、システム方式、付帯機能の方針、サービスレベルと品質
に対する方針の策定）

新全体像及び業務モデル
 1st Step
販売管理システム、財務管理システムを新年度までに刷新、稼働する







事業部門別損益管理を実施する
棚卸し差異、期ズレに対応するため、生産、倉庫、配送、店舗での商品受払管理を強化する
日報、週報体制および店舗からの伝票配送→集中入力を改め、すべてを発生時点入力とする
伝票単位での管理を改め、受払ともにすべて行明細管理とする
ハンディ端末等での入力作業の軽減、省力化を図る
仕分け、ハンディ端末用摘要辞書を整備し、売れ筋・死に筋・品切れ・返品・毀損事由等の現場情報の入力を促し、
売れ筋の把握と戻入原因を明確化することで、見込生産の精度を向上させる
違算の原因となるずさんな管理体制を改め、販売管理規定、受払管理規定を策定、定期的な従業員教育を実施し、
運用精度を向上し、運用によって発生するデータ品質の低下、テータの不整合発生を低減する
 2nd Step
販売管理システム、財務管理システム稼働後、生産管理と人事給与の レベルアップを検討する

要求品質
 新全体像及び業務モデルを実現し、売上が30%向上しても対応可能な処理速度の実現
 繁忙期現場での使用に耐えうる操作性であること

未決事項
 通販事業等で個人情報を取扱うことは事は理解していたが、セキュリティに関する仕様は示せていない。
 電算部門は新設部門で自社のビジネスモデルを整理した経験もなく、業務の全体像が明確に把握できていない。
29
モデルケースＡ社
次期システム全体像
全体システム体系図
30
 パッケージソフトウェア候補選定支援（使用許諾契約、保守
性、業務要件に対する機能適合評価）
ベンダは業務要件の定義に基づき、市場で該当するパッケージソフトウェア
を候補として取り上げます。この場合、一般的にカスタマイズに関わる開発
は、パッケージソフトウェアのメーカーもしくはそのメーカーが推奨するベン
ダが担当します。これは、これらのベンダ等がパッケージソフトウェアの仕
様の詳細を把握している為です。したがって要件定義を支援するベンダは、
これらの候補となるパッケージソフトウェアの開発以降を担当するベンダか
らのカスタマイズ部分を含む提案書に基づき、比較表の作成を行います。
比較表ではパッケージソフトウェアの機能範囲とコスト、カスタマイズ時のソ
フトウェアの保守性や使用許諾契約の制限及び著作権、パッケージソフト
ウェアとカスタマイズ部分の連携の容易さ、無償保守の範囲と有償保守の
費用、セキュリティ機能のレベル、不足機能、ベンダの支援体制などがわか
るように報告をまとめユーザに説明します。特に不足機能の影響やセキュ
リティ機能のリスクについてはユーザに十分に理解してもらいます。
モデルケースＡ社
次期販売管理システ
ム
フェーズＡユーザ側のポイン
ト
 企画段階
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。
31
 コンサルより報告された経営課題、業務課題に対する改善（案）提案に対して、それぞれの業務に係る社員
の評価を通して、最終的に経営者（プロジェクトオーナ）が実施の判断を行いましょう。
 ソフトウェアを企画するにあたって、システム化する業務の明確化と業務をＩＴ化する全体像を作成します。
 費用対効果、開発期間・体制、経営の要求との整合性をはかる必要があります。
 多くの要件を盛り込むと膨大な費用と時間がかかりますので、ＩＴ化することにより業務の効率化が進むかを検討して要件の取
捨取得を行いましょう。

業務要件定義段階
 機能要件だけでなく、セキュリティ要件などの直接業務に関わらない要件の定義を行います。操作画面や処
理の流れも想定してベンダーに伝え業務の流れシステムの動きを決めましょう。
 ここで決定した内容がRFP（提案依頼書、見積依頼書）になります。RFPが不十分ですと、設計開発段階で
悪影響が出ますので、要求事項はすべてベンダに伝えましょう。
 業界の特性などが伴う業務について、コンサルが十分に理解をしているかを確認するために説明を求め、不
十分であれば理解に必要な資料やインタビューの機会などを提供するようにしましょう。
 ユーザはベンダに対して、システム及び業務を実現するために必要な、開発、移行、運用、保守、教育など
の方針と個別業務の報告（案）を作成させ、十分な検討を行った上で、承認するようにしましょう。
 ここでは、報告（案）の個別業務とシステム化の方針の整合が取れていることを確認した上で、それぞれの業
務に係る社員に、現実の運用段階において業務に支障をきたさないか等を評価させ、経営者（プロジェクト
オーナ）は承認を行うようにしましょう。
 パッケージソフトウェア候補の選定段階
 ベンダが作成したパッケージソフトウェア候補の比較について、十分に理解した上で、総合評価をもとに、自
ら最終的な候補の選択を行わなければならない。
重要事項説明書
フエーズＡサンプ
ル①
A
A 要件定義支援及びパッケージソフトウェア候補選定支32
援業務契約 （パッケージカスタマイズモデルの場合）の
重要事項の例
要件定義支援及びパッケージソフトウェア候補選定支援業務契約（カスタマイズモデル）の重要事項
作業項目
■企画（業務の新全体像、業務モデル、システム方式、付帯機能の方針、サービ
スレベルと品質に対する方針の策定支援）
現行業務フロー及び情報システムモデルの作成
個別業務問題及び情報システムの問題ヒヤリング
経営戦略ヒヤリング
業務間連携及び情報システムの課題抽出
(2)具体的作業内容
作業内容及び作業実施担当
ユーザ
ベンダ
情報システム部門資料（帳票、
伝票、管理諸表、システムフ
ロー、機器構成等）の提出、 現行業務・情報システムの調
報告書(案)のご承認
査、インタビューの実施計画
実施計画のご承認、各部門担
当者、管理職、経営者インタ
ビュー日程ご調整と報告書
(案)のご承認
の策定、実施、報告書(案)の
取りまとめ
報告書(案)の社内評価と経営
者ご承認
課題抽出、テーマ、モデル案
の取りまとめと報告書(案)作
成
情報システム中期開発計画策定
経営戦略、経営課題、情報システム全体像、優先順位、整備計画、開発・運
用・保守方針、予算
中期開発計画書(案)の社内評
価と経営者ご承認
中期開発計画の策定と計画書
(案)の作成
今次業務の新全体像の策定
経営戦略、経営課題、業務モデル全体像、情報システム全体像、期待効果、優
先順位、影響を受ける業務・人的体制、開発・運用・保守方針、予算
業務の新全体像報告書(案)の
社内評価、経営者ご承認
業務の新全体像の策定と報告
書(案)の作成
情報システム開発テーマ・業務モデル案の策定
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
重要事項説明書
フエーズＡサンプ
ル②
A 要件定義支援及びパッケージソフトウェア候補選定支33
援業務契約 （パッケージカスタマイズモデルの場合）の
重要事項の例
作業項目
■業務要件定義（機能要件、非機能要件、セキュリティを含む）
業務システム個別計画書の策定
システム化目的・目標、システム化範囲・対象、主機能（入出力、画面遷移）、
応答性能（ピーク時、平常時）、データモデル、業務フロー、情報処理フロー、
既存システムインターフェース、人的インターフェース、セキュリティ要件、開
発方針、移行方針、運用方針、保守方針（復旧等を含む）、教育方針、採用可能
なテクノロジ、ハード、ソフトウェア、ネットワーク構成方針及び概略構成、設
備・建物概略構成、開発スケジュール、プロジェクト推進概略設計（開発管理、
品質管理、組織管理、費用管理、アウトソーシング管理）、法規制・内部統制等
制限事項一覧
セキュリティ仕様の策定
作業内容及び作業実施担当
ユーザ
ベンダ
各部門ご担当者、管理職、経
営者における、業務システム
個別計画書の評価及びご承認
今次開発する業務システムの
個別計画の策定及び報告書
(案)の作成
セキュリティ仕様書(案)の評
価及びご承認
セキュリティ仕様の策定及び
報告書（案）の作成
計画書に基づくRFI（適合パッケージ、ハードウェア・ネットワーク構成、開発方 RFI(案）のご承認とRFIの配布、RFI(案)作成、RFI対象ベンダ
ベンダ提案書の取りまとめ
候補案作成
式等の提案要求）の作成と配布
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
作業項目
■パッケージソフトウェア候補の選定支援（使用許諾契約、保守性、業務要件に対す
る機能適合評価、SaaS/ASPにおいてはSLAの評価を含みます）
作業内容及び作業実施担当
ユーザ
ベンダ
ベンダ提案書に基づく比較表の作成
使用許諾契約書（制限事項、カスタマイズ成果物著作権等）
保守（費用、期間、カスタマイズ成果物等）
機能適合評価（主機能、不足機能、性能、セキュリティ、運用及び保守性）
価格及び総合評価
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
比較表(案)ご承認
業務要件定義並びにパッケー 比較表(案)作成
ジ候補選定報告書の評価及び 業務要件定義並びにパッケー
ご承認
ジ候補選定報告書案作成
重要事項説明書
フエーズＡサンプ
ル③
A 要件定義支援及びパッケージソフトウェア候補選定支34
援業務契約 （パッケージカスタマイズモデルの場合）の
重要事項の例
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・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日付け見積の通り）
損害賠償限度額：
支払期限：○○○○年○○月○○日
支払方法：口座振込
モデルケースＡ社
次期財務会計システ
ム
フェーズＢでの概況
【目的】このフェーズでは、要件定義に基づきパッケージ候補を評価し、パッケ
ージの決定を行うフェーズですが、機能要件の明確化が十分で無く、
また、既存システムのソフトウェア資産管理が出来ていなかった事が
発覚し、移行時の役割、運用時の実現性などは検討されていなかった。
35
 機能要件の定義

ユーザはパッケージソフトウェアの不足部分（アドオン、外部プログラム）および外部インターフェース）
として、以下の要件を示した。
 販売管理：百貨店から売上データ取込み（日次・夜間バッチ）
量販店とのＥＤＩ対応（受注取込み・受注取消取込み・専用伝票発行・支払案内照合）
百貨店および量販店の店舗別事業管理帳票
物流システム（入出庫指図・ピッキングリスト・伝票発行・棚卸）
コンビニＥＤＩ対応（受注取込み・受注取消取込み・専用伝票発行・支払案内照合）
通信販売Ｗｅｂ対応（在庫照会・購買履歴・受注・宅配便伝票発行・送品案内・決済）
 財務会計：販売管理および生産管理から自動仕分データの取込み
百貨店および量販店の月ズレ処理に対応できる月次決算の遡及処理

財務会計については、ユーザの担当責任者が財務会計業務を熟知している取締役経理部長であるこ
とから、また、既存システムは会計事務所が導入支援を行ったことから、Ｐ／Ｌ・Ｂ／Ｓの階層やマスタ
等の整備に関しても明確に定義されており、新業務の全体像も具体的に示すことが出来た。
＊しかしながら、既存システムの資産管理はなされておらず、情報システムに関する各種ドキュメントも未
整備（未整理）で、また、新設の電算部門も単独の業務システムであれば対応可能なスキルはあるも
のの、今回の様な業務連携システムにおける構築経験は無く、新規事業への対応もあることから、何
から整理をして良いのか皆目見当がつかない状況であった。
モデルケースＡ社
次期販売管理システ
ム
36
【目的】コンサルタントの支援を得て、パッケージソフトウェア候補からシステム要
件評価および既存システムとの接続性の評価を経てパッケージソフトウェ
アを決定します。
併せて、ハードウェア構成およびテスト仕様書の作成を行います。
フェーズＢコンサル支援内容
①
 パッケージ候補のシステム要件評価（移行要件を含みます。）
 要件定義を支援するベンダは、ベンダの支援の下でユーザが選定したパッケージソフトウェアについて、さら
に詳細な評価を行いユーザに提案を行います。特に移行については、必要な作業とその対応を行うのが
ユーザかベンダかを明確にする必要があります。この場合の検討事項は以下のとおりです。
 機能要件の適合及び充足度、不足する機能要件、（カスタマイズ部分の機能要件）
 非機能要件の適合及び充足度、不足する非機能要件
 セキュリティ要件の適合及び充足度、不足するセキュリティ要件とそのリスク
 ハードウェア、ネットワーク構成方針との適合及び充足度
 既存システムインターフェース要件との適合及び充足度、実現困難性
 運用・保守方針適合及び充足度、実現困難性
 データ移行の整合性、実現困難性、移行に伴う制限事項
 法規制・内部統制等制限事項適合性
 パッケージ候補費用概算見積
 以上の検討の際、パッケージソフトウェアのブラックボックス部分（パッケージソフトウェアメーカでなくてはわ
からない部分）がある場合は、それによる不確定要素を明確にした上で、ユーザに承認を受けます。

APIの実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価）
 ベンダは不足する要件や他のシステムとの接続について、その実現方法を提案します。カスタマイズにより
実現する場合は、その部分については新規開発と同様に開発工数とコストがかかるので、概算のコストと開
発完了時期を提示する必要があります。またその他の手段で実現する場合は、その内容をより具体的に
ユーザに説明する必要があります。ここでは以下の点に注意します。
 論理的な接続だけではなく、そのタイミングや頻度についても要件を満たしているか。例えば、販売管理では日々データを
出力できるが財務管理では月に一度しか取込みができないようなケースで、財務管理側で日々の進捗確認は困難となりま
す。
 また、返品等の取引があったとき出力先のシステムでそれらのデータをどのように扱うかの確認も必要となります。
モデルケースＡ社
次期販売管理システ
ム
37
フェーズＢコンサル支援内容
②
 またベンダはSLAの評価が必要な場合には、より具体的な指標によりサービスレベルを提示するとともに、
そのレベルが維持されない場合のリスク等についても報告します。機能要件の適合及び充足度、不足する
機能要件、（カスタマイズ部分の機能要件）

パッケージソフトウェアの選定（ソフトウェア要件定義と評価）
 ベンダはこれまでの承認された報告内容に基づき、パッケージソフトウェアにおけるソフトウェア要件を入出
力画面や画面遷移を含む用件としてまとめ、ユーザの承認を受けます。

推奨ハードウェア構成の概要
 ベンダは、ハードウェアやネットワークの構成の詳細、既存システムとの物理的接続について報告し、ユー
ザの承認を受けます。この場合、ソフトウェアメーカーと開発ベンダが異なったり、構成に特殊なハードウェア
があると、開発時にソフトウェアやハードウェアが必要となるケースがあります。これらについても、必要なタ
イミングも合わせてユーザに報告する必要があります。

システム全体のテスト仕様書作成
 ベンダはユーザから要求がある場合、システム全体のテスト仕様書作成を支援します。
 その場合、主に他のシステムとのインタフェースに問題が無いことやカスタマイズ対応した部分が要件どおり
であることの確認が中心となりますが、機能面だけではなく運用の側面から問題の無いことが確認できるテ
ストを提案する必要があります。さらに通常時の運用だけではなく、ピーク時の負荷への耐性やエラー時や
障害時の運用の切換えやシステムの復旧についても確認する必要があります。
 ベンダは、以上のテスト内容とあわせテスト環境をどのように確保するか、場合によっては必要コストについ
ても説明する必要があります。
モデルケースＡ社
次期販売管理システ
ム
【目的】このフェーズにいてユーザ果たすべき役割と責任を果たすうえで、重要
なポイントの整理を行っております。
モデル契約書（重要事項説明書）に対する理解を深めましょう。
38
フェーズBユーザ側のポイン
ト
 パッケージソフトウェア候補のシステム要件評価段階
 ベンダに対して報告（案）の説明を十分に求め、特に移行時の役割、運用面の実現性などについて、コスト
面、人的ソース面、物理的設備についても問題がないか確認を行い、承認を行いましょう。
 業務要件定義の基づいて、機能要件の定義や使用予定のパッケージソフトウェアの比較を行います。
 APIの実現性の確認段階
 実現方法はもとより、人的側面、費用的側面、時期などに問題が無いことを十分に確認の上で承認します。
またSLAの評価が必要な場合には、特にリスクについて十分な検討が必要です。例えば、システムがダウン
したことにより取引先からペナルティを要求されるようなケースでは、許容できるダウンタイムやペナルティが
与える影響などの考慮も必要になります。
 パッケージソフトウェアの選定段階
 パッケージソフトウェアとカスタマイズ部分、それらと他のシステムとのインターフェースについての報告から、
これまでの個々の報告と全体の整合性が取れていることを確認し、承認します。
 パッケージソフトウェアの不足部分や変更部分は、この段階で明確化させておきましょう。
 推奨ハードウェア構成の概要段階
 これまでに承認した運用方針やバックアップ方法など、また非機能要件などを満足する構成であることを確
認し、承認します。
 選定したパッケージソフトウェアに合わせて実際に使用する推奨ハードウェア構成などのシステム要件をベン
ダに要求して報告させて決定します。作成するシステムで、現在は使用していないハードウェアやソフトウェ
アなどがある場合は、必要になる可能性があるので確認しておきましょう。
 システム全体のテスト使用書作成段階
 網羅的なテスト内容になっていることを確認した上で、承認します。
重要事項説明書 B パッケージソフトウェア選定支援及び要件定義支援業務 39
フエーズＢサンプ （パッケージカスタマイズモデルの場合）の重要事項の例
ル①
B
パッケージソフトウェア選定支援及び要件定義支援業務契約（カスタマイズモデル）の重要事項
(2)具体的作業内容
本件業務にあたって使用する業務要件定義書 ： 改訂版業務要件定義並びにパッケージ候補選定報告書
作業項目
作業内容及び作業実施担当
ユーザ
■パッケージ候補のシステム要件評価（移行要件を含みます。）
ベンダ
機能要件の適合及び充足度
不足する機能要件、実現困難性
非機能要件の適合及び充足度、実現困難性
セキュリティ要件との適合及び充足度、実現困難性
ハードウェア、ネットワーク構成方針との適合及び充足度
既存システムインターフェース要件との適合及び充足度、実現困難性
運用・保守方針適合及び充足度、実現困難性
詳細比較項目(案)の評価及び
ご承認
パッケージ候補システム要件
詳細比較報告書(案)の評価及
びご承認
詳細比較項目(案)の策定
パッケージ候補システム詳細
比較の実施と報告書(案)の作
成
ユーザ
ベンダ
パッケージ候補APIの実現性
確認報告書(案)の評価及びご
承認
パッケージ候補APIの実現性確
認の実施と報告書(案)の作成
パッケージ候補と既存システ
ム接続性評価報告書(案)の評
価及びご承認
パッケージ候補と既存システ
ム接続性評価の実施と報告書
(案)の作成
データ移行の整合性、実現困難性、移行に伴う制限事項
法規制・内部統制等制限事項適合性
パッケージ候補費用概算見積
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
■APIの実現性の確認（候補パッケージのAPI、既存システムとの接続性等の評価、
SaaS/ASPにおいてはSLAの評価）
不足する要件の実現方法
開発もしくは実現方法及び困難性評価
開発工数の概算見積、実現方法の概算見積
既存システムとの接続性評価
開発方法
開発工数の概算見積
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
重要事項説明書 B パッケージソフトウェア選定支援及び要件定義支援業務 40
フエーズＢサンプ （パッケージカスタマイズモデルの場合）の重要事項の例
ル②
作業項目
■パッケージソフトウェアの選定（ソフトウェア要件定義と評価）
作業内容及び作業実施担当
ユーザ
ベンダ
業務システム個別計画書、パッケージ候補システム要件詳細比較報告書及びパッ
総合評価報告書(案)の評価及 総合評価の実施と報告書(案)
ケージ候補APIの実現性確認報告書に基づく総合評価（セキュリティ要件及び運用・
びご承認
の作成
保守方針適合を含む）
カスタマイズ開発仕様及び概算見積
カスタマイズ開発仕様（画面
カスタマイズ開発仕様書
構成、画面遷移を含む）の策
（案）の評価及びご承認
定と仕様書（案）の作成
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
■推奨ハードウェア構成の概要
ハードウェア詳細構成及びネットワーク詳細構成
既存システムインターフェス詳細
ユーザ
ベンダ
ハードウェア・ネットワー
ク・既存システムインター
フェース詳細構成報告書(案)
の評価及びご承認
ハードウェア・ネットワー
ク・既存システムインター
フェース詳細構成の策定と報
告書(案)の作成
ユーザ
ベンダ
以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
■システム全体のテスト仕様書作成（○実施する・実施しない）
業務システム個別計画書、総合評価報告書及びハードウェア・ネットワーク・既存
システムインターフェース詳細構成報告書に基づく業務システムテスト仕様
実施する場合、以上に関わる報告書の作成：提出予定期限○○○○年○○月○○日
テスト仕様書（案）の評価及 テ ス ト 仕 様 の 策 定 と 仕 様 書
びご承認
（案）の作成
重要事項説明書 B パッケージソフトウェア選定支援及び要件定義支援業務 41
フエーズＢサンプ （パッケージカスタマイズモデルの場合）の重要事項の例
ル③
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・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 システム利用時間帯
42
Ⅱ-3 納期およびスケジュール
Ⅱ-4 納品条件
Ⅱ-5 プロジェクト及びプロジェクト推進体制
Ⅱ-6 移行方法
Ⅱ-7 教育・トレーニング計画
Ⅱ-8 保守・運用サービス
Ⅱ-9 費用見積
Ⅱ-10 セキュリティ対策
Ⅲ．提案手続きについて
Ⅲ-1 提案手続き・スケジュール
Ⅲ-2 提案依頼書の対応窓口
Ⅳ．開発に関する条件
Ⅴ．契約に関する事項（契約形態・検収・費用）
Ⅵ．貴社に関する事項
Ⅵ-1 会社概要
Ⅵ-2 実績の紹介
添付資料1
Ⅵ-3 類似システムリプレース実績
添付資料2
Ⅵ-4 オプションサービス説明資料
添付資料3
Ⅶ．用語集
添付資料4
組織図
業務規程
EOS,EDI取引先一覧
現行ネットワーク構成図
添付資料5 現行トランザクション量
別冊1 業務定義・システム機能要件
（基幹系業務編)
別冊2 業務定義・システム機能要件
（情報系業務編)
別冊3 業務定義・システム機能要件
（マスタ管理業務編）
モデルケースＡ社
次期販売管理システ
ム
サンプル 要件仕様書
要件定義書サンプル 別紙
43
設計開発、移行・
運用準備の
流れと責任
D 外部設計支援業務契約、E ソフトウェア設計・制作業務契約、F 構築
業務契約、G データ移行支援業務契約、H テスト支援業務契約、I 導入
教育支援業務契約
44
 仕様変更への対応
 設計開発、移行・運用準備段階では、確定した要件定義に対して、修正や変更
が発生する場合があります。修正や変更の原因を正しく把握し、対処することが
重要です。
 仕様と異なる実装がなされた場合は、変更規程に基づきユーザの承認を得て、
報告書を作成しなければなりません。
ⅰ
要件定義
設計開発
ⅱ
ⅲ
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
準委任
D 外部設計支援業務契約
請負
E ソフトウェア設計・制作業務契約F 構築業務契約
移行・運用
準備
準委任
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
モデルケースＡ社
次期販売・財務システ
ム
フェーズＤでの概況
【目的】本フェーズは要件定義書を基に、画面・帳票・インタフェース等の外部
設計書に対する検討会をユーザとベンダで行い、承認を行う段階です
が、本段階において追加・変更をせざる得なく状況となるに至った。
速やかに、連絡協議会が開催され要件変更手続きがとられた。
45
 外部設計書の承認段階での問題点
 コンビニ事業部は新規事業部門であることから、電算部門が中心となり、業務要件の集約を行っ
たが、事業の運営方針も不明確な点も多く、電算部門も新設で自社の業務知識が十分でないこ
とから、要件定義段階では見逃されていた、画面・帳票の不足が発生した。
 コンビニ事業における物流は共同配送センターを利用することで、物流部門は自部門の業務運
営上の問題点については、十分な打ち合わせを行っていたが、ＩＴに関しては、電算部門が別途
打ち合わせを行っているとの認識で、物流部門の要件から共同配送センター対応システムの要
件が欠落していた。
 百貨店からの売上データ取込みのインターフェース変更が百貨店事業部へ通知されていたが、
電算部門へ通知の連絡が滞っており、外部設計書の変更が必要となった。
 量販店事業部より来年から予定されている指定伝票の様式変更が反映させていないとの指摘が
なされた。
 要件定義段階への手戻りと外部設計書の修正（連絡協議会による要件変更手続）
 要件定義支援をおこなったコンサルタントであるＩＴコーディネータと外部設計支援をおこなったベ
ンダおよびユーザにて、連絡協議会が開催され、要件定義段階への前戻り作業の要因分析を
行ったところ、ユーザ電算部門と利用部門との連携が上手くいっていない点がクローズアップされ、
ユーザ社長はこの問題を重要視し、利用部門より新たにプロジェクトメンバーが追加アサインされ
た。
 ユーザ経営層からはコンサルタントであるＩＴコーディネータの債務不履行ではないのか、無償で
要件定義を再度 実施して欲しいとの要望が出されたが、コンサルタントの見解は、ユーザからの
情報提供の不足と報告書の確認不足である旨の説明とベンダも同様の所見であることから、自
社の問題が起因したものと納得が得られた。（準委任契約における責任範囲外）
 要件定義段階と外部設計の手戻り作業がスケジュール化され、プロジェクト全体のスケジュール
遅延とコスト増加について、ベンダより報告がなされ、コストについてはユーザとの合意が得られ
たが、スケジュールについては、当初スケジュールでの稼働に対する努力要請がベンダに対して
出され、ベンダは要請を受け入れるに至った。
モデルケースＡ社
次期販売財務システ
ム
46
フェーズDベンダ支援内容
 推奨ハードウェア構成
 ベンダは、外部設計段階で将来の処理増大に伴うスーケルアップ、スケールアウトの拡張構成などの柔軟
性の確保と稼働時点で過少、過剰設備とならないハードウェア構成とし、ユーザと合意を行う。
 外部設計支援業務段階における支援業務
 具体的作業内容で、要件定義書、作業体制、外部設計検討会の開催、委託先などについて、ユーザの合意
を得なければならない。
 パッケージソフトウェアの表示では、バージョン、リビジョン、保守やサポート体制について明らかにし、また、
その時点で判明している不具合などがあれば、併せてユーザの確認を得ておく必要がある。
 外部設計書、付属文章一覧で業務フロー、システム構成、実態関連図を作成する必要がある。
 外部設計検討会の開催支援
 ベンダは外部設計段階で作成した上記文章をユーザに十分に説明し、ユーザ、ベンダ合同で検討評価する
場であり、ベンダは事前にユーザに何を決定するのかなどの成果と品質について合意を得ておく必要があ
る。
 外部設計支援業務での要件の多大な追加、変更が生じた場合、その原因がベンダ、ユーザのいずれにあ
るのか、ベンダに説明を求めた上、重要事項説明書の記載と照らして判断する必要があります。
モデルケースＡ社
次期販売・財務システム
フェーズＤにおけるユーザポイ
ント①
 ユーザ側におけるポイント
 要件定義書などの仕様に基づいた、画面や帳票、
インターフェース、他のシステムと遣り取りすること
を前提としたデータ方式などの外部設計書の承認
を行います。
 外部設計支援業務はインタフェースや帳票、デー
タ種類のフォーマットなどを外部設計書を作成支
援する契約です。いずれも使い勝手や他とのデー
タやり取りにかかわる部分ですので注意してくださ
い。なお画面設計などは要件定義書で基にすれ
ば作成できるはずですので想定していません。セ
キュリティについてRFPに該当項目ない場合は、
ここで設定します。その際はセキュリティチェック
シートを利用してください。
 実際のインタフェースに関わる部分ですので、実
際に業務を運用している部門のスタッフにも内容
を確認させましょう。
 帳票は現在の使用している様式が使用可能可を
確認しましょう。
 データのフォーマット形式を確認しましょう。外部と
データの遣り取りをする場合は相手方の形式を確
認しましょう。
47
 ベンダ側からの要請されるポイント
 外部設計支援から担当するベンダが異なる時は、
外部設計支援を担当するベンダは要件定義を前
提に開発を行うので、要件定義が不十分だと、そ
れを十分なものとすることを求めてきます。この場
合、三者間で連絡協議会などを通して十分に状
況・問題点・課題の共有を図り、行うべき作業の分
担と責任を明確にする必要があります。
 要件定義支援担当のベンダが担当する作業例
•
•
•
•
コンビニ事業に必要な画面・帳票の洗い出し
百貨店売上データ取込みのインターフェース
量販店指定伝票の様式変更
これらをもとにした要件定義の見直しと改版
 外部設計担当のベンダが担当する作業例
•
•
新たな要件定義を前提とした開発体制の確保
これらをもとにした開発計画
 この場合、要件定義の見直しをしたうえで、外部設
計支援担当ベンダからあらためて外部設計以降
の重要事項説明書の説明を受け、確認後、承認を
することになります。ユーザがやるべきことを確認する必要
があります。
 尚、ひとつのベンダに全てをお願いする場合でも、
要件定義が不十分な場合は上記と同じステップを
踏む必要があります。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＤにおけるユーザポイ
ント②
 ユーザ側におけるポイント
 この段階で変更や追加事項が生じた場合は要件
定義が不十分と言うことになるので、連絡協議会
等を開催して要件定義を見直して、新たな外部設
計の重要事項説明書を提出を受けます。
 ユーザー側に責任のある変更の場合は、新たに
作業を行う必要や追加費用の発生もあります。作
業の進捗状況のスケジュール、報告については作
業体制に基づいた窓口より、どのような形式と区
切りで報告を受けるかを確認します。
 設計段階において、ベンダより設計環境の貸与や
借用を求められる場合もあるので、その際は費用
や期間などの明確化も行う必要があります。
48
重要事項説明書
フエーズＤサンプル
49
D 外部設計支援業務
重要事項説明書の例
D 外部設計支援業務契約の重要事項 (2) 具体的作業内容
１．要件定義
○○○○年○○月○○日付け「A社 次期販売・財務システム」要件定義書
第×版に基づく
２．設計作業の体制及び方法
（１） 作業体制（受託者の体制、責任者、主任担当者、連絡窓口等）
・責任者：
β社開発部 部長 甲野太郎
・主任担当者： β社開発部 開発マネージャー 乙山次郎
・連絡窓口： β社業務部 主任 丙川三郎
（２） 設計方法（設計工程、進捗管理及び報告、設計環境の貸与・借用等）
・進捗管理： β社にて管理。週1回、A社に進捗報告
・設計環境： β社にて準備（貸与なし）
（３）外部設計検討会（日程、場所、参加者、内容、変更管理手続等）
・○○○○年○○月○○日、A社本社にて実施
・A社、β社の責任者、主任担当者、α社（要件定義担当社）担当者が出席
・画面・帳票の過不足、インタフェース仕様の確認を行う。
（４）委託先
・なし
（５）期間： ○○○○年○○月○○日～ ○○○○年○○月○○日
３．未決事項
・生産管理システム（既存）とのネットワーク接続仕様
４．付帯事項
・帳票の過不足等、業務要件定義の不備による要求定義の改定はα社に
て行う。
・上記の改定によるβ社の作業量増加等が発生した場合は、提出期限等
の条件見直しについて、A社とβ社で協議する。
５．特約事項
業務完了報告書及び外部設計書の提出期限：○○○○年○○月○○日
上記報告書及び外部設計書に係る点検期間： 提出日から１０日間
受託金額（税抜）： ○百万円
損害賠償限度額： ○百万円
支払期限： ○○○○年○○月○○日
支払方法： 口座振り込み
モデルケースＡ社
次期販売・財務システ
ム
フェーズＥでの概況
50
【目的】請負契約であることからユーザはベンダへの丸投げ意識が強く、テスト
データの準備に関する利用部門の意識は低く、また、既存システムから
のテストデータ準備に関して、既存ベンダとの調整が難航し、作業遅延
をきたし、これらの問題をベンダの支援にて解決を図った。
 ベンダの適格性テスト
ユーザとしては、ソフトウェアの開発段階であり、また請負契約でもあることから、ベンダへの丸投げ意
識が強く、ベンダテストに対する関心は低くなりがちであった。
 ベンダの出荷テストである適格性テストについては、テスト体制・合格基準・ユーザデータの使用の有
無について、ユーザ電算部門はきちんと理解していたが、プロジェクト全体での周知までには至らず、
既存データがないコンビニ事業部（新規事業部門）については、テストデータの提供を行わず、ベンダ
が単独で仮想データを作成し、結果、想定される取引データが十分に反映されていないデータでの、適
格性テストをベンダが実施してしまった。
 通販事業部が取りまとめたテストデータには、各店舗で収集した個人情報が多数含まれていた。これら
のデータがベンダ側と個人情報に関する取扱および保管に関する取り決めもないままに、無造作にベ
ンダへ渡され使用されていた事が、ベンダのプロジェクト管理者が発見し、ベンダ側よりユーザ社長に
対して報告（謝罪）がなされた。
ユーザ社長は個人情報保護について認識を新たにし、個人情報を取扱う百貨店事業部と通販事業部
に対して、重点的に再発防止策の検討と徹底が指示された。（謝罪のおり、ベンダからセキュリティと個
人情報に関する社員教育の必要性について、提案が出されたがユーザの関心は低かった。）
 テストデータ作成のため、既存システムのベンダへ協力してもらいたい内容が、ベンダより示された、こ
れを受けて、ユーザ電算部門は、既存ベンダに協力要請とコスト交渉を行った。
既存ベンダより提示された、既存システムからテストデータ抽出プログラム開発費および立会作業費は、
ユーザの認識を大きく超えるもので、ユーザ社長の認識としては、立会作業は既存システムの運用支
援契約反中ではないのかとの疑問も既存ベンダに投げかけられ、既存ベンダも積極的に作業を行う事
由もなく、テストデータ準備作業は大幅に遅延するに至った。

モデルケースＡ社
次期販売・財務システ
ム
フェーズＥにおけるユーザポ
イント
 ユーザ側におけるポイント
 ベンダの出荷テストである適格性テストについて





は、テスト体制・合格基準・ユーザデータの仕様の
有無についてのベンダの説明について、十分に納
得の上、承諾する必要があります。
ベンダの出荷テストである適格性テストについて
は、テスト体制・合格基準・ユーザデータの使用の
有無について、ベンダへ説明を求める必要があり
ます。
制作されたソフトウェアは納入前にベンダ適格性
テストを行います。これはソフトウェアが的確に動
作するかを出荷前にベンダ内でテストを行うもの
です。
適格性テストについては、テスト体制・テスト内容・
テストに使用するデータについてベンダと取り決め
ます。
テストの内容について、その結果が運用に耐える
内容かどうかを判断できるスタッフもベンダとの取
り決め時に入ってもらい合格基準を決定しましょう。
テストに使うデータについて実際のデータを使う場
合は、個人情報・機密情報などが含まれている場
合もあるため、ベンダとの間に取り扱いの規定を
決める必要もあります。
51
 ベンダ側からの要請されるポイント
 テスト体制にはベンダ要員だけではなくユーザか
らも結果の妥当性について確認ができる人が求め
られます。
 ベンダはどのようなテストをするかを説明してくれ
ますがそれで十分かどうかの判断はユーザが行う
必要があります。判断がつかない場合は、IT化の
範囲と照らし十分なテスト範囲であることを確認で
きるように、ベンダに対して説明を求める必要があ
ります。
 その上で、適合性テストの合格基準を確認します。
 また、テストデータは条件を網羅していることが重
要となります。そのためユーザデータを使用する
場合、以下の点に注意しましょう。
 ユーザデータは必要な条件を網羅していることをどのよう
に確認するか。
 不足がある場合、ベンダとユーザどちらがテストデータを作
成するか。
 ユーザデータに個人情報や機密情報を含む場合、ベンダ
の取り扱いはどうなっているのか。ベンダに取扱規定があ
ればその規定を確認。無ければ、授受の方法・手段、管理
方法、返却や廃棄に関する手続き、等に問題が無いことを
確認します。
重要事項説明書
フエーズＥサンプ
ル
E ソフトウェア設計・制作業務
契約
重要事項説明書の例
E ソフトウェア設計・制作業務契約の重要事項
(2) 具体的作業内容
１．システム要件、プログラム仕様
○○○○年○○月○○日付け「A社 次期販売・財務システム」要件定義書
第×版及び○○○○年○○月○○日付け「A社 次期販売・財務システム」外部
設計書に基づく。
２．設計作業の体制及び方法
（１） 作業体制（受託者の体制、責任者、主任担当者、連絡窓口等
・責任者：
β社開発部 部長 甲野太郎
・主任担当者： β社開発部 開発マネージャー 乙山次郎
・連絡窓口： β社業務部 主任 丙川三郎
（２） 開発方法（開発工程、進捗管理及び報告、設計環境の貸与・借用等）
・進捗管理： β社にて管理。週1回、A社に進捗報告
・開発環境： β社
（３）委託先（委託先の概要、管理体制等）
・百貨店からの売上データ取込機能について、Ω社に製造を委託する。
・Ω社の概要： 従業員30人。Β社から、年10件程度を製造委託
・委託責任者： β社開発部 部長 甲野太郎
・委託担当者： β社開発部 開発マネージャー 乙山次郎
（４）期間： ○○○○年○○月○○日～ ○○○○年○○月○○日
52
３．ベンダにおける適格性（出荷）テスト条件
（１）テスト体制（出荷合格の体制（テスト実施主体、環境、責任者等）
・適格性テストは、β社品質管理部が行う（責任者：丁島四郎 品質管理部長）
（２）テスト内容、方法（出荷合格とする条件）
・適格性テスト仕様書にて定める。
（３）テストデータ（テストで使用するデータの詳細および作成主体等）
・テストデータは、A社にて、実データをもとに作成し、β社に提供する
（４）期間： ○○○○年○○月○○日～ ○○○○年○○月○○日
４．運用テスト仕様書（運用テスト計画、運用テスト仕様）の作成
・β社開発部にて作成する。
・○○○○年○○月○○日に運用仕様検討会議をA社本社にて行う。
５．連絡協議会の実施要領及びユーザ・ベンダの責任者、主任担当者
・○○○○年○○月○○日、A社本社にて実施
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
６．未決事項
７．付帯事項
８．特約事項
納期： ○○年○月○日
テスト期間： ○○年○月○日～○月○日
瑕疵担保期間： 1年間
受託金額（税抜）： ○○百万円
損害賠償限度額 ○○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
モデルケースＡ社
次期販売・財務システム
フェーズＦでの概況
53
【目的】このフェーズでは、要件定義および外部設計に基づき、指定されたハードウェ
・ソフトウェア・ネットワークが要求通り動作するように設定されたことを受入検査
します。既存システムとの併設（結合）についても同様です。
 構築仕様書の承認
 電算部門を中心に次期販売・財務システムにて使用するハードウェア・ソフトウェア・ネットワークの構築内
容について、ベンダより構築仕様書に基づいて説明が行われた。承認についてはユーザ社長より電算部門
に権限委譲がなされていたこともあり、構築仕様書の作成および承認については、スムーズに合意形成が
おこなわれた。
 併設する既存システムである生産管理システムとのネットワーク接続に対する接続使用に関しては、ベンダ
とユーザ電算部門が協力して作成した既存システム接続仕様（案）が、工場担当者より既存ベンダに示され、
既存ベンダは協力要請については、生産管理システムが今回の新システムの対象外で併設であることもか
らも、事前確認、立会作業および保守作業の作業分担等積極的な協力が得られる事となった。
 人事給与システムに関しては、市販されているパッケージソフトを購入し、ユーザが構築したこともあり、既
存システムに関する運用支援をおこなっているベンダがいないことから、新システム構築ベンダがパッケー
ジメーカに問合せを行い、併設環境を構築することになった。
しかしながら、人事給与システムに起因する不具合が発生した場合については、ベンダ側は責任を負わな
い旨の申し入れが出され、これを作業の条件にすることでユーザとベンダで合意がなされた。

構築、設定作業の受入れ
 生産管理システムの工場担当者4名は、新システムのプロジェクトメンバであったが、自部門システムが対
象でないことも有り、プロジェクトへの参画意識は低く、ベンダと電算部門にてスケジュールされた生産管理
システムと新システムとのネットワーク接続テスト実施時間帯でのシステム停止が出来ずに、作業者および
立会者が約半日待ちが発生し、追加費用の請求がベンダおよび既存ベンダよりユーザへ提示されるに至っ
た。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＦにおけるユーザポ
イント
 ユーザ側におけるポイント
 ベンダから提供を受ける構築業務設定報告書の
内容について十分に説明を受け、内容について十
分に理解してから承認する必要があります。
 構築仕様書の内容について、十分にベンダへ説
明を求め、同意する必要があります。
 構築仕様書と実作業が異なる場合には、構築業
務設定報告書においてベンダへ説明を求め、その
内容について承認をしなければなりません。
 ベンダの出荷テストである適格性テストについて
は、テスト体制・合格基準・ユーザデータの仕様の
有無について、ユーザにきちんと説明を求める必
要があります。
54
 ベンダ側からの要請されるポイント
 構築にあたり最も注意を要するのは、稼働中のシ
ステムに対する影響です。ベンダは構築するシス
テムについての説明は行いますが、それでは十分
ではありません。説明が不足している場合は、稼
働中システムへの影響をどのように確認したかの
説明を受ける必要があります。その場合、ベンダ
から以下のような点を求められることがあるので
ユーザは関係者への確認と調整を行います。
 構築作業時、生産管理システムや人事給与システムの稼
動停止、または稼動したままの構築が問題が無いことの
確認
 ハードウェアベンダが異なる場合、構築に必要なハード
ウェアの手配状況の確認
 既存システムのデータ等のバックアップ（ベンダは未知の
部分については責任を負いかねることになるので、万一を
考え必ず必要となります）
 これらについて既存ベンダとの調整
重要事項説明書
フエーズＦサンプ
ル
55
F 構築業務契約
重要事項説明書の例
F 構築・設定業務契約の重要事項 （2）具体的作業内容
項番
名称・型番
設置場所
仕様もしくは仕様書名
（設定内容、他システムとの結合の有無、障害発生時の切り分け作業、受入テスト条件等）
期間
１
通販システムサーバ
A社本社 712号室
通販システム設定仕様書。DMZを介してインターネットに接続
○月○日～○月○日
２
通販ネットワーク
A社本社
通販ネットワーク設定仕様書。DMZ、多重化の設定等
○月○日～○月○日
：
：
：
：
：
：
：
：
：
：
関連するシステム、ネットワークの停止等の条件
・生産管理システム、人事給与システムの稼働停止がないこと
連絡協議会の実施要領及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
委託先（委託先の概要、管理体制等）
・なし
付帯事項：
特約事項：
構築・設定業務完了報告書提出期限（構築・設定業務報告書を含む）： ○○○○年○○月○○日
受託金額： ○○百万円（税抜） 受託金額はソフトウエア設計製作業務の受託金額に含んでいます。
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
テスト期間： ○○○○年○○月○○日～○○月○○日
瑕疵担保期間： 1年間
損害賠償限度額： ○○百万円
モデルケースＡ社
次期販売・財務システ
ム
フェーズＧでの概況
【目的】このフェーズでは、既存システムのデータを新システムへ移行する
作業をおこないます。既存システムベンダに対する協力要請と作
業実施に関してはユーザ責任で実施する必要があります。
56
 要件定義書に基づくデータ移行作業
既存販売管理システムからのデータ移行作業については、全体コストが増加していることから、既存ベ
ンダへ作業依頼することなく、電算部門が既存システムからデータ抽出を行い、新システムベンダが移
行データの取込み作業を行う事で、移行作業が進められたが、利用したプログラムはテストデータ抽出
時に既存ベンダが開発したもので、ユーザ側より開発費の削減要求が強かった事もあり、繰り返し利
用時の変更データ部分の差分抽出機能等がカットされており、全てのマスタおよびトランザクション
データを繰り返し移行作業するのは、困難である事が明らかとなった。
再度、ユーザおよび既存ベンダと新システムベンダデータにて、データ移行に関する協議の場がもた
れ、データ移行作業の詳細仕様について追加作成が行われ、データ移行作業の役割分担とユーザ側
の当該事業部門における移行確認作業について、合意が形成された。
 しかしながら、ユーザとしては移行に関するコストは、テストデータ移行費用と二重投資を招くことになり、
結果として全体費用を押し上げることとなった。
 新規事業であるコンビニ事業および通販事業に関しては、あらかじめ事業部門で用意したエクセル
シートから、次期システムへ取込み作業を行って欲しいとの要請が出され、ベンダが作業を行ったが欠
落データや仕様外のデータが多数存在し、移行作業が暗礁に乗り上げる事となった、電算部門とベン
ダにて作成データのチェックを行う事で、移行作業を終えることができたが、スケジュールの遅延が発
生するに至った。
 財務会計システムからのデータ移行は、要件定義書作成時に、詳細項目、移行タイミングおよび作業
分担まで明確に取り決めがなされていた事と、これらに対する認知度が高く、スムーズに移行作業が
完了した。

モデルケースＡ社
次期販売・財務システ
ム
フェーズＧにおけるユーザポ
イント
 ユーザ側におけるポイント





要件定義の仕様に基づいた作業が行われて
いるかについて確認し、不明な点については
ベンダに説明を求めるようにしてください。
事業運営に影響を与える、既存システムの停
止やネットワーク上の機器に対する注意事項
の有無について、ベンダに事前確認を行い説
明を得る必要があります。
既存ベンダに対する協力要請および協力体制
の整備はユーザの責任と役割です。
ユーザとベンダおよび既存システムベンダ等
それぞれの役割分担と期日管理を明確に行う
必要があります。
ベンダが作業中に既存システムのデータ等を
誤消去する事も想定されますので、バックアッ
プの実施および復旧方法の検討等について
事前確認が必要です。
57
 ベンダ側からの要請されるポイント
 移行作業では構築作業以上に既存システム
への影響等に注意が必要となります。
 ベンダと合意する作業記述書の確認では、作
業項目が十分であることに加え、具体的に
ユーザ側の対応を行う社員をイメージし、日程
に問題が無いことや万一予定していた社員が
対応できない場合のことなどを考えておきます。
また、移行データの整合性を確認する具体的
な方法なども検討しておく必要があります。
 さらにベンダからは万一、移行が何らかの不
測事態により中断しなければならなくなった場
合、どうするかを相談されます。これについて
も、起こったときに考えるのではなく、重要事
項説明書を確認する時点で十分に協議してお
く必要があります。このとき考慮すべきこととし
ては以下のような事項があります。
 必要なバックアップデータ等の準備
 協力が必要な場合、既存ベンダへの要請
 現行システムに戻すための時間はどの程度の
余裕があるか、戻す手順と手続きはどうするか。
重要事項説明書
フエーズＧサンプ
ル
58
G データ移行支援業務契約
重要事項説明書の例
G データ移行支援業務の重要事項 （3）具体的作業内容
移
行
の
た
め
の
変
換
作
業
ユ
ー
ザ
管
理
者
期間
項番
１
会社名
A社
所属
コンピューターセンター
氏名
己田 五郎
連絡先
03-○○○○-○○○○
○○○○年○○月○○日～ ○○月○○日
ベ
ン
ダ
担
当
者
会社名
β社
所属
開発部
氏名
乙山次郎
連絡先
03-○○○○-○○○○
業務完了報告書提出日並びにその点検期間： ○○○○年○○月○○日（点検期間７日間）
作業内容（ユーザ、ベンダの役割分担を含みます。）
既存販売管理システムの履歴データを、新規システム用に変換（β社担当）
作業仕様書名、実施詳細
販売履歴データ変換仕様書
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、
主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
付帯事項： （作業を実施する場合の場所・期限等、要件の合意、承認ルールを含みます）
・変換作業はA社コンピュータセンターにて行う。
特約事項：
受託金額（税抜）もしくは受託金額の決定基準
○百万円
損害賠償限度額：
○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
モデルケースＡ社
59
次期販売・財務システ 【目的】このフェーズでは、運用にかかわる作業手順の策定および作業手順に
基づくテスト仕様書を作成します。テスト仕様書に基づき、プログラムが
正常に動作しているかの合否判定をおこないます。
ム
追加要望については、原則凍結し、別途改善プロジェクトへ先送りした
フェーズＨでの概況
 運用（作業）手順書の作成
 電算部門が運用手順書の作成をおこない、利用部門にて作業手順書を作成し、電算部門にて運用手順書
と作業手順書の整合性のチェックがおこなわれないまま、テスト仕様書の作成段階で不整合が発覚した。
不整合のポイントとしては、作業手順書のコンビニＥＤＩ自動実行の実施時間帯が、運用手順書の自動バック
アップの実行時間帯と重複するといったもので、べンダの指摘を受け、電算部門にて事業部門毎のシステム
稼働時間帯の再整理により、バックアップ自動実行可能時間はAM2：00～6：00の4時間であることが明確
になった。
 ベンダのアドバイスでシステム等のメンテナンスもあることから、バックアップ自動実行時間をAM2:00～4：
00までの２時間とすることで決定し、電算部門とベンダでバックアップ仕様の日常バックアップのカバレッジ
範囲の縮小がユーザ内で決定された。
 ベンダより想定されるシステム障害に対する復旧時間の目安について、ユーザに提示された。
 テスト仕様書の作成
 ベンダよりテストをすべきポイントについての提案がなされ、ユーザ電算部門の確認の上、利用部門に説明
がなされたが、実際の負荷を想定したテストについて、データボリュームが大きいコンビニ事業部と百貨店
事業部が難色を示し、電算部門は社長の判断を得て、計画通りのテストが実行された。
 電算部門が中心となり全システム利用部門が参加してテストが実施された。量販店事業部のプロジェクトメ
ンバから自部門へのテスト計画の周知が不十分で、テスト実行に対する要員確保が十分でなく混乱したが、
予定のテストは完了できた。

テストの合否判定責任
 日常のシステム利用については、大きな問題点は発生せずに、テストとしては合格と判定された。
しかしながら、一部の問合せ画面の操作性について、利用部門より要望が出されが凍結とした。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＨにおけるユーザポ
イント
 ユーザ側におけるポイント
 策定されたテスト仕様書に従って、実運用環境に




おいて、ユーザ内の実際の利用者にて作業をおこ
なってください。
ユーザが主体となって、場所や必要人員、所要時
間などに詳細に計画を策定し、実行しなければな
りません。
テストは現業業務と併行して実施されることから、
杜撰な計画や混乱は避けなければなりません。つ
いては、ベンダからテストに関する説明を十分に
得て、テストの実施計画の策定および社内への周
知を図ることが重要です。
システムの稼働時間帯とバックアップおよび保守
等の要する時間等を具体的に検証し、システムの
運用計画を最終確定する必要があります。
利用部門の担当者から要望等が発生した場合は、
要件定義に立ち返り、追加、修正を実施すべきか
の可否について検討し、業務遂行上、重大な問題
でない限り、原則は意見集約に止めるのが望まし
い。
60
 ベンダ側からの要請されるポイント
 テスト仕様書に基づきテストを実施する際、ユーザ
からの質問や問題が発生した時の対応について、
ベンダからユーザ側の連絡窓口を一本化するよう
求められます。
 この時、考慮すべき点は以下のようなことが考え
られます。
 ユーザ側で誰が窓口を行うか。この担当は新旧システム
の理解が十分な社員が行い、質問と問題点の切り分けや
問題点の影響度や重要性の判断を行える社員とします。
また、各業務担当とこの窓口担当の連絡方法についても
決めておく必要があります。
 通常時及び緊急時の連絡や回答の方法とベンダ側の連
絡先の確保。一般的には、連絡票のようなものを使い、そ
の中に問題点・原因・対応方法・対応結果等を記録し共有
します。口頭でのやり取りは、後々問題の原因になるので
避けましょう。
 また、この段階で要件定義に関わる問題点が出る
と要件定義担当ベンダへの確認や調整が必要と
なります。
重要事項説明書
フエーズＨサンプ
ル
61
H テスト支援業務契約
H 運用テスト支援業務契約の重要事項 （2）具体的作業内容
ユ
ー
ザ
管
理
者
会社名
A社
所属
コンピューターセンター
氏名
己田 五郎
連絡先
03-○○○○-○○○○
ベ
ン
ダ
担
当
者
会社名
β社
所属
開発部
氏名
乙山次郎
連絡先
03-○○○○-○○○○
■運用にかかわる作業手順の策定（作業内容及びユーザとベンダの役割分担）
・A社電算機担当部門にて運用手順書の作成を行う。
報告書の提出期限並びに報告書の点検期間
■テスト仕様書の策定（作業内容及びユーザとベンダの役割分担）
・β社がテストすべきポイントを示し、これに基づいて、A社にてテスト仕様書を策定する。
報告書の提出期限並びに報告書の点検期間
運
用
テ
ス
ト
支
援
概
要
項番
１
：
システム名称
財務システム
：
作業場所
A社本社
：
期間
支援内容
（ユーザとベンダの役割分担）
テスト仕様書
（日付、作成者、版等）
○月○日～○月○日
β社担当者が常駐し、ガイダンス、
質問対応を行う。
○月○日付「財務システム テスト仕
様書」
：
：
：
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者： 戊山取締役、
主任担当者： コンピューターセンター 己田課長。
β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
付帯事項： （作業を実施する場合の場所・期限等、要件の合意、承認ルールを含みます）
特約事項：
業務完了報告書提出期限： ○○○○年○○月○○日
受託金額（税抜もしくは受託金額の決定基準）： ○百万円
左記報告書の点検期間： 提出日から10日間
損害賠償限度額： ○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
モデルケースＡ社
次期販売・財務システ
ム
フェーズＩでの概況
【目的】導入教育実施内容に基づき、操作・運用方法等の教育を行います。
バックアップ等の運用に関しても同様です。
62
 導入教育としての操作・運用教育
 電算部門が中心となって、利用部門と検討をおこない、教育方法、対象、期間、場所、使用設備、等につい
て明確な導入教育計画が作成され、ベンダの協力も得て実施されました。
 本稼働後の、利用部門担当者の退職や休職による再教育について、導入教育計画として定める必要があ
ると、ベンダより指導されましたが、利用部門の人材が十分でないことから、再教育については電算部門に
て、運用の肩代わりと併行して教育することとなった。

バックアップの必要性について（復旧要件の最終確定）
 ベンダよりユーザにバックアップの目的について、万一の障害発生時に失ったデータやシステムを復旧する
ために、ＩＴを利用するうえで、必要不可欠な作業であり、「どのような障害に対して」は「何を」「どれくらいの
時間で」「どれくらいの期間を対象に」が明示されなければ、どのような方法（装置および手段）でバックアップ
を実施するのか計画できないといった指摘がなされた。
 ベンダの協力を得て、電算部門と利用部門との間で、復旧要件の最終確定作業が行われた。利用部門は
日常的に利用するシステムについては理解をしていたが、無人で自動実行されているプログラムや顧客と
のデータ連携における留意事項等の説明を受け、システム全体に対する理解を深める機会となった。
 復旧要件については以下の内容となった。
 百貨店部門：百貨店から売上データ受信後の日時更新の前後の日次バックアップとし、復旧についても
日次ベースでの復旧とする。
 量販店部門：百貨店同様
 コンビニ部門：リアルタイムバックアップが必要であり、復旧については、共同配送センターへの出荷を第
一とした復旧とする。
 通販部門：リアルタイムバックアップが必要であり、障害発生時は通販サイト一時停止が必要。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＩにおけるユーザポ
イント
 ユーザ側におけるポイント
 どのような導入教育支援が必要であるかを判断す




るために、従業員の構成（組織別人員数）や能力
（ＩＴスキル概要）等の情報をベンダに提供してくだ
さい。
ユーザは付帯事項（データのバックアップ等）、特
記事項（現行システムの停止）の記載について十
分に理解する必要があります。ベンダへ事前に説
明を求めてください。
ＩＴに関連する法令等（個人情報保護法）が必要な
場合は、ベンダと協議の上、教育計画を拡充する
必要があります。
バックアップ等システム運用上の知識が不足して
いる場合、ベンダに相談の上、必要な教育を実施
しましょう。
クライアントＰＣおよびプリンタ等の操作指導につ
いても、ベンダと相談の上、実施計画を策定する
ようにしましょう。
63
 ベンダ側からの要請されるポイント
 ベンダからは教育の準備と講師についてコストが
かかる旨の説明があるのが一般的です。その際、
初期導入教育について、どこまでが無償でどこか
らが有償なのかを事前に合意しておく必要があり
ます。
 またシステム稼動後の問合せについても、度が過
ぎると再教育が必要になります。この場合も、どこ
までが問合せで対応可能か、再教育にかかる費
用はどうなっているのかを確認しておく必要があり
ます。
 教育対象やそのレベルにより効果的な教育内容
は異なります。対象となる社員と現時点でのITレ
ベルと到達させたいレベルを具体的に説明する必
要があります。（例：現在のレベルはワープロや表
計算ソフトを使用したことが無いレベル。到達レベ
ルは、日常業務がマニュアルを見て一人で行える
レベル。等々）
 対象となる社員の情報以外にも、使用設備は、教
育期間は、どこで実施するのか等、ほとんどが費
用を必要とするものになるので十分に確認が必要
です。
重要事項説明書
フエーズＩサンプ
ル
64
Ｉ 導入教育支援業務契約
重要事項説明書の例
Ｉ 導入教育支援業務契約の重要事項 (2) 具体的作業内容
概要
日程
販売・財務システムにつき、全体像を把握するとともに、各人員
が必要とする具体的な利用法について習得するための導入教
育を実施する。
全体説明：
○○年○月○日○時○○分～○○時○○分
販売システム： ○○年○月○日○時○○分～○○時○○分
財務システム： ○○年○月○日○時○○分～○○時○○分
付帯事項
・Ａ社は、各対象者のコンピュータ利用経験につき、事前にβ社に通知する。
連絡協議会の実施要領及びユーザ・ベンダの責任者、主任担当者
・○○○○年○○月○○日、A社本社にて実施
・A社責任者： 戊山取締役、 主任担当者： コンピューターセンター 己田課長
・β社責任者： 開発部 甲野部長、 主任担当者： 開発部 乙山マネージャ
実施場所
全体説明： Ａ社 本社大会議室
販売システム： Ａ社 本社214会議室
財務システム： Ａ社 本社213会議室
特約事項
・導入教育完了後40日以内の問い合わせには、β社が無償で対応する。
・40日経過後については、別途協議する。
実施対象
人員
コンピュータセンター： ２名
販売部： 15名
財務部： 8名
業務完了報告書提出期限：○○○○年○○月○○日
実施方法及
び実施内容
目指すべき
水準
いずれも集合教育で実施。
全体説明は、対象者全員参加とし、新システムの全体像示す。
販売部の対象者は販売システムの、財務部の対象者は財務シ
ステムの説明にも参加する。ここでは、各システムの具体的な
使い方について実例を交えて説明する。
コンピュータセンターの対象者は全日程に参加する。
マニュアルを見ながらシステムの利用ができる程度を目標とす
る。
上記報告書の点検期間： 提出日から１０日間
受託金額（税抜）： ○百万円
損害賠償限度額： ○百万円
支払期限： ○○○○年○○月○○日
支払方法： 銀行口座振込
保守・運用支援の
流れと責任
Ｊ 保守業務契約、K 運用支援業務契約
65
 サービスの対象
 保守・運用は、実稼働するシステムに対するサービスの提供ですから、見積・契
約にあたっては、実際のシステムに基づいてサービスが提供されなければなり
ません。
 要件定義書、RFP、プログラム設計書、構築報告書等の文書の管理、メンテナ
ンスの記録など、システムに関する文書の管理について、相互の役割を明確に
します。
ⅰ
要件定義
設計開発
ⅱ
ⅲ
準委任
A 要件定義支援及びパッケージソフトウェア候補選定支援業務契約
B パッケージソフトウェア選定支援及び要件定義支援業務契約
準委任
D 外部設計支援業務契約
請負
E ソフトウェア設計・制作業務契約F 構築業務契約
移行・運用
準備
準委任
G データ移行支援業務契約、H テスト支援業務契約、
I 導入教育支援業務契約
保守・運用
準委任
J 保守業務契約、K 運用支援業務契約
モデルケースＡ社
次期販売・財務システ
ム
フェーズＪでの概況
66
【目的】このフェーズでは、保守に関してユーザとベンダ双方の合意を形成する
ためのＳＬＡおよび保守に関するその他留意事項について、ベンダより
説明を受け、システム運用時の障害発生に対する備えを行います。
 保守に関する合意形成
 電算部門の保守に対する要望は過大なものであり、ベンダから保守の分類について説明が行われた。
 是正保守：引き渡し後、発見された問題を訂正するために行う修正作業
 予防保守：引き渡し後、潜在的な場外が運用障害となる前に発見して是正作業
 適応保守：引き渡し後、変化している環境に順応するため、環境変化に歩調を合わせて行う改良作業
 完全化保守：引き渡し後、潜在的な障害が故障として現れる前に、検出し修正作業
 ユーザの事業と利用目的および必要コストから、是正保守をベースにSLAが策定された。また、ベンダより
サービスの範囲と別途有償となるか範囲が明確化され、保守業務内容の合意がおこなわれた。
 ネットワークや既存システムを含むシステム全体の障害切り分けについては、それぞれのベンダの保守業
務の範囲とともに不具合の調査費用についても明確に取り決めがおこなわれた。
 リモートアクセスでのサポートおよび現地サポートにおける、ユーザデータのアクセス関して、事前承認ルー
ルの策定がベンダより要請され、ユーザ電算部門で策定のうえ、双方で承認されました。

データ復旧に関する留意事項
 ハードウェア故障修理における原則は、導入当初の初期状態であり、データバックアップに関してはユーザ
責任であることと、データ復旧要件については、別途に運用支援契約の締結が必要である。

事前停止の考慮に関する留意事項
 保守のためにシステムの一部、全部に停止が発生します。これら事前停止（定期保守のための計画停止、
障害復旧のための緊急停止）の決定へのユーザ内承認ルールと通知方法の検討がベンダより要請され、
ユーザプロジェクトにて策定された。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＪにおけるユーザポ
イント
 ユーザ側におけるポイント
 保守業務で交換される故障部品は製造会社に戻




されるのが一般的であるため、個人情報を含んだ
ハードディスクの取り扱いなどについては、個人情
報保護規定と保守業務契約の関係に留意してくだ
さい。
個人情報保護、内部統制等の社内規定で、ベンダ
の保守業務でのデータアクセスに制限がある場合
は、事前承認のルールを明確化しておいてくださ
い。
SLAに基づく保守業務内容の事前合意が重要と
なります。
ネットワークを含むシステム全体の障害切り分け
をベンダへ委託する場合、保守業務の範囲ととも
に不具合の調査費用についても明確に取り決め
ておく必要があります。
リモートアクセスでのサポート、現地サポートを問
わず、ユーザデータにアクセスする場合の、事前
承認ルールを明確化する必要があります。
67
 ベンダ側からの要請されるポイント
 個人情報や機密情報に関して、ベンダからは対象
範囲を明確にすることを求められます。したがって、
事前に対象となる情報の範囲を明確にし、対象と
なる情報の取り扱いについて決めておく必要があ
ります。
 また、障害の切り分けをベンダに委託する場合で
も、自社で誰が連絡をするのか障害内容に応じて
決めておく必要があります。したがって、ベンダと
協力し障害範囲や対象に応じてユーザ側の窓口
担当（電算部門担当、各業務のシステム運用担当
など）とベンダ連絡先等を表などにまとめ関係部
署に周知徹底することが必要です。
 合わせて、ハードウェア引上げやリモート保守時
の承認者、オンサイト保守時の立会い、ソフトウェ
アの入換え手続き、作業完了の確認方法等につ
いても明確にしておく必要があります。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＫでの概況
68
【目的】このフェーズでは、運用支援に関してユーザとベンダ双方の合意を形成
するためのサービス仕様書およびＳＬＡ合意書を作成し、システム運用
後に想定される問題に対して、ベンダから支援について合意を得ます。
 システム運用に関する支援内容の合意形成
 電算部門は新設であり、またシステムの利用規模に対して２名の脆弱な体制であることから、ベンダの提供
する運用支援に対する期待は大きく、ユーザ経営者は新システムの稼働後に発生するもの全てが支援業
務の対象と考えていた。
 このような過度な期待と誤解の無いよう、ベンダから事業と利用目的とコストおよび電算部門が作成した
SLAにて、支援業務の範囲とどこからが有償となるかを明確にして、ＳＬＡに基づくサービス内容の提供に関
して、事前合意おこなわれた。
 セキュリティ監視サービスとして、不正アクセス検知報告、ログアイカーブ、ログ分析およびセキュリティイ
ンシデント発生時の緊急対応サービス
 サーバ運用支援サービスとして、稼働監視サービス、障害自動通報サービス、サーバ運用問合せサービ
ス
 バックアップデータ復旧支援サービス
 上記サービスに関して、ベンダよりサービス仕様書が作成され、ＳＬＡ合意書とともに、ユーザとベンダにて
合意が行われ、上記運用支援契約が締結された。

既存システムの廃棄
 ユーザは既存システムが産業廃棄物である認識に欠けており、ベンダより紹介を受けた産業廃棄物業者に
電算部門が連絡を取り、リサイクル処理に関する見積およびマニフェストを入手する手順の説明を受けた、
しかしながら、ユーザ社長および取締役経理部長が理解を示さなかったため、ベンダに依頼して、法令の説
明を社長および取締役経理部長に行い、廃棄コストの必要性について理解を得た。
モデルケースＡ社
次期販売・財務システ
ム
フェーズＫにおけるユーザポ
イント
 ユーザ側におけるポイント
 支援業務サービスの具体的内容について、ベンダ
側との認識に齟齬がないか十分な確認が重要で
す。
 ベンダよりサービス仕様書が作成され、ＳＬＡ合意
書とともに、ユーザとベンダにて合意を行い、支援
業務のサービス提供の具体的内容をベンダと取り
決めます。
69
 ベンダ側からの要請されるポイント
 ベンダからSLA（サービスレベル合意書）の内容に
ついて説明があり同意を求められます。この際、
理解できない点があれば理解できるまで説明を求
め確認をします。特に各サービス項目のレベルが
確認でき誰が判断しても同じ結果が得られるよう
な内容になっている必要があります。
＜サービスレベルの例＞
 平日のダウンタイム MAX○時間
 ハードウェア、ソフトウェアの入換えは原則休日
 給与変動項目の入力完了後、○時間で銀行への振込み
依頼完了
 月次の締め後、翌日午後に財務諸表出力可能
 サービス時間帯は、平日○時～○時、土曜日曜祝日○時
～○時
70
重要事項説明書
フエーズJ・Kサンプ
ル①
重要事項説明書の記入例
J
項
番
1
保守業務契約の重要事項 (2)ハードウェア保守＜記入例＞
保守サービス名称
業務内容
添付図書名
SLA合
意書
有無
○○○○年
○○月○○日
有り
保守対象機器
明細一覧表
有り
○○○○年
○○月○○日
○○○○年
○○月○○日
無し
保守対象機器
明細一覧表
有り
○○○○年
○○月○○日
○○○○年
○○月○○日
有り
保守対象機器
明細一覧表
有り
開始日
終了日
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
○○○○年
○○月○○日
東京都千代田区
￥○○○,○○○
○○-○○
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
ハードウェア保守サービス 東京都千代田区
￥○○○,○○○
（ネットワーク機器保守） ○○-○○
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
請求方法及
（円／年、税抜） び支払方法
サービス料金
ハードウェア保守サービス 東京都千代田区
￥○○○,○○○
（サーバ保守）
○○-○○
ハードウェア保守サービス
2 （クライアントPC及び周
辺機器保守）
3
遠隔操
作保守
の有無
サービス期間
請求開始
年月日
設置場所
受託金額合計（税抜）
損害賠償限度額：（項番ごとに記載）
付帯事項：（作業実施にあたりユーザが担当する作業）
電源及びハードウェア設置環境の維持・整備については、お客様が実施
するものとします。
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
・A社責任者：戊山取締役
主任担当者：コンピューターセンター 己田課長
・β社責任者：開発部 甲野部長
主任担当者： 開発部 乙山マネージャ
特約条項：
遠隔操作保守の内容：（項番ごとに記載）
項番1：遠隔操作保守はユーザデータへのアクセスを要する場合、原則、
接続毎にお客様の許可を得て実施します。夜間等で緊急の措置が必要な場
合の対応については、SLA合意書で定めます。
項番3：ルーター、ファイアウォールの状態監視は1時間毎とし、異常発生
時は、お客様の事前の許可無く外部接続で、障害範囲及び原因の特定調査、
復旧操作などの1次保守を実施します。遠隔操作保守で対応できない場合
は、SLA合意書に基づきオンサイト保守を実施します。
再委託先の表示：
71
重要事項説明書
フエーズJ・Kサンプ
ル②
重要事項説明書の記入例
J
保守業務契約の重要事項
保守サービス名称
項
業務内容
番
1
アプリケーションソフト
保守サービス
（XX社販売管理システム
保守）
(3)アプリケーションソフト保守＜記入例＞
設置場所
東京都千代田区
○○-○○
サービス料金
（円／年、税抜）
￥○○○,○○○
サービス期間
請求方法及
び支払方法
請求開始
年月日
開始日
終了日
年額一括
銀行口座自
動引落
○○○○年
○○月○○日
○○○○年
○○月○○日
○○○○年
○○月○○日
遠隔操
SLA合意書
作保守 添付図書名
有無
の有無
有り
ｘｘ社販売
管理システ
ム保守仕様
書
有り
2
受託金額合計（税抜）
損害賠償限度額：（項番ごとに記載）
付帯事項：（作業実施にあたりユーザが担当する作業）
遠隔操作保守の内容：（項番ごとに記載）＜例＞
バックアップはお客様が実施するものとし、データ復旧にあたっては、 項番1：遠隔操作保守はユーザデータへのアクセスを要する場合、原則、接続
都度、状況に応じてお客様と協議の上、復旧方法を定めるものとします。毎にお客様の許可を得て、作業内容についてご承認の上、実施します。マスタ
およびデータファイルについては、お客様の責任によるバックアップをお願い
連絡協議会の実施要項及びユーザ・ベンダの責任者、主任担当者：
申し上げます。夜間及び緊急時の対応については、SLA合意書で定めます。リ
・A社責任者：戊山取締役
モート保守で対応できない場合は、SLA合意書に基づきオンサイト保守を実施
主任担当者：コンピューターセンター 己田課長
します。
・β社責任者：開発部 甲野部長
主任担当者： 開発部 乙山マネージャ
特約条項：
再委託先の表示：
72
重要事項説明書
フエーズJ・Kサンプ
ル③
SLA合意書（記入例）
項
番
保守・運用
サービス名称
SLA/SLM
項目名
項目の説明
1
電話受付時間
2 ハードウェア保守
サービス
（サーバ・ルー
3
タ：製品名）
平均出動時間
サービ
ス提供
時間
平均復旧時間
4
定期点検
5
電話受付時間
6 ハードウェア保守
サービス
（クライアント・
7 プリンタ：製品
名）
出動時間
8
サービ
ス提供
時間 平均復旧時間
定期点検
測定条件又は方法
コールセンターでの電話受付時間
電話を受けてから技術者が現地に到
着するまでの時間（遠隔地は除
く。）
技術者が訪問してからハードウェア
が工場出荷状態に戻るまでの四半期
平均時間
定期点検月に障害が発生し訪問した
ときは、同時に定期点検を行うこと
がある。
コールセンターでの電話受付時間
電話を受けてから技術者が現地に到
着するまでの時間（遠隔地は除
く。）
技術者が訪問してからハードウェア
が工場出荷状態に戻るまでの平均時
間
定期点検月に障害が発生し訪問した
ときは、同時に定期点検を行うこと
があります。
測定単位
目標／
保証
値
時間
目標
平日：9時～19時、
土：9時～17時、日・
祝日：休み
月平均
目標
2時間
四半期平均時間
目標
12時間
回数
保証
年2回
時間
目標
平日：9時～17時、土
日・祝日：休み
四半期平均時間
目標
24時間
四半期平均時間
目標
48時間
回数
保証
なし
保守対象機器
明細項番
73
重要事項説明書
フエーズ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
着手時間(追加要望時） 連絡協議会で対応を決定する
メーカーとの保守契約
による
保守対象機器
明細項番
74
重要事項説明書
フエーズ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
連絡協議会
保守対象機器
明細項番