はじめてのRFP――発注時に意思疎通をスムーズにする提案依頼書の作り方

発注の基本はRFP作りから
発注をマスターしてベストな提案を引き出す
いちから覚える提案依頼書の作り方

制作会社など外部の業者に対して、具体的になにをしてもらいたいかの提案要求を伝える際に必要となるのが提案依頼書（RFP：Request for Proposal）だ。場合によっては、口頭の打ち合わせベースで仕事を進めることもあるかもしれないが、RFPを作ると作らないでは仕事の進め方に大きな差が出る。ここでは、RFPを作るときに必要な基本の要素を紹介しよう。

取材・文：編集部
協力：高橋 宏祐（富士通株式会社 コーポレートブランド室 担当部長）
富士通でエンジニア職を経験した後、1998年より富士通のウェブマスターとしてウェブ戦略を企画実行。2002年6月に富士通ウェブ・アクセシビリティ指針を公開し、日本のアクセシビリティ普及をリードする。2003年にFUJITSUウェブ・ユニバーサルデザインで「グッドデザイン賞」を受賞。2006年には第4回Webクリエーション・アウォード「Web人賞」を受賞。FUJITSUブランドのウェブマスターとして、世界35か国のグローバルサイトを管理する（Web担でのインタビュー記事）。

提案依頼書があると意思疎通がスムーズに

提案依頼書（RFP、アールエフピー）は、一般的に仕事を依頼する発注側が、依頼先に対してどういう仕事をしてもらいたいかを記載したものである。受注側からすれば要望を確認するためのものだ。一般的に、価格が優先される場合は「入札」と呼ばれ、技術的な事項やスキルが優先される場合には「プロポーザル（RFP）」という用語が使われる。たとえば、情報システムの発注においては、必要となるハードウェアやソフトウェアの仕様、品質条件、納品物品などが記載されるものだ（下記のサンプルRFPに示す）。

こう聞くとものものしく聞こえるが、簡単に言えば依頼先の会社に何をしてもらいたいか、その要求内容を文章にして明確に伝えるためのものだ。

外部の制作会社お願いするにしても、新しくウェブサイトを立ち上げようとする場合、まずは社内で計画を検討しているはずだ。どのレベルまで詳細に検討するかはともかくとして、どんな目的でウェブサイトを立ち上げるのか、ブログやSNSなどどんな機能がほしいのかといったことは、会議で決めて議事録としてまとめているだろう。そして制作会社に仕事を依頼するときには、会議で決まった（検討した）内容を基に依頼なり相談なりをするはずだ。ということは、RFPという言葉は知らなくても、多くの場合はそれに近い何かしらの書類は作っているはずだ。

仕事の進め方にはいろいろなケースがあるので、場合によっては口頭の打ち合わせベースで仕事を進めることもあるだろう。しかし、要求を文章で明確にすることでお互いの認識の差異をなくし、後々の工程での大幅な仕様変更や、そもそもの仕様の認識が異なるといった問題の発生を防ぐことができる。企業規模や案件規模、金額の大小は問わず、RFPを作ることで格段にプロジェクトの品質を上げることにつながるのだ。

発注側としては、依頼した内容と違う提案がされることの手間や手直しに費やす工数を減らすことができるし、予算超過やスケジュールの延期を防止できる。依頼される側の制作会社としても、その場感覚のあいまいな依頼内容のままで作業を進めることなく、ブレのない共通の認識をもつことで、想定したスケジュールや予算どおりに仕事を進めることができるわけだ。

あるとないとでは大違い、RFPで見える新たな発見

