システム開発を外部へ依頼するとき、

「開発会社へ何を伝えればよいのか分からない」

「複数社から見積を取ったが、提案内容がバラバラで比較できない」

「RFPにはどこまで要件を書けばよいのか」

と悩むことがあります。

このような場合に利用されるのが、RFPです。

RFPは「Request for Proposal」の略で、日本語では提案依頼書と呼ばれます。

IPAでは、RFPをシステム開発を依頼するベンダー企業に提案を依頼するための文書と説明しており、システム導入の背景・目的・求める内容・提案や契約の手続きなどを記載するとしています。

例えば、

顧客管理システムを
作ってください

という依頼だけを複数の開発会社へ送った場合、

A社は、

顧客登録
検索
案件管理

を前提に見積もり、

B社は、

顧客管理
案件管理
メール配信
分析
スマホ対応

まで含めて提案するかもしれません。

その結果、

A社：
150万円

B社：
400万円

となっても、単純には比較できません。

RFPで、

開発背景

目的

対象業務

必要な要件

予算

希望時期

提案してほしい内容

評価方法

を揃えて伝えることで、各社の提案条件を合わせやすくなります。

この記事では、システム開発におけるRFPの書き方、必要な構成、コピペして使えるテンプレート、要件定義書との違い、失敗を防ぐポイントまで解説します。

RFPとは

RFPとは、

システム開発を検討している企業が、開発会社へ提案を依頼するための文書

です。

IPAでは、提案依頼書について、

導入するシステムの概要

提案してほしい内容

調達条件

などを明示し、ベンダーへ提案書の提出を依頼する文書と整理しています。

一般的な流れは、

発注企業
↓
RFP作成
↓
複数の開発会社へ送付
↓
各社が提案書・見積書を作成
↓
比較・評価
↓
開発会社を選定
↓
契約

です。

RFPを作成する目的

RFPを作る目的は、単に、

見積金額を出してもらう

ことではありません。

主な目的は次の3つです。

1．自社の要望を開発会社へ正確に伝える

口頭や短いメールだけでは、

何のためのシステムなのか

誰が使うのか

どこまで開発するのか

が伝わりにくくなります。

RFPとして整理することで、各社へ同じ情報を提供できます。

2．提案内容を比較しやすくする

複数の会社へ、

同じ条件

を伝えることで、

価格

システム構成

開発方法

スケジュール

体制

保守

提案内容

を比較しやすくなります。

IPAでも、複数の候補ベンダーにRFPを提示し、一定の評価基準で提案を評価して、条件に合う製品やベンダーを選定する流れが示されています。

3．開発会社からより良い提案を受ける

RFPでは、

この仕様で必ず作ってください

と細かく固定するだけではなく、

この課題を解決するために
どのような方法がよいか提案してください

という余地を残すことも重要です。

IPAも、複数のベンダーから提案を受けることで、RFP作成時には考えつかなかった方法が見つかる場合があると説明しています。

RFPと要件定義書の違い

RFPと要件定義書は混同されやすい文書です。

簡単に分けると、

RFP
=
開発会社へ
提案してくださいと依頼する文書

要件定義書
=
実際に作るシステムの要件を
整理・合意する文書

です。

例えばRFPの段階では、

現在Excelで管理している顧客情報を
Webシステムへ移行したい。

顧客、案件、対応履歴を
一元管理したい。

程度でも構いません。

開発会社から、

この構成がおすすめです

この機能も必要ではないでしょうか

この部分は既存SaaSを利用できます

と提案してもらいます。

その後、選定した開発会社と、

詳細な機能

画面

権限

データ

非機能要件

運用

を詰めて要件定義書へ落とします。

実際にIPAの資料でも、RFP作成・ベンダー選定と要件定義は別の成果物・プロセスとして扱われています。

RFPに書くべき項目一覧

RFPの構成に絶対的な決まりはありませんが、一般的なシステム開発では次のような項目を整理します。

