こんにちは、キノトロープアカデミーです。

「キノトロープアカデミー」は、Web業界のトップランナーである株式会社キノトロープの社員が講師を務めるオンラインアカデミーです。リモートワーク時代に不可欠な「個のスキル」を高め、職人のような「匠」を目指す人を増やしたい。そんな願いを込め、基礎から経営判断、業務フローまで、一生モノのナレッジを惜しみなく公開していきます。

＜初級編 第2回＞
RFPとは
についてお伝えします。

担当は濱田です。

初めに結論を申し上げると、RFP（提案依頼書）は、単なる仕様書やマニュアルではありません。

「提案依頼」を「制作依頼」にしない。このマインドセット一つで、集まる提案の質は劇的に変わります。

数多くの大型案件を手掛けてきたプロの視点から言える、失敗しないRFP作成の結論は、

・RFPの役割は「良い提案をもらうこと」：
情報を埋めることが目的ではなく、パートナーから最高の知恵を引き出すための資料と定義しましょう
・依頼内容に合わせて「粒度」を変える：
キャンペーンサイトならスピード重視、大規模サイトならバランス重視。内容に最適な情報提供が不可欠です
・「機能」より「目的・目標」を語る：
細かな機能の指定（制作依頼）に終始せず、プロジェクトで何を成し遂げたいかという「目的」をプロに委ねることが、成功への近道です

さらに詳しく" RFPとは"をテーマに、
今日お伝えしたいことは3つあります。

RFP、日本語に直すと提案依頼です。
Webサイトやシステムのリニューアルや新規構築をお願いするときに、発注側のクライアントから受注側の制作会社やシステムベンダーなどに送る、依頼内容をまとめた資料です。

コンペ等で制作を依頼する多くの場合、このRFPを作成することが一般的です。

しかし、Webサイトのリニューアルサイクルは一般的に3年～5年と言われます。

毎年実施するものではないため、Web担当者が任期中にRFP作成を経験されることはそう多くはないでしょう。

Webやシステムに関する知識・経験が浅い場合、どのような内容のRFPを作成すればよいか、そもそもRFPはどういうものか、というところから分からないこともあるかと思います。

試しに「RFPとは」で検索してみると、多くがこのような意味を返してきます

"依頼側（発注企業）がシステム開発を
行う際に必要な要件をまとめ、発注先の
開発会社に具体的な提案を依頼するための資料"

システム寄りの定義が多いです。

これとともに、様々なRFPのテンプレートがネット上に転がっています。
では、とにかくそのテンプレート通りにRFPを作ってみましょう。おそらく上手くいかないのではないかと思います。

入念に準備し、評判が良いとされる制作会社やシステム開発会社に声をかけ、提案をもらうも、コンペがうまくいかなかった、ということはよくあるようです。

例えばですが、
・要望を機能要件として沢山伝えたのに、的外れな提案が出てきた
・コストも範囲もバラバラな提案で、選べない
・ただの会社紹介と機能一覧、サービス説明だけ。肝心の提案内容は？
・数が多すぎて、最後のほうは役員もまともに聞いてもらえない
といったものがあります。

私自身、過去に提案プレゼンをした中でも、結果的にコンペ自体が失敗していたという案件を何度か経験しています。

このようなコンペの失敗は、全て提案する側に問題があるのでしょうか？
いいえ、それだけではありません。依頼する側のRFPの作り方や伝え方に問題がある場合もあります。

RFPそのものの目的や、依頼内容に最適なRFPというものを理解したうえで作成すれば、このような失敗はある程度防げると思います。

キノトロープは、ありがたいことに年間数百を超えるオファーをいただきます。その多くが、Webサイトをリニューアルに関するものです。

オファーを分析してみると、ざっくりこの3パターンに分けられます。
・ほぼ何も書いてない（詳細は会って話す）
・とにかく細かく機能要求が書いてある（しかし提案側から見て大事なことは書いてない）
・その中間

具体的に説明します。
1パターン目「ほぼ何も書いてない」です。

こちらは、デザイン寄りの提案依頼やキャンペーンサイト、LPサイト作成依頼等で多い傾向にあります。

