ポイントを理解したら、
手を動かしてRFPを実際に作ってみよう！
第1回 RFPはアプリ・WEB開発プロジェクトでも大活躍！
最近RFPという言葉を耳にすることが多くなったと感じているウェブ担当者、アプリ担当者の方が多くなったようです。このコラムをお読みいただいている方の中にも、下記のようなやり取りを会社で聞いたことがある方もいらっしゃるかも知れません。
「来週頭までにRFP仕上げておかないと、外注先選定始められないよ！」とか「RFP作成ミーティングを行いますので、関係者は会議室に集合してください！」とか、若手の担当者が「RFP＝ Request For Proposal」（提案依頼書）という言葉をおしゃれなオフィスで普通に使っています。
こうした光景は、以前はあまり想像できませんでした。というのもRFPはもっと地味で大規模な「業務システム」や「情報系システム」などのようなシステム開発の部門で、きちんとした仕様書を間違いなく出してもらうために作成されることが多かったからです。
こうした背景がありますので、ウェブ担当者、アプリ担当者の方がきちんとしたRFPを作成しようと思ってネットで資料を探しても定番の情報がなかなか見つかりません。
「RFPの書き方」や「RFPの雛形」はまだまだ「大規模システム向け開発」のものが多く、「ウェブやアプリなどのライトな開発」のために参考になる情報があまりないのが現状です。
当社でもお客様からRFPをいただくことが多いのですが、中には「大規模システム向け開発」のRFP資料を参考にして相当苦労しながら作成されたのでは？と思えるものもございます。
「ウェブやアプリなどのライトな開発」のためのRFPでは、現状分析、工期や機能のご要望に関して「大規模システム向け開発」のRFPほどの正確さや厳密さがいらない部分もあります。そして、逆に「大規模システム向け開発」ではあまり考慮しなくても良い「ターゲットとするペルソナ」や「意識している競合情報」などが重要になってきます。
「大規模システム向け開発」は社内の業務システムや、情報システムを構築することが主目的なため、現状の業務フローの分析やシステムが稼働できる時期、一度作ったら数年、もしくは十年以上も使えるような機能の洗い出しなどが重視されるわけです。
一方で「ウェブやアプリなどのライトな開発」のためのRFPでは、社内システムではなくBtoCの開かれたシステムであることが基本です。例えばウェブサイトは会社の外に向かって情報を発信するために公開されるものですし、業務アプリなどの極小数なケースを除けば、大部分のアプリは他社との差別化に成功した人気アプリであることが求められるのです。
RFPを作成する目的は、開発者に「作って欲しいシステムの提案」を依頼することにあります。口頭で「こんなの欲しいです」と伝えるのではなく、きちんと文書にして依頼することで、下記のようなメリットを享受することができます。
「ウェブやアプリなどのライトな開発」では、システムを作ってプロジェクトが終わりというケースはまれです。サービスを公開した後のプロモーションや、サービスを活かすためのマーケティングなど様々な部署が納品物に関わってきます。
このため、プロジェクトの全体像の認識やスケジュール感、優先順位などについて各部署の意見を十分集約しておく必要があり、これは外部向けにRFPを作成することで自然と達成することが可能になります。
「大規模システム向け開発」のシステム開発では、実は提案の内容に大きな開きはあまりありません。工期や金額で「え？すごいな。こんなの可能なの？」という驚きはたまにあっても、地味なシステム開発で提案内容そのものに驚かされるということはほとんどないのです。
しかし、「ウェブやアプリなどのライトな開発」では、RFPさえしっかりしていれば、発注側が考えもしなかったようなウェブやアプリの特性を活かした斬新な提案をしてくれる業者がいくつもでてきます。
「ウェブやアプリなどのライトな開発」では、ひとつの発注物を納品してもらったら関係が切れる、ということはあまりありません。「こんなひどい開発会社とは早く縁を切りたい！」という不幸なケースは別として、たいていの場合はリリース後に明らかになってくる課題点を再び一緒に解決するパートナーとしておつきあいをしていくことが普通です。
例えば、ウェブサイトであれば思った以上にアクセス数が伸びない、アクセス数は確保できているがコンバージョンに結びついていない、などの現状をどう改善していくかなどの悩みについて、RFPの段階からコミットメントしてくれている開発会社は最も信頼のできる相談相手となってくるでしょう。
また、アプリをリリースした後もユーザーの要望に合わせて細かく機能や内容を改善していくことは当たり前になってきていますが、そうしたアプリのチューニングをまったく別の会社にイチから説明して発注するというのは考えただけでも大変な作業だとわかります。これも、納品してくれた会社が責任を持って納品後も面倒を見てくれる体制が理想です。
納品後のメンテナンスや、「予算」「時間」「体制」などで第１回目の納品で果たせなかった持ち越しの課題を、将来的にどう解決していくかなどについて、発注側のRFPに十分に答えてくれている開発会社であれば、こうした面でも心配はありません。
いきなり相見積もりを取って値段の安そうな業者に発注する、というRFPを飛ばした発注形態では、このような開発会社との関係を探る方法がそもそもなにもないわけですね。
ここまでで、「ウェブやアプリなどのライトな開発」でRFPを作成することの意義がお分かりいただけたと思います。
次回以降、RFPを書くときの心構えについて必要なポイントを解説いたしますが、いちばん大切なことはRFPとはあくまでも「提案を依頼」する文書だということなのです。
「そんなの当たり前じゃないか、分かってるよ」という声が聞こえてきそうですが、以外にもこの「提案を依頼」する文書だという意味を理解して作成されたRFPはそれほど多くないのです。
もっともこれは、「RFPとして必要なことが書いていないので、何をフィードバックしてよいのかわからない」ということではありません。
むしろその逆で、多くのウェブ担当者やアプリ担当者の方は、RFPを精緻に組み立てようとしすぎて、開発会社からの自由な提案をしばってしまっている、という場合があるのです。
例えば、ストレートに「ゲームのハイスコアをユーザーに知らせるのに良い解決方法を提案して欲しい」とRFPに書いてくれれば、開発会社からは「こういう解決方法と、こういう解決方法があって、それぞれのポイントはこうです」という回答がさくっと可能になるのです。
ところが、発注担当者の方がシステム系にかなり詳しくて、「ゲームアプリのハイスコア管理からランキングを自動的に集計し、ユーザーにプッシュ通信する時にユーザーの属性に合わせてターゲティングしたいのだが、mBaaSを使ったシステムのフロー図を出して欲しい」というリクエストがあったらどうでしょうか。
もちろん、開発会社はプロですので完璧なフィードバックは可能です。しかし、そもそも大手mBaaSサービスが苦戦する中mBaaSを使ってプッシュ通信をすることが、将来的に良いのかどうかは、判断が難しいところです。
せっかくつくったmBaaSベースのシステムが、mBaaSサービスの提供終了ですべて無駄に終わるというケースもありえます。
RFPの段階では、「ゲームのハイスコアをユーザーに知らせるのに良い解決方法を提案して欲しい」と書くにとどめておき、開発会社からmBaaSを含めた複数の提案を吸い上げるのが、賢いRFP作成のコツなのです。
いわば、隙を見せながら開発会社のポテンシャルを引き出すわけですね。
次回は、こうしたRFP作成の心構えのコツについて解説いたします。
もくじ