Written by aki(あき)
ネットワークエンジニア
大手Nierでネットワークエンジニアとして最前線で戦う傍ら、個人運営のサイト「ネットワークエンジニアを目指して」を運営し、読者を「ネットワークトラブルに恐れることなく立ち向かえるネットワークエンジニア」へと導くことを信条に、ネットワーク技術の解説と自身のノウハウを広めている。著書に「見てわかるTCP/IP」など。Twitter:itbook
RFPに記載する内容
RFPに記載する内容は、企業形態や規模、立場などによって変わりますが、概ね次の内容を盛り込みます。
1. プロジェクト概要
1.1 プロジェクト名称
1.2 プロジェクトの目的と背景
1.3 プロジェクトの課題
1.4 プロジェクトの範囲
1.5 会社情報
2. 提案依頼内容
2.1 プロジェクトのゴール
2.2 システム構成
2.3 システム要件
2.4 プロジェクトスケジュール
2.5 プロジェクト体制
2.6 納品物一覧
2.7 制約事項
3. 選定事項
3.1 選定条件
3.2 提案書の提出先
3.3 提案書の提出方法
プロジェクト概要
まずベンダーにどのようなRFPなのかを理解してもらうために、プロジェクトの全体像をはっきりとさせます。プロジェクト概要には次のような情報を記載します。
プロジェクト名称
プロジェクト名の誤表記や誤認識を防ぐために、プロジェクト名を伝えて共通認識をもつようにします。
プロジェクト目的と背景
なぜRFPを行うのか?調達して何を実現したいのか?というプロジェクトの目的と背景を記載します。
システムの開発といっても調達したいシステムが、パフォーマンス向上なのか、機能の追加なのかなど、調達の目的によって規模や費用が大きく変わります。
プロジェクト目的と背景がブレていると、単に仕様を満たしただけのシステムを納品されて、結果的に期待した調達ができませんのでしっかりと共有しておくことが重要です。
プロジェクトの課題
今回の調達にあたり、現状の課題を洗い出し、その課題に対してどのように解決していきたいかを記載します。
もし、その課題に対しての解決案が思いつかない(検討できていない)場合は、解決策についても提案を依頼することを記載するのもよいかもしれません。
現状の課題を明確化しておくことによって、多くの開発を行っているベンダーから最適な解決方法を改善提案を引き出すことができますので、できるだけ現状の課題を明記するようにします。
プロジェクトの範囲
RFPに含まれる範囲を明確化します。プロジェクトの目的と背景を共有した上で、実際にどの部分を提案してほしいのかを明記します。
システムの開発においても、機器の購入、設置工事、システム開発、運用、保守と多くの工程があり、その中でどの範囲を提案して欲しいのかを明確化します。
プロジェクト範囲の明確化は、ベンダーからの工数や機器購入の見積もりに関わってきます。プロジェクト範囲を明確にしておかないと、正確な見積もりを行うことができず、結果的にプロジェクトが始まってから追加工数やプロジェクトの遅延が発生してしまう可能性があります。
会社情報
必要により会社の基本情報や組織図、システムを利用する部門の情報などを簡潔に記載します。
提案依頼内容
具体的にどのような提案を期待しているか、どのような情報を提案に盛り込んで欲しいのかを明記します。提案を依頼したい範囲や役割分担、必須機能、運用・保守内容、成果物などを明記します。
プロジェクトのゴール
構築したいシステムの全体像やゴールがあれば明記します。
パフォーマンスと拡張性を向上させたシステムを構築したいのであれば、どれぐらいのパフォーマンスと拡張性を目標とするのかを記載します。
システム構成
全体のシステム構成イメージを記載します。情シス側でイメージする構成なので、ベンダーごとにシステム構成は変わりますが、ベンダーに全体のシステム構成をイメージしてもらう必要がある場合に記載します。
システム要件
提案システムにおけるシステムの要件や機能の要件を記載します。提案するベンダーにとっては、ここに記載されている要件を満たすシステムを提案することになるため非常に重要な情報になります。抜け漏れがないように明記するようにしましょう。
記載する内容はシステムの規模や内容によってさまざまですが、一般的には別資料として要件一覧を作成し、システムごとに機能要件を明記していきます。
勤怠管理システムを検討しているのであれば、次のような要件を記載します。
* 勤怠管理のデータ項目は追加削除が可能なこと
* 画面応答時間は3秒以内とすること
* データのメンテナンス(バックアップ・リストア・最適化・削除)が可能であり、その方法を提示可能なこと
* データの整合性チェックを自動で行い、不備が存在した場合、エラー出力が可能なこと
* データをCSV形式およびPDF形式による出力が可能なこと
* 現行システムから停止せずに移行できること
* ドキュメントは日本語で提示可能なこと
* 保証年数(瑕疵担保期間)はリリースから1年以上であること
機能要件はできるだけ具体的に記載するようにします。あいまいな表現で記載すると、提案者側の解釈が入ってしまい、本当に実現したい機能が盛り込まれないリスクが増加するためです。
システム要件の洗い出しを行う場合は、「機能要求」「性能要求」「移行要求」「セキュリティ要求」「品質要求」「運用・保守要求」という6つの項目を軸に洗い出すと抜け漏れが減ります。
機能要求
* 現行システムの洗い出し
* 現行システムには無いが、追加したい機能の洗い出し
性能要求
* ユーザーの操作に関する性能や負荷
* 内部処理に関する性能や負荷
* 関連システムとの連携に関する性能や負荷
移行要求
* 現行システムからの移行に関して
* システムやデータの切り戻しに関して
セキュリティ要求
* 不正データ検出と回避方法
* 情報漏えいに対する回避方法
* セキュリティ被害に対する回避方法
* 社内セキュリティ基準への準拠
品質要求
* 障害時の他システムへの影響範囲
* 社内品質基準への準拠
運用・保守要求
* 障害解析の容易性
* 障害時の解析や機器交換への対応基準
システム要件詳細
大規模システムのRFPは、詳細な機能要件がある場合は、別紙等でシステム要件の詳細な内容を記載するようにします。
プロジェクトスケジュール
システム導入までのスケジュールを記載します。ここで記載するスケジュールはシステムのリリース日や開発期間といった大枠な内容ではなく、できるだけ具体的に記載するようにします。
具体的には次のような内容を盛り込むようにします。
* 提案書提出期限
* 各社の提案期間
* 選定期日
* 開発期間
* テスト期間
* 移行期間
* サービスイン期日
プロジェクト体制
提案者側のプロジェクト体制を明記するとともに、ベンダー側のプロジェクト体制の記載をお願いします。プロジェクト規模によっては、PMの指名や保有資格、経歴などの記載をお願いする場合もあります。
納品物一覧
提案資料として受領したい納品物を記載します。納品物の例としては次のようなものがあります。
* 基本設計書
* 詳細設計書
* プログラムソースコード
* 単体・結合テスト仕様書
* 単体・結合テスト項目書
* テスト結果報告書
* システム要件回答表
* 移行概要書
* 費用
制約事項
RFPに対して制約がある場合は明記します。
選定事項
どのように選定を進めるのかその情報を記載します。
選定条件
各社の提案の中から、どの提案を選定するのかを明記します。一例としては次のような内容になります。
* すべてのシステム要件を満たしていること
* テスト結果が要求した条件をすべてクリアしていること
* 要求した成果物をすべて提出していること
提案書の提出先
提案書の提出先(担当者の氏名やメールアドレスなど)を明記します。
提案書の提出方法
提案書の提出方法(メールでの送付なのか、郵送なのかなど)を明記します。
RFPの書くときに注意すること
RFPを記載する際に注意するポイントとして、絶対に守って欲しい項目とマストではないがあればうれしい項目など、「何がどれくらい重要なのか」をベンダーに伝える必要があります。
ここではRFPを作成する上で、意識すべきポイントについて説明していきます。
ベンダーが回答できるレベルで記載する
RFPにシステム要件を記載する場合、ベンダーが答えられるレベルで記載します。具体的には次の3つのポイントを意識するようにします。
こうしてほしい
「サーバー稼働率は99.9%以上にしてほしい」「システム構築は○月○日までに完了してほしい」など、具体的に「こうしてほしい」と記載する。
ベンダーは要求する内容に対して、対応可能なのかどうか、対応できない場合どのように対処するのかを回答することになります。
どのように
「どのようにプロジェクト体制を組むのかを提示してほしい」「どのように稼働率を向上させるのかを提示してほしい」など、ベンダーに対して「どのように」してほしいのかを記載する。
ベンダーは最適だと思われる内容を回答することになります。
いつまでに
「いつまでに、システム試験が可能になるのかを提示してほしい」「いつまでに、スケジュールが確定するのかを提示してほしい」など、特に時期を意識して記載する。
ベンダーは対応可能な時期を回答することになります。
システム要件が固まっている場合は、「こうしてほしい」という内容を記載しますし、要件が固まっておらず、ベンダーから最適な提案を求めたい場合は「どのように」という内容を記載するようにします。
要件ごとに重要性を明記する
さまざまなシステム要件についても、重要性を伝えるようにします。「絶対に盛り込みたい機能」と「できれば盛り込みたい機能」など、重要性をベンダーに伝えることでより最適な提案が期待できます。
機能だけでなく、スケジュールも「絶対に死守しなければいけない時期」と「できれば遵守したい時期」など、重要度がある場合は明記するようにします。
まとめ
以上、RFPの書き方を紹介しました。ここで紹介した内容はあくまでも基本的なものですので、企業の特色や規模によって、盛り込む内容も変わります。ご紹介した内容を参考に、追加すべき内容がないか、不要な内容がないかを洗い出してみると、一層「使えるRFPのひな形」になると思いますのでぜひ実践してみてください。
関連する記事