RFP(提案依頼書)を作成するメリット、デメリットと活用方法について

RFPとは？

システム構築に関わっている方は「RFP」という語句をよく目にしたり、耳にされたりしているかと思います。RFPとは（Request for Proposal）の略語で、日本語に直すと「提案要請書」もしくは「提案依頼書」のことです。

現在では、システムの開発や導入をアウトソーシングする場合、発注者側がSIerやITベンターに対してRFPを提示することが当たり前になっています。RFPのメリット、デメリットについては後ほど述べますが、RFPの出来栄えの良しあしが、システム構築の成否を左右するといっても過言ではありません。より良いRFP策定は、より良いシステム構築の必須条件なのです。いずれにしてもRFPは発注側、受注側の双方にとって必要不可欠なものとなっていることを理解しておいてください。

SIerとは？詳細や問題点、将来性についてわかりやすく解説！

RFPの策定が一般化する前は、システムベンダーの営業担当が足しげく顧客のもとを訪ね、課題の確認や御用聞きをしていました。雑談を交え、時には飲食を共にしながら顧客から情報を聞き出し、数回のヒアリングを経てSEと共同で提案書を作成するというパターンが一般的でした。

しかし、これは営業担当と顧客の人間関係に依存する部分が多く、また非効率的でもあり、こうしたやり方は次第に減少していきました。

RFPは一度作成すれば、いちいち複数のベンダーに何度も説明をする必要もありませんし、「御用聞き」よりも遥かに効率的です。また、同じ土俵で各ベンダーから提案を受けることができ、各ITベンダーの提案を客観的に評価することができます。つまり、RFPの目的とは「広く、より良い提案を受け、より良い調達をする」ためなのです。

RFPとよく似た言葉にRFIがあります。RFIは(Request For Information)の略で、情報提供依頼書と訳されています。具体的には、ERPなどのパッケージ導入の際に、製品情報や導入事例などを広く集め、検討する際にRFIは利用されます。

一般的な情報を求めるのがRFI、個別具体的な提案を求めるのがRFPであると理解してください。

RFPとRFIとの違いとは？エンジニアがシステム開発に活用するコツ

RFPのメリット・デメリット

RFPについての理解をより深めるために、そのメリット、デメリットについて考察してみましょう。

RFPの必要性を理解するためには、RFPのメリットを理解しておく必要があります。

1.提案レベルの向上と合理的なベンダー選定 要件の明確化によって、要件に沿った提案をもらえる確率が上がります。またRFPを作成することによって、ITベンダーの提案レベルが上がり、提案内容の詰めを行うための時間を短縮できます。

2.ITベンダー評価がしやすくなる RFPに基づいた提案を受ける事によって、ITベンダー各社の提案を横並びで比較、評価がしやすくなります。

3.発注先との誤解やトラブル軽減ができる システム導入の際、発注側と受注側の間に齟齬が生じ、大幅なシステム変更、納期遅延、委託費の増額といったトラブルが起こりがちです。双方の認識の違いがこのようなトラブルの原因となるのです。 RFPは双方が文書で予めトラブルを招きやすい項目について確認し合えるため、トラブルを最小限に止めることができます。 「言った、言わない、聞いた、聞いていない」という両者の食い違いを防ぐ上でもRFPを作成しておくことは大きな意味があります。

4.システム導入目的や要件などのベクトルを合わせやすい RFPの作成により、システム導入の目的や要件を明確にできます。これにより、発注者とベンダー側のベクトルが一致し、より精度の高いシステム構築が可能となります。 

5.経営層や関係部門の理解と合意が得やすい RFPを作成し、経営層や関係部門に予め説明しておくことで、システム導入に対する経営層や関係部門の合意が得やすくなります。また協力を得やすくなるため、プロジェクトの進行が円滑になります。システム部門には根回しが苦手な方も少なくありませんが、RFPは根回しにも極めて高い効力を発揮します。経営層は、システム部門は問題意識や経営的な視点を持っていないと誤解しがちです。RFPを示すことで、システム部門の役割が見直されるきっかけに繋がるでしょう。

RFPの策定にデメリットはほぼありませんが、敢えてあげるならば、以下のデメリットがあります。

1. RFP作成に労力が掛かる RFPの策定にはかなりの労力が必要です。RFPを採用する前は、ベンダーの営業が御用聞き、ヒアリングに来てくれ、こちらが要件を伝えるだけで提案をしてもらえた時代もあります。そうした経験をしているシステム部門の方には、それがRFPのデメリットだと感じられるでしょう。

2. システム開発までの準備に時間が掛かる 過去には、システムは専門領域であり、システムはシステム部門に任せるという考え方が経営層の中にはありました。そうした誤解により、システム構築はシステム部門の専権事項だという我田引水的な考えもはびこっていたのです。

しかしRFPの策定においては経営課題、各部門の問題点なども整理する必要があり、また推進体制を整備するなど、従来のシステム構築では時間を掛けなかったところに注力する必要が生じるようになります。その結果として、従来よりもシステム開発着手までの時間が掛かるという、新たな問題が生まれました。確かに、RFPによってシステム開発の前工程の負荷が大きくなるのは事実です。しかし、完成したシステムの精度、そのパフォーマンスは明らかに向上し、手戻りやトラブルも少なくなり、トータルでは余計な労力やコストを防ぐことが可能になります。

