インフラRFPの書き方とベンダー評価マトリクス｜RFIとの違いも解説

こんにちは、もっちです！

私は大手SIerに18年勤務し、現在はオンプレミスやクラウドのインフラ基盤を統括するサービスマネージャーとして、日々ベンダーコントロールや設計・運用の最適化に取り組んでいます。

インフラの構築や大規模な更新プロジェクトにおいて、外部のベンダー（SIer）へ作業を委託する際に欠かせないのがRFP（提案依頼書：Request for Proposal）です。

しかし、現場でこんな悩みを抱えていませんか？

「RFPを出して提案・見積もりをもらったのに、構築が始まってから『それは範囲外です』と追加見積もりを突きつけられた…」
「価格の安さで選んだベンダーが、リリース後に不具合を出したまま対応を放置して炎上した…」
「そもそもRFPに何を書けば、ベンダーから精度の高い提案を引き出せるのかわからない…」

私自身、SIer側で提案書を書く「受注側」の経験と、サービスマネージャーとしてベンダーを選定・コントロールする「発注側」の経験の両方を18年間で積み重ねてきました。

今回はその両方の視点から、トラブルを未然に防ぎ、実効性の高い提案を引き出すためのRFPの書き方・テンプレートと、失敗しないベンダー評価マトリクスの作り方を余すことなく解説します！

なぜ「標準的なRFP」では追加見積もりと炎上が起きるのか？【実録トラブル】

一般的なWebサイトや本に載っている「標準的なRFPフォーマット」をそのまま使って発注しても、現場ではトラブルが絶えません。なぜなら、現場レベルでの「細かな認識のズレ」が抜け落ちているからです。

私自身も過去に、設計や段取りはベンダーと入念にすり合わせていたにもかかわらず、大きな落とし穴にはまった経験があります。

① ドキュメントフォーマットの認識ズレが招く「追加費用」の罠

あるプロジェクトで、インフラの構築や手順のすり合わせは順調に進んでいたのですが、「成果物ドキュメントの取り決め」が甘かったことがありました。

ベンダーから提出された通信要件定義書、可用性やパフォーマンスの根拠資料、運用手順書などのフォーマットが、自社で定めている標準フォーマットと全く異なっていたのです。

自社の運用基準に合わせるため「社内標準フォーマットに書き直してください」と依頼したところ、ベンダーからはこう返答されました。

「提案時の見積もりは当社の標準フォーマット作成を前提としています。御社指定のフォーマットへ打ち直し・再整理を行う場合、追加工数として別料金が発生します。」

設計内容自体は合意できていたにもかかわらず、ドキュメントの「形式」を定義していなかっただけで、想定外の追加費用が発生してしまったのです。

② リリース直後の落とし穴！「構築メンバー不在」で現場が詰む理由

もう一つの痛い失敗は、「リリース直後の初期サポート期間」の取り決めです。

RFPで「本番リリースまで」の範囲しか明確に定義しておらず、リリース後数ヶ月間の専任サポート期間を要件に盛り込んでいませんでした。

結果として、無事に本番稼働を迎えた直後、構築を担当したベンダーのエキスパートエンジニアたちは一斉に別プロジェクトへ引き揚げてしまいました。

リリース直後に細かな初期不具合や調整が発生した際、対応してくれたのはシステムの背景や経緯を知らない「標準の保守サポートエンジニア」だけ。仕様の意図を把握してもらうまでに多大な時間がかかり、障害対応が泥沼化して現場が疲弊することになりました。

RFIとRFPの違いとは？発注決定までに「半年」かけるべき理由とスケジュール

RFP作成で失敗しないためには、前段階であるRFI（情報提供依頼書：Request for Information）との使い分けと、余裕を持ったスケジュール設計が不可欠です。

【比較】RFIとRFPの目的の違い

• RFI（情報提供依頼書）：ベンダーに対して「技術的実現性」や「市場での概算価格」「技術トレンド」の情報提供を求めるもの。自社の構想段階で発行する。
• RFP（提案依頼書）：RFIで得た情報をもとに、自社の具体的な要件を提示し「具体的な構成案・スケジュール・正確な見積もり」を求めるもの。選定段階で発行する。

