“失敗原因トップ3”に入る「マルチベンダーのお見合い」状態
今やほとんどの企業で推進されているDXプロジェクト。DXは「デジタルによる変革（Digital Transformation）」の文字通り、システム開発で必要とされるプロセス（要件定義・設計・実装・テスト・リリース）以外にも、業務や組織に関する検討事項や各所と調整・交渉しなければならない事柄も多く発生します。その結果、プロジェクトを成功させるためにやり遂げなければならないタスクの量は膨大に……。それぞれの領域で求められる専門知識も高度かつ経験を必要とするため、単独の部署やベンダーに任せておくだけで成功するといったケースはないと言っていいでしょう。さらに、昨今の深刻化する人材不足やベンダー不足の状況も相まって、複数のベンダーが協力して一つのプロジェクトを遂行する「マルチベンダー体制」で実施することが今や一般的になっています。
こうしたマルチベンダー体制でしばしば起こるのが、ベンダー同士が野球でいう「お見合い」状態になってプロジェクトの進捗が滞ってしまうケース。お見合い状態とは、選手がボールを取りに行こうとするものの、互いに譲り合って捕球に向かわず、結果的にボールを落としてしまうといった消極的なプレーを指す言葉で、「誰かがやってくれるだろう」と思い込んでいるために発生するものです。DXプロジェクトでは複数の企業で多くの人員が稼働しているため、プロジェクトの停滞は大幅な費用とスケジュールの無駄につながってしまいます。加えて、停滞していることへの焦りから責任の押し付け合いなどに発展すると、プロジェクトそのものが空中分解する可能性もあります。実はこの「マルチベンダー体制のお見合い状態」は、私が企業のコンサルティングを実施する中で、大規模プロジェクトの失敗原因のトップ3に入るほど頻繁に見かける問題なのです。
[画像クリックで拡大]
そこで、今回は「マルチベンダー体制でお見合い状態が発生し、プロジェクトの停滞と巨額の費用ロスが発生！ こんなときどうすれば？」をテーマに取り上げます。マルチベンダー体制はなぜ失敗しやすいのか、その効果的な対処法についてお話ししましょう。
ベンダーの並列的な役割分担がお見合い状態を引き起こす
マルチベンダー体制では、次のようなプロジェクトを遂行する上で必要な役割に応じてベンダーが割り当てられるパターンがしばしばあります。
- 業務・システム要件の取りまとめ
- デザイン（UI/UX）
- フロントエンド開発
- バックエンド開発
- インフラ開発
- 現場オペレーション（システム導入先）
状況に応じてデザインとフロントエンド開発を兼ねたり、フロントエンド開発とバックエンド開発を兼ねたりするなど、複数の役割を1つの企業が担うことはありますが、DXプロジェクトでは複数の企業が参画することは一般的です。
また、これらの役割に加え、開発したシステムを第三者にサービスとして提供する場合は営業や広告・マーケティングが役割として加わったり、開発規模が大きくなることで同じ役割を担う企業が複数社加わったり、システムの導入先がグループ企業で複数社存在したり、システム連携が必要な際に担当ベンダーが加わったりすると、ステークホルダーは大幅に増えます。さらに、これらの企業の間で商流（受発注関係）が加わると、各社の関係性は指揮系統と契約関係が絡み合って複雑怪奇なものになってしまいがちです。
[画像クリックで拡大]
上記のような役割分担によるベンダーの割り当ては、プロジェクト発足当初は各所の責任が明確化されているため、綺麗に整理されているように見えます。しかし、こうした並列的な役割分担で実際にプロジェクトを進めると、発注元の情シス担当者の統括・調整業務が膨大となったり、リスクが顕在化する前に「先手」を打てずに調整業務が増大したりする恐れがあります。結果として、手が回らなくなって必要な検討や調整が進まなくなったり、情報の混乱が生じたりするようになってしまうのです。
このような状況下では、ベンダーはプロジェクトが本来目指すべき目標の達成よりも、自社の利益やリスクを意識するようになります。これはプロジェクトの発注企業にとっては背信行為にも取れますが、ベンダー各社としてはいち企業として売上や利益を確保し、プロジェクトの炎上に巻き込まれて社員がリタイア（休職・離職）する可能性は回避したいと考えるため、リーダーシップの欠如が引き起こす必然的な結果だといえるでしょう。
ベンダー各社がリスク回避のために受け身の行動を取るようになると、お互いに空気を読み合うお見合い状態になります。この時点で既に関係者の積極性や信頼関係は失われているため、合意形成の取りこぼしや確認事項に関するミスコミュニケーションや作業の手戻りが多発するようになり、プロジェクトは当初想定されていた計画通りには進まなくなります。この状態を放置すると、時間の経過とともに予算と納期のプレッシャーが強くなり、最終的に遂行責任の押し付け合いとなってプロジェクト全体が崩壊してしまう事態にもなりかねません。最悪のパターンでは、責任の所在を求めて裁判沙汰にまで発展することもあるでしょう。
