ベンダー選定で悩みやすいのは、どの会社を選ぶかだけではありません。なぜその会社を選んだのか、なぜ別の会社を選ばなかったのかを、社内にもベンダーにも説明できる状態にすることが重要です。
価格、機能、提案内容、実績、体制、保守のどれを重視するかが曖昧なまま比較すると、最後は担当者の印象や声の大きい関係者の意見に流されやすくなります。特にシステム開発では、初期費用が安く見えても、要件理解、変更対応、運用保守、プロジェクト管理の弱さが後から大きなリスクになることがあります。
この記事では、ベンダー選定の評価基準を決める手順、評価項目と配点の作り方、比較表に残すべき内容、選定理由の書き方を実務向けに整理します。ベンダー選定全体の流れを先に押さえたい場合は、ベンダー選定のプロセスもあわせて確認してください。
この記事のポイント
- ベンダー選定の評価基準は目的、要件、リスクから逆算して決める
- 評価項目は点数化できる粒度に分け、配点で重視する成果を示す
- 比較表には点数だけでなく根拠、懸念、確認済み事項を残す
- 選定理由は採用理由と不採用理由を同じ基準で説明できる形にする
評価基準と比較表を資料化しておくと、RFP回答の比較、社内稟議、発注後のベンダー管理までつなげやすくなります。後から見返しても判断の前提が分かる状態を目指しましょう。
目次
ベンダー選定の評価基準を決める
評価基準は目的と要件から逆算する
ベンダー選定の評価基準は、一般的な項目をそのまま並べるだけでは不十分です。まずは、今回のプロジェクトで何を実現したいのか、失敗すると困ることは何か、発注後にどのような関係を続けたいのかを整理します。
たとえば、短期で業務システムを作り替えたい場合は、納期、体制、要件理解、変更対応の評価が重要になります。一方、長く使う業務基盤を選ぶ場合は、保守体制、セキュリティ、拡張性、担当者の継続性も軽視できません。同じ「ベンダー選定」でも、目的によって評価基準は変わります。
最初に決めるべきなのは、「安い会社を選ぶ」のか「要件を実現できる会社を選ぶ」のかではなく、どの条件を満たせばプロジェクトが成功に近づくのかです。ここを曖昧にすると、提案書を受け取った後に評価軸が増え、比較が難しくなります。
評価項目は採点できる粒度に分ける
評価項目は、誰が見ても同じように判断しやすい粒度に分けます。「提案力」「信頼性」「対応力」のような大きな言葉だけでは、評価者によって点数の理由が変わります。項目を分けるほど、点数の根拠を残しやすくなります。
| 評価カテゴリ | 評価項目の例 | 確認すること |
|---|---|---|
| 要件理解 | 課題理解、業務理解、提案の具体性 | こちらの目的を理解し、現実的な解決策に落とせているか |
| 実現性 | 技術選定、開発体制、スケジュール | 提案内容を期限内に実行できる根拠があるか |
| 費用 | 初期費用、保守費用、追加費用条件 | 見積もりの前提が明確で、総コストを比較できるか |
| 実績 | 類似案件、業界理解、担当者経験 | 自社に近い課題や規模での実績があるか |
| 運用保守 | サポート体制、障害対応、改善提案 | リリース後も継続して相談できる体制か |
| リスク | セキュリティ、契約範囲、依存関係 | 発注後に問題になりやすい論点を先に説明できているか |
評価項目を細かくしすぎると入力が大変になりますが、粗すぎると比較表が形だけになります。まずは5から8カテゴリ程度に分け、その中に採点しやすい項目を置くと運用しやすいです。
配点は重視する成果に合わせる
評価基準を点数化する場合は、配点で優先順位を示します。すべての項目を同じ重みで評価すると、プロジェクトで重視したい成果が点数に反映されません。合計100点にしておくと、社内説明や比較表で扱いやすくなります。
たとえば、業務理解が重要な基幹システムなら、要件理解や運用保守の配点を高くします。短期開発が最優先なら、体制、スケジュール、実現性の比重を上げます。予算制約が強い場合でも、費用だけを大きくしすぎると、安さを理由にリスクの高いベンダーを選びやすくなるため注意が必要です。
| 重視する方針 | 配点の考え方 | 注意点 |
|---|---|---|
| 業務理解を重視 | 要件理解、提案内容、類似実績を高める | 費用が高くても妥当かを根拠で確認する |
| 納期を重視 | 体制、スケジュール、進行管理を高める | 短納期の前提や除外範囲を必ず確認する |
| 費用を重視 | 初期費用、保守費用、追加費用条件を見る | 見積もりに含まれない作業を比較する |
| 長期運用を重視 | 保守体制、改善提案、担当継続性を高める | 導入時だけでなく運用後の関わり方を見る |
配点は担当者だけで決めず、決裁者や利用部門と合意しておくことが大切です。後から「やはり価格が最優先だった」となると、評価表の意味が薄れてしまいます。
4段階評価で判断のぶれを減らす
点数をつけるときは、評価段階も先に決めます。5段階評価は使いやすい一方で、迷ったときに中間の3点へ集まりやすい傾向があります。評価の差を出したい場合は、4段階評価にして中間をなくすと判断しやすくなります。
| 評価 | 意味 | 記録する根拠 |
|---|---|---|
| 4 | 期待以上 | 要件を満たし、追加の提案や明確な実績がある |
| 3 | 期待通り | 要件を満たし、発注に必要な説明がある |
| 2 | 懸念あり | 要件の一部が曖昧、または追加確認が必要 |
| 1 | 不十分 | 要件を満たさない、根拠が弱い、リスクが大きい |
重要なのは、数字だけでなく理由を残すことです。同じ3点でも「十分に要件を満たしている3点」と「大きな問題はないが根拠が薄い3点」では意味が違います。比較表には、点数、判断理由、追加確認事項をセットで残しましょう。
RFPを出す前に評価基準を合意する
評価基準は、RFPを出す前に決めておくのが理想です。RFPの質問項目と評価表がつながっていれば、ベンダーからの回答をそのまま比較しやすくなります。RFP、RFQ、RFIの使い分けを整理したい場合は、RFI・RFQ・RFPの違いも参考になります。
たとえば、運用保守を評価するなら、RFPに「障害時の初動時間」「保守対応の範囲」「改善提案の頻度」「担当者変更時の引き継ぎ方法」を聞く必要があります。評価表にだけ運用保守の項目があっても、RFPで質問していなければ比較材料が足りません。
評価基準を先に合意すると、ベンダー選定の会議も進めやすくなります。候補先の印象ではなく、決めた評価基準に照らして何が強く、何が弱いのかを議論できるからです。
失格条件と追加確認条件を分ける
評価基準を作るときは、点数で比較する項目とは別に、失格条件と追加確認条件も決めておきます。たとえば、必須要件を満たさない、セキュリティ要件に対応できない、契約上受け入れられない前提がある場合は、総合点が高くても選定対象から外すべきです。
一方で、説明が不足しているだけなら、すぐに不採用にせず追加質問に回します。見積もりの前提、保守範囲、担当者の経験、納期の根拠などは、RFP回答だけでは判断しきれないことがあります。失格条件と追加確認条件を分けておくと、評価会議で「不安だから落とす」と「確認すれば判断できる」を混同しにくくなります。
評価者ごとの見方をそろえる
ベンダー評価は、情シス担当、利用部門、決裁者、経理、セキュリティ担当など、複数の関係者で見ることがあります。それぞれ重視する観点が違うため、同じ提案書を見ても点数が割れることは珍しくありません。
そのため、評価前に「誰がどの項目を見るのか」を決めておきます。技術や運用保守は情シス、業務適合性は利用部門、費用や契約条件は決裁者や管理部門のように役割を分けると、評価の根拠が整理されます。最終点だけを平均するのではなく、点数が大きく割れた項目を会議で確認することも大切です。
ベンダー選定の評価基準を比較表と理由に残す
比較表に残す項目をそろえる
比較表は、候補ベンダーごとに同じ項目で比較できるように作ります。項目がそろっていないと、ある会社は機能で評価し、別の会社は費用で評価するような状態になり、選定理由が説明しにくくなります。
| 比較表の項目 | 残す内容 | 目的 |
|---|---|---|
| 評価項目 | 要件理解、費用、体制、実績など | 同じ基準で比較する |
| 点数 | 評価段階と配点を反映した点数 | 総合評価を見える化する |
| 判断理由 | 点数をつけた根拠 | 後から理由を説明できるようにする |
| 懸念点 | 不明点、追加確認、リスク | 発注前に潰す論点を明確にする |
| 確認済み事項 | RFP回答、面談、見積もりで確認した内容 | 判断の証跡を残す |
| 総評 | 採用候補、不採用、保留の理由 | 社内稟議や結果連絡に使う |
比較表は見た目をきれいにすることより、判断に必要な情報が抜けないことが大切です。Excelやスプレッドシートで作る場合も、点数欄だけでなくコメント欄を必ず用意しましょう。
点数とコメントをセットで記録する
ベンダー評価表でよくある失敗は、点数だけが残り、なぜその点数になったのか分からなくなることです。これでは、決裁者から質問されたときや、落選したベンダーへ結果を伝えるときに説明が弱くなります。
コメントは長文である必要はありません。「見積もりの前提が明確」「類似案件の実績がある」「運用保守の範囲が曖昧」「追加費用条件の説明が不足」など、判断に効いた事実を短く残します。主観的な印象ではなく、提案書、見積書、面談、RFP回答で確認した内容に基づいて書くことが重要です。
評価コメントの書き方
- 良い点だけでなく懸念点も同じ粒度で残す
- 「安心感がある」ではなく「担当PMの類似案件経験がある」と書く
- 「高い」ではなく「保守費用に障害対応範囲が含まれない」と書く
- 判断できない項目は、未確認として追加質問に回す
評価コメントが具体的だと、次の確認事項も明確になります。比較表は選定会議のためだけでなく、ベンダーへの追加質問や発注後の管理にも使えます。
同点時の優先順位を先に決める
評価表を作っても、最終的に点数が近くなることはあります。その場合に備えて、同点時の優先順位を先に決めておくと判断しやすくなります。
たとえば、同点なら「要件理解の点数が高い方を優先する」「運用保守の懸念が少ない方を優先する」「初期費用ではなく3年間の総コストで見る」など、プロジェクトの成功条件に合わせてルールを置きます。決めていない場合は、最後に価格や印象へ寄りやすくなります。
見積もりの比較では、含まれる作業範囲の違いも確認が必要です。費用の妥当性を詳しく見たい場合は、システム開発の見積もり根拠も参考になります。
不採用理由も説明できる範囲で残す
ベンダー選定では、採用理由だけでなく不採用理由も残しておきます。社外へ詳細な点数や内部評価をすべて共有する必要はありませんが、少なくとも社内では「なぜ選ばなかったのか」を説明できる状態が必要です。
不採用理由は、相手を否定する言葉ではなく、今回のプロジェクト条件に合わなかった点として整理します。「今回重視した運用保守の体制が不足していた」「スケジュール前提が合わなかった」「追加費用の条件が不明確だった」のように、評価基準に沿って書くと納得感が出ます。
不採用理由を残しておくと、次回のベンダー選定にも活用できます。過去に何を懸念して選ばなかったのか、どの条件なら再検討できるのかが分かるため、候補先の棚卸しもしやすくなります。
発注後の管理項目へつなげる
比較表は、選定が終わったら捨てる資料ではありません。採用したベンダーの強み、懸念点、追加確認した内容は、発注後の進捗管理や品質管理にもつながります。たとえば、提案段階で「要件理解は高いが保守体制に確認が必要」と評価したなら、契約前に保守範囲を明文化し、運用開始後の確認項目にも入れておくべきです。
選定理由に残した内容は、発注後の期待値にもなります。「なぜこのベンダーに任せたのか」が分かっていれば、プロジェクト中に判断がぶれたときも、当初重視した評価基準へ戻れます。ベンダー選定の評価表を、選ぶための資料だけでなく、選んだ後に管理するための資料として使うと、発注後の認識ズレも減らしやすくなります。
