ポイントを理解したら、
手を動かしてRFPを実際に作ってみよう！
第2回 RFPを作る前に、絶対外せない3つのコツを確認しておこう
シリーズ第１回では、ウェブ担当者、アプリ担当者の方が「ウェブやアプリなどのライトな開発」でRFPを作成することの意義についてお伝えしました。
第２回では、第１回の終わりでふれた「RFP作成の心構えのコツ」について詳しく見ていきます。実際のRFPを作成する前に、そもそもRFPとは何なのか？他のドキュメントと比べてどんな特徴を持つのかについて整理することで、開発会社のポテンシャルを最大限引き出すことができるRFP作成が可能になります。
前回例にあげた下記の例を考えることから始めましょう。
システム構築に踏み込んだ要望がとても的確で、この文章を見たRFP開発会社の担当者も思わず「お、よく勉強されている担当さんだな、元エンジニアだろうか・・・」という感想が出てくると思います。
しかし結論から言いますとこれはRFPの段階では踏み込み過ぎなのです。
「仕様」を要求するやり取りではこの要望は満点に近いのですが、RFPとしてはこのリクエストはあまりよろしくありません。わかり易い言葉でいえば、この要望には、やはり「隙がなさすぎ」なのです。
こうした要望がRFPでいきなり出てくる背景としては、やはり「ウェブやアプリなどのライトな開発」向けのRFPの書き方の資料が極端に少ない事があるのでしょう。おそらく、このような要望を入れてきた担当者の方は「大規模システム向け開発」のRFPの書き方を参考に一生懸命作成されたのではないかと思われます。
「大規模システム向け開発」のRFPでは、RFPのやり取りの後、すぐにユーザーからの要望を吸い上げる「要求定義」と、開発サイドからの回答である「要件定義」「仕様」を明確にします。このため「ここが困っているから提案して欲しい」というものよりももっと、「要求定義」に近いものが期待されるという事情があります。
「ウェブやアプリなどのライトな開発」では、前提となる開発条件（この例ではmBaaS）も、各社によって提案が異なってきますので、最初から「ｍBaaS」として間口を狭めてしまうと、せっかくの開発会社の斬新で多彩な提案が集まらなくなります。
「ウェブやアプリなどのライトな開発」のためのRFP作りでつぎに注意すべき点は、RFPが「企画書」になってしまわないように注意しておくことです。
企画書づくりは、ウェブ担当者、アプリ担当者の方にとって普段やり慣れている得意分野の領域だと思います。「分かりやすく、全体を俯瞰した企画書づくりなら誰にも負けない！」というプライドをもった担当者の方が仕上げる企画書は確かにすばらしい出来栄えであると納得することがしばしばです。
でも、ここでも同じ問題が起こります。つまり「企画書」として完璧であるとRFPとしては隙がなさすぎで、開発会社からの斬新で多彩な提案の余地がないのです。
企画書とはいわば、システム開発の中身を含めた総合的な戦略ドキュメント、作戦指令書です。敵地を攻めるための作戦指令書にはいつまでにどこを攻略するかだけでなく、「用意するべき武器」や「補給物資」などの裏付けが必要です。
この「用意するべき武器」や「補給物資」については、やはり専門家の意見を集約して実現可能な、最適な戦略を組み立てるべきです。
しかし、開発会社では、ウェブ担当者、アプリ担当者の方が作成するRFPが完璧な企画書レベルになっていると、この「用意するべき武器」（ウェブサイトやアプリ）や「補給物資」（メンテナンス、チューニングなど）の提案がしにくいという面があるのです。
開発サイドのポテンシャルを引き出す効果的なRFPの作り方の最後のポイントは、RFPが「計画書」にならないように注意することです。
もちろん、プロジェクトをGOさせるためには最終的に開発サイドとはっきりした「計画書」を共有することが必須となってきます。
しかし、これについてもガチガチの「計画書」の雛形を作って「こんなスケジュールを想定しているが、大丈夫かどうか、回答ください」的なRFPにしてしまうと、隙がなさすぎて開発会社からの斬新で多彩な提案が出てきません。
「え？アイディアレベルの話なら分かるけど、開発計画に斬新とか、多彩とかあるんですか？」というウェブ担当者、アプリ担当者の方の声が聞こえてきそうですが、実はあるのです。しかも、これはとても重要なトピックスなのです。
例えば、現在「ウェブやアプリなどのライトな開発」では、アジャイル開発という手法が主流になってきています。「アジャイル開発」を簡単に説明すると下記のようなプロセスをたどりながら、製品完成度を高めていきます。
1．発注側と開発側が少数精鋭のプロジェクトチームです。
2．プロジェクトチームは開発範囲全体をだいたい2週間程度で出来る範囲に設定します。
3．プロジェクトの優先度を考慮し、どの範囲から着手するかを決定します。
4．プロジェクトチームは2週間というは期間内に、その範囲の要求の決定、実装、テスト、修正、リリースを行います。
5．リリースできた機能や残っているプロジェクトの範囲を検討し、次に着手する優先すべき範囲を決めます。
6．上記の2から5のサイクルを繰り返して開発を進め、全体の完成度を高めていきます。
このアジャイル開発のポイントは、少々乱暴に言うと「計画があってないようなもの」というところにあります。
第１回でも解説したように、「ウェブやアプリなどのライトな開発」では、ウェブサイトやアプリのリリースの後、継続してパートナーシップを気づいていいける会社がとても重要になってきます。
社内向けの「大規模システム向け開発」ではなく、BtoC型の製品では素早い市場の変化やユーザーの嗜好の変化に合わせて、柔軟にプロジェクトの優先順位を変えていくことが大切です。そして、ひとつ完成した納品物はそれで完結ではなく、次の課題解決へのたたき台として先に進んでいくことが重要です。
最初から「できるできない」を要求するようなガチガチの計画書をリクエストしてしまうと、こうしたアジャイル的な関わり方を拒否してしまうことにもなりかねません。
もくじ