ITベンダーマネジメントの目的は自社の経営課題を解決し、システム開発・運用を円滑・適切な遂行により事業に貢献するために「ITベンダーと良好な関係を築く」ことです。

本ページの内容

  1. ベンダーマネジメントのスコープ
  2. 契約スキームについて
  3. 契約の注意点
  4. ITベンダーとの付き合い方
  5. ITベンダー選定の要点

1. ベンダーマネジメントのスコープ

 大手企業では、100以上のシステム運用管理している場合があり、複数のベンダーとサポート契約しています。そしてベンダーを目的別(システム企画は戦略的ITパートナー、システム運用はIT運用パートナー)に区別して取引し、IT部門内にはVMO(Vendor Management Office、ベンダーマネジメント組織)という専任組織を設けて対応しているケースは少なくありません。中には取引するベンダーの調達基準(一部上場企業、三期連続赤字決算なしなど)を決めている大手企業もあります。
 しかし、中小企業では人的資源が潤沢ではなく、利用しているシステム数も多くても20以下であるため、VMOを設ける必要はありません。ここでは、中小企業向けにITベンダーマネジメントの要点を説明します。

 重要なのはまず、ITに関する事業会社とITベンダーの目的の違いを認識することです。
  1) 事業会社におけるIT部門の目的:システム導入・稼働による業務におけるIT活用を通じて経営課題を解決し、事業に貢献すること。
  2) ITベンダーの目的:顧客から受注したシステムを開発・納品・運用することで利益を上げること。
 次に、ITベンダーへシステム開発を依頼する際の全体スコープ(下図)を理解することが重要です。

2. 契約スキームについて

 ITベンダーにシステム開発を依頼する基本は「契約」です。一般的な契約のスキームは以下のとおりです。

 ある特定のITベンダーとの契約件数が増えることが見込まれる場合、契約を効率的に締結できる「基本契約書」方式を採用します。基本契約締結後、IT施策を実施する度に個別契約を締結する方法です。このスキームは以下のとおりです。

・NDAとは、Non Disclosure Agreementの略であり、秘密保持契約です。
・SLA とは、Service Level Agreementの略であり、サービス品質保証(サービスを提供する事業者が契約者に対し、サービスを保証する契約のこと)のです。

3. 契約の注意点

 ITベンダーにシステム開発を依頼する際の契約の具体的な内容は割愛させて頂きますが、契約を検討する際に生じることが多い三つの重要な課題の解決方法をご紹介します。

 (1)当初のITベンダーとの目的や認識の齟齬によるITベンダーの変更をスムーズに実現するにどうすればよいか

 (2)大規模システム開発の際に、見積額と執行額の適切性を確保する

 (3)当該システム稼働後のITサポートの運用費をどのように決定するか

★課題(1)の解決案

 ビジネス環境の変化により、既存ベンダーとの間で目的や認識に齟齬が発生して、調整不可になることがありますが、既存システムをサポートしているベンダーにロックイン(※)され、ベンダーチェンジが困難になりがちです。この課題解決は、「業務引継ぎ」条項を盛り込むことにより、解決できます。ベンダーチェンジの際には、サポート対象の既存システムの要件を既存ベンダーから他ベンダーへ引継ぎさせ、自社業務に支障を来すことを回避するという内容にです。
※ベンダーロックインとは、情報システムに特定の企業のノウハウ・サービスを組み込んだ構成になっているため、他社への切り替えが困難になること。

務引継ぎの事例

第〇〇条(業務の引継)
甲は、本契約または個別契約の全部または一部が解除された場合には、以下の各号の条件のもと、乙によって履行されていた業務内容について、確認を求めることができる。確認を求めることができる業務内容については、別途仕様書に明示するものとする。
(1)期間は解除から6ヶ月間とする。
(2)確認により、乙の業務請負が発生する場合、別途協議の上、甲は乙からの見積・請求に基づき対価を支払うものとする。
(3)甲から業務を委託された第三者は、確認を求めることができない。
(4)第△△条に定める機密情報及び個人情報の提供を求めることはできない。
(5)業務履行に際し使用していた乙の財産、設備、借用物など、乙に属するものの供与を求めることはできない。

