PMOが機能しないシステム開発プロジェクトはデスマーチまっしぐら

「PMOが機能しないプロジェクトは失敗する」ということはIT業界ではよく知られていますが、その割に、「機能していないPMO」は世の中に溢れています。なぜでしょうか？

おさらいですが、ある程度の規模のシステム開発プロジェクトになると、必ずPMO（プロジェクト・マネジメント・オフィス）を配置します。PMOは「全体管理チーム」という言葉で表現されることも多く、プロジェクト全体の進捗・課題・リスクを管理し、問題解消を促すことがその役割です。

このことをプロジェクトメンバー全員が正しく理解していないと、そのプロジェクトはデスマーチ（不眠不休の長時間労働状態）を突き進むことになります。たとえば、次のような認識齟齬があるプロジェクトは、デスマーチまっしぐらの典型です。

【ケース１：検討漏れが発覚してデスマーチへGO】
PMOメンバー
「自分たちは進捗・課題・リスク管理とプロジェクト外への報告書を作るだけ」
他チームメンバー
「PMOは領域横断課題を取り上げて解決支援もしてくれる」

【ケース２：PMOに作業が集中してボトルネックとなりデスマーチへGO】
PMOメンバー
「自分たちは進捗・課題・リスク管理とプロジェクト外への報告書を作る」
「チームに跨る横断案件は全部自分たちが預かって判断する」
他チームメンバー
「困ったらPMOにエスカレーションすれば、そこで判断してもらえる」

つまり、最低限しかやらないPMOにあらぬ期待を抱いているプロジェクト、なんでもレビューしないと気が済まないPMOを抱えているところは失敗プロジェクトであり、機能していないPMOを抱えているということです。やらなすぎもやりすぎも良くありません。

ケース２については、「十分な数のPMOがいれば問題ないのでは？」との疑問を持った人がいるかと思います。横断案件を仕分けするだけなら単純作業者のマンパワー投入で済むかもしれないと考えるかもしれませんが、仕分けて判断するためには業務内容をある程度理解している人が担当しなければ難しいでしょう。

しかし、そういう人材をPMOに置いておくくらいなら、各業務チームに配置して仕事をしてもらった方が生産的です。そもそも、そのような戦力に余裕のあるプロジェクトはありませんから、現場からすれば、絵に描いた餅です。

では、最適なPMOとは、�@どういう役割を担う組織で、�A数はどれくらい必要になるのでしょうか。

�@については冒頭で述べたことがそのまま答えになります。「プロジェクト全体の進捗・課題・リスクを管理し、問題解消を促すこと」です。重要なのは、PMOに割り当てられた工数で対処できるよう、横断的な問題の解消ルールがプロジェクト全体で合意できており、各チームの業務分掌がはっきりとしている状態を保つことです。

結局、どれくらいの工数をPMOに割り当てるかに帰結します。プロジェクト全体に対するPMOの要員数割合は、経験則からプロジェクト全体の10％程度と言われることがありますが、プロジェクトの性質・状態によって幅が出ます。私や周囲のベテランPMの見解では、以下の割合がベースになるように思えます。

●横断課題が比較的多発しそうな時期（要件定義・基本設計）
PMO：全体の10％〜20％
100人の社員・ベンダーを管理下に場合、PMOは10〜20人配置
※工数を高める要因：
管理ルールの内部徹底、横断課題の仕分け、各チームへの働きかけ

●それ以外の時期（詳細設計、結合テスト、総合テスト）
PMO：全体の7％〜15％
100人の社員・ベンダーを管理下に場合、PMOは7〜15人配置

％の下限はプロジェクトの参画人数が150人を超えるケース、上限は参画人数30人以下の小規模ケースでの要員割合を想定しています。プロジェクトメンバーが多くなるほど、PMO一人あたりの担当数が増えるイメージです。

また、プロジェクトメンバーの全体数は、PMOが直接管理することになるユーザー、ベンダーの要員数を意図しています。ただし、ユーザーやベンダーの中に専任のサブPMOがいるなら、その領域の要員数は全体数に含めずに考えます。アウトソーシングベンダーが20人のサブPMOと200人のPJメンバーを抱えているなら、サブPMOが役割を果たす限り、上位PMOの作業量はそれほど変わらないと考えるからです。

※サブPMOの工数に大きな不足はないという乱暴な前提を置いています

たとえば、社員50人、ベンダー200人、うちアウトソーシングベンダー100人（自分たちの領域についてプロジェクト管理は実施されていく）というケースで要件定義を実施するなら、

｛50人＋（200人-100人）｝×10％＝15人。

この15人がPMO要員数の素案です。配置の仕方としては、各チームに1名ずつチーム進捗管理要員を置き、残った人数を専任PMOとしてチーム化します。5つのアプリチーム、1つのアーキチーム、2つの試験チームがあるなら、それで6人カウントし、残りの9名でプロジェクト管理を行います。

社員10人、ベンダー20人で試験をするなら、

（10人＋20人）×15％＝4人

アプリチームが2つ、アーキチームが1つとして、テストフェーズなので各チームは兼務レベルの課題管理要員を置いてもらいます。その代わりにPMO要員の4人が集中管理をしていきます。

だいたいこれくらいの数がPMO要員数を議論するスタート地点になるでしょうか。あとは、プロジェクトの複雑性を加味して、鉛筆を舐めながらさじ加減を決める世界でしょう。accenture、IBM、NTTデータなどの超大規模なSI企業は要員見積りの方法論を持っていますが、ツールを叩いて出てきた数字について、検証せずにそのまま使っているところはありません。

ということで、長くなりましたが、「その役割に対する認識がプロジェクト内で齟齬が無い」ことと、「プロジェクト要員数の7〜20％くらいの範囲を素案とした工数検証」の両方が揃って、ようやくまともなPMOが動き出すという話でした。

私自身振り返ってみて思いますが、これができていないプロジェクト、相当たくさんありますね。できない理由は、予算制約や関係者の無理解など、外的要因によるものが多いと感じます。PMOがやることは戦術であり、PMOの役割・体制・工数を決めるのは戦略です。こういう状況を思うと、銀河英雄伝説でヤン・ウェンリーが語った名言が頭に浮かびます。

「５分と５分の条件を揃えるのが戦略だ 戦略を無視して戦術を論ずるなど、実際の戦争ではありえないことだ」

デスマーチに突入するプロジェクトは、たいてい戦略を無視した戦術を論じているところです・・・