業務システムを開発会社に頼もうとして3社に声をかけたら、見積もりの金額が何倍も違っていて、どれが妥当なのか比べようがない。発注のときによく起きることです。理由のひとつは、頼む側が「何を、どこまで、どんな条件で作ってほしいか」を書面で渡していないことです。この記事では、その書面である提案依頼書（RFP）について、中小企業が業務システムを発注するときに入れる10の項目、書き方の例、RFI（情報提供依頼書）や見積依頼との違い、届いた提案の比べ方、よくある失敗を順に紹介します。
この記事の結論
- 見積もりがそろわないのは、何を・どこまで・どんな条件で作るかを書面で渡していないことが理由のひとつです。RFPはその食い違いを発注の入口で減らす書面で、あとで契約の中身を決める土台にもなります。
- RFPには、背景・目的・範囲・現状の業務・必要な機能・非機能の条件・予算・スケジュール・提案の形式・評価のしかたの10項目を入れます。
- いちばん効くのは現状の業務です。「今と同じでよい」とは書かず、注文が入ってから出荷までをだれが何をしているかの順に書き出します。
- 条件はできるだけ数字で書き、機能は「必須」と「あれば望ましい」に分け、予算の上限か幅も示すと、比べやすい提案が集まります。
- 何を重く見て選ぶかは、提案が届く前に決めてRFPに書いておきます。費用は使い始めてからの数年分を合計して比べます。
見積もりがそろわないのは、依頼の書き方が原因のことが多い
口頭で「受注の管理をシステムにしたい」と伝えると、聞いた会社はそれぞれの想像で範囲を決めて見積もります。ある会社は表計算ソフトの置き換え程度と考え、別の会社は在庫や請求までつながる仕組みを考えます。金額がそろわないのは当然です。
IPA（情報処理推進機構）が発注側と受注側の双方に向けてまとめた「超上流から攻めるIT化の原理原則17ヶ条」には、「依頼する範囲、内容を漏れなく洗い出し、提示する」という行動の目安があり、「表現されない要件はシステムとして実現されない」とも書かれています[1]。ここでいう要件とは、システムが満たすべき条件のことです。頼む側が書かなかったことは、作られないか、相手の想像で作られます。
話がかみ合わないまま開発が進むと、完成してから「頼んだものと違う」となりがちです。要望が途中で形を変えていく仕組みはシステム開発の「伝言ゲーム」の記事でくわしく書いています。RFPは、この食い違いを発注の入口で減らすための道具です。
🛠 この記事のような業務システムの課題は、ご相談ください。今の業務の流れを伺い、どこをシステムにするかから一緒に決めます（相談は無料）。
Overview
RFPとは：開発会社に提案と見積もりを頼むための依頼書
RFPは「Request for Proposal」の頭文字で、日本語では提案依頼書と呼びます。発注する会社が、候補の開発会社に「この条件で、どう作るかの提案と見積もりを出してください」と頼むための書面です。作るのは発注する側です。
RFPは提案をもらうためだけの紙ではありません。IPAが公開している「情報システム・モデル取引・契約書」の契約書ひな型では、個別の業務に入る前に、発注者が示したRFPと、受注者が出した提案書・見積書を基礎にして、作業の範囲や契約の形、納期、役割分担、代金などを決めて個別契約を結ぶ、という流れが書かれています[2][3]。つまり、RFPに書いたことは、あとで契約の中身を決める土台になります。
契約の形（請負か準委任か）の違いは受託開発と請負の違いの記事で整理しています。
Difference
RFI・見積依頼（RFQ）との違い
RFPとよく並べて出てくるのが、RFI（Request for Information・情報提供依頼書）と、RFQ（Request for Quotation・見積依頼書）です。どれも開発会社に出す書面ですが、頼む中身が違います。
| 書面 | 頼むこと | 出す時期 | 中小企業での使いどころ |
|---|---|---|---|
| RFI（情報提供依頼書） | 会社の得意分野、似た開発の経験、使える製品や技術、おおよその費用感 | 候補を探す最初の段階 | 何ができるのか見当がつかないとき、候補を絞るために使う |
| RFP（提案依頼書） | こちらの目的と条件に対する、作り方・体制・日程・費用の提案 | 候補を数社に絞ったあと | 業務システムの発注先を選ぶときの中心になる書面 |
| RFQ（見積依頼書） | 決まった仕様に対する金額と納期 | 作るものがほぼ決まったあと | 既製品の導入や、仕様が固まった追加開発の見積もり |
IPAがモデル取引・契約書を紹介した講演資料では、契約の進め方の例として、RFIのあとにRFPを出して試算の見積もりを受け、要件が固まった段階で改めてRFPを出して概算、さらに確定の見積もりへ進む流れが示されています[2]。17ヶ条にも「多段階の見積もりは双方のリスクを低減する」とあります[1]。同じ資料では、多段階とは頼む先を毎回変えることではなく、中身の固まり具合に合わせて見積もりの精度を上げていくこと、と説明されています[2]。
中小企業の業務システムなら、正式なRFIを省き、数社と短く話して候補を絞ってからRFPを出す進め方でも十分なことが多いです。大事なのは、最初の見積もりはあくまで目安で、要件が決まったあとに見積もり直すものだと、発注側も分かっておくことです。要件を決める工程が開発全体のどこにあり、その工程で発注する側が何をするのかはシステム開発の流れを7つの工程で整理した記事で説明しています。
Items
RFPに入れる10の項目と書き方の例
業務システムの発注で、RFPに入れておきたい項目を10個にまとめました。決まった書式はないので、この順番で見出しを立てて書けば、そのまま提案依頼書のテンプレートとして使えます。
| 項目 | 書くこと | 書き方の例 |
|---|---|---|
| 1. 背景 | なぜ今システムが必要になったか | 受注が月300件を超え、電話とFAXの注文を手で表計算ソフトに入れる作業が追いつかない |
| 2. 目的 | 導入して何をどう変えたいか（できれば数字） | 受注の入力にかかる時間を半分にし、入力ミスによる誤出荷をなくす |
| 3. 範囲 | 頼む業務と、今回は頼まない業務 | 受注の登録から出荷指示までが対象。請求と会計は今の会計ソフトのまま使う |
| 4. 現状の業務 | 今の流れ、使っている道具、件数、担当者 | 注文はFAX6割・電話3割・メール1割。担当2名が表計算ソフトに入力し、倉庫へ紙で出荷指示 |
| 5. 必要な機能 | 欲しい機能を「必須」と「あれば望ましい」に分けて書く | 必須：受注の登録、出荷指示書の印刷、在庫の引き当て。望ましい：取引先が自分で注文できる画面 |
| 6. 非機能の条件 | 使う人数、速さ、止まってよい時間、守り方など | 同時に使うのは最大10人。平日8時から19時に使えること。社外からはスマートフォンで閲覧のみ |
| 7. 予算 | 上限か、おおよその幅 | 初期費用は600万円まで、月々の運用費は10万円以内を想定 |
| 8. スケジュール | 使い始めたい時期と、その理由 | 繁忙期の前の来年8月から使い始めたい |
| 9. 提案の形式 | 出してほしい書類、締め切り、質問の受け方 | 提案書と見積書（内訳つき）を11月30日までにメールで。質問は11月15日まで受け付け、回答は全社に共有 |
| 10. 評価のしかた | 何を重く見て選ぶか | 業務の理解、費用、体制と進め方、使い始めたあとの支え方、日程の5点で比べる（重みは下の表） |
表の例の数字は、書き方を示すための架空のものです。このほか、会社の概要、担当窓口、秘密の扱い（提案のために渡す資料を他に使わないこと）も最初に書いておくと、社内の帳票や数字を安心して渡せます。
「現状の業務」は手を抜かない
いちばん書き漏れやすく、いちばん効くのが現状の業務です。17ヶ条には「『今と同じ』という要件定義はありえない」とあり、今ある機能だけを見るのではなく、使われ方まで調べて要件にするよう書かれています[1]。「今の表計算ソフトと同じことができればよい」と書くと、表の外で担当者がしている確認や電話のやりとりが抜け落ちます。1件の注文が入ってから出荷されるまでを、だれが、何を見て、何をしているかの順に書き出してください。実際に使っている帳票や画面の写し（取引先名などは消したもの）を添えると、相手の理解が大きく変わります。
非機能の条件は、IPAの区分を目次にする
非機能とは、機能そのもの以外の条件のことで、速さや止まりにくさ、守り方などを指します。IPAの「非機能要求グレード」は、発注者と開発者の認識の行き違いを防ぐための道具で、非機能の条件を6つの大きな項目に分けて段階で示しています[4]。6つは、可用性（止まらずに使えるか）、性能・拡張性（速さと、件数が増えたときの余裕）、運用・保守性（日々の運用と直しやすさ）、移行性（今のデータや仕組みからの移し替え）、セキュリティ、システム環境・エコロジー（置き場所や守るべき規格などの前提）です[4]。中小企業のRFPで全部を細かく決める必要はありませんが、この6つを見出しにして「分かること」だけでも書くと、抜けが減ります。
書くときは、できるだけ数字にします。17ヶ条にも「数値化されない要件は人によって基準が異なる」とあります[1]。「速く動くこと」ではなく「受注の一覧が3秒以内に出ること」のように書けば、提案どうしを同じ物差しで比べられます。目的も同じです。IPAの「ユーザのための要件定義ガイド 第2版」は、要求を一覧にするとき、目的にあたるものには測る物差し、今の値、目標の値、いつまでに達成するかを書くよう勧めています[5]。
予算は書いたほうが提案がそろいやすい
予算を書くと値段を合わせてくるのでは、と心配する方もいます。ただ、予算が分からないと、相手は大きめの案と小さめの案のどちらで出すかを想像で決めるしかありません。上限か幅を書き、「この範囲で、どこまでできるかを示してほしい」と頼むほうが、比べやすい提案が集まります。費用の考え方は業務システム開発の費用相場の記事も参考になります。
Steps
RFPを作って出すまでの順番
- 社内で困りごとを集める：現場の担当者、管理する人、決める立場の人に、それぞれ何に困っていて何を変えたいかを聞きます。17ヶ条には、利害関係者の合意を得ないまま次の工程に入らない、という原則があります[1]。
- 10の項目を埋める：分からない所は空けずに「未定。提案の中で選択肢を示してほしい」と書きます。分からないことを分からないと書くのも、大切な情報です。
- 候補を絞る：知り合いの紹介や事例を見て数社に絞ります。必要ならRFIや短い面談で、得意分野が合うかを確かめます。依頼する前の確認の点は見積もり依頼前のチェックポイントの記事にまとめています。
- RFPを渡して説明する：書面を送るだけでなく、短い説明の場を設けると誤解が減ります。受けた質問と回答は全社に同じ内容で共有し、条件をそろえます。
- 提案を比べて選ぶ：決めておいた物差しで点を付け、気になる会社とは追加で話します。
Evaluation
届いた提案の比べ方
提案が届いてから物差しを考えると、説明の上手な会社や、いちばん安い会社に引っぱられがちです。RFPを出す前に、何をどのくらい重く見るかを決めて、RFPにも書いておきます。たとえば次のような表を用意します。重みは一例です。
| 見る点 | 確かめること | 重み（例） |
|---|---|---|
| 業務の理解 | 現状の業務を読んだうえで、困りごとに答えているか。こちらが書いていない問題点に気づいているか | 30 |
| 費用 | 内訳が分かるか。初期費用だけでなく、月々の費用や数年後の改修も示しているか | 25 |
| 体制と進め方 | だれが担当するか。発注側に何をしてほしいかが書かれているか | 20 |
| 使い始めたあと | 問い合わせ先、直すときの手順と費用、データの持ち出し方 | 15 |
| 日程 | 希望の時期に間に合うか。無理のある日程になっていないか | 10 |
17ヶ条には、システム化の費用はソフトウェア開発だけではないこと、運用・保守も見すえた計画を作ることも書かれています[1]。開発費が安くても、毎月の費用や改修費が高ければ、数年で逆転することがあります。見積もりの比べ方は、使い始めてからの数年分を合計して見るのが安全です。
Pitfalls
RFPでよくある失敗
機能の一覧だけで、目的が書かれていない。欲しい画面を並べただけだと、相手はその通りに作る見積もりしか出せません。目的が分かれば、「その目的なら既製品の設定で足ります」といった、こちらが思いつかない提案が出てきます。
「今と同じことができればよい」と書く。先に書いたとおり、今のやり方には紙や表に表れない作業が隠れています。そのまま渡すと、開発が始まってから要件が増え、費用と期間がふくらみます。
必須と望ましいを分けていない。全部が必須に見えると、見積もりは高くなり、予算に収めるための削り方も相手任せになります。17ヶ条にも、要件に優先順位を付けることが挙げられています[1]。要件定義ガイドでも、実現の手段にあたる要求には優先度を書き、要求がふくらまないよう、採用しなかったものも分かるようにしておくことが挙げられています[5]。
会社ごとに違う説明をしてしまう。電話で聞かれた質問に、それぞれ別の答えを返すと、前提の違う提案が集まります。質問と回答は文書にして全社に配ります。
出したあとの条件の変更を、口頭で済ませる。モデル取引・契約書の考え方では、RFPは契約の中身を決める土台になります[2]。出したあとに条件を変えたくなったら、その都度書面にして、全社に同じ内容で伝えてください。
FAQ
提案依頼書（RFP）についてよくある質問
提案依頼書のテンプレートはありますか？
決まった書式はありません。この記事の10の項目（背景、目的、範囲、現状の業務、必要な機能、非機能の条件、予算、スケジュール、提案の形式、評価のしかた）を見出しにして書けば、そのまま使えます。非機能の条件は、IPAの「非機能要求グレード」の6つの区分を目次にすると抜けが減ります。
RFPとRFIはどう違いますか？
RFIは、候補の会社の得意分野や使える技術などの情報を集めるための依頼で、候補を探す段階で出します。RFPは、こちらの目的と条件を示して、作り方と費用の提案を頼む書面で、候補を絞ったあとに出します。
小さな開発でもRFPは必要ですか？
何十ページもの書面は要りません。ただ、背景・目的・範囲・現状の業務・予算・使い始めたい時期の6つだけでもA4数枚にまとめて渡すと、口頭で頼むより見積もりがそろいやすくなります。
RFPを書く時間が社内にない場合はどうすればよいですか？
RFPの下書きづくりそのものを外部に手伝ってもらう方法があります。その場合も、目的と現状の業務を話すのは発注する側の役目です。17ヶ条にも「要件定義は発注者の責任である」とあります[1]。
Sources
参考にした資料
- IPA（情報処理推進機構）「超上流から攻めるIT化の原理原則17ヶ条」一覧表（SEC BOOKS『経営者が参画する要求品質の確保 第2版』別冊・2006年5月）
- IPA（情報処理推進機構）講演資料「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月）
- IPA（情報処理推進機構）「情報システム・モデル取引・契約書（第二版）」（2020年12月公開・2026年9月更新）
- IPA（情報処理推進機構）「非機能要求グレード2018」（2018年4月改訂・2023年8月ページ更新）
- IPA（情報処理推進機構）「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」7.3.4 要求一覧（2019年12月）
提案依頼書（RFP）は、開発会社に提案と見積もりを頼むための書面で、あとで契約の中身を決める土台にもなります。背景、目的、範囲、現状の業務、必要な機能、非機能の条件、予算、スケジュール、提案の形式、評価のしかたの10項目を書き、とくに現状の業務と数字で書ける条件を丁寧に埋めると、比べやすい提案が集まります。RFIは情報集め、RFQは決まった仕様の見積もりと、役割を分けて使ってください。当社では、今の業務の流れに合わせた業務システムづくりと、使い始めたあとの保守や機能の追加をご相談いただけます。
