私のキャリアの中に、数年ですがPMO(Project Management Office)的な経験があります。
＃PMOの役割や定義も組織においてまちまちなのですが…。
当時はそういう組織がなかったので、ホント何でも屋的に色々やっていました。
その時の経験から出た思いは「現場がスムーズに(かつ楽しくできれば尚良し)仕事をできるように環境を作り、PJのQCD(メンバーの満足感も含む)を成功させること」です。
他のエントリにも色々書いていますが、ベースはいかに「みんなの生産性を高めることができるか」だと思っています。
コミュニケーションの土壌を作るために、キックオフ宴会やランチMTGをしたり。
＃最近では、「飲みニケーション」に否定的な風潮もあったりしますが、やりようによっては素晴らしい関係を築くきっかけになると思います。
設計、開発、テストなど各工程をスムーズに進め、メンバーが無駄なパワーを使わないで済むために、バージョン管理やBTSなどのインフラ周りの構築やその利用ガイドの策定もしたり。
(小さなPJの場合ですが)できるだけ横串で仕様を理解して、個別最適になりがちな設計を全体視点からフォローしたり。
時には(あまりあって欲しく無いですが)、現場を知らないPM、管理部、(あまり理解の無い)上司から「このPJについてどうなっているか報告しろ」という、PJの成功とは全く関係のないタスクからチームの消耗を防いだりもしました。
一方、ある現場で見たPMOは、品質指標や課題件数、その進捗を過剰なまでに詳細に分析して、見栄えの良い円グラフや折れ線グラフにして、PJルームに張り出す…なんて方もいました。
「見える化」では、そういうのも大事ですが、それで終わるんじゃなく、踏み込んでの「こうしてはどうだろう？」とPJを進める/改善する/(トラブルを)防止するアクションが必要かと思います。
＃そんなのに限って「分析したところ遅れています。原因分析と対策を報告してください」なんてメールを多忙な現場PLに投げたりします。
最近はPMO的な仕事から離れていますが(あまりうちの会社にそういう役割はないみたいで…)、反面教師にしないとなぁと思ったので備忘録として書いておきます。
※注意：この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。
コメント