全1984文字
PR

 先日、あるユーザー企業でIT部門に所属する若手から相談を受けた。システム再構築のプロジェクトマネジャー(以下、PM)として任命されたとのこと。調達から開発まで担当する。基幹システムではないが、システムのスコープはそこそこ大きく、若手の初PMの仕事としては手ごわい。

 「ベンダーに丸投げしてはいけないことはよくわかる。しかし、ベンダーのPMはプロジェクト経験豊富で、製品知識も豊富。任せたほうがよいのではと思ってしまう」「過去に部内の先輩のPMを見てきたが、人によってやり方が異なる。失敗して大変な苦労をしたプロジェクトや明らかに丸投げしている案件もあった。だから、自分が何をしたらよいか、いまひとつ整理できていない」と感じているようだ。

 この若手IT部員のケースのように、一般にシステム構築のプロジェクトではユーザーとベンダーの双方がPMを立てる。この2人のPMで立場的に上位なのは発注者のユーザー側のPM(以下、ユーザーPM)である。商業上、お金を支払う顧客であるし、仕様などを最終決定するのもユーザーだからだ。

 しかし、現実にプロジェクトを回すのはベンダー側のPM(以下、ベンダーPM)であることが多い。定例会議などでベンダーPMが進捗管理や課題管理の資料を用意し、状況を説明する。ユーザーPMは基本的にベンダーPMの報告を聞くといった具合だ。

 もちろんベンダーが実際の開発作業を受託しているので、ベンダーPMがそれらの作業を行うの当然であるが、この構図は「丸投げ」を生みやすい。相手のベンダーPMが経験豊富ならなおさら任せたくなる気持ちもわからないではない。

 それでもやはり、ユーザーPMは自社の代表として積極的にプロジェクトに関与すべきである。なぜなら、ベンダーの仕事の範囲=プロジェクト全体ではないからだ。ベンダーが契約に基づいて行う作業はあくまでベンダー側の作業であって、プロジェクトにはユーザー側の作業もたくさんある。特にエンドユーザーとのもろもろの調整や、ユーザー側の意思決定の段取りなどはユーザーPMにしかできない仕事である。

 マスタースケジュールにしてもベンダーPMが書けるのは請けたベンダー作業の範囲であり、プロジェクト全体のマスタースケジュールはユーザーPMが協力しないと書けないはずだ。