LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

RFPとは何か——提案依頼書の役割と発注プロセスにおける位置づけ

RFP（Request for Proposal：提案依頼書）とは、システムやアプリの開発を外部ベンダーに発注する際に、発注者がベンダーに対して提案内容・見積もり・対応方針を求めるために作成する文書です。単なる仕様書とは異なり、「何を・なぜ・どのくらいの予算と期間で実現したいか」を体系的に伝えることで、複数のベンダーから比較可能な提案を引き出す機能を持ちます。

発注プロセスの観点でいうと、RFP作成は「RFI（Request for Information：情報提供依頼書）でベンダーの技術力や市場概況を把握した後、提案を募る段階」に位置します。ここで作成したRFPの品質が、後続の提案評価・ベンダー選定・契約・要件定義のすべてに影響を及ぼします。

発注担当者にとってRFP作成が難しいのは、「何をどこまで書けばよいか」の基準が社内にないためです。書き足りなければベンダーから的外れな提案が届き、書き過ぎると過度に詳細な仕様になって競争性が失われます。この「適切な粒度」を判断するには、調達・ITの両面の経験が求められます。

RFPに盛り込む6つの必須項目

RFPに何を書くかは発注する案件の性質によって変わりますが、システム・アプリ開発の場合は次の6項目が骨格になります。抜け漏れがあると、ベンダーが仮定を設けて見積もりを提出せざるを得なくなり、後から追加費用や仕様変更トラブルにつながります。

IPA（独立行政法人情報処理推進機構）は「情報システム・モデル取引・契約書」においてユーザー企業とITベンダー間の取引構造の透明化を目的とした各開発段階の責務解説と契約書ひな型を提供しています^*1。RFPを作成する際は、この資料を参照することで発注者側が準備すべき情報の範囲を把握できます。

RFP作成を外注・支援会社に依頼する3つのメリット

メリット1：「適切な粒度」の要件整理——発注経験が少ない企業が直面する壁を乗り越えられる

RFP作成に不慣れな担当者が直面する中心的な課題は、「どこまで要件を詰めてからRFPに書けばよいか」という粒度の判断です。書き込みが浅いと「何でも対応できます」という曖昧な提案が集まり、書き込みが深すぎると「要件定義を発注者がやってしまった」状態になってベンダーの創意工夫が生かせません。

支援会社に依頼すると、多数の発注案件をサポートした経験から「この業務種別ならこの粒度で書く」という感覚を持った担当者がヒアリングを行います。担当者が言語化できていない課題を引き出すファシリテーションも含まれるため、RFPの完成度が大きく変わります。

メリット2：複数ベンダーへの公平な比較条件——恣意的な選定リスクを排除できる

RFPには同一の条件でベンダーに提案を求める「競争性の確保」という機能があります。しかし発注者が特定ベンダーとの関係を持った状態でRFPを作成すると、意図せずそのベンダーに有利な要件や評価基準が組み込まれるリスクがあります。

第三者の支援会社が関与することで、特定ベンダーへの利益誘導が起きにくい中立的なRFPが作成できます。稟議・内部統制の観点からも、外部支援の記録は発注プロセスの透明性を示す根拠になります。

メリット3：後続の要件定義・契約リスクの軽減——RFPの質が契約トラブルを防ぐ

システム開発のトラブルの一因は、発注時の要件があいまいなまま契約したことにあります。「言った・言わない」の仕様紛争、追加費用の請求、納品後の品質不満といった問題は、多くの場合RFP段階の定義不足に起因します。

支援会社がRFPの段階で要件の整合性・矛盾・抜け漏れを指摘することで、契約後に発覚する変更コストを抑えられます。RFP作成への投資は、後工程の手戻りを減らすための予防的なコストと捉えることができます。

RFP作成外注の進め方——依頼から納品まで5ステップ

RFP作成の外注は以下のステップで進めます。各ステップの役割分担を事前に確認することで、支援会社との作業が円滑になります。