発注側の担当者は、日々の運用の中でスピーディーに依頼していることが多く、明確に書面化せずに口頭やメールでの依頼に頼った風土です。

「すぐにWord pressでキャンペーンサイトを立ち上げたい。詳しくは、会って説明します」といった具合に。

こちらが会いに行きたくなる要素は全くありません…。

この場合、依頼先を呼び出して口頭で説明しても、各社に伝える内容がブレたり、伝え忘れが起きたりします。また受け手の社内でも、口頭での伝言ゲームが起きやすいため、「伝えた（と思っていた）内容が反映されていない」といったことなります。

2つ目のパターン「とにかく細かく機能要求が書いてある、しかし大事な情報は書いてない」です。

これは、システム寄りの構築内容が主体だったり、RFPの作成にシステム部門が多く関わっていたり（システム部門の発注、システム部門がRFPを書いている、システム部門にRFPの書き方を聞いている）場合がほとんどです。

40、50ページ、時には100ページにおよぶ重厚な小説のごとく、分厚く機能要求が書かれています。

例えば利用する更新ツールやCMSについても指定されている、インフラや必要な機能・移行についても詳細に指定されていることも多いです。

しかし「このリニューアルで何を成し得たいのか？」等、本当に重要なことについては記述がない。もしくは伝わってこない。意外と多いのが、このパターンです

3つ目のパターンは、1つ目と2つ目の中間。「細かすぎず、粗すぎず」です。

重要なことも書いてあり、その上で提案に必要な情報が必要十分に記載されているパターンです。

我々はRFPをいただいてWebサイトリニューアル提案を行う側ですが、経験上、この3つ目のパターンが一番気持ちよく提案作業に入ることができます。

ポイントは、何をお願いするのかという依頼内容によって最適なRFPは変わるという事です。

規模小さめのキャンペーンサイトなど、短期間のスピード勝負やデザイン重視であれば、仰々しい要求資料は作らず、最低限の要件を1ページにまとめてスピーディーに依頼する形で十分です。（ただし、口頭での依頼はトラブルの元なのでやめましょう。）

要求した仕様通りに構築してもらいたいというシステム構築であれば、詳細な機能要件まで定義したRFPをつくることをおすすめします。

比較的規模の大きい、もしくは「コーポレートサイト全体」というような範囲の大きいWebサイトのリニューアルや構築の場合は、その中間という位置づけです。

システムも絡んでくるので、ある程度の要件や要望は細かく伝えなければならなりません。しかし言われた事だけ形にしてくるような提案にはなってほしくありません。サイト全体のリニューアルはそういう場合が多いと思います。

自社が何をお願いするためのRFPなのか、どのパターンに当てはまるのかが分かれば、作るべきRFPも見えてきます。

今まで話してきた内容を元に、RFPの役割を
定義してみます。
"RFPとは「良い提案をもらう」ために、必要な情報を正確に提供するもの"

・日々運用していく中での、サイトやシステムに対する不満
・腰の重い運用会社への不満
・社内外からのサイトに対する改善要望
・上司からのプレッシャー
それらを依頼内容として細かく指定したくなる気持ちは分かります。しかし、RFPは「提案依頼」書です。RFPを作ることが目的ではありません。

リニューアルプロジェクトがスムーズに進行し、あらかじめ定めた目標を一緒に叶えてくれる、導いてくれるパートナーを選定するためのものととらえれば、RFPで伝えるべき内容は至極シンプルになっていきます。

あなたがRFPに書こうとしている機能要件は、本来であればプロジェクトの中でプロフェッショナルである提案側と一緒に決めていくことがほとんどであるはずです。

そうでなければ、わざわざ「提案依頼書」として依頼する必要はありませんから。そうでなければ、提案依頼書ではなく「制作依頼書」です。

「提案依頼書」なのであれば、プロジェクトの「目的・目標」を明確に伝えることが重要であり、まず記載しなければならない内容です。

その目的目標を達成するために、どんな機能が必要か、どんなツールが必要か、どんなページにするべきかについては、プロフェッショナルである提案者に委ねるべきです。

最後までご覧いただきありがとうございました。

の３点についての内容でした。