RFP(提案依頼書)とは？意味を理解してらくらく作成！[サンプルあり]／第3回

きちんと要望を伝えたつもりなのに、ピンとのずれた提案ばかり

酒蔵メーカー「永鶴酒造」の山下さんは、ECサイトを新たに開発するため、比較検討の末に選び抜いたシステム開発会社3社と、それぞれ打ち合わせを行った。

特に説明資料や企画書などは事前に用意せず、口頭でどんどん要望を伝えていく山下さん。つい盛り上がって話が本題から脱線したり、その場で思いついたアイデアを口にしたり。開発会社の営業担当は山下さんの話を笑顔でうなずきながら、必死にメモを取る。

後日、3社から出揃った見積と提案書を見ると、ある会社は必須と伝えたつもりの要素が含まれていなかったり、自社の課題からずれた提案だったりした。また、ある会社は、その場の勢いで盛り上がった内容がすべて反映され、大幅に予算を超過した見当違いの見積になっていた。結局、山下さんはすべての開発会社に再度説明をするはめになってしまった……。

※社名や登場人物は架空のものです。

Webシステム開発全体の流れ
第3回は「提案依頼書（RFP）作成」を解説

リサーチとヒアリングによって発注先のシステム開発会社を絞り込んだら、いよいよ提案をもらうことになるのだが、ここで重要なのがRFP（Request For Proposal／提案依頼書）の作成だ。RFPは開発会社に良い提案をもらうための重要な情報伝達手段であり、プロジェクト全体の質を高めるためにも欠かせない要素となる。

第3回では、中小企業のWebシステム開発で使い勝手のよいフォーマットを示しながら、RFP作成にあたって注意すべきこと、基本的な考え方などを解説する。

「直接口頭で伝えればいい」は、プロジェクト失敗への第一歩

RFPとは、Request For Proposal（提案依頼書）の略で、発注企業がシステム開発を行う際に必要な要件をまとめ、発注先の開発会社に具体的な提案を依頼するための資料だ。

システム開発の発注経験がない担当者が、次のように疑問に思うケースも少なくない。

お金を払う側（発注企業）が、お金をもらう側（システム開発会社）のために、なぜ手間をかけてわざわざ説明資料を準備しなければならないのか、一から相談に乗ってくれるものではないのか

しかし、何も用意せず、すべて口頭で進めるのは後々の失敗につながる可能性が高い。伝達の達成レベルが、説明する側・受け手側個人の能力やその時の状況に大きく影響され、次のようなことが起こり得るからだ。

• 各社に伝える内容が、ミーティングごとにブレる。
• その場の話の盛り上がりに流され、伝えるべきポイントの強弱や優先順位にバラつきが出る。
• その時の体調や精神状態などで、伝えるべきことが抜ける、忘れる。

• 説明者の話に丁重に対応しながら、すべてメモを取ることは困難。
• メモを取りながら同時に質問することは難しく、確認漏れが起こりやすい。

開発会社の担当者は、発注企業から直接説明を聞く営業、技術的な部分を考える社内のエンジニアというように、役割が分かれている場合が多い。口頭だけだと、すべての情報は直接話を聞いた人の「メモ」と「記憶」だけになる。つまり、開発会社のなかで「伝言ゲーム」が発生し、情報が誤った形で伝わる可能性があるのだ。

口頭での伝達は、正確な情報や一番解決したいことを開発会社へ明確に伝えることは不可能に近い。第1回では、開発会社に声をかける前に最低限準備すべきことがあると話したが、それは提案依頼でも同じで、発注企業がシステム開発の要望を正確に伝えるためには説明資料であるRFPを準備すべきであり、それが良い提案を引き出すことにつながる。

RFPは正しい情報を提供し、良い提案をもらうための手段

RFPは、システム開発業界では一般的な用語であるが、発注が未経験の人には耳慣れない言葉だろう。ただRFPといっても、難しく構える必要はまったくない。良い提案をもらうために、できるかぎり限り正確な情報を正しく伝えるための説明資料だと考えればよい。つまり、RFP作成の目的は、

システム開発会社へ、解決したい課題や達成したい目的・目標を明確に伝えること

なのである。具体的なRFPの作成方法は、全体構成を次の3つに大きく分けて考えると作成しやすい。

1. 全体像

   今回提案を依頼したいシステム開発の全容をシンプルに理解させるためのもの。
   開発の目的、目標、予算、スケジュールなどを記載する。

2. 提案の要件

   具体的に何を満たした提案が欲しいかということを具体的に示したもの。
   提案を依頼したい範囲、役割分担、必須な機能、運用・保守、成果物を記載する。

3. その他

   1と2以外に伝えた方がよいと思われる情報、判断に迷っていることなどを補足として記載する。

全体の構成をふまえて、実際に作成したRFPのサンプルは以下の通りだ。特に注意すべき点はcheckポイントとして、後半で詳しく解説する。

6つのRFP作成チェックポイント

RFPの作成では、いくつか押さえておくべきポイントがある。特に重要なポイントに絞って解説していこう。

