RFPに「何を書くか」より、「何を書かないか」｜発注側が決めること、ベンダーに提案させること
RFP（提案依頼書）を作成し、複数のベンダーに提案を依頼する。
ところが、返ってきた提案書を並べてみると、どうも比較できない。
- A社はパッケージを前提にしている
- B社はスクラッチ開発を提案している
- C社は「この部分は別途」と書いてある
- 見積金額にも大きな開きがある
同じRFPを渡したはずなのに、各社が違うものを提案している。
こうなると、発注側は困ります。
「結局、どこが一番いいのか」
しかし、問題はベンダーの提案力ではないかもしれません。
そもそもRFPを作る段階で、発注側が決めることと、ベンダーに提案してもらうことが整理されていなかった可能性があります。
RFPが「社内要望の寄せ集め」になっていないか
RFPを作るために、まず各部門へヒアリングをする。
これは間違っていません。
問題は、その後です。
- 営業部：「外出先からスマホで入力できるようにしてほしい」
- 経理部：「承認フローをもっと厳密にしてほしい」
- 物流部：「在庫をリアルタイムに確認したい」
- 管理職：「ダッシュボードで全部見えるようにしてほしい」
- 情報システム部：「できるだけ標準機能で構築したい」
といった要望が出てきます。
これを整理してRFPに並べれば、一見すると立派な「機能要件一覧」ができます。
しかし、それは本当に要件でしょうか。
例えば営業部の、
「外出先からスマホで入力できるようにしてほしい」
という要望を、そのまま要件にする前に、少し掘り下げてみます。
なぜ、スマホが必要なのか。
外出中に入力できず、帰社後にまとめて入力しているから。
それによって、何が困っているのか。
案件情報が社内に共有されるのが翌日になり、上司や営業支援部門の対応が遅れるから。
ここまで掘り下げると、本当に必要なのは、
商談後、一定時間以内に案件情報を社内で共有できること
かもしれません。
スマホ入力は、そのための一つの手段です。
- スマホアプリが最適なのか
- ブラウザでよいのか
- 音声入力なのか
- あるいは別の方法で入力自体を減らせるのか
そこはベンダーに提案してもらう余地があります。
現場から出てきた「こうしてほしい」を、そのままシステム要件にしない。
RFPを作る前に必要なのは、要望を集めること以上に、「なぜ、それが必要なのか」を問い直すことです。
全部載せれば、「全部入り」の見積が返ってくる
もう一つ、RFP作成で難しいのが優先順位です。
各部門から出てきた要望には、それぞれ理由があります。
営業部にも事情がある。経理部にも事情がある。物流部にも事情がある。
だから、なかなか削れません。
結果として、
「せっかくシステムを刷新するのだから、とりあえず全部RFPに入れておこう」
となりがちです。
しかし、発注側が優先順位を決めなければ、ベンダーにはそれが分かりません。
すべて「必須」に見えれば、すべてを実現する前提でシステムを考えます。
- 機能が増える
- 連携が増える
- 例外処理が増える
- テスト範囲も広がる
当然、見積金額も大きくなります。
そして提示された金額を見て、
「思ったより高い。もっと安くならないか」
という話になる。
しかし、その前に確認した方がよいことがあります。
本当に、全部必要なのでしょうか。
RFP作成とは、要望を集めて文書にする仕事だけではありません。
むしろ難しいのは、
何をやり、何を今回はやらないのかを決めることです。
ここを決めないままRFPだけ完成させても、意思決定を後工程へ送っただけになってしまいます。
曖昧さは、ベンダーごとに違う形で埋められる
RFPに曖昧な部分が残っていると、ベンダーはそこを何らかの方法で補います。
例えば、
「将来の事業拡大にも柔軟に対応できること」
という要件があったとします。
「事業拡大」が何を意味するのかは書かれていません。
- 店舗が増えるのか
- 海外展開するのか
- ECを始めるのか
- 新しい商品カテゴリーが増えるのか
- M&Aで別会社のシステムを統合するのか
ベンダーによって解釈は変わります。
ある会社は、自社パッケージの拡張性を説明するでしょう。
ある会社は、将来変更のリスクを見込んで、設計や見積に余裕を持たせるかもしれません。
別の会社は、今回の見積範囲を限定し、
「将来の拡張については別途協議」
とするかもしれません。
例えば同じRFPに対して、
- A社：2,500万円
- B社：1,500万円
- C社：2,000万円
という提案が返ってきたとします。
このとき「B社が一番安い」とは、まだ言えません。
B社だけが何かを見積範囲から外しているのかもしれませんし、A社だけが将来拡張まで想定しているのかもしれません。
つまり、
金額が違うのではなく、見積もっているものが違う可能性がある。
RFPが曖昧であるほど、ベンダーの解釈が入り込みます。
そして、その解釈の違いが大きくなるほど、提案比較は難しくなります。
では、発注側はどこまで決めればいいのか
ここで、逆の問題が出てきます。
「曖昧にしてはいけないのであれば、全部こちらで決めてRFPに書けばいいのか」
そうとも限りません。
発注側が実現方法まで細かく指定してしまえば、ベンダーの専門性を使う余地がなくなります。
例えば、
「受注入力から出荷指示までを5クリック以内で完了できること」
という要件。
具体的なので、一見すると良い要件に見えます。
しかし、本当に解決したい問題が、
「受注処理に時間がかかり、繁忙期には出荷指示が滞留している」
ことであれば、「5クリック」は発注側が決めるべきことではないかもしれません。
画面遷移を減らすのか、自動入力するのか、そもそも入力そのものをなくすのか。
解決方法には、複数の可能性があります。
そこでRFPに書く内容を、次の3つに分けて考えてみます。
| 分類 | 発注側で整理すること | 例 |
|---|---|---|
| 固定する | 今回のプロジェクトで変えない前提・必須条件 | 対象業務、法令、全社IT方針、必須の外部連携 |
| 条件を示す | ベンダーが提案を考えるために必要な背景・制約 | 利用人数、繁忙期、将来の拠点増加、現行業務の問題 |
| 提案を求める | ベンダーの専門性を使いたい領域 | UI、製品、実現方式、自動化方法、アーキテクチャ |
もちろん、案件によって境界は変わります。
例えば「AWSを使うこと」は、技術方式だけを見ればベンダーに提案させてもよさそうです。
しかし、会社全体のクラウド方針としてAWSに統一しているのであれば、それは「固定する」に入ります。
重要なのは、
Whatは発注側、Howはベンダー
と機械的に分けることではありません。
今回のプロジェクトでは、どこまでを発注条件として固定し、どこから先に提案の余地を残すのか。
その境界を意識して決めることです。
RFPに「何を書くか」より、「何を書かないか」
RFPの質を高めようとすると、「もっと具体的に書こう」「もっと要件を明確にしよう」と、書くものを増やす方向に考えがちです。
しかし、実際には、「何を書かないか」を決めることも同じくらい重要です。
書かないものには、大きく二つあります。
一つは、今回やらないこと。
各部門から要望が出ていても、今回の目的や優先順位から外れるのであれば、対象から外す。
もう一つは、発注側で実現方法まで決める必要がないこと。
解決したい課題や守るべき条件までは明確にする。しかし、その実現方法についてベンダーの専門性を使いたいのであれば、あえて解決方法までは固定しない。
つまり、
「決まっていないから書けない」のと、「提案してほしいから決めすぎない」のは、まったく違います。
RFPに余白を残すことと、RFPが曖昧であることは、同じではありません。
むしろ、どこを固定し、どこに余白を残すかを意図的に設計することが、ベンダーから提案を引き出すためには重要です。
RFPを書く前に、まず3つだけ決める
RFPのテンプレートを開く前に、最低限、関係者で次の3つを確認してみてください。
- 今回、何を解決するのか：
「新システムを導入する」ではなく、導入によって何を変えたいのか。現場から出てきた要望についても、「なぜ必要なのか」を一段掘り下げます。 - 今回、どこまでやるのか：
すべての問題を一度に解決する必要はありません。今回やることと、やらないことを決めます。要望を追加するだけではなく、捨てる判断も必要です。 - 何を固定し、何をベンダーに提案してもらうのか：
法令や社内方針など、絶対に守る条件は固定する。一方で、実現方法について専門家の知見を使いたい部分には、提案の余地を残す。
この3つが整理されていれば、RFPに何を書くべきかはかなり見えてきます。
逆に、ここが決まっていない状態でテンプレートを埋め始めると、RFPは「検討した結果」ではなく、決まっていないことを覆い隠す文書になりかねません。
RFPを書くために、最初にWordやExcelを開く必要はありません。
まず開くべきなのは、各部門から集まった要望一覧です。
一つひとつについて、
- 「なぜ必要なのか」
- 「今回、本当にやるのか」
- 「実現方法まで、こちらで決める必要があるのか」
を問い直してみる。
そこまで整理できれば、RFPを書く仕事のかなりの部分は、すでに終わっています。
RFPを書く前の整理から、ご支援します
「各部門から要望は集めたが、優先順位が決まらない」
「どこまでを要件として決め、どこからベンダーに提案させるべきか分からない」
「RFPを作り始めたものの、この内容で本当に各社を比較できるのか不安がある」
オーシャン・アンド・パートナーズでは、RFPという文書を作るところだけではなく、その前にある業務整理、課題整理、要求事項の整理から、RFP作成、ベンダー選定まで、発注側の立場で支援しています。
すでにRFP作成を始めている段階でも構いません。
その要望は、本当に要件なのか。
今回どこまでやるのか。
何を決め、何をベンダーに提案してもらうのか。
一度整理するところから、ご相談いただけます。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア（全省庁統一資格Aランク）代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
