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

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

＜初級編第5回＞
正しいRFPの書き方その3（発注者向け）
についてお伝えします。

担当は濱田です。

Webサイトリニューアルで、プロから最高の提案を引き出す最大のポイントは、RFP（提案依頼書）で「要件と要望を明確に分けること」です。

セキュリティ等の必須条件を「要件」とし、デザインやUIなどのプロの知見を活かしてほしい要素を「要望」として分けて伝えることが重要になります。社内の改善案をすべて「要件」にしてしまうと、制作会社は枠に囚われてしまい、プロのノウハウを十分に引き出せなくなってしまいます。

この記事では、RFPの精度を高める「現状データ8項目」から、トラブルを防ぐ契約条件、そしてRFPに盛り込むべき全5章の記載項目までを分かりやすく解説します。制作会社を単なる作業者ではなく、成功への「パートナー」にするための正しいRFPの書き方をぜひ参考にしてください。

” 正しいRFPの書き方”をテーマに、
今日お伝えしたいことは2つあります。

RFPをテーマに、以前の記事では「RFPの正しい書き方その2」としてお伝えしました。
まだご覧になっていない方は、是非初級編第4回、「RFPの正しい書き方その2」をご覧いただければ幸いです。

前回お伝えした「RFPの精度を高めるための現状データ8項目」について簡単におさらいしてみましょう。

１．サイト構成、コンテンツボリューム。
これはカテゴリごとのページ数を整理するということでした。

２．利用しているアプリケーション・ASPとその範囲。
CMSや問い合わせフォーム、サイト内検索などのツールを使っているか、どこに使われているかという内容でした。

３．現状の訪問者数他アクセス状況。
これはグーグルアナリティクスの閲覧権限をいただき、提案側で調べることが多いです

４．現状の編集者数、更新頻度、運用スタッフのスキルレベル。

５．実施されているSEO対策等、集客施策。

６．外注の有無と量、範囲、年間発注金額。
これらの費用を踏まえた費用対効果の提案を受けられる可能性があります

７．サーバ構成、インフラ環境
これは最新のデータを情報システム部等に依頼ください。

８．現在の公開までの業務フロー。
企画から公開までのフローを可視化しておいてくださいという事です。

このような現状データをそろえておくことで、よりスムーズなコンペ進行が可能になります。

それでは今回の内容にはいります。

Webサイトのリニューアルを行う場合、プロジェクト立ち上げの前段階で、社内の関係者に対し現状のWebサイトに関する不満や改善要望などをヒアリングしたり、アンケートを取ったりすることが多いです。

関係者と言っても普段からWebサイトの運用に関わっているメンバーだけではなく、運用にほとんど関わりのない営業担当など多数の部署や人を含めます

それ自体は、プロジェクト立ち上げの社内説得材料として必要な行為であることは理解できます。また、Web担当者として改善に対する強い想いがあるのも十分理解できます。

しかし問題は、そこで出てきた「要望」を、クリアしなければならない条件、すなわち「要件」としてRFPに記載してしまうことです。

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

初級編第2回の「RFPとは」で軽く説明しましたが、Webサイトリニューアルの場合、「要件」の多くは、プロジェクトの中で決めていくものです。

「どういったデザインにすべきか」「どのような機能が必要か」は、プロジェクトがスタートしてから検討や検証を重ねて決定することです

もし、指示した通りに制作してもらいたいのであれば、最初から「制作依頼」として伝えることをお勧めします。

その際は間違っても「御社の知見から、より良い提案があればお願いします」などと中途半端に提案を望む形にしないことです。

コンペを実施するような、比較的大きな規模のWebサイトリニューアルの場合、ただの「制作依頼」ではなく、共にプロジェクトを成功に導いてくれる「パートナー」を求めていることがほとんどです。

しかし、RFPに明確に「要件」と記載されていると、提案する側は多くの場合その要件に合わせた提案を行います。例えそれより良いと思われる提案があったとしても、です。

Webサイト制作に関するプロに対して、すべて「要件」として伝えるのではなく、クリアすべき条件である「要件」と「要望」を明確に分けて伝えられれば、さらに良い提案につながります。

要件
・リニューアルにあたり、クリアしなければならない条件
要望
・発注側からの参考意見（提案で考慮してもらいたい点。無視されても構わない）

要件と要望をこのように定義すると、いままで一括りに「要件」とされていた項目も、このように分けることができます。

「要件」の例
　・セキュリティ規定により、個人情報をクラウド上に配置するのはNG
　・プロジェクト対象外の他システムから連携している××機能については
　　移行後も継続させること
　・製品情報マスタと連携するためのAPIを構築すること
　・24時間365日の監視復旧を行うこと
「要望」の例
　・女性からのアクセスを意識したコンテンツを作ること　　
　・○○○（参考サイト）のような先進的なデザインにすること
　・当社の理念である「情熱」が伝わるようなデザインであること
　・デスクトップ、スマートフォン、タブレットそれぞれに最適なレイアウトを
　　実装すること

ご覧の通り、要件にあたるのはセキュリティ規定や連携など、システム面の内容であることが多いです。

一方、UIやデザイン、コンテンツなどは提案側からすると「要望」として捉えられることが多いです。社内ヒアリングやアンケートの結果はこういった要望が多く集まると思いますが、そこは割り切って「要望」として伝え、プロの意見や提案を求めましょう。

今まで3回にわたり説明してきたRFPの書き方ですが、最終的にRFPに記載する項目を整理していきます。
RFPの「提案依頼内容として記載すべき点」はこの通りです。