RFP作成から始まるベンダ選定~選定でシステム開発プロジェクトの結果の8割が決まる
先日とある企業を訪ねたときの話しです。
先方が開口一番「今のシステム開発ベンダーにはほとほと困っているんですよ」と開発プロジェクトの心労を吐露されました。
話しの内容はこうでした。
新サービスの企画開発にあたって、システム開発ベンダを募集し、予定価格内で対応できる企業を発注先に決め、昨年末に開発体制をスタートしたそうです。営業やエンジニアの印象はなかなか良かった、集めた3社のうち提案内容も一番良かった、とここまでは良かった。
しかしこの時すでに誤算が生じていました。
ボタンの掛け違いが早々に露呈したのです。
開発仕様を決めてくれないと作業できないというシステム開発ベンダの主張によりプロジェクトがフリーズしました。
そもそも外部に発注したのは自社のリソース不足が理由であり、実業務と兼任のため開発仕様の作成まで手が回らないからでした。
役割分担の調整についてシステム開発ベンダから提案が無いまま進捗が遅れていきます。
背に腹替えられぬと実業務の手を止めて、開発仕様を作らざるを得ないことになりました。
想定外の負担を抱えているのに予定期日が来てもシステムは半分くらいしか出来ていません。
この先どうなるかと思うと溜息しかでないとのこと。
一体どこで判断を間違ってしまったのでしょうか?
実は一見当然のようなベンダ選定のプロセスに問題があるのです。
ベンダ選定で結果の8割が決まってしまう
ちなみに先の例のようにベンダ選定で躓いてしまうと後から挽回するのは難しくなります。
社内体制であれば内部調整で済むことも、外部に発注している場合は「契約」が絡むからです。
ベンダの仕事の仕方が下手でも簡単に切ることはできません。一度ベンダを決めて契約してしまったら、よほどのことが無い限り、最後まで走り抜くことになります。その「よほどのこと」が相当深刻ではあれば、損切りしたほうがダメージが少ないかも知れませんが、それでも相当に余分なエネルギーを使い、相応のダメージを受けます。
つまりシステム開発は、ベンダ選定という入り口のところで成否が8割決まってしまうのです。しかも自社にとって相性が良く無いベンダと出会う確率は、良いベンダと出会う確率よりも高い。それだけでなく技術スキルや仕事スキルが低いベンダと出会う確率だってかなり高いのです。
発注側に知識や工夫が無いとトンデモなことに巡り合ってしまう、と考えても大袈裟ではないでしょう。
ベンダ選定は候補社集めからすでに始まっている
上の図はシステム開発ベンダー選定のおおまかな流れです。
それでは順を追って見ていきます。
STEP1 候補の洗い出し~絞り込み
1.母集団形成
まず候補ベンダの母集団をつくります。
Webサイトをリサーチして少なくとも10社以上、できれば30社ほどをリストアップします。
数を集める意味は、母集団の中に本命候補となる企業が含まれる確率を高めるためです。そんな沢山の数を揃えても、この後の選定作業が大変ではないかと思われるかもしれませんが、母集団が大きければ大きいほうが自社にとっての「本命」と出会える確率が高まります。
ここは割り切って大きな母集団づくりを目指します。
母集団から絞り込んだ中に原石が残るわけですが、そもそも母集団に原石が混ざっていないことには話しになりません。だから広げる作業が大事なのです。母集団から最後の1社に決めるまでは「じょうろ」のように広い入り口から徐々に狭くなっていくイメージとなります。
2.有力候補の絞り込み
リストアップは広げる作業ですが、ここから先は絞り込みの作業となります。目安としては4~7社くらいでしょうか。自社が抱える案件の重要度やリソースによります。ただ途中でベンダから辞退されることもありますので無理に絞り込まずプラスαの候補数を残すことです。
絞り込みの方法として各社に情報提供を依頼します。
「情報提供依頼」というのはコーポレートサイトや会社案内に公開されていない情報を求めることを指します。例えば、自社が属する分野での事例の有無や内容。あるいは自社のテーマを伝えたうえで、そのベンダが提供しているサービスで対応可能かどうかと、どんなアプローチで可能なのかについての情報を個々に求めます。
このとき「提案して欲しい」と言うのではなく「情報提供をお願いしたい」という伝え方で、ベンダの担当者には意図が伝わるはずです。
なお母集団が大きいと1社1社お会いするのは大変なのでメールでのやり取りにとどめたいところです。先方から面会を求められても「今は広く情報収集している段階のため固まってからお願いしたい」と伝えます。
母集団を形成する1社1社全てにお会いするのは無理と割り切ったほうが良いでしょう。実際にお会いするのは絞り込んだ後で充分です。
STEP2 提案依頼(RFP:Request for Proposal)
1.提案依頼書作成
候補ベンダを絞り込んだら、いよいよこの中から本命を探っていくことになります。
その方法として提案依頼書(RFP:Request for Proposal)を元にコンペで選定します。
提案依頼書とは「このような内容で提案して欲しい」という内容を記載したドキュメントのことで、具体的にはシステム化したい機能や要件、解決したい課題など織り込みます(本ドキュメントの作り方については別の機会に触れます)。
2.ベンダとの面会
情報提供依頼のときは面会を省きましたが、この段階ではベンダと面会してノンバーバルな情報も掴んでおくことが望ましいでしょう。
ここで案件概要とコンペであることを伝え、段取りと各期日について説明し、参加意思を確認します。
3.機密保持契約の取り交わし
ベンダに提案依頼書を提示するにあたっては、そこに記載されている自社の機密情報についての守秘義務が必要です。
その一般的な方法として機密保持契約を結びます。
4.オリエンテーション
提案依頼書の説明を口頭で行って質疑応答する場を設けます。
1社づつ個別に行うのは開催側の負担が高いため、複数社を集めて説明会形式で行うのが良いでしょう。
5.ベンダからプレゼンテーションを受ける
各社からの提案内容についてのプレゼンテーションを受けます。
その際にはプロジェクトリーダーとその補佐役の方をプレゼンメンバーとして参加を要請しておき、人物象についてもしっかり観察します。
この時しっかり、じっくりと質問することで、実際にプロジェクトが動いているときの様子を想像していきます。
回答姿勢、背景となる経験や知識、お互いの噛み合いの良さを質問を通じた相互のコミュニケーションから把握します。
STEP3 提案評価
評点表につけた点数を積み上げて評価します。
一般的には残った上位2〜3社あたりで最終判断することになります。優劣付けられずに迷うこともあるでしょう。迷うというのは点数を比べるだけで決められないということです(オートマティックに決められるほど評点表が完璧に設計されていれば話は別ですが)。
その場合の評価方法について述べていきます。
まず比較すべきはベンダそのものではありません。自分達とベンダとの関係が重要です。
ベンダ側のリーダーや技術担当者と話しているときの自分達がどうであったか、ここを評価します。
そもそもITというテーマで、クライアント企業とベンダが仕事する場合、クライアントが「こんなものを作って欲しい」とベンダに求めるような一方通行の発注行為では、うまく廻りません。双方向性が大事なのです。
クライアント企業は自分たちのビジネスについて誰よりも詳しい人、システムベンダはテクノロジーの活かし方の専門家、というお互いの役割分担がコラボしあうような関係です。
言い換えると両者が二人三脚でゴールに向かうようなものなので、大事なのは相手のスペックではありません。
自分と相手の呼吸が合うかどうかが大事なのです。選定の最終段階ではここを重点的に評価しないといけません。
そのためのコミュニケーションの時間を別途作るのも良いでしょう。
STEP4 契約
ベンダが決まったら、ベンダ選定の最終関門である「契約」を取り交わす工程に進みます。
契約は言い換えればトラブルの予行演習とも言えます。冒頭の例では業務範囲についての取り決めが曖昧だったため、ベンダによる「それは自分たちの役割ではない」という主張に対抗できませんでした。
契約に織り込む内容は、お互いの仕事の仕方を両者が膝を詰めて話し合った結果とも言えます。
お互いの責任範囲、納品物の定義、各工程の期日、権利関係など事前に話し合うことは沢山あるでしょう。
そして上記以外にも考えられる得るあらゆる「うまくいかない事態」を想定して条件に織り込みます。
その結果として相手方との交渉において呑める呑めないという話しが必ず出てくるでしょう。
この「うまくいかない事態」を回避するために、ベンダにとって厳しい条件を折り込まざるを得ないかも知れません。
それを呑んで貰えるかどうかは交渉次第ですが、見逃せないポイントは今までは話しが和やかに進んでいても契約でご破算となる可能性が残っているということです。
他社には落選を伝えてしまった後に、本命から辞退されてしまったら次の選択枝はもうありません。
ということから契約が完了するまでは、以下の2点をしっかり抑えます。
まず決定ベンダには内示を告げるに留め、契約の仮合意を以て、役員会で最終承認すると伝えます。交渉相手を100%安心させず少しでも発注側優位に進めるためです。
一方で2位以下のベンダにも同じように伝えて保持します。このように契約が完了するまでは決して気を緩めてはいけません。
分かっていても「プレゼンが上手いベンダ」に心が傾くのは何故か?
一般にコンペというと提案内容やベンダの企業規模、安定性、将来性などスペック情報を見比べることが多いですが、スペックを見ても判断を迷うだけというケースは多いです。
また傾向としてプレゼンが旨いベンダに評点が集まります。なぜなら感情が揺り動かされるからです。
ベンダ選定というロジカルな場面で、感情で意思決定されることがあるのでしょうか。筆者の経験では企業の意思決定において感情要素が多分に影響することは少なくありません。感情が揺り動かされると、ロジック側の脳の働きよりも感情優位になるからです。当事者としては合理的に判断しているつもりでも第三者が客観的に見れば必ずしもそうではありません。
特に大きな予算が動く案件でプレゼンでは、意思決定権者から担当者までが同じ場に集まりますから、素晴らしいプレゼンを皆が聞いて、皆が感銘してしまったら反対する人は居なくなるわけです。このとき集団として誤った判断に突っ走りやすいのです。プレゼンが上手い=自社にベスト、であれば良いのですが、両者は必ずしもイコールではありません。
前述のとおり相手との息が合いそうかどうか、この点をしっかり見定めてください。
この記事を書いた人について
-
オーシャン・アンド・パートナーズ株式会社 代表取締役
協同組合シー・ソフトウェア(全省庁統一資格Aランク)代表理事
富士通、日本オラクル、フューチャーアーキテクト、独立系ベンチャーを経てオーシャン・アンド・パートナーズ株式会社を設立。2010年中小企業基盤整備機構「創業・ベンチャーフォーラム」にてチャレンジ事例100に選出。
最新記事一覧
- 経営者向け2024.11.18基幹システム再構築とは何か?:価値を生み出す仕組みの再設計
- システム開発2024.11.13見積依存のリスク:発注者が知っておくべき価格依存の弊害
- RFP2024.11.12システム再構築における発注力の重要性とその鍛え方
- RFP2024.11.11IT導入の成功に不可欠なシステム部門の役割拡大と組織づくり