RFP(提案依頼書)の書き方 記載する7つの項目と作成の進め方

RFP(Request For Proposal、提案依頼書)は、システム開発を頼みたい側が、候補のベンダーに「この内容で提案と見積もりを出してください」と求める文書です。何を書くかで、返ってくる提案の質が変わります。IPA(情報処理推進機構)の「情報システム・モデル取引・契約書」に載っている記載事項に沿って、書き方を整理します。

RFPとは

IPAの文書は、ユーザ企業がベンダにシステム開発の提案を求める文書をRFPと定義しています。ベンダはこれに対して提案書を作り、ユーザはその内容を総合的に判断してベンダを選びます。ベンダー選定の全体像はベンダー選定とはにまとめています。

RFPには、大きく分けて二つの用途があります。

• システム化の方向性やシステム化計画を実施するためのRFP。未確定の事項があってもよいとされる。
• 要件定義以降の作業を頼むためのRFP。どのようなシステムで何ができるのかを、要件定義として明確に表現する必要がある。

後者について、IPAの文書は「表現されていない要件はシステムとして実現されない」と書いています。また、オープンな調達では、要件定義を明確にする責任はユーザにあるとしています。

RFIとの違い

項目	RFI(情報提供依頼書)	RFP(提案依頼書)
目的	RFPを作るために必要な情報を集める	提案と見積もりを求める
求める内容の例	IT技術動向、パッケージ情報、開発方法論、価格情報	提案書、見積書
依頼先	ベンダのほか、関係先や業界団体の場合もある	候補に選んだベンダ
注意点	依頼先が必ずしもRFPの提出先になるとは限らないことを伝える	要件を明確にし、契約条件も示す

RFIは必ず出すものではなく、IPAの文書は「出す場合がある」としています。

RFPの記載事項

IPAの文書は、RFPの基本項目を次の7つで示しています。詳細な項目一覧は、同じ文書の別紙に載っています。

1. システムの概要(基本方針): 開発の経緯、基本方針、狙いとする効果を書く。
2. 提案依頼の手続き: 提案書を出すときの事務手続きや条件を指定する。
3. 依頼事項: RFPの中核。ベンダが責任を持って見積もれるように、機能要件だけでなく非機能要件も明らかにする。
4. 開発体制・開発環境: 作業の環境条件と、ユーザ・ベンダの役割分担を示す。
5. 保証要件: 提案書の提出を受ける時点で明らかにしておきたい、システムの保証要件を示す。
6. 契約事項: 契約書に入れたい重要事項を、先に示しておく。
7. その他: 必要に応じた特記事項。RFPへの返答にかかる費用の負担や、提供した情報の扱い(自由に使えるか、守秘義務があるか)も説明する。

また、RFPを書くときは、ユーザ企業の現況と環境をきちんとベンダに伝えないと、適切なシステム構築につながらないとされています。

契約事項に書くこと

6番目の契約事項について、IPAの文書は次の点を先に明らかにしておく必要があるとしています。

• 契約の類型(準委任か請負か)
• 再委託
• 損害賠償責任(範囲、限度額、期間)
• 知的財産権の帰属
• 第三者ソフトウェアの利用
• 検収・支払いの条件

請負と準委任の違いは、ラボ型開発とはで民法の条文に沿って扱っています。

非機能要件

非機能要件とは、機能そのもの以外の要件のことです。IPAの文書は、性能要件、運用のSLA(サービス水準)の要求事項、セキュリティ・障害対策などを例に挙げ、外部設計の途中で新しく出てくる要件があることにも注意を促しています。最初から全部を書き切れなくても、分かっている範囲を書き、残りは未確定として示します。

メリットと注意点

• メリット: 全候補に同じ条件を渡せるので、提案と見積もりを同じ物差しで比べられる。
• メリット: 契約条件を先に示すと、契約の段階での食い違いが減る。
• 注意点: 要件が曖昧なまま出すと、各社が違う前提で見積もる。比べにくくなるうえ、後から追加の費用になりやすい。
• 注意点: 要件定義の前の段階の見積もりは、IPAの文書では「確定見積」ではなく参考値として扱われる。

向いている場面・向いていない場面

RFPが向いているのは、複数社の提案を比べたい場面や、金額と影響が大きい案件です。

要件がほとんど決まっていない段階では、いきなり詳細なRFPを作るより、方向性を整理する作業を先に頼む形が合います。IPAのモデルでは、システム化の方向性、システム化計画、要件定義の段階を準委任契約としています(理由は、成果物がこの時点では具体的に定まらないため)。

作成の進め方

1. 目的と効果を書く。なぜ作るのか、どの業務を変えたいのかを、現状と合わせて整理する。
2. 業務部門とIT部門で分担する。IPAの文書は、どの項目をどちらが担当するかの分担表も示している。
3. 機能要件を書く。誰が、何を、どの手順で行うかを業務の流れで書く。
4. 非機能要件を書く。性能、可用性、セキュリティ、運用の条件を、分かる範囲で数字にする。
5. 契約事項と提案の手続きを書く。提案の期限、質問の受付方法、評価の観点を示す。
6. 質疑の期間を設ける。ベンダに不明点を文書で質問してもらい、疑義が残らないようにする(IPAの文書は、不明点があれば文書で質問することをベンダの側の務めとしている)。

候補の探し方はシステム開発会社の探し方にあります。紹介を受けられるサービスとして、大全にシステム幹事と比較ビズが載っています。

よくある質問

RFPは必ず作らないといけませんか。

IPAの文書は、ベンダ選定の一般的な流れとしてRFPを示していますが、作らなければならないという決まりを示しているわけではありません。案件の大きさに合わせて、書く範囲を決めます。

予算は書いてよいですか。

IPAの文書の記載事項には、予算を書くかどうかの指定はありません。書く場合も書かない場合も、各社が同じ前提で提案できるようにそろえることが大切です。

要件が固まっていないときはどうしますか。

IPAの文書は、要件定義の作成を支援してもらう準委任契約を結び、そこでできた要件定義書をもとにRFPを出す流れを示しています。

提案の費用は誰が持ちますか。

IPAの文書は、RFIについて、返答にかかったコストはベンダが持つことを事前に説明しておく例を挙げています。RFPでも、返答にかかる費用の負担を説明する必要があるとしています。どちらも、後で食い違わないよう、先に書面で伝えます。

次にやること

• 今の要件のうち、確定している部分と未確定の部分を、二列で書き分ける。
• 上の7項目に沿って、見出しだけのRFPの雛形を作る。
• 契約事項の6点(契約の類型、再委託、損害賠償、知的財産権、第三者ソフトウェア、検収・支払い)について、社内の希望を決めておく。