ベンダ選定で結果の7割が決まる？RFP作成から始まるベンダ選定の流れや選定基準のポイントを解説

2025/07/05

先日とある企業を訪ねたときの話しです。
先方が開口一番「今のシステム開発ベンダーにはほとほと困っているんですよ」と開発プロジェクトの心労を吐露されました。
話しの内容はこうでした。

新サービスの企画開発にあたって、システム開発ベンダを募集し、予定価格内で対応できる企業を発注先に決め、昨年末に開発体制をスタートしたそうです。営業やエンジニアの印象はなかなか良かった、集めた3社のうち提案内容も一番良かった、とここまでは良かった。
しかしこの時すでに誤算が生じていました。

ボタンの掛け違いが早々に露呈したのです。
開発仕様を決めてくれないと作業できないというシステム開発ベンダの主張によりプロジェクトがフリーズしました。
そもそも外部に発注したのは自社のリソース不足が理由であり、実業務と兼任のため開発仕様の作成まで手が回らないからでした。

役割分担の調整についてシステム開発ベンダから提案が無いまま進捗が遅れていきます。
背に腹替えられぬと実業務の手を止めて、開発仕様を作らざるを得ないことになりました。
想定外の負担を抱えているのに予定期日が来てもシステムは半分くらいしか出来ていません。
この先どうなるかと思うと溜息しかでないとのこと。
一体どこで判断を間違ってしまったのでしょうか？

実は一見当然のようなベンダ選定のプロセスに問題があるのです。

ベンダ選定で結果の7割が決まってしまう

ちなみに先の例のようにベンダ選定で躓いてしまうと後から挽回するのは難しくなります。
社内体制であれば内部調整で済むことも、外部に発注している場合は「契約」が絡むからです。

ベンダの仕事の仕方が下手でも簡単に切ることはできません。一度ベンダを決めて契約してしまったら、よほどのことが無い限り、最後まで走り抜くことになります。その「よほどのこと」が相当深刻ではあれば、損切りしたほうがダメージが少ないかも知れませんが、それでも相当に余分なエネルギーを使い、相応のダメージを受けます。

つまりシステム開発は、ベンダ選定という入り口のところで成否が7割決まってしまうのです。しかも自社にとって相性が良く無いベンダと出会う確率は、良いベンダと出会う確率よりも高い。それだけでなく技術スキルや仕事スキルが低いベンダと出会う確率だってかなり高いのです。

発注側に知識や工夫が無いとトンデモなことに巡り合ってしまう、と考えても大袈裟ではないでしょう。

システム外注で失敗したくない方はこちらもチェック
システム開発を外注先に丸投げすると生じるトラブルとは？失敗しないポイントや外注先選びのポイントを解説

ベンダ選定基準を設定する理由

システム開発プロジェクトを成功させるためには、明確なベンダ選定基準の設定が不可欠です。多くの企業が「なんとなく良さそう」という感覚的な判断や営業担当者の印象だけでベンダを選んでしまい、後になって予算オーバーや納期遅延などの大きな問題を抱えることがあります。

事前に選定基準を設定することで、プレゼンテーションの質や営業担当者の人柄に左右されることなく、ベンダの技術力や実績、プロジェクト管理能力といった本当の実力を客観的に見極めることができます。

また、複数の候補者を同じ基準で公平に評価できるため、「なぜこのベンダを選んだのか」という選定理由を社内外に明確に説明することが可能になります。さらに、プロジェクトに必要な技術要件や体制要件を事前に整理することで、契約後のトラブルや認識の相違を未然に防ぐことができるのです。

ベンダ選定基準の設定は単なる事務的な手続きではなく、プロジェクト成功のための重要な戦略的取り組みとして位置づけることが大切です。

「RFPが鍵！！ベンダ選定でプロジェクトの成否は8割決まる」を見る

ベンダ選定は候補社集めからすでに始まっている

上の図はシステム開発ベンダー選定のおおまかな流れです。
それでは順を追って見ていきます。

STEP1　候補の洗い出し～絞り込み

1．母集団形成

まず候補ベンダの母集団をつくります。
Webサイトをリサーチして少なくとも10社以上、できれば30社ほどをリストアップします。
数を集める意味は、母集団の中に本命候補となる企業が含まれる確率を高めるためです。そんな沢山の数を揃えても、この後の選定作業が大変ではないかと思われるかもしれませんが、母集団が大きければ大きいほうが自社にとっての「本命」と出会える確率が高まります。
ここは割り切って大きな母集団づくりを目指します。

