PMOという仕事は、外から見ると「進捗管理して会議回すだけでしょ?」と思われがちです。でも実際にPMOを10年以上やってきた私から言わせてもらえば、それは大きな誤解です。教科書には書いていない、現場でしか分からない苦労が山ほどあります。今回は、私が30年のIT業界キャリアの中でPMOとして本当に苦労したことを、包み隠さずお話しします。
PMOの現場で本当に起きていること
PMOの仕事は「調整役」と言われますが、その実態は想像以上に複雑です。プロジェクトが順調に進んでいるときは良いのですが、問題が起きたときのプレッシャーは相当なものがあります。
誰も語らないPMOの孤独
PMOをやっていて一番つらいのは、実は「孤独」なんです。開発チームからは「管理する側」として見られ、経営層からは「現場の代表」として見られる。どちらの立場でもない、中間に立つ存在として、誰にも本音を言えない状況が続きます。
プロジェクトが炎上しかけているとき、開発側は「無理なスケジュールを組んだマネジメントが悪い」と言い、経営側は「なぜ早く報告しなかったのか」と言う。その板挟みになるのがPMOです。夜中に一人でExcelと向き合いながら、どうやってスケジュールを立て直すか、誰にどう説明するかを考える。あの孤独感は、経験した人にしか分からないと思います。
ベンダー間の認識違いという地雷原
複数ベンダーが関わるプロジェクトでは、認識違いが日常茶飯事です。A社は「それはB社の範囲」と言い、B社は「それは要件定義で決まっていない」と言う。その調整をするのがPMOの役割なのですが、これが本当に大変なんです。
契約書を読み返し、議事録を掘り起こし、誰が何を言ったかを確認する。でも結局、グレーゾーンは必ず存在します。そのときPMOがどう判断するかで、プロジェクトの成否が左右されることもあります。責任は重いのに、決裁権限は限られている。このジレンマがPMOを苦しめます。
スケジュール遅延という終わりなき戦い
「今週は間に合いませんでした」という報告を受けるたびに、心臓がギュッとなります。なぜなら、その遅延が全体スケジュールにどう影響するかを瞬時に計算し、リカバリープランを考えなければならないからです。
1週間の遅れが、実は2週間の遅れになる。なぜなら、その工程の遅れが次工程の開始を遅らせ、さらに関連する他ベンダーの作業にも影響するからです。この連鎖を防ぐために、夜遅くまで調整を続ける。週末も頭の中でスケジュールを組み直している。そんな日々が続きます。
PMOとして10年以上、たくさんの『苦しい瞬間』を経験してきました。特に印象的だったのは、200名規模のインターネットバンキング開発プロジェクトでの出来事です。本番カットオーバーの2週間前、3つのベンダーから報告される進捗が『順調』だったのに、実態は仕様齟齬が複数発覚し、テストが回らない状態でした。各ベンダーは自社の見解しか持っておらず、PMOの私が間に立って認識を揃える必要がありました。徹夜で課題の洗い出し、関係者全員の合意形成、PMへのエスカレーション。3日3晩ほぼ寝ずに対応した記憶があります。PMOの苦労は『目立たない地味な作業の積み重ね』が大半ですが、こうしたクライシスの瞬間こそ、PMOの真価が問われると痛感した経験でした。
プロジェクトが佳境に入ると、毎日が火消しです。朝起きた瞬間から「今日は何が起きるだろう」と身構えている自分がいます。メールを開くのが怖い。Slackの通知音にドキッとする。そんな精神状態で何ヶ月も働き続けるのは、正直かなりきついです。
課題管理が機能しなくなる瞬間
PMOの基本業務の一つが課題管理ですが、これが形骸化する瞬間を何度も見てきました。最初はみんな真面目に課題を登録します。でもプロジェクトが忙しくなると、課題管理表への入力が後回しになる。気づけば、Excelには古い情報しかなく、本当の課題はチャットやメールに埋もれている。
そうなると、PMOとしては各チームに「課題を登録してください」とお願いし続けることになります。でも現場は忙しい。「そんなことしてる暇があったらコード書きたい」という本音が透けて見えます。PMOの仕事が「お願い」になってしまう瞬間、自分の存在価値に疑問を感じることもありました。
ステークホルダーの温度差というカオス
これも本当に苦労するポイントです。経営層は「予算とスケジュール厳守」、開発側は「品質を担保したい」、ユーザー部門は「使いやすさ優先」。それぞれの立場で優先順位が違います。
PMOとしては、この温度差を調整しながら、全体最適を目指さなければなりません。でも正直、全員を満足させることなんて不可能です。どこかで妥協点を見つけ、誰かには我慢してもらう。そのための説得材料を用意し、何度も会議を重ねる。この調整に費やす時間とエネルギーは膨大です。
急な要件変更という悪夢
「ここだけ変えたい」というユーザーからの一言が、どれだけの影響を及ぼすか。経験のない人には想像できないと思います。一箇所の変更が、設計、開発、テスト、ドキュメント、教育資料にまで波及する。その影響範囲を洗い出し、工数を見積もり、スケジュールを再調整する。
しかもユーザーは「ちょっとした変更」だと思っているので、「なんでそんなに時間がかかるの?」と言われる。その説明をするのもPMOの仕事です。技術的な背景を分かりやすく説明し、納得してもらう。あるいは、どうしても必要なら、何を諦めるかを一緒に考える。この交渉が本当に疲れます。
なぜPMOはこんなに苦労するのか
10年以上PMOをやってきて、なぜこれほど苦労するのかが見えてきました。それは構造的な問題です。
権限と責任のアンバランス
PMOの最大の苦しみは、責任は重いのに権限が限られていることです。プロジェクトの成否はPMOの管理能力に左右されると言われますが、実際には予算配分や人員配置の決定権はPMや経営層にあります。
たとえば、明らかに人手が足りないと分かっていても、PMOは「増員が必要です」と提案することしかできません。その提案が通るかどうかは、予算と経営判断次第です。でも結果的にスケジュールが遅れたら、「PMOの管理が甘かった」と言われる。このアンバランスがPMOを苦しめます。
私が金融系の大規模プロジェクトでPMOをやっていたとき、開発ベンダーの技術力不足を早い段階で察知しました。でも契約上、そのベンダーを外すことはできません。PMOとしてできることは、そのベンダーへのフォローを厚くし、他ベンダーに協力を仰ぎ、なんとか品質を保つことだけでした。結果的にプロジェクトは成功しましたが、その過程で費やしたエネルギーは計り知れません。
情報のハブであることの重圧
PMOはプロジェクトのすべての情報が集まる場所です。これは一見、良いポジションのように思えますが、実際には重圧です。なぜなら、どんな小さな情報も見逃せないからです。
開発チームの雑談の中に、実は重要なリスク情報が隠れていることがあります。ベンダーからの何気ないメールに、スケジュール遅延の予兆が含まれていることもあります。PMOはそれらを見逃さず、早めに手を打たなければなりません。
でも人間ですから、すべてをキャッチすることは不可能です。見逃してしまった情報が後で大問題になったとき、「なぜ早く気づかなかったのか」と責められます。この「常に気を張っている」状態が、精神的に本当にきついんです。
定量化できない仕事の価値
プログラマーなら書いたコード量、SEなら設計書の枚数など、成果が目に見えます。でもPMOの仕事は定量化しにくい。調整、交渉、リスク予測、関係構築。これらは数字では測れません。
だからこそ、プロジェクトが成功したときも「PMのおかげ」と言われることが多く、PMOの貢献は見えにくいんです。逆に問題が起きたときは、「PMOが管理できていなかった」と言われる。この非対称性が、PMOのモチベーションを下げます。
私自身、何度も「自分の仕事は本当に価値があるのか?」と自問しました。30年のキャリアの中で、PMOという役割の重要性は理解していますが、それでも評価されにくい立場であることは事実です。
完璧を求められる矛盾
プロジェクトマネジメントの世界では、PMBOKやPRINCE2といった方法論があり、PMOはそれに従って完璧に管理することを期待されます。でも現実のプロジェクトは、教科書通りにはいきません。
予算は限られ、納期は厳しく、人員は不足し、要件は変わり続ける。その中で「完璧な管理」を求められても、無理なものは無理なんです。でもPMOとしては、その現実を受け入れつつ、できる限り最善を尽くすしかありません。
この「理想と現実のギャップ」に挟まれながら、毎日を過ごす。これがPMOの苦労の本質だと、私は思います。
現代のITツールで苦労を減らせるか
10年前、私がPMOを始めた頃と比べて、今は様々なツールが登場しています。これらのツールは、PMOの苦労をどれだけ軽減できるのでしょうか。私が現場で見てきた経験から、実際に効果があると思うツールを紹介します。
JiraとConfluenceの組み合わせ
課題管理と情報共有の両方を担えるツールとして、私はJiraとConfluenceの組み合わせを推奨します。Excelでの課題管理が形骸化するのは、誰がいつ更新したか分かりにくく、情報が分散するからです。
Jiraなら、課題ごとにステータス、担当者、期日が明確になり、誰でもリアルタイムで状況を把握できます。私が現在担当しているプロジェクトでもJiraを使っていますが、「課題を登録してください」とお願いする回数が明らかに減りました。なぜなら、開発側もJira上で作業するため、自然と課題が可視化されるからです。
Confluenceは議事録や設計書の共有に使えます。PMOとして一番助かるのは、「あの時の決定事項は何だったか?」を探す時間が大幅に減ることです。検索機能が優秀なので、過去の議論をすぐに見つけられます。ただし、導入時にはテンプレートやワークフローの設定が必要で、そこそこの学習コストがかかります。中小企業で使うなら、まずはシンプルな運用から始めることをお勧めします。
Microsoft Projectとその限界
スケジュール管理といえばMicrosoft Projectが定番ですが、私の経験から言うと、これは大規模プロジェクト向けです。ガントチャートを細かく作り込めるのは良いのですが、メンテナンスが大変なんです。
プロジェクトが動き始めると、毎週のようにスケジュールが変わります。そのたびにMicrosoft Projectを更新するのは、正直かなりの手間です。私は以前、これに毎週半日を費やしていました。今は、簡易的なスケジュールはGoogleスプレッドシートで管理し、詳細なガントチャートはマイルストーン単位でしか更新しないようにしています。
中小企業のPMOが使うなら、最初からMicrosoft Projectに手を出さず、もっと軽量なツール(例えばAsanaやTrelloのタイムライン機能)で十分だと思います。大事なのは「更新し続けられること」です。どんなに高機能でも、メンテナンスできなければ意味がありません。
SlackやTeamsでの情報キャッチ
PMOの苦労の一つが「情報を見逃さないこと」ですが、現代ではSlackやMicrosoft Teamsが情報のハブになっています。私が今使っているのはSlackですが、チャンネルごとに通知設定を変え、重要な情報を見逃さないようにしています。
ただし、これにも落とし穴があります。情報が流れすぎて、逆に重要なことが埋もれるんです。私は一度、重要な障害報告がSlackに流れていたのに、他のメッセージに埋もれて半日気づかなかったことがあります。それ以来、重要な連絡は必ずメンション付きでもらうルールを徹底しました。
PMOとしては、チャットツールを「なんでも流れる場所」にするのではなく、「どこに何を流すか」のルールを最初に決めることが大事です。私が現場で実践しているのは、障害は専用チャンネル、スケジュール変更は別チャンネル、雑談はまた別、という分け方です。これだけで情報の見落としが格段に減りました。
30年現場にいた私が思うこと
PMOという仕事は、確かに苦労が多いです。孤独で、プレッシャーが大きく、評価されにくい。でも30年のキャリアを振り返ったとき、PMOとして働いた経験が私を大きく成長させてくれたと感じています。
PMOでしか学べないこと
PMOをやらなければ、プロジェクト全体を俯瞰する力は身につかなかったと思います。開発者として現場にいたときは、自分の担当部分しか見えていませんでした。でもPMOになってから、ビジネス側の視点、経営側の視点、ベンダー側の視点、すべてを理解する必要が出てきました。
この「多視点で物事を見る力」は、今の私の最大の武器です。問題が起きたとき、誰か一方を責めるのではなく、構造的に何が問題なのかを考えられるようになりました。これは、PMOという板挟みの立場だからこそ鍛えられた能力だと思います。
苦労する人ほど、現場を良くできる
私が今まで見てきた中で、優秀なPMOは例外なく「現場の痛み」を知っている人でした。開発経験があり、納期のプレッシャーを知っており、バグで苦しんだ経験がある。そういう人だからこそ、無理なスケジュールを組まず、現実的なリスク管理ができるんです。
もしあなたが今、PMOとして苦労しているなら、その経験は無駄ではありません。むしろ、その苦労が将来の財産になります。私自身、炎上プロジェクトで何度も胃が痛くなる思いをしましたが、その経験があるから今、冷静に対処できるんです。
完璧を目指さない勇気
PMOは「完璧な管理」を求められますが、完璧なんて無理です。私も最初の頃は、すべてをコントロールしようとして空回りしていました。でも今は違います。「ここは譲れない」「ここは妥協できる」という線引きができるようになりました。
たとえば、スケジュール遅延が避けられないとき、すべてを取り戻そうとするのではなく、「この機能は次フェーズに回せないか?」と提案する。完璧に全部やることを諦め、優先順位をつける。この判断ができるようになると、PMOとしての仕事がだいぶ楽になります。
明日からできる小さな一歩
もしあなたがPMOとして孤独を感じているなら、まず誰か一人、本音で話せる相手を見つけてください。同じプロジェクトの人でなくても構いません。社外の勉強会でも、SNSでもいい。PMO同士でつながると、「自分だけじゃなかった」と思えて、少し楽になります。
私も以前、PMOの勉強会に参加して、他のPMOが同じような苦労をしていることを知り、すごく救われました。「あの人も頑張ってるなら、自分も頑張ろう」と思えたんです。孤独は、つながることで和らぎます。
それから、課題管理やスケジュール管理が形骸化しているなら、まず一つだけルールを決めてください。「毎週金曜の夕方に、必ず課題の棚卸しをする」とか、「遅延が発生したら24時間以内に報告する」とか。小さなルールでいいんです。それを守ることから始めれば、少しずつプロジェクトの見通しが良くなります。
PMOという仕事は確かに大変ですが、やりがいもあります。プロジェクトが無事にリリースされたとき、チームのみんなが笑顔になる瞬間を見ると、「ああ、頑張ってよかった」と心から思えます。あなたのPMOとしての苦労が、いつか必ず報われる日が来ます。私はそう信じています。
コメント