RFPとは何か？RFP作成の目的、構成と目次案を解説

2020年4月7日

RFPとは

RFPとは“Request for Proposal"の略で、日本語では「提案依頼書」と呼ばれます。
企業や役所、大学などが外部にソフトウェア開発やWebサイトのリニューアルなどを委託しようと考えている時に、このRFPが作成されます。
RFPを作成するのは、なにもソフトウェア開発やWebサイトのようなITシステムを導入するときに限らないのですが、今後IT導入がますます増えていく中で、ITシステム導入のためのRFPを作成する人も多くなってくることが予想されます。
今回はこのRFPの目的と作成方法を構成と目次案を含めて解説していきます。

RFPについては動画でも解説しています

今回の内容については、動画でも解説していますので、ぜひご覧ください。

RFP作成の目的

なぜRFPは必要なのか

RFPはなぜ必要なのかから話をはじめていきましょう。
ソフトウェア開発を外注する場合でもなんであっても、RFPがないと発注できないというわけではありません。
では、なぜ人はわざわざRFPを作成するのでしょうか。
その理由をまとめると以下のようになります。

  1. 複数の業者から提案を受けるため
  2. 発注側（依頼側）とベンダー（受託側）との認識の差を小さくするため
  3. 公正なプロジェクトをスタートさせるため

ここからはこれらの内容を詳しく見ていきましょう。

複数の業者から提案を受けるメリット

RFPの最大のメリットは、複数の業者から提案を受けられるようになることです。
RFPがないと、今までお願いしていた業者に継続して依頼したり、少数の業者に提案してもらうことしかできません。
こうした状態では優れた提案を受けられる可能性が低くなってしまいます。
そのため、RFPを作成して広く提案を呼びかけ、画期的な提案を受けられるようにしていきます。

認識の差を小さくする

これからソフトウェア開発やWebサイトリニューアルを依頼しようとする発注者とその開発・制作を請け負いたいベンダーとの認識の差異を極力減らすというのも、RFPの重要な役割です。
RFPがないと、発注側の担当者の口頭での説明だけで開発内容の要件がベンダー側に伝わり、アバウトな見積りでプロジェクトをスタートさせないといけないこともあります。
その結果、プロジェクトがはじまってから「このような機能をつけるのであれば追加料金だ！」とか「そんな要望聞いていなかった！こんな期間では作成できない！」という事態に陥ってしまうこともあります。
こうしたトラブルを防ぐためにも、RFPを作成し、依頼内容を明確にしておくことが大切です。

公正なプロジェクトをスタートさせるため

RFPがない場合、既存の業者に依頼することが多くなりがちです。
その結果、適正な見積りにならなかったり、無駄な作業が発生したりすることもないわけではありません。
こうした不正を排除するためにも、広く提案を受けることが大切になり、それを支えるRFPが不可欠になります。

RFPのテンプレート（ひな型）について

こうしたRFPについては、さまざまなテンプレート（ひな型）が世の中に公開されています。
注意しなければならないのは、RFPは業種によって少しずつ内容が異なることです。
そのため、RFPのテンプレートを選ぶときには、しっかりと自分が求めている業種にあっているかどうかを確認する必要があります。
もしこれから導入しようとしているのがソフトウェア開発やWebサイトである場合は、以下のIPAがWebサイト上で公開しているRFPのひな型を使用するのがよいでしょう。

ここからは、上記のIPAのWebページで公開されている「RFP事例(要件定義)」に従って話を進めていきます。

RFPの構成と内容

RFPの構成

先ほどの「RFP事例（要件定義）」に沿っていくと、RFPの構成は以下のようになります。

  1. プロジェクト概要
  2. 業務・システム概要
  3. 機能要件
  4. 非機能要件
  5. 開発条件
  6. 提案依頼事項
  7. 提案手続き
  8. 評価
  9. 契約事項

これがRFPの目次案になります。
ここからは、各項目の内容を見ていきましょう。

プロジェクト概要

プロジェクトの背景、つまり戦略が目的を決定する。さらに前提条件がその目的の制約になる。

RFPではまずプロジェクトの概要を記載していきます。ここで記載する主な内容は以下の通りです。

  • プロジェクトの背景
  • プロジェクトの目的
  • プロジェクトの前提条件

プロジェクトの背景では、公開できる範囲で、何を意図したプロジェクトなのかを記述していきます。
例えば、「働き方改革の一環としてIT導入を進める」「販売力強化を行う」など、組織の大きな戦略の中で、これからスタートさせたい案件がどのような位置づけにあるのかを記載します。
そして、その大戦略の中でどのような目的をプロジェクトが持つのかを書いていきます。
例えば「入力作業の自動化を実現させる」「Webサイトにお問い合わせ内容にあわせたフォームを設置する」など、具体的なプロジェクトの目的を記載します。
最後に、プロジェクトの前提条件を記載していきます。多くの場合、この前提条件とは予算・スケジュールに関するものです。
つまり、いつまでに、どの程度の金額でこのプロジェクトの目的を達成させなければならないのかを記載します。

業務・システム概要

