提案依頼書（RFP）の基本的な構成と作成するためのポイント

新しいシステムを作ろうと思って何社か候補の会社を呼んだとしても、口頭だけの伝達では情報が十分に伝わらないことが多々あります。
そのような事態が起きないよう、システム開発に関する要件をまとめたものが「提案依頼書」です。

今回は、提案依頼書の書き方と記載するべきポイントをご紹介します。

提案依頼書とは？

提案依頼書とは、発注する側が受託側の企業に対し、提案してもらいたい内容を記載した資料のことです。
「なぜお金を払う側の企業が説明資料を作らないといけないのか」と思う方もいらっしゃると思います。

しかし、提案依頼書の作成は双方のメリットにつながります。
提案依頼書を作らないでプロジェクトを進めると以下のような弊害が生まれてきます。

発注側の弊害

・話し合うたびに内容にブレが出る。
・確認作業が属人化してしまい、抜け漏れが発生する

受託側の弊害

・口頭で伝えられた要件を抜けもれなく取るのはほぼ不可能
・実際に作業をするエンジニアへ謝った情報が伝わる可能性が高い

上記のようにそれぞれの立場で不具合が生じる可能性がかなり高いので、提案依頼書の形でまとめておくのが最善だといえるでしょう。

では、提案依頼書にはどういった事項を盛り込めばいいのでしょうか。

提案依頼書（RFP）の全体構成

プロジェクト内容によって異なる部分はありますが、基本的な構成は以下のようになります。

全体像・提案の要件・その他の３項目に分別し、それぞれに紐づく項目を洗い出します。

基本構成をベースに、作成した提案依頼書の内容が問題ないかどうかを確認するためのチェックポイントが6つあります。

提案依頼書（RFP）作成時のポイント6つ

1.プロジェクト名を共有できているか

多くの場合、受託側の企業は複数のプロジェクトを同時に回しています。
提案依頼書に明確にプロジェクト名をつけていないと、重大な齟齬が生じる可能性があります。

どんな小さなプロジェクトでも「◯◯株式会社　社内システム開発計画」というようにプロジェクト名を決めて双方の企業で共有しましょう。

2.最低限必要な項目が盛り込まれているか

システムの全体像を把握する上で「目的」「成果」「予算」「スケジュール」は最低限必要な項目です。
これらが盛り込まれていないと、提案依頼書を作る意味がないでしょう。

可能であれば目標を具体的な数値にするとより有意義な資料になります。

3.互いの企業の役割が明確に記載されているか

どのような仕事でもそうですが、関わる企業がそれぞれどのような役割を担っているかを明確にする必要があります。
提案依頼書でも「発注側」「受託側」の役割分担を明確化することが重要です。

4.システム会社側で対応するメンバーが決まっているか

「受注するまではシステム会社の社長さんが対応してくれていたけど、受注が決まると急にエンジニアとのやりとりになって思うように進まなかった。」

このような現象は頻繁に起こります。
「プロジェクトを仕切る人はだれか」を契約前に確認するようにしましょう。

5.判断に迷っている部分を、受託側の企業に共有できているか

どこまで出来てどこが出来ないのかがわからないままに提案依頼書を作ることもあるでしょう。

そんな時は正直に「わからないこと」「迷っていること」を受託側の企業リストアップして伝えるようにしましょう。
自分だけで悩むよりも建設的な意見交換ができるはずです。

6.情報は共有できているか

提案依頼書を作成する時、自分の中で勝手に「専門家に向けてこのような情報は記載する必要はない」と判断してしまっていないでしょうか。
相手がどのような情報を求めているのか、どのような情報を知らないのかをこちらで判断するのは困難です。
少しでも有益と思う情報は積極的に共有するようにしましょう。

まとめ

最初から完璧な提案依頼書を作ろうと思ってもどう進めればいいかすらわからない方が大半でしょう。
「はじめから完璧なものは作れない」ことを前提とし、まずは早く作ってみて、周囲の意見を取り入れながら随時加筆修正する方式をとる方が合理的です。

提案依頼書はより良い提案をもらうことを目的に作成します。
目的を達成するために必要な事項が盛り込まれているか、常にチームで確認するようにしましょう。