RFPとは？システム開発の提案依頼書の書き方と必ず入れる項目を解説

「システム開発を外部に依頼したいが、RFP（提案依頼書）に何を書けばよいか分からない」

情報システム部門やDX推進担当の方から、このようなご相談を数多くいただきます。

RFPの完成度は、その後にベンダーから届く提案内容の質や見積の精度、さらにはプロジェクト全体の成否を左右します。

本記事では、Webシステム開発・運用の契約企業600社以上と取引する中で、数多くのRFPを受け取ってきたCLINKSが、RFPの基本的な意味から、RFI・RFQとの違い、必ず盛り込むべき項目、作成の具体的な手順までを解説します。

読み終える頃には、貴社のプロジェクトに合わせたRFPを、迷わず作成できる状態になっているはずです。なお、当社ではRFPの整理や作成そのもののご相談も受け付けております。

RFP（Request for Proposal）とは、発注企業がシステム開発の目的や要件を提示し、ベンダーに具体的な提案を依頼する文書です。日本語では「提案依頼書」と呼ばれます。

見積金額だけでなく、課題の背景や実現したいゴールまで含めて伝える点が、RFPの大きな特徴です。

RFPを作成する主な目的は、複数のベンダーから同じ条件で提案を受け取り、比較検討できる状態をつくることです。

RFPがないまま「システムを作ってほしい」とだけ伝えると、ベンダーごとに前提が異なる提案が返ってきます。その結果、見積金額の差が機能や品質の差によるものなのか、前提条件の解釈の違いによるものなのか判断しづらくなるケースも少なくありません。

その点、RFPがあれば、同じ条件のもとで提案の内容を比べやすくなります。

RFPと混同されやすい言葉に、RFIとRFQがあります。まずは違いを表で整理します。

RFIは、RFPを作成する前段階で、市場にどのようなベンダーや技術があるかを把握するために使います。自社に知見が少ない技術領域を扱う場合は、RFIで情報を集めてからRFPを作成すると、要件の精度が上がります。

RFQは、仕様や提案内容がある程度固まった段階で、価格の見積のみを依頼する文書です。RFPの回答をもとに1〜数社に絞り込んだ後、詳細な見積調整の場面で使われることが多くなります。

RFPは、主に以下のような場面で必要になります。

• 老朽化した基幹システムを刷新したいとき
• 業務システムを新規に開発したいとき
• 複数のベンダーを比較して発注先を決めたいとき
• 社内稟議で「なぜこの内容・金額なのか」を説明する必要があるとき

一方で、既存ベンダーへの追加開発や小規模な改修では、簡易的な依頼書で対応するケースもあります。プロジェクトの規模や関係者の数に応じて、RFPを作成するかどうかを判断してください。

RFPに記載する項目は、大きく8つのカテゴリーに分けられます。

それぞれの項目を詳しく見ていきましょう。

• プロジェクト名
• 発注企業の概要（業種、規模、部門）
• 窓口担当者名・連絡先
• RFPの位置づけ（本提案依頼の目的）

• なぜこのシステムが必要になったのか（現状の課題）
• システム化によって解決したいこと
• 実現したいゴール（KGI・KPIがあれば明記）

背景や目的が具体的であるほど、ベンダーは的確な提案をしやすくなります。「業務効率化のため」といった抽象的な表現だけでなく、「月〇時間かかっている入力作業を〇割削減したい」のように、可能な範囲で定量的に書くことをおすすめします。

• 必須機能（Must）とあると望ましい機能（Want）を分けて記載
• 業務フローや画面イメージ（あれば添付）
• 既存システムとの連携要件、データ移行の要否

機能を思いつくままに羅列すると優先順位が伝わらず、見積の幅が広がりやすくなります。必須機能とそれ以外を分けて整理してください。

機能要件・非機能要件の整理は、ベンダー選定後の要件定義工程でも中心となる作業です。要件定義の進め方や要件定義書に書く項目を把握しておくと、RFP段階でどこまで書くべきかも判断しやすくなります。

関連記事：要件定義の進め方｜失敗しないための工程とドキュメントの作り方

• 可用性（稼働率、障害時の復旧目標）
• 性能・拡張性（想定同時アクセス数、将来の拡張見込み）
• 運用・保守性（運用体制、保守対応時間）
• セキュリティ（アクセス制御、データの取り扱い）
• 移行性（既存データ・システムからの移行方法）

非機能要件は発注企業側で言語化しにくく、RFPから抜け落ちやすい項目です。

IPA（情報処理推進機構）が公開している「非機能要求グレード」では、要件定義の段階で明らかにしておくべき非機能要求を、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6分野に整理しています（出典：IPA「非機能要求グレード」）。

この6分野を項目の抜け漏れチェックに活用すると、記載漏れを防ぎやすくなります。

• 希望する稼働開始日、主要マイルストーン
• 予算の目安（レンジでの提示でも可）

RFPに予算を明記しない企業も少なくありませんが、予算感が共有されていないRFPでは、提案内容の幅が広がりすぎて比較が難しくなる傾向があります。厳密な金額でなくても、レンジで示すだけで提案の精度は大きく変わります。

予算のレンジを決めるには、開発費用がどのような項目で構成され、どこに見落としがちなコストがあるかを知っておく必要があります。アプリ開発を例にした費用の内訳と予算計画の立て方は、以下の記事で解説しています。

関連記事：アプリ開発に必要な費用の内訳とは？予算計画をわかりやすく解説！

