PMOに向いていない人とは？「いると疲れるPMO」と「助かるPMO」の違い

「PMOって、いる意味あるの？」「PMOはいらない」。プロジェクトの現場では、こうした声を耳にすることがあります。検索でも「PMO 向いていない人」「PMO 意味ない」「PMO 嫌われる」といった言葉が並びます。

以前、X（旧Twitter）でこんな対比を投稿しました。ついていくと疲れるPMOは「課題管理表を更新する」「議事録を配る」。ついていくと助かるPMOは「困りごとを先回りして見つける」「トラブルの芽を摘む」。短い投稿でしたが、多くの方に読まれ、ブックマークもいただきました。思い当たる方が多かったのだと思います。

アクセンチュアで12年、数百人規模のプロジェクトでPMOをしてきて思うのは、PMOに向いているかどうかは、性格や頭の良さよりも「何を自分の仕事だと思っているか」で決まる、ということです。この記事では、PMOに向いていない人がはまりやすい3つの思い込みと、「いると助かるPMO」が実際にやっていること、そして開発経験がPMOでどう活きるかをまとめます。

「PMOはいらない」と言われる現場で起きていること

「結局、PMOって何やってるの？」と言われたことがあります。会議に出る。管理表を更新する。進捗を確認する。それだけなら、傍から見ると「何もしないスケジュール管理人」に見えても仕方がありません。

極端な話、プロジェクトマネジメントは、何もしなくても仕事をしたことにできてしまう仕事です。たとえば10人でシステム開発を進めていて、PMOが「予算をオーバーしていて、納期に間に合いません。以上です」と報告したとします。状況はまとめているので、一応仕事をしているように見えますし、本人も仕事をした気になってしまいます。

でも、本当に必要なのはその先です。「予算オーバーと納期遅れをどうするか」を考え、アウトになっているものをセーフの側に持っていく。あるいは「このタイミングでセーフにできる」と関係者に納得してもらう。そこまでやって、はじめてマネジメントです。

現場で「PMOはいらない」と言われるとき、多くはPMOという役割そのものではなく、状況を報告するところで止まっているPMOに向けられた言葉なのだと思います。

PMOに向いていない人がはまる3つの思い込み

向いていないと言われがちな人には、共通する思い込みがあります。どれも、まじめな人ほど陥りやすいものです。

① 管理表を整えることが仕事だと思っている

誤解のないように言うと、管理表の更新や議事録は大切です。タスクの進捗率をきちんと記入する、終わったら終了にする。こうした細部を「これくらいはいいか」と流すと、悪い習慣として定着し、あとで収拾がつかなくなります。細部まで管理を行き届かせるのは、PMOの基本です。

問題は、それが目的になってしまうことです。管理表は、どこで困りごとが起きているかを見つけるための道具です。表がきれいに更新されていても、遅れの理由や、誰が困っているのかに目が向いていなければ、プロジェクトは前に進みません。

② 嫌われないことを優先してしまう

PMOを長くやってきて思うのは、「嫌われないこと」より「止めないこと」の方が大事だということです。遅れているなら確認する。曖昧なら「誰が決めるんですか？」と聞く。誰も拾わない論点を拾う。

全員に好かれようとすると、言うべきことが言えなくなります。人間は感情の生き物なので、嫌われたくないと思うのは自然なことです。ただ、強く言えばいいわけでもありません。「なぜ今これをやる必要があるのか」を相手にも納得してもらう。押し切るだけでは長く続かないので、合意を取りながら、必要なときは嫌われる覚悟も持つ。この両方が必要です。

③ 問題が起きてから動けばいいと思っている

「問題が起きていないから、プロジェクトが落ち着いている」というのは、少し違います。落ち着いているプロジェクトには、たいてい先回りしてトラブルの芽を摘んでいる人がいます。

仕様のズレ、認識のズレ、人間関係の違和感。大きな問題になる前に一つひとつ潰しているから、周りからは何も起きていないように見える。火消しの力ももちろん大切ですが、芽のうちに見つけて摘む力は、それと同じくらい、あるいはそれ以上に大切だと思っています。

「いると助かるPMO」がやっていること

では、助かるPMOは何をしているのか。若手のコンサルタントによく話しているのは、プロジェクトマネジメントでいちばん必要なのは「困りごとを見つけて解決する」ことだ、ということです。プロジェクトがゴールに届かないのは、困りごとが解決されないまま期限を迎えるときだからです。

• 困りごとを先に見つける：会議の発言や管理表の数字の裏にある「誰が、何に困っているか」を探す
• 立場の違う声を翻訳する：開発・営業・経営には、それぞれの正義がある。目的は同じなのにぶつかる。その間に入って、互いに伝わる言葉に直す
• 「何を優先するか」「誰が決めるか」の合意を取る：決める人と決めることをはっきりさせ、プロジェクトを止めない
• アウトをセーフに持っていく：遅れや予算超過を報告で終わらせず、どうすれば取り戻せるかを関係者と決める

フレームワークや理論を知っていることも無駄ではありませんが、それが困りごとを解決してくれるとは限りません。解決の糸口が見えないときも、考え抜く、恥を忍んで人に聞く、とにかく動いてみる。その繰り返しで、プロジェクトもPMOも前に進みます。

