イベント・ニュース

情シスさんのためのRFPの書き方(前編)

Written by aki(あき)

ネットワークエンジニア
大手Nierでネットワークエンジニアとして最前線で戦う傍ら、個人運営のサイト「ネットワークエンジニアを目指して」を運営し、読者を「ネットワークトラブルに恐れることなく立ち向かえるネットワークエンジニア」へと導くことを信条に、ネットワーク技術の解説と自身のノウハウを広めている。著書に「見てわかるTCP/IP」など。Twitter:itbook

情シスさんのためのRFPの書き方(前編)

システムの開発や構築を社外のベンダーに依頼する場合、システムに対する要求を各ベンダーに伝える必要があります。そのための文書がRFP(Request For Proposal)といわれるものです。

ベンダーは基本的に、このRFPに書かれている要求事項をもとに見積りを作成し、システムを構築することになります。
そのためRFPには、ベンダーに伝えなければいけない内容を漏れなくダブリなく記載する必要があります。

RFPは「欲しいモノ」を確実に調達するための重要なドキュメントです。今回は情シスさん、特にRFPの作成経験が少ない情シス担当者向けに、RFPを作成する上でおさえておきたいポイントやRFPの書き方について説明していきます。

RFPとは

RFPは「Request For Proposal」の略で、モノやサービスを調達したいときに調達したい内容を書いてベンダーに提案を依頼するための文書のことです。たまに勘違いされる方もいますが、RFPはシステムを構築するためのものではありません。
RFPを使ってベンダーにプロジェクトの要件を伝え、ベンダーはRFPの内容をもとに見積りや提案書を作成します。
情シスがどのようなシステムを構築したいのかを明確にベンダーに伝えるためにとても重要なドキュメントで、RFPの内容が薄かったり漏れがあるとベンダーからは期待した提案内容を受け取ることはできません。

最悪の場合、開発が終わってみたら全然期待したシステムではなかったということにもなりかねません。
ベンダーはRFPを読んで、各社の強みを活かした提案を行い、依頼者側がその提案を気に入れば晴れて契約となり、システムや機器などを購入します。

RFPを複数のベンダーに送付して、その中からもっとも要件に合ったベンダーから購入する「入札」の形式もあれば、あらかじめ決まったベンダーにだけ提案をしてもらうような場合でも、システムの依頼内容を伝える意味で作成することもあります。

RFPという言葉を聞くと少し難しそうと思うかもしれませんが、日常の買い物も同じようなことをしています。
たとえばパソコンを購入しようとしたときに、事前に性能やデザイン、価格などの情報を入手して、目的に合ったパソコンを検討します。購入したいパソコンを決めたら、さまざまな電気店やネットショップから価格が安いショップで購入することを決めたとします。
個人で購入するレベルであれば、自分で調べて最適なモノを調達するだけですが、企業が導入するようなシステムの場合はそうはいきません。企業で導入するシステムでも特に高額な場合、RFPという書面をベンダーに発出し、ベンダーから提案をもらい「モノ」を調達します。

RFPを作成するメリット

RFPの作成には手間も時間もかかり、出来れば避けたいと思う方もいるかもしれません。しかし、RFPを作成することで次のようなメリットが生まれます。

提案内容の基準となる

各ベンダーに提案を依頼する際、どのようなシステムが欲しいのかを伝える必要があります。ベンダーに口頭やメールで簡単に伝えるだけだと、ベンダーが想定する部分が多くなり、各ベンダーで提案内容もバラバラになりがちです。
結果的にベンダーの選定基準も難しくなりますし、ベンダー選定後も事前に想定していたシステムとはかけ離れたものになってしまうリスクも高くなります。

しっかりと発注者側と提案者側で、最終納品物のイメージを合わせることはとても重要です。プロジェクトが動き出してから必須要件が漏れていることに気付き、改修が必要になると余計な工数もかかりますし、スケジュールも遅れることになります。

