システム開発会社への依頼で失敗しないRFPの書き方

01はじめに｜RFPは完璧な仕様書ではありません

要点： RFPが書けずに止まってしまう会社は少なくありません。原因は、最初から完成した仕様書を作ろうとしてしまうことにあります。RFPは仕様書ではなく、困っていることを伝えて提案を集めるための文書です。空欄があっても構いません。

「システムを作りたいけれど、何をどう伝えればいいのか分からない」。ご相談の場でいちばん多いのがこの言葉です。数社に声をかけたものの、返ってきた見積りが300万円と1,200万円で、比べようがなかった。そんな話も珍しくありません。

差が開く理由は、たいてい発注側の資料にあります。伝えた内容が会社ごとに違えば、各社は自分の解釈で範囲を決めます。片方は最小構成、もう片方はフル装備。金額が4倍離れます。

そこで使うのがRFP（提案依頼書）です。同じ前提を全社に渡し、同じ土俵で提案してもらうための文書です。書いているのは2000年創業のWeb制作・システム開発会社ZenWeb Japanです。開発の進め方そのものはWebシステム開発サービスのページもあわせてご覧ください。

全体像は動画でも押さえられます。先に見ておくと、このあとの各項目が入りやすくなります。

02提案依頼書とは何か｜要件定義書との違い

要点： 提案依頼書（RFP）は、発注先が決まる前に発注側が書く文書です。要件定義書は、発注先が決まったあとに開発会社と一緒に作ります。順番が違うので、書く深さも違います。RFPは「何に困っているか」まで、要件定義書は「どう作るか」までを扱います。

まず用語を整理しておきます。これらの意味が混ざったまま進めていくと、必要以上に多くの資料 を作ることになります。

大事なのは、RFPで画面の一覧まで決めきる必要はないという点です。RFPの役割は、各社が同じ条件で見積れる状態を作ることにあります。契約後の工程については要件定義とは？失敗しない進め方で詳しく整理しました。

03データで見る｜開発プロジェクトの工期は10年で悪化しています

要点： JUASの調査では、システム開発が予定どおり完了した割合は10年間ですべての規模で下がりました。100人月未満でも2024年度は31.0%です。つまり、7割近くは当初の計画どおりには終わっていません。準備の質が結果を分けます。

「うちだけがうまくいかないのでは」と心配される方がいます。数字を見ると、そうではないことが分かります。

同じ調査では、品質についても「満足」と答えた割合は100人月未満で23.9%にとどまりました。多くは「ある程度は満足」です。事前に合意形成ができていれば防げたはずの認識のズレが、至る所に残ってしまっています。

小規模なプロジェクトですら、予定どおり終わるのは3件に1件。準備を省いた分は、必ずどこかで返ってきます。

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

要点： RFPの質は、書き始める前にほぼ決まります。決めておくのは、誰の困りごとを解決するのか、成功をどう測るのか、社内で誰が決めるのか。この3つです。逆にいえば、この3つ以外は提案側に委ねても構いません。

いきなり項目を埋めようとすると、途中で手が止まってしまいます。作業に着手する前に、まずは 社内で認識を合わせておくべき3つの事項があります。

1. 誰の、どの作業を楽にするのか。 「業務効率化」では広すぎます。受注入力を担当する2名が毎日1時間かけている転記作業。ここまで絞ってください。
2. 終わったあと、何が変わっていれば成功か。 月40時間の作業を10時間にする、といった形で数字を置きます。金額より時間のほうが、社内でも合意しやすくなります。
3. 誰が決裁し、誰が窓口になるのか。 決め方が曖昧だと、提案側は確認待ちの時間を見積りに乗せます。

3つ目は見落とされがちです。IPAが公開している情報システム・モデル取引・契約書でも、発注側の協力義務と開発会社のプロジェクト管理義務は、トラブルの分かれ目として扱われています。誰がいつ決めるかは、契約前に共有しておくべき情報です。

この3つが決まっていれば、あとは順番に埋めるだけです。決まっていないまま書き始めると、社内の合意形成をRFPの上でやることになります。

