RFP(提案依頼書)とは?作成方法と注意点について解説
新たなシステムを導入したり、既存のシステムの入れ替えを検討している場合は、システムを開発する発注先を探す必要があります。このときに役立つものが、RFP(提案依頼書 / Request For Proposal)と呼ばれる書類です。RFPとは、受注候補となる企業にシステム開発の提案書を求めるための書類です。受注候補の企業は、RFPを基に提案書を発注企業に送付します。
RFPとは
RFP(提案依頼書 / Request For Proposal)とは、発注側となる企業が受注候補の企業に対して送付する、発注側が実現したいことをまとめた資料のことです。主に、自社にシステム導入したいときに、システム開発作業を依頼する開発会社を決めるために用いられます。
例えば、大手企業が顧客を管理するためのシステムを取り入れたいとして、そのシステム開発を外注したいときにRFPを作成します。受注候補の企業は、RFPをもとに発注側の狙いや求めている機能条件などを把握します。そのうえで、受注候補の企業は、システム開発の提案書を発注企業に送ります。一般的には、RFPの書き手と読み手の関係は下記のようになります。
- 書き手=システムを企画したディレクター
- 読み手=システム開発担当の候補となるエンジニア
RFPを作成するメリットと注意点
RFPを作成するメリットと注意点について、それぞれわけてご紹介します。
RFPを作成するメリット
RFPを作成する利点は下記のとおりです。
- 自社が求めるシステムの機能が正しく伝わる
- 発注先を確定する際に、決め手となる要素を把握できる
自社が求めるシステムの機能が正しく伝わる
RFPに必要事項を記載して受注候補に共有することで、自社のビジネス的な背景や求める機能がエンジニアに正しく伝わります。逆にRFPを用意しない場合は、下記のようなリスクをともないます。
- 自社がシステムを構築したい背景や狙いを正しくキャッチされない
- 受注候補の独自判断で機能要求を解釈してしまう
発注先選定の決め手になる
RFPの共有を経て受注候補から提案を受けると、複数社のいずれの企業に依頼するかの判断基準ができます。RFPの作成を進めていくと、自社にとって優先することが可視化されます。
例えば、「この機能は必ずほしい」と考えたとします。このとき、実はこの機能の実装は技術的に難易度が高いことが判明します。ただ自社が求める機能の開発と相性がよい開発会社では実現可能という回答がありました。このように、RFPを作成すると受注先の決め手になる要素をピックアップできるといった副産物があります。
RFPを作成するうえでの注意点
RFPを作成するうえで、注意したいポイントはこちらです。
システム開発の稼働までに時間がかかる
RFPを作成する際は、さまざまな事実確認や資料を成形する作業が発生し時間がかかります。さらに、RFPを受け取った受注候補が提案書を作成するのですが、受注候補の企業の組織体系によっては、社内承認を受けるまでに時間を要します。RFPを作成すると、こうした工程を経るためシステム開発が開始されるまでに長い時間が必要です。
RFPの目的と役割
RFPの目的は、「なぜ」「なにを」「どのように」したいのかを伝えるためのものです。こうした要素には、単純なシステムの機能性だけでなく企画趣旨や自社の背景といったものも含まれます。RFPで伝えるべき要素は、大きく4つにわかれます。
- 企画の趣旨
- 必要な機能
- 役割分担
- スケジュール
自社が実現したいことをRFPを通じて受注候補に共有することで、受注候補がシステム構築に対して適切な提案をしてくれたり、見積もりを出してくれます。
企画の趣旨を伝える
新たなシステムの導入を検討する場合、その狙いや目標があるはずです。RFPに、こうした企画の趣旨を盛り込んでください。さらに、自社の事業内容やシステムが必要になった背景、また課題を記載しておくことで、受注候補が「なにを作ればよいのか」といった答えを出すための一助になります。できるだけ詳しく説明してあげることで、システムを構築するエンジニアの負担が減り納品がはやくなります。
必要な機能を伝える
ここがもっとも重要なポイントとなりますが、システムに必要な機能を伝えます。ここで注意すべき点は、機能の拡張性を考慮しておくということです。
拡張性とは、完成したシステムに対して機能を後付けで追加することを指すのですが、一般的にはシステム運用中に、「この機能を追加したい」「この部分の性能を高めたい」といったことが度々起こります。そうしたときに、拡張性を考慮しないシステムを構築してしまうと、改良が極めて困難です。場合によっては、一から作り直すといったことが起こりかねませんので注意してください。ただし、原則的には拡張性を確保するほど開発コストが大きくなりますので、不安な場合は事前に開発会社にヒアリングしてください。
役割分担を明確にする
システムを構築する場合、通常はさまざまな作業を発注側と受注側の企業で分担して進めていくことになります。ここでいう役割分担とは、開発中はもちろんのこと、システムの納品後のアフターケアーなども含まれます。例えば、納品後に誰がシステムのメンテナンスをするのかなどといった問題があります。メンテナンスも含めて開発会社に担当してもらいたい場合は、その旨も伝えておく必要があります。
スケジュールを伝える
納品までの希望スケジュールをまとめておきます。スケジュールを記載しておくことで、エンジニアが地震の業務を設計するときに役立ちます。さらに開発にかかる工数を考慮すると、そもそも発注側による希望のスケジュールで納品を実現できるのか否かといった判断を受注候補がくだせるようになります。
RFPを作成してから納品までのプロセス
RFP作成後から納品までの大まかな手順をご紹介します。
- RFPの作成と共有
- システム開発の提案や見積の発行
- 発注側と受注候補の合意
- 開発と納品
- 納品後のアフターケアー
RFPの作成と共有
まずは、発注側の企業がRFPを作成します。実際にRFPを作成していく際は、大きく下記の2要素に分かれます。
- 提案依頼の概要:自社の課題や目的、またはシステム開発に至った背景
- 提案依頼の要件:システムに求める機能や依頼したい業務内容
RFPを作成したら、受注候補の企業に送付します。
開発の提案や見積の発行
受注候補の企業は、受け取ったRFPを基にしてシステム開発のための提案書を作成します。このとき、一般的には受注候補が発注側に質問して、コミュニケーションをとりながら提案書を成形していきます。さらに、このときに、システム開発に必要なコストを計算して見積を出しておきます。書類が完成したら、受注候補の企業が発注側の企業に提案書を送付します。
発注側と受注候補の合意
発注側の企業は、提案書を受け取ったのちに、実際に発注する企業を決めます。こうした発注依頼をする場合、通常は発注側の企業は複数の開発企業に打診して提案書を受け取ります。そのなかでもっとも自社の希望に近い提案書を受け入れて合意となります。
開発と納品
この段階になって、はじめてシステム開発が開始されます。受注側の企業は、作成した提案書のルールに沿ってシステム開発を進めていきます。システムが完成したら、発注側に納品します。
納品後のアフターケアー
これはRFPや提案書の内容にもよりますが、納品後に受注側の企業が担当する領域の作業があります。例えば、下記のような作業があります。
- サーバーをメンテナンスする
- 発注企業の社員にシステムの使い方をレクチャーする
RFPの構成と盛り込むべき要素
RFPの構成と作成するときに盛り込むべき要素は、下記のとおりです。
- 提案依頼の概要
- 提案依頼の要件
提案依頼の概要
受注候補が提案書を作成する際に、発注企業の事業内容や現在抱えている課題を把握してもらう必要があります。さらに、システムを構築する目的といったことを記載しておくと、受注候補の理解が進みます。
- 自社の事業内容や課題
- 自社の設備状況
- システム開発するに至った背景
提案依頼の要件
具体的にどのようなシステムを作りたいのか、といったことをまとめていきます。具体的には、システムに求める機能や受注候補に求める作業内容を記述していきます。
- システムの全体像:システムのイメージ図などを作成する
- 機能要件:システムに必要な機能を記述する
- テスト要件:テスト機能が必要であれば要件を記述する
- 移行要件:新システム移行時の要望があれば記述する
- 教育要件:システム利用者に教育が必要であれば要件を記述する
- 運用者の情報:システム運用のメンバー構成を記述する
- 依頼する作業内容:役割分担や依頼したい作業を記述する
ただし、発注側企業の目的や狙い、または受注候補との関係性によっては記述するべき要素が変わってきます。例えば、発注実績がある受注候補であれば、発注企業の事業内容を把握しています。そのため、「自社の事業内容」を改めて説明する必要性が低いです。このように、実際にRFP作成に着手するときは、自社の環境に合わせて必要な要素と不要な要素を考慮してください。
RFPの具体的な書き方
RFPを作成するうえでの具体的な書き方をご紹介します。例えば、WEBメディアサイトのコンテンツディレクターを担当しているとします。そこで新たに「サイト訪問者がアンケートに答えるとプレゼントが当たる企画」を実施するための簡易的な特設サイトを設置することになりました。
この場合は、特設サイト設置のためにドメイン取得からはじまり、WEBサイトやサイトを運営するためのCMS(Contents Management System)の構築といった作業が発生します。さらに、その特設サイトではアンケート機能を実装することになります。この場合は、RFPに記載するべき「提案依頼の要件」としては下記のような内容が挙げられます。
- 依頼する作業内容
- システム導入後の業務分担
- システム概要
- 機能要求
- スケジュール
提案依頼の概要
- 自社でプレゼントキャンペーンを実施する旨
- 自社メディアにキャンペーンページを設置する旨
- アンケートを実装してキャンペーン応募者の個人情報を収集したい旨
- CMSで参加者の個人情報を閲覧、または管理したい旨
提案依頼の要件
依頼する作業内容
- ドメイン取得といった、受注側が担当する作業範囲
- ドメインアカウントやパスワードといった、納品してほしいものの一覧
- 開発時の使用言語といった、技術要件
システム導入後の業務分担
- サーバーメンテナンスといった、受注側が担当する作業範囲の一覧
- 特設サイト運用といった、発注側が担当する作業範囲の一覧
システム概要
- システムの全体像
- 特設サイトのサイトマップ(別添資料など)
- トップページのページ構成(別添資料など)
- キャンペーンページのページ構成(別添資料など)
- CMSのサイトマップ(別添資料など)
- CMSのページ構成(別添資料など)
- 新規キャンペーンページの生成方法
- Googleインデックスの対象ページ
機能要求
- システムに対する機能要求の全体像
- アンケート結果をDBに蓄積するといった、特設サイト機能要求の一覧
- アンケート結果をCMSで閲覧するといった、CMS機能要求の一覧
スケジュール
- いつまでに納品してもらいたいのかといった、希望スケジュール
RFPに関するよくある質問
RFPに関して、よくある質問をQ&A方式で解説します。
Q:RFPは誰が作成するのですか?
Answer)ある程度は技術面のことを理解している人物でないと、RFPの作成が困難です。そのため、自社内におけるシステム企画の関係者が作成します。部署でいうと、オンラインやデジタル領域を管轄する情報処理事業部やWEB事業部といったものなどが挙げられます。
Q:RFPと要件定義は何が違うのですか?
Answer)RFPと要件定義は、システム開発の工程を決めるための書類という側面では似ています。ただし、両者は作成者と書類の目的が異なります。
前者は発注側が作成するもので、受注候補に提案書の送付を求めるためのものです。後者は開発側が作成するもので、発注側の要望を達成するために実施すること技術的な観点でまとめた定義書類です。この2つの書類は、重複する部分が多くなるのですが、要件定義の場合は開発者が作成することもあって、通常はRFPよりも具体的で詳しい内容になります。
Q:RFPとRFIの違いは何ですか?
Answer)RFPとRFI(Request For Informatio)は、情報をまとめた書類送付を求める点では共通しています。RFIは、日本語で情報提供依頼書と訳され、開発会社に実績やサービス内容といった情報の提供を求めるための書類です。そのため、作成者は情報収集がメインの目的となり、開発会社としては書類にまとめるべき要素がRFPと異なります。
Q: RFPとRFQの違いは何ですか?
Answer)RFQ(Request For Quotation)は、見積書依頼書と訳されるとおり、いわゆる見積を依頼するための書類です。通常は、RFIやRFPとセットで作られ用いられます。具体的には、RFPを作成してシステム開発の提案書を求める際に、同時にRFQも用意して見積も出してもらいます。
まとめ