業務・システム概要では、現在の業務やシステムの概要や、求めている新規のシステムの概要を掲載します。
組織のすべての業務をここで記載する必要はありませんが、例えばお店に新規で予約システムを導入するようなプロジェクトであれば、どのようなスタッフがどのような業務フローで現在予約をとっており、それをどうしたいのかを記載していくとよいでしょう。
業務フローやシステムの説明は文章だけで表現することは難しいため、適宜業務の流れを図示しながら記述していくとよいでしょう。

機能要件と非機能要件

次に機能要件と非機能要件を見ていきましょう。
機能要件とは、これから開発するシステムが「どのような動作をするのか」をまとめたものです。
つまり、「お問い合わせの種類に応じて担当者にメールを送る」、「入力された金額を自動で計算する」といった機能です。
一方で、非機能要件というのは、動作以外で求められる性質を指しています。
例えば保守性を高めるための要件やセキュリティのための要件が非機能要件に該当します。
この機能要件と非機能要件については、下に掲載した過去の記事でも解説しているため、ぜひそちらもご覧ください。

開発条件

開発条件では、開発のために必要な条件を記載していきます。開発をするための、詳しい制約条件とも言い換えることができるかもしれません。
開発条件で記載する主な内容は以下の通りです。

  • 開発の特徴
  • 開発工数見積
  • 開発期間
  • 作業場所
  • 開発用コンピュータ機器・使用材料の負担
  • 貸与物件・資料
  • 納品条件

開発の特徴には使用するプログラミング言語など、開発を行う上での制約条件を記載していきます。
開発工数見積では企画の段階で業者から受け取った参考見積の内容などを記載していきます。
開発期間や作業場所については読んで字のごとく、期間や場所を記載していきます。開発したソフトウェアやWebサイトなどを受入れる際、組織内の特定のPCでしか受入れ作業ができないということはよくある話ですので、そうした条件を記載していきます。
開発用コンピュータ機器・使用材料の負担については、何か特別な機器や材料の用意が必要な場合は記載します。
貸与物件・資料については、プロジェクトが始まった際にベンダーに貸し出すモノや資料を記載します。ITプロジェクトでは、過去の開発資料などが非常に重要になるので、何を貸与して、何を貸与しないのかを明記しておくとよいでしょう。
最後に納品条件を記載します。納品条件では、どのような状態になったらこのプロジェクトが完了したと言えるのかを記載していきます。
例えばプログラミングコードのデータや設計資料などの納品物や、その納品方法などを記載していきます。

提案依頼事項

提案依頼事項は、実際にRFPを渡したベンダーに何を提案してほしいのかを記述していきます。
提案依頼事項の内容はプロジェクトごとに変わっていきますが、ソフトウェア開発の場合、例として以下のようなものが挙げられます。

  • システム全体概要
  • 提供機能と実現化方式
  • 運用条件
  • プロジェクトの体制
  • スケジュール
  • 定例報告およびレビューの方法
  • 開発管理・開発手法・開発言語
  • 見積り
  • 提案者情報
  • 提案者問合わせ窓口

この他、プロジェクトの体制の追加項目としてメンバーの経歴を求めたり、グリーン調達の項目を追加したりすることもあります。

提案手続き

提案手続きではRFPを受け取ったベンダーがどのような行動を起こすべきかを記述していきます。
主な記述事項は以下の通りです。

  • 参加資格条件
  • 提案スケジュール
  • RFP説明会・質問会
  • 質問期限
  • 提案書の提出
  • プレゼンテーション
  • 選定結果の連絡
  • 問合せ先

この提案手続きの内容を詳しく見ていきましょう。

参加資格条件

参加資格条件では、この案件を提案するために必要な資格や条件を記載していきます。参加のための資格としてよくあるのは、全省庁統一資格やPマーク、ISOなどです。
このような資格でなくとも、条件として「類似案件を完遂したことがある」、「10年以上の経験をもつ人物が担当につく」などの記述を加えることもよくあります。

提案スケジュール

提案スケジュールは文字通りの意味で、RFPを公開してベンダーを選定するまでのスケジュールを記述していきます。
最近ではWebサイト上で提案のための資料をすべて公開することもありますが、あまりオープンにしたくない情報などは、直接資料をベンダーに取りに来てもらうこともあります。
その資料がいつからいつまで受け取りができるのか、そして後述するRFP説明会・質問会、提案書の提出やプレゼンテーション、選定結果の連絡までどのような日程で進んでいくのかを記載していきます。

RFP説明会・質問会

RFP説明会・質問会はRFPの内容を説明し、簡単な質疑応答をする場です。
Web上で公開できない資料をRFP説明会・質問会で配布することもあります。
このRFP説明会・質問会の場所と日程を 提案手続きの内容に記述していきます。

質問期限

質問期限では、RFP説明会・質問会の参加者や公開されているRFPを見たベンダーからの質問をいつまで受け付けし、いつまでに回答するのかを記載していきます。

提案書の提出

提案書の提出は、ベンダーがいつまでに提案書を作成し、どのような形式で提出するのかを記載していきます。
例えば直接書類を持参しなければならないのか、それともメールでの提出でよいのかなどを記述していきます。