また複数のベンダーに提案依頼する場合、RFPを1つ作成しておけば複数社にRFPを送るだけでよく、何度も同じ説明をしなくて済むというメリットもあります。

提案内容のエビデンスになる

ビジネスでの「言った言わない論争」ほど不幸なことはありません。口頭で要件を伝えたつもりが、相手の捉え方が違っていた、というような認識のズレが発生することは多々あります。そのような「言った言わない」を防ぐためにもRFPを作成するメリットはあります。

特に必須要件や考慮が必要な要件、ポイントとなる要件などをRFPに記載することで、それがエビデンスとなり余計なトラブルを防ぐことができますし、期待している提案を引き出すことができます。

提案の評価基準になる

複数のベンダーに提案依頼をする場合、最終的にどのベンダーを選択するのかを何らかの基準で決める必要があります。RFPはその際の評価基準としても活用できます。各ベンダーがRFPに記載した内容を満たした提案をしているか、漏れている項目は無いかなどRFPの内容をもとに選定を行うことができ、別途選定基準を検討する手間も省けます。

情シスがモノを調達する流れ

実際にRFPを活用して「モノ」を調達するときの、各ステークホルダーの関係とポイントは次のようになります。

ビジネス改善要望

システムの見直しや更改は、ユーザー部門からのシステムの改善要求や現状の課題からスタートすることが一般的です。システムの更改を失敗する原因の多くは、ユーザー部門が持っている課題を誤解したままシステム更改を進めてしまうことです。
まずは現場が現状のシステムに対して、何が困っているのかを日々収集しておくことが重要です。

システム更改検討

ユーザー部門から収集した課題や、ユーザー部門からのシステム改善要望などから、システムの更改や新規構築の検討を行います。ここで検討した内容がRFPへと盛り込まれます。具体的にどのようなシステムを構築するのかを検討した後に、そのシステムを実現するために、「いつ(When)、どこで(Where)、だれが(Who)、なにを(What)、なぜ(Why)、どのように(How)」調達を行うのかを決めます。

RFP作成

システム更改の検討を行った後は、RFPを作成していきます。RFPには企業のシステム基盤や調達への要求を含めた依頼内容を文書化します。RFPに記載する具体的な内容は別途ご紹介します。

RFP発出

RFPを作成した後は、各ベンダーにRFPを発出します。どのベンダーに発出するかは企業によってさまざまですが、過去に付き合いのあるベンダーや要求の内容を満たしてくれそうなベンダーに発出するのが一般的です。

提案内容検討

RFPを受け取ったベンダー側では、RFPに記載されている要求内容を確認し、自社の製品や技術でどのように実現できるのかを検討します。

提案書提示

ベンダーが行うRFPの回答は見積りだけの場合もあれば、詳細な提案書を含めて提示する場合もあります。ベンダーからの回答は、RFPに記載されている要求事項をすべて満たすような内容となることが基本です。

ベンダー確定

各ベンダーから提案書を受領したら、各提案が要求どおりの提案内容になっているかを吟味します。具体的には価格や要求機能を満たすかだけでなく、ベンダー側の担当者、組織もしっかり確認し、自社の目的を十分に理解して進めていく体制であるかを確認することも重要なポイントです。
ベンダーからの回答は、当然実現可能な提案をしてきますので、どのベンダーも基本的には「出来ます」という回答になります。その結果、価格が最も安いベンダーを採用したところ、実は期限内に終了できるリソースを確保できずに、最終的にプロジェクトが頓挫してしまったという事態にもなりかねません。
このような問題を回避するために、あらかじめベンダーの評価項目を決めておくことが必要です。評価項目には価格や要求機能を満たすかという観点だけでなく、過去の導入実績や営業/SEの受け答え、将来の拡張提案など総合的に評価できるような観点を盛り込むようにします。

まとめ


今回はRFPを作成することの重要性、RFPを活用してシステムや物品などの「モノ」を調達する流れについて説明しました。今回の解説でRFPの重要性を改めて認識していただいたかと思います。
次回は、RFPに記載する内容や具体的な書き方について紹介していきます。