• check1　開発プロジェクト名を共有できているか

  まずプロジェクト名を必ず記載する。これは「●●社　ECサイト開発計画」など簡単なもので十分だ。企画書にタイトルを書くのと同じで、プロジェクト名称があると、共通のゴールを発注側、受注側で共有しやすくなる。

• check2　最低限必要な項目が含まれているか

  システムの全体像を把握するために最低限必要な項目は、「開発の目的」「成果」「予算」「スケジュール」だ。これらは、本連載の第1回で作成したものがベースにあれば、すぐにできあがるはずだ。また、目標（ゴール）は売上などの数値目標も示せるとよい。

• check3　システム開発会社の役割、期待することは明示してあるか

  RFP作成で重要なことの1つは、発注企業と開発会社の役割分担を明確にすることだ。ここが曖昧な状態だと、「これは（相手方が）やってくれるはず」といったお互いの思い違いから、後々タスクのお見合いが発生して、トラブルになりやすい。

  ポイントは、「必ず提案してほしいこと」「可能であれば提案してほしいこと」を明確に記載することだ。

• check4　実際に対応してくれるシステム開発会社のメンバーはだれか

  開発会社の開発体制、メンバーは提案の段階で具体的になっていた方がよい。受注が決まるまでは、社長をはじめとするメンバーが真摯に対応してくれたものの、受注が決まった途端、「あとはエンジニアと直接やり取りしてくれ」という状況になり、困ってしまったという話もよく耳にする。

  特に、プロジェクトを仕切るリーダーは、過去の経験や実績だけではなく、プレゼンに参加させて人柄や相性などもチェックすべきだ。また、受注後もプロジェクトにコミットしてもらうために、必ずミーティングに参加することを条件に入れるのもよい。

• check5　判断に迷っていること、よくわからないことをリストアップ

  RFP作成の段階では、何をどこまで開発するか、すべて決まっていないことの方が多い。その場合は、迷っていることを開発会社にきちんと伝えることが重要だ。そうすると、開発会社は開発した場合のメリット、デメリットなどをふまえて、提案を考えることができる。

  また、中小企業のITに詳しくない担当者だと、当然、技術的によくわからないいことも多い。その場合は、わからないこと、疑問に思っていることを正面から伝えた方が、発注企業と開発会社、お互いのためになる。業界特有の専門用語など、わかったつもりで話を進めてしまうのも危険だ。

• check6　役立つと思った情報はどんどん提供していく

  上記以外に、これは開発会社に伝えておくと提案に役立ちそうと思うことは、遠慮せずにどんどん提供していこう。発注側にとっては当たり前のことでも、参考になる情報は多い。ECサイトの場合だと、競合と意識しているサイト、自社に合いそうなデザインに近いサイトなどを教えてあげると、開発会社の業界調査が効率的に行えるうえ、デザインのイメージの相違なども避けやすくなる。

  また、サイト情報だけではなく、自社のカタログやパンフレット、過去の販促物など、紙媒体も同様に参考になるので、ぜひ一式を準備することをおすすめする。

雛形は参考にしながらも、こだわる必要はない

RFPの作成は、RFPにフォーカスした書籍が多数あるほど奥深いテーマだ。インターネットで検索すると、さまざまなフォーマットを見つけることができるだろう。

• RFP/SLA見本（ITコーディネータ協会）
• RFP書き方のまとめ（NAVERまとめ）

上記サイトをざっとながめるだけでも、さまざまなフォーマットがあることがわかる。本稿でも、いろいろな参考事例やサンプルを提示し、RFPの作成について解説をしたが、特定のフォーマットに必ずしもこだわる必要はない。作成した書類を今回紹介したチェックポイントをベースに見直し、伝えるべき情報が抜けていないか、まだ検討しきれてないことはないか、確認しながらブラッシュアップを繰り返し、社内で意思統一するための叩き台のような形で利用しながら作成していけばよい。

たとえば、上記で紹介したITコーディネータの見本などはかなりのボリュームがあり、敷居が高いと感じるかもしれないが、

はじめから完璧なRFPでなくてもOK

ということを伝えておこう。システム開発に慣れた大企業の人でも、まったく漏れのない完璧なRFPを作ることは非常に難しい。中小企業のシステム開発の発注経験がない担当者ならなおさらのことだ。

また、RFPはあくまで質の高い提案をもらうためのものであり、良い提案をもらい、発注先が決まればその役目を終え、開発の詳細な設計資料の作成へと移っていく。最終的にRFPの目的（良い提案をもらうこと）が果たされれば、必ずしも完璧なRFPを完成させる必要もないのだ。

だからといって手を抜いていいわけではなく、発注企業の担当者は、できる限り正確な情報を伝えるため、良いRFPを作成する努力は行わなければいけない。しかし、それでも足らなかったり、抜けてしまったりする部分を補ってくれる開発会社が、その企業にとってベストパートナーになると筆者は考える。それらの見極めは、第4回で説明する「オリエンテーション」や提案の内容などをふまえながら、判断していけばよいだろう。