RFP（提案依頼書）の書き方｜目次テンプレートと項目別の記入例

RFP（Request for Proposal、提案依頼書）とは、システムの発注側が「何に困っていて、何を、いつまでに、どんな条件で実現したいか」を文書にまとめ、複数のベンダーに同じ条件で提案を依頼するための書類です。 同じ文書を渡すことで各社の提案を横に並べて比べられるようになり、選んだ理由も説明しやすくなります。

この記事では、目次から最終章までをそのまま貼れるRFPの全文テンプレートと、架空の「備品予約システム刷新」を題材にした全項目の記入例を本文に載せています。機能要件一覧・非機能要件一覧・提案評価表は表計算ソフトに貼れるタブ区切りで用意し、評価表の加重合計はPythonで検算しました。契約に関わる項目は一般的な項目の例であり、実際の条件は自社の規程と法務担当の確認に従ってください。

確認環境：Ubuntu 24.04、Python 3.11.15（採点の検算）、LibreOffice Calc 24.2（表計算の数式の検算）、@mermaid-js/mermaid-cli 12.0.0 と Chromium（ガント図の描画）。

RFPの章立て早見表

迷ったら「2. 背景と目的」「4. 依頼する範囲」「12. 選定の進め方」の3章を先に固めると、残りの章が書きやすくなります。

RFI・RFP・RFQの違い

名前の似た3つの文書は、選定のどの段階で、何を集めたいかで使い分けます。

候補が見えていないときは RFI から始め、候補が3〜5社に絞れたら RFP に進みます。パッケージの追加ライセンスのように仕様が決まっている買い物は RFQ だけで足ります。

作成から契約までのスケジュール

RFPの発行から契約までは、提案書の作成期間を3〜4週間取ると、各社が体制と見積もりを検討する時間を確保できます。次の Mermaid のコードは、Mermaid に対応したエディタやWikiに貼るとガント図として表示されます。

gantt
    title ベンダー選定スケジュール（例）
    dateFormat YYYY-MM-DD
    axisFormat %m/%d
    excludes weekends
    section 準備
    RFPの作成と社内承認      :a1, 2027-01-12, 15d
    候補ベンダーの選定       :a2, 2027-01-25, 5d
    section 提案依頼
    RFPの発行                :milestone, m1, 2027-02-01, 0d
    説明会                   :b1, 2027-02-05, 1d
    質問の受付               :b2, 2027-02-01, 10d
    質問への回答（全社へ）   :b3, after b2, 3d
    提案書の作成期間         :b4, 2027-02-01, 20d
    提案書の提出期限         :milestone, m2, 2027-02-26, 0d
    section 評価
    書類評価（採点）         :c1, 2027-03-01, 5d
    提案説明会とデモ         :c2, after c1, 3d
    最終評価と社内決裁       :c3, after c2, 5d
    section 契約
    結果の通知               :milestone, m3, after c3, 0d
    契約条件の調整と締結     :d1, after c3, 10d
    開発開始                 :milestone, m4, after d1, 0d

RFPの全文テンプレート（Markdown）

次のテンプレートは、そのまま貼って【　】の中を書き換えると1本のRFPになります。丸かっこは書くときの手引きなので、完成時に消してください。

# 【システム名】 提案依頼書（RFP）

- 文書番号：【RFP-2027-001】
- 版数：【1.0】
- 発行日：【YYYY年MM月DD日】
- 発行者：【会社名 部署名】

## 目次

1. 依頼の概要
2. 背景と目的
3. 現行の業務とシステム
4. 依頼する範囲
5. 機能要件
6. 非機能要件
7. スケジュール
8. 体制と進め方
9. 成果物
10. 予算と見積もり
11. 提案書に書いてほしいこと
12. 選定の進め方
13. 契約に関する事項
14. 別紙一覧

## 1. 依頼の概要

### 1.1 件名
【システム名】の【新規構築／刷新】に関する提案依頼

### 1.2 発注者
| 項目 | 内容 |
|---|---|
| 会社名 | 【　】 |
| 所在地 | 【　】 |
| 事業内容 | 【　】 |
| 従業員数 | 【　】名（【YYYY年MM月】時点） |

### 1.3 窓口
| 項目 | 内容 |
|---|---|
| 担当 | 【部署名　氏名】 |
| メール | 【　】 |
| 受付時間 | 【平日 9:00〜17:00】 |

### 1.4 本書の目的
（この文書で何を依頼し、何を受け取りたいかを2〜3文で書く）

### 1.5 本書の取り扱い
（秘密情報として扱うこと、提案以外の目的で使わないこと、辞退する場合の返却・削除の方法）

