--- title: "ベンダー選定とは？システム開発の発注先を決める流れと評価表の配点設計" url: "https://www.issoh.co.jp/column/details/18684/" published: 2026-10-21 updated: 2026-10-21 categories: ["Webシステム"] publisher: "株式会社一創" --- # ベンダー選定とは？システム開発の発注先を決める流れと評価表の配点設計 ベンダー選定とは、システムの開発や構築、運用を依頼する会社を、複数の候補から比較して1社に決める工程です。候補探しから契約締結まで、中規模の業務システムなら3〜4か月かかるのが普通で、この間の判断がそのまま開発の成否を左右します。この記事では、RFIとロングリストづくりから、RFP配布、提案評価、ショートリストへの絞り込み、契約までの流れを順に整理しました。そのうえで、必須要件の足切りと配点を組み合わせた評価表の作り方、価格偏重や体制のすり替えといった失敗、選定支援を外部へ頼むべき条件まで、発注者の立場で判断を言い切ります。 ## まとめ｜ベンダー選定は評価基準を先に決めてから候補を絞る発注の工程 ベンダー選定で結果を分けるのは、候補の数でも提案書の見栄えでもありません。評価基準を提案の受領前に決めておけるかどうかです。必須要件で足切りし、残った候補を配点付きの評価表で採点する。この順序を守れば、声の大きい評価者や最安値の提示額に判断が引きずられにくくなります。 流れはRFIで10社前後に広げ、RFPを3〜5社に配り、提案とプレゼンで2〜3社に絞って1社と契約する形が標準です。社内に選定経験者がいて対象が単一部門で閉じる案件なら自社で回せます。複数部門にまたがる刷新や、初期費用が数千万円を超える案件では、評価表の設計と進行だけを外部の選定支援に任せ、最終決定は自社で持つ分担が現実的です。 ## ベンダー選定とは何か｜システム開発で発注先を決める工程の範囲と位置づけ ベンダーは製品やサービスを提供する事業者を指し、システム開発ではSIerや受託開発会社、パッケージ製品の提供元がこれにあたります。選定という言葉が示す範囲を先に揃えておきます。 ### ベンダー選定の意味と、見積比較や外注先探しとの違いが出る範囲の線引き ベンダー選定は、候補を集める段階から契約を結ぶ段階までを1つの工程として扱う考え方です。見積比較は、その途中にある価格評価の一部に過ぎません。金額だけを並べて決めると、提案範囲の違いや体制の差が比べられないまま発注することになります。外注先探しとの違いもあります。外注先探しは、SIer・受託開発会社・フリーランスといった依頼先の種類から当たりを付ける作業で、選定はその後に来る比較と決定の手続きです。依頼先の種類ごとの向き不向きは[業務システム開発の外注先の選び方と依頼手順の解説](https://www.issoh.co.jp/column/details/15781/)で整理しているので、本記事では候補が見えた後の比べ方と決め方に絞ります。 ### 要件定義・RFP・契約とベンダー選定がつながる順序と工程表での位置 工程表で見ると、ベンダー選定は企画と要件定義の間、または要件定義と設計の間に入ります。前者は課題と範囲だけを固めた段階で提案を募る形で、要件定義そのものを選んだベンダーと一緒に行います。後者は自社または別の支援会社が要件定義を終えてから、設計以降の開発会社を選ぶ形です。どちらを取るかで、RFPに書ける情報量と評価できる項目が変わります。要件定義前の選定では実現方法の提案力と要件定義の進め方を評価し、要件定義後の選定では見積もりの精度と開発体制を重く見る。この違いを決めずに評価表を作ると、配点の根拠が説明できなくなります。 ## ベンダー選定の流れ｜RFIからロングリスト・ショートリスト・契約までの段階 選定は「広げる」「絞る」「決める」の順に進みます。段階ごとに候補の数の目安を持っておくと、評価にかける工数を見積もりやすくなります。 ### RFIとロングリスト作成で候補を10社前後まで広げる段階の進め方と期間 最初に作るのがロングリストです。業界の導入事例、展示会、既存取引先からの紹介、マッチングサービスなどから、対応できそうな会社を10社前後挙げます。この段階では評価せず、漏れなく拾うことを優先します。 1. 対象業務・想定規模・希望時期を1枚にまとめ、候補探しの条件を社内で合意する 2. 候補10社前後にRFI（情報提供依頼書）を送り、実績・体制・対応領域を書面で回答してもらう 3. 回答期限は2週間程度とし、未回答や対象外の回答だった会社をここで外す 4. RFIの回答をもとに、RFPを配布する3〜5社を選ぶ RFIは提案を求める文書ではありません。実績と体制を聞く情報収集であり、ここで見積もりまで求めると回答率が下がります。RFIとRFP、RFQの役割の違いは[RFI・RFP・RFQの違いと発行の流れの解説](https://www.issoh.co.jp/column/details/2459/)で比較しています。 ### RFP配布から提案評価とプレゼンでショートリストへ絞る段階の手順 RFPを配布する社数は3〜5社が目安です。2社では比較が成り立たず、6社を超えると提案書の読み込みと採点に評価者の工数が取られ、1社あたりの確認が浅くなります。RFPには評価基準と配点、スケジュールを日付付きで書き、質問は締切を設けてまとめて受け付け、回答は全社へ同じ内容で返す運用です。記載項目と章立ては[RFPの書き方と章立てサンプルの解説](https://www.issoh.co.jp/column/details/16290/)にまとめています。提案書を受け取ったら書面で一次評価を行い、上位2〜3社をショートリストに残してプレゼンテーションと質疑に進む段取りです。プレゼンでは、提案書の説明を聞くより、想定外の事態への対応を質問するほうが差が出ます。「要件が2割増えたらどう進めるか」「主要メンバーが離脱したらどう補うか」。答え方に、その会社の現場の実力が表れるからです。 ### 内定から契約締結までに詰める条件と契約書のひな型・取適法の確認 1社に内定したら、提案書とRFPの内容を契約条件へ落とし込みます。確認するのは、契約形態（請負か準委任か）、検収の基準、契約不適合責任の期間、成果物の権利帰属、再委託の可否、追加費用が発生する条件です。条項の叩き台には、IPAが公開している[情報システム・モデル取引・契約書（第二版）](https://www.ipa.go.jp/digital/model/model20201222.html)が使えます。公開日は2020年12月22日で、受託開発・保守運用向けの版の更新日は2025年4月8日です。第二版ではプロジェクトマネジメント義務と協力義務、システム開発における複数契約の関係などが見直されており、発注者側にも協力する義務がある点を契約前に読んでおくと、選定後の役割分担で揉めにくくなります。もう1点、2026年1月1日に下請法が改正され、[中小受託取引適正化法（取適法）](https://www.jftc.go.jp/toriteki/toritekigaiyo/gaiyo.html)として施行されました。資本金に加えて従業員数の基準が加わり、協議を適切に行わない一方的な代金決定や、手形による代金の支払いが禁止されています。選んだベンダーが中小企業にあたる場合は、発注書面と支払条件をこの基準で見直してから契約に進みます。 ## ベンダー選定の評価基準と評価表｜足切りと配点で採点のぶれを抑える方法 評価表は、提案を受け取る前に作り、RFPで候補へ開示します。受領後に作ると、気に入った提案に合わせて基準を動かす余地が生まれます。 ### 評価項目を必須要件と加点要件に分けて足切りする評価表の組み立て方 評価表は2段構えで作ります。1段目は必須要件で、満たさなければ総合点にかかわらず選外とする項目です。たとえば、希望時期までの稼働に同意できること、指定するセキュリティ基準や認証を満たすこと、保守を5年以上引き受けられること。この判定は「満たす／満たさない」の2択で行い、点数を付けません。2段目が加点要件で、提案内容や体制を配点付きで採点します。足切りを入れずに全項目を点数化すると、必須条件を1つ満たしていない会社が、他の項目の高得点で首位に立つことが起きます。総合点が高くても必須要件の不足は埋まらないため、点数で議論する前に候補から外すのが筋です。 ### 提案内容・体制・価格・保守の配点例と案件の性質で配分を変える基準 加点要件の配点は、案件の性質で変えます。次の表は100点満点での配分例です。 | 評価項目 | 新規開発 | 刷新・移行 | 小規模改修 | | ----------- | ---- | ----- | ----- | | 提案内容と課題の理解 | 40点 | 30点 | 25点 | | 体制・実績・要員の経験 | 25点 | 35点 | 20点 | | 価格と見積もりの根拠 | 25点 | 20点 | 40点 | | 保守運用と引き継ぎ | 10点 | 15点 | 15点 | 新規開発は課題の解き方そのものを比べたいので、提案内容に最も厚く配点します。刷新や移行では現行調査と移行の経験が失敗を分けるため、比重を上げる対象は体制と実績です。刷新案件の配点の組み替え方は[システム刷新のRFPとベンダー選定基準の解説](https://www.issoh.co.jp/column/details/16400/)で詳しく扱っています。要件が固まった小規模改修では提案の差が出にくく、価格の比重を上げても判断を誤りにくい構成です。価格を評価するときは総額だけでなく、工程別の工数と単価の内訳を揃えて比べます。見積書の読み方と相見積もりの比べ方は[システム開発の見積もりと相見積もりの比較の解説](https://www.issoh.co.jp/column/details/13443/)を参照してください。 ### 評価者を複数置くときの採点基準の書き方と点数が割れたときの扱い 評価者は業務部門、情報システム部門、決裁者側から2〜4名を出すのが一般的です。人数を増やすほど公平になるわけではなく、採点基準の書き方で精度が決まります。各項目に「5点＝具体的な数値と手順まで提案がある」「3点＝方針はあるが手順がない」「1点＝RFPの記載を言い換えただけ」のような水準の定義を付け、評価者が同じ物差しで採点できるようにする方式です。採点後に同じ項目で2点以上割れたら、平均で均さずに理由を突き合わせます。業務部門だけが低く付けた項目は、現場の運用に合わない箇所を見つけている場合が多く、平均すると見落としがそのまま埋もれるおそれがあるためです。突き合わせた結果は議事録に残し、不採用の会社に理由を伝えるときの根拠にします。 ## ベンダー選定でよく起きる失敗と、契約後の手戻りにつながる見落とし 選定の失敗は、契約直後ではなく開発の中盤に表面化します。原因の多くは、評価表の段階で防げたものです。 ### 価格の配点が高すぎて最安値の提案が選ばれ追加費用で逆転する失敗 最も多いのが、価格に40点以上を配点した結果、提案範囲の狭い最安値の会社が選ばれる失敗です。安い見積もりは、対象外の作業を前提から外していることが少なくありません。データ移行、外部システムとの接続試験、操作研修、本番切り替え時の立ち会い。これらが「別途見積もり」になっていると、開発中に追加費用として出てきて、2番手の提案額を上回ることもあります。防ぐ方法は、RFPで作業範囲の一覧を示し、各社に「含む／含まない／別途」を明記させることです。そのうえで、含まない作業を自社の想定額で足し戻してから価格を比べます。 ### 提案書の体制図と実際の参画メンバーが入れ替わる失敗と契約前の確認 提案時に紹介された経験豊富なプロジェクトマネージャーが、契約後には別の案件に回っている。提案書の体制図に役割名しか書かれていない場合に起きやすい失敗です。プレゼンには実際に参画するプロジェクトマネージャーとリーダーの出席を求め、本人に質疑へ答えてもらいます。契約書や発注書には主要メンバーの氏名と、交代する場合の事前協議の手続きを入れておきます。体制の評価点は、この確認ができた後に確定させるのが安全です。 ### 現行ベンダーを候補に含めたときの情報格差で比較が崩れる失敗の防ぎ方 既存システムを保守している現行ベンダーは、業務と構成を知っている分、見積もりの精度で有利に立ちます。他社は不明点を安全側に見積もるため、金額が膨らみ、価格評価で現行ベンダーが勝ち続ける構図になりがちです。防ぐには、現行の構成図、データ量、連携先の一覧をRFPの添付資料として全社に同じ粒度で開示し、質疑の回答も全社に共有します。それでも情報格差が埋まらない規模なら、現状調査を別に発注してから選定に入る順序を検討します。 ## ベンダー選定を自社で進めるか、選定支援（PMO）を外部へ頼むかの判断条件 選定支援は、評価表の設計、RFPの作成、提案評価の進行を外部の専門家が手伝う形のサービスです。全案件に必要なものではないため、条件で線を引きます。 ### 自社だけでベンダー選定を進めてよい案件の条件と社内体制の目安 次の条件がそろうなら、自社だけで進めて構いません。過去3年以内にシステム開発の発注と選定を経験した担当者がいる。対象業務が単一部門で閉じ、関係者が5名程度に収まる。初期費用が1,000万円未満で、候補が既存取引先を含む3社程度に絞れている。この規模で外部支援を入れると、支援費用が選定で避けられる損失を上回りやすく、やり取りの相手が増える分だけ進行も遅れます。評価表と比較の段取りは、本記事の流れに沿って社内で作れば足ります。 ### 選定支援を外部に頼むべき案件と、支援会社に任せてはいけない判断 外部の選定支援を入れるべきなのは、複数部門の要求を取りまとめる必要がある案件、基幹系の刷新や移行を含む案件、初期費用が数千万円を超える案件、社内に選定経験者がいない案件のいずれかに当てはまる場合です。こうした案件では、評価表の設計を誤ったときの損失が支援費用を大きく上回ります。ただし、支援会社に任せてはいけない判断は、次に挙げる2つです。1つは最終的な発注先の決定で、評価結果の説明責任は発注者に残ります。もう1つは配点の承認で、何を重く見るかは自社の事業判断そのものです。支援会社自身が開発の候補に入る場合は、利益相反を避けるため選定支援と開発の受注を分ける運用にします。RFP作成から提案評価の進行までを相談したい段階であれば、[要件定義・RFP作成・PMO支援のサービス](https://www.issoh.co.jp/service/system/pmo/)で支援範囲を確認できます。 ## よくある質問 ベンダー選定について、発注担当者から多く挙がる質問を5つ取り上げます。 ### ベンダー選定にはどのくらいの期間がかかりますか？ 中規模の業務システム開発で複数社を比べる場合、RFIの送付から契約締結まで3〜4か月が目安です。内訳は、RFIとロングリスト作成に3〜4週間、RFP作成に3〜6週間、提案書の作成期間として3〜4週間、提案評価とプレゼンに2〜3週間、社内決裁と契約交渉に2〜4週間です。提案期間を2週間に詰めると、各社が既存の提案書を流用しやすくなり、比較に使える情報が減ります。稼働希望日から逆算して着手時期を決めてください。 ### ベンダー選定の評価表はどのような項目で作ればよいですか？ まず満たさなければ選外とする必須要件を3〜5項目決め、そのうえで提案内容、体制と実績、価格、保守運用の4項目に配点を付ける形が基本です。必須要件は点数化せず、満たすか満たさないかで判定します。各項目には5点・3点・1点がどの水準かを文章で定義しておくと、評価者による採点のぶれが小さくなります。評価表は提案を受け取る前に完成させ、RFPで候補へ開示してください。 ### ベンダー選定では何社に声をかけるのが適切ですか？ 情報収集のRFIは10社前後、提案を依頼するRFPは3〜5社、プレゼンに進むショートリストは2〜3社が目安です。RFPを2社にしか配らないと価格や提案の妥当性を比べる基準が持てず、6社を超えると評価者の読み込みが追いつかなくなります。小規模改修で候補が限られる場合でも、相見積もりは2社以上から取り、作業範囲を揃えて比べてください。 ### ベンダー選定で不採用にした会社には理由を伝えるべきですか？ 伝えるべきです。提案書の作成には各社が数十時間単位の工数をかけており、理由のない不採用通知が続くと、次回のRFPで辞退や流用提案が増えます。伝える内容は詳細でなくてよく、評価表のどの項目で差がついたかを1〜2文で示せば十分です。採点の突き合わせを議事録に残しておけば、通知文はそこから作れます。他社の提案内容や金額を漏らさないよう注意してください。 ### ベンダー選定の支援を頼むと費用はどのくらいかかりますか？ 支援の範囲と期間で大きく変わり、一律の相場はありません。費用は、評価表とRFPの作成だけを頼むのか、RFIから契約交渉までの進行を任せるのかで決まり、多くは準委任契約で月単位の工数として見積もられます。判断の目安は、選定を誤った場合の損失と比べることです。初期費用が数千万円規模の開発なら、選定の誤りによる手戻りの損失が支援費用を上回る場面が多くなります。 ## 関連記事 - [RFPとは？提案依頼書の意味・目的・記載項目と目次テンプレートを解説](https://www.issoh.co.jp/column/details/15344/)：選定の中心になる提案依頼書の定義と目的を確認できます。 - [準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説](https://www.issoh.co.jp/column/details/13187/)：選定後に決める契約形態の違いを整理しています。 - [AWS構築代行の依頼範囲と費用｜内製との比較とベンダー選定の判断軸](https://www.issoh.co.jp/column/details/16406/)：クラウド構築に領域を絞った場合の選定の判断軸です。 - [システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】](https://www.issoh.co.jp/column/details/15670/)：選定後に発注側が担う管理の役割を扱っています。 - [業務システム開発の外注先はどう選ぶ？依頼手順と発注前準備・失敗回避を解説](https://www.issoh.co.jp/column/details/15781/)：外注先の種類ごとの向き不向きと発注前の準備をまとめています。 --- 出典: [ベンダー選定とは？システム開発の発注先を決める流れと評価表の配点設計]()（株式会社一創）