PMO（Project Management Office）とは、SIerの大規模プロジェクトにおいて、進捗管理・課題管理・関係者調整などの 「プロジェクト管理業務」を専門に担う役割です。

一方で、SIerの現場で働いていると、 「PMOは結局、何をしているポジションなのか分かりにくい」 と感じたことがある人も多いのではないでしょうか。

この記事では、 SIer2年目の現場社員が、大規模プロジェクトで実際に関わったPMOを見て感じたことをもとに、

  • PMOはどのような役割として配置されているのか
  • なぜ現場から評価が割れやすいのか
  • PMOという仕事が構造的に難しい理由

を整理します。

なお、本記事は特定のPMOや個人を評価・批判するものではありません。 筆者が関わった大規模案件での経験をもとに、 「現場の末端からPMOはどう見えていたのか」 を言語化した記録です。

小規模案件やすべてのPMOに当てはまる話ではありませんが、 PMOと関わる立場にある方、あるいは将来PMOになる可能性のある方にとって、 考える材料になれば幸いです。

PMOとは何をするポジションなのか（現場目線）

一般的にPMOは、プロジェクトマネジメントを支援する立場として説明されることが多いです。

ただ、現場社員の立場から見ると、PMOは「PMやPLが担っている管理業務の一部を引き受けるポジション」 という印象を持つことが多いように感じます。

PMやPLほど意思決定はしないものの、進捗・課題・調整といった管理の実務を支える役割。 少なくとも、開発そのものを直接進める立場ではありません。

SIerの大規模プロジェクトにおける開発体制

自分が関わってきたSIerの大規模プロジェクトでは、 おおよそ以下のような体制を取っていることが多かったです。

  • PM：部長や課長クラス、またはそれに準ずる立場
  • PL：案件全体、あるいは工程・領域ごとのリーダー
  • TL：チームリーダー。工程や領域が少ない場合は、PL一人が担当するが、その工程そのものが大きい場合、PLの下にさらにTLを入れる
  • メンバー（SE）：設計・開発・テストを担当する現場社員
  • PG：二次受け、三次受け以降

案件規模が小さい場合は、PLが設計からリリースまでを一貫して見ることもあります。

しかし規模が大きくなると、管理対象が増え、工程も細分化されるため、「管理だけを専門に行う役割」が必要になってきます。

その文脈で登場するのがPMOです。

なぜPMOが必要になるのか

PMOがアサインされる最大の理由は、 プロジェクト内で管理リソースが不足しているからだと感じています。

進捗管理、課題管理、関係者間の調整などは、誰かが必ずやらなければいけない仕事です。 しかし、それらをすべてPMやPLが抱え込むと、本来注力すべき判断や設計に時間を割けなくなります。

その結果、「管理を専門に担う役割」としてPMOが必要になる、という構造になっているように見えました。

社外PMOだけでなく、社内PMOという形もある

PMOというと、コンサル会社などから派遣される「社外PMO」を思い浮かべる人も多いと思います。

一方で、自分が見てきた範囲では、 他部署から来た年齢の高い社員や、役職のある人がPMO的な立ち位置になるケースもありました。

形式上は社内の人間ですが、役割としては社外PMOとかなり近いものを担っている印象です。 この点で共通しているのは、必ずしも現場の細かい業務やシステムを熟知していなくても、一定レベルで業務が回るという前提があることです。

管理業務は、プロジェクト全体を俯瞰し、情報を整理し、関係者を動かすことが中心になります。 そのため、「現場を知らなくても成立しやすい役割」という側面があるのは事実だと感じています。

現場社員から見えたPMOは、大きく2タイプいた

自分が関わったプロジェクトでは、PMOは大きく2つのタイプに分かれているように見えました。

タイプ1：管理に徹するPMO（進捗・課題管理特化型）

一つ目は、管理業務に徹するタイプのPMOです。

  • 課題管理表の更新・確認
  • 期限が迫っているタスクの洗い出し
  • 会議体の運営や議事録作成

現場の開発内容には深く立ち入らず、「管理を回すこと」に集中します。

正直なところ、このタイプのPMOが「具体的に何をしているのか」は、 現場の末端社員からは見えにくいと感じることが多かったです。

PL層に話を聞いても、「特別に細かい指示を受けているわけではない」 ように見える場面もあり、管理がどこまで機能しているのか分かりにくい、 という印象を持つこともありました。 ただし、これは何もしていない、という意味ではありません。

おそらくこのタイプのPMOは、

  • プロジェクト全体の状況を俯瞰する
  • 破綻しそうなポイントを早めに察知する
  • 問題が顕在化する前に、最低限の手当てを打つ

といった役割を担っているのだと思います。

現場から見ると地味で、成果が見えにくい一方で、大規模プロジェクトでは このタイプのPMOがいることで、最低限プロジェクトが破綻しない、 という側面があるのだと思われます。

タイプ2：現場に入り込むPMO（課題発見・先回り型）

もう一つは、現場に踏み込み、理解しようとするPMOです。

  • システム構成や処理内容を把握しようとする
  • インフラや設計にも関心を持つ
  • 課題を自分で見つけ、早めに潰そうとする

