ベンダーから「より良い提案書」を出して貰うために〜正しいRFPの出し方

皆さん、「RFP」と言うドキュメントを作成した事はありますか ?

「RFP」とは、「Request For Proposal」の略で、日本語に訳すと「情報提供依頼書」、あるいは「提案依頼書」となります。

それで、何をするためのドキュメントなの ? となるかと思いますが・・・

例えば、何らかの業務を効率化するために、該当業務をシステム化しようとした時に、自社でシステムを作成できない場合には、私共のような、外部のソフトウェア開発会社(以下、ベンダー)にシステム作成を依頼する事になると思います。

その時に、ベンダーに提出するのが「RFP」となります。「RFP」の内容としては、上図の様に、システムを作成する上で必要となる数々の情報となります。

そして、「RFP」を受け取ったベンダーは、「RFP」の内容を参考にしながら「提案書」を作成することになります。

つまり、システムを作成するベンダーに対して、「提案書を出して下さい」と依頼するのが「RFP」と言う事になります。

要件概要の作成から「RFP」の作成、ベンダーからの提案書の提出、および契約までの流れを図にすると、下図のようになります。

「RFP」は、通常、複数のベンダーに提出します。そして、ベンダーから提出された複数の提案書を検討し、さらにベンダーの絞り込みを行うか、あるいはシステム開発を依頼するベンダーを決定します。

「RFP」を出すベンダーは何社でも構わないのですが、その後、ベンダーから提出される提案書を検討する必要があります。余りにも多くのベンダーに「RFP」を出してしまうと、検討作業が大変な事になってしまいますので、3〜5社位が妥当な数だと思います。

これで、発注先ベンダーが決まって開発作業が始まれば、後は、開発作業の進捗管理を行うだけ、と話がトントン拍子で進めば良いのですが・・・

貴方の作成した「RFP」の出来栄えが優れており、かつベンダーも優秀で、貴方の希望を全て理解しており、さらに予算も希望金額の範囲内に収まって・・・等と言うことは、まず有り得ません。

システム開発の検討を開始してから、「RFP」の発行、および発注先ベンダーの決定までの間では、通常、次のような問題が発生します。

●RFPが作成できない
●ベンダーの提案書が的外れ/ピント外れ
●提案書の内容が薄い
●全然関係ないパッケージの導入を勧められる
●内容が薄いのに「全て対応可能」と言う提案書ばかり
●予算オーバー
●納期オーバー・・・・・等

これらの問題の内、最後の2個は、今回のブログの主題としている「RFP」や「提案書」の内容とはかけ離れていますので、この2点に関しては割愛します。

それにしても、「RFP」の発行から発注先ベンダー決定までの間には、数々の問題が発生します。

今回のブログでは、【ベンダーから「より良い提案書」を出して貰うために〜正しいRFPの出し方】と題して、「RFP」の発行から発注先ベンダー決定までの間に起こる問題点とその解決策をご紹介したいと思います。

また、「おまけ」として、RFP、および提案書の精度向上に関して、次の2つの方法を紹介したいと思います。

●RFP精度向上方法
●提案書精度向上方法

それでは今回も宜しくお願いします。

- - - - -

■RFPが作成できない

●現象
・RFPを作成した事がない
・要件概要を整理できない
・何を、どのように書けば良いのか解らない

●原因
・発注元の経験不足
・発注元のスキル不足

●解決策
これまでシステム開発に関わった事が無い人は、要件概要やRFPの作成は、確かに難しいと思われるかもしれません。

しかし、これまで要件概要/RFPを作成した事が無い人でも、ツボさえ抑えておけば大丈夫です。

【ツボ】
・開発の背景を説明する：何故、システム開発を行う必要があるのかを説明する
・問題点を明確にする：どのような業務で、何が問題になっているのかを説明する
・期待する改善方法を説明する：問題点を、どのように改善したいのかを説明する
・懸案事項を説明する：改善方法に問題/懸案事項があれば、その内容を説明する
・希望納品物を説明する：どのような成果物を納品して欲しいのかを説明する
・希望納品時期を説明する：何時までに納品して欲しいのかを説明する
・保守に関する希望を説明する：納品後、保守サービスが必要か否かを説明する
・データ移行について説明する：本番業務を開始する上で移行作業が必要か否かについて説明する

