システム開発を外部へ依頼するとき、
「提案依頼書には何を書けばよいのか分からない」
「RFPのテンプレートをそのまま使いたい」
「複数の開発会社から同じ条件で提案を受けたい」
と悩むことがあります。
提案依頼書は、RFP(Request for Proposal)とも呼ばれ、開発会社へシステムの提案を依頼するための文書です。
IPAでも、提案依頼書は、導入するシステムの概要・提案依頼事項・調達条件などをベンダーへ提示し、提案書の提出を依頼するための文書と整理されています。
例えば、
顧客管理システムを作りたいので
見積をお願いします
とだけ依頼すると、開発会社によって想定する内容が大きく変わる可能性があります。
A社は、
顧客登録
顧客検索
CSV出力
を想定し、
B社は、
顧客管理
案件管理
営業履歴
ダッシュボード
スマートフォン対応
まで含めるかもしれません。
この状態では、
A社:150万円
B社:350万円
という見積が出ても、単純には比較できません。
そこで提案依頼書に、
なぜ作るのか
何を解決したいのか
誰が使うのか
どこまで作るのか
予算はいくらか
いつまでに必要か
何を提案してほしいのか
を整理します。
この記事では、中小企業のWebシステム・業務システム開発で使いやすい提案依頼書テンプレートを掲載し、各項目の書き方を具体例付きで解説します。
【コピペ用】システム開発の提案依頼書テンプレート
まず、すぐに使えるテンプレートを紹介します。
必要な箇所だけコピーして利用できます。
# システム開発 提案依頼書(RFP)
## 1. プロジェクト概要
プロジェクト名:
対象業務:
対象部署:
想定利用者数:
依頼内容:
## 2. システム化の背景
現在の業務:
現在発生している課題:
今回システム化を検討した理由:
## 3. 開発目的・ゴール
開発目的:
システム導入後に実現したい状態:
KPI・目標値:
## 4. 現在の業務・システム
現在の業務フロー:
現在利用しているシステム:
現在利用しているExcel・帳票:
## 5. 解決したい課題
課題1:
課題2:
課題3:
## 6. システム化対象範囲
今回の開発対象:
今回の対象外:
将来的に検討する機能:
## 7. 機能要件
F01:
機能名:
概要:
優先度:
F02:
機能名:
概要:
優先度:
## 8. 非機能要件
想定利用者数:
最大同時利用者数:
利用時間:
性能:
対応端末:
対応ブラウザ:
セキュリティ:
バックアップ:
ログ:
## 9. データ移行
移行元:
移行対象:
データ件数:
移行対象期間:
## 10. 外部システム連携
連携先:
連携内容:
連携方式:
## 11. 運用・保守
希望する保守内容:
希望対応時間:
障害対応:
問い合わせ対応:
## 12. 発注者側の体制
プロジェクト責任者:
業務担当:
システム担当:
決裁者:
## 13. 予算
初期開発予算:
月額運用予算:
## 14. スケジュール
RFP配布:
質問期限:
提案書提出期限:
ベンダー決定:
開発開始:
希望リリース:
## 15. 提案依頼事項
以下について提案してください。
・システム構成
・採用技術
・開発方法
・プロジェクト体制
・開発スケジュール
・開発費用
・運用費用
・保守内容
・データ移行方法
・セキュリティ対策
・類似開発実績
・想定リスク
・追加提案
## 16. 提案書の提出方法
提出期限:
提出形式:
提出先:
提案説明会の有無:
## 17. 評価方法
評価項目:
評価方法:
## 18. 契約条件・その他
契約形態:
成果物:
支払条件:
再委託:
秘密保持:
その他:
このテンプレートをすべて埋める必要はありません。
小規模システムであれば、
背景
目的
対象範囲
必要機能
利用者
データ移行
予算
納期
提案してほしい内容
程度に絞っても構いません。
重要なのは、資料のページ数ではなく、開発会社が同じ前提条件で提案できる状態を作ることです。
1.プロジェクト概要
最初に、今回何を依頼したいのかを簡潔に記載します。
テンプレート
プロジェクト名:
対象業務:
対象部署:
利用者:
利用人数:
依頼範囲:
記入例
プロジェクト名:
顧客・案件管理システム構築
対象業務:
営業部門の顧客・案件管理
対象部署:
営業部、営業管理部
利用者:
営業担当者、営業管理者
利用人数:
約30名
依頼範囲:
要件定義、設計、開発、テスト、
リリース、運用保守
この項目を読むだけで、
何のシステムなのか
誰が使うのか
どこまで依頼するのか
が分かる状態にします。
2.システム化の背景
次に、
なぜ今回システム開発を行うのか
を説明します。
記入例
現在、営業担当者ごとにExcelで
顧客情報・案件情報を管理している。
Excelの形式が担当者によって異なり、
営業部全体で案件状況を把握することが
難しくなっている。
また、担当者変更・退職時に
過去の対応履歴を確認できないケースがある。
これらを解消するため、
顧客・案件管理システムの導入を検討している。
ここで重要なのは、
顧客管理システムを作りたい
だけで終わらせないことです。
開発会社は背景が分かることで、
案件共有が重要
対応履歴が重要
属人化解消が重要
と優先順位を理解しやすくなります。
3.開発目的・ゴール
背景の次に、
システム導入後に
どうなりたいのか
を書きます。
記入例
開発目的:
顧客・案件情報を営業部内で一元管理し、
担当者への情報属人化を解消する。
実現したい状態:
・営業担当者全員が同じ顧客情報を参照できる
・担当変更後も過去の対応履歴を確認できる
・管理者が案件進捗を随時確認できる
目標:
毎週約2時間発生している
営業案件の集計作業を30分以内に削減する。
可能であれば、
時間
件数
割合
処理時間
などで数値化します。
4.現在の業務・システム
現在どのように仕事をしているかを書きます。
例えば、
顧客から問い合わせ
↓
営業担当者がExcelへ入力
↓
案件発生
↓
別Excelへ案件情報を入力
↓
毎週金曜日に管理者へ送付
↓
管理者が各Excelを統合
↓
営業会議資料作成
とします。
現在使っているツールも書く
例えば、
顧客管理:
Excel
メール:
Gmail
ファイル:
Google Drive
社内チャット:
Slack
会計:
freee
などです。
既存システムとの連携が必要になる可能性があるため、可能な範囲で記載します。
5.解決したい課題
課題は一覧化すると分かりやすくなります。
| ID | 課題 | 優先度 |
|---|---|---|
| P01 | 顧客情報が担当者ごとに分散 | 高 |
| P02 | 案件進捗を管理者が把握できない | 高 |
| P03 | 過去の対応履歴が共有されない | 高 |
| P04 | Excel集計に時間がかかる | 中 |
| P05 | 外出先から確認できない | 低 |
優先順位を付けると、開発会社側も、
どこに予算を使うべきか
判断しやすくなります。
6.システム化対象範囲
提案依頼書では、
何を作るか
と同時に、
何を作らないか
を明確にします。
記入例
今回対象:
・顧客管理
・案件管理
・対応履歴
・担当者管理
・CSV出力
・ユーザー管理
今回対象外:
・会計機能
・請求書発行
・メール配信
・AIによる売上予測
将来検討:
・会計システム連携
・AI営業支援
対象外を明記しないと、
発注者:
当然入っていると思った
開発会社:
依頼されていない
という認識違いにつながります。
7.機能要件
必要な機能が分かっている場合は一覧化します。
テンプレート
| ID | 機能 | 概要 | 優先度 |
|---|---|---|---|
| F01 | ログイン | ユーザー認証 | Must |
| F02 | 顧客管理 | 顧客登録・編集 | Must |
| F03 | 顧客検索 | 条件指定検索 | Must |
| F04 | 案件管理 | 案件登録・更新 | Must |
| F05 | 対応履歴 | 顧客対応を記録 | Must |
| F06 | CSV出力 | 一覧データ出力 | Should |
| F07 | ダッシュボード | 案件状況表示 | Could |
詳細まで決まっていなくてもよい
RFPの段階で、
検索ボタンは
右上に青色で配置
まで決める必要はありません。
まず、
顧客を検索できる
案件を管理できる
履歴を残せる
という要求を整理します。
詳細なUI・仕様は要件定義・設計工程で詰める方法があります。
8.非機能要件
システムの機能以外の条件です。
例えば、
利用者:
30名
最大同時利用:
20名
利用時間:
平日8:00〜20:00
対応端末:
PC、スマートフォン
対応ブラウザ:
Chrome、Edge最新版
バックアップ:
1日1回以上を希望
セキュリティ:
ユーザー権限管理が必要
個人情報:
顧客氏名・電話番号・メールを保存
などです。
まだ具体的に決められない場合は、
利用者30人程度を想定している。
必要なバックアップ方式・セキュリティ構成を
提案してほしい。
としても構いません。
9.データ移行
既存システム・Excelからデータを移す場合は必ず記載します。
記入例
移行元:
Excel
顧客:
約20,000件
案件:
約50,000件
Excelファイル:
約30ファイル
対象期間:
過去5年分
補足:
担当者ごとにExcel形式が異なるため、
データ整理方法も含めて提案してほしい。
データ移行を提案依頼書へ書いていないと、後から、
データ移行は別料金です
となる可能性があります。
10.外部システム連携
例えば、
会計システム
Google Workspace
Slack
Salesforce
決済サービス
既存基幹システム
などと連携する場合です。
テンプレート
連携先:
連携するデータ:
連携方向:
連携頻度:
API有無:
提案してほしい内容:
記入例
連携先:
Slack
用途:
案件ステータス変更時の通知
詳細:
最適な連携方法を提案してほしい。
詳細仕様が分からなくても、
何を実現したいか
は伝えます。
11.運用・保守
開発後も保守を依頼する場合は記載します。
例えば、
希望内容:
・障害対応
・問い合わせ対応
・セキュリティアップデート
・バックアップ確認
・軽微な修正
希望対応時間:
平日9:00〜18:00
提案希望:
・月額保守費
・保守対象
・対応時間
・緊急時対応方法
とします。
開発費だけでなく、
年間でいくらかかるのか
を比較できるようにします。
12.発注者側の体制
開発会社の体制だけでなく、発注企業側の体制も記載します。
例えば、
プロジェクト責任者:
営業部長
業務担当:
営業担当者2名
システム担当:
情報システム担当者1名
最終決裁:
代表取締役
です。
開発会社側も、
誰へ要件確認すればよいか
誰が意思決定するか
を把握できます。
13.予算
可能であれば、予算レンジを記載します。
例えば、
初期開発:
300〜500万円程度
月額運用:
10万円以内を希望
などです。
正確な金額を示したくなければ、
500万円以内
300〜500万円程度
数百万円規模
などでも構いません。
予算がないと、
発注側:
100万円程度を想定
開発側:
1,000万円規模を提案
という大きなミスマッチが発生する可能性があります。
14.スケジュール
提案プロセスと開発スケジュールを書きます。
例えば、
RFP配布:
8月1日
質問受付期限:
8月10日
質問回答:
8月15日
提案書提出:
8月25日
プレゼン:
9月1日
ベンダー決定:
9月5日
契約:
9月中
開発開始:
10月
希望リリース:
翌年3月
です。
リリース期限の理由も書く
例えば、
希望:
3月末
だけでなく、
4月1日の新年度から
新システムを利用する必要がある
と書きます。
これによって開発会社も期限の重要度を理解できます。
15.提案依頼事項
テンプレートの中でも特に重要な部分です。
開発会社へ、
提案書に何を書いてほしいか
を指定します。
そのまま使える例
以下の内容についてご提案ください。
1.当社課題に対する理解
2.提案するシステムの全体構成
3.採用技術および選定理由
4.要件定義・開発の進め方
5.プロジェクト体制
6.開発スケジュール
7.初期開発費用
8.月額運用・保守費用
9.保守内容
10.データ移行方法
11.セキュリティ対策
12.想定されるリスク
13.類似システムの開発実績
14.当社要求以外の改善提案
提案項目を指定すると、
A社:
費用しか書いていない
B社:
技術説明だけ
C社:
開発体制だけ
というバラつきを減らせます。
IPAの実際の調達資料でも、提案書に求める項目をあらかじめ整理し、全体方針・実施方法・体制・実績などについて提案を求める形式が採られています。
16.見積書のフォーマットも揃える
価格を比較する場合は、
一式300万円
だけではなく、可能なら内訳を依頼します。
例えば、
| 項目 | 金額 |
|---|---|
| 要件定義 | ○円 |
| 基本設計 | ○円 |
| 詳細設計 | ○円 |
| 開発 | ○円 |
| テスト | ○円 |
| データ移行 | ○円 |
| リリース | ○円 |
| PM | ○円 |
| 月額保守 | ○円 |
です。
これによって、
A社はデータ移行込み
B社は別料金
などの違いを確認しやすくなります。
17.提案書の提出方法
例えば、
提出期限:
2026年8月25日 17:00
形式:
PDF
提出方法:
メール
ページ数:
原則30ページ以内
プレゼン:
60分
内訳:
提案45分
質疑15分
などです。
複数社へ依頼するなら条件を統一します。
18.質問受付方法
開発会社から質問が来ることを想定します。
例えば、
質問期限:
8月10日
質問方法:
指定Excel
回答日:
8月15日
回答方法:
各社へ同一内容を共有
などです。
複数社を比較する場合、
A社だけ追加情報を知っている
という状態をできるだけ避けます。
19.評価方法
提案依頼書を作るなら、評価方法も事前に決めておくと選定しやすくなります。
例えば、
| 評価項目 | 配点 |
|---|---|
| 課題・要件理解 | 20 |
| 提案内容 | 20 |
| 技術力 | 15 |
| 開発体制 | 10 |
| スケジュール | 10 |
| 費用 | 15 |
| 運用・保守 | 5 |
| 実績 | 5 |
| 合計 | 100 |
です。
価格だけで決めるのではなく、
本当に課題を理解しているか
実現可能な提案か
必要な体制があるか
も確認します。
中小企業向けの簡易提案依頼書テンプレート
ここまでのテンプレートでは項目が多いと感じる場合は、次の簡易版でも構いません。
# システム開発 提案依頼書
## 1. 今回お願いしたいこと
○○業務をWebシステム化したい。
## 2. 現在の業務
現在は以下の流れで業務を行っている。
1.
2.
3.
現在利用しているもの:
・Excel
・Google Drive
・Gmail
## 3. 現在困っていること
・
・
・
## 4. システム導入後に実現したいこと
・
・
・
## 5. 必要と考えている機能
・
・
・
## 6. 利用者
利用部署:
利用人数:
管理者:
## 7. 既存データ
既存Excel:
件数:
移行希望:
## 8. 予算
○○〜○○万円程度
## 9. 希望時期
○年○月までに利用開始希望
## 10. 提案してほしいこと
・システム構成
・開発方法
・開発費
・スケジュール
・保守費
・追加提案
小規模な業務システムであれば、この程度からでも開発会社へ相談できます。
提案依頼書はWord・Excel・PowerPointのどれがよい?
形式に絶対的な決まりはありません。
Word・Google Docs
向いている内容は、
背景
目的
課題
依頼内容
条件
です。
文章中心のRFPに向いています。
Excel・Google Sheets
向いているのは、
機能一覧
非機能要件
課題一覧
質問票
見積フォーマット
評価表
です。
PowerPoint
経営層・関係部署へ、
プロジェクト概要
現状課題
導入後イメージ
を説明する用途には使いやすいですが、詳細な要件管理には表計算や文書を併用した方が管理しやすいでしょう。
実務では複数ファイルでもよい
例えば、
RFP本文
→ Google Docs
機能一覧
→ Google Sheets
現行業務
→ 業務フロー図
既存資料
→ Excel・PDF
という構成でも問題ありません。
提案依頼書にはどこまで要件を書くべき?
すべてを決定する必要はありません。
例えば、
顧客検索機能が必要
まで書き、
検索アルゴリズム
DBインデックス
API設計
は開発会社へ提案してもらうこともできます。
重要なのは、
発注者が決めるべきこと
と、
開発会社から提案してほしいこと
を分けることです。
例えば、
発注者側で決める
なぜ作るか
何を解決するか
誰が使うか
絶対必要な機能
予算
納期
社内ルール
開発会社から提案を受ける
技術構成
クラウド
開発方法
データ移行方式
具体的なセキュリティ構成
保守方法
などです。
提案依頼書でよくある失敗
失敗1|テンプレートを埋めることが目的になる
提案依頼書の目的は、
項目を全部埋める
ことではありません。
自社に合った提案を
開発会社から受ける
ことが目的です。
不要な項目は削除して構いません。
失敗2|背景・目的を書かない
例えば、
必要機能:
顧客登録
検索
CSV
だけでは、開発会社はなぜその機能が必要なのか理解できません。
背景・課題を記載します。
失敗3|対象外を書かない
後から、
当然この機能も
含まれていると思った
というトラブルにつながります。
対象外も明示します。
失敗4|提案してほしい項目を指定しない
各社の提案書の構成がバラバラになり、比較しにくくなります。
提案項目を指定します。
失敗5|予算を書かない
予算規模が分からないと、提案規模が大きくばらつく可能性があります。
金額またはレンジを伝えます。
失敗6|機能を細かく決めすぎる
発注者側で技術仕様まで固定すると、開発会社からの改善提案を受けにくくなることがあります。
理由がない部分は、
最適な方法を提案してください
とします。
失敗7|現場担当者が確認していない
管理者だけでRFPを作ると、実際の業務が抜ける場合があります。
利用者にもレビューしてもらいます。
提案依頼書を作成する手順
おすすめは次の流れです。
STEP1
現在の業務を整理する
↓
STEP2
業務課題を洗い出す
↓
STEP3
開発目的を決める
↓
STEP4
対象範囲を決める
↓
STEP5
必要な要件を整理する
↓
STEP6
予算・納期を決める
↓
STEP7
提案してほしい内容を決める
↓
STEP8
評価方法を決める
↓
STEP9
現場・管理者でレビュー
↓
STEP10
開発会社へ配布
いきなりテンプレートへ文字を入れるより、
業務
↓
課題
↓
目的
↓
システム
という順番で整理すると作りやすくなります。
提案依頼書に関するよくある質問
提案依頼書とRFPは同じですか?
基本的には同じ意味で使われます。
RFPは「Request for Proposal」の略で、日本語では「提案依頼書」です。
IPAでも、RFPは導入システムの概要や提案依頼事項、調達条件などを示し、ベンダーへ提案書の提出を依頼する文書と整理されています。
提案依頼書と要件定義書の違いは?
提案依頼書は、
開発会社へ
提案してください
と依頼する文書です。
要件定義書は、
実際に開発するシステムは
この内容です
と要件を整理・合意する文書です。
一般的には、
RFP作成
↓
開発会社から提案
↓
ベンダー選定
↓
要件定義
↓
要件定義書
という流れがあります。
提案依頼書は必ず必要ですか?
必須ではありません。
例えば、
小規模開発
依頼先がすでに決まっている
要件整理から一緒に進める
場合は、正式なRFPを作成しないこともあります。
一方、
複数社を比較する
一定規模以上の予算
開発範囲が広い
社内承認が必要
場合は、提案依頼書を作るメリットが大きくなります。
要件が決まっていなくても提案依頼書を作れますか?
作れます。
少なくとも、
現在の業務
現在の課題
実現したいこと
利用者
予算
希望時期
が分かれば、開発会社から実現方法を提案してもらうことができます。
むしろ技術的な実現方法まで分からないからこそ、提案を依頼する意味があります。
提案依頼書は何ページ必要ですか?
決まりはありません。
小規模システムなら数ページでも十分な場合があります。
重要なのはページ数ではなく、
開発会社が
見積・提案に必要な情報を
理解できること
です。
hiro-dev-labの要件整理・業務システム開発支援
hiro-dev-labでは、Webシステム・業務システムについて、実装だけでなく発注前の業務・要件整理から対応しています。
例えば、
- 現状業務のヒアリング
- 業務フロー整理
- 課題整理
- システム化範囲の整理
- 提案依頼書作成に必要な情報整理
- 業務要件・機能要件整理
- 非機能要件整理
- データ移行方針の整理
- 外部システム連携の検討
- Java・Python・TypeScriptによるWebシステム開発
などを検討できます。
例えば、
現在
Excelで業務管理
↓
業務が複雑化
↓
システム化したい
↓
しかし何を開発会社へ
伝えればよいか分からない
という状態であれば、
現在の業務をヒアリング
↓
課題整理
↓
システム化する範囲を整理
↓
必要要件を整理
↓
提案依頼書・要件資料へ反映
↓
設計・開発
という順番で進めることができます。
提案依頼書は「完成された仕様書」ではなく「良い提案を受けるための資料」
提案依頼書を作成するとき、
細かく書くほど良い
とは限りません。
大切なのは、
なぜシステムを作りたいのか
何に困っているのか
何を必須とするのか
何は今回対象外なのか
予算はいくらか
いつまでに必要か
何を提案してほしいのか
が伝わることです。
まずは今回紹介したテンプレートを使って、
1.背景
2.目的
3.現状業務
4.課題
5.対象範囲
6.必要な機能
7.非機能要件
8.データ移行
9.予算
10.スケジュール
11.提案依頼事項
を整理してみてください。
そして、
どんなシステムにすればよいか分からない
要件自体がまだ曖昧
既存ExcelをどうWeb化すればよいか分からない
という場合は、無理にRFPを完成させる必要はありません。
現在の業務と課題から整理し、開発会社と一緒にシステム化の方向性を決める方法もあります。
提案依頼書・要件定義・業務システム開発について相談する