1．プロジェクト概要

2．システム化の背景

3．目的・ゴール

4．現在の業務・システム

5．解決したい課題

6．システム化対象範囲

7．システム要件

8．非機能要件

9．データ移行

10．運用・保守

11．プロジェクト体制

12．予算

13．スケジュール

14．提案依頼事項

15．提案書の提出方法

16．評価・選定方法

17．契約条件

18．その他制約

IPAが紹介するRFPの目次例でも、システム化の背景・目的・課題・効果・現行システムとの関係・予算に加え、提案依頼事項、提案手続き、開発条件、保証要件、契約条件などが含まれています。

ここから、それぞれの書き方を見ていきます。

1．プロジェクト概要

最初に、今回何を依頼するのか簡潔に記載します。

テンプレート

プロジェクト名：

対象システム：

対象業務：

利用部署：

想定利用者数：

依頼内容：

希望する契約形態：

記入例

プロジェクト名：
顧客・案件管理システム構築

対象業務：
営業部門の顧客・案件管理

利用部署：
営業部、営業管理部

想定利用者数：
約30名

依頼内容：
要件定義、設計、開発、テスト、
リリース、保守

概要：
現在Excelで管理している顧客・案件情報を
Webシステムへ一元化する。

ここでは1ページ程度で全体像が分かれば十分です。

2．システム化の背景

次に、

なぜ今回の開発を行うのか

を記載します。

記入例

現在、営業担当者ごとに
Excelファイルで顧客情報を管理している。

担当者によって管理方法が異なり、
顧客情報・案件状況を営業部全体で
把握することが難しくなっている。

また、担当者が休職・退職した際に、
過去の顧客対応履歴を確認できないケースがある。

この課題を解消するため、
顧客・案件管理システムの導入を検討している。

「システムを作りたい」だけでは不足

例えば、

在庫管理システムを導入したい

だけでは、開発会社は何を重視すればよいのか判断できません。

背景として、

現在3拠点がExcelで管理

本社が毎週統合

毎週3時間かかる

最新在庫を即時確認できない

などを書きます。

これにより開発会社側も、

リアルタイム性が重要

複数拠点対応が重要

Excel移行が必要

と判断しやすくなります。

3．目的・ゴール

RFPでは、

何を作るか

だけではなく、

導入によって
何を実現したいか

を明確にします。

例

目的：

顧客・案件情報を一元管理し、
営業活動の属人化を解消する。


目標：

・すべての営業担当者が同じ顧客情報を参照できる

・担当者変更後も過去の対応履歴を確認できる

・毎週2時間かかっている営業案件集計を
  30分以内に削減する

可能であれば数値化します。

KPIが決まっていれば記載する

例えば、

月末集計時間：
5時間 → 1時間

問い合わせ件数：
月100件 → 月30件

入力作業：
1件10分 → 3分

などです。

これにより、開発会社も目的に合わせた提案がしやすくなります。

4．現在の業務・システム

現在どのように業務を行っているのかを書きます。

例えば、

顧客から問い合わせ

↓

営業担当者がExcelへ登録

↓

案件発生時に別Excelへ記録

↓

週末に各担当者が
管理者へファイル送付

↓

管理者が統合

↓

営業会議資料を作成

などです。

現行システムも書く

例えば、

顧客管理：
Excel

会計：
freee

メール：
Gmail

チャット：
Slack

ファイル：
Google Drive

などです。

RFPには業務フローや要件一覧、課題一覧、現行システム構成図などを補足資料として添付すると、ベンダー側が状況を理解しやすくなるとIPAも説明しています。

5．解決したい課題

現在の課題を一覧化します。

例えば、

ID	課題	優先度
P01	顧客情報が担当者ごとに分散	高
P02	案件状況を管理者が確認できない	高
P03	対応履歴が残らない	高
P04	毎週Excelを統合している	中
P05	スマホから確認できない	低