いきなりRFPを作成しようとすると、技術的な実現性や市場相場がわからないため、要件がブレて不完全なRFPになってしまいます。

RFIから発注決定までの「半年間」のリアルなロードマップ

大規模なインフラ更新や基盤刷新においては、RFI提出から最終発注まで「最低でも半年（6ヶ月）」の期間を見込むのが実務上のリアルな感覚です。

時期	フェーズ	主な作業内容・ポイント
1〜2ヶ月目	RFI提出・情報収集	複数ベンダーへRFIを送付。技術動向や他社事例、概算コストの情報が出揃うまでに1〜2ヶ月を要する。
3〜4ヶ月目	構成検討・RFP作成	RFIで集めた情報をもとに自社の非機能要件や予算を整理。具体的なRFPと評価マトリクスを作成。
5〜6ヶ月目	提案コンペ・社内調整	ベンダーからの提案・プレゼン実施。選定後、社内稟議の作成、経営層説明、法務部による契約書チェックを経て最終発注へ。

このスケジュールを無理に短縮して突貫でRFPを発注すると、社内調整の不備やベンダー側の検討不足を招き、プロジェクト開始後に炎上するリスクが一気に高まります。

受注側（SIer）が「圧倒的に書きやすい」と感じるRFPの必須記載項目

私が大手SIer側で提案書（回答）を作成していた時代、発注者から提示されて「この案件は非常に提案がしやすい！精度の高い見積もりが作れる！」と感じたRFPには明確な共通点がありました。

それは、「要件が定量的な『数値目標』として定義されていること」です。

「現状踏襲」や「予算と納期だけ」のRFPがSIerを困らせる理由

逆に、最も困るのが次のようなRFPです。

• 「現行システムと同等の構成で提案してください（※ただし現行の仕様書や設定情報は不十分）」
• 「予算〇〇万円、納期〇月でできる最大限のインフラを提案してください」

要件が曖昧だと、受注側SIerとしては「想定外のリスク」を考慮せざるを得ません。

結果としてリスク対策費や予備工数を手厚く積んだ「高額な安全倒しの見積もり」を出さざるを得なくなります。あるいは、安く受注するために必要な工程を削った「危険な提案」が通ってしまうのです。

提案精度を激変させる「数値目標」の提示

SIerから最適な提案を引き出すためには、RFPに以下の必須項目と「数値目標」を盛り込みましょう。

1. 背景とビジネス上の目的：なぜこのインフラ更新を行うのか（単なる老朽化更新か、業務拡大対応か）。
2. 対象範囲（スコープ）：オンプレ・クラウドの境界、ネットワーク範囲、移行データの容量。
3. 定量的な非機能要件：
   • 可用性：稼働率（例：99.9%）、許容できるダウンタイム。
   • 性能・容量：ピーク時のCPU/メモリ使用率の上限、同時接続ユーザー数、データ増加予測。
   • BCP/DR：目標復旧時間（RTO）、目標復旧ポイント（RPO）。
4. 成果物ドキュメントの指定：自社指定フォーマットの有無、提出形式（Word/Excel/Markdown等）。
5. 運用・サポート要件：本番稼働後〇ヶ月間の初期手厚サポート体制の明記。

インフラRFP（提案依頼書）の基本構成案と必須記載項目

実際のRFP作成時にそのまま使える、標準的な目次構成テンプレートを作成しました。このフォーマットに沿って自社の要件を埋めていくことで、抜け漏れのないRFPが完成します。

インフラシステム構築・更新に関する提案依頼書（RFP）構成案

• 1. 概要・背景
  • 1.1. 本プロジェクトの背景および目的
  • 1.2. 実施体制（発注側体制図）
  • 1.3. 全体スケジュール（提案〜本番稼働・運用移行）
• 2. システム提案要件（機能・構成）
  • 2.1. システム対象範囲（オンプレ/クラウド/ネットワーク/セキュリティ）
  • 2.2. 現行システムの課題および刷新方針
  • 2.3. 想定システム構成および技術要件
• 3. 非機能要件（品質・性能）
  • 3.1. 可用性・信頼性（SLA/稼働率目標：99.9%等）
  • 3.2. 性能・拡張性（同時接続数/リソース増設上限）
  • 3.3. 運用・保守性（監視項目/一次切り分け範囲）
  • 3.4. BCP/セキュリティ要件（RTO/RPO/バックアップ頻度）
