「RFPとは?」「書き方が知りたい」「rfp作成のテンプレートが欲しい」そんな人向けに、サンプルを用いて分かりやすく解説します。中小企業のWebシステム開発で使い勝手のよいフォーマットを示しながら、詳しい構成や作り方のコツを伝授。ITの知識がない人も、このひな形を参考にぜひチャレンジしてみましょう。解説/ノウハウ294800333Webシステム開発の受託側と発注側の両方に長年携わってきた筆者が、本当にあった失敗事例やつまづきやすいポイントを紹介しながら、Webシステム開発の知識や経験が浅い担当者が、自社に最も適したシステム開発会社を見つけ出すための正しい道筋を、全5回に分けて解説する。要望を伝えたつもりなのに、ピンとのずれた提案ばかり酒蔵メーカー「永鶴酒造」の山下さんは、ECサイトを新たに開発するため、比較検討の末に選び抜いたシステム開発会社3社と、それぞれ打ち合わせを行った。説明資料や企画書などは事前に用意せず、口頭でどんどん要望を伝えていく山下さん。盛り上がって話が本題から脱線したり、その場で思いついたアイデアを口にしたり。開発会社の営業担当は山下さんの話を笑顔でうなずきながら、必死にメモを取る。後日、3社から出揃った見積と提案書を見ると、ある会社は必須と伝えたつもりの要素が含まれていなかったり、自社の課題からずれた提案だったりした。ある会社は、その場の勢いで盛り上がった内容がすべて反映され、大幅に予算を超過した見当違いの見積になっていた。結局、山下さんはすべての開発会社に再度説明をするはめになってしまった......。※社名や登場人物は架空のものです。Proposal/提案依頼書)の作成だ。RFPは開発会社に良い提案をもらうための重要な情報伝達手段であり、プロジェクト全体の質を高めるためにも欠かせない要素となる。第3回では、中小企業のWebシステム開発で使い勝手のよいフォーマットを示しながら、RFP作成にあたって注意すべきこと、基本的な考え方などを解説する。Proposal(提案依頼書)の略で、発注企業がシステム開発を行う際に必要な要件をまとめ、発注先の開発会社に具体的な提案を依頼するための資料だ。システム開発の発注経験がない担当者が、次のように疑問に思うケースも少なくない。お金を払う側(発注企業)が、お金をもらう側(システム開発会社)のために、なぜ手間をかけてわざわざ説明資料を準備しなければならないのか、一から相談に乗ってくれるものではないのかしかし、何も用意せず、すべて口頭で進めるのは後々の失敗につながる可能性が高い。伝達の達成レベルが、説明する側・受け手側個人の能力やその時の状況に大きく影響され、次のようなことが起こり得るからだ。説明する側(発注企業)各社に伝える内容が、ミーティングごとにブレる。その場の話の盛り上がりに流され、伝えるべきポイントの強弱や優先順位にバラつきが出る。その時の体調や精神状態などで、伝えるべきことが抜ける、忘れる。受け手側(システム開発会社)説明者の話に丁重に対応しながら、すべてメモを取ることは困難。メモを取りながら同時に質問することは難しく、確認漏れが起こりやすい。開発会社の担当者は、発注企業から直接説明を聞く営業、技術的な部分を考える社内のエンジニアというように、役割が分かれている場合が多い。口頭だけだと、すべての情報は直接話を聞いた人の「メモ」と「記憶」だけになる。開発会社のなかで「伝言ゲーム」が発生し、情報が誤った形で伝わる可能性があるのだ。口頭での伝達は、正確な情報や一番解決したいことを開発会社へ明確に伝えることは不可能に近い。[2]では、開発会社に声をかける前に最低限準備すべきことがあると話したが、それは提案依頼でも同じで、発注企業がシステム開発の要望を正確に伝えるためには説明資料であるRFPを準備すべきであり、それが良い提案を引き出すことにつながる。RFPは正しい情報を提供し、良い提案をもらうための手段RFPは、システム開発業界では一般的な用語であるが、発注が未経験の人には耳慣れない言葉だろう。RFPといっても、難しく構える必要はまったくない。良い提案をもらうために、できるかぎり限り正確な情報を正しく伝えるための説明資料だと考えればよい。RFP作成の目的は、システム開発会社へ、解決したい課題や達成したい目的・目標を明確に伝えることなのである。依頼したいシステム開発の全容をシンプルに理解させるためのもの。スケジュールなどを記載する。具体的に何を満たした提案が欲しいかということを具体的に示したもの。その他1と2以外に伝えた方がよいと思われる情報、判断に迷っていることなどを補足として記載する。想定する競合サイト全体の構成をふまえて、実際に作成したRFPのサンプルは以下の通りだ。注意すべき点はcheckポイントとして、後半で詳しく解説する。開発にあたっての初期費用:300万円を上限とする保守・運用は上記300万円に含めない。(Flash使用有無、ブラウザなど)はアドバイスがほしいフィーチャーフォン版では、PC同等まで対応すべきか弊社が保有する商品画像はカタログ印刷用のみ。雑誌の比較記事や店員のおすすめなどを参考にして、いろいろな銘柄を試したがる人が多い試飲して自分の好みに合っていると思えば気前よくお買い上げ来店の際は異なる銘柄を数本まとめて買って行く人が多い(1回の来店での平均購買単価は7,000円程度)合わせる酒の肴(料理)や酒器にも関心、こだわりがある人が多い「これ!」というお気に入りの銘柄が見つかれば、定期的にリピート買いする人が多い以上6つのRFP作成チェックポイントRFPの作成では、いくつか押さえておくべきポイントがある。重要なポイントに絞って解説していこう。開発プロジェクト名を共有できているかまずプロジェクト名を必ず記載する。ECサイト開発計画」など簡単なもので十分だ。企画書にタイトルを書くのと同じで、プロジェクト名称があると、共通のゴールを発注側、受注側で共有しやすくなる。これらは、本連載の第1回で作成したものがベースにあれば、すぐにできあがるはずだ。目標(ゴール)は売上などの数値目標も示せるとよい。システム開発会社の役割、期待することは明示してあるかRFP作成で重要なことの1つは、発注企業と開発会社の役割分担を明確にすることだ。ここが曖昧な状態だと、「これは(相手方が)やってくれるはず」といったお互いの思い違いから、後々タスクのお見合いが発生して、トラブルになりやすい。ポイントは、「必ず提案してほしいこと」「可能であれば提案してほしいこと」を明確に記載することだ。実際に対応してくれるシステム開発会社のメンバーはだれか開発会社の開発体制、メンバーは提案の段階で具体的になっていた方がよい。受注が決まるまでは、社長をはじめとするメンバーが真摯に対応してくれたものの、受注が決まった途端、「あとはエンジニアと直接やり取りしてくれ」という状況になり、困ってしまったという話もよく耳にする。プロジェクトを仕切るリーダーは、過去の経験や実績だけではなく、プレゼンに参加させて人柄や相性などもチェックすべきだ。受注後もプロジェクトにコミットしてもらうために、必ずミーティングに参加することを条件に入れるのもよい。判断に迷っていること、よくわからないことをリストアップRFP作成の段階では、何をどこまで開発するか、すべて決まっていないことの方が多い。その場合は、迷っていることを開発会社にきちんと伝えることが重要だ。すると、開発会社は開発した場合のメリット、デメリットなどをふまえて、提案を考えることができる。中小企業のITに詳しくない担当者だと、当然、技術的によくわからないいことも多い。その場合は、わからないこと、疑問に思っていることを正面から伝えた方が、発注企業と開発会社、お互いのためになる。業界特有の専門用語など、わかったつもりで話を進めてしまうのも危険だ。役立つと思った情報はどんどん提供していく上記以外に、これは開発会社に伝えておくと提案に役立ちそうと思うことは、遠慮せずにどんどん提供していこう。発注側にとっては当たり前のことでも、参考になる情報は多い。ECサイトの場合だと、競合と意識しているサイト、自社に合いそうなデザインに近いサイトなどを教えてあげると、開発会社の業界調査が効率的に行えるうえ、デザインのイメージの相違なども避けやすくなる。サイト情報だけではなく、自社のカタログやパンフレット、過去の販促物など、紙媒体も同様に参考になるので、ぜひ一式を準備することをおすすめする。雛形は参考にしながらも、こだわる必要はないRFPの作成は、RFPにフォーカスした書籍が多数あるほど奥深いテーマだ。インターネットで検索すると、さまざまなフォーマットを見つけることができるだろう。[4]上記サイトをざっとながめるだけでも、さまざまなフォーマットがあることがわかる。本稿でも、いろいろな参考事例やサンプルを提示し、RFPの作成について解説をしたが、特定のフォーマットに必ずしもこだわる必要はない。作成した書類を今回紹介したチェックポイントをベースに見直し、伝えるべき情報が抜けていないか、まだ検討しきれてないことはないか、確認しながらブラッシュアップを繰り返し、社内で意思統一するための叩き台のような形で利用しながら作成していけばよい。上記で紹介したITコーディネータの見本などはかなりのボリュームがあり、敷居が高いと感じるかもしれないが、はじめから完璧なRFPでなくてもOKということを伝えておこう。システム開発に慣れた大企業の人でも、まったく漏れのない完璧なRFPを作ることは非常に難しい。中小企業のシステム開発の発注経験がない担当者ならなおさらのことだ。RFPはあくまで質の高い提案をもらうためのものであり、良い提案をもらい、発注先が決まればその役目を終え、開発の詳細な設計資料の作成へと移っていく。最終的にRFPの目的(良い提案をもらうこと)が果たされれば、必ずしも完璧なRFPを完成させる必要もないのだ。いって手を抜いていいわけではなく、発注企業の担当者は、できる限り正確な情報を伝えるため、良いRFPを作成する努力は行わなければいけない。それでも足らなかったり、抜けてしまったりする部分を補ってくれる開発会社が、その企業にとってベストパートナーになると筆者は考える。[5]で説明する「オリエンテーション」や提案の内容などをふまえながら、判断していけばよいだろう。http://b.hatena.ne.jp/entry/https%3A%2F%2Fwebtan.impress.co.jp%2Fe%2F2013%2F03%2F15%2F14724。