## 2. 背景と目的

### 2.1 背景
（なぜ今この取り組みが必要になったのか。事実と数字で書く）

### 2.2 現状の課題
| No. | 課題 | 困っていること（数字つき） |
|---|---|---|
| 1 | 【　】 | 【　】 |
| 2 | 【　】 | 【　】 |

### 2.3 目的
（課題を解いた結果、どうなりたいか）

### 2.4 目標（数値）
| No. | 指標 | 現在の値 | 目標の値 | 測り方 |
|---|---|---|---|---|
| 1 | 【　】 | 【　】 | 【　】 | 【　】 |

## 3. 現行の業務とシステム

### 3.1 業務の流れ
（誰が、何を、どの順で行っているか。図は別紙でもよい）

### 3.2 利用者とデータ量
| 項目 | 現在の値 | 3年後の見込み |
|---|---|---|
| 利用者数 | 【　】 | 【　】 |
| 同時利用者数（最大） | 【　】 | 【　】 |
| 主なデータの件数 | 【　】 | 【　】 |

### 3.3 現行システムの構成
| 項目 | 内容 |
|---|---|
| 稼働開始 | 【YYYY年】 |
| 構成 | 【OS、データベース、言語など】 |
| 連携しているシステム | 【　】 |
| 保守の状況 | 【　】 |

## 4. 依頼する範囲

### 4.1 対象とする業務・機能
（箇条書きで。詳細は5章と別紙）

### 4.2 依頼する作業
| 作業 | 依頼する | 備考 |
|---|---|---|
| 要件定義 | 【する／しない】 | 【　】 |
| 設計・製造・テスト | 【する／しない】 | 【　】 |
| データ移行 | 【する／しない】 | 【　】 |
| 利用者向けの説明 | 【する／しない】 | 【　】 |
| 稼働後の運用・保守 | 【する／しない】 | 【　】 |

### 4.3 対象外
（今回の依頼に含めないものを明記する）

### 4.4 発注者が行うこと
（要件の確認、受け入れテスト、利用者への周知、データの整理など）

## 5. 機能要件

### 5.1 機能要件一覧
別紙1「機能要件一覧」のとおり。各要件について、回答欄に対応方法を記入してください。

### 5.2 優先度の定義
| 優先度 | 意味 |
|---|---|
| 必須 | 稼働日に必要。対応できない場合は代わりの方法を提案してください |
| 希望 | あれば望ましい。費用と期間を分けて提示してください |
| 将来 | 今回は対象外。拡張できる構成かどうかを教えてください |

### 5.3 回答欄の書き方
| 記号 | 意味 |
|---|---|
| A | 標準の機能で対応できる |
| B | 設定の変更で対応できる |
| C | 追加の開発で対応できる（費用を見積もりに含める） |
| D | 代わりの方法を提案する（備考に内容を書く） |
| E | 対応できない |

## 6. 非機能要件
別紙2「非機能要件一覧」のとおり。機能要件と同じ記号で回答してください。
（性能、可用性、セキュリティ、運用・保守、移行、拡張性のうち、特に重視する点を2〜3文で書く）

## 7. スケジュール

| 節目 | 希望する時期 | 動かせるか |
|---|---|---|
| 契約 | 【YYYY年MM月】 | 【可／不可】 |
| 要件定義の完了 | 【YYYY年MM月】 | 【可／不可】 |
| 受け入れテストの開始 | 【YYYY年MM月】 | 【可／不可】 |
| 稼働 | 【YYYY年MM月DD日】 | 【可／不可】 |

（動かせない日付には理由を書く。繁忙期など作業を避けたい期間も書く）

## 8. 体制と進め方

### 8.1 発注者の体制
| 役割 | 担当 | 関わる割合の目安 |
|---|---|---|
| 責任者 | 【　】 | 【　】 |
| 担当リーダー | 【　】 | 【　】 |
| 業務の担当 | 【　】 | 【　】 |

### 8.2 提案してほしい体制
（責任者、リーダー、主要な担当者の役割と経験、参加する割合を示してください）

### 8.3 会議と報告
（定例の頻度、進捗報告の形式、課題と変更の管理方法）

## 9. 成果物

| No. | 成果物 | 形式 | 納品の時期 |
|---|---|---|---|
| 1 | 【要件定義書】 | 【　】 | 【　】 |
| 2 | 【設計書】 | 【　】 | 【　】 |
| 3 | 【ソースコード一式】 | 【　】 | 【　】 |
| 4 | 【テスト結果報告書】 | 【　】 | 【　】 |
| 5 | 【操作マニュアル・運用手順書】 | 【　】 | 【　】 |

