ベンダー評価方法4ステップ｜提案書比較・デモ・ヒアリングの進め方

RFP（提案依頼書）を送って複数の開発会社から提案書が届いた瞬間、多くの担当者が同じ壁にぶつかります。提案書はどれも丁寧に作り込まれていて、価格は数百万円〜千万円単位で開いている。社内の関係者からは「こっちの方が見栄えが良い」「いや、安い方で十分だ」と意見が分かれ、議論はなかなかまとまりません。

しかも、ベンダー選定の責任は最終的に発注担当者であるあなたに集まります。プロジェクトが失敗した場合、「なぜその会社にしたのか」を経営層に説明できなければなりません。だからこそ「何を基準に比較すれば、後から責任を問われない選び方になるのか」が見えないまま、提案書を眺めて時間だけが過ぎていく状況になりがちです。

この不安を解消する唯一の方法は、属人的な印象や価格だけで判断するのではなく、評価プロセスを定型化することです。誰が見ても再現できる手続きで選んでいれば、結果が良くも悪くも「妥当なプロセスで選んだ」と説明できます。日本情報システム・ユーザー協会（JUAS）の企業 IT 動向調査 2024でも、システム開発の QCD（品質・コスト・納期）の遵守状況はここ 10 年で 10 ポイント以上悪化していると報告されており、ベンダー選定段階での評価設計の重要性は年々高まっています。

本記事では、RFP 送付後のベンダー評価方法を「提案書評価 → デモ → ヒアリング → 最終選定」の 4 ステップに分解し、それぞれの段階で何を、誰が、どう判断すべきかを実践的に解説します。評価シートの作り方、AI 開発会社向けの追加質問例、最安値選択や大手信仰などの意思決定の落とし穴まで網羅し、選定責任を担保できる手順をまとめました。

なお、RFP の作成段階に課題がある方はシステム開発 RFP の書き方もあわせてご確認ください。RFP の品質が低いと、提案書の比較もうまくいかなくなるため、前段の整備も同じくらい重要です。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

RFP 後のベンダー評価とは？評価プロセスの全体像

RFP 後のベンダー評価とは、複数社から届いた提案書を比較・採点し、デモやヒアリングを経て最終的に発注先を 1 社に絞り込む一連のプロセスを指します。提案書を読み比べて「なんとなく良さそう」で決めるのではなく、評価視点をあらかじめ設計しておき、誰が見ても同じ結論に至る手続きとして実施することが基本です。

ベンダー評価の 4 ステップ（提案書 → デモ → ヒアリング → 最終選定）

ベンダー評価は次の 4 ステップで進めます。

提案書受領からおよそ 4〜6 週間で 1 社に絞り込むのが標準的なペースです。期間が短すぎるとデモやヒアリングが形骸化し、長すぎるとベンダー側のリソース確保に影響します。RFP 送付の段階で「●月●日までに最終選定」とスケジュールを共有しておくと、ベンダーも評価期間中の体制を組みやすくなります。

評価プロセスを設計しないとどうなるか

評価プロセスを設計せずに進めると、次のような問題が連鎖的に発生します。

• 最安値選択: 比較軸がないため、最も分かりやすい「価格」だけで判断してしまう。結果として品質・体制が伴わず、追加費用や納期遅延で結局高くつく
• 社内対立の長期化: 経営層は「コスト重視」、利用部門は「使いやすさ重視」、情シスは「技術力重視」と評価軸がバラバラになり、合意形成に何週間もかかる
• 選定責任の所在が不明確: 「みんなで決めた」になり、プロジェクトがうまくいかなかったときに発注担当者が個人的な責任を問われる

特に最後の点は、発注担当者にとって最大のリスクです。プロセスを文書化しておけば「評価シートで点数化した結果、最も総合点の高い A 社を選定した」と社内に説明でき、結果が振るわなくても選定プロセスの妥当性を根拠に説明責任を果たせます。

ステップ 1：提案書の評価方法と評価シートの作り方

提案書を受け取ったら、まずは評価シートで点数化します。ここでの最大のポイントは、提案書を受領する前に評価シートを完成させておくことです。提案書を読んでから評価項目を決めると、無意識に「目に入った内容」を評価項目化してしまい、特定のベンダーに有利・不利な設計になりがちです。

評価視点の 4 カテゴリ（信頼性・提案妥当性・機能網羅性・コスト）

評価項目は次の 4 カテゴリで整理すると過不足なくまとまります。

