PMOはスクラムマスターである

PMOの役割とは一体何だろうか。長年PMOとして働く中で、その役割は環境や案件により大きく変わると感じてきた。単なる進捗管理の事務局から、全社の品質を担保する絶大な権力を持つ立場まで、その姿は様々だ。

しかし、ルールという法律を作り、管理と統制でチームを縛ることは、本当にプロジェクトを成功へ導くのだろうか。本記事では、PMOが陥りやすい「権力による支配」の構造を振り返りつつ、本来あるべき「スクラムマスター」としての支援的役割の重要性について紐解いていく。マイクロマネジメントを捨て、チームを信じて自律を促す「真のPMOの姿」をともに探求しよう。

【参考】
ＰＭＯ導入フレームワーク　～プロジェクトを成功に導く、人・組織・プロセス・ツール～ | 高橋 信也, 峯本 展夫 |本 | 通販 | Amazon

図解まるわかり PMO・PMのきほん | 西村 泰洋, 相川 正昭 |本 | 通販 | Amazon

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

【1】そもそも、PMOとはどんな役割を持つ人なのか？

PMOという職種の仕事についてもう8年くらいになる。
PMOになって仕事すると不思議な感覚になる。
PMOの役割が、会社によって、環境によって、案件によって、変わってくるからだ。

【2】当初は、PMOはある一つの大規模案件にて、プロマネの代わりに進捗管理や課題管理をしたり、経営層向け月次報告を作ったりする事務局的だった。
あくまでの、管理作業のお手伝いであり、開発チームに指示する権限はない。
リーダーやメンバーは自分の作業で忙しいのに、管理作業に必要な情報を作る事務作業はやりたがらない。
しかし、プロマネから委託されている立場により、開発チームのリーダーやメンバーに、必要な情報を出せと強制する権力を持っている。
当然、嫌がられやすい。

【3】次に、PMOとは、社内の全案件のゲートレビューに関する事務局だった。
だから、PMOは所詮、ゲートレビューのファシリテーションと議事録の作成、展開をやるに過ぎない。
大した仕事では無さそうに見える。
しかし、PMOは強力な権限を持つ。

ゲートレビューであるからには、PMOが、この案件は品質が悪いので次工程に進められない、特にリリース判定会議ではリリースに必要な品質を担保されていないのでリリース不可だ、と言えば、案件はストップさせられる。
案件のプロマネからすれば、顧客の契約を守れないからありえない事態だ。
しかし、プロマネはPMOと喧嘩しても、PMOからネチネチと突っ込まれる指摘に説明責任があるから、立場は弱い。
よって、プロマネは、PMOの言いなりにならざるを得ない。
1億円以上の案件であれば、プロマネは中間管理職相当なのに、PMO事務局というヒラの社員にペコペコするしかないのだ。

【4】さらに、PMOはゲートレビュー事務局がベースなので、全社の品質管理、さらには標準化推進する事務局を担当する役割を持つ。
大手のSIerであっても大規模案件のQCD管理に手こずっているので、ソフトウェア開発の品質保証の役割で、社内の全案件に対し、品質を担保せよと号令をかける。
号令だけでは弱いので、標準化という名のもとに、PMOは自ら社内案件を縛る法律を作り、自ら作った法律を社内案件全てのリーダーやメンバーに対し、強制させる。
PMOはそれだけの強い力を持つ。
リーダーやメンバーが反発しても、PMOは経営陣のお墨付きを得ているというバックを元に、彼らを従わせる権力を持っている。

【5】しかし、本来のPMOの役割は、スクラムマスターであるべきだと考える。

なぜならば、チームが自律的に動いているならば、PMOはマイクロマネジメントなど不要であり、スクラムマスターのように彼らが抱える組織的課題を解決し、支援する役割になるからだ。

たとえば、チーム自身が日々の進捗・課題管理を自ら運営して解決できて、納期を守り、品質を担保できる状態を維持できるならば、PMOがわざわざマイクロマネジメントする必要すらない。
そもそも、PMOが自ら法律を作ってマイクロマネジメントをチームに課すことは、チームを方任ずれば野放図に動くので、チームを信頼できない、という結果を招くだろう。

よって、PMOのあるべき姿は、当初はチームを指導したりコーチングして彼らの能力を引き出したり、動機付けたりするだろうが、最終的には、彼らの能力を信頼して委任する状態になるだろう。
その姿はまさにスクラムマスターと同じだ。