RFPの書き方・記載項目・提案評価を理解すると、単に『提案依頼書』という名称を覚えるだけでなく、なぜ発注側が条件を文書化し、複数の提案を同じ軸で比べるのかが分かります。RFPは、外部の会社に解決方法を考えてもらうための出発点です。よいRFPは、発注側の希望を一方的に並べる文書ではなく、提案者が前提を理解し、比較可能な提案を返せるようにする文書です。
RFPを書く前に整理する目的と仕組み
RFP（提案依頼書）は、システム導入や業務委託で、発注側が実現したいことと条件を示し、ベンダーに提案を求める文書です。まず重要なのは、製品名や画面の細部を先に決めることではなく、現状の困りごと、達成したい状態、対象となる業務を分けて整理することです。例えば、入力作業に時間がかかるという現状、転記を減らして確認しやすくしたいという目的、対象は受注処理であるという範囲を区別します。こうすると、提案者は単なる機能の有無ではなく、目的に合う実現方法を説明できます。
RFPは調達の途中に置かれます。検討初期に市場や選択肢を広く知りたい段階ではRFIで情報を集めます。候補や課題の方向が見えて、解決方法・費用・進め方を比べたい段階でRFPを出します。価格を中心に条件が定まったものの見積を求めるならRFQが適します。基礎用語とこの順序はRFP・RFI・RFQの違いを解説した記事で確認すると、RFPの書き方を学ぶ前提がそろうため理解しやすくなります。
RFPの主な記載項目と、曖昧にしない書き方
RFPの記載項目は組織や案件によって異なりますが、提案を比較するためには、少なくとも背景・目的、対象範囲、要件、制約条件、進行条件、提出方法、評価方法をつなげて書きます。各項目は『何を望むか』だけでなく、『なぜ必要か』『どこまでが対象か』が読める状態を目指します。
| 記載項目 | 書く内容 | 提案比較で役立つ理由 |
|---|---|---|
| 背景・目的 | 現状の課題と、導入後に目指す状態 | 機能の数ではなく、解決したい課題に沿って提案を読めるため |
| 対象範囲 | 対象業務、利用部門、対象外の領域 | 提案ごとの前提や費用の差を見つけやすくするため |
| 要件 | 必要な機能、性能、セキュリティ、データ連携など | 必須条件と工夫の提案を区別できるため |
| 制約・予定 | 予算の考え方、希望時期、利用できる既存環境 | 実現性と進め方を比較できるため |
| 提出・評価方法 | 提案書の構成、質問期限、評価項目と選定手順 | 各社の回答形式をそろえ、公平に確認できるため |
要件には優先度を付けると有効です。満たさなければ選定できない必須要件、できれば満たしたい要望要件、提案者の工夫を聞きたい検討事項を混ぜずに書きます。全項目を必須にすると、柔軟な解決策を比べにくくなります。逆に『使いやすいこと』のような言葉だけでは判断できません。利用者、利用場面、確認したい操作を添えると、提案の根拠を読み取れます。要件をどのようにまとめるかは、要件定義の記事を読むと、RFPに書く条件と導入後に具体化する内容の境界を整理できるため役立ちます。
提案評価は価格だけで決めない
提案評価とは、提出された提案書を、あらかじめ示した基準に照らして比較することです。価格が低くても、必須要件を満たさない、移行方法が不明確、導入後の運用を支えられない場合は、目的に対する適合度を慎重に確認する必要があります。一方で、高価な提案が自動的に優れているわけでもありません。背景・目的、要件、制約に対して、根拠のある方法と実行可能な計画を示しているかを見ます。
評価項目の例には、要件への適合、実現方法の妥当性、体制と予定、費用の内訳、導入後の支援、質問への回答の明確さがあります。評価基準をRFPに書いておくと、提案者は何を説明すべきか把握でき、発注側も受け取ってから基準を変えにくくなります。比較表では、各社の○×だけで結論を急がず、前提条件や除外事項も併記します。『対応可能』という一語でも、標準機能なのか追加作業なのか、いつ実現するのかで意味が変わるからです。
ITパスポート試験での見分け方
試験問題では、文書の名前ではなく、誰が、いつ、何を求めているかを読み取ります。市場やベンダーの情報を幅広く集めるならRFI、要件を示して解決方法を含む提案を求めるならRFP、仕様や数量が定まり価格・見積を中心に求めるならRFQです。RFPを受け取った後に、基準に沿って提案書を比べる場面なら提案評価を指します。『提案』『評価基準』『比較』という語だけで決めず、依頼の段階と求める回答の中身を確認しましょう。
確認問題：発注側が、業務上の課題、必須機能、希望時期、提案の評価項目を示し、複数社に解決方法と費用を説明する提案書を求めた。最も適切な文書はどれか。
ア．RFI イ．RFP ウ．RFQ エ．SLA
答え：イのRFPです。課題と要件を示したうえで、解決方法を含む提案を求めているからです。RFIは情報収集、RFQは価格中心の見積依頼、SLAはサービス水準に関する合意であり、提案を比較するための依頼文書ではありません。
仕事と日常生活で考えるRFP
仕事では、部門が受注管理の仕組みを見直したい場合、現行作業の問題、利用者、必要な連携、移行したい時期を整理してRFPにします。受け取った提案では、入力の手間をどのように減らすか、既存データをどう移すか、障害時に誰が支援するかを、同じ評価項目で確認します。これは特定の会社の事例ではなく、外部委託を比較するときの一般的な考え方です。
日常生活でも、複数のサービスを比べる前に、目的と条件を言語化する場面があります。例えば、家族で利用する通信サービスを検討するとき、予算だけでなく、必要な回線数、利用場所、困ったときのサポート、契約期間を先に並べると、料金だけの比較を避けられます。これは正式なRFPではありませんが、条件をそろえて提案や選択肢を比較するという仕組みを理解する助けになります。
次に読む記事
- RFPとは？RFI・RFQとの違い：書き方と評価を学ぶ前に、三つの依頼文書の役割と順序を確認するため。
- 要件定義とは？：RFPに示す条件と、導入後に詳細化する要件の関係を理解するため。
- 仕事で使う知識の記事まとめ：調達や要件整理を、他の業務で使うIT知識と結び付けて復習するため。
RFPでは、目的、条件、評価基準を一続きに考えることが大切です。試験では依頼文書の役割を見分け、仕事では比較の前提をそろえる文書として捉えると、暗記だけではない理解につながります。ITパスポートの出題範囲はIPAのITパスポート試験案内で確認し、用語を学習計画の中に位置付けましょう。