「セキュリティ」を独立カテゴリにする企業もあります。個人情報や決済情報を扱うシステムの場合は、IPA の重要情報を扱うシステムの要求策定ガイドを参考に、セキュリティ要件を独立した評価カテゴリとして切り出すのが安全です。

評価項目の細分化と配点の考え方

各カテゴリの配下に、5〜10 個の評価項目を細分化します。例えば「ベンダー信頼性」配下なら「自社業界での開発実績件数」「直近 3 年の継続契約率」「主要メンバーの経験年数」などです。

配点は 自社の優先度 を反映させます。判断基準は次のとおりです。

• 価格よりも納期を優先したい場合 → 「スケジュール妥当性」の配点を厚くする（例: 30 点）
• 内製化を将来見据えている場合 → 「ドキュメント整備・技術移管の具体性」を配点に追加する
• セキュリティ・コンプライアンスが重い業界（金融・医療）→ 「セキュリティ対応・第三者認証取得の有無」を配点全体の 25〜30% に設定する

配点設計でよくある失敗は、各項目の配点を均等にしてしまうことです。均等配点にすると「強みが分散しているベンダー」が有利になり、自社の課題に対する適合度が見えにくくなります。配点に強弱をつけることで、自社の優先順位がそのまま評価軸になる点を押さえてください。

点数化のルール（3 段階 vs 5 段階・点数算出式）

各項目の評価点は 3 段階または 5 段階で付けます。

• 3 段階（◎ / ○ / ×）: シンプルで意見が割れにくい。評価項目数が多い場合に向く
• 5 段階（5 / 4 / 3 / 2 / 1）: 微妙な差を表現できる。評価項目数が 20 個以下の場合に向く

点数算出式は次の通りです。

項目スコア = 配点 × 評価点 ÷ 段階数の最大値

例えば配点 20 点・5 段階評価で「4」を付けた場合、項目スコア = 20 × 4 ÷ 5 = 16 点 となります。各カテゴリの項目スコアを合計して、総合点を比較します。

評価シートのサンプル項目

実際の評価シートは次のような構造になります（一部抜粋）。

このように、評価シートを作っておけば「A 社と B 社の差は 2 点で、決定要因は提案妥当性とコストだった」と、決定根拠を具体的に説明できます。

提案書受領前にシートを完成させる理由

評価シートは提案書を受領する前に完成させ、社内の関係者で配点の合意を取っておくのが鉄則です。理由は次の 2 点です。

• 恣意性の排除: 提案書を読んでからシートを作ると、無意識に「特定の提案書の長所」を評価項目化してしまい、選びたい会社に有利な設計になる
• 社内合意のスピード化: 提案書受領後に配点を議論すると、各部門が「自部門に有利な配点」を主張し始めて議論が長引く。事前に決めておけば、評価フェーズでは「点数を付けるだけ」に集中できる

この一手間が、最終選定時の「なぜそう決めたのか」への説明を圧倒的に楽にします。

ステップ 2：デモで確認すべき観点

提案書の点数化で残った 2〜3 社に対しては、デモを実施します。デモの目的は「提案書では分からない実際の動作・体制・操作性を確認すること」です。提案書はどうしても見栄えのする書面になるため、実物を見て初めて分かる差を埋めるのがデモの役割です。

デモの目的

デモで見るべきポイントを最初に整理しておきます。

• 提案書に書かれた機能が 本当に動くか（モックアップでなく実装済みかを確認）
• 操作性・レスポンス速度が 業務で使えるレベルか
• 想定する カスタマイズ要望 に対する反応・回答
• 実装担当者（PM・リードエンジニア）が同席し、技術的な質問に答えられるか

「営業担当だけのデモ」は避けるべきです。営業担当は提案書の内容を流暢に説明できますが、実装の妥当性に踏み込んだ質問には答えられません。デモのアポイント時点で「実装責任者の同席」を依頼してください。

観点 1：既存類似プロダクトの実動作確認

デモでまず確認すべきは、提案するベンダー自身が開発した類似プロダクトの実動作です。「過去にこういう案件を担当しました」という説明だけでなく、実際の画面や処理を見せてもらいます。

確認のポイント:

• データ件数が業務想定に近いか（少件数のサンプルしか動かない場合は要注意）
• 例外処理やエラーハンドリングが実装されているか
• ログ・監視・運用画面が用意されているか

観点 2：カスタマイズ対応の柔軟性

