システムを導入する際には、「どのようにして自社にあったシステムを導入するのか」という視点が非常に重要となります。やみくもにシステムを導入してしまうと、「機能が全然足りない」「予算がオーバーした」といった問題にぶち当たるでしょう。

そういった導入時の失敗を少しでも減らす役割を期待できるものに「RFP（提案依頼書）」があります。近年ではRFPを作成し、システム開発会社からの提案を比較検討したうえで、委託先を決定する企業が多くなってきている印象です。

今回はこのRFPについて書き方や記載すべき内容をメインに解説し、今すぐ使えるサンプル・テンプレもあわせて紹介します。

RFP（提案依頼書）とは？

RFPとは、「Request for Proposal」の略称で、直訳すると「提案依頼書」になります。

システムを発注する側の企業が、開発会社に対して提案してほしい内容をまとめた文書のことを指します。

RFPというカタチで要望や依頼事項をまとめて記載することで、提案依頼を受けた複数の開発会社は、共通の条件のもとで提案書の作成や見積額の算定が行えます。また、要望を満たしたうえで、さらに独自性に訴求する提案もできるはずです。

仮にRFPを作成しないで各社から提案依頼を受けた場合、提案範囲や見積額にバラつきが発生する可能性が高まります。これでは、各社からの提案書を横ならびで比較検討することは難しくなるでしょう。

また依頼内容が正確に伝わらず、出来上がったシステムが想定外のものになる、要望漏れが多発するなど、さまざまな問題を引き起こす可能性も否めません。

RFPを作成するにはそれ相応の労力を要しますが、最終的に期待しているシステムを手に入れるためには、しっかり準備を行ったうえでRFPを制作すべきです。

RFPを書く前の準備

多くの時間と労力をかけて作成するRFPが中途半端になってしまうことは避けたいところです。そうならないためにも、RFPを作る前にこれから紹介する3つの準備を行いましょう。

準備1. 関係部署やプロジェクト担当者へヒアリングを行う

「自社が抱えている課題」「どのようなシステムを作ればその課題が解決されるか」などを、関係部署やプロジェクト担当者へヒアリングし、必要な情報を集めるところからはじめましょう。

システムにはさまざまな機能が搭載されますが、それらの機能を一番使う部署のメンバーや現場の意見を反映できていないシステムでは、満足度の高いシステムにはならないでしょう。

準備2. 目的を明確にする

自社の課題・現場の要望などをふまえ、システムやアプリケーションを作る目的を明確にしておく必要があります。この際、目標を数字などの定量的なカタチで明確化することをおすすめします。そうすれば、RFPを作成する際にその数字を活用できるはずです。

また、開発会社にも得意不得意な分野・業界があり、目的が明確でないと開発会社の選定作業に影響を及ぼしかねません。目的を明確化にする作業はとても重要です。

準備3. 予算の上限を決める

システム開発にあてられる予算の上限は決めておきましょう。システム開発を依頼する際には、できるだけ費用を抑えたいもの。ですが、予算が少なすぎると開発会社もなかなか良い提案はできません。

発注費用を極限まで抑えたいがゆえに、本当に出せる予算額から大幅に少ない金額を開発会社に伝える企業もあります。しかし、安かろう悪かろうというのはシステム開発にもいえることです。

現実離れした低予算では、いくら実績豊富な開発会社でもできることが限られます。そのため、「1000万円までにおさめたい」というように、妥当な範囲で予算の上限を設定しておきましょう。

関連記事：システム開発の費用/料金相場はいくら？ 現役エンジニアが解説！

RFPの書き方・記載すべき項目

ここからは、RFPの書き方・記載すべき項目について解説を進めていきます。

書くべき内容はプロジェクトの性質ごとに細かく変わってきますが、ざっくりまとめると、最低でも以下の内容をRFPには盛り込むべきです。

・プロジェクトの概要
・プロジェクトの対象範囲
・予算、スケジュール
・要件
・納品物
・依頼内容、まとめ

以下では、さらに具体的な記載項目を見ていきましょう。

項目1. 表紙・表題

はじめに目にする表紙・表題には、「○○プロジェクト提案依頼書」といった表題をつけておきましょう。会社名と担当者名もそれぞれ記載し、連絡先も明記しておきます。

また、簡単な概要説明を兼ねたあいさつ文も記載しておきます。詳細については後ほどじっくりと記載していくので、ここでは今回の依頼の全体像を簡潔にまとめたものを紹介するだけで良いでしょう。

