このところ、スケジュール通りにプロジェクトが進まず、遅延が発生して困っているという相談をいくつか受けた。それぞれの案件を調査してみると、状況や遅延の原因はさまざま。このままの体制ややり方ではプロジェクトが確実に頓挫してしまう深刻なものもあれば、ユーザーとベンダーのコミュニケーションの取り方を工夫すれば改善できそうな軽いものもあった。

 プロジェクトがうまく進まない原因は、主にベンダーの力量不足による場合もあれば、発注者側のベンダーコントロールが稚拙だったり、声の大きなエンドユーザーの追加要求を抑えられなかったりといった原因もある。もちろん、多くの場合はどちらか一方ではなく、ベンダーとユーザーの双方に問題がある。

 シビアな状況を打開するには発注者が覚悟を持って主体的に取り組み、場合によっては身を切る判断をしなければ問題解決はできない。たとえベンダー側に問題があったとしても、問題解決の主役は発注者である。むしろベンダー側の問題が大きければ大きいほど、発注者の思い切った決断が必要となる。なぜならば、ベンダー側に解決能力が無いからこそ、大きな問題となるからだ。

有能なプロマネがいないから無能なプロマネをアサイン

 ベンダー側の問題の代表例として、プロジェクトマネジャーが無能な場合がある。無能なプロジェクトマネジャーにいくらマネジメントの改善を求めても無駄である。また、ベンダー側も有能な人が少ないから無能なプロジェクトマネジャーをアサインしている。だからプロジェクトが遅延してもベンダー側から「プロマネを交代させましょう」と言ってくることはない。もし交代を望むなら発注者がベンダーの上層部に強く要求するしかない。要求が受け入れられない場合は、プロジェクト中止も選択肢とするくらいの覚悟を持って交渉すべきである。

 別のケースも紹介しよう。ベンダーの総合テストが終了し、ユーザー側で受け入れテストを行うことになった。しかしベンダーが総合テストで確認済みとしている機能をユーザーがテストしたら、いくつも不具合が生じた。それをベンダーに報告して修正してもらっても、また別の不具合が見つかる。まさにモグラ叩き状態となった。こうなると、テストスケジュールは大幅に遅れ、受け入れテストに協力するエンドユーザーの不満も増大する。

 この場合もベンダー任せだと、ベンダーSEは自社オフィスにいて、管理表をメールなどでやり取りしながらデバックする方法を取るだろう。平時ならそれでもよい。しかし、モグラ叩き状態となったらこれではダメだ。ベンダーSEとユーザーが一つの部屋で数日~数週間缶詰めになって集中的に対処すべきである。そのために発注者は部屋を用意し、エンドユーザーの時間を割き、ベンダーに強く申し出る。

 缶詰めでやるのは根性論ではない。コミュニケーションの問題である。同じ環境で同じ時間に不具合を両者が確認する。そしてどう解決するかその場で話し合う。業務に影響の少ない不具合であれば、そのまま放置という選択もあろう。いずれにしろ、発注者が覚悟を決めて、大胆な決断をして強く申し出ないと、ベンダーは動かない。