提案活動を行う際に,提案を受け取る側のユーザー企業の考えを知ることは極めて重要だ。ユーザー企業の立場でベンダー選定のコンサルティングサービスを行う筆者が,実際に見た提案書の例を通して,ユーザー企業が提案書に何を望み,どのように評価しているかを解説する。

内山悟志(うちやまさとし)
アイ・ティ・アール代表取締役

 「ページごとに書式やフォーマットがバラバラで,明らかに社内のいろいろな部署から資料を寄せ集めて作ったということが分かる」,「情報システムに関する問題点や解決策が述べられているが,極めて一般的かつ表面的な内容で,まったくリアリティが感じられない」。

 いずれも,筆者がユーザー企業とともにベンダーを選定する際に,実際によく目にする提案書だ。当然のことだが,こうした提案書を高く評価するケースは,まずない。ユーザー企業にとって提案書は自らのビジネスの成否を決めることもある重要な文書だからだ。ではユーザー企業が評価する優れた提案書とはどんなものか。そもそも提案書のどこをどう評価するのだろうか。以下では,ユーザー企業の立場から見た,提案書のチェックポイントを紹介しよう。

一般化したRFPの作成

 ユーザー企業がベンダーに相談を持ちかけ,提案を要求するケースは大きく2通りに分けることができる。

 1つは,依頼内容が不明確な状況で,ベンダーに提案を求めるケース。ユーザー企業の悩みは様々であり,場合によってはユーザー企業自身が自社の課題を十分に整理できていないこともある。そこで自分たちの漠然とした問題意識やニーズを引き出して,整理してもらうことをベンダーに求めるのだ。この場合は,課題や要件を整理するために,提案を受ける前段階からベンダーに作業を手伝ってもらうことが少なくない。

 ユーザー企業がベンダーに提案を要請するもう1つの状況は,「RFI(情報要請書,Request for Information)」および「RFP(提案依頼書,Request for Proposal)」を発行する場合である。基本的に,競争入札のように複数社に対して同時に提案を求めるのが一般的だ。

 周知のとおりRFPとは,情報システム構築を外注しようとしたり,ハードやソフト,あるいはサービスを購入しようとしたりする際に,各種の要件をまとめてベンダーに知らせるための文書である。

 以前は,ユーザー企業がベンダーの提案を受けるために正式なRFPを作成するケースは,まれだった。しかし,90年代後半以降は,オープン化の浸透とともに,ITに様々な選択肢が登場してきた。その結果,従来のように特定ベンダーに発注するのではなく,自らの責任で自由に発注先を選択することが可能になった。そこでRFPの有用性が認識されるようになったというわけだ。現在では,大手企業において一定規模以上のプロジェクトにおけるベンダー選定では,RFPの作成が一般化しつつある。

選ぶのは「モノ」か「力量」か

 ここでRFPの種類と中身について説明しよう。ユーザー企業が作成するRFPには,やはり大きく分けて2つのパターンがある。「詳細なRFP」と「簡素なRFP」だ(表1)。

表1●RFP(提案依頼書)の2つのタイプ
表1●RFP(提案依頼書)の2つのタイプ
RFPは,目的に応じて2つのタイプがある。詳細なRFPは,ベンダーに対して製品・サービスやプロジェクトの推進体制などの「実現性」の提案を求め,簡素なRFPは,経営に関する「課題構造」を整理・分析し,その「解決策」を明確に示した提案を求める

 詳細なRFPは,要件を綿密に記述して,ベンダーにそれに沿った提案を求めるものである。それぞれのベンダーが示す解決策から,要件に合致したものを選ぶことになる。

 もう一方の簡素なRFPは,要件の概略だけを示し,ベンダーからある程度バラエティに富んだ提案を受け,課題解決に対して実行力のありそうなベンダーを選ぶためのものだ。

 新築社屋を建てる時の設計士の選定に例えると,前者は具体的な新社屋の外観模型や詳細図面の提示をしてもらい,「モノ」を選ぶことを目的とする。これに対して後者は,これまで設計したビルの写真やデザイン・コンセプトの提示を受け,「人」(デザイナーの力量)を選ぶことを目的としている。当然のことながら,前者のように具体的な仕様の提示を求める場合は,入居人員,必要な設備などに関する詳細な要件を伝えられることが前提となる。一方,後者のように力量でベンダーを選ぶ場合は,選定の後に詳細な仕様を詰める作業が追加されることになる。

 既存システムをそのままダウンサイジングしたり,明確な目的があって改修するといった案件は要件が確定しているので,詳細なRFPを作成できる。この場合は,機能,仕様,スケジュール,手法などについて,ベンダーが明確に示してくれているかどうかが提案内容のチェックポイントとなる。

 一方,業務改革のコンサルティングや新規業務のシステム化など要件が不確定で解決策が見えないような案件はどうか。例外はあるが,一般には簡素なRFPを作成する。こちら の場合はソリューションの内容に加えて,同様のプロジェクトの実施経験,担当者のスキル,会社としての対応能力などもチェックする。

質問はどんどんぶつけてよい

 ユーザー企業がRFPを作成する場合に,ベンダーを選定する手順は図1のとおりだ。実際の作業は,大きく分けて「事前調査」と「評価・選定」の2つのステップから成る。

 事前調査では,自社の課題に対する解決策を,ある程度幅広い視野で模索する。進め方は,雑誌,トレードショー,インターネットといった一般公開情報を収集する場合と,RFI(情報要請書)を作成し,各ベンダーからパンフレット,既存のプレゼンテーション資料,技術ドキュメント,価格表などを入手する場合がある。事前調査の目的はあくまでも情報収集であるため,自社のニーズや要件を詳しくはベンダーに伝えないのが一般的だ。

 事前調査を終えると,自社の要件をRFPとして作成し,候補となるベンダーに対して投げかけ,提案を受ける。このとき,多数のベンダーにRFPを渡すと選定が煩雑になるため,事前調査をもとに3社から6社程度に絞り込むのが普通である。

 RFPを渡してから,提案書の提出締め切りまでの期間は,一般的に2~3週間だ。その間に,ベンダーが提案を検討する上で必要な質問事項は,積極的にぶつけてもらってかまわない。むしろユーザー企業はそれを望んでいる。ベンダーがどのような質問を投げかけてくるかを,提案姿勢や洞察の鋭さといった観点から評価している場合もあるからだ。

 ユーザー企業は提案書を待つ間に,どのような基準で評価・選定するかについて検討し,採点表を作ることが多い。各社から提案を受け取ると,その内容およびプレゼンテーションをもとに,要件に適合する解決策とベンダーを評価する。プロジェクト・メンバーの間でそれぞれの採点結果を突き合わせ,さらに定性的な検討も行ったうえで,最終的にプロジェクト・チームとしての結論を下す。必要であれば経営者などの承認を得て,合否を各ベンダーに通知するという流れだ。

図1●ユーザー企業がベンダーを選定する際の一般的なプロセス
図1●ユーザー企業がベンダーを選定する際の一般的なプロセス
選定プロセスには,情報収集のための「事前調査」と,具体的なベンダー選定のための「評価・選定」の2つの段階がある。最近は,後者のコンペを2回実施し,1回目でITベンダーの「提案の内容」を,2回目で「見積もり」を評価する方法が増えている