明瞭な「提案依頼書（RFP）」の書き方：「訴えてやる！」を未然に防ぐ（1/4 ページ）

システム開発に先立ってユーザーがベンダーに提出する「提案依頼書（RFP）」。ここであいまいな表現やヌケがあると、後々トラブルになることもあります。連載「エンジニアのためのビジネス文書作成術」、第3回目は「RFP」の書き方と、Wordの「スタイル」を活用して「RFP」を見やすくするコツを伝授します。

[吉澤準特，＠IT]

連載「エンジニアのためのビジネス文書作成術」は、書籍「外資系コンサルのビジネス文書作成術」（吉澤準特著　東洋経済新報社）を基に、出版社の許可を得て、筆者自身が＠IT読者向けに再構成したものです。画像はWindows 7 + Word 2013上のものです。機能はWord 2013、2016のいずれでも使用できます

　連載「エンジニアのためのビジネス文書作成術」、第1回は「議事録」の書き方を、第2回は「要件定義書」の書き方を学びました。第3回は「提案依頼書（RFP）」をWordで作ります。

　提案依頼書（RFP）とは、発注者（ユーザー）が、自分たちが提案してほしいことを具体的な「内容（要件）」にまとめた文書です。受注者（ベンダー）が「提案書」を作成するためのインプット（材料）になります。

　RFPはシステムの「実装内容」だけでなく、自社とベンダーの「責任関係」を決める文書です。「役割分担」は、そのまま契約内容に跳ね返ります。曖昧な表現や適切ではない割り振りは厳禁です。

　以下は、RFPが曖昧だったために、発注者の意図と違うものが作られた例です。

提案依頼内容	⇒	ベンダーの考えたもの	⇒	その結果
アジャイル開発で多段階リリースすること by開発部長	⇒	アジャイルだから設計書を作らなくてもよい	⇒	メンテナンス大混乱
稼働後障害を起こさないシステムを構築すること by金融機関CEO	⇒	バグゼロにするからテスト工数「4万人月」	⇒	プロジェクトコスト青天井
敵モビルスーツの攻撃を防ぎつつ反撃できる武器を開発すること byオデッサ基地司令	⇒	防御中に攻撃するから盾の中にミサイルを搭載	⇒	相手の攻撃で盾内のミサイルが誘爆

　こうした思い違いを防ぐには、ユーザー、ベンダー双方が「委託範囲」をよく理解しなければなりません。「何がベンダーからユーザーへ引き継がれ」「どういった体制・スケジュールの下で行われるか」も明確にする必要があります。「提案ルール」も一緒に提示すれば、ユーザーの期待した形でベンダーは提案できます。

RFPに含める項目

　RFPは次のような章構成で作成しましょう。

RFPの章構成

1. 委託範囲
2. 納品成果物
3. 体制・役割分担
4. スケジュール
5. 前提条件
6. 応札要件
7. 費用
8. 提案手続き

　サンプルとして、ITコーディネーター協会が発行する「RFPのドキュメント見本（開発編／運用保守編）」を参照すると良いでしょう。

　ベンダーはこのフォーマットに慣れ親しんでいますので、似たような形でRFPを示せばベンダーの提案負荷を減らせます。また、「検討漏れ」を未然に防ぐことも期待できます。

　次ページから、各章の内容を見ていきます。