『RFPを書くためにネットに落ちてるサンプル目次をそのまんまコピー！　でも中身って結局どうやって書けばいいの？』

そんなRFPビギナーにもわかる実践的なコツを紹介します。
今回は、前回に引き続き”ベンダー側の視点からもらってうれしい”RFPの書き方の解説です。

（第1章はこちら）

情シス「目次はわかった。では中身は？」

前編では、RFPの目次をご紹介しました。今回はその内容を詳しく見ていきましょう。今回はあくまでもベンダー側から見て「こんなRFPならうれしい」というポイントを説明します。
「RFPって、要は希望価格とシステム要件を書けばいい」というイメージは強いかもしれません。もちろん価格とシステム要件は大事ですが、実際は、それだけではなく下記のような項目をしっかり事前検討して書くことが推奨されます。
前編でも述べたように、RFPは発注元とベンダーの意識合わせの第一歩なのです。

冒頭で「いつまでに、いくらで、何をしたいのか」を共有

まずは冒頭に「いつまでに、いくらで、何をしたいのか」を掲げましょう。これが全ての前提となります。具体的に以下の項目に分割して書きます。

１．システム概要　～すべてをここに3行でまとめる気持ちで

RFPの最初に、このシステムで何をしたいかを短い文で伝えます。
まずはシステム名称を書きましょう。「インターネット通信販売管理システム」「多拠点間商品在庫管理システム」のように、メインの機能を表します。
そして、システム開発で実現したいことを書きます。「インターネットでの通販サイトと販売管理システムを作成し、インターネット通販に関する業務（商品販売、受注、決済、在庫管理、出荷管理、顧客情報管理等）をシステム上で行えるようにする」などと書きます。システムで実現したい機能がいくつもある場合、ここで全てを細かく網羅する必要はありません。
この部分は、「このシステムで何をするか」がまとまっている情報であり、RFPを受け取ったベンダー側でもこのシステムを表す説明文として読み直すことが多い箇所です。
あまり長いと全体がわかりづらくなり、後々出てくる詳細の記載と不整合が起きてしまうケースも出てきてしまいます。RFP内での記述の不整合はベンダーの混乱の元になりますので、ここはあくまでも概要にとどめておきましょう。

２．開発目的　～背景を忘れずに

ここでシステムによって達成したい目標、解決すべき課題を書きます。
重要なことは、業務上なぜこのシステムを発注することになったのかの背景を入れることです。
開発の背景は、発注者が「何を達成したくて（または解決したくて）システム開発を行うのか」がわかる情報です。
これがあることにより、ベンダーは顧客が本当にやりたいことがわかり意識合わせができます。
この背景をベンダーに理解してもらえれば、ベンダー側からより良い実現方法の提案を受けられます。

３．開発期間　～締め切りはいつ？

開発を行う期間はいつからいつまでか、工程ごとの目安の時期、決まっているリリース日などの事柄を書きます。
他にも例えば、サーバールーム新設予定に合わせて構築するなどの時期の制約や、完成したシステムを使うことが決まっているイベントなど開発期間に関する情報を記載します。
納入に物理機器を含む開発の場合は機器の選定や調達にも時間がかかるので、ベンダーに期間の情報を具体的に知らせることが大切です。

４．開発予算　～ある程度分類しておこう

開発予算の初期費用や上限、開発／運用／維持などの工程ごとにかかる予算の目安を書きます。
複数のシステムが連携するシステムであればその機能範囲ごとの予算の目安でもいいでしょう。
まるっと上限のみを書いてもいいのですが、あらかじめRFP作成時に予算をざっくりと分類しておくことでベンダー側も工程計画がしやすくなり、発注側も後々のベンダー管理の準備ができます。

求める「機能」って何なのか？　立ち止まって考えよう

５．機能要件　～人間がやりたいことだけ書こう

ここでは、開発するシステムで実現する機能と操作、性能に関する要件を書きます。
ここで、RFPビギナーは「実現する『機能』って何だっけ？」となるかもしれません。「機能」と言われるとよくわからなくなりがちですが、RFPの機能要件に書くべきなのは「人間がやりたい操作と、システムに期待する結果」です。
例えば、「顧客が通販サイトで商品を見て購入と決済ができる」「購入操作をしたら在庫情報の更新ができる」「ユーザーからの問い合わせをシステム上で受け付け、従業員がまとめて見ることができる」など、あくまでも誰が何をしたいかに焦点を当てて書きましょう。
これが明確になっていると、ベンダーは設計のイメージがぐっとしやすくなります。

性能に関する要件とは、システムの動作が行われる速さや、システムで達成しなければならない業務量がどのくらいか等の情報です。例えば「商品情報表示は3秒以内」「アクセス想定50000PV／月」などといったことです。
性能に関する要件が決まっていなければ書く必要はありません。もし書く場合は単位と範囲を明確に書いてください。

６．開発範囲　～コレはココまで

開発範囲には、発注する範囲、つまりベンダーに任せる部分と発注元で（または別のベンダーで）行う部分を明確にするという意図があります。
例えば、システムの現場導入作業はどこまでやるのか、維持管理をどうやってやるのか、連携するサイトの運営は他の企業に任せるのかなど、この発注で行う仕事の範囲をしっかり決めておきます。
ベンダーから見れば、この範囲が明確でないと業務量の見積もりがしづらくなります。適正な提案を受けるためにも必要な項目です。

７．運用要件　～納入後に残されるのは運用

ここでは、システムの稼働時間や運用保守に関わる事柄を書きます。
運用オペレーション上の要望、このシステム稼働率をどのくらいに設定するか、システムに関して操作マニュアルやレクチャーをどうするか、システムメンテナンスをどのように行いたいかなどを記載します。
機能要件と同じようにこうした運用要件はとても重要なものです。
日々の運用の利便性が低ければシステム導入の効果が薄れてしまいますし、システムダウンすることで業務に影響が出てしまえばむしろ逆に痛手となってしまいます。
開発と運用のベンダーが分かれる場合もあります。運用はシステム構築後は発注元で把握してやっていかなければならず、コストもずっと残り続けるものです。
そうした運用コストをしっかりと視野に入れて、ベンダーに伝えておくことが必要です。

８．セキュリティ要件　～守るべきものを明確に

企業のシステムは、アクセスするユーザーの情報など何らかの個人情報を扱うことが必要となるケースが多いです。
セキュリティ要件は、自社のセキュリティポリシーやシステムで扱う情報の重要度、システム上のデータに対してどうした扱いをするのかを定める項目です。
情報セキュリティは企業の信頼度と直結し、とても重要なものです。特に個人情報や機密情報を扱うシステムであればこの項目を入れておきましょう。

 

 

さて、次回はいよいよRFPの最終編。
RFPの〆に書くべき項目と、RFPに対するベンダーからの提案を受け取るまでの最終まとめです。

 

【執筆：編集Gp　星野 美緒】