提案依頼書（RFP）を書く前に決めること：見積もる側が迷わず答えられ、3社を比べやすい依頼の出し方（ひな形つき）

提案依頼書（RFP）のひな形を探すと、章立てのそろったものがたくさん見つかります。「はじめに」「プロジェクトの概要」「依頼の内容」「日程」「評価の基準」。章立てを埋めていけば、それらしい文書はできあがります。

ところが、見積もる側から見ると、そうしてできた依頼書には共通の空白があることが多いのです。背景や目的は丁寧に書かれているのに、データの件数、使う人の数、やらないこと、期限の理由が書いていない。見積もる側は、その空白を自分たちの前提で埋めて金額を出します。前提の置き方は会社ごとに違うので、届く見積もりもばらばらになります。

この記事は、はじめて提案依頼書を書いて開発会社に見積もりを頼む、中小企業の担当者に向けて書いています。次のことを順にまとめます。

• 見積もる側が、提案依頼書のどこを読み、どこで迷うか
• 書き始める前に決めておく8つのこと
• まだ決まっていないときの、情報提供依頼（RFI）の使い方
• 提案依頼書の章立てと、書くときのコツ

章ごとのサンプル文は、SucSak の「RFPテンプレートの項目は？章別のサンプルと書き方を解説」にまとまっています。作るものの中身（目的、業務の流れ、使う人など）を社内でまとめる方法は「要件定義とは：開発会社に頼む前に、社内でまとめておくこと」で書きました。この記事は、その間にある「依頼の出し方」を決める話です。

結論：書く前に「何を頼み、どう選ぶか」を決める

先に結論を書きます。

• 提案依頼書を書く前に、何を頼むのか、どの会社に何社頼むか、予算を伝えるか、どこまで書いてどこを提案してもらうか、回答の様式、選び方、質問の受け方と日程、作ったものの権利の希望の8つを決めます
• 見積もる側が迷うのは、件数などの数字、やらないこと、期限の理由、決める人が書いていない所です。ここを埋めるだけで、見積もりの差は小さくなります
• 分からない所は空けずに「未定（提案してほしい）」と書きます。空いていると、見積もる側は自分の前提で埋めます
• 要件がまだ決まっていない段階なら、作るところの見積もりを頼む前に、要件定義の支援を頼むか、情報提供依頼（RFI）で目安を集めます

見積もる側は、提案依頼書のどこを読むか

提案依頼書を受け取ったとき、見積もる側のクリーヴァがまず読むのは、次の順です。

1. 何のためのシステムか：困っていることと、うまくいったと言える数字。目的が分かると、どの機能が本当に必須かを判断できます
2. 範囲：入れたい機能と、やらないこと。やらないことが書いてあると、範囲の読み方がそろいます
3. 数字：使う人の数、データの件数、1日の件数。作る量とテストの量が、ここで決まります
4. 条件：使う時間、端末、セキュリティの決まり、つなぐシステム
5. 日程と、その理由：使い始めたい時期と、それが動かせるかどうか
6. 誰が決めるか：窓口の人と、最後に決める人。打ち合わせの回数と進め方が変わります

このうち、書かれていないことが多いのは3、5、6と、2の「やらないこと」です。目的や背景はよく書かれているのに、見積もりに直接効く数字が空いている。見積もる側にとって一番困るのはここです。

「今と同じ」「すぐに」は、見積もれない

IPA の「実務に活かすIT化の原理原則17ヶ条」は、原理原則の13番目に「数値化されない要件は人によって基準が異なる」を挙げています。「今と同じように使えること」「画面がすぐに表示されること」と書かれても、見積もる側は「今」がどうなっているかを知りません。「1日の受付は約15件、ピークの月は約25件」「一覧の表示は3秒以内」のように、おおよその数字で書いてもらえると、前提を置かずに済みます。

書き始める前に決めておく8つのこと

提案依頼書の中身を書く前に、社内で決めておくことがあります。どれも、決めずに書き始めると、書きながら迷うか、各社への説明がぶれる項目です。

1. 何を頼むのか：要件定義の支援からか、作るところからか

最初に決めるのは、今回の依頼で何を頼むかです。IPA と経済産業省の「情報システム・モデル取引・契約書〈第二版〉」の解説は、要件定義の段階では、発注する側が要件定義の支援を準委任の契約で頼み、できた要件定義書をもとに提案依頼書を示して「概算見積」を受ける、という流れを示しています。