05データで見る｜発注側に足りないのは「要件を仕様に落とす力」

要点： 内製化に踏み切れない理由を尋ねた調査では、人材の不足に続いて「現行業務への理解不足」が38.7%、「ビジネス要件をシステム仕様に落とせない」が30.2%と並びました。技術力ではなく、業務を言葉にする力が足りていません。RFPはその力を補う道具でもあります。

止まっている原因は、プログラムを書ける人がいないことではありません。

ここから読み取れることは1つです。発注 要件 まとめ方でつまずいているのは、技術以前の段階だということ。だからRFPを書く作業そのものが、社内の整理になります。書けなかった項目は、そのまま「まだ決まっていないこと」として見えてきます。これがRFPを作る最大の副産物です。

06RFP 書き方の全体像｜10項目の構成

要点： RFPは10項目でまとまります。背景、目的、対象範囲、現行環境、機能の希望、予算、スケジュール、体制、提案してほしい内容、選定の進め方。A4で10ページ前後、多くても15ページに収めてください。

順番に埋めていける形で並べます。上から書くと自然につながります。

1. プロジェクトの背景。 「受注のたびに担当者がメールとExcelを行き来している」というように、具体的な場面で書きます。
2. 目的とゴール。 完成後に何が変わっていればよいかを数字で置きます。稼働そのものはゴールではありません。
3. 対象範囲。 今回やること、今回はやらないこと。この2つを並べて書くのが要点です。
4. 現行の環境。 使っているソフト、連携したい先、データ量、利用人数。分かる範囲で構いません。
5. 機能の希望。 必須と、あれば嬉しいものを分けます。ここを分けないと見積りが膨らみます。
6. 予算の考え方。 上限を隠すより、枠を伝えたほうが現実的な提案が返ってきます。
7. 希望スケジュール。 稼働させたい時期と、その理由。理由があると調整の余地が生まれます。
8. 体制と決裁の流れ。 窓口担当者、確認に関わる部署、決裁者。必ず書いてください。
9. 提案してほしい内容。 提案書の項目、見積りの分け方、想定体制、実績の提示方法を指定します。
10. 選定の進め方。 提出期限、質問受付の期間、評価の観点、決定時期を明示します。

この10項目のうち、金額に直結するのは3・5・6・7です。ここが曖昧なままだと、各社の解釈で数字が動きます。見積書の読み方はシステム開発の見積もりの見方にまとめました。

07データで見る｜項目が抜けたとき、提案はどう歪むか

要点： ZenWeb Japanが受け取るRFPで抜けやすいのは、対象外の明記、連携先、決裁の流れの3つです。抜けた項目ごとに、提案側は安全側に倒します。その結果、見積りは膨らむか、あとから追加費用が発生するかのどちらかになります。

当社にご依頼いただいた案件をもとに、抜けやすい項目と、そのとき何が起きるかを整理しました。

共通しているのは、抜けた項目は必ず金額か期間に跳ね返ることです。提案側は分からない部分を勝手に小さく見積れません。安全側に倒すか、後回しにするか。どちらも発注側の得にはなりません。

費用の内訳そのものについてはシステム開発の費用相場｜100万円と1000万円の違いで規模別に解説しています。

08書けない項目は「提案してください」と書く

要点： 分からない項目を空欄のまま出すと、各社が別々の前提で埋めてしまいます。そこで「この部分は決まっていないので、御社の考えをご提案ください」と明記してください。空欄と、提案依頼はまったく違う扱いになります。

これがこの記事でいちばんお伝えしたい書き方です。「すべての項目を埋めましょう」と説く記事は多いのですが、中小企業の現場では埋まらない項目が必ず出ます。

埋まらないまま提出すると、提案側は推測します。推測は会社ごとに違うので、比較ができません。ところが同じ空欄でも、「決まっていないので提案してほしい」と書いてあれば、各社はそこを提案の見せ場として扱います。同じ論点について複数の考え方が返ってくるので、判断材料が増えます。