母集団から絞り込んだ中に原石が残るわけですが、そもそも母集団に原石が混ざっていないことには話しになりません。だから広げる作業が大事なのです。母集団から最後の1社に決めるまでは「じょうろ」のように広い入り口から徐々に狭くなっていくイメージとなります。

2．有力候補の絞り込み

リストアップは広げる作業ですが、ここから先は絞り込みの作業となります。目安としては4～7社くらいでしょうか。自社が抱える案件の重要度やリソースによります。ただ途中でベンダから辞退されることもありますので無理に絞り込まずプラスαの候補数を残すことです。

絞り込みの方法として各社に情報提供を依頼します。
「情報提供依頼」というのはコーポレートサイトや会社案内に公開されていない情報を求めることを指します。例えば、自社が属する分野での事例の有無や内容。あるいは自社のテーマを伝えたうえで、そのベンダが提供しているサービスで対応可能かどうかと、どんなアプローチで可能なのかについての情報を個々に求めます。
このとき「提案して欲しい」と言うのではなく「情報提供をお願いしたい」という伝え方で、ベンダの担当者には意図が伝わるはずです。

なお母集団が大きいと1社1社お会いするのは大変なのでメールでのやり取りにとどめたいところです。先方から面会を求められても「今は広く情報収集している段階のため固まってからお願いしたい」と伝えます。
母集団を形成する1社1社全てにお会いするのは無理と割り切ったほうが良いでしょう。実際にお会いするのは絞り込んだ後で充分です。

STEP2　提案依頼（RFP：Request for Proposal）

1．提案依頼書作成

候補ベンダを絞り込んだら、いよいよこの中から本命を探っていくことになります。
その方法として提案依頼書（RFP：Request for Proposal）を元にコンペで選定します。

提案依頼書とは「このような内容で提案して欲しい」という内容を記載したドキュメントのことで、具体的にはシステム化したい機能や要件、解決したい課題など織り込みます（本ドキュメントの作り方については別の機会に触れます）。

2．ベンダとの面会

情報提供依頼のときは面会を省きましたが、この段階ではベンダと面会してノンバーバルな情報も掴んでおくことが望ましいでしょう。
ここで案件概要とコンペであることを伝え、段取りと各期日について説明し、参加意思を確認します。

3．機密保持契約の取り交わし

ベンダに提案依頼書を提示するにあたっては、そこに記載されている自社の機密情報についての守秘義務が必要です。
その一般的な方法として機密保持契約を結びます。

4．オリエンテーション

提案依頼書の説明を口頭で行って質疑応答する場を設けます。
1社づつ個別に行うのは開催側の負担が高いため、複数社を集めて説明会形式で行うのが良いでしょう。

5．ベンダからプレゼンテーションを受ける

各社からの提案内容についてのプレゼンテーションを受けます。
その際にはプロジェクトリーダーとその補佐役の方をプレゼンメンバーとして参加を要請しておき、人物象についてもしっかり観察します。
この時しっかり、じっくりと質問することで、実際にプロジェクトが動いているときの様子を想像していきます。
回答姿勢、背景となる経験や知識、お互いの噛み合いの良さを質問を通じた相互のコミュニケーションから把握します。

STEP3　提案評価

評点表につけた点数を積み上げて評価します。
一般的には残った上位２〜３社あたりで最終判断することになります。優劣付けられずに迷うこともあるでしょう。迷うというのは点数を比べるだけで決められないということです（オートマティックに決められるほど評点表が完璧に設計されていれば話は別ですが）。

その場合の評価方法について述べていきます。
まず比較すべきはベンダそのものではありません。自分達とベンダとの関係が重要です。
ベンダ側のリーダーや技術担当者と話しているときの自分達がどうであったか、ここを評価します。

そもそもITというテーマで、クライアント企業とベンダが仕事する場合、クライアントが「こんなものを作って欲しい」とベンダに求めるような一方通行の発注行為では、うまく廻りません。双方向性が大事なのです。
クライアント企業は自分たちのビジネスについて誰よりも詳しい人、システムベンダはテクノロジーの活かし方の専門家、というお互いの役割分担がコラボしあうような関係です。

言い換えると両者が二人三脚でゴールに向かうようなものなので、大事なのは相手のスペックではありません。
自分と相手の呼吸が合うかどうかが大事なのです。選定の最終段階ではここを重点的に評価しないといけません。
そのためのコミュニケーションの時間を別途作るのも良いでしょう。

STEP4　契約

ベンダが決まったら、ベンダ選定の最終関門である「契約」を取り交わす工程に進みます。
契約は言い換えればトラブルの予行演習とも言えます。冒頭の例では業務範囲についての取り決めが曖昧だったため、ベンダによる「それは自分たちの役割ではない」という主張に対抗できませんでした。

