見出し画像

PMO論――20年経って、結局何だったのか


1.PMOが浸透して20年、何が変わったのか

PMO(Project Management Office)という言葉が日本のIT業界に浸透し始めて、もう20年近くになる。
2000年代初頭、みずほ銀行の統合障害やシステム開発プロジェクトの大型失敗が相次いだ時期、「プロジェクトを管理する専門部隊が必要だ」という機運が高まった。そこで登場したのがPMOだ。

当初、PMOは華々しく登場した。大手SIerやコンサルファームが「プロジェクト成功の鍵はPMOにある」と謳い、PMO要員の育成に力を入れた。
Excel方眼紙を駆使した進捗管理表、WBSの精緻化、課題管理票のメンテナンス。PMOはプロジェクトの「見える化」を推進し、炎上を未然に防ぐ存在として期待された。

しかし、20年経った今、現場ではこんな声が聞こえる。

「PMOって、結局Excel更新してるだけだよね」
「会議の議事録係じゃん」
「PMOがいても炎上するときは炎上する」

一方で、優秀なPMOがいるプロジェクトは、確かに違う。
進捗の把握が早く、問題の芽を事前に潰し、意思決定がスムーズに進む。
では、何が違うのか。

2.PMO要不要論――存在意義が問われ続ける理由

PMOに対する評価は、今も二極化している。

「PMOは不要」という意見の多くは、こう続く。
「結局、進捗管理表を更新するだけで、何も判断しない。プロジェクトマネージャーがしっかりしていれば、PMOなんていらない」

確かに、PMOが単なる「作業代行者」になっているケースは多い。
会議のセッティング、議事録の作成、Excelの更新。
これらは確かに必要な作業だが、PMOの本質ではない。こういうPMOが量産された結果、「PMO=雑用係」というイメージが定着してしまった。

「お前は、数多いるPMOと何が違うの?アサインする価値あるの?」
面談で尋ねられたことはある。

一方で、「PMOは必要」と断言する人もいる。
彼らが言うのは、「プロジェクトマネージャーは目の前の問題に追われて、全体を俯瞰する余裕がない。その視点を補完するのがPMOだ」ということだ。

ここで重要なのは、PMOの役割が「作業支援」なのか「判断支援」なのか、という点だ。前者であれば、確かに不要論が成り立つ。
しかし後者であれば、PMOは不可欠な存在になる。

3.技術職を経験した者のPMO――現場への理解と限界

技術者出身のPMOは、強みと弱みがはっきりしている。

強みは、現場の言葉が分かることだ。
「ここの実装、思ったより工数かかりそうです」と開発者が言ったとき、技術者出身のPMOは、その裏にある技術的課題を察知できる。
「これ、設計が甘かったんじゃないか?」
「ライブラリの選定ミスか?」
と仮説を立て、早めに手を打てる。

一方で、弱みもある。
技術に詳しいがゆえに、細部に入り込みすぎてしまうのだ。
「このコードのここが気になる」
「このアーキテクチャは将来的に問題が出る」
と、ミクロな視点に引っ張られ、マクロな視点――プロジェクト全体のリスクや、ステークホルダーとの調整――が疎かになる。

技術者出身のPMOに必要なのは、
「技術を分かった上で、あえて手を出さない」という抑制だ。
技術的な議論に深入りせず、
「この技術課題は、プロジェクト全体のスケジュールにどう影響するのか」という視点に立ち返る力が求められる。

4.技術職でない者のPMO――言葉の翻訳者としての役割

一方、技術職を経験していないPMOもいる。こちらは逆に、技術的な細部に入り込めないという弱みを抱えている。

「APIって何ですか?」
「この遅延、どのくらい深刻なんですか?」
――技術に疎いPMOは、開発者から煙たがられることも多い。しかし、優秀な非技術職PMOは、この弱みを強みに変える。

彼らは「分からない」ことを恥じず、徹底的に質問する。
そして、技術者の言葉を、経営層や顧客が理解できる言葉に「翻訳」する。「このバグ修正には3日かかる」を「リリース予定が3日遅れるリスクがある」に変換し、意思決定者に判断材料を渡す。

非技術職PMOの強みは、マクロな視点を失わないことだ。技術の詳細に引っ張られず、「誰が何を決めるべきか」「このタイミングで何を報告すべきか」という構造を見失わない。

5.マクロの視点とミクロの視点――PMOの本質は「視点の切り替え」

結局、PMOに求められるのは、マクロとミクロを行き来する力だ。

ミクロの視点とは、現場で起きている具体的な問題を把握する力。
「この機能の開発が遅れている」
「このメンバーが疲弊している」
という事実を、早期に察知する。

マクロの視点とは、それがプロジェクト全体にどう影響するかを判断する力。
「この遅延は、リリース全体に影響するのか、それとも限定的か」
「このリスクを、誰に、いつ、どう報告すべきか」
を見極める。

マクロとミクロの視点

技術者出身のPMOは、ミクロは得意だがマクロが苦手。非技術職のPMOは、マクロは得意だがミクロが苦手。どちらも一長一短だ。

しかし、優秀なPMOは、自分の弱みを自覚し、補完する。
技術者出身なら、意識的にマクロに視点を戻す。
非技術職なら、技術者に「これ、どういう意味ですか?」と愚直に聞き続ける。

筆者の経験した「全体統括PMO」は、
毎週50スライド程度の”補助資料”をスピードよく作成し、
プロジェクトオーナー等のステークホルダーに、
A3用紙一枚で、短時間で判断を仰ぐというサイクルで、
意思決定を迅速に、正確にすることをサポートし、
プロジェクトの円滑な運営、進行へと寄与すべく、
必死で働いた

最後に――PMOは「職種」ではなく「視点」だ

20年経って分かったことがある。

PMOは、職種ではない。視点だ。

進捗管理表を更新するだけなら、誰でもできる。
しかし、進捗の裏にある構造的な問題を見抜き、意思決定者に判断材料を渡し、プロジェクトを前に進める――それができるかどうかが、PMOの価値を決める。

技術者出身だろうが、非技術職だろうが、関係ない。マクロとミクロを行き来し、
「今、このプロジェクトに必要な視点は何か」を問い続けられるかどうか。それが、PMOの本質だ。

20年経っても、PMO要不要論は続いている。しかし、問題はPMOという「役割」の有無ではなく、プロジェクトに「視点を切り替える存在」がいるかどうかだ。

肩書きがPMOでなくても構わない。プロジェクトマネージャーでも、リーダーでも、時にはメンバーでもいい。誰かが、マクロとミクロを行き来し、判断の軸を示す。それができていれば、プロジェクトは前に進む。

PMOとは、結局のところ、「考える装置」なのだ。


次はこちら!

【 固定リンク 】
プロジェクトマネジメントは、言葉でできている


いいなと思ったら応援しよう!