業務システムの刷新を任され、開発会社に声をかける前に「まずRFPを作ってください」と言われて手が止まった経験はないでしょうか。RFPは提案依頼書とも呼ばれ、発注者が自社の課題や要件を開発会社に伝えるための文書です。

書き方しだいで、集まる提案の質と比較のしやすさが大きく変わります。逆に項目が抜けていると、各社の見積もりの前提がそろわず、金額だけで選ぶ判断になりがちです。この記事では、業務システム開発を想定したRFPの書き方を、記載項目・作成手順・失敗例・評価方法の順に解説します。

この記事を読むと理解できること

• RFPとは何か、RFI・RFQとどう違うのか

• 業務システム開発のRFPに書くべき記載項目

• RFPを作成してから開発会社に送付するまでの7ステップ

• 提案の質が落ちるRFPの典型的な失敗と書き方のコツ

• 受け取った提案を公平に比較するための評価表の作り方

• 契約形態や予算をRFP段階でどこまで書くべきか

RFPとは何か？業務システム開発で書く目的とRFI・RFQとの違い

RFPとは、発注者が開発会社に対して「何を解決したいのか」「どんな条件で提案してほしいのか」を伝える文書です。目的は、複数社から同じ前提に立った提案を受け取り、比較して発注先を決めることにあります。

口頭の説明や簡単なメモだけで依頼すると、各社が独自の解釈で提案を作ります。その結果、機能の範囲や含まれる作業が会社ごとに違い、見積金額を並べても比べられない状態になります。RFPは、この前提のズレを最初に揃えるための道具です。

RFPを書く3つの目的

1つ目は、提案の質を上げることです。課題と背景が伝わっていれば、開発会社は自社の知見を生かした解決策を提案できます。

2つ目は、同じ条件で比較できるようにすることです。範囲・納期・予算の前提を明記すれば、提案と見積もりを横並びで評価できます。

3つ目は、社内の合意形成です。RFPを書く過程で、情報システム部門と事業部門、決裁者のあいだで「何のためのシステムか」をすり合わせることになります。

RFI・RFQとの違い

RFPと混同されやすい文書に、RFIとRFQがあります。一般的にはRFI、RFP、RFQの順で使われますが、候補が決まっている場合はRFPから始めることもあります。

業務システムの刷新では、要件がまだ固まり切っていないことが多いため、RFPで解決策そのものを提案してもらう進め方が中心になります。

RFPには何を書くべきか？業務システム開発の記載項目一覧

結論から言うと、RFPには「なぜ作るのか」「何を作るのか」「どう提案してほしいのか」の3つを書きます。決まった書式はありませんが、業務システム開発では次の項目をそろえると抜け漏れを防げます。

業務システムならではの書き方

業務システムのRFPで特に差が出るのは、現場の業務と利用者の書き方です。「受発注を効率化したい」とだけ書くのではなく、誰がどの画面で何件くらい処理しているのか、どこで手作業や二重入力が発生しているのかまで書くと、提案の具体性が上がります。

現状の業務フロー図や、よく使われている帳票・Excelをそのまま添付するのも有効です。整った資料でなくても、実物があるだけで開発会社は業務の実態を読み取れます。

FAKEがデザインドリブン®で業務システムに関わる際も、最初に確認するのは機能一覧より「現場の誰が、どんな場面で使うのか」です。RFPの段階で利用者像と業務シナリオが書かれていると、使われないシステムになるリスクを提案の時点で議論できます。要件を利用者の行動から組み立てる考え方は、UX視点で考える要件定義の進め方でも詳しく解説しています。

非機能要件と運用・保守の書き方

非機能要件は、業務システムのRFPで最も書き漏れやすい項目です。利用者数や同時アクセス数、1日に処理する件数、利用する時間帯、社外からアクセスするかどうかといった前提は、開発会社が構成や費用を決める根拠になります。

セキュリティについては、社内の情報セキュリティ規程や、取引先から求められている基準があればそのまま添付します。権限の考え方も重要で、「部署ごとに見られるデータを分けたい」「承認者だけが確定できるようにしたい」といった要望は、早い段階で書いておくほど設計に反映されやすくなります。

稼働後の運用・保守も、RFPの範囲に含めるかどうかを明記します。問い合わせ対応、障害時の対応時間、軽微な改修の扱いなどが書かれていないと、各社が想定する保守の範囲が違ってしまい、初期費用だけが安い提案が有利に見えてしまいます。