• 技術構成。 「クラウドかオンプレミスかは決めていません。運用負荷と費用の観点でご提案ください」
• 段階分け。 「予算内に収まらない場合、どこまでを第一段階にすべきかをご提案ください」
• 運用の分担。 「稼働後にどこまでを自社で運用できるか判断がついていません。想定される分担をお示しください」

この書き方をすると、金額だけの比較から一歩抜けて、提案の質で会社を選べるようになります。

09見積りを横並びで比べられる形にする

要点： 見積りが比べられないのは、各社が違う粒度で出してくるからです。RFPの中で分け方を指定してください。要件定義、設計・開発、テスト、移行、教育、初年度メンテナンス。この6区分で出してもらえば、差がどこにあるか一目で分かります。

「安いほうを選んだら、あとから追加が続いた」。よく聞く話です。原因は見積書の粒度にあります。

そこでRFPに「見積りは以下の区分でご提示ください」と書きます。区分を指定するだけで、各社の数字が同じ土俵に乗ります。

あわせて、「前提条件と、見積りに含まれない作業を明記してください。」の1行を入れるだけで、 後の追加費用をぐっと減らすことができます。

10ベンダー 選定の進め方｜評価基準はRFPに書く

要点： ベンダー 選定でもめるのは、評価基準を後から決めるからです。RFPの段階で観点と重みを書いてください。金額、業務理解、体制、稼働後の支援、実績。この5つに配点を付けておけば、社内の合意も取りやすくなります。

提案が出そろってから基準を決めると、どうしても金額に引っ張られます。先に書いておけば、その場の空気で判断が動きにくくなります。

声をかける会社数は3〜4社が現実的です。多すぎると、質問対応と読み込みだけで担当者の時間が埋まります。

• 金額。 初期費用だけでなく、5年間の総額で見ます。月額が積み上がるためです。
• 業務理解。 提案書がこちらの課題を自分の言葉で言い直せているか。ここが最も差が出ます。
• 体制。 誰が窓口になり、誰が作るのか。営業と開発が分断されていないかを見ます。
• 稼働後の支援。 メンテナンスの範囲、連絡手段、対応時間。作って終わりの会社かが分かります。
• 実績。 業種より、業務の型が近いかを見てください。受発注なら受発注の経験です。

制作会社そのものの見極め方は制作会社の選び方｜失敗する会社の共通点で整理しています。外注と内製で迷っている段階ならシステム開発の外注と内製を先にお読みください。

11データで見る｜RFP作成から発注までのスケジュール

要点： 中小企業の業務システムであれば、RFP作成から発注決定までは概ね8〜10週です。うち社内整理に2〜3週、提案期間に3週、比較と決定に2週。ここを詰めすぎると、判断の質が落ちます。

「どのくらい時間がかかりますか」というご質問も多いので、当社の案件から標準的な流れを整理しました。

提案期間を2週間未満にすると、各社は概算しか出せません。3週間は確保してください。ここを削ると、提案の精度がそのまま落ちます。

補助金を使うなら、公募期間との兼ね合いも見ておきます。

12RFP テンプレートの使い方と注意点

要点： RFP テンプレートは、項目の抜け漏れを防ぐには役立ちます。ただし、そのまま埋めると自社の言葉が消えます。背景と課題の欄だけは、テンプレートの表現を使わず、現場で実際に起きていることを自分の言葉で書いてください。

テンプレートを使うこと自体に問題はありません。注意点は使い方のほうにあります。

• 項目の確認には使う。 自社のRFPに何が足りていないかを照らし合わせる用途では、テンプレートが役に立ちます。
• 背景と課題はコピーしない。 ここが一般論になると、提案も一般論で返ってきます。「毎月末に3人が半日かけて突き合わせをしている」といった具体を入れてください。
• 使わない項目は削る。 空欄が並んだ資料は読む側の負担になります。関係のない項目は消して構いません。
• 形式にこだわらない。 WordでもExcelでも、内容が伝われば問題ありません。

じつのところ、提案側がいちばん読むのは背景と課題の欄です。ここに温度がある会社には、提案側も本気の資料を用意します。