• 提案書に記載してほしい項目（体制、進め方、実績など）
• 見積の内訳の粒度（工程別か、機能別かなど）
• デモやプレゼンの要否
• 提案書の提出期限・提出方法・提出先
• 質問の受付期限・受付方法・回答予定日

• 評価項目とその配点（価格、技術力、実績、体制など）
• 必須要件（実績年数、対応可能な契約形態など）

評価基準を事前に明文化しておくと、選定後に社内で「なぜこのベンダーを選んだのか」を説明しやすくなります。

• 契約形態（準委任契約／請負契約）
• 支払条件、検収条件
• 秘密保持契約（NDA）の締結有無
• 稼働後の保守・運用体制の要否

システム開発の契約形態は、業務内容によって準委任と請負を使い分ける必要があります。両者の違いを曖昧にしたままRFPを作成すると、後の契約交渉で認識のズレが生じやすくなるため注意してください。

契約形態の違いは、成果の予測が難しいAI開発を依頼する場合に特に重要で、請負と準委任のどちらを選ぶかで責任範囲が変わります。AI開発の契約が複雑になる理由と、契約形態ごとの特徴は、以下の記事で詳しく解説しています。

関連記事：AI開発の契約形態やスムーズに進めるための考え方を解説

RFPは、以下の6ステップで作成を進めると、抜け漏れの少ない文書に仕上がります。

RFP作成の最初のステップは、現状の課題とシステム化の目的を言語化することです。関係部門へのヒアリングを行い、「誰が」「何に困っていて」「どうなればよいか」を整理します。

課題と目的の言語化は、AI開発を外注する場合にも同じように出発点になります。外注と自社開発の役割分担をどう決めるか、要件定義から運用までをどのような流れで進めるかは、以下の記事で解説しています。

関連記事：AI開発を外注する際の判断軸と要件定義から運用までの進め方

自社に知見の少ない技術領域を扱う場合は、RFPを作成する前にRFIでベンダーの実績や技術動向を確認しておくと、要件の精度が上がります。

「RFPに必ず入れるべき項目」を参考に、各項目を記載します。最初から完璧を目指さず、まずは一通り埋めることを優先してください。

機能要件だけでドラフトを終えず、非機能要件の欄を必ず設けてください。IPAの「非機能要求グレード」などのフレームワークを参考にすると、抜け漏れの確認がしやすくなります。

情報システム部門だけでなく、実際にシステムを利用する事業部門や、予算を管理する部門にもレビューを依頼します。部門間で認識がずれている項目があれば、この段階で解消しておきます。

RFPを配布した後は、必ず質疑応答（Q&A）の期間を設けてください。ベンダーからの質問とその回答を依頼先全社に共有することで、提案内容の前提条件を揃えることができます。

RFP作成では、以下のような失敗が起こりやすくなります。

予算のレンジすら示さないRFPでは、ベンダー側も想定する規模感をつかめず、実現性の低い提案や、逆に過大な見積を提示してしまうことがあります。厳密な金額を出せない場合でも、レンジでの提示をおすすめします。

機能要件は具体的に書けても、非機能要件は後回しにされがちです。当社への開発相談でも、稼働後に「アクセスが集中すると重くなる」「想定より復旧に時間がかかった」といった相談を受けることがあり、その多くは非機能要件がRFP段階で明確になっていないことが原因です。

リプレイス案件では、現行システムの仕様や連携先の整理が不十分なまま発注してしまうと、着手後に想定外の作業が発覚し、追加費用や納期遅延につながりやすくなります。可能な範囲で現行システムの仕様書やデータ構造を整理し、RFPに添付することをおすすめします。

評価基準を決めずに提案を集めると、結果的に価格の安さだけで選んでしまいがちです。事前に評価項目と配点を決めておくことで、価格以外の観点（実績、体制、提案内容の妥当性など）も含めた選定が可能になります。

評価項目を決める際は、開発会社の選定基準として一般的に重視される観点を参考にすると、抜け漏れを防げます。アプリ開発会社を選ぶ際の5つのポイントと評価項目は、以下の記事で紹介しています。

関連記事：アプリ開発会社を選ぶ際の5つのポイントとは？プロジェクトを成功に導く方法を紹介

質疑応答の期間を設けないと、ベンダーごとに異なる前提で提案書が作成されてしまい、比較が難しくなります。RFP配布後には、必ず一定期間の質問受付期間を設けてください。

最後に、RFPに関するよくある質問を紹介します。

「開発したいシステムはあるものの、要件をどう整理すればよいか分からない」「RFPに何を書くべきか迷っている」とお悩みではありませんか。

CLINKSでは、RFPの作成前からシステム開発のご相談を承っています。契約企業600社以上のシステム開発実績をもとに、貴社の課題やご要望を伺い、状況に合った進め方をご提案します。

要件やRFPが固まっていない段階でも、まずはお気軽にご相談ください。

その他のお問い合わせはこちら

AIを活用した業務効率化やシステム開発をご検討の方は、AI受託開発サービスもご覧ください。サービス内容と開発実績をご紹介しています。

RFP（提案依頼書）は、システム開発を外部に依頼する際に、複数のベンダーから比較可能な提案を集めるための文書です。

RFPには、プロジェクトの基本情報から、背景・目的、機能要件、非機能要件、スケジュール・予算、選定基準、契約条件まで、8つのカテゴリーの項目を盛り込むことをおすすめします。特に非機能要件と予算は、抜け落ちやすい項目のため注意が必要です。

RFPの完成度は、その後の提案の質や見積の精度、そしてプロジェクトそのものの成否に直結します。本記事で紹介した項目とステップを参考に、貴社のプロジェクトに合わせたRFPを作成してみてください。