つまり、要件定義書がまだない状態で、作るところまでの見積もりを頼むのは、本来より一段早い依頼です。手元に要件がまとまっていないなら、まず要件定義の支援を頼む依頼にするか、要件定義と作るところを分けて見積もってもらう依頼にします。17ヶ条の9番目は「要件定義は発注者の責任である」で、開発会社が支援する場合でも、要件定義の成果物の責任は発注する側にあるとしています。

2. どの会社に、何社頼むか

社内で比べる手間を考えると、3社前後が扱いやすい数です。社数より大事なのは、選ぶ会社の条件をそろえることです。モデル契約の別紙は、提案依頼書に書く手続きの1つとして、参加資格の条件（認証の有無、開発の実績、近くに支援の体制があるかなど）を挙げています。似た業務の経験、保守まで頼めるか、会社の規模など、自社にとって外せない条件を先に決めておきます。

3. 予算を伝えるか

伝えるか伝えないかに、正解はありません。伝えると、各社が同じ枠の中で、何を入れて何を外すかを提案するので、比べやすくなります。伝えない場合は、各社が自分の読みで範囲を決めるため、金額の差が広がります。

見積もる側から言うと、予算の枠が分かっていると、「この枠なら必須の6つを先に作り、残りは次の段階に回す」といった段階の分け方を提案できます。どちらにするかを決め、全社に同じように扱います。

4. どこまで書き、どこを提案してもらうか

全部を決めてから出す必要はありません。決まっていることは書き、決まっていないことは「未定（提案してほしい）」と書きます。たとえば、契約の形、作り方（既製のサービスを使うか、個別に作るか）、段階の分け方は、提案してもらってよい項目です。

ただし、モデル契約の解説は、開発会社が責任を持って見積もりを出すのに十分な要件として、機能の要件だけでなく、機能以外の要件（非機能要件）も明らかにする必要があるとしています。使う人数、使う時間、止まってよい時間、セキュリティの決まりは、おおよそでも書いておきます。

5. 回答の様式

各社の答えを同じ並びにするための様式を、依頼と一緒に渡します。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」の実践ガイドブックは、同じ粒度で見積もりを比べられるよう、発注する側が見積もりの様式を指定して提出を求めるのが望ましいとしています。また、内訳を「一式○○円」とせず、妥当性を確かめられる粒度で書いてもらうことも求めています。

様式に入れるのは、費目ごとの金額、月額、そして前提です。前提の書き方と比べ方は「開発の見積もりは、なぜ会社ごとに違うのか」でくわしく書いています。

6. 選び方

何を見て選ぶかを、依頼を出す前に決めます。届いてから考えると、どうしても金額に引っぱられます。IPA の「ユーザのための要件定義ガイド 第2版」は、「一番安いから」といった理由でベンダーを選んでしまう例を挙げ、選ぶための明確な基準を決めておく必要があるとしています。

モデル契約の別紙も、提案依頼書に、ベンダーを選ぶ組織や決めるまでの流れを、分かる範囲で書くこととしています。たとえば次のような観点を、重みと一緒に決めます。

重みは、会社の事情で決めます。たとえば、社内にシステムの担当がいない会社なら「進め方」と「作った後」を重く、予算の上限が固い会社なら「前提の明確さ」と「金額」を重く見ます。デジタル庁のガイドラインも、事業者の評価の項目として、業務の理解度、要件定義の理解度、計画の能力、管理の能力、技術の能力、実績、組織としての対応力などを並べています。国の調達のための項目ですが、何を見るかを考える手がかりになります。

決めた観点は、依頼書の「選ぶときに見ること」に書いておきます。各社は、何を重く見られるかが分かると、その点を厚く提案してきます。金額だけで決めないことを、先に伝えておく意味もあります。

7. 質問の受け方と日程

質問をどう受け、どう返すかを決めます。ある会社の質問への答えは、ほかの会社にも同じように返します。1社だけが知っている前提があると、比べられなくなるからです。

日程は、質問の受付の期限、回答の期限、説明の場、選ぶ時期、結果を知らせる日を決めます。モデル契約の別紙も、説明会の日程、提案書の提出の期限、決める時期などを明示することを挙げています。回答までの期間が短すぎると、見積もる側は質問する時間がとれず、前提を多めに置くしかなくなります。依頼を出してから回答まで、3〜4週間はみておきます。