RFPを作ることのメリットは、何も依頼先との意思疎通がスムーズなるというだけではない。もう1つ、大きなメリットとして、自社内における関係者の理解が格段にスムーズになることがあげられる。会議のたびに「そうだったか？」と上司の言っていることが違う、「やっぱりあれもこれも」と思いつきでの意見が出てきた、といった経験の一度や二度はだれでもあるものだ。これは、制作会社とやりとりをするときも同じで、RFPを作ることで、打ち合わせのたびに言っていることが毎回異なるといったことをなくすこともできる。また、自チーム内での説明にも有用なツールとなる。RFPを議論の柱として、詳細仕様をチーム内で詰めて行くことができる。何よりも、RFPを作ることで頭の中が整理され、より良いアイデアや見落としていた仕様などが判明することが多いため、企画の質を上げる効果もあるわけだ。

また、過去のプロジェクト情報は大きなノウハウであり、工数や金額といった見積り算出はもとより、過去に作成したRFPは同様のプロジェクトの参考になる場合が多いので、ぜひ作っておきたい。RFPは発注時の正式依頼文書にも使えるので一石二鳥だ。

実際にRFPは、プロジェクト進行のどの段階で作るのがいいのだろうか。基本的には、プロジェクト立ち上げのタイミングになる。つまり、ウェブサイトの新規立ち上げなど、プロジェクトの全体像（作業範囲）が明らかになり、プロジェクトを遂行するのに外部に提案を依頼する必要が発生した段階だ（図1）。当然だが、予算が確保されていることが前提となる。

図1　RFP提出前後の一連の流れ（図はクリックで拡大）

困ったことに、RFPには決まった作り方がない。業種はもとより、企業によってそのフォーマットは異なるので、こればかりは経験を積み上げていくしかない。ただし、フォーマットはなくとも、依頼先の制作会社がヒアリングシートなどを用意している場合もあるので、社内にノウハウがない場合はまず相談してみるのも1つの手だ。

「富士通キッズサイト」のRFPにみる提案依頼書の作り方

図2　「富士通キッズ」は、子供の理数系離れを食い止めるために企画された子供向けのコンテンツ。Flashアニメーションを利用して子供が楽しめるようにしたり、プリントして学校に持って行くことを想定してA4縦で印刷できるようにしたりと、いろいろな工夫がなされている。

では、「富士通キッズサイト」（図2）のRFPをサンプルとして紹介しよう。ここで示したRFPは、富士通が実際に「富士通キッズサイト」を作った際に使用したRFPを誌面用に多少調整したものなので、実際に利用されたRFPに近いものだと思ってもらっていい。

各項目に関してさらに詳しい解説を、サンプルRFPのあとで示しているので、まずはざっと「RFPとはどんなものか」をみたうえで、作るうえでの注意点などをチェックしてほしい。

発注主が確認しておくべきRFP各要素のチェック点

以下では、RFPに盛り込む各要素に関して解説する。サンプルRFPでの項目名を示して解説しているので、参考にしながら読んでほしい。

良いRFP作りの基本はプロジェクト名の決定から

RFPを初めて作る場合の意外なコツとして、「プロジェクト名称」を最初に決めるということがある。当たり前のようだが、初めにプロジェクト名を決めることで頭の中を整理できる。

続いて「プロジェクト概要」「プロジェクトの目標／ゴール」を決めていこう。目標にはたとえば「業界No.1のサイトになる！」のような構想や思いを、ゴールには「月間ページビュー数を10％アップ」のような客観的な数値目標を設定する。目標とゴールは、明示的に分けて記述する方が理解しやすい。

最低限この3つを決めたら、次にメインユーザー（利用するお客様の姿、想定するユーザーの姿）を考える。これは具体的であればあるほど良い。富士通キッズの場合ならば、単に「小学生」とするのではなく、「小学校高学年（4〜6年生）」、さらにはその保護者や学校の先生といった具合だ。

具体的な競合先がある場合は、例を示した方が制作会社も対策をイメージしやすく、提案のレベルアップにもつながる。

制作会社に相談に行くにしても、まずこれらの要素をおさえることで、スムーズな意思疎通ができるはずだ。

1.5「受託責任範囲（発注範囲）」