上記の【ツボ】に関して、出来れば、と言うか、必ず全てを記載して下さい。説明する必要が無い物もあると思いますが、その時には、「章」だけは設けて、中身は「不要」でも良いと思います。

そして、説明をする必要がある項目に関しては、出来る限り、そして思いつく限りの説明を記載して下さい。

但し、自己満足の説明では、相手に、貴方の真意や熱意が伝わりません。貴方の真意・熱意は、ドキュメント内容を通して相手に伝わります。

貴方が作成したRFPが「冷めたRFP」であれば、ベンダーから提出される提案書の内容も、きっと「冷めた提案書」になると思います。

また、説明すべき内容があれば、「5W1H」を基本に、説明を記載して下さい。分かり易い文章の基本は「5W1H」です。

【 5W1H 】
Who ：誰が
What ：何を
Where ：何処で
When ：何時までに
Why ：何故
How ：どのようにして

■提案書の内容が的外れ/ピント外れ

●現象

【的外れ】
・RFPの内容と提案書の内容が全く一致しない
・主要機能を誤解しているので、付随する機能も全て見直しが必要
・提案書の全面的な書き換えが必要

【ピント外れ】
・RFPを理解しているが焦点を当てる箇所を間違えている
・一部機能の説明が間違えている
・部分的な修正で対応可能

●原因
・RFPの内容が薄い
・発注元とベンダーのコミュニケーション不足
・ベンダー技術者の力量不足
・ベンダーが意図的に焦点をずらしている
・ベンダーの小会社が提案書を作成している
・ベンダーの部門間のコミュニケーション不足

●解決策
提案内容が、「ピント外れ」だったり、あるいは「的外れ」だった場合、まず疑うべきは、RFPの記載内容の正確性、および記載内容の粒度だと思われます。

基本的に、提案書の正確性や粒度は、RFPの正確性と粒度に比例します。

RFPの記載内容が曖昧な場合、当然、ベンダーから提出される提案書も曖昧になりますし、RFPの記載内容の密度が粗い場合、提案書の密度も粗くなります。

RFPの記載内容が、そこそこ「まとも」であるにも関わらず、提案内容が「ピント外れ」だったり、あるいは「的外れ」だった場合には、発注元とベンダーとの間の、コミュニケーション不足が考えられます。

通常、ベンダーが提案書を作成する前には、RFPの内容に関して、発注元とベンダーとの間で、質疑応答が行われます。

この質疑応答で、核心に迫ることができれば、提案書の内容も、核心を突いた内容になりますし、上辺だけの質疑応答の場合、提案書の内容も、当たり障りない物になります。

また、発注元とベンダーの窓口とは、そこそこ熱いやり取りが出来たとしても、ベンダー内部でコミュニケーション不足が発生する可能性もあります。

例えば、ベンダーの窓口は営業で、実際に提案書を作成するのは、開発側の人間だったり、あるいはベンダーの小会社やパートナーだったりする場合、どうしても窓口と担当者との間は【伝言ゲーム】になってしまいます。

【伝言ゲーム】を避けるためには、直接、担当者とコミュニケーションを取るか、あるいはコミュニケーションの結果をドキュメントとして残す方法があります。

一番悲しいのは、ベンダーに提案書を作成するだけのスキルが無いケースです。

提案書が作成出来なければ、もう、どうしようもありません。そのような低スキルのベンダーに、RFPを出した貴方に、相手を見る目が無かったと言う事になってしまいます。

また、酷いケースとしては、ベンダーが、「何らかの意図を持って」、故意に、的外れな提案書を作成しているケースもあります。

例えば、後述する別項目でも触れますが、ベンダーが自社パッケージ・ソフトウェアを導入したいがために、故意に焦点をボカした提案書を作成するケースがあります。