13よくある失敗5つと、その直し方

要点： RFPでよく起きる失敗は5つです。予算を隠す、要望をすべて必須にする、現場に聞かずに書く、質問期間を設けない、そして評価基準を後から決める。どれも直し方ははっきりしています。

ご相談を受けたRFPで、繰り返し見かけるものを挙げます。

1. 予算を書かない。 「高い金額を出されそう」と考えて伏せる方がいます。実際には逆で、枠が分からないと各社は無難な構成を出します。「この範囲で最大限の提案がほしい」と書くほうが、実のある提案が集まります。
2. 要望を全部「必須」にする。 現場の希望をそのまま並べると、初期費用が跳ね上がります。必須は、それがないと業務が回らないものだけです。
3. 現場に聞かずに書く。 管理部門だけで作ったRFPは、稼働後に「実際の手順と違う」と言われます。1時間でよいので、手を動かしている方に確認してください。
4. 質問受付の期間を設けない。 提案側の質問は、こちらの見落としを教えてくれます。提出期限の1週間前までを受付期間にし、回答は全社へ共有します。
5. 評価基準を後から決める。 提案を見てから基準を作ると、説明できない決定になります。社内で異論が出る原因もここです。

とくに1つ目は誤解が根強く残っています。予算枠の共有は、値引きの放棄ではありません。限られた枠の中で何を優先するか、その判断を提案側に求める行為です。

14まとめ｜RFPは社内の整理から始まります

要点： RFP 書き方の答えは、書式ではなく順番にあります。対象を1業務に絞り、成功を時間で定義し、決め方を明記する。この3つが決まっていれば、残りの項目は自然に埋まります。書けないところは、提案を求めると書いてください。

お伝えしたことを、もう一度並べます。

• RFPは仕様書ではありません。前提をそろえて提案を集めるための文書です。
• 金額に効果的なのは、範囲・必須機能・予算枠・時期の4つです。ここを曖昧にしないでください。
• 抜けやすいのは「やらない範囲」「連携先」「決裁の流れ」です。まずここから書いてください。
• 分からない項目は空欄にせず、提案してほしいと明記します。判断材料が増えます。
• 発注までは8〜10週。提案期間の3週間は削らないでください。

ZenWeb Japanは2000年創業、PNHグループの一員としてホームページ制作とWebシステム開発を手がけてきました。デジタル化の進め方全体は小規模から始めるDXを、Webサイト側の費用感はホームページ制作の費用相場をご覧ください。詳細は会社概要とWeb制作ブログにまとめています。

15よくある質問

1. RFPは何ページくらいが適切ですか

A4で10ページ前後が目安です。中小企業の業務システムであれば、多くても15ページに収まります。厚さは評価されません。むしろ長すぎると、提案側が要点を取り違えます。図や表で読む時間を短くするほうが効果的です。

2. 何社くらいに送るのがよいでしょうか

3〜4社をおすすめしています。2社では比較になりにくく、5社を超えると質問対応だけで担当者の時間が埋まります。事前にRFI（情報提供依頼書）で候補を絞ってから、本命の数社にRFPを送る形が現実的です。

3. 予算が決まっていない場合はどう書けばよいですか

金額そのものが決まっていなくても、判断の材料は書けます。「削減したい作業時間は月40時間」「回収したい期間は3年以内」といった形です。この2つがあれば、提案側は妥当な投資規模を逆算できます。何も書かないより、はるかに現実的な提案が返ってきます。

4. RFPは自社で書かないといけませんか

すべてを自社で書く必要はありません。業務の流れと困っていることは社内でしか書けませんが、構成の相談や項目の抜け漏れ確認は、開発会社に手伝ってもらえます。当社でも、RFP作成の段階からご相談をいただくことがあります。

5. 提案が全社とも予算を超えたときはどうすればよいですか

まず範囲を削ります。必須機能のうち、初年度は手作業のままでも回るものを第二段階に回してください。それでも届かなければ、既製のサービスで代替できないかを各社に再提案してもらいます。値引き交渉より、範囲の見直しのほうが確実です。