の機能や事例などをまとめたサービス資料を配布しています
まずは無料で資料請求


STANDS編集部
日々の業務で活用いただける実践的なフレームワークや、知っておきたいSaaSのトレンドワード・キーワードの解説、CS業務改善のためのヒントなどをお届けいたします。
STANDS編集部
日々の業務で活用いただける実践的なフレームワークや、知っておきたいSaaSのトレンドワード・キーワードの解説、CS業務改善のためのヒントなどをお届けいたします。
Onboarding 資料請求フォーム
RFPとはRequest for Proposalの頭文字をとった略称です。日本語では、提案依頼書と言われます。企業がシステム開発や業務委託をする際に、発注先候補に具体的な提案を依頼するための文書です。
開発したいシステムの目的・概要・要件・制約条件などが記載されます。複数の発注先候補に同じRFPを元に提案をしてもらうことで、委託先を選定するための資料とするのです。
一般的には、RFPで以下の3つの要求を明確にします。
・何をしたいか(業務要求、技術要求、運用要求)
・いくらでしたいか(予算)
・いつまでにしたいか(納期、スケジュール)
ただ、システム開発に関する専門知識を持たない人や、これまでにRFPを作成したことがない人は、どのようにRFPを作成すれば良いか不安を感じるでしょう。この記事では、RFPの内容や作成するメリットを解説します。
作成時の注意点も説明しますので、RFPを作成する際の参考にしてください。自社のシステム開発や業務委託先を選ぶための参考にしていただけると幸いです。
RFPを作成する目的は、発注側の考えをシステム開発側に漏れなく伝え、相互理解を深めることです。発注側の課題や要望、要件を開発側と共有し、最適な提案を引き出すために作成されます。
発注側と開発側の認識のズレをなくすことが大切です。発注側と開発側の認識に齟齬があると、開発時や運用時に必ずトラブルに陥ります。それを防ぐために、最初の提案段階から、RFPを通じて課題や目的、方向性を共有するのです。
開発に関する、「何を」「どうやって」「いくらで」「いつまでに」といった項目を共有することで、その後の手順や開発をスムーズに進められます。
RFPと似た役割を持ち、名称も似ているので混同しやすいものに、RFIとRFQがあります。違いを把握しておきましょう。
RFPは前述の通り、Request for Proposalの略で、委託先候補から具体的な提案をもらうために、要件などをまとめた依頼書です。
RFIは、Request for Informationの頭文字を取った略称です。情報を求めるというような意味合いになります。委託先候補となる開発企業などに対して、教えてほしい項目をまとめた依頼書です。いわばRFPの前段階となるもので、調査段階での情報を収集するために作成します。
RFQは、Request for Quotationの略称です。価格や費用の見積りを求める依頼書です。RFPへの返答となる提案を受け取った後で、具体的な要件をまとめた上で、それを実現するための具体的なサービスやシステム開発のコストを比較するために、見積もりを依頼する際に作成します。
RFPを作成せずにシステム開発を進めることは可能です。しかし、要望を口頭や簡単な資料で説明しただけでは、自社が求める開発要件が相手に伝わらないリスクがあります。また、複数の開発業者に提案や相見積もりを求める際に、相手によって理解がバラバラで比較できなくなることもあります。
そのため、RFPを作成することにメリットがあるのです。ここでは、RFPを作成する主なメリットを説明します。
RFPを作成することで、発注側の課題や求めている解決方法が明確になります。自社の課題やシステムを開発する目的を提示し、要件や要望を正確に伝えることができます。
このような課題を解決できるシステムを開発してほしいので、このような要望を実現するシステムを提案してください、という依頼が可能になることがメリットです。その結果、発注者は最適な提案を受けられるようになります。
また、RFPを通じて正確な情報を提供することで、口頭での伝達による認識の齟齬を防げることもメリットです。複数の開発業者に提案を依頼する際にも、それぞれの開発業者との打ち合わせで違うことを伝えてしまったり、認識がずれてしまったりすることで生じる問題を防げます。
RFPを作成することで、複数の開発企業に提案を依頼した際に、比較しやすくなることもメリットです。発注側の要求が固定されるため、提案内容の差がわかりやすくなるのです。
明確な要求定義がないと、複数の提案を受け取った際に、必要な機能要件が伝わっているかもわかりません。どのような機能を持っているかを精査するところから検証を始めなければならず、当然ながら開発費用や期間にも大きな差が生じます。
その結果、複数の提案を比較することすら難しく、コンペのやり直しが必要になることも多くなります。
RFPにはスケジュールも記載します。そのため、提案を受けた納期や、その後の進捗についても評価や管理がしやすくなるというメリットもあります。また、RFPにある当初の計画から、必要に応じて予算やスケジュールを見直すことも可能です。
明確な計画の提示がなければ、発注側と開発側で認識のズレが生じたり、言った・言わないのトラブルが起こったりしやすくなります。そのようなリスクを避けるためにも、RFPの作成と提示は有効です。
同じ内容のRFPを全てのシステム開発会社に提出することで、発注側の依頼内容を均一にできることが大きなメリットです。発注時の要望が同じならば、複数の開発会社からの提案内容にブレが生じにくくなります。その結果、提案内容やシステムの差異、見積価格の違いがわかりやすくなるのです。
また、REFがあることで、開発側も安心できます。具体的な要件が提示されることで、提案も具体的になります。また、単なる情報収集段階ではないと伝えられるため、きちんと労力をかけた提案の返答をしてもらえやすくなるのです。
RFPは、発注側と受注側の認識をすり合わせる機能を持つ資料です。そのための情報が記載されていることが必要です。少なくとも、プロジェクトの概要・提案を依頼する内容・選定の進め方については提示しましょう。
まず、どのようなプロジェクトに関する開発であるか、開発するシステムがどのようなものであるか、全体像を示す必要があります。
自社の課題と解決方法、目指しているゴールを提示することで、より良い提案を引き出すことが可能です。具体的には、以下のような項目があげられます。
・依頼する理由や提案依頼書の目的
・システム開発や導入の経緯、自社の環境や経営的課題といった背景
・解決したい課題
・プロジェクトの具体的な目的と目指しているゴール
・現在使用しているシステムやソフトなどの構成
・開発したシステムを運用する人員や環境などの計画
次に、提案内容に盛り込んでほしい項目を記載します。提案をする開発側は、得意な分野や、独自の課題解決方法に関してより多く説明する傾向があります。それらは差別化できる点なので重要です。
しかし、発注側として重点を置きたいことや自社の運用環境への対応など、明確にしておきたい項目もあります。それらの、提案書に記載してほしい内容を示しておきます。
具体的には、以下のような項目です。
・開発会社の組織情報
・提案システムの概要や構成、機能
・開発スケジュール
・プロジェクトに関わる人員などの体制
・プロジェクトのマネジメント方法や進め方
・納品内容
・運用保守の内容や範囲
・サポート体制や運用時の研修などの内容
・費用の見積もり
・同様のシステム開発の実績や導入事例
複数の開発企業に提案を依頼した後、どのように選考を進めるかを提示します。選考のスケジュール、その後の開発スケジュールも記載しておきましょう。
提案を依頼された開発会社のリソースも有限です。できるだけ受注確度の高い案件に注力したいのは当然です。そのため、選考の進め方が曖昧な依頼や、評価基準がわからない依頼については、提案の作成自体を断ることもあります。
発注側が本気であることや、良い提案を採用する体制が整っていることを示すことが必要です。具体的には、以下のような項目を説明しましょう。
・選定スケジュール(提案書の提出期限・プレゼンの日程・選考結果の期日・選考結果の連絡方法)
・提案書提出先(自社や担当者の情報)
・評価基準・評価方針・重視するポイント
ここでは、RFPを作成して、実際に活用する手順を説明します。すなわち、自社内の課題からシステム要件を検討し、開発企業に提案を依頼して、比較検討した後に発注先を決めるまでの手順です。計画的に進めなければ、最終的な選定結果はもちろん、開発されたシステムの良し悪しにも関わります。
システムを開発するためには、まずシステムを開発・導入する目的を明確にする必要があります。各部署の課題や問題点を洗い出し、それらを解決するためのシステムの要件を設定するのです。
そのために、社内でヒアリングやミーティングを行いましょう。システム導入によって複数の部署に影響が及ぶこともあるので、幅広く情報を洗い出し、共有することが重要です。
また、システムの開発・導入後に有効に使えるように、体制を検討することも大切です。システムをどこでどう使うか、誰が使うか、社内教育は必要か、人的リソースや人員のリテラシーを考慮して検討しましょう。
社内での情報収集を行い、課題と解決策が設定でき、希望するシステムの要件が把握できたら、RFPを作成します。前述の記載すべき項目に従って、具体的かつ詳細に説明してください。
同時に、システム開発を依頼する候補となる開発企業を探します。複数の候補が見つかったら、RFPを渡して、提案書の作成を依頼しましょう。
場合によっては、システム開発企業に対してRFPの内容を説明する、オリエンテーションの場を設けることも必要です。
システム開発を依頼する候補となる複数の企業に対して、RFPを提出して提案を依頼した後は、設定した期日まで提案や見積を待ちます。開発企業からの質問があれば都度回答しましょう。その質問と回答は、参加している全社に公開するのが一般的です。
そして、参加各社からの提案が集まったら、審査チームで選考を進めます。RFP作成時に設定した評価基準に基づいて選考しましょう。最終決定までに必要があれば、プレゼンテーションやコンペティションを実施して提案内容を詳しく聞き、開発に関する調整をする場を設けます。
ここまで、REPの記載内容や作成手順を説明しました。それらに従えば、RFPを作成できます。ただし、RFPの作成時には注意すべき点もあります。
RFPは開発を依頼する候補となる企業とのコミュニケーションを潤滑にするためのものです。ここでは、この役割を果たすための注意点を説明します。
RFPには、システムに必要な全ての要件を抜け漏れなく、詳細に記述する必要があります。システム開発にあたり、希望する要件は全て記載しましょう。基本機能だけではなく、障害時のサポート体制や、データのバックアップ体制などの非機能要件も含めて検討しなければなりません。
ただし、RFPに記載する要件は、現実的に実現できる内容にすることも重要です。例えば、24時間365日いつでも運用サポートが必要などとすると、コストが大幅に上がります。
また、運用を開始するにあたり実現したい機能ではないものの、将来的に拡張したい項目があれば、あらかじめ記載しておきましょう。
RFPは抜け漏れを防ぐために、複数の人の意見を取り入れることが大切です。1人で作成せず、必要に応じて各部署にチェックしてもらいましょう。特に、REPを作成する担当者が情報システム部の所属の場合、現場の業務フローを把握しきれていないことが一般的です。
システムに期待する機能は、部署や業種によって異なります。連携すべき各部署間で齟齬が生じないように確認が必要です。現場の運用環境を考慮して、現実的に使いやすいシステム要件を設定してください。
RFP提出後の追加要求は避けるべきです。システム開発会社はRFPを基に提案書や見積書を作成するため、追加要求があると、それに応じて修正しなければなりません。開発するシステムの機能にも見直しが生じます。さらに、開発時の員体制やスケジュールも変更が必要で、見積もり金額も再検討することとなります。
それだけ提案までのコストが増えるのです。その結果、提案締め切りの期日に間に合わなかったり、受注確度の低い発注元と判断され、提案自体が作成されなくなったりしてしまいます。
RFPは日本語では提案依頼書と言われます。企業がシステム開発や業務委託をする際に、発注先候補に具体的な提案を依頼するための文書です。発注側の考えをシステム開発側に漏れなく伝え、相互理解を深めることを目的に作成されます。
RFPは企業がシステム開発を検討している際に、開発企業にシステムの正確な要件と要望を伝えるために重要なツールです。RFPがあれば、複数の開発企業に対して同じように依頼できるため、複数の提案を比較して、スムーズな選考を行えます。
RFPを作成する際は、社内の各部門と連携し、課題や目的を明確に記載してください。ベンダーとの間でのシステム要件に関する齟齬が発生しないよう注意しましょう。
システム開発は、自社の業務生産性を向上させ、ビジネスを進化させるために重要です。そのスタート地点においても、システム開発をスムーズに進めるためにも、RFPは重要なのです。ぜひこの記事の内容を参考に、RFPを効果的に作成し活用してください。
関連記事