提案書の様式を指定する

提出してもらう提案書の様式も、RFPで指定しておきます。課題の理解、解決策、体制、スケジュール、見積もりの内訳といった章立てをあらかじめ示しておけば、各社の提案を同じ順番で読み比べられます。

見積もりについては、初期費用と稼働後の費用を分け、工程別・機能別の内訳を出してもらうよう依頼します。様式がそろっていれば、評価の時間を短くできるだけでなく、どの会社がどこで差をつけているのかも見えやすくなります。

契約形態はRFPでどこまで書くか

契約形態は、RFPの段階で「請負を想定」「要件定義は準委任を想定」のように方針だけでも示しておくと、見積もりの前提がそろいます。要件が固まっていない工程を請負で一括発注すると、開発会社はリスク分を上乗せして見積もるため、総額が膨らむことがあります。

契約形態ごとの責任範囲の違いは、準委任と請負の違いで整理しています。

RFPはどんな手順で書けばよいか？作成から送付までの7ステップ

RFPは、いきなり書き始めるより、社内で決めることを順番に固めてから文書にまとめる方が早く仕上がります。業務システム開発では、次の7ステップで進めるのが現実的です。

ステップ1 目的とゴールを決める

最初に、システム刷新で何を実現したいのかを決めます。「処理時間を短くする」「入力ミスを減らす」など、可能な範囲で測れる指標にしておくと、提案の評価にも使えます。

ステップ2 現状の業務と課題を洗い出す

現場の担当者にヒアリングし、業務の流れと困りごとを集めます。情報システム部門だけで書いたRFPは、現場の実態とずれやすいため、利用部門の声を必ず入れます。

ステップ3 体制と決裁者を決める

RFPの作成責任者と、提案を評価するメンバー、最終的な決裁者を決めておきます。決裁者が後から加わると、評価基準そのものが覆ることがあるためです。

ステップ4 要件を洗い出して優先度をつける

機能要件と非機能要件を洗い出し、必須と希望に分けます。すべてを必須にすると提案の幅が狭まり、見積もりも高くなりやすいため、予算と見比べながら優先度をつけます。

ステップ5 予算・納期と評価基準を決める

予算の上限や目安、稼働希望時期を決めます。あわせて、提案を何で評価するのか、評価項目と配点もこの段階で決めておきます。

ステップ6 文書にまとめて社内レビューする

ここまでの内容をRFPとして文書化し、関係部署でレビューします。社内用語や略語が混ざっていないか、外部の人が読んで誤解しないかを確認します。

ステップ7 送付して質疑に対応する

候補の開発会社にRFPを送付します。機密情報を含む場合は、送付前に秘密保持契約を結んでおきます。質疑への回答は、公平性を保つため全社に同じ内容を共有します。

依頼先は3〜5社程度に絞るのが一般的です。多すぎると評価の負荷が大きくなり、少なすぎると比較になりません。

RFPで提案の質が落ちるのはなぜか？よくある失敗と書き方のコツ

提案の質が落ちる原因の多くは、RFPの書き方にあります。特に多いのは、手段を細かく指定しすぎるケースと、逆に情報が少なすぎるケースです。

よくある失敗

1つ目は、画面や機能を細かく指定しすぎることです。発注者が考えた解決策をそのまま書くと、開発会社はその通りに見積もるしかなく、より良い方法を提案する余地がなくなります。

2つ目は、予算を伏せることです。予算が分からないと、開発会社は規模感を推測で決めるしかありません。その結果、各社の提案の規模がばらばらになり、比較が難しくなります。

3つ目は、「使いやすいこと」「高速であること」のような曖昧な要件です。人によって解釈が変わる表現は、提案の段階では問題にならなくても、開発の途中で認識のズレとして表面化します。

書き方のコツ

コツは、手段ではなく解決したい状態を書くことです。「この画面にこのボタンを置く」ではなく、「担当者が1件の受注を登録するまでの手順を減らしたい」と書けば、開発会社はそれぞれの知見から解決策を提案できます。

曖昧な要件は、数字か具体的な場面に置き換えます。「使いやすい」であれば、「初めて使う営業担当者がマニュアルなしで受注登録できる」のように、誰がどんな状態になれば達成なのかを書きます。

