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

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

[吉澤準特，＠IT]

5　前提条件

　「前提条件」として、「コンプライアンス規定」「作業関連規定」「その他」を以下の観点で整理しましょう。

• 機密情報、個人情報の取り扱い
• セキュリティ対策
• プロジェクト作業場所
• 資料提供／返却ルール
• プロジェクト管理標準
• 開発標準

　ベンダーに委託する内容に「機密・個人情報」が含まれる場合は、取り扱いルールを必ず定義しなければなりません。

　「プロジェクト作業場所」をどこにするのかは、金銭的に大きなインパクトがあります。

　ユーザーが空室を提供できない場合、ベンダーは新しくプロジェクトルームを契約しなければなりません。20人を収容できるプロジェクトルームを山手線沿線で確保する場合、光熱費込みで月100万円以上は必要です。1年以上続くプロジェクトなら、1000万円以上の追加支出が掛かります。

　「プロジェクト管理標準」は、多くのベンダーが「PMP（Project Management Professional）」を提案してくるでしょう。

　しかし、クイック＆多段階リリースが求められるWeb系システムなどは、PMPで用いられる「EVM（Earned Value Management）」による進捗（しんちょく）管理だけでは実情を把握しきれないこともあります。その場合は、ベンダーに知見を積極的に提案してもらいましょう。

　ユーザー企業に「開発標準」があるなら、それを前提としてベンダーに提案してもらうと、過去に構築したシステムの共通仕様と合わせられます。

6　応札要件

　「応札要件」は、委託する業務をベンダーが遂行するために必要となる「条件」を提示します。

　個人情報を扱うシステムで「プライバシーマーク」と「ISMS認証（情報セキュリティ管理に関する認証）」を取得しているベンダーに限定して提案書を受け付ける、などです。官公庁の案件は、「CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）」のレベル3以上を応札要件としています。

　応札要件を指定することで、不測の事態が生じた際にも影響を最小限に抑制できます。

契約条件に定義する内容

• 契約形態（請負契約／準委任契約）
• 契約変更／解除ルール
• 契約有効期間
• 想定外事象発生時の対応（瑕疵担保責任）
• 業務委託料、諸費用、支払方法
• 成果物権利

　ユーザーのリスクを考慮すると、RFPで依頼する規模のシステム開発は請負契約を採用することが一般的です。

　しかし請負契約は、基本的に成果物の「著作権」はベンダーが所有し、改変や他社への譲渡（運用保守フェースでの他社による改変や引き継ぎ）を認めないとされることもありますので、注意が必要です

7　費用

　「費用」には、提案金額に関する「ルール」を示します。

　「費用総額／内訳を提案書に記載する」「資産と役務を分けて示す」「稼働前費用と稼働後費用を区分する」「見積もり内容は『システム一式』ではなく『明細』と『価格』を記載する」、など期待することをはっきりとRFPに記載します。

　共通の「見積もり入力シート」を各ベンダーに配布すると良いでしょう。

8　提案手続き

　「提案の手続き」は、ベンダーが提案書を提出する際のルールを記します。

• 提案書を提出する窓口
• 納品方法
• 納品期限
• RFPに関する問い合わせ窓口
• 提案受領後の選定プロセス
• 選定結果の告知

　「納品方法」は、紙媒体／電子媒体の「数」を指定します。容量を勘案し、提案書の一部（エグゼクティブサマリー／見積もり明細など）を別途電子メールで受け取る方法もあります。

　納品期限は日にちだけでなく、「時間」まで厳密に指定しましょう。