★特記事項:
 実例として、ITベンダーA社はベンダーチェンジされない自信があるため、どのような業務引継ぎの内容でも快諾しました(追加料金・対応期限なし)。また、B社は追加料金なしですが、期限付きで承諾しました。C社は業務引継ぎ作業は別料金かつ期限付きという条件で承諾しました。どのような契約引継ぎ内容がよいかは、自社にメリットのある内容調整を試みてください。ベンダーチェンジの場合でも、既存ベンダーにはのそれまでの貢献を考慮して、Win-Winとなる内容が望ましいのは言うまでもありません。

★課題(2)の解決案

 システム開発の見積金額が妥当である場合は「請負契約」締結で問題ありません。しかしながら、大規模システムの経験がない発注企業ため、ITベンダーから提示された見積額が妥当性の判断がつかず「請負契約」の締結に躊躇するかもしれません。この場合、開発に携わるSEの単価を合意して、実際の作業時間に応じて実費払いにする「準委任契約」を締結することで解決できます。

★見積書の事例

項番明細定価(円)工数単位金額
1プロジェクト管理1,000,0002.50人月2,500,000
2システム開発1,000,00015.00人月15,000,000
--- --- ---   ---   合計  17,500,000

  上記見積り金額が、妥当と判断された場合は「請負契約」を締結します。自社で適切な金額か判断できない場合、経営層に上申する稟議書・決議書では、当該システム導入にかかる上限(アッパー)の額として承認を得ます。実装の際には実際の作業時間に応じた実費払いとなり、見積金額より低い金額で着地できます。

★特記事項2:1人月は1ヶ月20日、1日当たりの勤務時間8時間です。しかし、毎月の祝休日および作業者が取得する休暇を考慮する必要があります。システムエンジニアの作業時間は月によって、136~144時間換算となることを前提としています。プロジェクトマネジメントの全体スケジュールに反映してください。

★特記事項3:請負契約と準委任契約の違いは以下のとおりです。

項番内容請負契約準委任契約
1見積書の明細は「ソフトウェア一式」なのか、
あるいは成果物リストなのか
ソフトウェア一式成果物リスト
2成果物は開発したソフトウェアなのか、
あるいは作業報告なのか
ソフトウェア 作業報告
3成果物の瑕疵担保責任はあるのか ありなし
4検収は成果物の検査合格後か、
あるいは予定された作業終了後か
検査合格後 作業終了後
5著作権の帰属(受注者、発注者) 受注者 発注者
6作業進捗や工数消化の報告は契約上の行為なのか、
あるいは便宜的なものか
契約上の行為便宜的
7開発メンバーの開示は契約上の行為か、
あるいは便宜的なものか
契約上の行為 便宜的

  一般的に大規模システム導入の際、要件定義工程については「準委任契約」を締結して、システム導入費用(初期費用)については「請負契約」を締結します。

★課題(3)の解決案

 個別システム利用期間(一般的には5年間)のシステム運用費は、下記のとおり、固定額として提示する場合があります。

 しかし、経年にてITベンダーのシステム運用担当の習熟度が上がり、対応時間は短縮され、かつユーザーからの問合せ件数は減少する傾向にあるため、システム運用費の減額を運用契約に盛り込むのが適切です(下図参照)。運用費をどれだけ減額するのが妥当であるか、システムの規模や運用担当者のレベルと数によりますので、ITベンダーと調整ください。

 下表は、システム運用費用の見積り事例です。

項番ランニング費用定価(円)工数単位金額(円)
1運用実施(1年目)1,000,0000.90人月900,000
2運用実施(2年目)1,000,0000.70人月700,000
3運用実施(3年目) 1,000,0000.50人月 500,000
4運用実施(4年目) 1,000,0000.20人月 200,000
5運用実施(5年目) 1,000,0000.20人月200,000
--- --- --- ---合計2,500,000

 技術レベルが高く、良心的なITベンダーは、事業会社が困っている点を把握しているため、上記3項目についても初めから見積書や提案書に盛り込んで提示します。

★重要:ITベンダーとの契約締結前には、必ず法務部(法務機能を有する部門:例えば渉外企画部や総務部など)による契約のリーガルチェックを受け、承認を得てください。 