8. 作ったものの権利と、作った後のこと

ソースコードの著作権を自社に移したいか、作った後の保守も同じ会社に頼みたいか、将来ほかの会社にも直してもらえる形にしたいかを決めます。モデル契約の解説は、発注する側が著作権の譲り受けを希望する場合、事前に提案依頼書でその旨を明らかにすることを求めています。後から言い出すと、見積もりの前提が変わります。くわしくは「ソースコードの著作権は誰のものか」で書いています。

まだ決まっていないときは、情報提供依頼（RFI）から

作りたいものの方向は見えているが、作り方も費用も見当がつかない。そういう段階で提案依頼書を出すと、各社の前提がばらばらになります。その前に、情報提供依頼（RFI）で情報を集める方法があります。

デジタル庁のガイドラインは、要件定義の準備として、必要に応じて RFI を行うとし、説明書に書く項目として、調達の概要、その時点の検討の内容や要件の案、資料の提供を求める内容、提出の期限や方法を挙げています。求める内容には、実現の方法、必要な経費や要員の見込み、要件の案への修正の提案（既製のサービスを使うか、個別に作るか、進め方など）が含まれます。

民間の小さな発注なら、もっと簡単で構いません。「こういうことをしたい。どんな作り方があり、費用はどのくらいの幅か、教えてほしい」と、2〜3社に聞く形です。IPA の要件定義ガイドは、概算でも「見積り」として頼むと、開発会社に公式な見積書のような印象を与え、時間がかかったり、余分なリスクが積まれたりしかねないとして、目安であることとスピードを優先することを前提として伝える方法を挙げています。RFI で聞くときも、「目安でよい」とはっきり書くと、早く、率直な答えが返ってきやすくなります。

要件定義の支援を頼むときの依頼書

8つのことの1番目で「要件定義の支援から頼む」と決めた場合、依頼書の中身は作るところの依頼とは少し変わります。作るものがまだ決まっていないので、機能の一覧で見積もってもらうことはできません。代わりに、次のことを書きます。

• 要件定義で決めたいこと：作る範囲、やらないこと、画面のたたき台、作るところの見積もりなど、終わったときに手元にほしいもの
• 期間と、社内で出られる人：何週間で終えたいか。業務を知っている人が、週に何時間打ち合わせに出られるか
• 今ある材料：業務の流れのメモ、今の Excel や帳票、困りごとの数字
• 終わった後の進め方：作るところを同じ会社に頼む前提か、改めて各社に依頼するか

モデル契約の考え方では、要件定義の支援は準委任の契約で、作るところは請負の契約、と分けるのが基本です。準委任の見積もりは、作るものの量ではなく、期間と関わる人で決まります。そのため、比べるときは金額だけでなく、何回の打ち合わせで、どんな成果物が手元に残るかを見ます。クリーヴァでも、最初の段階で業務を整理して作る範囲とやらないことを決め、稟議に使える見積もりを出してから、作る段階に進む形をとっています。

小さな依頼なら、どこまで簡単にしてよいか

社内の小さな管理ツールのように、初期費用が数百万円までの依頼で、11章すべてを埋める必要はありません。少なくとも次の6つが書いてあれば、見積もる側は前提を大きく置かずに見積もれます。

1. 目的と、うまくいったと言える数字
2. 使う人と人数、使う場面（パソコンかスマホか）
3. 機能の一覧（優先度つき）と、やらないこと
4. データの件数と、移すデータの有無
5. 使い始めたい時期と、その理由
6. 回答の期限と、回答の様式

逆に、どれほど小さな依頼でも、この6つが空いていると、見積もりは各社の想像の比べ合いになります。A4で2〜3枚の依頼書と、機能の一覧、回答の様式の3点がそろっていれば、小さな依頼としては十分です。

提案依頼書の章立て

ここまでを決めたら、提案依頼書を書きます。この記事のひな形は、次の11の章でできています。モデル契約の別紙が挙げる記載項目（システムの概要、提案依頼の手続き、依頼の事項）を、中小企業の依頼に合わせてまとめたものです。

4章の「使い方の条件」は、IPA の「非機能要求グレード」が挙げる6つの大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）のうち、中小企業の依頼で最低限書いておきたいものを、ふだんの言葉にしたものです。