プレゼンテーション

資料だけでベンダーを選定するのではなく、プレゼンテーションを行ってもらう場合は、そのプレゼンテーションの日程を記載します。

選定結果の連絡

選定結果の連絡では、選定したベンダーをいつ・どのような形式で連絡するのかを記述していきます。

問合せ先

最後に問合せ先を記載します。担当者名と担当部署、メールアドレスと電話番号などを記載していきましょう。

評価

評価では、どのようにベンダーを選定するのかを記載します。
せっかくRFPを作成してまで、広くベンダーを募ったのに、最終的なベンダーの選定が「制作実績が多いから」という一面的な評価だったり、「担当者が話しやすそう」というフワッとした理由だと、今までの苦労が水の泡になってしまいます。
例えば、以下の項目をそれぞれ10点満点で採点し、総合得点で評価するなど、多面的で定量的な評価を行うことが大切です。

  • 業務への理解
  • 機能要件への充足度
  • 非機能要件への充足度
  • 提案の実現可能性
  • プロジェクト遂行力
  • 実績
  • 見積り金額

こうした評価方法をRFP作成の過程でまとめ、RFPに盛り込んでいきましょう。

契約事項

RFPの最後に契約事項を記載していきます。

  • 発注形態
  • 検収
  • 支払条件
  • 機密保持契約
  • 著作権等
  • 瑕疵担保・賠償責任

契約事項では、ベンダーを選定した後にそのベンダーとどのような契約を結んでいくのかを記載していきます。
これら契約事項の各項目の内容について詳しく見ていきましょう。

発注形態

発注形態では、どのような契約形態を結んでいくのかを明記していきます。
大まかに分けて、ITプロジェクトの契約形態には以下の２つの種類があります。

  • 請負契約
  • 準委任契約

請負契約は「○○の開発を××日までに△△円で開発してね」というように、成果物に対してお金が支払われる契約です。何かを開発していくのであれば、請負契約で問題ないでしょう。
一方で、準委任契約はコンサルティングのように、サービスの提供時間によって料金が発生する案件で結ばれる契約です。

検収

検収の項目では、どのような状態になった時に、検収を行うのかを記載します。
検収というのは、発注に応じて納められた品などを、注文の際の品質条件・数量・仕様に合っていると確かめた上で、受け取ることを指します。
この検収が発注側で完了したということは、ベンダーに対して、「制作してもらった内容には問題ありませんでした。ありがとうございました。」というようなもので、プロジェクトの事実上の完了式のようなものになります。
そのため、この検収をどのような状態になったら行うかは重要な問題です。
例えば、「すべてのテストを実施し、開発側で問題ないと判断され、検収依頼書を作成した後」や「すべての成果物が納品された後、１週間以内」などの条件を記載していきます。

支払条件

支払条件の項目には、どのような状態になったら発注側からベンダーに支払いを行うのかを記載していきます。
例えば「作業完了報告書とともに、請求書・納品書を発注側が受領した後」など、支払いの条件を記載します。
多くの場合、先ほどの検収が完了していなければ支払条件を満たすような書類の作成が許されないため、検収完了が支払条件の第一関門になることがよくあります。

機密保持契約

プロジェクトの大小にかかわらず、他の組織とプロジェクトを進めていくと、少なからず自分の組織の情報を相手に渡すことになります。
そのため、ベンダーが外部に情報を漏らさないように機密保持契約を結びます。
プロジェクトが開始する前であっても、提案依頼を受けるためにいくらかの機密情報を渡さないといけない場合は、事前に機密保持契約を結んでおくことも大切です。

著作権等

著作権等の項目では、プロジェクトで制作・開発する著作権の帰属について明記していきます。
「Webサイトをおしゃれにデザインしてもらったのはいいものの、著作権がすべてデザイン会社にあって他の広報活動につかえない！」というようなトラブルはよく耳にします。
これはソフトウェア開発であってもなんでも、著作権に関する記述がなければ、制作・開発した組織に帰属していてもおかしくはありません。
そのため、「完成したシステムの所有権、著作権、２次的著作物の利用権は対価の支払時点で弊社に帰属または移転されることを原則とする。」というような一文を加え、著作権ごと購入することを明記しておきましょう。

瑕疵担保・賠償責任

最後に瑕疵担保責任や賠償責任について記載していきます。
例えば「予約システムでお客さんを増やそう」というプロジェクトで開発・納品された予約システムが、予約はできるものの、条件によってはお客さんに通知メールが送られないという不具合が見つかったとします。
こうした不具合は検収が終わるまでには見つけておきたいものの、残念なことに検収や支払い後に見つかってしまった場合、どのくらいの期間までであれば修正に応じてもらうのかを示すのが瑕疵担保責任です。
そして、その不具合によって不利益を被った場合、どのような責任が発生するのかを示したのが賠償責任です。
ただし、先ほどの準委任契約では瑕疵担保責任が発生しませんので、その点は注意が必要です。

参考

書籍

  • 秋本芳伸、岡田泰子『90分で学べるRFPの作り方』日経BP 、2006年

Webページ

文書・資料RFP

Posted by promapedia