## 10. 予算と見積もり

### 10.1 予算
（上限額を示す／示さない。示さない場合は理由と、想定する規模感を書く）

### 10.2 見積もりの内訳
次の区分で、初期費用と稼働後5年間の費用を分けて提示してください。

| 区分 | 内訳の例 |
|---|---|
| 初期費用 | 要件定義、設計・製造・テスト、データ移行、利用者向けの説明、ライセンス |
| 運用費用（年額） | 保守、クラウド利用料、ライセンス、問い合わせ対応 |
| 任意の項目 | 優先度「希望」の機能ごとの費用 |

### 10.3 見積もりの前提
（見積もりの前提条件、含まれないもの、有効期限を書いてください）

## 11. 提案書に書いてほしいこと

### 11.1 提案書の目次
1. 会社概要と類似の導入事例
2. 提案の要点（課題の理解と解決の方針）
3. システムの構成
4. 機能要件・非機能要件への回答（別紙1・別紙2に記入）
5. スケジュール
6. 体制
7. 運用・保守の内容
8. 見積もり
9. 想定するリスクと対応
10. 前提条件と発注者への依頼事項

### 11.2 形式
| 項目 | 指定 |
|---|---|
| ファイル形式 | 【PDF】、別紙は【表計算ファイル】 |
| ページ数 | 本編【30】ページ以内 |
| 提出方法 | 【メール添付／ファイル共有】 |

## 12. 選定の進め方

### 12.1 日程
| 節目 | 日付 |
|---|---|
| RFPの発行 | 【YYYY年MM月DD日】 |
| 説明会 | 【YYYY年MM月DD日】 |
| 質問の締め切り | 【YYYY年MM月DD日 17:00】 |
| 質問への回答 | 【YYYY年MM月DD日】 |
| 提案書の提出期限 | 【YYYY年MM月DD日 17:00】 |
| 提案説明会 | 【YYYY年MM月DD日〜DD日】 |
| 結果の通知 | 【YYYY年MM月DD日】 |

### 12.2 質問の方法
（窓口あてにメールで。質問と回答は社名を伏せて全社に共有する）

### 12.3 評価の方法
| 評価項目 | 重み |
|---|---|
| 【要件の充足度】 | 【　】 |
| 【提案の具体性と実現性】 | 【　】 |
| 【体制とスキル】 | 【　】 |
| 【スケジュールの妥当性】 | 【　】 |
| 【運用・保守の内容】 | 【　】 |
| 【費用】 | 【　】 |
| 合計 | 100 |

（優先度「必須」の要件に E が1つでもある提案は、評価の対象外とする、などの条件を書く）

### 12.4 結果の通知
（通知の方法と時期。提案の作成にかかる費用の扱い）

## 13. 契約に関する事項

| 項目 | 内容 |
|---|---|
| 契約の形態 | 【工程ごとに提案してください／指定あり】 |
| 検収 | 【条件と期間】 |
| 支払い | 【時期と方法】 |
| 成果物の権利 | 【　】 |
| 秘密保持 | 【契約の有無と時期】 |
| 再委託 | 【事前の承認が必要／不要】 |
| 不具合への対応 | 【期間と範囲】 |

## 14. 別紙一覧

| No. | 名称 |
|---|---|
| 別紙1 | 機能要件一覧 |
| 別紙2 | 非機能要件一覧 |
| 別紙3 | 現行の業務の流れ |
| 別紙4 | 現行システムの画面・帳票の一覧 |

項目別の記入例（備品予約システムの刷新）

架空の会社「サンプル商事株式会社」が、社内の備品予約システムを作り直す場合の記入例です。会社名・数値はすべて説明用に作ったものです。

1章 依頼の概要の記入例

## 1. 依頼の概要

### 1.1 件名
備品予約システムの刷新に関する提案依頼

### 1.2 発注者
| 項目 | 内容 |
|---|---|
| 会社名 | サンプル商事株式会社 |
| 所在地 | 東京都（本社）、大阪府（支社） |
| 事業内容 | 事務用品の卸売 |
| 従業員数 | 420名（2027年1月時点） |

### 1.3 窓口
| 項目 | 内容 |
|---|---|
| 担当 | 情報システム部　山田 |
| メール | rfp@example.co.jp |
| 受付時間 | 平日 9:00〜17:00 |

### 1.4 本書の目的
本書は、備品予約システムの刷新について、構築と稼働後5年間の運用・保守の提案を依頼するものです。
課題の解決方法、体制、スケジュール、費用を提案書として提出してください。