詐欺みたいな話ですが、IT業界では、良く見かける話です。このような提案書には気を付ける必要があります。

■提案書の内容が薄い

●現象
・提案書の項目が少ない(章立てが少ない)
・項目(章立て)は揃っているが、各項目の記載内容が少なすぎる
・言葉使いが漠然とし過ぎている
・表現が曖昧
・何が言いたいのか解らない

●原因
・RFPの内容が薄い
・発注元とベンダーのコミュニケーション不足
・ベンダー技術者の力量不足
・ベンダーが、過去に作成した提案書の使い回しを行っている
・ベンダーへの思いやりが掛けている

●解決策
提案書の内容が「薄い」場合も、前述と同様、次の点を疑って見るべきだと思います。

(1)RFP記載内容の正確性、および記載内容の粒度
(2)提案書作成前の質疑応答の頻度、および粒度
(3)ベンダーのスキル

また、全てのベンダーに当てはまる訳でありませんが、過去に、他のお客様に提出した提案書を、宛名情報だけを変更して、そのまま提出する、とんでもないベンダーも存在します。

「そんなベンダーって存在するの ?!」と思う方も居ると思いますが・・・この様な、非常識なベンダーは、確かに存在します。

弊社を含め、ほとんどのベンダーでは、「提案書の雛形」を用意しておき、発注元からのRFPの内容に従い、雛形を修正する形で提案書を作成しています。

お客様毎に、最初から提案書を作成する方法は、一見、親切に思えるかもしれませんが、作業効率が悪く、提案書をお客様に提出するまでに余計な時間が掛かるので、この方法を採用するベンダーは存在しないと思います。

また、雛形と言っても、目次を準備しておくだけですから、記載する内容は、お客様毎に異なります。

しかし、前述の「提案書の使い回し」を行うベンダーは、提案書の内容を故意に薄くすることで、どの様なお客様に対しても融通がきく「万能型の提案書」を使います。

故に、このベンダーからの提案書は、内容が薄っぺらになり、ベンダーの熱意が全く感じられない提案書になってしまいます。

記載内容が「薄っぺら」の提案書を作成したベンダーに関しては、システム開発を発注しても、担当者に、仕事に対する熱意が欠落しているので、良いシステムが出来上がるとは思えません。

故に、このように熱意が感じられないベンダーに関しては、後々の事を考えると、システム発注先企業の選定対象から除外した方が良いと思います。

一方で、ベンダー側としても、仕事なので一生懸命「提案書」を作成しますが、人間ですので、次のような発注元に対しては、提案書を作成する熱意が薄らぎます。

・単純に「見積り金額」だけでベンダーを決定してしまう非常にドライ(冷淡)な発注元
・ベンダーに対して見下した態度を取る発注元
・自分勝手な事ばかり言う発注元(例：仕様変更頻発、機能変更頻発、等)
・提案書を出すまでは何度も催促して来るが、提案書を出すと何も連絡して来ない発注元

私達ベンダーも、仕事が欲しいので、必死に提案書を作成しますが、それでも上記の様な発注元からの依頼に関しては、仕事に対する熱意が薄れると共に、提案書の内容も薄れてしまいます。

発注元が、ベンダーの「やる気」を削ぐような態度を取れば、得られる提案書の質は確実に低下します。

発注元とベンダーが相互に協力しなければ、プロジェクトの成功は望めません。お互いに相手を尊重し、提案プロセスから良好な関係を築き、それを維持していくことが大切になります。

■全然関係ないパッケージの導入を勧められる

●現象
・RFPに記載した要求事項に合致しないパッケージ・ソフトウェアを提案された
・一部機能のみが合致するパッケージ・ソフトウェアを無理やり勧められた

●原因
・ベンダーが、該当パッケージ・ソフトウェアの開発・販売している
・ベンダーが、該当パッケージ・ソフトウェアの販売代理店になっている

●解決策
本ケースに関しては、前述の通り、ベンダーが、自社が販売しているパッケージ・ソフトウェアを導入してもらうために、的外れな提案書を作成するケースです。私が、お客様から伺った、具体的な例を紹介します。

