RFP採点経験の立場から、RFPに対する各ベンダーからの提案内容で重視するポイントや、採点の考え方をまとめさせていただきました。
目次
RFPの説明からベンダー選定までの流れ
RFPの説明からベンダー選定までの流れは、以下一般的な流れになります。
- ①RFP説明会
- ②QA対応
- ③提案書提出
- ④プレゼンテーション
- ⑤採点
- ⑦選定・フィードバック
今回お伝えしたいスコープは、③～⑤に絞りたいと思います。
RFPへの提案で押さえるべき5つのポイント
- POINT①：必須要件と任意要件の違いを理解する
- POINT②：常に「本当にできるの？」と採点者が思っていることを理解する
- POINT③：実績・開発メンバー紹介は自己満足ではなく、RFPの開発内容に合わせることを心がける
- POINT④：スケジュールはマイルストーンのゴールも明確に
- POINT⑤：素晴らしいプレゼンテーションよりも、わかりやすい提案書作成
POINT①：必須要件と任意要件の違いを理解する
必須要件
必須要件は依頼者側が絶対に実現したい機能や環境であるため、出来ないという回答はできません。出来るために何を行うか、を検討しましょう。採点者側が各ベンダーから提出された提案書で一番最初にチェックするのが、必須要件を満たしているか、です。満たしていない場合は、どんなに素晴らしい提案でも代案がなければ、その時点で0点となります。
任意要件
任意要件は対応できれば尚可、つまり加点対象の要件となります。必ずすべてが出来る必要はありませんが、1つでも多く実現できれば加点されます。
POINT②：「本当にできるの？」と採点者が思っていることを理解する
実績と開発メンバーの紹介で不信感を解消する
採点者はあくまでも提案書内でしかジャッジが出来ない立場です。そのため、上司から「この会社で本当に大丈夫なの？」と聞かれたときに、説明する論理的な説明が必要です。その際に一番強い説得材料は「実績」です。
RFPに即した開発実績が多数あったり、関わったことがあるメンバーの実績を記載することは効果的です。
POINT③：実績・開発メンバー紹介は自己満足ではなく、RFPの開発内容に合わせることを心がける
なぜ組織図が必要なのか？
ポイントは、下記の3点が挙げられます。
- ※開発にかける人員は十分か
- ※指示系統は明確か
- ※トラブル時、迅速な対応が行われるか（運用体制も提案範囲に入る場合）
開発にかける人員は十分か
開発を依頼する場合、当然見積金額も決定要因の1つとなります。ただし、コストが安い理由として少ない人員構成で対応するようであれば、依頼内容に対して十分に対応頂けるか、不安があります。人数が多ければそれでよいのか、という問題はありますが、しっかりと対応頂ける担保要因の1つとして、万全の組織体制を提案できることはプラス要素となります。
指示系統
提案企業が開発のリソースとして外部ベンダーと連携して行う場合に、指示系統をどう行うのかが重要になります。さらに外部ベンダーが遠方の企業であれば、どういう形でコミュニケーションを取っていくのか、不安を感じやすいです。そのため、指示系統とコミュニケーション方法を明確にする必要があります。
トラブル時、迅速な対応が行われるか（運用体制も提案範囲に入る場合）
RFPの中に、開発後の運用も対応してほしいとある場合、ポイントはトラブル時の体制と連絡経路、対応スピードになります。上記事項に対する対応方法を明確にする必要があります。
プロフィールはどんな内容を記載すべきか
開発メンバーの紹介も記載しましょう。紹介する内容としては、スキルや実績についてです。その際、RFPの目的や開発内容に沿った実績やスキルを記載するようにしましょう。豊富なスキルや実績を書くことは重要ですが、RFPで求められる開発要件と関係のない実績を記載することで、「実績はすごいけど、今回の開発とは関係ないね。」となり、突っ込まれる要素にもなってしまいます。
POINT④：スケジュールはマイルストーンのゴールも明確に
スケジュールの記載方法
RFPに粒度は別にしても、期待されるスケジュールが提示されています。マイルストーンごとの日程設定がある場合、RFPのスケジュールを守ることが前提となります。もし無い場合でも、提案内容にマイルストーンの時期と納品物等を明示しておきましょう。見積金額と同レベルで、スケジュール内での納品も最重要項目の１つとなります。
POINT⑤：素晴らしいプレゼンテーションよりも、わかりやすい提案書作成
採点者は提案内容がRFPの要件を網羅しているかをチェックする
採点側では、RFPの要件一覧を作成し、各ベンダーを並べて、記載の有無について○×をつけるケースがあります。その場合、詳細な内容よりも、記載があるか否かを一覧で並べて評価する形になります。要件に対する網羅性が重要です。
＋αの提案は、技術レベルの誇示ではなく、解決できる課題が何かを軸に伝える
採点者が対象の技術に詳しい場合は技術ベースでの説明で問題ないかもしれません。ただ多くの場合、対象の技術に詳しくない方が採点する場合も多く、専門用語だけの説明だと理解できません。そのため、技術ベースの説明ではなく、どんな課題を解決できるのか、イメージしやすい視点で記載したほうが良いです。
以上、簡単ではありますが、参考にしてみてください。
- XCALLYがメジャーバージョンアップするのでウェビナーに参加してみた - 2022-01-20
- 0120番号をクラウドPBXで利用するための基本的な作業手順 - 2021-06-03
- Kamailioとはなにか - 2021-04-21
- RFPの発注者とベンダー、両方の立場を並行で仕事してみて思うこと - 2020-12-09
- コールセンターはAIに仕事を取って代わられるのか - 2019-09-17
【採用情報】一緒に働く仲間を募集しています