ステップ1：社内の課題・目的を言語化する（発注者側の事前準備）

支援会社に依頼する前に、「なぜこのシステムを作るのか」「誰が使うのか」「どんな課題を解決したいのか」を社内で議論しておく必要があります。この事前整理が不十分だと、支援会社とのヒアリングが発散してしまいます。

最低限用意しておくべき情報は、①現状の業務フロー（箇条書きでも可）、②システム利用想定ユーザー数・部門、③大まかな予算感と稼働希望時期の3点です。

ステップ2：支援会社の選定・依頼（キックオフ前）

支援会社の選定は、後述する「外注先選定で確認すべき4つのポイント」を参照してください。選定後は、守秘義務契約（NDA）を締結してからヒアリングに入ります。開発対象が業務システムか、スマートフォンアプリか、SaaSか、などによって支援会社に必要な知見が変わります。

ステップ3：ヒアリング・要件整理（支援会社主導）

支援会社が発注者の現場担当者・IT部門・経営層へのヒアリングを実施し、課題・目的・制約条件を整理します。ヒアリングは複数回に分けて行われることが多く、業務部門と情報システム部門で意見が食い違う箇所を丁寧にすり合わせます。

この段階で、市場に存在する類似システムの相場感や主要ベンダーの特性についての情報提供を受けられる場合もあります。

ステップ4：RFP草案の作成・レビュー（共同作業）

支援会社がRFP草案を作成し、発注者がレビューを行います。レビューでは「自社担当者がベンダーに口頭説明なしで意図を伝えられるか」を基準に確認します。専門用語が多すぎる・抽象的すぎる・逆に詳細すぎるといった点を調整します。

ステップ5：RFP配布・質疑応答対応（最終フェーズ）

完成したRFPをベンダーに配布し、質疑応答対応と提案書の受け取りに移ります。支援会社によっては、提案評価のフレームワーク作成や評価補助まで対応する場合があります。

費用の考え方——市場参考値と変動要因

RFP作成支援の費用は、対象システムの複雑さ・ヒアリング回数・ドキュメントの深度によって大きく変動します。以下は市場参考値であり、一次資料に基づく確定値ではありません。実際の見積もりは複数の支援会社に問い合わせてご確認ください。

費用に影響する主な変動要因は以下の4点です。

• システムの複雑さ：業務領域が多岐にわたるほどヒアリング工数が増えます。
• 関係者の人数：ヒアリング対象者が増えるほど、日程調整・資料整理の工数が上がります。
• 成果物の範囲：RFP本文のみか、RFI・評価シート・ベンダー候補リストまで含めるかで変わります。
• 期間・スピード：短期集中で仕上げるほど費用が上がる傾向があります。

相見積もりを取る際は、「ヒアリング回数」「成果物の範囲」「改訂回数の上限」を各社に明示して比較することで、提示価格の根拠を正確に比較できます。

RFI・要件定義・提案評価との関係を整理する

RFP作成の前後に存在するプロセスの関係を理解しておくことで、支援会社に依頼する範囲を的確に絞れます。

RFI（情報提供依頼書）との違い——RFPの前段に位置する市場調査ツール

RFI（Request for Information：情報提供依頼書）は、RFPを作成するための情報収集を目的とした文書です。「どんなベンダーが存在するか」「どんな技術的アプローチが市場にあるか」を把握するために配布します。RFIで得た情報をもとに、RFPの要件や評価基準を具体化するという順序になります。

RFP作成支援を依頼する場合、支援会社が「RFIは必要か・不要か」を判断するヒアリングを最初に行います。発注者の課題が明確で市場情報が十分にある案件ではRFIを省略できますが、新技術領域や先例が少ない業務システムではRFIから始めることが多いです。

要件定義との関係——RFPは「要件定義の前段」であり混同しない

要件定義（Requirements Definition）は、発注先が決まった後に発注者とベンダーが共同で行う詳細な仕様策定プロセスです。RFPはその前段——「どのベンダーに要件定義を委託するかを決めるための競争資料」です。