項目2. 背景・課題

今回の依頼にいたる背景や自社が抱えている課題についても明確に記載します。

背景には「プロジェクトを実施することになった理由」を記載し、課題には「自社の目的を達成するために解決が必要なもの」や、「関係部署からヒアリングできた現場が抱えている悩みや要望」などを記載します。

これらを依頼先に理解してもらうことで、自社のニーズに沿ったシステム開発の提案を受けやすくなります。ヒアリングなどで認識した課題はできるだけ詳細に、複数ある場合には省略することなくすべて記載しておくことをおすすめします。

項目3. ゴール・目的

背景や課題を洗いざらい記載できたら、次はプロジェクトでどのように課題を解決に導きたいのかを明記します。

システム開発やアプリケーション開発を行う目的には、「業務効率化」や「ユーザビリティの向上」などがあげられますが、最終的な目的・ゴールは必須です。

ゴールは、「品質（Quality）」「費用（Cost）」「Delivery（納期）」ごとになるべく数字付きで設定すると良いでしょう。

プロジェクトのゴールは、納品後にプロジェクトの成果を評価する指標としても活用します。定量的でないと評価が難しくなるため、できるだけ定量的なものを設定することがおすすめです。

項目4. ターゲット

ゴールや自社のクライアント層を念頭に置いた、メインターゲットの設定もここで行います。

ターゲット層を明確にすることで、目的・目標達成のためにターゲットにどのようなアクションをとってもらう必要があるのかを開発会社も想定しやすくなります。

ビジネス戦略上でターゲットとするペルソナがすでに決まっているのであれば、それらの情報はくまなく記載しておくことがおすすめです。

項目5. 競合企業・参考サイト

競合企業や参考サイトの情報も記載しておくのがベストです。開発会社には、競合分析をしたうえで、見積もりや提案をするところが多くあります。

「競合として意識している企業」や「業界的に有名な企業」など、具体的な企業名をあげながら記載しておきましょう。

項目6. 対象範囲

今回の提案依頼の対象範囲を具体的に明記します。たとえば、Webサイト制作であれば以下の作業項目などが挙げられます。

・要件定義
・サイトマップ案
・サイトコンテンツ案
・サイトデザイン案
・CMSの導入案
・セキュリティ対策
・公開後の運用、保守サービス
・プロジェクトスケジュールの作成、管理
・プロジェクト体制の提案

このなかのどの項目を外注するのかをしっかり明記しましょう。各社バラつきなく、一定レベルの提案を受けるためには、対象範囲はできるだけ詳細に定めることがおすすめです。

項目7. 対象外範囲・特記事項

対象範囲を明記すると同時に、対象外となる範囲や特記事項なども記載しておきましょう。

特に使用したいツールや自社で担当したい工程がある場合には、なるべく記載しておきましょう。打ち合わせなどがスタートした時に、「○○はやらなくていいよ」と伝えた場合、開発会社は改めて工数や見積もりなどを計算し直す必要が生じてしまうためです。

また、サーバーOSやミドルウェア、OSのバージョンなど自社のインフラ環境に指定がある場合には、その旨を特記事項として記載しておきましょう。開発会社側からすれば、あらかじめそのような情報は知っておいたほうが話を進めやすくなります。

項目8. オプション提案範囲

必須の対象範囲ではないものの、できれば追加で提案してほしい事項については、オプション提案範囲としてまとめておきます。たとえば、Webサイト制作後の分析ツールやMAツールの導入、保守・運用サポートなどがあげられます。

オプション提案は各社の差が付きやすい部分でもあります。各社の熱量や力量、考え方が見える部分でもあるため、依頼先を選定する際には非常に重要なポイントになるはずです。

項目9. 予算

先ほども触れたように、予算の上限を設けて提案を受けることをおすすめします。

開発会社ごとで提示額にバラつきがあると、どうしても金額が低いところに意識が集中してしまい、横一線での比較検討ができなくなります。

バラつきの差を少なくさせるためにも、上限は設けましょう。また、質の良い提案を集めるためには、理由の明記を条件としたうえで予算を超過した提案も認めることを検討してみるのもおすすめです。

予算に関していえば、金額だけではなく項目ごとに明記しても良いかもしれません。たとえば、「システム構築費用」「運用・保守費用」「ソフトウェア費用」などと項目を分けることで、初期費用からランニングコストまで詳細な比較検討が可能になります。

