誰でも書ける！RFPの作り方を解説
新しいシステムやサービスを導入する際、どのベンダーに何をどこまで依頼するかを明確にするために欠かせないのが、RFP（提案依頼書）の作成です。
本記事では、押さえておきたいRFP作成の基本構成と考え方を整理しました。社内の合意形成とスムーズなベンダー選定につなげるポイントを分かりやすく解説していきます。
RFPとは？
RFP（提案依頼書）とは、新しいシステムやサービスを導入する際に、発注側がベンダーに対して「こういう提案をしてください」と求めるための文書です。RFPを作成することで、導入の目的や背景、求める成果などを自社で整理できるため、複数ベンダーの条件を比較しやすくなります。
プロジェクト開始前に作成しておけば、関係者の大まかな認識をそろえることが可能になります。
RFPの目的
RFPの目的は、発注側の期待や要件を文書として明確にし、ベンダーに「何を、どの程度まで実現してほしいのか」を正しく伝えることにあります。あいまいな口頭説明に頼らず、客観的な内容を社内で共有できるようになるため、ベンダーからの提案内容を比較検討しやすくなるでしょう。
後工程の手戻りや認識ズレのリスクを減らせるだけでなく、社内での合意形成を進める重要な材料にもなります。
RFPの作り方
- 提案書の目的
- 自社の概要
- プロジェクト概要
- システム化方針
- 機能要求
- 非機能要求
- その他の要求
- 契約内容
- 予算
- スケジュール
提案書の目的
今回のRFPで何を実現したいのかを端的に示します。新システム導入の背景や課題、導入後に期待する姿を整理し、ベンダーに目指してほしい方向性を明らかにしましょう。提案内容を評価する際の観点や重視したいポイントも簡潔に記載しておけば、複数社からの提案を比較しやすくなります。
発注側の意図を丁寧に言語化しておくことは、ベンダーとの認識ギャップの低減に有効。提案の質の向上も期待できます。
自社の概要
企業の基本情報をベンダーに正しく共有します。業種や提供サービス、従業員数、拠点数、主要な顧客層などを整理し、自社がどのようなビジネスモデルで収益を上げているのかを示すことが重要です。現在のIT環境や既存システムの構成、関連部門の体制なども簡潔に記載しておくと良いでしょう。
「自社の概要」を通じ、ベンダーは提案の前提条件をつかみやすくなるため、自社に合った提案内容につながりやすくなります。経営方針や中長期のビジョンにも触れておけば、先方にとってはパートナーとしての相性判断もしやすくなります。
プロジェクト概要
今回のシステム導入や業務改善の目的、対象となる部門・業務範囲、想定している利用者数などを整理して共有します。開始予定時期や完了目標時期、プロジェクト体制のイメージなども共有することで、ベンダーは必要な工数や役割分担を想定しやすくなります。
将来の拡張や段階的な展開も考えている場合には、その構想も簡潔に触れておくことをおすすめします。
システム化方針
スクラッチ開発かパッケージ導入か、クラウドかオンプレミスかといった基本方針を明確にします。既存システムとの連携方針、標準機能の優先度、カスタマイズの許容性などの考え方も示しましょう。
運用・保守の担当範囲や、将来の拡張の見込みに向けた方向性も記載しておけば、ベンダーは提案の範囲やアーキテクチャを整理しやすくなります。結果として、自社のIT投資全体のロードマップも描きやすくなるでしょう。
機能要求
新システムで実現したい業務機能を具体的に整理します。必須となるコア機能、できれば実装したい推奨機能、余裕があれば検討する将来機能など、優先順位を明示することが重要です。
現行システムで不便に感じている点や、追加したい機能の背景もあわせて記載しておけば、ベンダーは制約や期待値を読み取りやすくなります。結果、要件とのフィット感が高い提案を受けやすくなり、後からの大きな仕様変更も起こりにくくなるでしょう。
非機能要求
ユーザビリティや性能、拡張性、セキュリティ、保守サービスなど、システムの「使い勝手」や「品質」に関わる条件を整理します。画面操作のしやすさやレスポンス速度、将来の利用者増加に耐えられる設計かどうかは、日々の業務負荷に直結するポイントです。障害発生時の対応時間や問い合わせ窓口の体制など、運用・保守面で求めるレベルも明確にしておきましょう。
非機能要求を漏れなく明示すれば、自社の運用実態に合ったシステム提案につながりやすくなります。
その他の要求
設計・開発・テストの進め方や品質基準、レビュー体制など、プロジェクト遂行上の前提条件を整理します。たとえば、どの工程でどのようなテストを行うか、どう受け入れ条件を定義するかといった点です。
旧システムからのデータ移行方針や、ユーザー教育の方法・対象・実施時期なども明記しておくと、導入後の立ち上がりがスムーズになります。
契約内容
支払い条件や検収条件、保守費用の扱いなど、金銭・責任に関わる取り決めを整理します。成果物の著作権・知的財産権の帰属、仕様変更時の対応ルール、遅延や障害が発生した場合の責任分担も明確にしておくようにしましょう。
契約面の前提を具体的に示すことは、双方が納得できる協業関係の土台です。後々のトラブル抑制にもつながります。
予算
システム導入に充てられる概算金額や、その内訳イメージをできる範囲で示します。初期導入費用と保守・運用費用を分けて考えているのか、複数年度での投資を想定しているのかについても、ベンダーには重要な情報です。
厳守したい上限額、オプション提案に使える余裕枠の有無なども伝えておくと、ベンダーは提案内容とコストのバランスを取りやすくなります。結果、自社の投資感覚に合った現実的な提案を得やすくなるでしょう。
スケジュール
プロジェクト全体の開始時期、要件定義・設計・開発・テスト・移行といった各工程の期間、および本番稼働の目標時期を示します。社内の繁忙期や決算期など作業が制約される時期も明記しておくと、現実的な提案につながりやすくなるでしょう。
マイルストンやレビュー時期を事前に共有しておけば、ベンダーとの進捗確認や合意形成もしやすくなるため、プロジェクト遅延のリスク低減につながります。
まとめ
RFPは、自社の課題や期待を整理し、ベンダーに正しく伝えるための重要なドキュメントです。その作成にあたっては、まずこのページで紹介した「自社概要」「プロジェクト概要」「機能・非機能要求」などの項目をしっかりと押さえておきましょう。それぞれの項目の目的を整理することで、一定水準のRFPを作成することができます。
ただし、現場の制約や利害調整が絡んでいる場合、社内だけで理想的なRFPをまとめきるのは簡単ではありません。プロジェクトを前に進めたい場合は、PMO支援の専門会社に相談するという方法も選択肢の一つです。
以下のページではおすすめのPMO会社を紹介していますので、あわせて参考にしてみてください。