### 1.5 本書の取り扱い
本書と別紙は秘密情報です。提案の検討以外の目的で使わないでください。
提案を辞退する場合は、受け取ったファイルを削除し、その旨を窓口に連絡してください。

2章 背景と目的の記入例

課題には数字を、目標には測り方を付けると、ベンダーが規模と優先順位を読み取れます。

## 2. 背景と目的

### 2.1 背景
会議室のプロジェクターやノートPCなど約350点の備品を、2016年に導入した予約システムで管理しています。
支社の開設と在宅勤務の広がりで利用の形が変わり、現行システムでは対応しきれない場面が増えました。
現行システムの基盤は2028年3月に保守の期限を迎えます。

### 2.2 現状の課題
| No. | 課題 | 困っていること（数字つき） |
|---|---|---|
| 1 | スマートフォンから予約できない | 予約の約3割が総務部への電話・メール依頼（月およそ240件）になっている |
| 2 | 返却の遅れに気づきにくい | 返却期限を過ぎた貸出が月平均18件あり、次の予約者が使えないことがある |
| 3 | 棚卸しに時間がかかる | 年2回の棚卸しに、1回あたり延べ40時間かかっている |
| 4 | 支社の備品が別管理 | 大阪支社は表計算ファイルで管理しており、全社の利用状況を集計できない |

### 2.3 目的
社員が場所を問わず自分で予約と返却の手続きを行えるようにし、総務部の代行作業と棚卸しの負担を減らします。

### 2.4 目標（数値）
| No. | 指標 | 現在の値 | 目標の値 | 測り方 |
|---|---|---|---|---|
| 1 | 総務部が代行する予約の件数 | 月240件 | 月50件以下 | 代行登録の件数をシステムで集計 |
| 2 | 返却期限を過ぎた貸出 | 月18件 | 月5件以下 | 期限超過の件数をシステムで集計 |
| 3 | 棚卸し1回の作業時間 | 延べ40時間 | 延べ15時間以下 | 作業記録 |
| 4 | 全社の備品を1つの画面で検索 | 本社のみ | 本社と支社 | 稼働時に確認 |

3章 現行の業務とシステムの記入例

## 3. 現行の業務とシステム

### 3.1 業務の流れ
1. 社員が社内ネットワークのPCから空き状況を検索し、予約する
2. 上長の承認が必要な備品（持ち出し用PCなど12種類）は、上長がメールの通知から承認する
3. 総務部が貸出日に備品を渡し、システムに貸出を記録する
4. 返却時に総務部が状態を確認し、返却を記録する
詳細は別紙3を参照してください。

### 3.2 利用者とデータ量
| 項目 | 現在の値 | 3年後の見込み |
|---|---|---|
| 利用者数 | 420名 | 500名 |
| 同時利用者数（最大） | 約30名 | 約50名 |
| 備品の点数 | 約350点 | 約450点 |
| 予約の件数 | 月約800件 | 月約1,000件 |
| 保存している予約履歴 | 約9万件（2016年〜） | 約13万件 |

### 3.3 現行システムの構成
| 項目 | 内容 |
|---|---|
| 稼働開始 | 2016年 |
| 構成 | 社内サーバー1台（Windows Server、SQL Server）、Webアプリケーション |
| 連携しているシステム | 人事システム（社員と所属の情報をCSVで日次取り込み） |
| 保守の状況 | 基盤の保守期限は2028年3月。現行ベンダーとの保守契約は2028年3月まで |

4章 依頼する範囲の記入例

対象外と発注者が行うことを書くと、見積もりの前提が各社でそろいます。

## 4. 依頼する範囲

### 4.1 対象とする業務・機能
- 備品の検索、予約、承認、貸出、返却
- 備品の台帳管理と棚卸し
- 利用状況の集計
- 社員・所属の情報の取り込み

### 4.2 依頼する作業
| 作業 | 依頼する | 備考 |
|---|---|---|
| 要件定義 | する | 本書と別紙をもとに、当社と共同で確定する |
| 設計・製造・テスト | する | パッケージやクラウドサービスの利用も可 |
| データ移行 | する | 備品台帳350点と、直近3年分の予約履歴（約2.9万件） |
| 利用者向けの説明 | する | 総務部向け1回、一般社員向けは資料の提供のみ |
| 稼働後の運用・保守 | する | 稼働後5年間 |

### 4.3 対象外
- 会議室の予約（別システムで運用しており、今回は連携もしない）
- 備品の購入申請と資産の会計処理
- 社員が使うPC・スマートフォンの調達

