３．ベンダーが「できない」と言いづらいRFPになっている。

【どんな問題が起こるのか】

IT業界では、RFPにおける機能要件の「マッチング率」が重要な意味を持つと認識されています。機能のひとつにでも×がつくと不利になるという認識ですから、多くのベンダーは、様々な解釈を駆使して、できるかぎり多くの 〇 をつけていきます。その結果、ほとんどのベンダーのマッチング率は高くなり、中でも高いマッチング率をはじき出したベンダーの提案が選ばれる可能性が非常に高くなります。これまで書いてきたように、ほとんどの場合、プレゼンテーションというフォーマルな場以外の直接の接触がないため、提出された書類、中でも人によって判断が分かれない「数字」が大きな意味を持つことになるからです。

　既に確定したルールやプロセスをそのままシステム化するタイプのシステム導入であれば、「マッチング率」をベースにした選考は大変合理的です。しかし、人材・タレントマネジメントのエリアは、ほとんどの企業で制度やプロセスが確定していません。ある程度確定したものがあったとしても、ビジネス・労働市場が変化すれば、それに合わせて変えていくことが求められる世界です。また、個社の要件が必ず出てくる戦略の世界でもあります。そうした性質を持つ人材・タレントマネジメントに対して、「パッケージ」という枠組み中で提供される機能だけで、すべての希望に対応できるということはないといっていいでしょう。

しかし、RFPでは×が多くなってしまうと選ばれないという認識が、できないこと、できないかもしれないことを覆い隠してしまいます。そして、そのことが分かるのは、実際のプロジェクトが始まってから、ということになるのです。

【こうした問題を回避するにはどうしたらいいのか】

繰り返しになりますが、パッケージソリューションをベースに、自社の戦略に関わるエリアをシステムでサポートしようと考えたとき、列記した要求機能にすべて 〇 ということは、精緻に誠実に考えれば、ほぼありえません。ですから、もし回答がすべて 〇 だったら、「おかしい」と疑ってかかった方がいいでしょう。「ユーザーの視点で考えれば△かもしれないし、×かもしれない」と率直に伝え、「確かにこの文言をそのままであれば△や×だけれど、こうすれば解決可能」、「こうした機能の組合せで対応できる」など、しっかりと対応策を提示してくれるベンダーの方が信頼できます。

　要望が実現できるか否かを確認することも重要ですが、「できない」ことがあったとき、どのように対応し、解決していってくれるのかを知ることも、同様に重要なのです。その点を認識し、それを確認する方法を探すことをお薦めします。例えば、

「マッチング率も重要な参考情報の一つですが、すべてが 〇 ということもないと理解しています。是非、素直に△・×である機能を教えてください。それに対して、＜どうしてその機能を持っていないのか＞という貴社のシステムに対する考えや、＜他社ではそうしたことを、ＸＸＸＸのような方法で行っている＞という解決策などを教えてください。その情報を、選考の重要な要素として精査させていただきます」

と伝えてみてはどうでしょうか。

その上で、「『公平』であろうとしすぎる」でも書いたように、そのことを話し合えるワークショップを開催できればベストでしょう。ここでは、実際にプロジェクトに関わる人に参加してもらうことが肝要です。そして目の前には、具体的に△・×という、具体的な困難・課題・ハードルが提示されていますから、それについて、どのように解決をしていくのかを提案してもらい、ユーザーとして納得できるか否かを吟味し、具体的な落し所を探っていくプロセスを経験してみるのです。ここまで話し合いをすれば、長く困難が伴うプロジェクトを共に乗り切れる人や組織なのかがわかりますし、システムに期待できることについて、後から「聞いていたことと違う」「話が違う」という落とし穴に落ちる可能性を大幅に減らすことができるでしょう。

RFPは、「人事はシステムのことがわからないから」ということで、選考は情報システム部にまかせるというケースも少なくありません。専門家にまかせるメリットも大きいですが、様々なタイプのシステムを扱っている情報システム部では、システム選び＝RFP＝これまでのお作法に則る、と、一律に扱われてしまう可能性もあります。是非、今回ご紹介した3つの落とし穴に落ちないよう、「お作法」を押さえつつも、「自社に最適なシステム、サービス、そしてプロジェクトの仲間を選ぶ」ためには、どういった方法が適しているのかを真剣に考えていただければと思います。