書くときのコツ

最後に、書くときのコツを4つ挙げます。

• 数字で書く：「多い」「すぐに」ではなく、「月約300件」「3秒以内」。おおよそで構いません
• やらないことを書く：範囲の外を書くと、各社の前提がそろいます
• 現物を添える：今使っている Excel、紙の帳票、画面の写真。説明の文章より、見積もる側には伝わります
• 空けずに「未定」と書く：空いている欄は、見積もる側が自分の前提で埋めます。「未定（提案してほしい）」と書けば、提案の比べどころになります

見積もる側からのお願いを1つ足すと、窓口の人に業務を知っている人をつないでもらえると助かります。依頼書で分からない所を、短い打ち合わせで聞ければ、前提を置く量はさらに減ります。

見積もりが割れやすい書き方と、直し方

見積もる側として依頼書を読んでいると、各社の金額が割れそうだと分かる書き方があります。よく見かける5つを、直し方と一緒に挙げます。

どれも、書いた人の頭の中では答えが決まっていることです。見積もる側にはその答えが見えないので、各社が別々の答えを置きます。

4つ目の「セキュリティは万全に」については、モデル契約の別紙も、発注する側のセキュリティの基本方針やほかのシステムの環境を示さなければ、セキュリティを確保できないという例を挙げています。社内に規程がなければ、「規程はない。必要な対策を提案してほしい」と書けば十分です。

依頼を出す前の社内の確認

書き上げた依頼書は、出す前に社内で読み合わせます。確かめるのは次の3つです。

1. 業務を知っている人が読んで、今の流れと違う所がないか：書いた人と、実際に業務を回している人の認識がずれていることがあります
2. 決める人が、目的と予算の枠、選び方に同意しているか：後から決める人が「そんなつもりではなかった」となると、各社に出し直すことになります
3. 書いていない数字がないか：件数、人数、期限。ここが空いていたら、おおよそで埋めます

モデル契約の別紙には、依頼書のどの部分を業務の部門とシステムの部門がそれぞれ受け持つかを示した表も付いています。中小企業ではシステムの担当がいないことも多いので、少なくとも、業務の部分は業務を回している人が、目的と予算は決める人が目を通す形にします。

送るときに添えるもの

依頼書と一緒に、次のものを添えて送ります。

• 機能の一覧：優先度と、今のやり方を書いたもの
• 回答の様式：費目ごとの金額、月額、前提の問いを並べたもの
• 現物：今使っている Excel、紙の帳票、画面の写真。個人情報は消すか、架空の値に置き換えます
• 秘密保持の扱い：依頼書を検討の目的以外に使わないこと。必要なら先に秘密保持の約束を結びます

届いた提案書の読み比べ方は、SucSak の「システム開発の提案書はどこを見る？届いた提案の読み方を解説」にまとまっています。見積もりの金額の比べ方は「開発の見積もりは、なぜ会社ごとに違うのか」で書いています。

おわりに

提案依頼書は、章立てを埋める前に、何を頼み、どう選ぶかを決めるところから始まります。見積もる側が迷うのは、数字、やらないこと、期限の理由、決める人の4つです。ここが埋まっていれば、届く見積もりの前提はそろい、3社を同じ物差しで比べられます。

この記事で紹介した提案依頼書の11の章、機能の一覧、回答の様式は、「開発の発注準備シート」の Excel にそのまま入っています。架空の設備会社の記入例つきです。

開発の発注準備シートの Excel をダウンロードする

登録は要りません。依頼を出す前の準備から、見積もりの比べ方、契約の前に確かめることまでを順番にまとめた PDF「開発の発注 準備ガイド」も用意しています。はじめて開発会社に相談するときの準備は「開発会社に初めて相談する前に」で説明しています。提案依頼書づくりのご相談は、クリーヴァでもお受けしています。

出典（2026年11月11日に確認）

• IPA・経済産業省「情報システム・モデル取引・契約書〈第二版〉」（2020年12月、2025年4月更新）
• IPA「ユーザのための要件定義ガイド 第2版」（2019年12月）
• IPA「実務に活かすIT化の原理原則17ヶ条」（2010年10月）
• デジタル庁「デジタル・ガバメント推進標準ガイドライン」と実践ガイドブック（2026年6月12日版）
• IPA「非機能要求グレード2018」（2018年4月）