ポイントを理解したら、
手を動かしてRFPを実際に作ってみよう！
第3回 RFPの書き方3つのポイントとは？こうすれば必ずやりたいことが伝わる！
ここまで、ウェブ担当者、アプリ担当者の方向けに「ウェブやアプリなどのライトな開発」のためのRFP作成の意義や、基本的な心構えについて解説してきました。
今回からは、いよいよ実際に「ウェブやアプリなどのライトな開発」のためのRFP作成の方法について解説していきます。
「ウェブやアプリなどのライトな開発」のためのRFP作成では、最初から「仕様書」「企画書」「計画書」などに直結するような間口を狭めたリクエストを出すのではなく、ある程度の「隙」をあえて見せることで、開発会社からの斬新で多彩な提案が可能になります。
しかし、だからといって丸投げ的に「良い提案ください」という接し方をしても、今度は「隙」がありすぎて、開発会社ではどんな提案をして良いのか途方にくれてしまいます。
それでは、「隙」を見せつつも、「必要最小限の的確なポイント」をおさえたRFPの書き方の3つのポイントを具体的に見ていきましょう。
RFPでは、まずこのプロジェクトで何を達成したいのかを開発会社に明確に伝えます。具体的には、下記の項目について、過不足なく伝えることが大事です。
プロジェクト開発に至った背景を説明します。
例えばわかりやすいのは、リニューアルやバージョンアップ系の依頼です。現在のホームページを時代に合わせて改良したいとか、現在リリースしているスマートフォンアプリをユーザーのリクエストに答えてバージョンアップしたい、などの場合にはプロジェクトの背景がはっきりしています。
また、新規の場合であっても「現在こういうことで困っているのでウェブで解決したい」「現在ウェエブサイトだけが集客窓口になっているので、スマホアプリからも集客をしたい」などの課題を解決するために必要である、などの説明の仕方は分かりやすく相手に伝わります。
売上向上や、顧客の囲い込み、アプリによるマネタイズなど、製品を作ってもらった後にどんな効果をねらっているかを伝えます。
「単に制作物を納品してもらって終わり」ということでなく、本来こういう目的のためにウェブサイトやアプリが必要なのだ、ということを伝えることによって、単に見栄えの良いホームページ、最新機能を付けただけのスマートフォンアプリなどのが納品されてしまうことを防ぎます。
「いついつまでに納品してください」ということだけでなく、運用の開始や、集客の目標、コンバージョンの目標などの時期についてもできる限り伝えましょう。
例えば、スマホアプリのリリース自体が最終目標となっていると、開発会社も納品して終わり、という意識で仕事をしてしまうことになります。アプリをリリースした後、3ヶ月後にダウンロード数1万を目指す、ということを伝えることによって、提案内容も変わってくるはずです。
「大規模システム向け開発」ではペルソナなどは考慮しなくてもプロジェクトは成功に導くことができます。しかし、「ウェブやアプリなどのライトな開発」ではRFPの段階で、想定しているペルソナをきちんと伝えることで、プロジェクトの出口、方向性を明確に共有することが可能になります。
これも「ウェブやアプリなどのライトな開発」では非常に重要になってきます。具体的に競合と想定されるウェブサイトのURLを複数提示して、どんな点で差別化したいかということを伝えたり、想定される競合アプリを具体的に提示して、どんなところで勝負したいかを伝えるなどすると、開発側でもイメージが湧いてきます。開発会社では同業他社のホームページやスマホアプリを開発したことがある、という場合も多いはずなので、そうした実績をもとに発注側が思っても見なかった斬新な提案を引き出せることもあります。
RFPでは、このプロジェクトで具体的に何がしたいのか開発会社に明確に伝えます。具体的には、下記の項目について、過不足なく伝えることが大事です。
ウェブサイトの制作やアプリの開発にあたって、発注側で整備すべき資料や既存システムの稼働状況などについて用意できるものを提示した上で、各種役割分担の提案をお願いします。
機能として入れ欲しい用件については、まずは発注側からボールを投げることが大切です。社内でのブレストでもよいですし、同業他社のホームページやスマホアプリなどを参考に、自社で必要な機能を洗い出して提示しましょう。
初期費用にかけられる予算と、バージョンアップや集客施策など納品後にかけられる予算については、分けて提示した方が、現実的で段階的な提案を受けられます。
例えば、せっかく作ったホームページやスマホアプリを誰も見に来てくれない、使ってくれないという状態では初期費用をかけた費用が無駄になってしまいます。
初期費用と段階的な予算を提示することによって、開発会社が長期に渡ってどのような関わりを自社に提案してくれるのか、各社の提案に期待が持てます。
開発手法の提案、というと開発会社が決めるものだ、という思い込みがあるかもしれませんが、実はそうではありません。もちとん、プログラミングレベルやデザインの現場レベルに発注側があれこれ口を出すということはありませんが、一度設計をしたら一気に納品まで開発側で行う「ウォーターフォール型開発」にしたいのか、途中で発注側も含めて小さな完成形を繰り返しテストしながらリリースして、プロジェクトの優先順位を途中途中で変更していく「アジャイル型」にしたいのか、については発注側から希望を出しておくとよいでしょう。
開発会社によっては「アジャイル型は経験がありません」という回答をもらうこともありますが、初期のRFPの段階でそれがわかると、お互いに無駄なやり取りをしなくて良いというメリットがあります。
こちらから割ける人員と、人員の部署などについて提示し、開発側からの人員と担当内容についても提案してもらいます。とくに「アジャイル型開発」を希望した場合には、担当窓口を通じて遣り取りをするだけでなく、発注側と開発側から人員を出し合ってプロジェクトチームを組むことになりますので、この提案はとても重要になってきます。
RFPでは、各社に共通のドキュメントを提出してもらうことで最終的な依頼先選定作業を迅速・的確に行うことができます。具体的には、下記のドキュメントについて提出を促します。
このドキュメントの具体的言葉をご覧いただけるとお分かりになると思いますが、この段階で初めて開発側から提示されるのが「設計書」や「計画書」なのです。
ホームページ制作や、スマホアプリ制作は予算がけっこう大きいこともあり、「最初から厳密な計画を提示して間違いのないように発注しなければならない・・・」と思い込んでしまう担当者の方も多いのですが、RFPの段階では、発注者側からの「計画書」「設計書」はいりません。
そして、開発側からのこうしたドキュメントの提示を受け、それも踏まえて実現可能な「企画書」を作るというのが、RFPをきっかけとしたキャッチボールの次にやるべきことなのです。
以上、RFPで書くべき内容について概略をお伝えしました。次回から3回に分けて具体的にRFPをどう書いていくかについてウェブサイトリニューアルを題材にみていきます。
もくじ