「PMO」という言葉に振り回されないために
近年IT業界ですっかり定着した言葉の一つに「PMO」がある。
「プロジェクトマネジメントオフィス」の頭文字をとったものだ。
この「PMO」という言葉は指す範囲が広すぎるため、一体どういう種別のPMOなのかを明確にして会話しないと全く話が噛み合わない。
また、同じ理由で「PMO経験あり」という要員に対する期待値もギャップが生まれやすい。
私自身も仕事上悩みの種でもあるので、これを機に簡単に整理してみようと思う。
プロジェクト単位か？プロジェクト横断か？
まずは単体のプロジェクトに対するPMOなのか、それとも複数のプロジェクトを横断的に見るPMOなのかといった違いがある。
前者は個別のプロジェクトの中にチームとして設置される。
当然目指すのは個別プロジェクトの成功だ。
後者の場合は会社の中に一つの部署として存在するイメージで、全社的にプロジェクトの最適化を目指す。プロジェクトによって管理方法や品質のばらつきが発生しないようにするといった活動を行うわけだ。
私個人としても、メンバ育成の観点でも、身近な話題となりやすいのが前者の「プロジェクト単位のPMO」だ。
プロジェクトの要員募集で「PMO経験者希望」などのスキル要求が指しているのもこちらであることがほとんどだ。
よって後段では「プロジェクト単位のPMO」についてさらに細分化していく。
PMの権限に近い順に「指揮型」→「管理型」→「支援型」
本記事を書くにあたり、複数のPMOについて言及しているWebサイトを参考にさせていただいた。（サイトは記事の最後にまとめて紹介する）
どれもとても詳しく書いてあるのだが、ざっくり理解するためにはこの
PMの権限に近い順に「指揮型」→「管理型」→「支援型」
というフレームで十分だと思った。
まず前提として、PMOの仕事は本来プロジェクトマネージャー(PM)が全て行うはずのものである。今でも小さいプロジェクトであればPMがやっているはずだ。ただ、大きなプロジェクトになってくるとPMの手が回らなくなってくる。そうなるとサブPMだったり、若手メンバだったり、他のメンバに代わりにやってもらうことになる。ただ、当然他のメンバも自分の本来の役割もあるわけで、だったらPMの仕事の一部を担う専門の要員を配置しようというのがPMOの発想だ。
じゃあ、PMOにどこまでPMの仕事に関与してもらうの？というのがポイントになってくる。
そこで関与のレベルを示すのが上述の
「指揮型」→「管理型」→「支援型」
のレベル分けである。
1.指揮型：PMより経験豊富なPMOも
まずは指揮型。
指揮するならその人がPMでは？と思った方もいるだろう。半分くらいは合っている。
ユーザ企業の期待の若手がPMとして抜擢されたが、システム開発PMの経験は浅い。そこに外部のPM経験豊富なITコンサルが指揮型PMOとして参画しているといえばイメージ湧きやすいだろうか。
三国志でいえば諸葛亮孔明がまさにそうだろう。PMは劉備だが、実質的に蜀の国をリードしていたのは孔明だった。
PMO専門のコンサル会社というのも世の中には存在するが、彼らが高単価で請け負うのもこの領域だろう。
2.管理型:プロジェクト進行管理は任せろ！
進捗管理、品質管理、会議体運営、課題管理、スケジュール管理……
大きくなればなるほど工数を取られる各種管理業務を担うのがこの管理型PMO。
プロジェクト立ち上げ時期は特にこれらの管理の枠組みが決まっていない。ゆえに枠組みの構築からその運用、そして改善のサイクルを回していかないとならない。そこを専門家の知見を生かして推進するのがミッションだ。
一例を挙げると、課題管理にはBacklogやJiraといったクラウドサービスを使うのか、それともライセンス費をかけたくなかったりプロジェクトの固有状況に応じてカスタマイズしたいのでExcelVBAで作るのかを決めるのも管理型PMOの仕事だ。当然それらのツールを実際に作ったり運用するスキルも求められる。VBA開発は専任のメンバをアサインしてもよいが、手の動くPMOは自分でやってしまうことも。
※VBAについてはこんな記事も書いているのでよろしければ。
会議体運営では会議室の確保からメンバのスケジュール調整、そして当日のファシリテーションから議事録作成までを任されることがある。
こうなってくるとシステム開発の専門用語はある程度知っている必要があるし、クライアント固有の用語なども早期に覚えてキャッチアップする必要がある。地味だが瞬発力と緻密さが要求される仕事だ。
あくまで進行管理なので、プロジェクトの方向性といった意思決定に関与することはないが、意思決定に必要な情報を正確に吸い上げてPMに渡すのが管理型PMOの重要なミッションの一つである。
3.支援型:プロジェクトの庶務
あえて「庶務」と言い切った。PMOアドミなどと呼ばれることもある。
プロジェクトでは新規参画者のPC手配、入館手続き、経費精算といった雑多なタスクが発生する。これらを単価の高いメンバーが担うのは効率が悪い。そこで支援型PMOの出番である。
本当に単純なマニュアルに沿ったオペレーションのみ担当することもあるし、マニュアルを作成・更新することもある。
また、場合によっては会議体運営まで担うこともあり、その場合は管理型に近づいていると言えるだろう。
あくまで実際に見てきたところだと、この種のポジションにはIT専業ではない派遣会社の要員だったり、ロースキルSES会社の若手女性社員がアサインされていることが多かった。
※このポジションに若手女性がアサインされがちな点については、庶務＝若手女性という価値観が色濃く出ており、時代の流れにはそぐわないとは思うが、実際に見てきた「事実」としてはそうだった。
「PMO経験者」の面談ではどのレベルのPMOだったかを確認
PMO案件は開発系案件に比べると単価が高いことが多い。これは高単価のコンサルティングファームが一次請けになっていることもあるし、実際に求められるスキルセットが高いことも影響している。
当然こういう案件に自社プロパーや協力会社社員・個人事業主を紹介して利益を挙げたいといのが多くの中小コンサルティング会社/SES企業の考えることだ。
ただ、要求スキルセットの詳細が「高いコミュニケーション能力」「一人称で動けること」「指示待ちではなく積極的に当事者意識をもって推進できること」といった曖昧なことも多い。
さらに面倒なことに、要員側のスキルシートにも「PMOとしてプロジェクトマネジメントを推進」といったさっぱり中身がわからない記述も多かったりする。
こうなってくると面談で中身を判断するしかない。
その際には上述の3つのレベルでどこに相当する経験を持っているのかを意識して質問するのが肝要だ。
PMO案件でバリューを出せるパターン／出せないパターン
私の見てきた範囲での話にはなるが、PMO案件でバリューを出せるパターン／出せないパターンを整理してみる。
なお、「支援型」でバリューを出せない人はほとんどいないので、「管理型」「指揮型」についての話となる。
＜バリューを出せるパターン＞
・ユーザ系SIerでプロジェクト管理を担当した経験があり、ベンダ担当部分についても中身をしっかりと理解して任せていた人
・自分の担当範囲外にも目が届く人
・プロジェクト全体を俯瞰的に見られる人
・システム開発プロジェクトでチームリーダー以上の経験がある人
＜バリューを出せないパターン＞
・プロジェクト管理経験ありといいつつ、ほとんどベンダに丸投げしており、中身をほとんど把握していなかった人
・自分の担当範囲しか見えない人
・プロジェクト全体におけるタスクの位置づけを理解できない人（視座が低い人）
・システム開発プロジェクトでいちメンバーの経験しかない人
あくまで私が見た範囲にとどまるのと、記載も網羅的でないため、大して参考にならないかもしれない。ただ、こういった生きた経験に基づく考察を書いている記事があまりなかったため、少しでも役に立てばと思い書いてみた。
参考にさせていただいたサイト
最後に本記事を書くにあたり参考にさせていただいたサイトを紹介する。
併せてご覧いただけると良いと思う。
株式会社 EnMan Corporation様 PMOの種類
この記事が気に入ったらサポートをしてみませんか？