7割が失敗するDX推進プロジェクト成功の秘訣

一般的に、7割のDX推進プロジェクトが失敗すると言われています。メンバーの全員が失敗したくないと考えているはずなのに、なぜ失敗は繰り返されるのでしょうか？横断的な組織構成で、データ連携を多く必要とするようなDX推進のようなプロジェクトでは、本当の課題・目的が見えず失敗するケースも散見されます。リカバリーをスムーズに行い、プロジェクトの失敗を回避できる体制づくりについてご紹介します。

INDEX

• 隠された課題を抽出し、真の目的を定義してプロジェクトを計画・実行することが、プロジェクトを成功に導くカギとなる。
• 中立的な立場のコンサルタントであれば、プロジェクトマネージャーとしても公平に優先順位を決めることができる。
• プロジェクトマネージャーが、システムの各機能に割り振られたリソースや進捗を正確に把握していることは少ない。

隠された課題を抽出し、真の目的を定義してプロジェクトを計画・実行することが、プロジェクトを成功に導くカギとなる。

一般的なシステム開発を含むプロジェクトでは、SIerなどによってアサインされたプロジェクトマネージャーが、クライアントから提示されたRFPに基づきプロジェクト計画書を作成します。このような流れでは、クライアント側の課題やプロジェクトの真の目的が明文化されず、開発フェーズを経てから、露見することも少なくありません。

その結果、プロジェクトの再計画が必要になり、リカバリーに失敗すれば納期遅延や品質低下に直結してしまうでしょう。クライアント自身が気付かない課題を抽出し、真の目的やゴールを定義してプロジェクトを計画・実行することがプロジェクトを成功に導くカギとなります。

それでは、失敗しないプロジェクト体制は、どのように築くことができるのでしょうか？

中立的な立場のコンサルタントであれば、プロジェクトマネージャーとしても公平に優先順位を決めることができる。

客観的な視点で課題を抽出し、解決策を考えるコンサルタントが上流工程に関わることで、プロジェクトの背景や特徴、体制などについて深く理解することができます。特にデータ連携を伴うシステム開発プロジェクトでは、実際に各部門の担当者から直接話を聞くまでは、クライアント側の実態が見えないことが多いです。それは、課題抽出のプロではないクライアント側の担当者では、多面的な視点が欠けており、問題の本質に迫ることが難しいからです。

また、各部門の担当者から作業フローや既存システムについて、具体的な話を聞くことで、隠れていた課題が見え、ユーザーを意識して優先順位を決めながら整理することで、真の目的を導きだし最適な改善策を考えることができます。ここで想定されるユーザーは、プロジェクト完了後に完成したシステムを操作するクライアント側の担当者も含まれます。そして、この過程で生まれるコミュニケーションや理解が助けになり、クライアントからの信頼を得ることもできるのです。

クライアント側・受注側のどちらでもない中立的な立場であるコンサルタントであれば、プロジェクトの目的と照らし合わせ、公平に物事の優先順位を決められます。不測の事態が発生しても、そのコンサルタントがプロジェクトマネージャーとして判断・提案したリカバリー策は説得力の高いものとなり、承認されやすくなります。リカバリー策が定まらないまま納期が遅延することや品質の低下を回避して、プロジェクトを成功に導くことが可能になるのです。

プロジェクトマネージャーが、システムの各機能に割り振られたリソースや進捗を正確に把握していることは少ない。

一般的なプロジェクトの多くは、コンペによって受注側を決めますが、クライアント側はRFP（要件依頼書）によって予算を明示する必要があり、受注側は予算を使い切る内容を企画・提案することが多いでしょう。そして、提案内容に大差がなければ、より多くの機能を盛り込んだ魅力的な企画が通ることになります。受注後に、SIerなどがプロジェクトマネージャーをアサインされプロジェクトはスタートし、要件定義・設計が順調に進み、開発が始まる頃の定例会では「進捗は問題ないです。」と、毎回同じような報告がプロジェクトマネージャーからされることでしょう。

ところがある日、定例会の数日前にプロジェクトマネージャーから担当者個人宛に連絡が入り、「開発責任者からスケジュールの相談が入っており、今週の定例会で議題に入れる予定です。」と、プロジェクトに黄色信号が灯ることは良くあります。クライアント側からは開発現場の状況がみえづらいものですが、プロジェクトマネージャーもまた、システムの各機能に割り振られたリソースや進捗を正確に把握していることも少ないように感じます。開発現場からの報告を鵜呑みにし、気が付いた時には公開を遅らせる判断を迫られることもあります。これは、同一企業内で効率を優先した分業化の弊害でもあります。

想定していたスケジュール通りに進まないのは、「こんな機能あるといいよね。」、「既存システムとの連携を考えると〇〇ができる機能が必要です。」と要件定義・設計を通して追加要望が積み重なり、当初想定していたシステム設計・仕様への影響の調査、リソース確保など、開発現場に余計な負荷をかけてしまうことで、引き起こされるケースも多いでしょう。

また、開発・テストが完了した段階で、クライアント側では初めて運用を想定したオペレーションができるようになり、システムを俯瞰して確認することができます。最悪のケースでは、「想像していたイメージと違う。」、「処理スピードが遅くて話にならない。」などのように、RFPには記載の無かった要望や不満が噴出します。その結果。信頼関係が崩れ、スピーディーな判断や、妥協案などの相談もできなくなり、プロジェクトが頓挫してしまうこともあるでしょう。

結局のところ、SIerなど受注側がアサインしたプロジェクトマネージャーは、発注時の要件に合わせてプロジェクトを進行することになり、「きっとこのプロジェクトは上手くいく。」のように正常化バイアスが働き、危険を察知する感度が低くなってしまいます。「本当に大丈夫なのだろうか？」、「各機能の進捗は問題ないか？」というような第三者視点で、開発現場のリソースや進捗状況の詳細を把握することで、早期に問題を察知することができるのです。

そして最も大事なことは、上流工程においてクライアント自身が気付かない課題を早期に発見することが、後工程で発生する問題を回避することに繋がるのです。同じ視点でゴールに向かうパートナーになることで、問題が発生しても建設的な質の高い議論のなかから妥協策を見つけ、残りの作業に対しても前向きに取り組むことができるようになるのです。

このように、クライアント側と受注側のギャップを埋めることができる、中立的な立場のコンサルタントを、RFPを作る前にプロジェクト体制に入れることで、本質的な課題を見据えクライアントと同じ視点で解決策を模索することができます。そして、プロジェクトをマネージメントする立場として参加させることで、リスクを回避しながら、プロジェクトを成功させることができるのです。