提案依頼書（RFP）を作るとき取得者は何に気をつけるべきか
情報セキュリティマネジメント試験 令和元年度秋期 午前 問49 ／ システム企画 › 調達計画・実施
過去問にチャレンジ
情報システムを取得するための提案依頼書(RFP)の作成と提案依頼に当たって，取得者であるユーザー企業側の対応のうち，適切なものはどれか。
- ア
RFP 作成の手間を省くために、要求事項の記述は最小限にとどめる。曖昧な点や不完全な点があれば、供給者であるベンダ企業から取得者に都度確認させる。
- イ
取得者であるユーザー企業側では，事前に実現性の確認を行わずに，要求事項が実現可能かどうかの調査や検討は供給者であるベンダー企業側に任せる。
- ウ
複数の要求事項がある場合，重要な要求とそうでない要求の区別がつくようにRFP作成時点で重要度を設定しておく。
- エ
要求事項は機能を記述するのではなく, 極力, 具体的な製品名や実現手段を細かく指定する。
会話形式の解説
講師今回は提案依頼書、つまりRFPを作るときの取得者側の姿勢がテーマです。RFPは、発注する側が求めるシステムと条件をベンダに示して、提案を出してもらうための文書です。取得者が自分の責任で、何を実現したいかをはっきり伝えているか。この点で各選択肢を見ていきましょう。
受験者私は、要求事項を最小限にして不明点はベンダに都度確認してもらう、という対応も現実的だと思いました。やり取りしながら詰めればよいのではないでしょうか。
講師手間は減りますが、要求が曖昧なままだと取得者とベンダの間で認識のずれが起きます。それに、各社がばらばらの解釈で提案を出すので、比べて評価するのも難しくなります。必要な内容はRFPの段階で明確に書いておくべきです。
受験者なるほど、比較しにくくなるのは困りますね。では、要求が実現できるかどうかの調査をベンダに任せる対応はどうですか。技術に詳しいのはベンダ側なので、任せてもよい気がします。
講師そこは迷いやすいところです。ただ、業務の要件を最もよく分かっているのはユーザー企業です。通常は取得者側が取得要件を整理し、それをもとにRFPを作ります。ですから実現性についても、事前に取得者側で確かめておく必要があります。丸投げは適切ではありません。
受験者複数の要求事項に、RFPを作る時点で重要度を付けておくという対応は、優先順位が伝わるので良さそうに見えます。
講師その通りで、これが適切な対応です。どの要求を優先すべきかが分かれば、ベンダはそれを踏まえて提案を組み立てられます。取得者にとっても、提案を評価・比較するときの基準がはっきりします。
受験者残りは、機能ではなく具体的な製品名や実現手段を細かく指定する対応ですね。曖昧さをなくすという意味では、これも正しいように感じてしまいます。
講師RFPでは「何を実現するか」を示し、「どう実現するか」はベンダの提案に任せるのが原則です。手段まで縛ると提案の幅が狭まり、より良い解決策を得られなくなるおそれがあります。具体的に書くべきなのは要求の中身であり、実現手段ではありません。
受験者整理すると、要求の中身は取得者が責任を持って明確に書き、重要度も示す。実現性は取得者側でも確認する。製品や手段はベンダの提案に任せる、ということですね。
講師よく整理できています。補足すると、既存システムとの互換性など正当な理由がある場合は、例外的に製品を指定することもあります。あくまで原則は「何を実現するか」を書くことだと覚えておきましょう。
まとめ
提案依頼書（RFP）は、取得者が求めるシステムと条件をベンダに示し、提案を求めるための文書です。要求事項は曖昧さや漏れがないよう具体的に書き、複数ある場合は重要度を設定しておくと、ベンダは提案を組み立てやすく、取得者も評価・比較しやすくなります。要求の実現可能性は、ベンダに丸投げせず取得者側でも事前に確認します。RFPには「何を実現するか」を書き、製品や実現手段はベンダの提案に任せるのが原則です。ただし、既存システムとの互換性など正当な理由があれば、例外的に製品を指定することもあります。
解答・解説
正解はウです
この問題のテーマ
情報システムを調達するとき、発注する側のユーザー企業（取得者）が、提案依頼書（RFP）をどう作り、どう提案を依頼すべきかを選ぶ問題です。RFPは、ベンダ（システムを提供する会社）に出す提案の依頼文書です。
解き方の考え方
最初に、RFPが何のための文書かを確かめます。RFPは、求めるシステムと条件をベンダに示し、提案を出してもらう文書です。次に、各選択肢が「取得者が自分の責任で、何を実現したいかを明確に伝える」という原則に合うかを照らします。手間を省く、ベンダに丸投げする、実現手段まで縛るといった対応は、この原則に合わないので外れます。
選択肢ごとの解説
- ×ア RFP 作成の手間を省くために、要求事項の記述は最小限にとどめる。曖昧な点や不完全な点があれば、供給者であるベンダ企業から取得者に都度確認させる。要求事項を最小限にして、不明点はベンダに都度確認させるという対応は誤りです。要求が曖昧なままだと、取得者とベンダの間で認識のずれが生じます。そのうえ提案内容にばらつきが出て、比較や評価もしにくくなります。必要な内容は、RFPの段階で明確に書いておくべきです。
- ×イ 取得者であるユーザー企業側では，事前に実現性の確認を行わずに，要求事項が実現可能かどうかの調査や検討は供給者であるベンダー企業側に任せる。要求が実現できるかどうかの検討をベンダに任せるという対応は誤りです。業務要件を最もよく分かっているのはユーザー企業です。取得要件は取得者側が定義して承認し、それをもとにRFPを作ります。したがって、実現性も事前に取得者側で確かめておく必要があります。
- ○ウ 複数の要求事項がある場合，重要な要求とそうでない要求の区別がつくようにRFP作成時点で重要度を設定しておく。RFPを作る時点で要求事項に重要度を設定しておくという対応は適切です。どの要求を優先すべきかが分かれば、ベンダはそれを踏まえて提案を組み立てられます。取得者にとっても、提案を評価・比較するときの基準がはっきりします。
- ×エ 要求事項は機能を記述するのではなく, 極力, 具体的な製品名や実現手段を細かく指定する。具体的な製品名や実現手段を細かく指定するという対応は誤りです。RFPでは「何を実現するか」を示し、「どう実現するか」はベンダの提案に任せるのが原則です。手段まで縛ると提案の幅が狭まり、より良い解決策を得られなくなるおそれがあります。
補足
「具体的に書く」ことと「製品名まで指定する」ことは別です。具体的にすべきなのは要求の中身であり、実現手段ではありません。なお、既存システムとの互換性など正当な理由がある場合は、例外的に製品を指定することもあります。
POINT
- RFPは、取得者が求めるシステムと条件をベンダに示して提案を求める文書です。
- RFPの要求事項は、曖昧さや漏れがないよう具体的に書きます。
- 要求事項が複数あるときは、重要度を示しておくと提案の作成や評価がしやすくなります。
- 要求の実現可能性は、取得者側でも事前に確認しておきます。
- RFPには「何を実現するか」を書き、製品や実現手段はベンダの提案に任せます。