### 4.4 発注者が行うこと
- 要件の確認と決定（担当リーダーが週8時間程度参加）
- 備品台帳の内容の整理（移行前に重複と廃棄済みを当社で整理する）
- 受け入れテストの実施（総務部3名、2週間）
- 社員への周知

5章・6章 要件の記入例

本文には定義だけを書き、要件そのものは別紙の一覧に集めます。一覧の内容は後の節に載せています。

## 5. 機能要件

### 5.1 機能要件一覧
別紙1「機能要件一覧」（全18件、うち必須12件）のとおり。各要件について、回答欄に対応方法を記入してください。

## 6. 非機能要件
別紙2「非機能要件一覧」（全16件）のとおり。機能要件と同じ記号で回答してください。
当社が特に重視するのは次の3点です。
- 平日の業務時間（8:00〜20:00）に安定して使えること
- スマートフォンの画面でも予約の操作を3分以内に終えられること
- 社員の情報を扱うため、通信と保存データが暗号化されていること

7章 スケジュールの記入例

## 7. スケジュール

| 節目 | 希望する時期 | 動かせるか |
|---|---|---|
| 契約 | 2027年4月 | 可 |
| 要件定義の完了 | 2027年6月 | 可 |
| 受け入れテストの開始 | 2027年11月 | 可 |
| 稼働 | 2028年1月11日 | 可（遅くとも2028年2月末まで） |
| 現行システムの停止 | 2028年3月31日 | 不可（基盤の保守期限のため） |

- 3月と9月は棚卸しの月のため、総務部が参加する作業は避けてください。
- 稼働日の前後1週間は、問い合わせに対応できる体制を提案してください。

8章・9章 体制と成果物の記入例

## 8. 体制と進め方

### 8.1 発注者の体制
| 役割 | 担当 | 関わる割合の目安 |
|---|---|---|
| 責任者 | 情報システム部長 | 月2時間（節目の判断） |
| 担当リーダー | 情報システム部　山田 | 週8時間 |
| 業務の担当 | 総務部 2名 | 要件定義と受け入れテストの期間は週6時間 |

### 8.2 提案してほしい体制
責任者、リーダー、主要な担当者について、役割、類似システムの経験年数、参加する割合を示してください。
リーダーは提案説明会に出席してください。

### 8.3 会議と報告
- 定例会議：週1回（オンライン、60分）
- 進捗報告：週次。予定と実際の差、課題、次週の予定を含めてください
- 仕様の変更：書面で依頼し、費用と期間への影響を確認してから着手します

## 9. 成果物

| No. | 成果物 | 形式 | 納品の時期 |
|---|---|---|---|
| 1 | 要件定義書 | PDFと編集できる形式 | 要件定義の完了時 |
| 2 | 基本設計書（画面、データ、連携） | PDFと編集できる形式 | 設計の完了時 |
| 3 | ソースコードと設定一式 | リポジトリ | 稼働時 |
| 4 | テスト結果報告書 | PDF | 受け入れテストの開始前 |
| 5 | データ移行の手順書と結果報告書 | PDF | 稼働時 |
| 6 | 操作マニュアル（一般社員向け・総務部向け） | PDF | 受け入れテストの開始前 |
| 7 | 運用手順書 | PDFと編集できる形式 | 稼働時 |

10章・11章 予算と提案書の記入例

## 10. 予算と見積もり

### 10.1 予算
上限額は示しません。初期費用と5年間の運用費用の合計で評価します。
優先度「希望」の機能は、機能ごとに費用を分けて提示してください。

### 10.2 見積もりの内訳
| 区分 | 内訳 |
|---|---|
| 初期費用 | 要件定義、設計・製造・テスト、データ移行、利用者向けの説明、ライセンス |
| 運用費用（年額） | 保守、クラウド利用料、ライセンス、問い合わせ対応 |
| 任意の項目 | 優先度「希望」の機能（6件）ごとの費用 |

### 10.3 見積もりの前提
見積もりの前提条件、見積もりに含まれないもの、有効期限（提出日から90日以上）を書いてください。

## 11. 提案書に書いてほしいこと

### 11.2 形式
| 項目 | 指定 |
|---|---|
| ファイル形式 | PDF。別紙1・別紙2は表計算ファイルのまま記入 |
| ページ数 | 本編30ページ以内（会社案内などの添付は別） |
| 提出方法 | 窓口あてにメールで送付（1通20MBまで） |

12章 選定の進め方の記入例

評価項目と重みを先に示すと、各社が力を入れる場所を合わせられ、提案が比べやすくなります。

## 12. 選定の進め方

