誰でも分かるRFPの基本：18項目で網羅的に作成

情報システム部の存在意義は、ITサービスを通したユーザ利便性の向上にあります。ITサービスとは単一、もしくは複数のシステムによって提供されるものですから、新しいシステムを企画立案して運用に漕ぎつけるまでの流れは、情報システム部の主たる業務と言えるでしょう。

新しいシステムを構築するためには、企画段階で得た構想を要件レベルに具体化し、システム設計者に引き渡します。企画をした人間が設計・構築・テスト・リリースまで担当できるにこしたことはないのですが、上流工程を担当する人間はスキルセット上、高コスト（月単価150万円以上）であることがほとんどですし、そもそも社内でシステム実装スキルを有する人間を必要数確保できないという根本的な課題もあって、要件定義フェーズ以前と設計フェーズ以降では担当者が異なることが多いのが実情です。

そこで要件定義フェーズで整理したことを正確に設計フェーズにつなげるために用いられるのが RFP（Request For Proposal 提案要求書）です。RFPをうまく作成できるかどうかで、そのシステムの命運が決まると言っても過言ではありません。なぜなら、システムの実装内容だけでなく、自社とベンダーの責任関係を決めるインプットになる文書であり、RFPで書かれた内容に従ってベンダーは提案書と契約書を作成するからです。曖昧な表現や適切性に欠ける責任関係を記してしまえば、そのまま契約内容に跳ね返ってきます。

今回は「適切なRFPの作り方」というテーマで、「委託内容」と「契約スキーム」の2つに分けてRFPに必要とされる項目の記入方法を紹介します。あなたの会社にもRFPのひな形があるかもしれませんが、その内容が本当に妥当であるか、一度検証してみることをおすすめします。もし、足りない項目や考慮不足があるようでしたら、次の RFP作成までに修正しておきましょう。

ちなみに、RFPで示す各項目の内容は要件定義フェーズで全て決めている必要があります。RFPの項目をしっかり定義できていれば、それを記入するために必要な情報も明らかになります。つまり、要件定義フェーズで決めるべきことも自ずと決まってくるということです。

RFPで最初に定義する必要があるのは、委託内容に関する次の6点です。

委託範囲に関して定義すべき項目

• 委託範囲
• 納品成果物
• 体制・役割分担
• スケジュール
• 前提条件
• 応札要件

委託内容を確実に遂行するために、契約スキームに関する次の6点を定義します。

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

最後に、RFPに対する提案の手続きを指定します。RFPを受領した後、ベンダーが提案書を提出するまでに行われる以下の点を明記します。

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

特に納品方法では、紙媒体／電子媒体の数を指定します。容量を勘案し、提案書の一部（エグゼクティブサマリー／見積り明細など）を別途電子メールで受け取る方法もあります。受け取り側の都合に合わせて、納品期限は日にちだけでなく、時間まで厳密に指定しましょう。

ここまでに挙げた18点は、以下のリンク先で詳細説明をしています。はてブ500超の記事ですので、おそらく参考になるかと思います。興味のある方は御覧ください。

http://enterprisezine.jp/article/detail/3414