実際の業務システムは、リリース後に必ず仕様変更が発生します。デモ中に その場で具体的な変更要望を投げ、回答内容を見ます。

良い質問例:

• 「この画面の入力項目を 1 つ増やすとしたら、工数はどのくらいですか？」
• 「この一覧画面で、検索条件を 1 つ追加する場合の見積方法を教えてください」
• 「外部 API との連携を追加する場合、見積から実装完了まで何日くらいかかりますか？」

良い回答の特徴は、前提条件と工数感を即座に答えられること（例: 「項目が文字列で、既存テーブルに収まる場合は 0.5 人日です」）。逆に「持ち帰って確認します」が連発する場合、実装に踏み込めていない可能性があります。

観点 3：技術スタック・アーキテクチャの妥当性

技術スタック・アーキテクチャは、自社の情シス担当やエンジニアが同席して確認します。同席者がいない場合は、後述のヒアリングで時間を取ってください。

確認のポイント:

• 採用言語・フレームワーク・データベースが、自社の保守体制で扱えるものか
• マネージドサービス（AWS / GCP / Azure）の利用方針と、ロックインのリスク
• 内製コードと OSS / 外部ライブラリの比率（過度に内製依存している場合、属人化リスクあり）

「最新技術を使っています」とだけ言われた場合は、「なぜその技術を選定したか」「他の選択肢と比較した結果か」を必ず質問してください。理由を説明できないベンダーは、技術選定が属人的である可能性が高いです。

観点 4：実装担当者の同席有無

デモには 実装担当者（PM・リードエンジニア） が同席しているかを確認します。営業担当だけが対応する場合、契約後に実際に開発するメンバーと評価対象がズレるリスクがあります。

可能であれば、以下を質問してください。

• 「契約後、本日同席されているリードエンジニアの方は何 % のリソースで関与いただけますか？」
• 「PM の方は他案件と兼任ですか？兼任の場合、本案件への稼働比率は？」

「契約後はメンバーが変わります」と言われた場合は、変更後のメンバーのスキル証明（経歴書・資格）の提出を求めるのが安全です。

観点 5：質疑応答での反応速度

最後に、質疑応答でのベンダー側の反応速度を観察します。技術的な質問に対して、明確に答えられない・誤魔化す傾向がある場合は、契約後のコミュニケーションでも同じ問題が起きる可能性が高いです。

【受注者視点コラム】こう聞かれると本気度が伝わる

開発を受注する立場として申し上げると、デモで「過去案件の実画面を見せてください」「この変更要望の工数は？」と踏み込まれると、こちらも本気度が試されていると感じます。逆に「御社の強みは何ですか？」のような抽象的な質問だけだと、提案書の内容を読み上げて終わりになってしまうため、ベンダーの実力を測る機会にはなりにくいのが正直なところです。

もう一つ伝えたいのは、デモの場で 「この機能は他社事例で苦労した点はありますか？」 と聞かれると、技術力のあるベンダーは喜んで具体的な失敗談を話します。隠さず話すことが信頼構築につながると分かっているからです。逆に「特に問題ありませんでした」とだけ答えるベンダーは、本当に問題が起きていなかったか、あるいは課題を整理できていないかのどちらかです。

秋霜堂株式会社（以下、秋霜堂）でも、デモの場で踏み込んだ質問をいただくと、お客様が選定責任を真剣に果たそうとされていることが伝わり、こちら側の提案密度も自然と上がります。

ステップ 3：ヒアリングで聞くべき質問例（一般案件 + AI 開発案件）

デモ後の個別ヒアリングは、契約・体制・運用面の論点を深掘りする場です。ここで聞き漏らした内容は、契約後にトラブルの種になります。本セクションでは、一般案件向けの基本質問と、AI 開発を含む案件向けの追加質問の両方を紹介します。

一般案件のヒアリング質問例（体制・契約・追加見積・SLA）

まずは全案件で必須の質問項目です。

特に 知財帰属 は契約後にトラブルになりやすい論点です。「成果物はお客様に帰属しますが、汎用的な部分はベンダー側に留保します」という曖昧な回答は要注意です。何が「汎用的な部分」かを契約書で明確にしておかないと、後から自社で改修できないリスクがあります。

コミュニケーション頻度と意思決定スピードを確認する質問

ベンダー選定後の体験を大きく左右するのが、コミュニケーション設計です。