1.5「受託責任範囲（発注範囲）」は、提案の具体的な成果物（納品物）として何をどういった形で納品してほしいかを示したものだ。

企画書は当然として、ウェブサイト新規立ち上げともなると、デザインから中身のコンテンツ一式までが必要だ。成果物は費用に直結するので、しっかりと決めておくこと。社内にプロジェクトに利用できる資料などがある場合は、整理しておくとベストだ。細かな納品形式としては、「素材はCD-ROMで納品すること」「紙のサイトマップと仕様書を納品する」といったこともあげられる。納品物の一覧も必ずもらっておくこと。

忘れがちだが、納品物やその中で使っている画像や写真などの著作権や、ドメイン名の所有権がだれのものになるのかは、必ず明らかにしておこう。サイトで利用する権利を得ているだけで権利自体は制作会社が保持するのか、それとも権利が自社に帰属するようになるのかだ。これによって、ウェブサイトで使った素材をカタログや後ほどのリニューアルで流用する場合の自由度や手間が大きく変わってしまうからだ（もちろん費用にも反映されるが）。

納品物とは別に、どの作業をだれがどこまでやるのか、ドメイン名の取得やサーバー管理、コンテンツのアップロード作業はどうするかなども明確にしておくと、言った言わないといった後々のトラブルが少なくて済む。

1.6「ウェブサイトのスコープ（作業範囲）」

1.6「ウェブサイトのスコープ（作業範囲）」は、対象ユーザーとウェブサイトの戦略が見えていれば自ずと決まってくる項目だ。現在のウェブサイトの調査や分析から依頼する場合もあれば、求人コーナーなど、ある特定のコンテンツの企画立案をお願いすることも考えられる。このどこまでを対象範囲とするかは費用に影響するので明確にしておくこと。

1.7「検討対象」

1.7「検討対象」は、ウェブサイトの「目的／ゴール」を達成するために、具体的に何を提案してほしいかである。コンテンツなのかシステムなのか、ビジネス戦略なのかといったことを明らかにしておく。

ここは制作会社に提案してもらう部分でもあるので、社内であがった課題を洗い出して、提案を引き出すようにしよう。ウェブサイトのリニューアルであれば、現状の分析から依頼することも考えられる。

1.8「前提条件」

1.8「前提条件」は、必ずクリアしなければならないハードル、つまり制限を制作会社側にイメージさせるものだ。

一番わかりやすいのが締め切りだ。たとえば、どれほど実績のある制作会社でも、他の案件の進行があり「3か月後にサイトオープンする」という条件がクリアできないこともあるだろう。もしそうなら提案を断るしかない。

提案書自体の締め切りも考えておくべきだ。数社でプレゼンテーションを行う場合は、プレゼンの方式や提出資料のフォーマットなども決める必要があるだろう。

その他に、素材として使う写真はすべてオリジナルであること、社内資料の持ち出しは不可能であるといった要素があげられる。

1.9「品質要件」

1.9「品質要件」は成果物の質を決定する重要な要素だ。ただし、人の好みに左右される要素ではなく、客観的なチェック要素を用意すること。

ウェブサイトであれば、「高齢者・障害者に配慮したアクセシビリティ『JIS X8341-3』の必須要件をすべて満たすこと」のように、あらかじめ守るべき要件を掲示する。プログラムの設計であれば、必ずデバッグを行うはずだ。それと同じと考えればいい。

とはいえ、JISに準拠しているか、HTMLに間違いがないかなどを素人がチェックするのは難しいので、「一般公開されているチェックツールをクリアすること」のように、なにかしらの指標を設けるだけでもいい^※1。他には、社内のコンテンツガイドラインに沿うことや、デザインにこだわる場合は画像の解像度などを示しておこう。

1.10「技術的要件」

1.10「技術的要件」は、ウェブサイトであれば対応ブラウザやOSの種類、バージョンなどを記述する。

