PMOが生まれた「背景」とPMOの「これから」

はじめに

PMの補佐的な役割を担う「PMO」(ピーエムオー：Project Management Office)は、プロジェクトを成功へ導くキーパーソンであり、多くの企業からニーズが増えつつある、と前回で解説しました。今回は「そもそも、なぜPMOというポジションが誕生したのか」という背景から、実際のプロジェクトにおけるPMOの動き、またPMOの今後についても触れていきたいと思います。

IT革命で企業や
プロジェクトに訪れた大きな変化

“IT革命”が流行語となった2000年以降、コンピュータの進化、インターネットの爆発的な普及をはじめ、世の中のIT化が一気に加速。それにともないIT業界の市場規模も急拡大しました。

それまでのIT企業と言えば、サーバ構築もやればネットワーク構築もソフトウェア開発も自社で行う、といった「すべて自社で完結する」スタイルが基本的でした。しかしIT革命後、テクノロジーが次々に進化し、IT企業の業務量や業務範囲が膨大化、複雑化すると、その体制では難しくなってきました。

また事業が細分化され、例えばアプリケーションだけ、プラットフォームだけ、インフラストラクチャーだけを行う会社といったように、専門分野に特化した企業も増加。IT業界は“餅は餅屋”の時代に変化していったのです。

すると、企業のプロジェクトにも変化が起こりました。それまで自社のみで完結できるプロジェクトばかりだったのが、1つのプロジェクトを進行させるために数多くの企業や自社・他社のメンバたちと関わる必要が出てきたのです。

システム開発プロジェクトを例にすると、発注企業(事業会社)と受注企業(システムベンダー)それぞれに、担当業務ごとに編成された10人前後のチームや部門が複数存在し、全体で200人以上が関わるプロジェクトも少なくありません。一方で、規模の大きなプロジェクトにも関わらず、人手不足の状態で進行せざるをえない場合もあります。さらに1つの企業でそのようなプロジェクトが同時にいくつも走っているということも、決して珍しくはないのです。

しかも、企業としては収益につながるプロジェクトをできる限り引き受けたいのが本音です。最初は「会計システムの開発だけ」だった話が、「セキュリティ対策システムもやろう」「勤怠や給与システムも!」などと、トップがどんどん引き受けてしまい、プロジェクトがさらに増加、複雑化してしまうのはよくある話です。そのしわ寄せは、プロジェクト全体の進行やリーダー、メンバーたちへ及ぶことになります。

特に負担が大きいのはPMやリーダーです。次々に増える自分の本来業務のほか、各チームメンバ一人ひとりの進捗管理や報告業務、取引先や再委託先ベンダーとのやりとりなど、納期に追われながらたくさんの仕事を抱えることになります。

PMやリーダーといったプロジェクトの柱となる人たちがパンク状態では、プロジェクトの成功は見えないばかりか、遠ざかってしまうばかりです。そこで求められるように誕生したのがPMOという職種なのです。

時代の変化から必然的に生まれたPMO

混乱するプロジェクトを統制するために必要なのは、プロジェクト全体を冷静に見つめ、発見した課題を解決したり、各チームや企業同士をつないだり、ゴールに最短で向かうための正しい取捨選択や優先順位を判断、提案できる存在。それがPMOなのです。

プロジェクト体制図

PMOはメンバ同士やクライアント、取引先といった企業間の橋渡し役となって、コミュニケーションを円滑にします。職種や会社も違う者同士が1つのプロジェクトを進めていくのですから、意見の食い違いや勘違いもあるでしょう。PMOはそれぞれの職種や立場を理解し、同じ言語で対話することで差異を調整します。

また、各リーダーの進捗管理や報告業務といった仕事を効率的にこなせるシステムの導入、仕組みの構築など、個々の負担を軽減し、本来業務に注力できるようPMOが動くこともあります。

そして、前述の「トップが次々プロジェクトを引き受けてしまう問題」を食い止められるのもPMOにほかならないのです。当然ですが、チームリーダーやメンバは、会社が「やる」といった仕事はやるしかありません。しかしPMOは、進捗や業務負担などを精査した上で「今年は会計システムの開発にとどめ、セキュリティ対策はやめましょう!」といった“区切り”や“やらない決断”をトップに提案できる立場でもあるのです。

そうかと思えば、プロジェクト内で使用するフォーマットの統一といった、とても細やかな調整もPMOが行います。これは実はとても重要で、統一しないままプロジェクトを始めてしまうと、業務報告1つとってもWordで報告書を作る人、Excelを使う人、チャットで報告する人などバラバラになり、とてもまとめられません。2〜30人のプロジェクトになれば、余計に手間がかかってしまうでしょう。

また、プロジェクトの規模が大きくなるほど、情報を全体に浸透させるのは大変です。PMOは、業務に必要な情報を1カ所の共有フォルダにまとめておくなど、各メンバが「情報集め」に時間をかけることなく、本来業務や課題解決に集中できるような環境づくりにも一役買います。

業務が複雑化、細分化されている現代では、PMOのこうした調整力や課題解決力、提案力、決断力といったさまざまな力が、プロジェクトの成功率をグンと引き上げてくれるのです。

PMOのこれから

IT革命から20年以上経った今もなお、ChatGPTのようなAI技術、ノーコード開発の普及などテクノロジーの進化は止まりません。つまり、これからもプロジェクトのさらなる膨大化や複雑化は避けられないでしょう。

そのため、今後はPMOの中でも最新技術やコードなどの知識や技術を携えたPMOのニーズがさらに高まっていくのではないかと思っています。一方、プログラマーやエンジニアといった職種は、テクノロジーに取って代わられてしまうのは時間の問題とも言えます。だからこそ私は、今キャリアに悩んでいらっしゃるプログラマーやエンジニアのみなさんには、ぜひPMOへのキャリアアップを検討いただきたいと思っているのです。

いくらテクノロジーが進化しても、開発に関わるたくさんの人間の考えを整理しながら、それを具現化していく仕事はこれからも人間しかできないでしょう。

おわりに

第2回の今回は、以下のような内容を解説してきました。

• 2000年ごろを境にテクノロジーの進化とともに業務の細分化、プロジェクトの複雑化が加速し続けている
• プロジェクト全体の調整や課題解決を行い、プロジェクトを成功に導く職種としてPMOが誕生した
• これからは特に最新技術、ITの知識や経験を持ったPMOのニーズが高まっていく

PMOというポジションが、どのようにして生まれ、プロジェクト内でどのような動きをしているか、イメージできたでしょうか。ちなみに、PMOをしていると「これはどうやって解決したら良いんだ……」と大きな壁にぶつかることもありますが、その大きな壁をどうやって攻略するのか、それを考えること自体が刺激的で楽しいと個人的には感じています。

私のSE時代を思い返すと、解決策は開発するか／しないか、しない場合はお客様側で対応、する場合は開発するという、パターンがほとんど見えているものばかりでした。「できないことをどう実現させるか」を徹底的に悩んで考えると、解決したときの喜びが何倍にもなって跳ね返ってきます。これがPMOという仕事の大きなやりがいだと感じますし、もっとたくさんの方にこの経験をしていただきたいなとも思っています。

次回は、プロジェクトの重要なポジションである「PL」「PM」について、「PMO」との違いを解説します。どうぞお楽しみに!