この記事では、提案依頼書「RFP」の基本的な書き方について書きたいと思います。久しぶりにRFPを書く仕事をしたのですが、まったくもって基本ができていないことに気づきました。そこで、RFPに関する本を１冊読みました。その他にもAmazonで検索すると良さそうなものがあります。私が読んだのは、「RFP＆提案書完全マニュアル」です。この本を読んで、ポイントとなりそうなところを、エッセンスとして記載したいと思います。
提案依頼書「RFP」とは
いつもの通りRFP(Request For Proposal)とはそもそもどういう意味なのかというと、e-wordsにはこう書いてあります。
RFPとは、情報システムの導入や業務委託を行うにあたり、発注先候補の業者に具体的な提案を依頼する文書。必要なシステムの概要や構成要件、調達条件が記述されている。
RFPには、必要とするハードウェアやソフトウェア、サービスなどのシステムの概要や、依頼事項、保証用件、契約事項などが記述されており、業者はこれをもとに提案書を作成する。発注元は業者の提案書を評価し、契約する業者を選定、ハードウェアやソフトウェア、サービスなどを調達する。
これまで情報システム業界では、口約束やあいまいな発注による開発現場の混乱や紛争の発生、納期の遅れやシステム障害などに悩まされてきた。事前にRFPを通じて調達条件や契約内容を明らかにしておくことで、こうした混乱を未然に防ぐことの重要性が注目されつつある。(by http://e-words.jp/w/RFP.html)
RFPには何を書くのか？
RFPには、３つの情報を記載します。
- 何を（業務要求・技術要求・運用要求）
- いくらで（予算）
- いつまでに（納期）
言われてみれば、人にものを頼む時と一緒にですね、後輩や同期にお使いをお願いするのと一緒ですね。「お弁当とおやつを１３時までに１０００円で買ってきて」みたいなものですね。
RFPの位置づけ
RFPの作業はいつ行うかという位置づけは、システム構築の各フェーズを例に出すと次の場所になります。
- 情報化企画
- ITリソースの調達
- 事前調査
- ★ RFPの作成 ★
- 社内検討→RFP作成チーム編成→RFP記述→社内レビュー
- RFP説明会→Q&Aなどの連絡対応→提案書受領
- 提案依頼書評価および決定
- ベンダーと契約
- システム開発、導入
- 要件定義
- 外部設計
- 運用、保守
私が今まで業務経験で多いのは、「３．システム開発導入」。次に「４．運用、保守」です。RFPは、もう１つ上流ですね。この本では、短期開発でもRFPは必須という記載があります。RFPを書くことで次のことを防ぐことができます。
- 要求が曖昧となり、ベンダー側が提案範囲を見極めることが困難なため、なんでも詰め込んだ過剰提案や一般論的提案になりやすり
- 「言った、言わない」や「聞いた、聞かない」など情報伝達上のミスが発生しやすい
- 提案書を判断する段階で基準が曖昧となり、結果的に単純に価格だけで判断してしまう
メリットとしては、次が挙げられます。
- 文書化することで、要求を明確で具体的な物にする
- 要求事項の優先順位を明らかにする
- ベンダーに対して公平に情報提供をおこなえる
- 同時に複数のベンダーに提案依頼をすることで時間を短縮できる
- ベンダーからの提案書を評価する段階でその評価軸となる
- 投資対効果を検討するきっかけとなる
個人的には、公平性の確保や費用対効果の検討といった理にかなったシステムを構築できることろがいいですね。作ってリリースしてみたけれど、何も効果がなかったと言ったら、プロジェクトの最中にいなくなってしまった仲間がかわいそうです。
分かっていて中々実践するのが難しいですが、RFPを書く際は、要求や内容に漏れ、偏り、ムリ、無駄、矛盾、利害の衝突などがないよう記載しましょう。
RFPの一般的な目次と書く事
本にサンプルRFPはありますが、全部書き写すの骨が折れるので、それぞれの章・節でどんなことを書くか箇条書きにしたいと思います。ポイントは、詳細まで書く事よりも、網羅性が大事！ということです。
(1) 趣旨：システムの目的を明示
ポイントは次の点です。
- 経営戦略や経営陣の思いを完結に表したキーメッセージ
- 自社の経営環境や抱えている問題点から、なぜ今回のシステムが必要になったのか
- どのようなビジネス上の効果をシステムに期待しているのか
(2) 業務要求：趣旨に照らして書き出す（機能要件の元）
要件定義書の元みたいなイメージです。要件定義の上流にあるRFPの時点で業務要求を細かくやると要件定義でやることが少なくなるので、「詳細に書くほど後が楽」という記載があります。確かにそうですね。システム開発時点で要件が曖昧で、外部設計の段階でだいぶ要件定義の見直しが入りますものね。ただし、RFPは、提案を依頼するものですので、詳細に詰めきれない部分は「ベンダーの提案に任せるのも手」という記載があります。また、業務要求をまとめるためには、事前アンケートをとったり、業務見学をさせてもらったり、RFPのレビューに参加をしてもらう等「エンドユーザの協力が不可欠です。」という記載があります。これは私の経験上でもユーザ部門に１日でも業務体験をさせてもらえると、要件定義からテストフェーズまでユーザ目線に立った思想での仕様作成、指摘が行えるようになりますので、やることをおすすめします。（実際は上長などにお願いをして動いてもらわないと難しいとは思いますが、、、。）業務要求には、次のことを書きます。
- 業務基本要求
- 業務機能要求
- 業務フロー要求
- データ入力・表示要求
- 帳票要求
(3) 技術要求：インフラ、性能、障害対策を書く（非機能要件の元）
自社に見合った技術要求を記載することがポイントです。技術要求の要素としては、次のものがあります。
- ITインフラ ：OS/ミドルウェア、ハードウェア、ネットワーク
- システム能力 ：パフォーマンス、キャパシティ、拡張性
- 障害対策 ：ハード/ソフト障害、ネットワーク障害、DR、運用回避策
中小企業では、要員確保が難しい部分がありますので、既存のシステムの構成をもとに具体的な提案をベンダーにお願いする形式の方が上手くいく傾向があります。具体的な技術要求とベンダーに提案を求める例を次に記載します。
- OSについて
- （具体的な要求) WindowsServer2016
- （ベンダー提案）Windowsで最新のものを
- 障害対策
- （具体的な要求) CPU、メモリ、ハードディスク、電源装置が全て２重化されホットスタンバイであること
- （ベンダー提案）高度な障害対策機能を搭載していること
- 画面レスポンス
- （具体的な要求)すべての画面遷移が１秒以内であること。また、遅くとも３秒以内であることは必須条件
- （ベンダー提案）ストレスなく作業が進行できる画面遷移のスピードであること
非機能要求か機能要求か微妙なラインだが、顧客情報漏えいに対する対策についてもRFPに一筆書いておくべき時代になっています。。また、既設設備のネットワークのサーバを使用する場合はその旨を記載すると、ベンダーが提案時に迷わなくて済むようになります。
(4) 運用要求：システムリリース後の保守体制を記載し、ベンダー開発以降も付き合えるかどうか見極める
各要件に見合った保守要求を書く事がポイント。運用要求の要素を次に箇条書きにします。
- 運用要求
日常運用屋バックアップ作業などの運用計画に関する要求 - 保守要求
ベンダーに求めるハードウェアやソフトウェアやネットワークに対する保守サービスの要求 - 教育・研修要求
エンドユーザやシステム要員に対する教育・研修の要求 - 移行要求
システムの本番移行への要求。特に既存システムのリプレースの場合等に求める要求 - アウトソース要求
運用全体あるいは一部をアウトソースすることを検討している場合の要求
ベンダーがシステムリリース後も自社のサービスを一緒に支えてくれるパートナーになれるかは、この運用要求をしっかり考えていてくれるかを見ることで判断することができます。作り逃げするベンダーは、運用要求に対する提案がほとんどありません。また、自社の調査がまだまだ未完成の状態でRFPを書き上げなければならない状態の場合は、ベンダーがからの提案をたたき台に検討したい旨を伝えると、良い解決策に出会える可能せがあります。ベンダー側にとっても自社の提案力（アイディア）を見せることが出来るいい場になります。
(5) 予算：提示できれば後が楽
自社の予算「イニシャルコストとランニングコスト（５年分)」を提示し、ベンダーから的外れな提案をもらわないようにします。私はこの本を読む前までは、予算を提示するべきではないと思っていました。「予算は２０００万」と提示したほうがベンダー側も発注側もメリットがあります。ただし、予算提示が可能なケースは以下の場合です。
- IT投資の経験が豊富で検討がつく
- 事前に投資対効果の検討を十分に行っていて、投資の目処が立っている
- 経営上または財務上の事情で、投資できる予算がほぼ確定している
ベンダーから安くシステムを買おうとして予算を低く提示した場合は、ベンダーが機能を削減して提示してきたり、発注側の仕様変更を聞いてくれなくなり、結果的に予算を超過してしまうケースが多いので、かけひきはしない方がよいという記載があります。私は開発をしている時に、この光景を何度も見たことがあります。私の経験上も正直に提示して、正直にお話をすることがお互いにとって良い方向に進みますね。正直に話しても疑ってきたり、ケチをつけてくるお客さまがいたら、そのお客さまは悪いお客さまですので、早々に縁を切るか、辛抱強く話し合うことをおすすめします。
また、私は見たことがなかったのですが、開発するシステムの内容によっては、「国もしくは自治体による補助金」を利用することが可能な場合があります。詳しい方はそちらも情報のアンテナをはっておくと、良いかもしれません。
(6) スケジュール
これは、発注側よりベンダー側が気にしてくれる項目だとは思いますが、社内的な事情や法改正の影響でリリース日が決まっているプロジェクトであれば、正しくそのことを記載しましょう。RFPを書いている時点での注意点は、RFP発行からプロジェクトが始まるまで２ヵ月かかるということです。RFP発行からプロジェクトキックオフまでの流れを記載します。
- RFP発行（2週間）
- ベンダー提案受領（1～2週間）
- ベンダー選定(1～2週間)
- ベンダー決定(1週間)
- 契約業務(1～2週間)
- 調達（人・モノ）(1～2週間)
- プロジェクトキックオフ
全部で7週から12週くらいの期間が必要となります。この本を読んでいて、ハッとしたことというと、「開始日」をしっかり書くということです。終了日はいつも気にしますが、開始日も意識して記載するようにしましょう。また、システムの試験運用も考慮したスケジュールにしましょう。
(7) 特記事項：上手く書けば選定が楽になる
この本では、特記事項に次のことを書いています。
- 提案書の書式と構成、提出方法、提出期限。
- 提案書の選考方法（書類/プレゼンテーション)
- RFPに対する問い合わせ先
５．まとめ
このページでは、RFPの書き方についてまとめてきました。約６０ページを凝縮したのですが、薄っぺらくなってしまいましたね。。。私自身RFPを書いたのは３回程度でまだまだ未熟さを感じました。今回書いた内容を基礎として今後、素早くエレガントなRFPを書けるようにできるように精進していきたいと思います。
最後までお読み頂きありがとうございます。この記事を読まれた方は、次の記事もおすすめします。
コメント