このタイプのPMOは、PLやメンバーとの距離が近く、 「一緒にプロジェクトを回している感覚」がありました。

一見すると、このタイプの方が現場から好かれそうに見えるかもしれません。 正直に言うと、自分自身もタイプ1しか知らなかった頃は、 「タイプ2のようなPMOだったら良いのに」と思っていました。

ただ、実際に関わってみると、必ずしもそう単純な話ではありませんでした。

タイプ2のPMOは、課題を早めに潰すために、PMやPLだけでなく、 必要に応じて現場メンバーや二次受けのリーダー層にも 積極的にヒアリングを行います。 これはPMOとしては自然な動きですが、 プロジェクトの状況によっては、各メンバーの稼働を削ることにもつながります。

管理を入れることで、一人ひとりの作業効率は下がる。 しかしその代わりに、プロジェクト全体の状況が「見える化」される。 大規模プロジェクトでは、このトレードオフはある程度受け入れられている、 というのが自分の理解です。

また、これまで暗黙的に回っていた部分を明文化し、 責任範囲を整理しようとすることで、 現場が一時的に動きにくくなる場面もありました。 結果として、短期的には進捗が遅れるように見えることもあります。

こうした点から、タイプ2のPMOは「正しいことをしている」一方で、 現場との摩擦が生まれやすい立場でもあると感じました。 一見すると現場に歓迎されそうなタイプですが、 実際にはそう単純ではない、というのが正直な感想です。

とはいえ、タイプ1のPMOが現場から特別好かれるかというと、 それもまた別の話ではありますが。笑

PMOという仕事が「難しい」と感じる理由

ここまでPMOを2つのタイプに分けて整理してきましたが、 そもそもPMOという仕事自体が、かなり難易度の高い役割だと感じています。

まず、新人や若手がPMOとしてアサインされるケースを考えてみると、 そもそも「現場とはどういうものか」という感覚を まだ十分に掴めていないことが多いと思います。

現場経験が浅い段階では、

  • どこが危険なのか
  • どの課題が将来炎上につながりやすいのか
  • 今は口を出すべきか、静観すべきか

といった判断を、感覚的に掴むのは難しいです。

その結果、PMOとしては「管理業務に徹する」という動きになりやすい。 これは能力の問題というより、構造的にそうならざるを得ない面があると感じています。

一方で、現場経験が豊富なPMOであっても、別の難しさがあるように思います。 特に炎上気味のプロジェクトでは、PMOがどれだけ「こうした方が良い」と思っても、 現場がそれを受け入れられる状況ではないことが多いです。

「仕組みを変えた方が良いのは分かっている。」
「でも、変えて定着させるまでの工数が重すぎる。」
「今はそれどころではない。」

現場側にいた経験があると、そう思ってしまう気持ちも理解できます。 結果として、正論を言っても動かせない、 やればやるほど虚しさを感じる、という状態に陥りやすいのがPMOという立場だと感じました。

では、PMO自身が作業に深く入り込めば良いのかというと、それもまた違います。 作業をし始めると、PMOではなく「一作業者」になってしまい、本来の役割から外れてしまう。 どこまで踏み込み、どこで線を引くのか。 このバランスを取り続けるのは、かなり難しい仕事です。

さらに、特に社外PMOの場合は、「雇われている立場」として 何らかの価値を出すことを期待されやすい。

しかし実際には、権限もなく、直接人を動かせるわけでもない中で、成果を示す必要があります。 その結果、資料や管理物を整える方向に寄ってしまうのも、一種の生存戦略なのかもしれません。 こうした点を踏まえると、PMOという仕事は、単純に良い・悪いで評価できるものではなく、 構造的に難しさを抱えた役割なのだと感じています。

どちらが正解、という話ではない

もちろん、どちらのPMOが正しい、という単純な話ではありません。

  • プロジェクトの規模
  • フェーズ
  • 現場の成熟度

によって、求められるPMO像は変わります。 管理に特化したPMOが必要な場面もあれば、現場に入り込むPMOが力を発揮する場面もあります。

重要なのは、そのPMOに何が期待されているのかが明確になっているか
なのだと思います。

SIer2年目の現場社員として感じたこと

PMOが入るからといって、必ずしも現場が楽になるわけではありません。

一方で、理解しようとする姿勢を持ったPMOがいると、 現場としては安心感が生まれるのも事実です。 自分自身も、将来どの立場でプロジェクトに関わるのかを考える中で、 PMOという役割を意識するようになりました。

まとめ：PMOは「どう見えるか」で評価が分かれる

PMOという役割は、

  • 成果が見えにくい
  • 評価が割れやすい

という、非常に難しい立場です。

この記事も、あくまで 現場の末端から見たときに、PMOはこう見えていた という記録です。

PMOという役割をどう捉えるかは、自分が今どの立場にいるかによって変わるのかもしれません。 これからPMOと関わる人、あるいは将来PMOになるかもしれない人にとって、何か考えるきっかけになれば幸いです。