### 12.1 日程
| 節目 | 日付 |
|---|---|
| RFPの発行 | 2027年2月1日 |
| 説明会 | 2027年2月5日（オンライン） |
| 質問の締め切り | 2027年2月12日 17:00 |
| 質問への回答 | 2027年2月17日 |
| 提案書の提出期限 | 2027年2月26日 17:00 |
| 提案説明会 | 2027年3月8日〜10日（1社60分） |
| 結果の通知 | 2027年3月17日 |

### 12.2 質問の方法
窓口あてにメールで送ってください。質問番号、該当する章、質問内容を表にしてください。
質問と回答は、社名を伏せて提案を依頼した全社に共有します。

### 12.3 評価の方法
| 評価項目 | 重み |
|---|---|
| 要件の充足度 | 25 |
| 提案の具体性と実現性 | 15 |
| 体制とスキル | 15 |
| スケジュールの妥当性 | 10 |
| 運用・保守の内容 | 10 |
| 費用（初期＋5年間の運用） | 20 |
| 提案書と説明のわかりやすさ | 5 |
| 合計 | 100 |

- 各項目を5点満点で採点し、重みを掛けて合計します。
- 優先度「必須」の要件に E（対応できない）が1つでもある提案は、評価の対象外とします。

### 12.4 結果の通知
提案した全社に、2027年3月17日までにメールで通知します。
提案書の作成と説明会への参加にかかる費用は、各社の負担とします。

13章 契約に関する事項の記入例

ここは一般的な項目の例です。条件の内容は、自社の規程と法務担当の確認をもとに決めてください。

## 13. 契約に関する事項

| 項目 | 内容 |
|---|---|
| 契約の形態 | 工程ごとに適した形態を提案してください |
| 検収 | 受け入れテストの合格をもって検収とします。検収の期間は納品から10営業日 |
| 支払い | 検収月の翌月末。分割を希望する場合は提案してください |
| 成果物の権利 | 提案に含めてください（パッケージ部分と個別に開発した部分を分けて記載） |
| 秘密保持 | 本書の受け取り前に、秘密保持契約を結びます |
| 再委託 | 事前に書面で当社の承認を得てください |
| 不具合への対応 | 対応する期間と範囲を提案してください |

機能要件一覧（タブ区切り）

次のブロックを表計算ソフトに貼ると、列に分かれて入ります。1行に1つの要件、主語と条件と数値を入れるのが書き方の基本です。

ID  分類  要件  優先度 回答（A〜E） 備考
F-001   検索  社員は、備品を名称・分類・設置場所・利用日時で検索できる    必須      
F-002   検索  検索結果に、指定した日時の空き状況を表示する  必須      
F-003   予約  社員は、空いている備品を30分単位で予約できる 必須      
F-004   予約  同じ備品・同じ時間帯の予約が重ならないようにする    必須      
F-005   予約  社員は、利用開始前の自分の予約を変更・取り消しできる  必須      
F-006   予約  毎週同じ曜日・時間の予約を、最大3か月先までまとめて登録できる 希望      
F-007   承認  承認が必要な備品の予約は、予約者の上長に承認依頼を通知する   必須      
F-008   承認  上長は、通知から承認または差し戻し（理由つき）ができる 必須      
F-009   貸出・返却   総務部は、備品に貼った二次元コードを読み取って貸出・返却を記録できる  必須      
F-010   貸出・返却   返却期限の前日と、期限を過ぎた翌朝に、予約者へ通知する 必須      
F-011   貸出・返却   返却時に、備品の状態（正常・要修理）とメモを記録できる 希望      
F-012   台帳  総務部は、備品の登録・変更・廃棄をCSVの取り込みでも行える  希望      
F-013   台帳  棚卸しで、読み取った備品と台帳の差を一覧で表示する   必須      
F-014   集計  備品ごと・月ごとの利用回数と利用時間をCSVで出力できる    希望      
F-015   連携  人事システムのCSV（社員・所属）を1日1回取り込む  必須      
F-016   連携  社内のシングルサインオンでログインできる    必須      
F-017   通知  通知の方法を、メールとチャットから社員が選べる 希望      
F-018   画面  スマートフォンの画面幅で、検索から予約までの操作ができる    希望      

非機能要件一覧（タブ区切り）

非機能要件は数値と測り方で書くと、各社の提案を同じ物差しで比べられます。数値はこの題材のための例です。

