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

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

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

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

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

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

そして最も大事なことは、上流工程においてクライアント自身が気付かない課題を早期に発見することが、後工程で発生する問題を回避することに繋がるのです。・・・

>>>このストーリーの続きは以下のURLからご覧いただけます！

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