契約に織り込む内容は、お互いの仕事の仕方を両者が膝を詰めて話し合った結果とも言えます。
お互いの責任範囲、納品物の定義、各工程の期日、権利関係など事前に話し合うことは沢山あるでしょう。

そして上記以外にも考えられる得るあらゆる「うまくいかない事態」を想定して条件に織り込みます。
その結果として相手方との交渉において呑める呑めないという話しが必ず出てくるでしょう。

この「うまくいかない事態」を回避するために、ベンダにとって厳しい条件を折り込まざるを得ないかも知れません。
それを呑んで貰えるかどうかは交渉次第ですが、見逃せないポイントは今までは話しが和やかに進んでいても契約でご破算となる可能性が残っているということです。
他社には落選を伝えてしまった後に、本命から辞退されてしまったら次の選択枝はもうありません。

ということから契約が完了するまでは、以下の2点をしっかり抑えます。
まず決定ベンダには内示を告げるに留め、契約の仮合意を以て、役員会で最終承認すると伝えます。交渉相手を100％安心させず少しでも発注側優位に進めるためです。
一方で2位以下のベンダにも同じように伝えて保持します。このように契約が完了するまでは決して気を緩めてはいけません。

ベンダ選定基準の8つのポイント

システム開発の成功可否は、最初のベンダ選定がプロジェクトの成否を大きく左右します。以下の八つの評価ポイントは、価格や営業トークに左右されず“技術力・実績・運用体制・相性”を多面的に見極めるチェックリストです。

自社の戦略や制約と照合し、最適なパートナー選びにご活用ください。

①企業としての事業継続性と安定性はあるか

システム開発は長期的なパートナーシップを前提とした関係です。開発完了後も保守・運用やシステム拡張などで継続的な関わりが必要になります。そのため、ベンダ企業の財務状況、経営基盤、事業継続性を慎重に評価する必要があります。

具体的には、決算書類の確認、従業員数の推移、主要取引先との関係性、業界での立ち位置などを総合的に判断します。特に中小規模のベンダの場合、経営者の年齢や後継者の有無、事業の多角化状況なども重要な評価要素となります。安定性に不安があるベンダを選んでしまうと、プロジェクト途中での撤退や、完了後のサポートが受けられないリスクがあります。

②過去の実績は豊富か

ベンダの技術力や実行力を測る最も確実な方法は、過去の実績を詳細に確認することです。単に「実績が多い」だけでなく、自社のプロジェクトと類似する規模や業種、技術要件での成功事例があるかが重要です。

実績評価では、プロジェクトの規模（予算・期間・人員）、技術的な難易度、顧客の満足度、納期遵守率などを具体的に確認します。可能であれば、実際にそのシステムを導入した企業からの推薦状や評価を取得することで、より客観的な判断材料を得ることができます。実績が不足しているベンダは、技術的な課題への対応力や予期しない問題への解決能力に不安が残ります。

③要件の網羅性は高いか

システム開発では、要件定義の段階でどれだけ詳細に検討できるかが成功の鍵を握ります。優秀なベンダは、発注者が明示していない潜在的な要件も含めて包括的に提案してくれます。

要件の網羅性を評価する際は、機能要件だけでなく、非機能要件（性能、セキュリティ、可用性、拡張性など）についても十分に検討されているかを確認します。また、将来的な業務拡張や法規制の変更に対する柔軟性、他システムとの連携可能性なども考慮されているかがポイントです。要件の理解が浅いベンダを選ぶと、開発途中での仕様変更や追加費用の発生につながりやすくなります。

④妥当な費用か

コストは重要な選定要素ですが、単純に安ければ良いというものではありません。提示された費用が妥当かどうかを、市場相場や他社見積もりと比較して判断する必要があります。

費用評価では、初期開発費だけでなく、保守・運用費、将来の機能拡張費用なども含めたトータルコストで考えることが重要です。異常に安い見積もりは、後から追加費用を請求される可能性や、品質に問題がある可能性があります。逆に高額すぎる場合は、不要な機能が含まれていたり、効率的な開発手法が採用されていない可能性があります。費用対効果を総合的に判断することが求められます。

⑤スケジュールと納期は妥当か

システム開発プロジェクトでは、納期の遵守が事業計画に直接影響します。提示されたスケジュールが現実的で実現可能かを慎重に評価する必要があります。

スケジュール評価では、各工程の期間設定、リソース配分、リスクバッファの確保状況などを確認します。楽観的すぎるスケジュールは後に大幅な遅延を招く可能性があり、一方で過度に余裕を持ったスケジュールは機会損失につながります。過去の類似プロジェクトでの実績と照らし合わせ、そのベンダのプロジェクト管理能力も含めて総合的に判断することが重要です。