先回りして芽を摘むために私が大切にしているのは、品質報告に向けて、プロジェクト全体で「何をもって品質が良いと言えるのか」の認識をそろえておくことです。メンバーは一生懸命やっているのに原因分析が足りず、見つかった不具合をモグラ叩きのように直し続けている。そうならないように、工程の途中で、品質評価の観点を前もって擦り合わせておきます。

もう一つは、本番リリースの直前と直後です。この時期は、ふだんはやらない特殊な作業が発生しやすくなります。関係者それぞれが、いつ、どんな作業をするのかを事前に確認しておくことが大切です。

補足：品質評価の観点を前もってそろえる

一般的には、次のような点をテストの計画段階や工程の途中で決めておくと、品質報告のときに「結局、品質は大丈夫なのか」で揉めにくくなります。

• テストの終了条件を先に決める：テストケースの消化率だけでなく、未解決の不具合をどこまで残してよいかも含めて合意しておく
• 量と中身の両方で見る：規模に対するテスト件数（テスト密度）と不具合件数（不具合密度）を見る。目標値は合否を決めるためではなく、極端なズレに気づくための目安として使う
• 不具合を分類して原因を追う：どの機能のどんな処理で出ているか、設計のミスか実装のミスかを分け、似た不具合が他にないかを確かめる。直す前に「なぜ出たか」を見ることが、モグラ叩きを防ぐ
• 不具合の出方の推移を見る：累積の不具合件数がテストの進み具合に対して落ち着いてきているか（収束しているか）を確認する

補足：本番リリースの直前・直後に確認しておくこと

• いつ・誰が・何を・どの順でやるか：当日の作業の流れと体制を、関係者全員が同じ資料で確認する
• リハーサルをする：できれば本番と同じ手順・同じデータ量で一度通し、かかる時間を実際に測っておく
• 元に戻す基準を決めておく：どの状態になったら切り戻すのか、誰が判断するのかを事前に文書にしておく
• リリース直後の確認を割り振る：主要な画面やデータを誰が確認するか、問い合わせを誰が受けるかを決めておく。重要な作業は2名以上でダブルチェックする

参考：@IT「システム開発における『第4コーナー』テスト工程で注意すべきポイント」（ウルシステムズ 前岩浩史、2016年2月）、一創「システム移行とは？移行方式の種類と進め方・失敗を防ぐ判断基準を解説」（2026年7月）、ツクリンク「リリース改善会でリリースフローをとことん改善した」（Zenn、2025年4月）

私が理想だと思っているのは、「マネジメントしないマネジメント」です。誰かが仕様変更を指示したら、受けた人が「その真意はわかっているから、自分の担当ではこうしておくよ」と、会話もチャットもなしに動けていて、PMOが確認しても問題がない。そんな状態です。逆説的ですが、助かるPMOほど、最後は「自分がいなくても回る」状態を目指しています。もちろん、それは「何もしないマネジメント」とはまったく別物です。

開発経験はPMOでこう活きる

「開発しかやってこなかったから、PMOは向いていないのでは」と考える方もいるかもしれません。私自身、開発設計を4年経験してから、約300人規模のプロジェクトの管理に移りました。その経験から言うと、開発経験はPMOで十分に活きます。開発メンバーのうちから、次のようなことを意識しておくと、PMOの仕事にそのままつながります。

• 用語の意味を確認する：同じ言葉でも、会社や現場によって意味が違うことは普通にあります。「それは何を指していますか？」と確認できる人は、認識ズレを防ぐ大切さを知っている人です
• 「伝えた」ではなく「伝わったか」を確かめる：伝えたつもり、共有したつもりから、多くの問題は始まります
• 見積もりや仕様の「なぜ」を聞く：根拠を聞けると、ズレに早く気づけます
• 決まっていないことに気づいたら「誰が決めますか？」と聞く：止まっている判断を見つけるのは、PMOの入口です

どれも特別なスキルではありません。でも、こうした小さな確認の積み重ねが、あとから起きる大きな炎上を防ぎます。

まとめ：向き不向きより「伸びる人」かどうか

PMOに向いていない人とは、管理表を整えることが仕事だと思っている人、嫌われないことを優先してしまう人、問題が起きてから動けばいいと思っている人です。逆に言えば、困りごとを先回りして見つけ、立場の違う人の間に入り、合意を取りながらプロジェクトを前に進めようとする人は、経験が浅くてもPMOとして伸びていきます。

コンサルタントやPMOには、「伸びる人」と「伸びない人」がいます。私は、「自分はまだわかっていない」という事実に向き合える人が伸びる人だと考えています。わかっていないのに、わかったふりをしない。プロジェクトは毎回内容が変わるので、誰もが最初は「よくわからない」ところから始まります。そこから考えて動き続けられるかどうかが、向き不向きよりも大きな差になると思っています。

あわせて読みたい

• 「SESの案件が減っている」は本当？上流工程で選ばれるエンジニアの条件
• プロジェクトの進捗が止まる本当の理由は「決める人がいない」こと