システム構築をしている人である程度の大規模プロジェクトに参画している人であれば体制図にPMO（Project Management Office）と言うポジションがある場合が多いのではないでしょうか？僕が会社に入った頃にはこのような言葉はなくて「事務局」と言う風に呼ばれていました。
当時の事務局ってのは、会議のスケジューリング調整をしたり、チーム間の連携（と言っても共通フォーマットを各チームに展開する）を取るなどの仕事をしていました。特別なスキルは要求されていなかった時代です。
でも、プロジェクトが大きくなればなるほど、PMOは事務局と言う意味よりも、チーム間を横串と通して管理し、一貫性・整合性を保つような業務となってきます。
僕が思う、”上手くいくプロジェクト”って言うのは「PMOに優秀な人材を置いている」プロジェクトなんですよね。本当に、チームリーダー以上、プロジェクトマネージャ未満位のスキルと知識がある人材がPMOに入っているプロジェクトは経験上上手く行きます。
逆に、「事務局」的な感じのまま真面目に働いてくれればそれで良いと言う感じの人材を置くとそのプロジェクトは失敗します。理由はプロジェクトをまとめきれないんです。原因はいくつかあると思いますが、”スキル不足”が大きいと思います。
PMOは頑張っていますが、失敗するPMOの場合はPMの要求を上手くチームに展開できずに”作業するだけ”になりがちなのですよ。「PMから言われているので」ってのはわかるんですがそれ以上の意味をちゃんと理解していない場合って結構あります。その結果「PMOのせい」とされてしまい各チームからの遅延の対象として槍玉に挙げられます。そういう時はチーム間は仲良く共通の敵（PMO）を作るんです。タバコ部屋での会話で耳にタコができる位そう言う会話（「PMOが何言ってるかわかんないんだよ！」みたいなニュアンス）を聞いてきました。
なので、僕はPMOにはPMに訴求力がある位のスキルがある人がふさわしいと思います。ある程度年齢がいっていても関係ありません。逆に若いと舐められます。場合によっては若手にPMの経験をさせる場合に自分がPMOとして参画することによってリスクコントロールできる場合があると思います。
PMが介入するまでもなく、PMOがチーム間の調整を行い、整合性をとり結果をPMに報告できる。経験則ですがその位のPMOがいるプロジェクトは大抵成功しています。
またチームリーダーの中でできる人がそうPMOの”役割”を兼任することもあります。PMOが設置されていても、です。そう言う場合の体制図上のPMOは機能をなしていないことになります。PMとしてはメンバーチェンジするかExcel管理などの本当の「資料管理」に回ってもらった方が良いでしょう。
仕事を上手く回すたった一つのコツは”根回し”です。根回しを是としない意見も多く聞きます。確かにわからない事はないです。実に日本的な感じもしますしね。
でも、全てのステークホルダー（利害関係者）に根回しできる人間は重宝されるのです。会議は”検討の場”から”確認の場”に移ります。無駄な会議はしない。ただ、”合意をとる”為の会議。なので、時間が超過したり次回に延期になる事はありません。勿論根回しだけでは合意を取れない場面はあります。その時こそ議題を提示してその問題に対して各人が意見を言い合うべきです。本来の意味での”会議”ですね。そう言う場合でもアジェンダを整理し会議前に展開しておく……など、優秀なPMOはきちんとそう言う作業をします。
昔、僕がチームリーダーをしていたプロジェクトでは週例（週間報告会）の前日にお客様と「明日、こう言う事を話します。何か問題はありますか？」と事前に会話しておきました。その際にお客様が「○○さんがなんて言うかな？」なんて言う話が出てきたらしめたもの、事前に回答を準備しておきます。
他のチームのぐだぐだとかもあって結果的に週例は長い時間になりましたが、僕のチームの報告は定刻で納めていました。
後日、飲みの席で他のチームのお客様から「波秋さんは、根回しがうまいね」と言われたものです。これは良い意味で捉えて本当にうれしかったです。
エンジニアって上司に評価されるより、お客様に評価される方が何百倍も嬉しいんですよ。勿論給与が絡んでくるので複雑ですけれど上司に褒められても給料上がらなかったら意味ねーって言うか……。お客様からの評価は給与に直結しなくても「仕方ないよね」って思えますから。
これを読んでいるシステムエンジニアの人はPMの立場だったり設計だったり……色々な立場の人がいると思います。
もう一度、あなたのプロジェクトでPMOがどのように機能しているか、よく考えてみてもらえると幸いです。