ID  分類  要件  目標値・条件  優先度 回答（A〜E） 備考
N-001   性能  検索結果の表示時間   同時50名の利用時に、3秒以内が95%以上   必須      
N-002   性能  予約の登録時間 同時50名の利用時に、2秒以内が95%以上   必須      
N-003   可用性 サービスの提供時間   平日8:00〜20:00（計画停止は土日・夜間に行う） 必須      
N-004   可用性 稼働率 提供時間に対して月間99.5%以上   必須      
N-005   可用性 障害からの復旧時間   障害の検知から4時間以内    必須      
N-006   可用性 バックアップ  1日1回、7世代を保存。前日の時点に戻せる   必須      
N-007   セキュリティ  通信の暗号化  すべての通信をTLS 1.2以上で暗号化する  必須      
N-008   セキュリティ  権限  一般社員・上長・総務部・管理者の4種類で操作を分ける  必須      
N-009   セキュリティ  操作の記録   ログイン、予約の変更、台帳の変更を1年間保存する    必須      
N-010   セキュリティ  脆弱性への対応 稼働前に診断を行い、重大な指摘は稼働までに対応する   必須      
N-011   運用・保守   問い合わせの受付    平日9:00〜18:00、メールと電話 必須      
N-012   運用・保守   監視  サービスの停止を検知し、15分以内に当社へ連絡する   希望      
N-013   移行  データ移行   備品台帳350点と直近3年分の予約履歴を移行し、件数を照合する 必須      
N-014   移行  切り替え    切り替えによる停止は、土日の2日間以内 必須      
N-015   拡張性 利用者の増加  利用者500名、備品450点まで構成の変更なく対応できる    必須      
N-016   利用環境    対応ブラウザー 提案時点の主要なブラウザーの最新版（PC・スマートフォン）   必須      

N-004 の稼働率を停止時間に直すと、平日12時間×22日＝264時間に対して 264×0.005＝月1.32時間（約79分）までという意味になります。数値を決めるときは、このように時間に直して無理がないかを確かめると決めやすくなります。

提案評価表と重み付け採点

評価表（タブ区切り）

各項目を5点満点で採点し、重み（合計100）を掛けて100点満点に換算します。次の表は、3社から提案を受けたと仮定した採点例です。

評価項目    重み  A社  B社  C社
要件の充足度  25  4   5   3
提案の具体性と実現性  15  4   3   4
体制とスキル  15  3   4   4
スケジュールの妥当性  10  4   3   5
運用・保守の内容    10  3   4   3
費用（初期＋5年間の運用）   20  4.2 3.1 5.0
提案書と説明のわかりやすさ   5   4   3   4

表計算ソフトでは、項目ごとの点数を =C2*$B2/5 で求めて縦に合計するか、=SUMPRODUCT($B$2:$B$8,C2:C8)/5 で一度に求めます。どちらの数式も LibreOffice Calc で計算し、A社 75.8、B社 75.4、C社 79 と、下の Python の結果と同じ値になりました。

採点の物差し（5点満点）

費用の点数の出し方

費用は、最も低い提案額を5点とし、他社は比率で点を付ける方法がよく使われます。

# 費用点 = 最も低い提案額 ÷ その会社の提案額 × 5（小数第1位に丸め）
prices = {"A社": 1800, "B社": 2400, "C社": 1500}   # 単位: 万円（初期＋5年間の運用）
lowest = min(prices.values())
for name, p in prices.items():
    print(f"{name}: {p:>5,} 万円 -> 費用点 {lowest / p * 5:.1f}")

実行結果：

A社: 1,800 万円 -> 費用点 4.2
B社: 2,400 万円 -> 費用点 3.1
C社: 1,500 万円 -> 費用点 5.0

加重合計をPythonで検算する

import csv, io

DATA = """評価項目\t重み\tA社\tB社\tC社
要件の充足度\t25\t4\t5\t3
提案の具体性と実現性\t15\t4\t3\t4
体制とスキル\t15\t3\t4\t4
スケジュールの妥当性\t10\t4\t3\t5
運用・保守の内容\t10\t3\t4\t3
費用（初期＋5年間の運用）\t20\t4.2\t3.1\t5.0
提案書と説明のわかりやすさ\t5\t4\t3\t4
"""

rows = list(csv.DictReader(io.StringIO(DATA), delimiter="\t"))
vendors = ["A社", "B社", "C社"]
total_weight = sum(int(r["重み"]) for r in rows)
print("重みの合計:", total_weight)

totals = {v: 0.0 for v in vendors}
for r in rows:
    w = int(r["重み"])
    parts = []
    for v in vendors:
        point = float(r[v]) * w / 5      # 5点満点を重みの点数に換算
        totals[v] += point
        parts.append(f"{v} {point:5.1f}")
    print(f'{r["評価項目"]:<14} 重み{w:>3} | ' + " | ".join(parts))