• 定例ミーティングの頻度（週次 / 隔週 / 月次）は？
• チャットツール（Slack / Teams 等）でのリアルタイム連絡は可能か？
• 「明日までに回答が必要」のような急ぎの案件への対応スピードは？
• 仕様判断が必要な場合、ベンダー側でどこまで判断できるか？（社内エスカレーションが必要な範囲）

「週次定例だけで、その間は連絡が取りづらい」というベンダーは、トラブル発生時の対応も遅れやすい傾向があります。秋霜堂では週次定例 + リアルタイムチャット対応を標準としていますが、これを満たすベンダーは中小規模の専門ベンダーに多い印象です。

AI 開発会社向けの追加質問（PoC・学習データ・精度評価）

AI 機能を含む案件では、通常案件の質問に加えて以下の論点を確認する必要があります。AI 開発は「動くものを作る」だけでなく「精度を保証する」という追加責任が発生するため、契約構造が通常開発と異なるためです。

PoC（Proof of Concept、概念実証）の進め方が不明確なベンダーは、AI 案件の経験が浅い可能性があります。PoC の設計について深く知りたい場合はAI PoC の進め方をあわせてご覧ください。

AI 開発会社向け追加質問（本番投入後の継続運用・モデル更新）

AI システムは本番投入後の運用フェーズが本番です。学習データのドリフト（時間経過によるデータ傾向の変化）や、業務環境の変化に応じてモデルを更新する必要が生じます。

• 本番投入後のモデル精度モニタリングは誰が、どの頻度で実施しますか？
• モデル更新（再学習）の頻度・費用構造は？（月額固定 / 件数課金 / 都度見積）
• 学習データの蓄積・管理基盤（特徴量ストア・MLOps 基盤）は提供されますか？
• モデルの説明可能性（なぜその判定をしたかの根拠提示）はどこまで対応可能ですか？

AI 開発会社の選び方をより詳しく知りたい場合はAI 開発会社の選び方もあわせて参照してください。

「答えに詰まる回答」をどう評価するか

ヒアリングでは、答えに詰まる質問が必ず出てきます。重要なのは、詰まり方を評価することです。

• 良い詰まり方: 「現時点では即答できないので、明日中に再回答します」と宣言し、実際に翌日回答してくる
• 悪い詰まり方: 曖昧な一般論で誤魔化す、「契約後に詳細を詰めましょう」と先送りにする

詰まる質問が出ること自体は、踏み込んだ質問ができている証拠です。回答プロセス（持ち帰り → 確実な再回答）が機能しているか で本気度を判断してください。

ステップ 4：最終選定の意思決定と落とし穴

評価シートの集計、デモ評価、ヒアリング結果を踏まえて、最終的に 1 社を選定します。本セクションでは、点数集計の方法と、最終段階で陥りやすい意思決定の落とし穴を解説します。

点数集計と僅差時の判定方法

各社の総合点を集計したら、まずは 点差を確認 します。点差別の対応方針は次の通りです。

• 20 点以上の差: 上位社を選定。ただし、上位社の致命的な弱点（例: セキュリティ評価が著しく低い）がないかを最終確認する
• 5〜20 点の差: 上位 2 社で評価会議を開催。デモ・ヒアリングでの定性評価（社内の体感的な評価）を加味して判断する
• 5 点未満の差: 評価項目の重要度を社内で再議論し、配点の重み付けを調整した上で再集計する

点差が僅差の場合、安易に「両社とも甲乙つけがたい」で判断を先送りすると、最終的に最安値や知名度で選んでしまいがちです。評価会議では「もし 5 点しか差がなければ、自社にとってどちらの強みがより重要か」を改めて議論する手順を踏んでください。

落とし穴 1：最安値選択バイアス（安さの裏側にあるリスク）

最も陥りやすいバイアスが「最安値選択」です。価格は最も分かりやすい比較軸であるため、社内議論が長引くと最終的に「とりあえず安い方」で着地しがちです。

しかし、システム開発において価格差は 次のリスクの裏返し であることが多いです。

• 経験の浅いエンジニアをアサインし、結果的に開発期間が延びる
• 機能要件を最低限のラインで解釈しており、追加要件で見積が膨らむ
• ドキュメント整備・テストカバレッジが不足し、運用フェーズの保守費用が高くつく

JUAS の企業 IT 動向調査 2024が示すように、システム開発の QCD 遵守率は近年悪化傾向にあります。最安値ベンダーが結果的に最高コストになるケースは珍しくないため、価格差の理由を提案書・ヒアリングで必ず確認してください。