項目10. プロジェクトスケジュール

プロジェクトの想定スケジュールも明記します。

開発会社は、スケジュールと予算を照らし合わせながら提案書を作成します。「いつ頃のシステムリリースを想定しているのか」「どのようなマイルストーンを想定しているのか」などを、具体的かつ視覚的にわかりやすいよう「表」に明記しておきましょう。

項目11. 選定スケジュール

提案依頼から委託先選定までのスケジュールも記載しておきます。提案の締め切り日を記載するのも大切ですが、選考日やプレゼン、結果通知の日程もあわせて記載しておきましょう。これにより、提案依頼先も今後のスケジュールが立てやすくなります。

項目12. 機能要件

機能要件として、システムやアプリケーションに必要な機能を定義します。たとえば、ECサイトであれば、会員登録機能やデータベース連携、ポイント付与といった機能は不可欠でしょう。

また、機能要件を洗い出す際には、必ず複数人で行うようにしてください。ひとりの目線だけで作業を行うと、必ず漏れが発生します。システムもアプリケーションも多くの人が利用することを考えると、作成前の段階から多くの目線を入れる必要があります。

委託先が決まった後でも、機能要件についての打ち合わせは行われますが、RFPの段階でわかっている限りの機能はすべて盛り込むようにしましょう。

RFPに記載されていない機能を後から追加するとなると、金額やスケジュールに変更が生じる可能性も否定できません。詳細がわからなければ抽象的でも良いので、まずは忘れずに記載することが大切です。

項目13. 非機能要件

機能要件を明記すると同時に、非機能要件についても可能な限り記載しておきましょう。

非機能要件とは、機能以外のすべての要件のことを指します。たとえば、レスポンス速度やOS・ブラウザなどの動作環境、データベースのバックアップなどが挙げられます。

非機能要件は、機能要件よりも記載項目が多くなりがちです。IPA（独立行政法人情報処理推進機構）が定義する「非機能要求グレード」の通り、以下の項目に分けて記載してみましょう。

1. 性能・拡張性
2. セキュリティ
3. 運用・保守性
4. 移行性
5. 可用性
6. システム環境・エコロジー

項目14. インフラ要件

システムを稼働させるにはサーバーが必要です。WebアプリではドメインやSSL認証なども必要になってきます。そういったインフラについて、自社で用意するのか、委託先に用意してもらうのかなどはあらかじめ記載しておきましょう。

委託先にサーバーを用意してもらう場合には、必要なスペックなどについても記載しておいたほうが良いでしょう。ただし、インフラ要件に関しては多少の専門的な知識が必要となる部分でもあります。委託先も開発のプロのため、わかる範囲で記載すれば、過去の実績からどのぐらいのスペックが必要なのかわかるはずです。

項目15. 納品物

請負契約で開発を依頼する場合、成果物の納品で契約が完了となります。成果物にはもちろん動作可能なシステム一式が必要ですが、それ以外にも要件定義書や仕様書、デザインデータなども納品物として指定しておくことをおすすめします。

これらの納品物は、保守・運用後も必須となります。仕様書などは追加や修正に必要なのはもちろんですが、「契約対象範囲の機能で不具合が発生しているのか」を検証する際にも活用できるため、トラブル回避にも役立ちます。

項目16. 提出日・提案物

提出期限や提案物だけでなく、提案書のフォーマットなども明記しておきましょう。提案書のデータ形式やフォーマットが各社でバラつきがあると、選定時に比較検討しにくいケースが発生します。

また、具体的な開発案だけでなくプロジェクトのチーム体制やスケジュールなどもあわせて記載してもらいます。自社での比較検討に必要だと思うことは何でも盛り込んでおきましょう。

項目17. 契約条件・対応窓口

システムの著作権の取り決めや、機密情報の取り扱い、瑕疵担保責任、検収・支払条件などについても最後に記載しておきましょう。

また、Q&Aのようなカタチで依頼先とのやり取りが発生する可能性が高いため、その際の受付先や窓口も決めて記載しておきます。提案書と見積書の提出先が違うケースには、それぞれの担当窓口と対応範囲についても明記し、電話やメールといった連絡手段は可能な限り記載しておきましょう。

RFPを作成する際のポイント

ここまでRFPの書き方・記載すべき項目を解説してきましたが、実際に書く際にはどのようなことに注意して作成すればよいのでしょうか。ここではRFPを作成する際のポイントについて解説します。