• 4. 成果物およびドキュメント要件
  • 4.1. 納品ドキュメント一覧（設計書/テスト仕様書/運用手順書）
  • 4.2. ドキュメントフォーマット指定（当社指定フォーマットへの準拠）
• 5. 導入・保守サポート要件
  • 5.1. 移行計画およびダウンタイム制限
  • 5.2. リリース後初期手厚サポート体制（構築メンバーによる〇ヶ月間対応）
• 6. 提案手続き・選定方法
  • 6.1. 質問回答の受発注スケジュール
  • 6.2. 提出書類および見積書の形式（概算費用と内訳）
  • 6.3. ベンダー選定基準（技術力/体制/運用性/価格の総合評価）

価格だけで選ぶと後悔する！ベンダー評価マトリクスと「プロの見極めポイント」

RFPを送付してベンダーから提案書が出揃ったら、公平かつ多角的に評価するための「ベンダー評価マトリクス（評価スコアシート）」を作成します。

価格の安さだけで選ぶと、構築品質の低さや運用のしづらさで後から何倍ものコストがかかります。価格と技術・体制の評価配分は「価格40%：技術・体制・運用性60%」程度の傾斜をつけるのがおすすめです。

ベンダー選定評価マトリクスの例

評価カテゴリー	配点	評価チェック項目	プロの着眼点
要件適合性	25点	RFPで提示した数値目標（SLA/RTO等）を満たしているか	実現施策に無理がなく、技術的根拠が明確か
ドキュメント	10点	指定フォーマットへの対応、納品物一覧の明確さ	過去のサンプル等で記載レベルを確認できるか
運用・移行性	15点	移行時のダウンタイム削減策、運用移管フローの妥当性	構築後の運用チームが困らない設計になっているか
体制・サポート	20点	リリース後の初期サポート体制と要員配置	構築に携わったメインエンジニアがサポートに入るか
費用・価格	30点	提示価格の妥当性、追加費用発生条件の明記	範囲外作業の単価や変更管理ルールが明確か

プロの見極めポイント：「リリース後サポートに『構築メンバー』が入っているか？」

評価マトリクスの中でも、私が特に重視しているプロの着眼点があります。

それは、「本番リリース後の初期サポート（1〜3ヶ月程度）において、構築を担当した主要メンバーが直接対応してくれる体制になっているか？」という点です。

プレゼンや提案書でここを確認すると、ベンダーの姿勢がはっきりと分かります。

• 信頼できるベンダー：「構築を担当したリードエンジニアが、リリース後1ヶ月間は二次受け・QA対応として体制に残ります」と明記してくれる。
• 注意が必要なベンダー：「リリース翌日からは当社の標準運用保守窓口（コールセンターや共通サポート）へ移管されます」という体制になっている。

自分たちが作ったシステムに対して、リリース後も不具合から逃げずに最後まで責任を持って伴走してくれるベンダーかどうか。これこそが、長期的に信頼できるパートナーを見極める最大の踏み絵になります。

まとめ：RFPは作って終わりではない！パートナーシップを構築する最初の一歩

今回は、丸投げや足もと見られを防ぐためのRFPの書き方とベンダー評価マトリクスについて解説しました。

1. ドキュメントフォーマットやリリース直後のサポート体制をRFPで明記し、追加費用と炎上を防ぐ
2. RFIから発注決定まで「半年」のロードマップを組み、要件を熟成させる
3. SIerが提案しやすいよう、定量的な「数値目標」とテンプレートを活用してRFPを作成する
4. 評価マトリクスでは価格だけでなく「構築メンバーによるリリース後サポート」の有無を見極める

RFPは単なる「発注のための指示書」ではありません。発注側と受注側が同じゴールを目指し、対等で健全なパートナーシップを築くための「最初の契約（コミュニケーション）」です。

曖昧な丸投げをやめ、明確な意志と基準を持ったRFPを作成することで、ベンダーはあなたにとって最強の味方になってくれます。

ベンダーコントロールの全体像や、対等な関係を築くためのマインドセットについては、ぜひこちらの記事も参考にしてみてください！