DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

夏の高校野球予選もいよいよ終盤を迎えています。超ハイリスク「甲子園への道プロジェクト」を成功に導くことができるチームはごくわずか。あと一歩で甲子園を逃すチームにもプロ注目の選手がゴロゴロいるので、プロ野球のスカウトたちも、必死に情報収集を行っていることでしょう。

しかし、長年のスカウト活動を通して目の肥えたスカウトマンたちが必死に情報収集してドラフト上位指名した選手たちも、いざふたを開けてみたらまったく使い物にならず、あっと言う間にプロ野球の世界を離れていくなんてことも良く聞きますよね。

同じように、せっかくしっかりとしたベンダー選定プロセスを踏んでも、期待通りの成果をあげられないシステム開発ベンダーもいますよね？今回は、システム開発プロジェクトの失敗原因のひとつとしてあげられるベンダー選定の失敗について考察します。

【　一般的なベンダー選定プロセス　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずは、簡単に一般的なベンダー選定のプロセスを確認します。

図１では、要件定義以降（たとえば、要件定義～移行まで）を委託する場合のベンダー選定プロセスを示しています。

①　ベンダー選定方針策定
ここではシステム企画で検討した外部委託の活用方針に基づき、具体的にどのような手順やスケジュールでベンダーを選定するか方針を明文化して、社内承認を得ます。
たとえば、ベンダーとのコミュニケーションを重視して過去に委託したことのあるベンダーを優先的に選定するとか、今回は失敗が許されないプロジェクトなのでコストよりもスキルを重視するとか、逆に発注側でベンダーをしっかりコントロールするのでコストを重視するとか、そのプロジェクトの特性に応じた方針を明確にします。

②　ＲＦＰ策定
システム企画書の内容をもとに、ＲＦＰ（提案依頼書）を策定します。詳細は、ＲＦＰの書き方に関する文献が多数出ているので、そちらを参照してください。（※１）

③　候補ベンダー選抜、引合
ベンダー選定方針に基づき、委託先候補ベンダーをリストアップします。この段階で各ベンダーのホームページなどに開示されている情報などから、会社の安定性や提案依頼範囲の他社導入実績などを下調べします。そして、実際にベンダーの営業担当とコンタクトをとるなどして、提案参加への「やる気度」なども確認します。

④　ＲＦＰ配布・説明会実施
提案依頼候補のベンダーに対し、ＲＦＰを配布し、説明会を実施します。ＲＦＰは事前に配布し、各ベンダーが読み込んだうえで説明会に参加してもらうようにします。説明会への参加メンバーの顔触れ、説明会での質疑応答内容なども候補ベンダーの実力と「やる気度」を確認するために有益な情報となります。

⑤　ベンダー選定評価基準策定
ベンダー選定方針に基づき、どのような評価軸でベンダー選定を行うか、具体的な評価項目をリストアップし、審査者がどのように評点するかなどの基準を策定します。コスト重視なのか、実績重視なのかなどの方針によって、どの評価項目を優先させるか、重みづけを検討します。

⑥　ＲＦＰのＱ＆Ａ対応
ＲＦＰの記載内容に対してベンダーからの質問を受け付け、回答します。公平を期すために、各ベンダーからの質問および回答内容については、提案依頼ベンダー全社に同じ内容を共有するのが一般的です。この段階で、プロジェクトに内在するリスクについて鋭い質問がされるのか、記載不備など形式的な質問ばかりなされるのかなど、ベンダーの実力把握としても重要なプロセスになります。

⑦　ベンダー提案書受領・一次評価（書面審査）
各ベンダーから提示された提案書を一次評価し、候補ベンダーを数社に絞り込みます。ベンダーの評価に際しては、発注側のプロジェクトマネージャだけでなく、プロジェクトオーナやプロジェクトメンバなど、複数名で評価を実施することで、客観的な評価を行います。ＲＦＰの内容について誤認していたり、依頼内容に沿わないような提案の場合は、改善を依頼して、できる限りＲＦＰの趣旨に沿った提案にブラッシュアップするよう促します。

⑧　提案説明会実施・二次評価（プレゼン審査）
各ベンダーからの提案内容を、実際にプロジェクトに参画するベンダー側のプロジェクトマネージャや主要メンバからプレゼンテーションしてもらうことで、体制面の評価も行います。

⑨　内定・交渉・契約
二次評価の結果、最終的に交渉するベンダーを選定します。契約文書については、指定の様式があればＲＦＰと合わせて事前に配布しておくなど、最終段階で無用な事務手続き上の齟齬や調整が出来るだけ発生しないように留意します。
二次評価の結果、どのベンダーも合格点に達しなかったなんてケースについても、あらかじめ対応方針を明確にしておくと良いでしょう。

ベンダー選定後は、ベンダーからの見積り内容やベンダーの作成するプロジェクト計画書をもとに、発注側で作るプロジェクト計画書と摺合せを行って、発注側、受注側の計画の整合性を確保した上でキックオフを迎えることになります。

【　ベンダー選定の落とし穴　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
しかし、これだけしっかりしたベンダー選定手続きを実施していたとしても、キックオフ後にプロジェクトが暗礁に乗り上げて、プロジェクトの中断やベンダーチェンジに至る事例をなんども目の当たりにしてきました。