こうしておくと、

今回のシステムで
最も解決したいこと

が分かります。

6．システム化対象範囲

RFPでは、

何を依頼するか

だけではなく、

何を依頼しないか

も明記します。

例

今回対象：

・顧客管理
・案件管理
・対応履歴
・ユーザー管理
・CSV出力


今回対象外：

・会計機能
・請求書作成
・メールマーケティング
・AIによる営業予測

対象外を書いておくことで、

当然含まれていると思っていた

という認識違いを防げます。

7．システム要件

RFPの段階で必要な機能がある程度分かっている場合は、一覧にします。

例えば、

ID	要件	優先度
F01	ユーザーがログインできる	Must
F02	顧客を登録・編集できる	Must
F03	顧客を検索できる	Must
F04	案件を登録できる	Must
F05	顧客ごとの対応履歴を記録できる	Must
F06	案件一覧をCSV出力できる	Should
F07	スマートフォン対応	Should

RFPでは、すべての仕様を詳細に確定している必要はありません。

例えば、

顧客検索が必要

まで書き、

部分一致

前方一致

検索API設計

などは要件定義・設計時に決めることもできます。

8．非機能要件

機能以外の条件も記載します。

例えば、

利用人数：
30人

最大同時利用：
20人

利用時間：
平日8:00〜20:00

対応端末：
PC、スマートフォン

ブラウザ：
Chrome、Edge

バックアップ：
1日1回以上を希望

セキュリティ：
個人情報を扱うため
ユーザー権限管理が必要

などです。

まだ詳細が決まっていない場合は、

最適なバックアップ構成を
提案してください

としても構いません。

RFPですべてを決定しなくてもよい

例えば、

AWSのこのサービスを必ず使う

と細かく指定するより、

月間利用者30人程度を想定。
運用負荷・費用を抑えられる
クラウド構成を提案してほしい

とする方が、開発会社の提案力を比較できる場合があります。

9．データ移行

既存システム・Excelから移行する場合は重要です。

例

移行対象：

顧客：
約20,000件

案件：
約50,000件

移行元：
Excel

ファイル数：
約30ファイル

移行対象期間：
過去5年分


要望：

既存Excelの形式にばらつきがあるため、
データクレンジング方法を含めて提案してほしい。

データ移行をRFPへ書かないと、後から追加費用になりやすいため注意します。

10．運用・保守

開発後の対応も提案してもらう場合は記載します。

例

希望する保守内容：

・障害対応
・問い合わせ対応
・セキュリティアップデート
・バックアップ確認
・軽微な修正

希望対応時間：

平日9:00〜18:00


提案依頼：

月額保守費用

保守範囲

対応可能時間

緊急障害時の対応方法

開発費だけではなく、運用・保守費まで比較できるようにします。

11．プロジェクト体制

発注者側の体制も書いておくとよいでしょう。

例えば、

プロジェクト責任者：
営業部長

業務担当：
営業担当者2名

システム担当：
情報システム担当1名

最終決裁：
代表取締役

などです。

さらに開発会社へ、

PM

SE

開発者

デザイナー

などの提案体制を示してもらいます。

12．予算

可能であれば予算を記載します。

例えば、

初期開発予算：

300〜500万円程度


月額運用費：

10万円以内を希望

です。

予算を書かない方がよい？

予算を伝えると、

上限いっぱいで見積もられるのでは？

と心配することもあります。

しかし、予算をまったく伝えないと、

100万円想定の発注者

vs

1,000万円想定の開発会社

のようなミスマッチが発生します。

詳細金額を出したくない場合は、

300〜500万円

500万円以内

数百万円規模

など幅を持たせる方法があります。

IPAが紹介するRFP目次例にも予算は含まれています。

13．スケジュール

例えば、

RFP配布：
8月1日

質問受付：
8月1日〜8月10日

提案書提出：
8月25日

ベンダー選定：
9月5日

契約：
9月中旬