あるベンダーは、自社でERP(Enterprise Resource Planning)系のパッケージ・ソフトウェアを取り扱っていました。

このベンダーに、在庫管理業務の効率化のためのRFPを出した所、在庫管理業務とは余り関係のない、生産管理や人事管理、それに給与管理までを含んだERP製品の提案書を提出して来ました。

在庫管理システムだけであれば100万円程度の予算で済む案件が、数千万円規模まで膨らんでいたそうです。

このベンダーの場合、自社製品に、たまたま在庫管理機能があるのを良いことに、本来は関係無い機能までも含んだ、いわゆる「ソリューション提案」と言う形で、余計な機能までも提案していました。

発注先企業が、当初から「ソリューション型提案」を望んでいるのであれば、このベンダーからの提案書は、それなりに助かる物だと思います。

しかし、単純に、「在庫管理システム」だけを必要とする発注先企業にとっては、このようなソリューション型提案は、迷惑この上ない提案書になります。

ベンダーにとっては、100万円程度のシステムが、数千万円規模のシステムまで膨らむので、受注できれば「儲け物」の案件になりますが、発注先企業にとっては、将に「詐欺」みたいな話になってしまいます。

結局、このお客様は、該当ベンダーからの提案書は破棄して、弊社に開発を依頼されました。

上記例のように、自社パッケージ・ソフトウェアを持っているベンダーや、他社パッケージ・ソフトウェアの販売代理店になっているベンダーが、パッケージ・ソフトウェア、つまりプロダクト(製品)を全面に押し出す営業スタイルを、「プロダクト・アウト」と呼んでいます。

「プロダクト・アウト」の営業スタイルは、顧客や市場のニーズを理解せず、自社の意向や技術を重視して製品やサービスを開発する傾向が強く、顧客や市場のニーズを重視する「マーケット・イン」と呼ばれる営業スタイルの対極とされています。

このため、「プロダクト・アウト」の営業スタイルを取るベンダーの提案書は、自社製品の強みや、自社製品と競合製品との機能比較ばかりで、お客様がRFPで依頼した内容とは、全然関係の無い事ばかりになります。

また、前述の通り、自社製品が提供する機能の説明ばかりなので、本当に必要な機能の説明は、ごく一部の機能の説明だけになってしまいます。

このような「プロダクト・アウト」の提案書を防止するためには、RFPの中、あるいは表紙に、パッケージ・ソフトウェアに関する機能説明だけを列挙した提案書は、評価対象から除外する旨を明記するしかありません。例えば、

【提案書提出時の注意点】
本RFPに基づいて提案書を提出して頂く場合には、次の点をご注意下さい。下記注意事項にご留意頂けない場合には、申し訳ございませんが、評価対象企業から除外させて頂きます。

(1)RFPの主旨から逸脱した提案書の提出はご遠慮下さい。
(2)単一パッケージ・ソフトウェアの宣伝、および説明はご遠慮下さい。
(3)単一製品、あるいは複数の製品を組み合わせただけのソリューション提案はご遠慮下さい。

■内容が薄いのに「全て対応可能」と言う提案書ばかり

●現象
・実現性が薄そうな機能に関しても、「問題無し/対応可能」と提案された
・提供機能に関する具体的な説明が、提案書に記載されていない
・RFPの懸案事項に関して、何も提案がない
・開発スケジュールに具体性がない

●原因
・RFPの内容が薄い
・発注元とベンダーのコミュニケーション不足
・ベンダー技術者の力量不足
・実際の開発作業は、小会社/パートナーに丸投げしている

●解決策
提案書の内容が「薄い」にも関わらず、全ての要求事項に対して「対応可能」とだけ記載されている場合も、これまでと同様、次の点を疑って見るべきだと思います。

(1)RFP記載内容の正確性、および記載内容の粒度
(2)提案書作成前の質疑応答の頻度、および粒度
(3)ベンダーのスキルレベル