AI機能を組み込む開発の場合は、データの準備状況や精度の考え方など、業務システム全般とは別の論点が加わります。AI案件のRFPについては、AI開発を発注する流れで準備からRFP作成までを解説しています。

RFPを受け取った後はどう評価するか？比較表と選定の進め方

RFPは送って終わりではなく、届いた提案を評価して初めて役割を果たします。評価の基準は、提案を受け取る前に決めておくことが大切です。

評価表を作る

評価表は、RFPに書いた目的と要件に対応させて作ります。例えば、課題の理解度、解決策の妥当性、体制と実績、費用の妥当性、運用・保守の体制などを評価項目にし、それぞれに配点をつけます。

提案を読んでから評価項目を決めると、印象の良かった会社に合わせて基準を作ってしまいがちです。RFPを作るステップ5で評価基準を固めておくのは、この偏りを防ぐためです。

提案書で見るべきポイント

提案書では、金額の前に「RFPに書いた課題をどう理解しているか」を確認します。課題の言い換えが的確な会社は、開発が始まってからの認識のズレも少ない傾向があります。

見積もりは総額だけでなく、工程別・機能別の内訳を比べます。同じRFPを渡しても金額に差が出るのは、含まれる作業や前提が違うからです。内訳を見れば、どこに差があるのかが分かります。

プレゼンと質疑で確かめる

書面だけで判断しにくい場合は、提案のプレゼンテーションの場を設けます。実際にプロジェクトを担当する人が説明に来るか、現場の業務について質問してくるかも、相性を見る材料になります。

選定後にRFPを契約へ引き継ぐ

発注先が決まったら、RFPと提案書の内容を契約や要件定義に引き継ぎます。RFPに書いた目的や対象範囲、提案書で合意した前提が契約書や要件定義書に反映されていないと、選定時の議論が後工程で失われてしまいます。

選ばなかった会社にも、結果と理由を簡潔に伝えておくと関係を保てます。次の案件で再び声をかける可能性があるため、提案への協力に対する礼儀として対応しておきましょう。

業務システムやDX案件に強い開発会社の選び方は、業務システム・DXに強い開発会社の比較でも紹介しています。

まとめ

RFPは、開発会社から比較できる提案を集めるための文書です。書く内容は「なぜ作るのか」「何を作るのか」「どう提案してほしいのか」の3つに整理でき、業務システム開発では現場の業務フローと利用者像、既存システムとの連携まで書くことで提案の具体性が上がります。

作成は、目的の決定から送付・質疑対応までの7ステップで進めると、社内の合意形成も同時に進みます。手段を細かく指定しすぎず、解決したい状態と予算・納期を明記することが、質の高い提案を引き出すコツです。

そして、評価基準はRFPを送る前に決めておきます。RFPと評価表をセットで用意すれば、金額だけに頼らず、自社の課題を最も理解している開発会社を選べるようになります。

RFPの書き方に関するよくある質問

RFPはどのくらいの分量で書けばよいですか？

決まった分量はありません。業務システム開発では、本文で目的・課題・範囲・要件・条件を伝え、業務フロー図や帳票などの資料は添付で補う形が読みやすくなります。分量よりも、各社が同じ前提で見積もれるだけの情報がそろっているかを基準に判断してください。

RFPに予算を書くと、その金額いっぱいで見積もられませんか？

その可能性はありますが、予算を伏せた場合の方が提案の規模がばらつき、比較が難しくなります。上限や目安を示したうえで、見積もりの内訳を工程別・機能別に出してもらえば、金額の妥当性は内訳で確かめられます。

RFPのテンプレートはそのまま使ってもよいですか？

テンプレートは記載漏れを防ぐのに役立ちますが、そのまま埋めるだけでは業務システム特有の情報が抜けやすくなります。特に、利用者像・業務フロー・既存システムとの連携・データ移行の項目は、自社の状況に合わせて追加してください。

RFPは誰が書くべきですか？

取りまとめは情報システム部門やプロジェクト責任者が担うことが多いですが、内容は利用部門と一緒に作るのが理想です。現場の業務を知る人が関わらないと、課題の書き方が抽象的になり、開発会社の提案も一般論にとどまりやすくなります。

RFPを出した後に要件を変更してもよいですか？

提案期間中に要件を変える場合は、すべての候補会社に同じ内容を同じタイミングで伝えてください。一部の会社にだけ伝えると比較の公平性が崩れます。変更が大きい場合は、提出期限の延長も検討します。