ただし、対応する条件が広くなればなるほど、検証作業に費やす予算が必要になる。対象ユーザーがどのような環境なのかわからない場合は、制作会社に最低限必要な条件を提案してもらうのもいいだろう。実績のある会社であれば、市場の情報にも詳しいはずだ。例外として、社内向けのサイトである場合、企業によってはセキュリティの関係上、機能制限を設けたシステムを使っている場合などもあるので、特殊な環境が前提の場合は注意しておこう。

2「マスタスケジュール」

2「マスタスケジュール」は、いつまでに提案が必要か、いつまでに実装するか、反映する時期はといったスケジュールを明記する部分だ。

この他に気をつけておきたいものに、「制約条件」がある。予算100万円、社長や役員向けに社内でプレゼンをしてOKをもらうことといったものだ。

こんなはずでは……ダメなRFPが招くトラブル

制作会社にRFPを提出して提案を受けたら、いよいよ契約してウェブサイトの制作に入ることになる（現実には打ち合わせをしながら正式なRFPを完成させる）。しかし、最終的なRFPで肝心な要素が抜け落ちていたために、場合によっては成果物がまったく使えないということにもなりかねない。良いRFPの作り方で説明した「プロジェクト名称」「プロジェクト概要」「目標／ゴール」はもちろんのことだが、特に気をつけたいのが納品物と作業範囲（作業分担）が明確でない場合、そして前提条件に漏れがある場合だ。

作業範囲は、たとえば、テストサーバー上でウェブサイトの稼働チェックが完璧であったとする。ところが、実際に納品されたHTMLファイルを本番用の自社サーバーで公開しようとしたところ、リンク先ディレクトリのURLが間違っていたため、すべてのHTMLファイルをすべて書き直す必要が出てきてしまった。こうしたとき、いったいだれが修正するのかとなるが、作業範囲に「本番用のサーバーでの稼働を検証すること」と明示してあれば、こうしたトラブルは起きないはずだ。

さらに悲惨なのが、そもそもの前提条件に抜けがある場合だ。せっかく完成しても、企業ブランドにそぐわないので公開できないといったことにもなりかねない。

RFPに必要な要素をここまであげてきたが、1ついえることは、最も重要なのは「納品物」と「品質条件」を明確に示すことだ。納品物は作業範囲や価格、ひいてはクオリティにも影響するので必ず示すこと。プロジェクトの途中でどうしても変更を要する場合もあるだろうが、そうしたときには「コスト」「品質」「スケジュール」のバランスがマッチしているかを再検討する。この3つは、1つの要素が他の2つにも影響を与えるので、変更のインパクトとリスクを考えることだ。特にスケジュール変更は社内だけでなく、外部の取引先にも影響を与える恐れがある。

品質については、前述したように、納品されたものがまったく使えなくて、社内ですべて作り直すということにもなりかねない。チェックツールでエラーがないことを確認するといったレベルでも構わないので、品質条件に加えることだ。これだけでもクオリティに違いが出る。富士通では、「富士通アクセシビリティ・アシスタンス」というツールを公開しているが、自社のRFPでも実際にこのツールによるチェックをクリア条件に設定している（図3）。

図3　富士通では、ユニバーサルデザインを基本としたデザイン活動の1つとして、視覚障害者や色覚障害者のアクセシビリティを高めるための診断ソフトウェアツール群「Fujitsu Accessibility Assistance」を無償で提供している。実際に富士通も品質条件のチェックにこれらのツールを利用しているという。

こう書くとRFPの作成は大変なように思えるが、1から10まですべてを自分で作る必要はない。最低限、目的は明確にしつつも、どういった解決策があるかなど、制作会社に相談するほうがスムーズに、かつ良いRFPを作れる場合もある。もし、門前払いされるようなら、依頼先を見直すのもきっかけにもなるだろう。ただし、自主性は持つこと。そして大切なのは人と人との付き合いつきあいなので、制作会社を問わずよいパートナーと付き合うことだ。