ポイント1. 自社の課題と要望を意識して作成する

今まで解説してきた通り、RFPには記載しておくべき項目が多く、書き方が分かっても手が動かないかもしれません。その際には、まずは自社の「課題」と「要望」を意識して作成することからはじめてください。

細かい機能や要件に関しては、正式に契約が決まってからでも打ち合わせできます。しかし、「課題」と「要望」が定まっていなければ、「どんなシステムが欲しいですか？」「何を解決させたいですか？」と開発会社も疑問点が多くなり、できる提案もなくなります。また、どれぐらいの予算や工数が必要なのかも概算できません。

双方のためにも「課題」と「要望」をしっかり書くことを意識してください。

ポイント2. あいまいさは排除する

開発会社ごとに解釈が異なってしまわないように、あいまいな表現は極力排除するように心がけましょう。

あいまいさを排除するというと、「RFP作成段階から細かな点まで決めなければならない」と考えてしまう方もいるかもしれません。ですが、RFPはあくまでも開発会社やシステムを選定するために作成するもので、システムの設計書ではありません。

「RFPは自社に最適なシステムを導入するために必要なものだ」という前提で記載内容を検討し、各社があいまいに理解しないような記述内容にする、なるべく数字を使った定量的な表現を取り入れる、といった点を意識してみると良いでしょう。

ポイント3. RFPに詳しい人や専門家に確認してもらう

RFPの作成が完了した後も、すぐに提案依頼先に送るのではなく、外部のアドバイザーなどに一度確認してもらうことをおすすめします。第三者から見て、あいまいな表現が残っていないかを確認することは大切です。

また、開発依頼自体がはじめてのケースでは、「必要な要件や機能が詳細に明記されていない」「工数や予算がプロからみた場合に現実味がない」など、「これでは良い開発会社とはなかなか出会えないな……」と感じるRFPもチラホラ見受けられます。

RFPがあれば、おそらくどこかの開発会社が依頼を受けてくれると思います。しかし、その会社が希望通りのシステムを開発してくれるかどうかは別問題です。数ある開発会社から、自社の希望通りのシステムを開発してくれる会社と出会うためには、RFPの出来がとても重要です。

GIGでは、RFPに関する相談も承っていますので、ぜひお気軽にお問い合わせください。

RFPのサンプル・テンプレ

RFPを作成するにあたり、白紙の状態からいきなり書き進めることはおすすめできませんし、おそらく何を書いていけば良いのかわからなくなります。まずはテンプレートなどを積極的に活用することがおすすめです。

GIGでは、RFPのサンプル・テンプレートとして「BtoB企業向けのRFPの書き方」を用意しています。

こちらではテンプレートを確認できることはもちろん、改めてRFPの役割や作成時における注意点などを振り返り、理想的なRFPに必要な項目も詳しく解説しています。

下記からテンプレートをダウンロードしていただけるため、ぜひこの機会にご活用ください。

関連資料：BtoB企業向け RFPの書き方とは

RFPの作成支援はGIGにお任せください

今回はRFPについて解説してきました。書き方・記載すべき内容は理解していても、自分たちの要望・要件をきちんと文書化できる企業はそこまで多くない印象です。外部にシステム開発を委託するノウハウが無いケースだと、難易度はますます上がります。

ですが、面倒だからといってRFPを作成するプロセスをスルーするのは避けたいところ。RFPがあるほうが、自社の要件に沿った開発を行ってくれる企業と出会える確率は上がりますし、外部委託を行うノウハウがない場合には、なおさらRFPの作成からはじめていただきたいと思います。

GIGでは必要に応じてRFPの作成支援を行っております。また、システム開発に加え、マーケティングを得意としているため、競合調査や過去データの分析など、根拠あるデータをもとに要件定義を進め、精度の高いシステム開発を行ってきました。

RFPの作成支援やシステム開発全般について疑問点がある場合には、ぜひ一度お問い合わせください。

■株式会社GIG
お仕事のお問い合わせはこちら
会社紹介資料のダウンロードはこちら
採用応募はこちら（GIG採用サイト）
採用応募はこちら（Wantedly）

GIG BLOG編集部

株式会社GIGのメンバーによって構成される編集部。GIG社員のインタビューや、GIGで行われたイベントのレポート、その他GIGにかかわるさまざまな情報をお届けします。