ベンダー選定とは システム開発の発注先を決める進め方と比べる観点

ベンダー選定とは、システムの開発や導入を頼む会社(ベンダー)を、複数の候補から比べて決めることです。価格だけで決めると、開発の途中で作業範囲や責任の食い違いが出やすくなります。ここでは、IPA(情報処理推進機構)が公開している「情報システム・モデル取引・契約書」の考え方に沿って、進め方と比べる観点を整理します。

ベンダー選定とは

IPAのモデル取引・契約書(第二版)は、発注する側を「ユーザ企業」、受ける側を「ITベンダ」と呼び、両者の取引の構造を透明にするための解説と契約書のひな型を公開しています。この文書の中で、ベンダーを決めるまでの流れは次のように書かれています。

• ユーザは、候補になるベンダを複数社リストアップする。
• 各社が情報システムを適切に開発する能力があるかを、技術力や経営の健全性などの観点から分析・検討する(文書は「デューデリジェンス(実態把握)」と呼んでいる)。
• その前提として、ベンダにシステム開発の提案を求める。これが提案依頼書(RFP)である。
• RFPの作成に先立って、必要な情報の提供を求める情報提供依頼書(RFI)を出す場合がある。
• ベンダはRFPに対して提案書を作って出す。ユーザは、各社の提案書とその他の情報を総合的に判断してベンダを選ぶ。

提案書は、IPAの文書で「ベンダ選定にかかわる最も重要な提出文書」とされています。RFPの書き方は別の記事RFP(提案依頼書)の書き方で扱います。

価格だけで決めることとの違い

IPAの文書は、ベンダ選定上の留意点について、単に入札価格の安いベンダを採用するのではなく、履行体制などにも配慮したうえで、TCO(Total Cost of Ownership、導入後の運用も含めた総費用)に基づいて判断すべきだと書いています。極端な安値の場合には注意が必要とも記載されています。

観点	価格だけで決める場合	提案内容を総合して決める場合
比べるもの	見積もりの合計額	提案書、体制、実績、TCO
見えにくいこと	作業範囲、前提条件の違い	比較に手間がかかる
起きやすいこと	範囲外の追加費用、体制の不足	比較の物差しを先に決めておけば減らせる

提案書で比べる観点

IPAの文書が挙げる提案書の記載事項は11項目あります。ベンダの提案を比べるときの物差しとして使えます。

1. はじめに(提案の要約)
2. システム構想
3. システム構成
4. システムの性能予測
5. システム拡張性
6. システムの信頼性・セキュリティ
7. 開発計画(スケジュール、見積条件、契約条件を含む)
8. 推進体制(予定されている再委託先も記述する)
9. 期待効果分析
10. 今後の課題
11. 関連する実績

この文書は、ベンダが得られる範囲で予想できるリスクを説明していなければ、法的責任を問われうるとも書いています。提案の段階でリスクの説明があるかどうかも、比べる材料になります。

見積もりの見方

IPAの文書によると、システム化の方向性、システム化計画、要件定義の各段階の見積もりは「確定見積」ではありません。画面や帳票などを決める外部設計の段階で確定見積が可能と考え、外部設計をユーザが承認したあとに要件の追加や仕様変更があれば、変更管理の手続に沿って追加・再見積りを行うとしています。

そのため、見積もりを比べるときは、金額より先に「どの段階の見積もりか」「何を前提にしているか」をそろえて見る必要があります。

メリットと注意点

複数社を同じ条件で比べる進め方には、次のメリットと注意点があります。

• メリット: 同じRFPに対する提案を並べるので、範囲や前提の違いが見つけやすい。
• メリット: 提案の段階で、体制や再委託の有無、契約条件を確認できる。
• 注意点: RFPに書かれていない要件は、提案にも見積もりにも反映されない。IPAの文書は、要件定義以降のRFPでは、表現されていない要件はシステムとして実現されないと書いている。
• 注意点: 候補を増やすほど、ユーザ側の確認の手間も増える。

再委託についても確認が要ります。IPAの文書は、基本的な大口再委託先やオフショア利用などの推進体制を、契約前の提案・見積もりの段階で説明することとしています。

向いている場面・向いていない場面

向いているのは、金額が大きい、業務への影響が大きい、あるいは長く使うシステムを頼む場面です。複数の提案を比べる手間をかける価値があります。

一方、既存のサービスを契約するだけの場合や、短い作業を頼む場合は、同じ手順をそのまま使うと重くなります。この場合は、RFPを簡単にして、確認する観点だけを残す形でも構いません。

選ぶとき・進めるときの手順

1. 目的と範囲を整理する。何のために作るのか、どの業務が対象かを、社内で言葉にする。
2. 候補を探す。紹介サービスや比較サイトの使い方はシステム開発会社の探し方で扱う。
3. 必要なら、RFIで情報を集める。
4. RFPを作って、候補に同じ内容を渡す。
5. 提案書と見積もりを、上の11項目と前提条件で比べる。
6. 面談や質疑で、体制、再委託、リスクの説明を確認する。
7. 契約の形(請負か準委任か)と条件を詰める。IPAの文書は、RFPの時点で契約類型、再委託、損害賠償責任、知的財産権の帰属、検収・支払い条件などを明らかにしておくこととしている。

発注先の紹介を受けられるサービスとして、大全にはシステム幹事、比較ビズ、発注ナビ、PRONIアイミツが載っています。いずれも発注する側は無料とされています(各社の案内による)。詳しい内容は開発会社を探すサービスの一覧とシステム開発会社を探すを見てください。

よくある質問

何社に声をかければよいですか。

IPAの文書に社数の決まりは書かれていません。複数社をリストアップするとされているだけです。比べる手間と得られる情報のバランスで、社内で決めます。

見積もりが一番安い会社を選んではいけませんか。

IPAの文書は、価格だけでなくTCOと履行体制を見て判断すべきとしています。安い見積もりでも、前提や範囲が同じであれば選択肢になります。範囲の違いと、極端な安値には注意してください。

RFIとRFPはどう違いますか。

IPAの文書では、RFIは情報の提供を求めるもの(技術動向、パッケージ情報、価格情報など)、RFPはシステム開発の提案を求めるものです。RFIの依頼先が、そのままRFPの提出先になるとは限らないと書かれています。

契約前にベンダ側の説明をどこまで求めてよいですか。

IPAの文書は、ベンダが提案の段階で、提案するシステムの機能、ユーザのニーズへの適合度、開発手法、受注後の体制を検討し、想定されるリスクを説明する義務を負うとした裁判例を紹介しています。ただし、この裁判例も、受注前に得られる情報には限りがあることを認めています。

次にやること

• 発注の目的と範囲を、A4一枚程度に書き出す。
• 提案書を比べる観点を、上の11項目から選んで一覧にする。
• 候補を探すサービスを一つ選び、条件を入力して紹介を受ける。