オルタナティブ・ブログ > プロジェクトマネジメント10.0 >

失敗しないウェブアプリケーション開発の処方箋

【RFP】世界一簡単な提案依頼

»

先日のエントリ「【RFP】 これがループスの”提案依頼書 雛形”です」では、
ループスが普段利用しているRFPの雛形を紹介させていただきました。

今回は、なぜループスが提案を依頼する際に雛形を使っているかを紹介させてください。

◆適当に提案依頼をするとロクなことがない

これがループスが提案依頼書の雛形を作って
その中身にこだわっている理由です。

提案依頼は適当に済ませられないのでしょうか。
説明するため、まずは世界一簡単な提案依頼を紹介します。

◆世界一簡単な提案依頼

一番簡単な提案依頼書は以下のようなものです。

会社のお金が3,000万円余っています。どう使ったらいいか提案してください。

上記の文章を見込みのありそうな会社数社に投げ込むと、
恐らく営業さんが提案を持ってきてくれます。
費用対効果で考えると悪くない提案依頼かもしれません。

◆悪くない?じゃあいいじゃないか。俺は1行ですます。

ちょっと待ってください、この提案依頼から得られる結果には問題が2つあります。

  1. 受け取る提案は、依頼した側固有の事情をあまり考慮しないものになる
  2. 気合の入った提案は多分来ない

(1)は事情を説明していないので当然です。
システム開発の提案がくるかも知れませんし、金融商品の提案がくるかも知れませんし、
不動産の紹介がくるかも知れません。

依頼した理由を満たせない提案を「的外れな提案」と言いますが、
的外れな提案は多くの場合「提案依頼内容がうまく伝わっていない」ためにできあがります。

こういう仕事は提案を依頼する方にとっても、提案する方にとっても時間の無駄なので
なんとか減らしたいですよね。

(2)は提案を依頼する側の問題です。
前述の通りこの提案依頼から「的を射た提案」を作るのは難しいです。
的を射た提案でなければビジネスには結びつかないと思います。

ビジネスに結び付かない仕事には多くのコストをかけてもらえません。

提案する側がコストをかける気にならない場合、
大抵、既存の製品説明資料やサービス案内が届きます。
これで満足できるなら最初からWEBで検索した方が早いです。

◆「世界一」に足りないもの

ここまでで、提案依頼書を頑張って作る大きな理由が少なくとも2点は明らかです。
ループスで作る依頼書は、以下の点についてより高い結果を得られるよう考慮しています。

  1. 依頼する側の事情や要求を明確にし、作成される提案がより的を射たものになるよう促す
  2. 提案する側のモチベーションを刺激し、ポテンシャルを引き出す

その為に、提案依頼書の作成にあたっては以下の3点を抑えるようにしています。

1.何を提案して欲しいのか明確にする

的を射た提案を得るために必要です。

例えば・・・、
私はだれなのか、普段は何をしていて、提案を依頼する目的は何なのか。
提案して欲しいのはモノか、システムか、企画か、それともビジネスモデルか、生き方か。

2.前提条件は何か

的を射た提案を得るために必要です。

例えば・・・、
どんな提案は評価し、どんな提案は却下するか。
組織にマッチするものは何か、しないものは何か。
予算はどれくらいか、どんな法令を遵守する必要があるのか、どんな性能を期待するか。

3.なぜあなたは提案書を作る必要があるのか

提案を唯一無二のソリューションに昇華するため、
提案依頼をする担当の方に強烈なモチベーションを持っていただくことは意外と重要です。

金銭をはじめとした報酬を明示することはもちろんですが、
提案する側の労力に敬意を払い、共に問題を解決していくパートナーとして接するように心がけています。

◆なぜループスが提案を依頼する際に雛形を使っているか

「的を射た提案を得るため」に必要な提案依頼の「観点」を統一的に管理できるからです。

WEBアプリケーションを開発する際に検討しなければならない事項はある程度決まっていますが、
気の使い方は個々人でかなりの差があると感じています。

ある人は企画の鋭さに関心があり、ある人はリスクに関心があり、ある人は運営方法に関心がある。

業務の標準化をする時はいつでもそうですが、観点が俗人的にならないよう
このような雛形を作成し、管理しています。

【RFP】 これがループスの”提案依頼書 雛形”です」で紹介した提案依頼書の雛形は、
中身自体はすかすかですが、観点としてはある程度整理されているのではないかと思います。

今後機会があれば(ブログのネタがない時にでも)中身について
紹介させていただく機会があるかもしれませんが、
まずは「ループスではこういう観点で提案を評価してるのだな」程度の
参考にしていただければと思います。

※逆に、自分達が作るものは「非機能要件定義書」という形で観点を整理しています。
 こちらも機会があればご紹介させて頂きたいと思います。

Comment(0)