要件定義開始：
10月

希望リリース：
翌年3月

などです。

特に、

絶対に変更できないリリース日

がある場合は理由も伝えます。

例えば、

4月1日の新制度開始に合わせる必要がある

などです。

14．提案依頼事項

RFPで特に重要な部分です。

開発会社へ、

提案書に
何を書いてほしいか

を指定します。

例えば、

以下について提案してください。

1．システム全体構成

2．採用技術・選定理由

3．開発方法

4．プロジェクト体制

5．開発スケジュール

6．開発費

7．月額運用費

8．保守内容

9．セキュリティ対策

10．データ移行方法

11．想定リスク

12．類似システムの開発実績

13．当社要件に対する改善提案

この項目を揃えることで、各社の比較がしやすくなります。

見積は内訳も依頼する

例えば、

合計500万円

だけでは比較しにくいため、

要件定義：
50万円

設計：
70万円

開発：
250万円

テスト：
80万円

リリース：
20万円

PM：
30万円

など、可能な範囲で内訳を依頼します。

15．提案書の提出方法

例えば、

提出期限：

2026年8月25日 17:00


提出形式：

PDF


送付方法：

指定メールアドレス


ページ数：

原則30ページ以内


プレゼン：

60分
提案45分
質疑15分

などです。

提出条件を各社で統一します。

16．質問の受付方法

開発会社からRFPについて質問が来る場合があります。

例えば、

質問受付期間：
8月1日〜8月10日

質問方法：
Excelの質問票

回答：
8月15日までに全社共有

などです。

複数社へ依頼する場合は、

A社だけに追加情報を伝えた

という状況を避けるため、質問への回答を同じ条件で共有することも検討します。

17．評価・選定方法

RFPを送る前に、

どう選ぶか

を決めておきます。

例えば、

評価項目	配点
要件理解	20
提案内容	20
技術力	15
開発体制	10
スケジュール	10
費用	15
保守・運用	5
実績	5
合計	100

などです。

価格だけで決めると、

最安値ではあるが
必要な要件が入っていなかった

という可能性があります。

IPAも、RFPに対する複数の提案を一定の評価基準で評価し、条件に合うベンダーを選定する流れを示しています。

18．契約条件

現時点で決まっている条件があれば記載します。

例えば、

成果物の著作権

ソースコードの所有

秘密保持

再委託条件

検収方法

支払条件

契約形態

などです。

契約条件は案件によって法的な検討が必要になるため、重要案件では専門家への確認も検討します。

【コピペ用】RFPテンプレート

中小企業の業務システム開発で使いやすい簡易テンプレートです。

# システム開発 提案依頼書（RFP）

## 1. プロジェクト概要

プロジェクト名：

対象業務：

利用部署：

想定利用者：

依頼範囲：

## 2. システム化の背景

現在の業務：

現在の問題：

今回開発を検討した理由：

## 3. 目的・ゴール

システム導入目的：

実現したい状態：

KPI・目標：

## 4. 現在の業務・システム

現在の業務フロー：

利用中のシステム：

利用中のExcel・帳票：

## 5. 解決したい課題

P01：

P02：

P03：

## 6. システム化対象範囲

今回の対象：

今回の対象外：

将来対応：

## 7. システム要件

F01：

F02：

F03：

## 8. 非機能要件

利用時間：

想定利用人数：

想定データ量：

対応端末：

セキュリティ：

バックアップ：

## 9. データ移行

移行元：

移行対象：

件数：

## 10. 運用・保守

希望する保守内容：

希望対応時間：

## 11. 発注者側の体制

責任者：

業務担当：

システム担当：

## 12. 予算

初期開発予算：

月額予算：

## 13. スケジュール

RFP配布：

質問期限：

提案書提出：

ベンダー決定：

開発開始：

希望リリース：

## 14. 提案依頼事項

以下を提案してください。

