PMOとは？役割・業務内容とPMとの違いをわかりやすく解説
PMOという言葉は聞くものの、実際に何をする組織なのかは伝わりにくいところがあります。資料を集めているだけの部署に見えることもあれば、現場を助けていることもある。この差は、PMOにどこまでの権限を与えているかで決まります。この記事では、PMOの役割と業務内容、PMとの違い、そして機能する条件を整理します。
PMOはProject Management Officeの略で、組織内のプロジェクトを横断的に支える部門やチームを指します。個別のプロジェクトを進めるのではなく、進めやすい状態をつくるのが役割です。
具体的には、進め方の標準を決める、複数案件の状況を集めて共有する、共通のツールやテンプレートを整える、といった仕事を担います。
プロジェクトが1つだけなら、PMOは必要ありません。問題になるのは、複数の案件が並行し始めてからです。
案件ごとに進め方が違うと、担当が変わるたびに覚え直しが発生します。報告の形式もばらばらなら、経営層が全体の状況を把握できません。さらに、ある案件で踏んだ失敗を、別の案件でまた繰り返すことになります。
これらは、個々のPMがどれだけ優秀でも解決しません。自分の案件しか見えていないからです。横断して見る役割が別に必要になります。
最も分かりやすい違いは、プロジェクトが失敗したときに誰が説明を求められるかです。
この線引きが曖昧なままPMOを置くと、実務で必ずもめます。PMOが指示を出したのにPMが責任を負う、あるいは双方が相手の決定を待って進まなくなる、といった事態が起きます。
次の3点を文書にしておくと、後の混乱が減ります。
特に3つ目が決まっていないと、対立したときにプロジェクトが止まります。
与える権限の大きさによって、3つの型に分けられます。どれが正解ということはなく、組織の状態に合うものを選びます。
テンプレートや過去事例を提供し、相談に応じる型です。強制力はなく、使うかどうかはPMの判断に任せます。
導入の抵抗が少なく、最初の一歩としては現実的です。ただし、使われなければ意味がないため、提供するものの質が直接問われます。
標準の遵守を求める型です。決められた形式で報告すること、規定の手順を踏むことを条件にします。
案件間のばらつきは抑えられますが、ルールを増やしすぎると現場の手間だけが増えます。定期的にルールを減らす見直しが必要になります。
PMOがプロジェクトを直接管理する型です。PMをPMOが任命し、優先順位や資源配分を決めます。
横断的な最適化がしやすい一方で、PMOに実務を知らない人が入ると現場と乖離します。権限を与えるなら、実務経験のある人を置くことが前提になります。
型によって重心は変わりますが、主な仕事は次のとおりです。
計画の立て方、進捗の表し方、完了の判定基準を揃えます。揃っていないと、集めた数字を並べても比較できません。
とはいえ、最初から網羅的な規則を作る必要はありません。完了の定義と進捗の段階だけを揃えれば、横断して見る土台はできます。
各プロジェクトの状況を集め、経営層が判断できる形にして提示します。ここで問われるのは、集めることではなく削ることです。全案件の詳細を並べた資料は、読まれません。
PMOにしかできない仕事です。同じ外注先に複数の案件が集中している、特定のメンバーに負荷が偏っている、同じ時期に納期が重なっている。これらは個別のPMからは見えません。
共通で使うツールの選定と運用、テンプレートの作成です。案件ごとにPMが自分で揃えていると、同じ作業が何度も発生します。
終わった案件の振り返りを集め、次に渡す仕事です。見積もりの実績値、よく起きるトラブルと対応、外注先の評価。この蓄積がないと、組織としての精度は上がりません。
置いたものの機能していない、というケースには共通した形があります。
最も多い失敗です。毎週PMから進捗を集め、資料にまとめて上に上げる。それだけで終わっていると、現場にとってはPMOは手間を増やす存在にしかなりません。
分かれ目は、集めた情報を使って何かを返しているかです。他案件の実績値を提供する、負荷が偏っていることを伝える、他部署との調整を引き受ける。何か1つでも返せていれば、協力は得られます。
問題が起きるたびにチェック項目を追加していくと、手続きだけが肥大化します。やがて現場は形式的に埋めるだけになり、チェックも機能しなくなります。
ルールを追加するときは、同時に何かを減らす。この原則を決めておくと、肥大化を抑えられます。
現場経験のないメンバーだけでPMOを組むと、提案が実態と合わなくなります。現場からは「分かっていない人が口を出してくる」と受け取られ、協力が得られなくなります。
少なくとも1人は、自社のプロジェクトを回した経験のある人を入れてください。
人数ではなく、並行している案件数で判断します。
目安としては、同時に動いているプロジェクトが5件を超えてきたあたりから、横断して見る役割が必要になります。それ未満なら、マネージャーが兼任で把握できる範囲です。
ただし件数が少なくても、他部署や外部パートナーが多く絡む場合は、調整の負荷が上がるため早めに必要になります。
PMOは、専任の部署でなくても成立します。機能だけを分散させる方法もあります。
組織を立ち上げると人件費が発生し、成果を問われます。まずは機能だけを試して、必要性が確かめられてから組織化する順序が安全です。
情報を整理して、相手に応じた粒度で伝える力が中心です。加えて、現場と経営の両方と話せること。プロジェクトを回した経験があると、提案の現実味が変わります。
見る案件数と、与える権限の大きさで変わります。支援型で数件を見るなら1人でも回りますが、指揮型で多くの案件を抱えるなら相応の人数が必要です。小さく始めて、手が回らなくなってから増やす順序を推奨します。
最初に手間を増やす施策から入ると、ほぼ確実に抵抗されます。逆に、現場が面倒に思っている作業を引き受けるところから入ると、受け入れられやすくなります。報告資料の作成や、他部署との調整などが候補です。
PMOは直接の成果物を持たないため、評価が難しい組織です。実務では、納期遵守率、見積もりの乖離率、報告資料の作成時間といった、導入前後で比べられる数字を先に決めておくと説明がしやすくなります。
PMOの仕事のかなりの部分は、情報を集めて揃える作業に費やされます。案件ごとに管理表の形式が違うと、集計するたびに転記が発生します。
Xtrategyでは、施策のスケジュールと予算・KPIを同一画面で管理し、複数の施策を横断して進捗を確認できます。集める作業が減れば、判断と支援に時間を使えるようになります。
PMOは、置けば機能するものではありません。現場に何を返せているかで価値が決まります。まずは専任組織を作る前に、週に一度案件を並べて見る場をつくるところから始めてみてください。