⑥依頼したいシステムの分野が得意か

システム開発には様々な専門分野があり、ベンダによって得意不得意があります。自社が求めるシステムの分野でどの程度の専門性と経験を持っているかが重要な選定要素となります。

分野の専門性は、単に「できます」という回答だけでなく、具体的な技術者のスキルレベル、保有する技術認定、その分野での開発実績年数、最新技術への対応状況などで判断します。例えば、ECサイト開発、基幹システム刷新、AI・IoT導入など、それぞれに特化した知識とノウハウが必要です。

専門性の低いベンダを選ぶと、技術的な課題に直面した際の解決力不足や、業界特有の要件への理解不足が問題となる可能性があります。

⑦今回のプロジェクトの位置づけを正しく認識しているのか

ベンダが自社にとってのプロジェクトの重要性や位置づけを正しく理解しているかは、プロジェクトの成功に大きく影響します。単なる技術的な作業として捉えているのか、事業戦略の一環として理解しているのかで、提案内容やアプローチが大きく変わります。

プロジェクトの位置づけ理解度は、提案書の内容や質疑応答での回答から判断できます。自社の事業目標や課題を深く理解し、システム導入がもたらすビジネス価値を具体的に提示できるベンダは、単なる開発業者ではなく真のパートナーとして機能します。逆に、技術的な実装にのみ焦点を当てたベンダでは、真の課題解決に至らない可能性があります。

⑧委任契約なのか請負契約なのか

契約形態の理解は、プロジェクトの責任範囲や成果物の品質保証に直結する重要な要素です。委任契約と請負契約では、ベンダの責任範囲、成果物に対する保証、費用の支払い方法などが大きく異なります。

委任契約では、ベンダは一定の作業を行う義務を負いますが、必ずしも特定の成果物の完成を保証するものではありません。一方、請負契約では、約束された成果物の完成と引き渡しまでがベンダの責任となります。契約形態を正しく理解していないベンダは、責任範囲について後にトラブルの原因となる可能性があります。

提案段階で契約形態について明確に議論し、お互いの認識を合わせておくことが重要です。

分かっていても「プレゼンが上手いベンダ」に心が傾くのは何故か？

一般にコンペというと提案内容やベンダの企業規模、安定性、将来性などスペック情報を見比べることが多いですが、スペックを見ても判断を迷うだけというケースは多いです。

また傾向としてプレゼンが旨いベンダに評点が集まります。なぜなら感情が揺り動かされるからです。

ベンダ選定というロジカルな場面で、感情で意思決定されることがあるのでしょうか。筆者の経験では企業の意思決定において感情要素が多分に影響することは少なくありません。感情が揺り動かされると、ロジック側の脳の働きよりも感情優位になるからです。当事者としては合理的に判断しているつもりでも第三者が客観的に見れば必ずしもそうではありません。

特に大きな予算が動く案件でプレゼンでは、意思決定権者から担当者までが同じ場に集まりますから、素晴らしいプレゼンを皆が聞いて、皆が感銘してしまったら反対する人は居なくなるわけです。このとき集団として誤った判断に突っ走りやすいのです。プレゼンが上手い＝自社にベスト、であれば良いのですが、両者は必ずしもイコールではありません。

前述のとおり相手との息が合いそうかどうか、この点をしっかり見定めてください。

ベンダ選定ならオーシャン・アンド・パートナーズ株式会社へ

システム開発プロジェクトの成否は、初期のベンダ選定が大きく左右するといわれます。いったん契約を結ぶと人員の再手配や違約交渉の負担が重く、途中でパートナーを替えるのは現実的ではありません。

そのため企業の財務安定性や類似実績、要件網羅度、費用とスケジュールの妥当性、分野特化の技術力、プロジェクト目的の理解度、さらに委任か請負かといった契約形態まで、八項目を総合的に点検する姿勢が欠かせます。

こうした評価とRFP作成を自社だけで担う余裕がない場合は、製造・流通・医療・金融などで豊富な支援実績を持つオーシャン・アンド・パートナーズ株式会社が、戦略的なRFP策定から候補比較や最終交渉まで一貫して伴走し、最適なベンダ選定を支援します。

詳しくは、オーシャン・アンド・パートナーズの公式HPをご覧ください。

▼オンライン相談会も実施中！詳しくは下記からお問い合わせください▼

オーシャン・アンド・パートナーズにお問い合わせする

この記事を書いた人について

谷尾 薫
谷尾 薫
オーシャン・アンド・パートナーズ株式会社　代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事

富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。

関連記事