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

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

[吉澤準特，＠IT]

　システム自体や作成文書に不備がないことをベンダーに必ず保証してもらいたい場合、契約形態は「請負契約」が適しています。そうでないものは「準委任契約」とします。

1　委託範囲

　「委託範囲」で依頼したい提案の「概要」を定義します。「案件目的」「業務概要」「システム化の範囲」「全工程のスケジュール」が当たります。

　「契約委託範囲」「機能、非機能要件」「作業要件」も明文化します。

必須記述項目

• 対象業務名
• 対象システム
• 調達対象の内容
• 情報システム要件
• 規模／性能要件
• 信頼性要件
• 情報セキュリティ要件
• テスト要件
• 移行要件
• 教育／研修要件
• 保守／運用要件

　上記は、必須記述項目です。提案書にどんなプラスアルファを盛り込んでくるかはベンダー次第ですが、最低限の水準は必ず示しましょう。

2　納品成果物

　「納品成果物」は、契約後の「成果物一覧」と、その「納期」です。

　納品成果物の「検収方法」もRFPで指定しましょう。「工程ごとの成果物（検収物）」を指定し、「ユーザー承認に要する期間」も示します。

3　体制、役割分担

　「体制、役割分担」では、委託業務を推進する体制、委託者と受託者の役割／責任分担を定義します。

　「体制図」「役割分担表」「再委託（二次請け以降）の扱い」を指定し、「現場管理責任者」の提示を求めます。

　重要なのは、委託するユーザー企業がベンダーをどれだけ主体的に管理できるかです。

　多重請負構造では、ユーザーやプライムベンダー（直接契約する一次請けベンダー）の統制が現場の二次請け以降のメンバーにまで浸透しないことがあります。これを防ぐため、「参画メンバーはプライムベンダーとその協力会社（二次請け）までに限る」という制約を設けることもあります。

4　スケジュール

　「スケジュール」は、委託業務の「実施スケジュール」を定義します。

　「マスタースケジュール」「マイルストーン」「各タスクの終了条件」を指定し、「順守すべき期日」をベンダーに示します。

　各マイルストーンの達成承認における「合意形成のリードタイム」と「段取り」は、可能な限り明確化しましょう。意思決定の合意形成に1カ月必要なら、それに関係するマイルストーンは実質1カ月前倒しで設定しなければなりません。