RFPに書く要件はあくまで「概要・方向性」であり、詳細仕様は要件定義フェーズで固めます。この違いを理解していないと、RFP段階で過度に細かい仕様書を作ってしまい、発注者が要件定義をやり切った状態でベンダーに発注するという本末転倒な事態が起きます。

提案評価との関係——RFPの評価基準が選定の公平性を左右する

ベンダー提案を受け取った後の提案評価では、RFPに記載した評価基準をスコアリングシートに落とし込んで採点します。評価基準の重み付けが不明確だと、「安いベンダーを選ぶ」「担当者の主観で選ぶ」といった問題が起きます。支援会社によっては提案評価シートの設計まで支援範囲に含む場合があり、このフェーズを外注に含めるかどうかを最初に確認しておくことが大切です。

外注先選定で確認すべき4つのポイント

確認ポイント1：発注側の立場に立った実績があるか

RFP作成支援の会社には、「ITコンサルティング会社」「PMO支援会社」「IT調達専門会社」「システム開発会社の上流工程担当」など、複数の形態があります。重要なのは、その会社が「発注者側（ユーザー企業側）」の代理人として動いた実績を持つかどうかです。

ベンダー側の経験しかない会社は、特定の技術スタックや開発手法に偏ったRFPを作りがちです。発注者の利益を中立的に代弁できるかを、過去の支援事例や担当者のキャリアで確認してください。

確認ポイント2：対象業務・システム領域の知見があるか

業務基幹システム（ERP・会計）、スマートフォンアプリ、SaaS型サービス、社内向け業務ツールでは、RFPに盛り込む項目や評価基準が大きく異なります。支援会社の過去実績で類似した業種・システム種別の案件があるかを確認します。

専門知見がない支援会社に依頼すると、汎用テンプレートに当てはめただけの画一的なRFPができあがり、発注案件の特性が反映されないリスクがあります。

確認ポイント3：社内への関与度合いを明示できるか

RFP作成は「書いてもらう」だけでは機能しません。発注者の業務担当者・IT部門・経営者へのヒアリング、内部調整への伴走が必要です。支援会社が「ヒアリング回数」「関与する社内レイヤー」「業務担当者への説明会の有無」を提案段階で明示できるかを確認してください。

ヒアリングが1〜2回で済むような提案は、表面的な整理にとどまる可能性があります。要件の複雑さに応じた関与計画を提示できる会社を選ぶことが大切です。

確認ポイント4：成果物の範囲と改訂対応の条件を確認する

「RFP本文の納品」だけで契約が終わる会社もあれば、「配布後の質疑応答対応・評価補助」まで含む会社もあります。成果物のスコープと、完成後の改訂・追加対応の条件（含まれるか・別途費用か）を契約前に明確にしておく必要があります。

発注後に「ここまでは対象外でした」というトラブルを防ぐために、成果物の定義と受け渡し条件を書面で確認することを推奨します。

まとめ——RFP作成支援を活用して発注品質を高める3つの判断軸

本稿では、RFPとは何か・記載必須の6項目・外注メリット・進め方・費用の考え方・RFI／要件定義との関係・外注先選定を整理しました。要点を3つに集約します。

第一に、RFPの品質は後続のベンダー選定・契約・要件定義のすべてに影響します。発注経験が少ない企業ほど、外注支援によって「適切な粒度の要件整理」と「ベンダー比較の公平性」を担保することが、後工程の手戻りコスト削減につながります。

第二に、RFP作成外注の費用は「支援範囲」「ヒアリング回数」「成果物の定義」によって変動します。相見積もりの際は支援スコープを明示して比較し、「書いてもらうだけ」の形式的な発注を避けることが大切です。

第三に、外注先選定では「発注者側の立場での支援実績」「対象業務・システム領域の知見」「社内関与の計画」「成果物範囲の明確さ」の4点を確認することで、支援会社の実力を見極められます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書」（2025年公開・随時更新）

Tweet