「システム会社や委託先に声をかけたいけれど、何をどう伝えればいいか分からない」「相見積もりを取ってみたら、各社の提案内容も金額もバラバラで、そもそも比較検討ができない」「導入後に『あれもできない、これも別料金』と言われるトラブルだけは避けたい」
新しいシステム導入やコールセンター業務の委託（BPO）を検討する際、こうした悩みに直面する担当者は少なくありません。「プロなんだから、いい感じの提案を持ってきてほしい」と言いたくなる気持ちは痛いほど分かります。RFP（提案依頼書）の作成は、専門知識が必要で骨の折れる作業だからです。
しかし、この「こちらの要望を曖昧にしたままの依頼（丸投げ）」こそが、プロジェクトが炎上し、コスト超過や納期遅延を招く最大の火種となります。
本記事では、業者にこちらの要望を正確に伝え、自社の課題解決に直結するパートナーを選ぶための「RFPの書き方」と必須項目について解説します。
なぜRFP（提案依頼書）が必要？トラブルを防ぐ役割
口頭依頼が招く「言った言わない」トラブル
システム導入や業務委託において、最初に行うべきは「自分たちが何を求めているか」を明確に文書化することです。この文書をRFPと呼びます。
RFP（Request For Proposal）とは？
提案依頼書のこと。発注企業が、システム開発会社やBPOベンダー（受注側）に対して、具体的なシステム要件や業務範囲、解決したい課題、予算などを提示し、提案を依頼するための文書。
これと似た言葉に「RFI」がありますが、役割が異なります。
RFI（Request For Information）とは？
情報提供依頼書のこと。RFPを作成する前段階で、ベンダーがどのような技術や実績を持っているか、概算でいくらかかりそうかといった「情報収集」のために発行する文書。
RFPを作成せず、口頭やメールだけで「コールセンターを効率化したい」と依頼してしまうと、ベンダー側はそれぞれの解釈で提案を作ります。その結果、発注側は「当然やってくれると思っていた機能が含まれていない」、ベンダー側は「その機能は要件に入っていなかった（別料金だ）」という認識のズレが生じます。
これが、プロジェクト後半で発生する「言った言わない」のトラブルの原因です。RFPは、こうした認識齟齬による追加費用やトラブルを防ぐための、プロジェクトの憲法のような役割を果たします。
各社の提案を「横並び」で比較するために
RFPを作成するもう一つの重要な目的は、複数のベンダーからの提案を公平に比較検討するためです。もし、こちらの条件（前提、範囲、ゴール）を統一せずに相見積もりを取ったらどうなるでしょうか。あるベンダー（A社）は「最高品質のフル機能プラン（松コース）」を提案し、別のベンダー（B社）は「最低限の機能に絞った格安プラン（梅コース）」を提案してくるかもしれません。
これでは、出てきた見積金額に数倍の開きが生じ、金額だけで良し悪しを判断することが不可能になります。すべてのベンダーを「同じ前提条件」という土俵に乗せることが不可欠です。
また、ベンダーは外部の人間であり、自社の内部事情まで察してくれるわけではありません。自社が抱える「現状の課題」と「目指すべきゴール」を明確に提示しなければ、実効性のある提案を引き出すことは不可能です。RFPは単なる依頼書ではなく、自社の運命を預けるパートナーを見極めるための、大切なコミュニケーションツールであると認識しましょう。
参考：RFP標準項目一覧
| 大項目 | 中項目 | 詳細内容（記載すべき具体的な要件） |
| プロジェクト概要 | 背景・目的 | なぜこのプロジェクトが必要なのか、解決したい経営課題・業務課題。 |
| 目標・ゴール | 定量的目標（KPI）および定性的ゴール。 | |
| 全体スケジュール | 提案締切、選定時期、着工、リリース予定日。 | |
| 現行状況 | 業務フロー | 現状の業務プロセス（AS-IS）と課題点。 |
| システム構成 | 現行のハードウェア、ソフトウェア、ネットワーク、データ量。 | |
| システム要件 | 機能要件 | 実装必須な機能、外部システム連携要件。 |
| 非機能要件 | 可用性、性能、拡張性、運用・保守性、移行性、セキュリティ。 | |
| 技術制約 | 指定のOS、DB、クラウドプラットフォーム、開発言語など。 | |
| プロジェクト管理 | 実施体制 | プロジェクトマネジメント方針、報告ライン、会議体。 |
| 役割分担 | 発注側と受注側の責任分界点（RACIマトリクス等）。 | |
| 提案依頼事項 | 提案書構成 | 提出書類の目次指定、ファイル形式、ページ制限。 |
| 概算見積 | 開発費用、ライセンス費用、保守運用費用の内訳。 | |
| 契約・評価 | 契約条件 | 契約形態（準委任・請負）、検収条件、瑕疵担保責任（契約不適合責任）。 |
| 選定基準 | 採点基準（技術点・価格点の配分）、評価プロセス。 |
RFPの作成｜ステップ1：課題と目標数値（KPI）の定義
現状の課題と「As-Is / To-Be」の明記
RFP作成の第一歩は、自社の現状と、目指すべき姿のギャップを言語化することです。これをビジネス用語で「As-Is / To-Be」と呼びます。
As-Is / To-Beとは？
「As-Is（アズイズ）」は現在の状態、「To-Be（トゥービー）」はあるべき理想の姿を指す。この2つの差分が、プロジェクトで解決すべき「課題」となる。
単に「電話がつながりにくいので改善したい」という抽象的な表現では不十分です。「現在の応答率は70%であり（As-Is）、これを導入後3ヶ月以内に90%まで引き上げたい（To-Be）」といったように、具体的な数値を用いて記述します。他にも「放棄呼を現在の半分以下にしたい」「オペレーターの研修期間を1ヶ月から2週間に短縮したい」など、解決したい悩みとその指標を明確にします。
この情報があって初めて、ベンダーは「応答率を上げるために、このシステム機能が必要です」「研修短縮のために、このFAQツールを使いましょう」といった、根拠のある解決策を提案できるようになります。
サービスレベル（SLA）と業務範囲の線引き
次に、ベンダーに求める「責任の範囲」と「品質の基準」を明確にします。
SLA（サービスレベルアグリーメント）とは？
サービス品質保証のこと。発注者と受注者の間で合意する「サービスの定義、範囲、品質基準」を定めたもの。
KPI（重要業績評価指標）とは？
目標の達成度合いを計測するための定量的な指標。応答率、AHT（平均処理時間）、稼働率などが該当する。
特に業務委託（BPO）の場合、どこまでをベンダーに任せるかの線引き（責任分界点）が重要です。「電話対応のみ」なのか、「メールやチャット対応」も含むのか。「平日の9時-18時」なのか、「土日祝を含む24時間365日」なのか。また、システム導入であれば、「サーバーの保守」は誰がやるのか、「障害時の復旧目標時間」はどうするかなどを指定します。
これらが曖昧だと、ベンダーはリスクを見込んで高めの見積もりを出すか、逆に安く見せるために必要なサポートを削って提案してくる可能性があります。後々の追加請求を防ぐためにも、範囲とレベルは厳密に定義しましょう。
RFPの作成｜ステップ2：導入後のトラブルを防ぐ要件定義
機能要件と非機能要件の洗い出し
具体的なシステムの要望を記述するフェーズです。ここでは「機能要件」と「非機能要件」の2つに分けて整理します。
「機能要件」とは、システムが具体的に何をするべきかという要求です。「全通話を自動録音したい」「CRM（顧客管理システム）と連携して着信時にポップアップさせたい」「IVR（自動音声）で用件ごとに着信を振り分けたい」といった、業務に必要な機能をリストアップします。この際、「最新のAI機能が欲しい」といった手段を目的化した書き方ではなく、「後処理時間を短縮するために、通話内容を要約する機能が欲しい」というように、目的ベースで記述することが重要です。
一方、「非機能要件」とは、性能や安定性に関する要求です。「24時間365日止まらないこと（可用性）」「画面表示は1秒以内であること（性能）」「最大同時通話数100回線に耐えられること（拡張性）」などが該当します。機能面ばかりに目が行きがちですが、実際に運用が始まると、この非機能要件（動きの軽さや止まりにくさ）が現場のストレスに直結するため、漏れなく記載する必要があります。
セキュリティ基準と物理環境
コールセンターでは膨大な個人情報を扱うため、セキュリティ要件は極めて重要です。システム導入であれば、データの保管場所（サーバー）は国内限定とするのか、海外でも良いのか。また、通信の暗号化や、オペレーターごとのアクセス権限設定機能などが求められます。
業務委託（BPO）の場合は、委託先のセンター環境そのものが評価対象となります。「Pマーク」や「ISMS（情報セキュリティマネジメントシステム）」といった第三者認証の取得を必須条件とするのが一般的です。さらに物理的なセキュリティとして、「執務室への私物（スマホやメモ用紙）の持ち込み禁止」「入退室管理ゲートの設置」「監視カメラの有無」なども要件に含めます。
万が一の情報漏洩は企業の存続に関わる問題となるため、コストよりも優先して厳格な基準を設けるべき項目です。
RFPの作成｜ステップ3：評価と見積もり
見積もりフォーマットの統一
RFPの回答として提出される見積書ですが、各社が好き勝手な書式で提出してくると、比較検討が非常に困難になります。ある会社は「初期費用」が高く、ある会社は「月額費用（ランニングコスト）」が高い、また別の会社は「保守費用」が別枠になっているなど、内訳がバラバラでは総額の妥当性が判断できません。
これを防ぐために、発注側で「見積もり回答用のExcelフォーマット」を用意し、RFPと一緒に配布することをお勧めします。「初期導入費」「ライセンス費」「開発費」「保守運用費」などの項目をあらかじめ設定し、そこに数値を入力してもらう形式にします。こうすることで、各社の費用構造を横並びで比較（アップル・トゥ・アップル）できるようになり、「なぜA社はこの項目が高いのか」といった質問もしやすくなります。
評価基準（採点表）の作成
最後に、提案をどのような基準で選定するかを定めます。単に「合計金額が一番安いところ」を選ぶのであればRFPなど不要です。システムや委託先選びは、結婚相手選びにも似ています。価格だけでなく、「提案の具体性」「過去の実績」「プロジェクト体制」「担当者の熱意」などを総合的に判断する必要があります。
事前に社内で「価格40点、機能30点、実績30点」といった配点基準（評価シート）を作成しておきましょう。最安値の提案には、必ず「安い理由」があります。
必要な人員を削っているのか、品質管理の工数を省いているのか、あるいは独自の技術で効率化しているのか。安さだけに飛びつかず、「なぜ安いのか」「なぜ高いのか」をRFPの回答から読み解き、自社の課題を本当に解決してくれるパートナーを見極める力が、発注者としての責任です。
まとめ
RFP（提案依頼書）の作成は、確かに手間のかかる作業です。しかし、この工程を惜しんで丸投げしてしまうと、後から「思っていたものと違う」という手戻りが発生し、結果的に何倍ものコストと時間を失うことになります。
「現状（As-Is）とゴール（To-Be）を明確にする」「機能だけでなく非機能要件やセキュリティ基準を定める」「見積もりフォーマットを統一して横並びで比較する」。これらのステップを踏むことは、プロジェクト全体の成功率を劇的に高めるための投資です。
良い提案を引き出すのは、ベンダーの能力だけではありません。発注者の「RFPの質」こそが、最高のパートナーと出会うための鍵となります。まずは、自社の現在の数値（応答率や処理件数など）を洗い出すことから始めてみてください。