・システム構成
・採用技術
・開発体制
・スケジュール
・開発費
・運用費
・保守内容
・データ移行
・セキュリティ対策
・類似実績
・想定リスク
・改善提案

## 15. 提案書提出方法

提出期限：

提出形式：

提出先：

プレゼン有無：

## 16. 評価方法

評価項目：

配点：

## 17. 契約条件

契約形態：

成果物：

支払条件：

その他：

## 18. 補足資料

・業務フロー
・現行システム構成
・機能一覧
・既存Excel
・既存帳票

小規模システムならRFPはもっと簡単でもよい

例えば予算100〜300万円程度の小規模な業務システムで、

50ページのRFP

を作る必要はありません。

最低限、

1．背景

2．目的

3．現在の業務

4．困っていること

5．作りたい範囲

6．必要な機能

7．利用者

8．既存データ

9．予算

10．希望時期

11．提案してほしい内容

が分かれば、提案できる場合があります。

重要なのは資料のページ数ではなく、

各社が
同じ条件で提案できること

です。

RFPを作る前に整理しておきたい資料

可能であれば、

現在使っているExcel

業務フロー

既存帳票

マニュアル

現行システム画面

課題一覧

機能要望一覧

などを準備します。

開発会社は文章だけで説明されるより、実物を見た方が業務を理解しやすくなります。

RFPで「要件を決めすぎる」のも問題

RFPを詳細に作ろうとするあまり、

画面構成

DB構成

クラウドサービス

ライブラリ

API設計

まで発注者側で固定するケースがあります。

明確な理由があれば問題ありません。

しかし、技術選定まで固定すると、

開発会社から
より良い方法を提案してもらう余地

が小さくなります。

例えば、

AWS Lambdaを必ず使用すること

ではなく、

月額インフラ費を抑えながら、
利用者100名程度に対応できる
クラウド構成を提案すること

と要求レベルで記載する方法があります。

RFPでよくある失敗

失敗1｜「○○システムを作りたい」だけ

背景・目的が分からないと、開発会社は適切な提案をしにくくなります。

失敗2｜欲しい機能しか書いていない

例えば、

ログイン

顧客登録

検索

CSV

だけでは、

なぜ必要なのか

が分かりません。

課題・目的も記載します。

失敗3｜対象外を書いていない

開発範囲の認識違いにつながります。

今回作らないもの

も明記します。

失敗4｜予算をまったく伝えない

提案規模が大きくばらつく原因になります。

正確な金額を出せなくても予算レンジを示します。

失敗5｜納期だけ書いて理由を書かない

例えば、

12月末必須

なのか、

できれば12月

なのかで提案は変わります。

背景まで共有します。

失敗6｜提案してほしい内容を指定しない

A社はシステム構成を詳細に説明し、B社は金額だけという状態になると比較できません。

提案項目を揃えます。

失敗7｜価格だけで選定する

価格に加えて、

要件理解

提案内容

体制

技術力

スケジュール

保守

も評価します。

失敗8｜現場担当者がRFP作成に参加していない

経営者・管理職だけでRFPを作ると、実際の業務が抜けることがあります。

システムを利用する現場担当者にも確認します。

失敗9｜RFPを完成させること自体が目的になる

RFPは、

立派な資料を作る

ことが目的ではありません。

目的は、

適切な開発会社から
適切な提案を受ける

ことです。

RFP作成のおすすめ手順

実際には次の流れで作成すると整理しやすくなります。

STEP1
システム化の背景を整理

↓

STEP2
目的・課題を整理

↓

STEP3
現在の業務を整理

↓

STEP4
対象範囲を決める

↓

STEP5
必要な要件を整理

↓

STEP6
予算・納期を決める

↓

STEP7
開発会社へ提案してほしい内容を決める

↓

STEP8
評価基準を作る

↓

STEP9
社内レビュー

↓

STEP10
RFP配布

RFP作成時にヒアリングしておきたい質問

背景・目的