システム開発とは？ITエンジニアを目指す上で必須の基本知識を解説！

RFP策定前に注意すべきこと

RFPは机上の空論では意味がありません。RFPにはしっかり事実を記載し、精度が高く、しかも実現可能なものでなければなりません。そのようなRFPを策定するには、さまざまな準備が必要です。

システムを構築し、導入する目的には経営課題の達成、売上増進やコスト削減、各部門の問題解決などがあります。それらを実現するためには、ステークホルダー(利害関係者)の参画が欠かせず、プロジェクトの編成が必要です。むしろ、関係部門を巻き込むことがプロジェクトの成功には欠かせないといえます。

プロジェクトを進める上では人・モノ・金が必要です。経営層の理解や承認が得られなければ、プロジェクトそのものが成立しません。そのためにも、プロジェクト編成に対して経営側の事前の理解を得ておくことが必要です。よく、RFPの策定からベンダー選定までシステム部門だけで進めてしまい、事後承諾のような形で経営側の決裁を得る方がいますが、万一否決をされてしまうと、契約不履行として訴訟問題に至る場合もあり得ます。ここは面倒でも、きちんと経営層の理解と協力を得ておくことが求められます。

経営層の理解を得られるようなRFPの策定というのは、大変難しいものです。RFPを策定する人に経営的センスがなければ、経営層を納得させるだけのRFPの策定はできません。RFPの策定が身の丈を超える難易度の高いものである場合は、ITコンサルタントなどの協力を求めることです。ITコンサルタントの多くは、経営層の理解や協力を得るコツも心得ている方が少なくありません。

IТコンサルタント企業の一覧！仕事内容や年収、必要なスキル・資格を解説

RFPを作成してみよう

RFPを策定するのは誰の仕事か？おそらくこの記事を読まれた方は他人事のように思っておられるかもしれませんが、RFP策定は、SEがキャリアアップしていくための外せない階段です。将来的にシステムプランナーやプロジェクトリーダー、ITコンサルタントなどを目指すなら、RFP策定のスキルは身に付けておく必要があります。

RFPには基本的に記載すべきことがほぼ決まっています。テンプレートを用意しているSIerなどもあります。そうしたものを参考にしながら、まずは自分で作成してみることが重要です。

プロジェクト成功の鍵！プロジェクトリーダーの役割について解説

ITコンサルタントになるために必要な資格は？仕事内容や年収も

RFPには最低限、以下の内容を盛り込んでおく必要があります。チェックリストとしてもご利用ください。

1.概要    案件に関する全体像をITベンダーに理解してもらうための情報を記載します。 □目的：何を提案してもらいたいのか □背景：プロジェクト推進の経営的背景など □課題：抱えている問題や解決したい課題 □プロジェクトの目的：プロジェクトが何を目的として何を狙っているのか □ゴール：達成すべき品質や納期など □範囲：システム導入の範囲 □会社情報：事業内容、組織図、拠点情報、システム利用者情報、関係部門などの情報 □システム構成：現行システムやハード、ネットワーク、関係システムの情報

2.要件   要件にはITベンダーに提案書に盛り込んでほしい情報を記載します。また、導入事例や同様のプロジェクトの実績があれば、それらも可能な限り記載してもらいましょう。 □貴社情報：提案する側のITベンダーの会社情報(資本関係、協力会社、サービス内容や製品情報など □提案システムの概要：どのようなシステムを提案するのかを分かりやすく記載 □期待される効果：提案するシステムによってどのような効果が得られるのか(定性効果、定量効果) □提案システム構成 □プロジェクト体制とスケジュール □プロジェクトマネジメントの方法(レビューボード、進捗会議など) □プロジェクトの推進方法 □運用、保守の内容 □サービスレベル(SLA…Service Level Agreement) □納品予定物一覧 □ドキュメントのサンプル □概算工数と概算費用 □導入事例 □著作権の帰属先(一般的には作成した人に帰属する) □契約書案　など

3. 選定方法など どのようにベンダーの選定を行うのかを記載します。 □選定スケジュール：提案書の提出期日、プレゼンテーションの日程 □選考結果の連絡方法 □RFPに関する問合せ先 □提案書の提出先、提出方法(紙媒体、電子ファイル) □評価の方針：重視するポイント  など

以上のRFPの記載内容から、非常にボリュームがあることがお分かり頂けたと思います。これを1人で全て仕上げるのは至難の業です。

RFPはシステム部門を中心に策定していきますが、他部門の協力も必要です。またシステム部門の中でも企画・開発・運用それぞれの担当者の参画が必須です。RFPに盛り込む項目が決まったら、分担を決め、適宜進捗報告や擦り合わせをしましょう。

また、次回のRFP策定に備えて、この機会に会社としてのRFPのひな型を作ってしまいましょう。初回は手探りの部分もありますが、ひな型を作成してしまえば、次回からはかなりスピードアップ、精度アップが可能となるはずです。

良いRFPを策定できる会社には、次第に優秀なベンダーが集まるようになっていきます。RFPを求めてこないITベンダーは逆に信用できません。またRFPは発注側の顔となりますので、是非よいRFP策定を目指してください。