4. ITベンダーとの付き合い方

 発注者と受注者間で良好な関係を構築すべきことは当然です。システム障害がほとんど発生しない環境であれば、問題はありません。しかし、一般的にシステム障害は発生します。システム障害の発生時には、IT担当の対応次第でITベンダーとの関係をビジネスライクなものからパートナーとしての信頼関係に発展させることができます。ITベンダーが契約の内容以上に期待に応え、高いモチベーションをもって対応してくれる方法を次に紹介します。

 まず、IT担当に障害の責めがある場合、関係者に謝ってITベンダーに対応を要請することが普通です。逆にITベンダーに責めがある障害が発生した場合、二つの対応が考えられます。
 (1)IT担当が早期に解決しようとして、ITベンダーに激怒するケースです。ベンダーに怒ってプレッシャーを与え、障害が早期に解決するならば、怒る行為は「あり」です。
 (2)IT担当は、まずは、障害を解決することに集中します。ITベンダー向けにネガティブな言葉は使いません。障害が解決した後で、ITベンダーに厳重に抗議して、再発防止策を講じるよう指示します(可能であれば、穏やかな顔で穏やかな言葉で厳しい内容を伝える)。このケースを以下の図に示します。

★要点:上記(1)の行為を繰り返していると、いつか逆のケース(自社に責任があるシステム障害)が発生して自社が困った場合、ITベンダーは契約以上のことはしませんし、する気にもなりません。逆に(2)の行為を繰り返していると、自社の責めによる障害が発生した場合、ITベンダーはなんとか助けようと自主的、かつ最大限に努力してくれるようになります。これがモチベーションアップと信頼関係の賜物です(下図参照)。

★結論:障害発生時には(2)の対応を試みることを強く推奨します。

5. ITベンダー選定の要点 

 ITベンダーと取引する際、まずは下表のITベンダー側の体制を理解することです。

項番ITベンダー側の基本体制役割顧客との関係
1営業担当顧客のカウンターパート・契約担当顧客と折衝
2ITコンサルタント顧客のニーズ整理、技術知識提供 顧客と折衝・調整
3プロジェクトマネジャー要件定義を含むプロジェクトの全体管理同上
4プロジェクトリーダープロジェクトの一部をリードする表に出る場合と
表に出ない場合がある
5プロジェクトメンバープロジェクトの一部を担当する表に出ない
6システムエンジニア仕様要件などのシステム開発顧客と調整あり
7プログラマープログラム開発表に出ない
8カスタマーエンジニアサーバー構築などマニュアルがある作業 顧客と調整 あり

 ITベンダー選定については、ITベンダー自体の良し悪しもありますが、どのITベンダーにも高いスキルのエンジニアもいれば、ジュニアレベルのエンジニアもいます。重要なのは、スキルの高い社員を自社プロジェクトのためにアサインしてもらうことです。そして、可能な限りその優秀なエンジニアを他のプロジェクトでもキープすることです。そのためには、事前にプロジェクトマネジャーやシステムエンジニアの実績を確認する必要があります。


 ここで大事なのは「ITスキル」を保持したプロジェクトマネジャーを選ぶことです。実例を挙げると、あるパッケージの会計システムを導入した際、A社ではプロジェクトマネジャー、製品パッケージ担当とインフラ担当の計3名が参加しました。プロジェクトマネジャーはプロジェクトマネジメントのスキルしかなく、製品パッケージ担当は当該ソフトウェアの知識しかなく、インフラ担当はサーバー・ネットワークマターしか担当できませんでした。結果、導入価格も高くなりましたし、問題が発生した際、調整や解決に多くの時間が掛かりました。B社から1名のみがプロジェクトマネジャー、製品パッケージ担当およびインフラ担当として参加しました。つまり、ITスキルを保持したプロジェクトマネジャーでした。結果、A社と比較して、導入価格はそれほど安くはなりませんでしたが、要件定義の時間、調整時間や導入時間は短縮され、納品物の品質は高かくなりました。

 なお、提案依頼(RFP)において「ITベンダーを選定するための評価方法」は”プロジェクトマネジメント”のページで紹介しています。、「こちら」をクリックしてご参照ください。

ワンポイントメッセージ:ITベンダーが「知識・経験・実績」を有することはお付き合いと契約締結の基本ですが、お互いに信頼関係を築いて発展させていくことが重要です。

 次項の”グローバル対応”は「こちら」をクリックしてご参照ください。