print("-" * 60)
for v in sorted(vendors, key=lambda x: -totals[x]):
    print(f"{v}: {totals[v]:.1f} 点（100点満点）")

実行結果：

重みの合計: 100
要件の充足度         重み 25 | A社  20.0 | B社  25.0 | C社  15.0
提案の具体性と実現性     重み 15 | A社  12.0 | B社   9.0 | C社  12.0
体制とスキル         重み 15 | A社   9.0 | B社  12.0 | C社  12.0
スケジュールの妥当性     重み 10 | A社   8.0 | B社   6.0 | C社  10.0
運用・保守の内容       重み 10 | A社   6.0 | B社   8.0 | C社   6.0
費用（初期＋5年間の運用）  重み 20 | A社  16.8 | B社  12.4 | C社  20.0
提案書と説明のわかりやすさ  重み  5 | A社   4.0 | B社   3.0 | C社   4.0
------------------------------------------------------------
C社: 79.0 点（100点満点）
A社: 75.8 点（100点満点）
B社: 75.4 点（100点満点）

結果の読み方

この例では、要件の充足度が3社で最も低いC社が、費用とスケジュールの点で総合1位になりました。重み付け採点は、ある項目の低さを別の項目で補える仕組みだからです。そのため、次の3点を採点の前に決めておくと、結果に納得しやすくなります。

A社とB社の差は0.4点です。採点者が1人変われば入れ替わる差なので、複数人で採点して平均を取り、点数だけでなく理由も記録しておくと説明がしやすくなります。

曖昧な書き方と直した書き方

RFPの文が具体的だと、各社が同じ前提で見積もれます。数値・主語・条件・期限の4つを足すのが直し方の基本です。

数値を決めきれない項目は、「現在は月800件。3年後に1,000件を見込む」のように現在の値と見込みを書き、方式や目標値を提案してもらう形にすると、ベンダーの知見を引き出せます。

発行前のチェックリスト

- [ ] 背景と課題に数字が入っている
- [ ] 目標に測り方が書いてある
- [ ] 対象外と、発注者が行うことが書いてある
- [ ] 機能要件は1行1要件で、IDと優先度が付いている
- [ ] 必須の要件が全体の6〜7割以内に収まっている
- [ ] 非機能要件に数値と条件が入っている
- [ ] 動かせない日付と、その理由が書いてある
- [ ] 見積もりの内訳（初期・運用・任意）を指定している
- [ ] 評価項目の重みの合計が100になっている
- [ ] 足切りの条件を書いている
- [ ] 質問の締め切り・回答日・提出期限に日付と時刻が入っている
- [ ] 提案書の作成期間が3週間以上ある
- [ ] 業務部門と決裁者の承認を得ている
- [ ] 秘密保持の扱いを決めている

よくある質問

Q. RFPは何ページくらいが適切ですか？ A. 本文10〜30ページと別紙が目安です。ページ数よりも、背景・範囲・選定の進め方の3つがそろっていて、要件が一覧になっていることが大切です。小さな依頼なら、早見表の章を5〜6ページにまとめた形でも役目を果たします。

Q. 予算は書いたほうがよいですか？ A. 上限を示すと、予算に合う提案が集まりやすくなります。示さない場合は、利用者数やデータ量など規模がわかる数字を多めに書き、初期費用と運用費用を分けて提示してもらうと比べやすくなります。

Q. 要件が固まりきっていない場合はどうすればよいですか？ A. 固まっている部分を必須、迷っている部分を希望として書き、未決の点は「提案してほしいこと」として明記します。候補や進め方そのものが見えていない段階なら、先に RFI で情報を集める方法が合っています。

Q. 何社に依頼するのがよいですか？ A. 3〜5社が比べやすい数です。提案書の読み込みと説明会には1社あたり数時間かかるため、評価にかけられる時間から逆算して決めます。

まとめ

• RFPは、複数のベンダーに同じ条件で提案を依頼し、横に並べて比べるための文書です。
• 章立ては14章。背景と目的・依頼する範囲・選定の進め方の3章を先に固めます。
• 課題には数字、目標には測り方、範囲には対象外と発注者が行うことを書きます。
• 機能要件と非機能要件は1行1要件の一覧にし、ID・優先度・回答欄（A〜E）を付けます。
• 評価は項目と重みを先に示し、5点満点×重みで100点満点に換算します。
• 重み付け採点は項目どうしを補い合うため、足切りの条件と僅差の扱いを採点の前に決めます。
• 曖昧な文は、数値・主語・条件・期限を足して直します。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。