また、特に要求事項を実現するための具体性に乏しい提案書に関しては、次の疑いがあります。

(1)営業窓口は本社で、開発担当はグループ小会社
(2)営業担当は一次請会社で、開発担当は二次請パートナー会社

このような状態の時には、窓口と実担当との連携不足で、提案内容が薄く、機能の実現性に疑問がある提案書が作成される可能性が高くなります。

どんなに素晴らしい提案が記載してあっても、具体的な開発スケジュールの記載が無い提案書は、その実現性を疑った方が良いと思います。

提案書の善し悪しを決定する重要な項目は何点もありますが、その中でも重要な項目は次の様な点です。

(1)必要機能が全て網羅されている
(2)各機能の処理概要が記載されている
(3)機能に関する制限や懸案事項が記載されている
(4)具体的な入出力データが提示されている
(5)システム開発スケジュール案が提示されている
(6)スケジュールの実現可能性が高い(工数/担当に妥当性がある)

しかし、上図のように、営業窓口と実際の開発担当が異なる場合には、次のような提案書になります。

●必要機能は網羅されている
●機能概要の説明が短い
●制限事項や懸案事項の説明が無い
●開発スケジュールが提示されていない
●開発スケジュールは提示されているが、工数/担当人数がいい加減

このように、提供機能を実現するために、出来る限り、下記「5W1H」を明確にする必要があります。

Who ：誰が → 発注先 or ベンダー
What ：何を → 人 or 物 or 資金
Where ：何処で → 発注先 or ベンダー
When ：何時までに → 何月までに
Why ：何故 → 何のために
How ：どのようにして → どの位必要か

「5W1H」が不明確な提案書では、システム開発に対してイメージが湧きません。例えば、具体的な開発規模と開発スケジュールが解れば、次のような全体スケジュールをイメージすることも可能です。

・本番開始が7月だから、5月までに納品してもらい、試験を2ヶ月間実施すれば本番には間に合う。
・受入試験は、発注元が行うので、5月までに試験環境を構築する必要がある。
・費用は、試験終了後必要になるから、7月までに予算が執行できるようにして、請求書は6月末に発行してもらえば良い。

しかし、提案書には、「できる」とだけ記載があり、その他の説明が無い場合、上記のような全体スケジュールをイメージすることも出来ません。

具体性がない提案書に関しては、ベンダーに差し戻して、書き直してもらった方が良いと思います。

- - - - -

今回、「RFP」の発行から発注先ベンダー決定までの間に起こる問題点とその解決策をご紹介して来ましたが、いかがでしたか ?

●RFPが作成できない
●ベンダーの提案書が的外れ/ピント外れ
●提案書の内容が薄い
●全然関係ないパッケージの導入を勧められる
●内容が薄いのに「全て対応可能」と言う提案書ばかり

これら問題に関しては、次のような原因がある事も説明してきた通りです。

・発注元が作成したRFPの内容が薄い
・各種コミュニケーション不足
・ベンダー技術者のスキル不足
・大手ベンダーによる下請けへの丸投げ
・「プロダクト・アウト」ベンダーによるソリューション提案
・発注元企業の態度

また、これまでの説明では、上図のように、要件概要を作成した後、直ぐにRFPを作成する業務フローとしましたが、要件概要作成とRFP作成の間に、RFI(Request For Information)と言う工程を組み入れることで、RFPの精度を向上させることも可能です。

また、提案書に対して、フィードバックを行うことで、提案書の精度を向上させることも可能です。

最後に、RFP、および提案書の精度を向上させるための方法を、それぞれ紹介します。

■RFP精度向上

いきなりベンダーにRFPを提出しても、精度の高い提案書を作成して貰えるとは思わない方が良いと思います。

第一に、RFP自体、よほど作成の仕方に慣れていないと、ベンダーに理解してもらえるRFPは作成出来ません。

ベンダーとしても、不完全なRFPから、何とか品質の高い提案書を作成しようと努力しますが・・・精度の悪いRFPからは、精度の悪い提案書しか作成出来ません。「鳶が鷹を生む」事は、まずありません。

