RFPの書き方と要件定義の関係｜基幹システムの提案依頼書と提案の比べ方
RFP（提案依頼書）は、要件定義で決めたことを開発会社に正しく伝え、各社の提案を同じ物差しで比べるための文書です。要件定義が曖昧なままRFPを出すと、提案の前提が各社でばらばらになり、比べること自体ができなくなります。この記事では、基幹システムのRFPの書き方として、要件定義との関係、12章の章立て、非機能要件と現状の数字の書き方、提案評価の重みづけ、比較で見落としやすい点、送付から契約までのスケジュール例を、大手コンサルティングファーム出身の専門家の知見をもとに解説します。
- RFPと要件定義書の違いと、どの順番で作るか
- 基幹システムのRFPに入れる12の章と、それぞれに書くこと
- 見積もりに必要な「現状の数字」と非機能要件の書き方
- 提案を比べる評価項目と重みづけの例、比較で見落としやすい7つの点
- RFPの書き直し例と、送付から契約までのスケジュール例
RFPと要件定義の関係：要件定義書に「提案の条件」を足したもの
要件定義書は、新しいシステムで何を実現し、何を実現しないかを決めた文書です。RFPはそれをもとに、誰に・どんな形で・何を提案してほしいかを加えた依頼書です。
| 項目 | 要件定義書 | RFP（提案依頼書） |
|---|---|---|
| 目的 | 実現する業務と範囲を社内で合意する | 開発会社から比べられる提案を集める |
| 読む人 | 経営・業務部門・作る側 | 提案する開発会社・製品ベンダー |
| 中身 | 業務フロー、機能要件一覧、非機能要件、移行要件 | 要件定義書（別紙）＋提案してほしい内容、見積もりの様式、契約条件、選定の進め方 |
| 決めるのは | 発注側 | 発注側 |
IPA（情報処理推進機構）の「共通フレーム2013」のガイダンスが参照する「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義は発注者の責任である」「機能要求は膨張する。コスト，納期が抑制する」という原則があります。RFPも同じで、作成の作業を外部に頼んでも、目的・優先順位・対象外を決めるのは発注側です。要件定義書そのものの書き方は要件定義書の書き方で解説しています。
中小企業では、RFPを作らずに付き合いのある1社に相談して見積もりを取ることも少なくありません。それ自体が悪いわけではありませんが、比べる相手がいないと、範囲や単価が妥当かを判断する材料がなくなります。1社に絞る場合でも、RFPの形で依頼内容を文書にしておけば、見積もりの前提が残り、後で範囲をめぐる行き違いが起きにくくなります。
要件定義の前にRFPを出すか、後に出すか
RFPを出すタイミングは2通りあります。どちらを選ぶかで、RFPに書けることと、受け取れる見積もりの確かさが変わります。
| タイミング | RFPに書けること | 受け取れる見積もり | 向いている場合 |
|---|---|---|---|
| 要件定義の後 | 機能要件一覧（優先度つき）、帳票、連携、移行の範囲まで | 前提のそろった固定見積もり | 作り方を複数から比べたい。費用を確定させてから発注したい |
| 要件定義の前 | 目的、対象範囲、主要な業務と課題まで | 要件定義フェーズの見積もり＋開発以降の概算 | 発注先と一緒に要件を詰めたい。急いで着手したい |
要件定義の前にRFPを出す場合は、要件定義が終わった時点で開発以降を再見積もりすることを条件に入れておきます。前述のIPAのガイダンスでも、「多段階の見積りは双方のリスクを低減する」という原則が挙げられています。
基幹システムのRFPの章立て（12章）
中小企業の基幹システムなら、次の12章で足ります。要件の詳細は要件定義書を別紙で付け、本文は提案の条件に集中させます。
| 章 | 書くこと | 抜けると起きること |
|---|---|---|
| 1. 会社概要と依頼の背景 | 事業内容、拠点、従業員数、刷新を考えた理由 | 業界や規模に合わない提案が来る |
| 2. 目的と成功基準 | 刷新で改善したいこと。刷新後にどの数字が変われば成功か | 機能の多さを競う提案になる |
| 3. 対象範囲と対象外 | 対象の業務・拠点・部署。対象外にするもの | 各社が違う範囲で見積もる |
| 4. 現行システムとデータ | 今のシステム構成、データ件数、利用人数、連携先 | 移行と連携の費用が見積もれない |
| 5. 要件（別紙：要件定義書） | 機能要件一覧（優先度つき）、帳票、非機能要件 | 「標準機能で対応可能」の範囲が各社で違う |
| 6. 移行要件 | 移すデータの種類・期間、照合の方法、作業の分担 | 移行が「一式」や「別途」になる |
| 7. 発注側の体制と担う作業 | 責任者、決裁者、テスト・データ準備で自社が担う作業 | 社内の作業量が見えないまま契約する |
| 8. スケジュール | 稼働希望時期、繁忙期など避けたい時期、判断ゲートの時期 | 決算期や繁忙期に稼働が重なる |
| 9. 提案してほしい内容 | 作り方、Fit&Gap（標準機能で足りる部分と足りない部分）、体制、移行・テスト・定着の計画 | 提案書の構成が各社で違い、比べにくい |
| 10. 見積もりの様式 | 費目×年（5年分）の表、対象外・前提条件・発注側作業の欄 | 「一式」の見積もりが並び、比べられない |
| 11. 契約条件 | フェーズごとの契約、追加要望の費用の決め方、成果物の扱い、保守の範囲 | 追加費用の交渉で揉める |
| 12. 選定の進め方 | 質問の受付期限、提案の締切、デモの実施、評価の観点 | 提案の質がそろわない |
10章の見積もりの様式は、5年総費用で比べるための仕掛けです。費目の一覧と試算表のひな形はERP・基幹システムの費用で紹介しています。
11章の契約条件を考えるときは、IPAが2020年12月に公開した「情報システム・モデル取引・契約書（第二版）」が参考になります。ユーザ企業・ITベンダのいずれかにメリットが偏らない契約書の作成を目指したモデルで、工程ごとに個別契約を結び、工程によって請負契約と準委任契約を使い分ける考え方が整理されています。設計書やプログラムなどの成果物を誰がどう使えるかも、この章で決めておく項目です。成果物の扱いが曖昧だと、将来ほかの会社に保守を引き継ぐときに困ります。契約・設計・体制での防ぎ方はベンダーロックインとはで解説しています。
4章・5章に書く「現状の数字」と非機能要件
見積もりの精度は、RFPに書かれた現状の数字で決まります。「中規模」「多数」といった言葉では、各社が自分の想定で見積もります。次の数字は、分かる範囲で書いておきます。
| 項目 | 書く数字 | 記入例 |
|---|---|---|
| 利用者 | 利用人数、同時に使う人数、拠点数 | 利用者45人、同時利用最大20人、本社＋2倉庫 |
| 取引量 | 月間の受注件数・明細行数、仕入件数 | 受注 月2,500件・明細9,000行、仕入 月800件 |
| マスタ | 取引先数、品目数、有効なものと休眠中のもの | 得意先1,200社（うち有効700社）、品目8,000点 |
| 帳票 | 帳票の種類数、取引先指定の様式の数 | 帳票35種、うち取引先指定の納品書6種 |
| 連携 | 連携先、方式、頻度 | 会計ソフトへ日次CSV、大手取引先2社とEDI |
| 移行 | 移す期間、残高の種類 | 直近3年の取引履歴、売掛・買掛・在庫残高 |
※記入例は説明用の例です。
非機能要件（性能・可用性・セキュリティ・運用など、機能以外の要件）も、RFPで抜けやすい部分です。IPAの「非機能要求グレード」は、非機能要求の項目を6つの大項目に分けて整理し、3つの典型的なモデルシステムごとに要求レベルの目安を示しています。中小企業の基幹システムでも、「業務時間中に止まったら何時間で復旧すればよいか」「バックアップはどこに、どの頻度で取るか」「何年分のデータを保存するか」の3点だけは、数字でRFPに書いておきます。書き方の例は非機能要件とはで紹介しています。
あとで比べられなくなるRFPの書き方3つと、書き直し例
「最適」の判断を相手に任せると、各社が得意な製品と範囲で提案します。要件一覧の行ごとに対応方法を書いてもらえば、Fit&Gapの結果を横に並べて比べられます。ギャップの埋め方はフィットアンドギャップ分析とはで解説しています。
初期と月額だけでは、データ移行や研修が含まれているかが分かりません。費目と年をそろえることで、対象外の費目を足し戻して比べられます。
体制図だけでは、提案に来た人が実際に担当するのかが分かりません。提案時と開発時で担当者が変わることがあるため、関与の割合と交代時の扱いまで書いてもらいます。
提案評価の重みづけ表
提案が届く前に、評価の項目と重みを決めておきます。届いてから決めると、印象の良かった提案に合わせて基準を作ってしまいがちです。
| 評価項目 | 重み | 見るところ |
|---|---|---|
| 業務への適合（Fit&Gap） | 30 | 必須要件のうち、標準機能・設定で対応できる割合。追加開発の行の妥当性 |
| 5年総費用 | 20 | 対象外の費目を足し戻した後の5年合計。年ごとの負担の偏り |
| 体制と担当者の経験 | 15 | 実際の担当者の類似経験、関与の割合、交代時の扱い |
| 移行・テスト・定着の計画 | 15 | データ整備の分担、移行リハーサルの回数、業務シナリオテスト、稼働後の支援期間 |
| 将来の変更・引き継ぎのしやすさ | 10 | 業務変更への対応方法、他社への引き継ぎや社内での運用のしやすさ |
| 稼働後の保守体制 | 10 | 保守の範囲、問い合わせ窓口、軽微な改修の扱い |
※説明用の例です。重みは自社の目的に合わせて決めます。各項目は5段階（5＝要件を十分に満たす、3＝一部に条件つき、1＝満たさない）で採点し、重みを掛けて合計します。
採点の計算例
| 評価項目（重み） | A社 | B社 | C社 |
|---|---|---|---|
| 業務への適合（30） | 4→120 | 3→90 | 5→150 |
| 5年総費用（20） | 3→60 | 5→100 | 2→40 |
| 体制と担当者の経験（15） | 4→60 | 3→45 | 3→45 |
| 移行・テスト・定着の計画（15） | 4→60 | 2→30 | 4→60 |
| 将来の変更・引き継ぎ（10） | 3→30 | 3→30 | 2→20 |
| 稼働後の保守体制（10） | 4→40 | 3→30 | 3→30 |
| 合計（満点500） | 370 | 325 | 345 |
※説明用の例です。「4→120」は5段階の点数4に重み30を掛けた値です。
この例では、5年総費用が最も安いB社が、移行・テスト・定着の計画の弱さで3位になっています。逆に、業務への適合が最も高いC社は、費用と引き継ぎのしやすさで点を落としています。合計点だけで決めず、点の低い項目が契約条件や追加の提案で補えるものかを確かめてから最終判断します。
採点は1人で行わず、経営・業務部門・管理部門から最低3人が別々に採点し、点差の大きい項目だけを話し合います。点差が大きい項目は、RFPの書き方が曖昧だったか、提案書の記載が不足している項目であることが多く、追加の質問の対象になります。
「体制と担当者の経験」に重みを置く理由は、調査にも表れています。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書 2026」では、システム開発の品質が予定どおりにならなかった要因として「ベンダーのスキル不足」が59.9%で、「計画時の考慮不足」（48.8%）などの要因を上回りました（品質が悪化した企業への複数回答。東証上場企業とそれに準じる企業が対象）。提案書の会社の実績だけでなく、実際に担当する人の経験を確かめる必要があります。評価表の作り方と面談で聞くことはベンダー選定の進め方で詳しく解説しています。
提案比較で見落としやすい7つの点
点数をつける前に、各社の提案が同じ前提で書かれているかを確認します。見落としやすいのは次の7点です。
| 確認点 | よくある違い |
|---|---|
| 1. 対象と対象外の業務範囲 | ある会社は購買まで、別の会社は在庫までを範囲にしている |
| 2. 標準機能と追加開発の部分 | 「対応可能」の中に追加開発が含まれている |
| 3. データ移行・外部連携・テストの担当範囲 | ある会社はデータ移行・教育込み、別の会社は別途 |
| 4. 責任者と実際の担当者の経験 | 提案に来た責任者と、開発時の担当者が違う |
| 5. 追加要件の費用算定方法 | 単価・算定の基準が書かれていない |
| 6. 稼働後の保守体制と範囲 | 保守に軽微な改修が含まれるかどうかが違う |
| 7. 将来の改修・他社への引き継ぎのしやすさ | 設計書などの成果物の扱いが書かれていない |
確認は、7つの点を行に、各社を列にした比較表を作って進めます。提案書から該当する記述を抜き出して表に書き写し、記述が見つからない欄は空欄のまま残して、各社への質問の一覧にします。空欄を推測で埋めないことが大切です。「たぶん含まれているだろう」と判断した項目が、契約後に「別途」として出てくることがあるからです。
2の「対応可能」と5の「費用算定方法」は、見積書の工数と単価を並べると違いが見えやすくなります。見積書の項目ごとの確認の仕方はシステム開発の見積もりの見方をご覧ください。
提案比較でよく見落とされるのは、各社の見積もりの前提の違いです。A社はデータ移行や教育まで含めているのに、B社は別途になっている、ということが普通に起こります。
提案書に「貴社の要件はすべて標準機能で対応可能です」と書かれていたら、要件一覧の行ごとの記入を求めてください。行ごとに書いてもらうと、設定で対応する部分、運用で回避する部分が具体的に出てきます。また、自社の業務シナリオを渡してデモを依頼するのも有効です。製品の標準デモではなく、自社の見積から請求までの流れで動かしてもらうと、追加開発が必要な部分が見えてきます。
RFP作成から契約までの5つのステップとスケジュール例
- 評価項目と重みを先に決める
RFPを書く前に、何を重視して選ぶかを経営と決めます。RFPの「提案してほしい内容」は、この評価項目に対応させます。 - RFPを書き、提案先を3〜5社に絞って送る
要件定義書を別紙で付け、見積もりの様式を指定します。作り方を比べたい場合は、パッケージ・SaaS・独自開発など異なる作り方の会社を混ぜます。送る前に、秘密保持契約を結ぶかどうかと、提案書の作成費用の扱い、提案書や見積書を選定以外の目的に使わないことを決め、RFPに書いておきます。提案先が安心して詳しい情報を出せるようにするためです。 - 質問を受け付け、回答を全社に共有する
1社からの質問への回答は全社に同じ内容で返します。前提をそろえるためです。質問の多い項目は、RFPの書き方が曖昧だった部分です。回答で前提を補い、必要なら見積もりの様式も修正して全社に送り直します。 - 自社の業務シナリオでデモをしてもらう
見積→受注→出荷→請求など、実際の業務の流れと例外処理を2〜3パターン渡し、その場で操作してもらいます。 - 前提をそろえて採点し、契約条件を詰める
見落としやすい7点を確認して対象外を足し戻したうえで採点します。上位の会社と、フェーズごとの契約、追加要望の費用の決め方、保守の範囲を詰めます。
デモで渡す業務シナリオの例
デモは、製品の機能紹介ではなく、自社の業務が回るかを確かめる場です。シナリオは、通常の流れ1つと、例外処理を含む流れ1〜2つを用意し、全社に同じ内容で渡します。
| シナリオ | 流れ | 確かめること |
|---|---|---|
| A：通常の受注 | 見積作成→受注変換→在庫引当→出荷指示→売上計上→月末締めの請求書発行 | 入力の回数と画面の数。見積から請求まで再入力がないか |
| B：例外のある受注 | 取引先別の掛率を適用し、分納（2回に分けて出荷）し、途中で1明細を返品 | 掛率の持ち方、分納と返品の残高の扱い、請求書への反映 |
| C：月末の締め | 20日締めと末締めの取引先が混在する状態で請求と売掛残高を確定し、会計へ仕訳を渡す | 締め日別の請求、入金消込、会計への連携の手順 |
※説明用の例です。自社で件数が多い取引と、手作業で処理している例外を選んでシナリオにします。
デモでは、評価者が見るだけでなく、キーユーザー（実際に入力する担当者）にも同席してもらい、操作の手数や画面の見やすさを評価に加えます。その場で操作できなかった部分は「後日回答」で終わらせず、回答の期限を決めて全社分を並べて比べます。
スケジュール例
| 週 | やること | 発注側の担当 |
|---|---|---|
| 1週目 | RFP送付、提案意思の確認 | プロジェクト責任者 |
| 2週目 | 質問の受付締切、全社への回答 | プロジェクト責任者・各業務の決裁者 |
| 4〜5週目 | 提案書・見積書の提出締切 | ― |
| 6週目 | 業務シナリオでのデモ（1社2〜3時間） | 評価者3人以上＋キーユーザー |
| 7週目 | 前提の確認、対象外の足し戻し、採点 | 評価者 |
| 8週目 | 上位社との契約条件の調整、発注先の決定 | 経営・プロジェクト責任者 |
※説明用の例です。提案の準備期間は2〜3週間あると、見積もりの精度がそろいやすくなります。
RFPを送る前のチェックリスト
- 目的と、成功を測る数字が書かれている
- 対象範囲と対象外が明記されている
- 機能要件一覧に優先度（必須／あれば／後回し）がついている
- データ件数・利用人数・連携先など、見積もりに必要な現状の数字がある
- 復旧時間・バックアップ・データ保存期間が数字で書かれている
- 要件一覧の行ごとに対応方法を記入してもらう様式になっている
- 見積もりの様式が費目×年（5年分）で、対象外・前提条件・発注側作業の欄がある
- 実際の担当者の経験と関与の割合を記載してもらうようになっている
- 追加要望の費用の決め方、成果物の扱い、保守の範囲を提案してもらうようになっている
- 業務シナリオでのデモを選定の進め方に入れている
- 評価項目と重みを、提案を受け取る前に決めている
よくある質問
RFPは何社に出せばよいですか？
比べる手間と比較の幅を考えると、3〜5社が扱いやすい数です。数を増やすより、パッケージ・SaaS・独自開発のように作り方の異なる会社を含めるほうが、比較の意味が大きくなります。作り方の違いは中小企業のERPの選び方でも解説しています。
要件定義書がなくてもRFPは出せますか？
出せますが、受け取れるのは概算の見積もりになります。その場合は、要件定義をフェーズとして切り出して依頼し、要件定義の完了後に開発以降を再見積もりすることをRFPの条件に入れてください。
RFPを作るのにどのくらいの期間がかかりますか？
要件定義書ができている場合、製品選定・RFPのフェーズ全体（RFP作成、提案受付、デモ、評価、契約条件の整理）で1〜2か月が目安です。提案の準備期間と質問の受付期間を十分に取ると、提案の質がそろいやすくなります。
提案の点数が僅差のときはどう決めればよいですか？
重みの大きい「業務への適合」と、業務シナリオでのデモの結果を優先して見直します。それでも差がつかない場合は、実際の担当者との面談で、例外処理への対応方法を具体的に聞いてみると違いが見えます。
RFPの作成を外部に頼むことはできますか？
できます。章立てや見積もりの様式づくり、評価表の作成、提案の比較は、外部の支援者に任せられる作業です。ただし、目的・優先順位・対象外を決めるのは発注側です。提案する立場の会社にRFPの作成を頼むと、その会社に有利な条件になりやすいため、作成を頼む相手と提案を依頼する相手は分けてください。
この記事で紹介した12章のRFPひな形、見積もりの様式、提案評価の重みづけシートを、そのまま使える形にまとめた資料です。
資料をダウンロードする（無料）まとめ
RFPの書き方の要点は、要件定義で決めた「実現すること・しないこと」に、提案と見積もりの条件を足すことです。現状の数字と非機能要件を数字で書き、要件一覧の行ごとに対応方法を書いてもらい、見積もりを費目×年の様式で出してもらい、実際の担当者の経験まで確認する。評価の項目と重みを先に決めておけば、印象ではなく自社の目的に沿って提案を選べます。
要件定義がまだでRFPを書けるか分からない、届いた提案をどう比べればよいか分からないという方は、無料診断で現状を整理し、次に決めるべきことをお伝えします。
RFPの章立て、見積もり前提の比較表、重みづけシート
資料をダウンロードする
