システム開発を外部企業に依頼するにあたって、RFP（提案依頼書）はプロジェクトの成功の鍵を握る重要な文書となります。
良いRFPは、開発会社から最適な提案を引き出し、プロジェクトのリスクを抑える役割を果たします。
本記事では、主にオフショア開発を検討している企業担当者様に向けて、RFPを作成する際の具体的な手順と注意点について解説します。
Contents
RFP（Request for Proposal）とは？
RFPとは、Request For Proposalの略です。日本語では提案依頼書と呼ばれます。
企業がシステム開発など特定のプロジェクトの推進を外部企業に発注するにあたって、発注先候補のベンダー企業から最適な提案を引き出すことを目的とした文書です。
また、RFPの作成は、自社の課題やニーズを明確にすることにより、社内での認識合わせなどにも役立ちます。
RFPには、プロジェクトの全体像や具体的なシステムの要件などが記載されます。発注先候補となるベンダー企業は、このRFPを各社読み解き提案を行います。発注企業はその提案内容を比較・評価して自社にとっての最適なパートナーを選定します。
オフショア開発を初期から検討している場合も、しっかりとしたRFPを作成することが重要です。RFPを使って明確に要望を伝えておくことは、オフショア開発のプロジェクトを進める中で起きがちな、文化の違いによる齟齬発生などを防ぐことにも繋がります。
RFPとRFIの違い
RFPとよく混同されるものにRFIがあります。ここで、RFPとRFIの違いについても理解しておきましょう。
RFIは、Request for Informationの略です。日本語では情報提供依頼書などと訳されます。ベンダー企業から、会社の基本情報や技術情報などを提供してもらうための文書です。
流れとしては、まず、RFIにて複数のベンダー企業の情報を収集します。収集情報をもとに軽くスクリーニングをかけて、候補に残ったベンダー企業にRFPを渡し、具体的な提案をしてもらいます。 そのため、RFIを作成するタイミングは、RFPよりも前になります。
ちなみに、筆者はこれまでベンダー企業側で多くの提案活動に携わってきましたが、ここ数年はRFIを受け取ることは少ない傾向にあるように思います。これはRFIの本来の目的である「（RFP共有先企業の選定にあたって）企業の技術情報や製品情報、企業情報を得ること」が、コーポレートサイトの閲覧だけで達成できることが多いからだと考えます。
また、一般的にRFIの作成は必須ではないので、対応領域や言語などを知りたい会社があれば、直接コンタクトフォームなどから問い合わせをしてみるのも一つです。
RFP作成の前に準備すべきこと
RFPの内容や作り方に細かいルールはありません。しかしながらRFPを作成する前に、いくつかの準備を適切に行えば、RFPの精度をより高めることができます。
プロジェクトの社内の立ち位置や方向性の明確化
RFPを作成する前に、まずそのシステム開発プロジェクトの社内の立ち位置や方向性をしっかり整理することが大切です。
実務を担当するメンバーと話し合って、具体的な要件や目標を明確にする事ももちろん重要です。しかし組織として投資を行う以上、短期的な課題解決や成果だけでなく、企業全体の成長や競争力向上を見据えた意図が含まれていることを忘れずに、まずは広い視野で整理していきましょう。
例えば、経営陣がこのプロジェクトに対してどのような成果を期待しているのか、またそれが会社の長期的なビジョンや戦略とどう結びついているのかを確認することが重要です。
是非この段階で、経営陣あるいは経営陣直下のチームとコミュニケーションをとり、該当プロジェクトやシステムに対する経営陣の考えをヒアリングしてください。経営陣が捉えている課題や目的、プロジェクトへの期待値を早期にキャッチアップすることが、プロジェクトの方向性をより明確にし、RFP作成やベンダー選定をスムーズに進めてくれます。
筆者は経験上、いかに初期段階で経営陣を巻き込めるかどうかが、システム開発プロジェクトの成功を左右すると感じています。「経営陣はこう思っているだろう」という憶測だけでベンダー選定を進めてしまうと、提案の最終段階やプロジェクト開始キックオフ段階で話が覆ることもあり得ます。
社内ステークホルダーの課題とニーズの整理
経営陣へのヒアリングと、ヒアリング内容を基にした整理が完了したら、次に社内の各ステークホルダーと連携していきます。課題やニーズを吸い上げ、システムの方向性をより具体的に固めていきます。
社内ステークホルダーとして連携すべき部門には、以下のようなものが挙げられます。
- 営業部門
-
営業部門のメンバーは日々顧客の声をダイレクトに聞いている立場です。該当のシステムをどう思っているかや、利用する上での不満が何なのかなど、顧客の生の声を営業部門から吸い上げると良いです。既存顧客はもちろん、受注に至らなかったリード顧客の声も是非このタイミングで上げていきましょう。
- カスタマーサクセス部門
-
顧客満足度の向上や顧客との継続的な関係構築を担当するカスタマーサクセス部門からは、顧客のニーズや問題点について直接的なフィードバックを収集できます。カスタマーサクセス部門は問い合わせ内容の集計をしているところも多いので、是非そういったデータも収集すると今後の意思決定に役立ちます。
- マーケティング部門
-
マーケティング部門には数値分析やレポーティングを依頼することをお勧めします。アクセス解析により明らかになった現システムの課題などを基に、新しいシステムで改善すべき目標やKPIを整理していきます。
- 開発・情報システム部門
-
開発部門あるいはシステムを管理する情報システム部門からは、システム開発における技術的要件に関する専門的な意見を集めます。
現在のシステム構成の問題点や改善点といった現行システムの評価や、システム構成図、セキュリティ要件のキャッチアップが必要になるでしょう。
各部門からの意見を集約し、それらを整理してRFPに反映させることで、プロジェクトの成功に向けた強固な基盤を築くことができます。
ただし、一点注意して欲しいのは、全員の意見を取り入れたものが決して良いシステムではないということです。顧客やステークホルダーの意見をそのまま取り入れたものの、結局あまり使われなかったというのはシステム開発においてよく聞く話です。また、全ての意見を取り入れたシステムは逆に使い勝手が悪くなる可能性も高まりますし、開発費用がいくらあっても足りません。
重要なのは、該当システムの目的や戦略、各部門からの要望を実現することによる効果の大きさなど、複数の観点から、収集した情報や意見に対して優先順位付けしていくことです。
RFPの構成要素となるもの
以下がRFPの構成要素です。システムの特徴やベンダー企業への依頼内容などによって、内容の濃淡や順番などは自社に最適化してください。
- 提案依頼の概要
- システム構築方針
- 現行システムの課題と解決
- 機能要件
- 非機能要件
- 設計・開発・テスト要件
- 提案要領
RFPの具体的な作成方法・書き方
この時点である程度システムの課題やあるべき姿の大枠が見えてきているはずです。ここからは具体的にRFPを作成していくフェーズに入ります。
提案依頼の概要
提案依頼の概要では、本書の目的や貴社の会社概要、プロジェクトの目的、背景、ゴール、範囲といった内容を簡潔に記述します。この部分は、ベンダーがプロジェクトの全体像を把握するために必要な情報となります。
システム構築方針
システム構築方針では、新システムの基本的な設計思想や方向性を示します。この項目は、社内の開発部門・情報システム部門と密に連携して内容を決めてください。
書き方としては、まずシステムの採用する技術やアーキテクチャの方針を明記します。
将来的な拡張性や統合の可能性もあれば触れておくと良いでしょう。
また、新システムではなく既存システムのリニューアルの場合は、現行システムの構成などもわかる範囲で明記してください。
ちなみに、社内にエンジニアがいないため具体的な技術に触れられないというケースもあるかもしれません。その場合は、無理に言語や技術を全て自社で決め込む必要はありません。
筆者がこれまで携わった提案活動でも、言語の指定などがないケースは多くありました。システムで「何がしたいか」をRFPの中で明らかにしておけば、細かい技術周りについてはベンダー企業が最適な提案してくれるケースが多いので安心してください。
現行システムの課題と解決
続いて、現行システムの課題と解決についてです。箇条書きなどで簡潔に現行システムの解決したい課題について明記していきます。基本的には項目は複数個上がるはずです。
ポイントとしては、定量的に書ける部分はできるだけ定量的に書く事です。例えば「入力に時間がかかる」という課題があれば、具体的に「○秒かかる」のかもあわせて書くイメージです。
他にも、マーケターから共有を受けたアナリティクスレポートや、カスタマーサクセス部門から共有を受けた実際の問い合わせ内容など、補足できる情報があれば是非添付してください。
機能要件
機能要件とは、システムが実現すべき具体的な機能のことを指します。例えば、以下のような項目について言及していきます。
ECサイトシステム構築の場合
- 商品管理
- 商品登録：商品データをシステムに登録できる
- 商品情報更新：既存の商品データを更新できる。
- 商品カテゴリ管理：商品カテゴリを追加・編集・削除できる。
- 在庫管理：商品ごとの在庫数を管理し、在庫切れの通知を設定できる。
機能要件は自社の開発部門や情報システムなど、システムの技術面を担当する部門と全面的に協力して作成してください。
機能要件は、明確な表現を心がけ、何がしたいかが簡潔にわかるように明記してください。また、1項目に対して1つの要件になるように記載していきます。
機能要件は、非開発会社にとっては聞き馴染みがないかもしれませんが、システムの具体的な要件が決まる大事な項目です。要件が曖昧だと、ベンダー企業からの提案の精度が低下し、後々予算が膨らむ可能性が高くなります。そのため、しっかりと要件を決めていきましょう。
非機能要件
非機能要件とは、システムの機能以外の側面に関する要件を指します。具体的には、パフォーマンス、セキュリティ、信頼性、可用性、拡張性など、システムがどのように動作すべきかに関する要件です。非機能要件は、システムの品質や運用面で非常に重要な要素です。例えば、以下のような項目について言及していきます。
ECサイトシステム構築の例
パフォーマンス
- 応答時間：ユーザーからのリクエストに対して、システムが2秒以内に応答すること。
- 同時接続数：システムは、ピーク時に1,000人の同時アクセスを処理できること。
セキュリティ
- データ保護：顧客の個人情報は、暗号化された状態で保存されること。
- 認証・認可：ユーザーアクセスは、強力な認証と権限管理によって保護されること。
可用性
- 稼働率：システムは年間稼働率99.9%以上を確保すること。
- 災害復旧：システム障害時には、1時間以内に復旧できる体制を整えること。
非機能要件は、運用担当者やセキュリティ専門家とも連携して作成することが重要です。
また、非機能要件がしっかり定義されていないと、開発後の運用段階でパフォーマンスの低下やセキュリティリスクの増大など、深刻な問題が発生する可能性があります。そのため、非機能要件を明確に設定することは、システムの信頼性や安定性を確保するために非常に重要です。
設計・開発・テスト要件
設計・開発・テスト要件は、システム開発プロセス全体にわたる重要な要件です。例えばテスト要件では単体テストや結合テストの項目や基準を詳細に定めていくなどです。
提案要領
最後に、ベンダーに対する提案書の作成・提出に関する指示や条件を記載します。これにより、提案書の形式や内容の統一性が確保されます。具体的には、提案書に含めるべき項目や構成、提案書の提出期限や方法を記述します。
以上の項目をRFP内で記述することで、ベンダー企業から質の高い提案を引き出すことができます。
オフショア開発におけるRFPの注意点
基本的なRFPの構成などはオフショア開発だからといって特別変える必要はありません。しかしオフショア開発では、国内開発とは異なる特有の課題が存在します。そのためRFP作成時に以下の項目をベンダーへの提案要領に入れ込むと良いでしょう。
プロジェクトメンバー・体制
オフショア開発を円滑に進めるために、具体的なプロジェクトのメンバーや体制を提案時に把握しておくと良いでしょう。例えば、貴社とのカウンターパートとなるBrSEなどのメンバーの経歴や技術、言語スキルなどです。その他、プロジェクトを推進する上でのコミュニケーションの頻度や方法（ビデオ会議、チャットツール、メールなど）も記載してもらうと良いでしょう。
タイムゾーン・時差の対応
貴社とオフショアチームが異なるタイムゾーンにいる場合、日常的なコミュニケーションや会議のタイミングについて明記してもらうのも良いです。主要な連絡が可能な時間帯を定め、対応が必要な時間差の影響を軽減する方法を具体的に示します。
その他、緊急時の対応がどうなるかも明らかにしてもらうと、いざという時に安心です。
品質管理体制
提案を担当するベンダー企業に対して、品質保証に関する具体的なプランの提示を求めることが重要です。こちらから、定期的なコードレビューやテストプロセスの設定をRFPの中で義務付ける形でも良いです。
オフショア開発は、文化の違いから双方の求める品質レベルに差が出ることも珍しくありません。品質を確保するために、提案段階で各社の品質管理体制をチェックしておきましょう。
RFPの質がプロジェクト成功の鍵を握る
システム開発におけるRFPの作成方法について解説しました。RFPは、プロジェクトの成功を左右する重要な文書であり、その作成には時間と労力がかかります。しかし、質の高いRFPを作成することができれば、最適な開発パートナーを見つけることができ、プロジェクトの成功確率が高まります。
当社ではRFP作成のサポートのご支援も可能ですので、お気軽にお問い合わせください。