落とし穴 2：大手信仰バイアス（中小・専門ベンダーが優位なケース）

逆のバイアスが「大手信仰」です。「大手なら安心だろう」という心理は社内説明もしやすく、選定者の心理的な安心感も大きいため、選びがちです。

ただし、案件によっては中小・専門ベンダーが優位なケースもあります。

• 小規模案件（〜 1000 万円程度）: 大手では PM が複数案件を兼任し、責任者の関与が薄くなる
• アジャイル前提の案件: 大手は階層が深く、意思決定スピードが遅い
• 特定領域の専門性が必要な案件（AI / IoT / Web3 等）: 専門ベンダーの方が深い知見を持つことが多い

選定の際は「自社の案件規模・特性に対して、どのベンダー規模が最適か」を冷静に判断してください。会社規模ではなく、担当チームの実力 で評価する視点が重要です。

落とし穴 3：直近成功体験バイアス（過去案件と異なる失敗要因）

「前回の発注はうまくいったから、今回も同じやり方で」というバイアスも要注意です。前回案件と今回案件で、要件・期間・体制・関与者が変われば、成功要因も変わります。

具体的には次の点を確認してください。

• 前回案件と今回案件で、技術スタックが大きく異なる場合 → 前回ベンダーが今回案件の技術に対応できるか
• 前回案件より大規模・長期になる場合 → ベンダー側の体制スケーラビリティ
• 前回と異なる業界知識が必要な場合 → 業界特有の規制・商習慣への対応経験

過去の関係性は重要ですが、それだけで決めるのは避けてください。過去案件と今回案件の差分 を整理し、その差分にベンダーが対応できるかを評価軸に加えるのが安全です。

稟議・社内説明用に残しておくべき選定記録

最終選定後は、稟議資料として次の記録を残してください。後から「なぜそう決めたのか」を問われた際の説明責任を果たすためです。

• 評価シート（全候補社分）: 配点・採点・スコア・総合点
• デモ議事録: 各社のデモ実施日・参加者・質問項目・回答概要
• ヒアリング回答記録: 質問項目と各社の回答（特に契約・体制・追加見積に関する論点）
• 評価会議議事録: 最終選定にあたっての議論内容・決定理由・反対意見の有無
• 最終決裁理由書: 「●社を選定した 3 つの理由」を経営層向けに 1 ページにまとめた要約

これらが揃っていれば、プロジェクトが想定通りに進まなかった場合でも「妥当なプロセスで選定した」ことを根拠を持って示せます。選定記録の文書化は、発注担当者自身を守る最大の保険です。

まとめ：評価プロセスを定型化することが、選定責任を担保する

本記事では、RFP 後のベンダー評価方法を「提案書評価 → デモ → ヒアリング → 最終選定」の 4 ステップで解説しました。各ステップの要点を再掲します。

• ステップ 1（提案書評価）: 受領前に評価シートを完成させ、4 カテゴリ × 配点強弱で点数化する
• ステップ 2（デモ）: 実装担当者の同席を必須とし、カスタマイズ要望をその場で投げて反応速度を見る
• ステップ 3（ヒアリング）: 体制・契約・追加見積・SLA を確認。AI 案件は PoC・学習データ・精度評価・継続運用の追加質問を行う
• ステップ 4（最終選定）: 点差別の判定ルールを決め、最安値・大手信仰・過去成功体験のバイアスを排除する

ベンダー選定に「正解」はありません。しかし、定型化されたプロセスで選ぶことで、結果が良くも悪くも「妥当なプロセスで選んだ」と説明できる体制が整います。これが、発注担当者にとっての最大の保険であり、裏テーマである「選定責任を後から問われることへの恐れ」への回答です。

今すぐ着手できるネクストアクションとしては、次の 2 つをおすすめします。

1. 今週中に評価シートのドラフトを作る: 4 カテゴリを軸に、自社の優先度を反映した配点を設計する
2. 社内合意を取る: 配点の妥当性を経営層・利用部門と共有し、提案書受領前に合意を取っておく

なお、RFP 自体の品質に課題を感じている方はシステム開発 RFP の書き方をあわせてご覧ください。RFP の品質が高いほど、提案書の比較もスムーズに進みます。

—Free Download / 資料ダウンロード

システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集

この資料でわかること

システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。

こんな方におすすめです

• 初めてシステム開発を外注する担当者
• 過去の発注で失敗を経験した方
• ベンダー選定の基準が分からない方

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。