プロ野球のドラフト指名をかけるスカウティングと同じように、ベンダー選定はそんなに簡単なものではありません。発注側組織のビジネス目標達成のために大きな投資を伴うシステム開発の場合、ベンダー選定の失敗によるプロジェクトの失敗は、断じて許されることではありません。

では、先ほどのベンダー選定のプロセスのどの部分にどのような落とし穴があるのか、もう少し深堀してみたいと思います。

＜　ベンダー選定の落とし穴　＞

１． 準備期間の不足

図１で示すベンダー選定プロセスでは、ＩＴ構想・企画～キックオフまでの間にＲＦＰ作成から契約までを実施することになります。ベンダー選定のためにとれる期間は、せいぜい１～２ヶ月程度ではないでしょうか？つまり、各ベンダーとしては、ＲＦＰを受領してから数週間のうちに発注側の意図を汲み取った上で、要件定義から移行までのフィージビリティのある計画を組み立てる必要が出てくるのです。

発注側の立場からすると、ベンダーから提出された提案書に記載されたスケジュール、予算、品質が確保されなければ、ベンダー責任でプロジェクトが失敗したとみなすことでしょう。

どう思います？ベンダーの立場で、上記のスケジュール感で提案した通りにＱ（品質）Ｃ（予算）Ｄ（納期）を達成するためには、発注側の企画段階から深く入り込んでしっかり情報収集して発注側とスコープや進め方を握っておくか、キックオフ後にいくつかチェックポイントを設けておいて、そのたびにプロジェクト全体のスコープやスケジュール、コストを見直しして、着地点を模索していくというアプローチしか無いのではないでしょうか？

実際、図１に示すようなベンダー選定プロセスを踏みながらも、実際は出来レースというケースも何度も見てきました。

２．提案チームと開発チームのスキルギャップ

発注側からすると、候補ベンダー選抜、引合の段階から、長い期間をかけて、最終的には提案書の評価、および、実際にプロジェクトに参画するベンダー主要メンバのプレゼン評価まで行って、ベンダーを選定することになります。

しかし、プロ野球ドラフトの例をあげるまでもなく、人物評価はそんなに簡単なものではありません。ましてや、プレゼン評価に出てくるメンバは多くても10人程度であり、プロジェクトメンバ全員と面談するわけにはいきません。

開発ベンダーとしては、受注がとれるかどうかは大きなことなので、提案チームに優秀な人材を固めるということも往々にして行われるものです。その場合、キックオフ後にふたを開けてみたら、開発チームのメンバの実力は明らかに不足していて、というか提案チームのメンバ以外はすべて再委託、再々委託のメンバであったり、発注側が思い描いたプロジェクト運営ができないということもあり得るのです。

３．発注側と受注側の役割分担の認識齟齬

発注側の作成するシステム企画書やそれをもとにしたＲＦＰの検討が不十分だった場合、キックオフ後に要求仕様やシステム化の目的にブレが生じるケースがあります。そのようなケースに委託先ベンダーが踏み込んで要求仕様やシステム企画段階までさかのぼって精査に積極的に入り込んでくれるか、それとも「要求仕様は発注側の問題」として突き放してしまうかでプロジェクトの先行きは大きく異なります。

発注側としては、他社導入事例なども参考にして、その業務におけるシステム導入のプロフェッショナルに委託しているのだから、たとえ発注側が少しぐらいしっかりしていなくてもベンダー側がフォローしてくれるのが当たり前と考えます。しかし、受注側としては、ＲＦＰの記載内容に対して提案書を提示し、その内容に基づいて契約しているので、要求仕様の精査などは契約外という主張も当然のことです。

このようなケースでは、発注側、受注側がお互いに歩み寄らなければ、プロジェクトはとん挫するのは当然のことです。

さあ、どうしたものか？

既にみなさんお気づきのことと思いますが、図１で示すベンダー選定プロセスは、発注側で策定するシステム企画書がしっかり出来ていることが大前提になっているのです！

旧来のベンダーに要求仕様の整理やプロジェクト全体のマネジメントまで依存するようなやり方や体質が残っている組織では、よっぽど良いベンダーに当たらない限り、このようなベンダー選定プロセスは合わないのではないでしょうか？

しっかりしたＲＦＰ（提案依頼書）の提示が前提となっているベンダー選定プロセスは、しっかりしたＩＴ構想・企画を実施しない限り成り立たないという事実をしっかりと受け止める必要があるのです！

「ベンダー選定プロセスは、ＩＴ構想・企画がきちんとできていることが大前提だ！」

ドラフト1位に指名したスーパー高校生が期待通り活躍しなくても、他のメンバたちだけで試合に勝ち続けることができなければ、ペナントレースを勝ち取ることができないのは当たり前ですよね！

それでは次回もお楽しみに！　　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　ベンダー選定プロセスやＲＦＰ記載内容については、以下書籍参照。
・長尾清一(2009)『ベンダーマネジメントの極意』日経BP社

RFPについては、当ブログの以下記事も参照。
・【第２８回】ＲＦＰに隠された暗号を読み解け！