そこで、発注元、およびベンダー、双方にとって有益な「RFI」と言う仕組みを紹介しますが、「RFI」は、主に、次の3点を目標にして実施します。

●ベンダー選定のための第一次選定作業
●価格/費用感の把握
●要求事項の実現可否把握

そして、上記目的を達成するために、次のような内容を含む「RFI」を作成します。

●プロジェクト概要の説明
●各種必要資料の指定(会社案内、製品事例集、価格情報、等)
●確認項目/質問票(◯/☓形式の質問票を作成する)

また、ベンダーの担当者に協力してもらい、デモを交えた説明会を開くのも「RFI」の一環といえます。

「RFI」を実施する事で、発注元は、ベンダーから有用な情報を早期に得られますし、ベンダーは、発注元の業務特性や要求のポイントを事前に把握する事ができますので、精度の高い提案書の作成につながります。

■提案書精度向上

「RFI」を作業工程に取り込んだからと言って、それだけで「RFP」の精度が高まるはずはありません。

通常、物事の精度や品質を高めるためには、フィードバックが有効な事は、誰もが認める事だと思います。

このため、より良い提案書を作成するために、「RFP〜提案書」の作業工程の中に、フィードバックの仕組みを取り入れ、提案書をブラッシュアップします。

しかし、フィードバックの仕組みを取り入れる件に関しては、事前にベンダーに説明して了承を得ておく必要があります。それがベンダーへの思いやりです。

さらに、提案書に記載する項目の内、工数やスケジュールに関しては、最初の内は記載不要とし、ある程度ブラッシュアップが行われた後で記載するようにした方が良いと思います。

何故かと言うと、ブラッシュアップが済んでいない段階で、工数や開発スケジュールを記載しても、必ず修正が必要になるからです。

工数やスケジュールを提案書に記載するのは、かなり面倒な作業です。フィードバックを行う度に、工数やスケジュールを変更するのは無駄な作業になりますので、ある程度ブラッシュアップが済むまでは、工数/スケジュールの作成は避けた方が良いと思います。

また、次の点は、企業、あるいは案件毎に異なると思いますが、事前に運用方法を決めておいた方が良いと思います。

●何回フィードバックを行うのか
●何度目のフィードバックから工数/スケジュールを作成してもらうの

ちなみに、前述の図では、1社にしかフィードバックを行っていないイメージですが、実際には、複数のベンダーに対してフィードバックを行い、その都度、ベンダー企業を選定していけば、最終的な契約を行う時点で、1社に選定されていることになると思います。

- - - - -

以上、【ベンダーから「より良い提案書」を提出してもらうため】と題して、ベンダーから提案書を提出してもらう過程において発生する様々な問題点と、その解決方法を紹介しました。

また、RFP、および提案書の精度を向上させるため効果的な方法を、それぞれ1種類ずつですが、合わせて紹介しました。

システム開発を外部に依頼したことが無い方の場合、RFP、RFI、等、全て聞いたことも無い言葉だと思います。

しかし、IT関係に限らず、日々の業務を行う上で、自ら提案書を作成したり、あるいは取引先に提案書を依頼したりするケースは、普通に存在すると思います。

このような時に、今回のブログ内容を参考にして頂き、より良い提案書を作成して貰えるようにして下さい。

それでは次回ブログも宜しくお願いします。

以上

【株式会社 エム・システム】
本      社　 ：〒124-0023 東京都葛飾区東新小岩8-5-5 5F
 　 　 　 　 　 TEL : 03-5671-2360 / FAX : 03-5671-2361
盛岡事業所　 ：〒020-0022 岩手県盛岡市大通3-2-8 3F
 　 　 　 　 　 TEL : 019-656-1530 / FAX : 019-656-1531
E-mail　 　　： info@msystm.co.jp 
URL　　　　　： http://msystm.co.jp/
   　　　　　： http://msystm.co.jp/excel_top.html
ブログ       ： http://d.hatena.ne.jp/msystem/ 
Facebook　 　： http://www.facebook.com/msysteminc