なぜシステム化するのか？

何に困っているのか？

何が改善されれば成功か？

業務

現在どのように仕事をしているか？

誰が利用するか？

Excel・紙・既存システムはあるか？

開発範囲

今回必ず作るものは？

将来追加でもよいものは？

今回作らないものは？

制約

予算は？

希望時期は？

既存クラウドの指定は？

社内セキュリティルールは？

これらを整理した上でRFPへ落とします。

RFPに関するよくある質問

RFPは必ず作る必要がありますか？

必須ではありません。

小規模な開発で、信頼できる一社と要件整理から進める場合は、正式なRFPを作らないこともあります。

一方、

複数の開発会社を比較したい

予算が大きい

社内の合意形成が必要

開発対象が複雑

な場合は、RFPを作るメリットが大きくなります。

RFPは誰が作るのですか？

基本的には発注企業側が作成します。

IPAでも、システムを導入する企業がRFPを作成してベンダーへ提示する流れが示されています。

ただし、社内にシステム開発の知識がない場合は、ITコンサルタントや外部エンジニアへRFP作成支援を依頼する方法もあります。

RFPとRFIの違いは？

RFIは「Request for Information」で、情報提供依頼です。

IPAでは、RFIについてRFP作成に先立ち、実現手段や技術動向などの情報をベンダーから集めるための依頼と整理しています。

つまり、

RFI
=
まず情報をください

RFP
=
この条件で提案してください

という違いです。

RFPと見積依頼の違いは？

見積依頼では主に、

いくらかかるか

を確認します。

RFPでは、

どう作るか

どのような体制か

どの技術を使うか

いつ作るか

いくらかかるか

まで含めて提案してもらいます。

要件が固まっていなくてもRFPは作れますか？

作れます。

むしろ、

課題・目的は明確だが
最適な実現方法は分からない

場合に、開発会社から提案を受ける意味があります。

ただし、

何に困っているのか

誰が使うのか

予算はいくらか

いつまでに必要か

程度は整理しておいた方がよいでしょう。

hiro-dev-labのRFP・要件定義・システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく発注前の要件整理から対応できます。

例えば、

• 現状業務のヒアリング
• 業務フロー整理
• 課題整理
• システム化対象範囲の整理
• RFP作成に必要な要件整理
• 業務要件・機能要件の整理
• 非機能要件整理
• 機能一覧作成
• データ・権限設計
• 外部システム連携の検討
• 開発後の運用・保守設計
• Java・Python・TypeScriptによるWebシステム開発

などを検討できます。

例えば、

Excelで業務管理している

↓

システム化したい

↓

何を開発会社へ伝えればよいか分からない

という状態であれば、

現状業務をヒアリング

↓

課題を整理

↓

システム化する範囲を決める

↓

必要な要件を整理

↓

RFP・要件資料へ反映

↓

開発

という順番で進めることができます。

良いRFPとは「仕様を細かく書いた資料」ではなく「良い提案を引き出せる資料」

RFPを作成するとき、

詳細を書けば書くほど
良いRFPになる

とは限りません。

重要なのは、

なぜシステムが必要なのか

何を解決したいのか

何を必須とするのか

どこまで提案してほしいのか

予算・納期はどの程度か

が開発会社へ伝わることです。

RFPでは、

1．背景を伝える

2．目的・ゴールを伝える

3．現在の業務・課題を伝える

4．対象範囲を明確にする

5．必要な要件を整理する

6．予算・納期を共有する

7．提案してほしい内容を揃える

8．評価基準を決める

という流れを意識すると、複数社の提案を比較しやすくなります。

「システムを開発したいが、何を開発会社へ伝えればよいか分からない」

「複数社から提案・見積を取りたい」

「現在の業務を整理してRFPへ落とし込みたい」

「要件整理からシステム開発まで相談したい」

といった段階からでも、発注前の整理を進めることができます。

RFP・要件定義・業務システム開発について相談する