PMOの現場で実際に起きていること
PMOという職種に興味を持って調べ始めると、ネット上には「プロジェクトマネジメントオフィス」「進捗管理」「調整役」といった言葉が並んでいます。でも、実際の現場では、もっと複雑で人間臭いことが毎日起きています。
私はIT業界で30年働いてきて、プログラマーからSE、そしてPMO・PMへとキャリアを積んできました。その過程で、PMOという役割に就いた多くの人たちを見てきました。技術的には優秀なのにPMOとして苦しんでいる人、逆に技術経験は浅いのに見事に現場をまとめている人。この違いは一体どこから来るのか、ずっと観察してきました。
結論から言うと、PMOの向き不向きは技術力の問題ではありません。もっと根本的な、その人の思考特性とコミュニケーションスタイルの問題なんです。
私はPMOとして10年以上、後輩PMOや候補者を多数見てきました。向いている人と向いていない人の違いは、技術力ではなく『思考特性』にあります。例えば、ある若手SEがPMOにアサインされたケースで、彼は技術力は申し分なかったのですが、『答えを急ぐ性格』が災いしました。会議で議論が長引くとイライラし、結論を強引にまとめる傾向があり、結果としてステークホルダーの反発を招きました。一方、別の若手は『複数の視点を持てる人』で、対立する意見も両方の言い分を理解した上で着地点を探せました。彼は3年でPMOとして信頼される存在になりました。技術力より、性格と思考特性がPMOの適性を決める、というのが30年見てきた結論です。
この出来事から私が学んだのは、PMOには「答えを急がない力」が必要だということです。プログラマーやSEとして優秀だった人ほど、正解を早く出そうとします。でもPMOの仕事は、不完全な情報の中で複数の関係者の思惑を調整し、全員が納得できる着地点を探すことです。白黒つけられない状態に耐えられるかどうかが、向き不向きの大きな分かれ目になります。
技術者からPMOへの転身で起きる違和感
技術者として活躍していた人がPMOに転身すると、最初は必ずと言っていいほど違和感を覚えます。それは「答えが一つではない世界」に放り込まれるからです。
プログラミングの世界には正解があります。バグは修正すれば直るし、パフォーマンスは数値で測れます。でもPMOの世界は違います。顧客は「使いやすくしてほしい」と言い、開発チームは「仕様を明確にしてほしい」と言い、経営層は「予算内で終わらせてほしい」と言う。全員の言い分が正しくて、全員の要求を同時に満たすことは不可能です。
この状況で「正解探し」を始めてしまう人は、PMOとして苦労します。正解はないのだから、探しても見つからない。必要なのは「最適解を作り出す力」です。これは技術力とは全く別の能力なんです。
地味な作業の連続に耐えられるか
もう一つ、多くの人が見落としている現実があります。PMOの仕事の大半は、驚くほど地味だということです。
進捗会議の議事録を書く。Excelの工数表を更新する。課題管理表の期日を確認する。各チームに状況をヒアリングする。こうした作業を、毎日、毎週、毎月、繰り返し続けます。華やかな戦略立案や意思決定の場面は、実はそれほど多くありません。
私が見てきた中で、PMOとして長続きしなかった人の多くは、この地味さに耐えられなくなった人たちです。特に、開発の最前線で新しい技術に触れていた人ほど、「自分は今、何のためにExcelと向き合っているんだろう」と感じてしまいます。
逆に、PMOとして活躍している人は、この地味な作業の積み重ねが現場を支えていることを理解しています。課題管理表の一行一行が、誰かの困りごとを可視化している。進捗会議の議事録が、後で振り返るときの貴重な記録になる。そう思えるかどうかが、向き不向きを分けます。
なぜPMOの向き不向きが生まれるのか
30年の経験から見えてきたのは、PMOという仕事の本質が「曖昧さとの共存」だということです。この特性が、向き不向きを生む最大の理由です。
PMOは境界線上に立つ役割
PMOは常に境界線上に立っています。顧客と開発チームの間。経営層と現場の間。技術と業務の間。この「間」に立つことの難しさを、多くの人が過小評価しています。
プログラマーやSEは、基本的には開発側の人間です。技術的な課題を解決するのが仕事で、立ち位置は明確です。でもPMOは違います。時には開発側の味方として顧客に説明し、時には顧客側の視点で開発チームに厳しいことを言わなければなりません。
この立ち位置の曖昧さが、ある種の人にとってはストレスになります。「どっちの味方なんだ」と言われることもあります。でも、それがPMOの仕事なんです。どちらの味方でもなく、プロジェクト全体の味方。この感覚を持てるかどうかが、向き不向きの核心です。
答えを出す人ではなく、答えを引き出す人
もう一つの本質は、PMOは「答えを出す人」ではなく「答えを引き出す人」だということです。この違いを理解していない人は、PMOとして苦労します。
プロジェクトで問題が起きたとき、SEなら「この問題の解決策はこれです」と答えを提示します。でもPMOは「この問題について、開発チームはどう考えていますか?顧客はどう感じていますか?」と問いかけ、関係者から答えを引き出します。そして、それらの答えを統合して、全員が納得できる解決策に導きます。
私が見てきた中で、PMOとして向いていなかった人の多くは、自分で答えを出そうとしすぎました。「私が正しい解決策を考えたのに、なぜみんな納得しないんだ」と苦しんでいました。でも、PMOの仕事は正しい答えを出すことではなく、関係者が納得できる答えを一緒に作ることなんです。
感情労働としてのPMO
PMOは技術職でありながら、実は感情労働の側面が非常に強い仕事です。この点を理解せずにPMOになると、想定外のストレスに直面します。
プロジェクトが遅延すると、開発チームは疲弊し、顧客は不安になり、経営層はイライラします。PMOはその全ての感情を受け止める立場にいます。開発チームの「もう無理です」という悲鳴も、顧客の「約束が違う」という怒りも、経営層の「何をやっているんだ」というプレッシャーも、全部受け止めなければなりません。
この感情の洪水に飲み込まれずに、冷静に状況を整理し、次のアクションを示せる人が、PMOに向いています。逆に、他人の感情に引きずられやすい人、自分の感情をコントロールできない人は、PMOとして消耗してしまいます。
向いている人・向いていない人の具体的な特徴
30年間、様々なPMOを見てきて気づいた、向いている人と向いていない人の具体的な特徴をまとめます。採用や育成、キャリア選択の参考にしてください。
向いている人の3つの特徴
1. 答えを急がない人
情報が不完全な状態でも焦らず、必要な情報が揃うまで判断を保留できる人です。「とりあえず決めましょう」と急かされても、「もう少し状況を見てから判断しましょう」と言える人。プロジェクトの現場では、焦って決めた判断が後で大きな問題になることが多々あります。PMOに必要なのは、この「待つ力」です。
ただし、これは優柔不断とは違います。判断を保留しながらも、その間に必要な情報を集め、関係者の意見を聞き、判断の材料を揃える行動をしています。能動的な保留ができる人が、PMOに向いています。
2. 複数の視点を同時に持てる人
顧客の立場、開発チームの立場、経営層の視点を同時に理解できる人です。「顧客は無茶を言う」「開発は言い訳ばかり」と一方的な見方をせず、「顧客がそう言うのは、こういう事情があるからだな」「開発がそう反応するのは、こういう背景があるからだな」と多角的に理解できる人です。
私が一緒に働いてきたPMOの中で最も優秀だった人は、会議の後でこう言っていました。「今の会議で、顧客は3回、本当に言いたいことを飲み込みましたね。開発側も2回、言葉を選んでいました」。この観察眼がPMOには必要です。
3. 地味な作業を価値化できる人
課題管理表の更新、議事録の作成、進捗の集計といった地味な作業に、ちゃんと意味を見出せる人です。「面倒な事務作業」ではなく「プロジェクトの状態を可視化する重要な仕事」として捉えられる人。こうした人は、地味な作業を続けることができるし、その作業の質も高くなります。
PMOの仕事の8割は、こうした地道な情報収集と整理です。ここに価値を感じられない人は、PMOとして長続きしません。
向いていない人の3つの特徴
1. 完璧主義すぎる人
全ての情報を集めてから判断したい、全ての課題を解決してから次に進みたい、という完璧主義の人は、PMOとして苦労します。プロジェクトの現場は常に不完全で、全ての情報が揃うことはありません。70%の情報で80点の判断をする、という割り切りが必要です。
私が見てきた中で、完璧主義のPMOは常に疲弊していました。課題管理表の細かい記述にこだわり、議事録の表現に何時間もかけ、結果として本質的な調整業務に時間を割けなくなっていました。
2. 感情的になりやすい人
プロジェクトの現場では、理不尽なことが毎日起きます。突然の仕様変更、一方的な納期短縮、無茶な要求。こうした状況で感情的に反応してしまう人は、PMOには向いていません。
PMOに必要なのは、感情と行動を切り離す能力です。内心では「ふざけるな」と思っても、表面上は冷静に「承知しました。影響範囲を確認して、明日までに回答します」と言える人。この演技力というか、感情のコントロール力が不可欠です。
3. 目立ちたがりの人
自分の成果を認められたい、評価されたいという欲求が強い人は、PMOとして満足感を得にくいです。PMOの仕事は基本的に裏方です。プロジェクトが成功したとき、顧客から感謝されるのは開発チームのリーダーです。経営層から評価されるのはPMです。PMOの名前が出ることは、ほとんどありません。
でも、プロジェクトが炎上せずに進んでいるのは、PMOが毎日地道に情報を集め、課題を早期に発見し、関係者を調整しているからです。この「見えない貢献」に満足感を得られる人が、PMOに向いています。
技術力との関係
よく聞かれるのが「PMOには高い技術力が必要ですか?」という質問です。私の答えは「必要だが、最優先ではない」です。
技術的な理解は必要です。開発チームが何に困っているのか、技術的な課題の難易度はどれくらいか、ある程度理解できないと、適切な調整ができません。でも、最新の技術トレンドに詳しい必要はないし、自分でコードを書ける必要もありません。
私が見てきた優秀なPMOの中には、元営業職の人もいました。技術的な深い知識はなかったのですが、人の話を聞く力、関係者の本音を引き出す力、複雑な状況を整理する力が抜群で、開発経験豊富なPMOよりも現場をうまく回していました。
技術力は後から学べます。でも、思考特性やコミュニケーションスタイルは、大人になってから変えるのは難しい。PMOの向き不向きを見極めるときは、技術力よりも、その人の性格や思考の癖を見るべきです。
30年現場にいた私が思うこと
PMOという職種は、日本のIT業界ではまだ比較的新しい役割です。2000年代に入ってから徐々に認知されてきましたが、その役割や必要なスキルについては、まだ定まっていない部分が多くあります。
私が30年のキャリアで見てきたのは、PMOに「なるべき人」と「なりたい人」のミスマッチです。技術者としてキャリアを積んできた人が、次のステップとして何となくPMOを選び、でも実際にやってみると「こんなはずじゃなかった」と感じる。このパターンを何度も見てきました。
PMOは技術職ではなく調整職
PMOを技術職の延長線上で捉えている人が多いのですが、実際には全く違う職種です。私の感覚では、PMOは技術職3割、調整職7割です。技術的な知識は必要ですが、それは道具に過ぎません。本質は人と人の間に立って、複雑な利害関係を整理し、プロジェクトを前に進める調整力です。
この調整という仕事が、実は想像以上に難しい。技術的な問題なら、勉強すれば解決策が見つかります。でも人間関係の調整には正解がありません。相手の性格、その日の機嫌、組織の力関係、過去の経緯、全てを考慮しながら、最適な落としどころを探す。この複雑さに面白さを感じられる人が、PMOに向いています。
向いていないと気づいたら、戻る勇気も必要
もしPMOになってみて「自分には向いていない」と感じたら、元の職種に戻る選択肢も考えてください。これは失敗ではなく、自分の適性を知るプロセスです。
私が見てきた中で、優秀な技術者がPMOになって苦しみ、結局開発に戻って再び輝いた人が何人もいます。PMOに向いていないことは、その人の能力が低いことを意味しません。単に、その人の強みが別のところにあるというだけです。
IT業界は幸い、キャリアの選択肢が豊富です。一度PMOになったら一生PMOではありません。自分の適性を見極めながら、柔軟にキャリアを選んでいく。それがIT業界で長く働くコツだと、私は思います。
明日からできる適性の見極め方
最後に、PMOへのキャリアチェンジを考えている方へ、明日から試せる適性の見極め方をお伝えします。
まず、今の職場で「調整役」を買って出てください。部門間の意見の相違があったとき、技術チームと業務チームの間に立って調整する役割を、一度引き受けてみる。この経験が、PMOの仕事の縮図です。
そのとき、自分がどう感じるかを観察してください。「面倒だな」と感じるか、「複雑で面白いな」と感じるか。両方の言い分を聞いて、落としどころを探すプロセスに、ワクワクするか、それともストレスを感じるか。この感覚が、あなたの適性を教えてくれます。
もう一つ試してほしいのは、会議の議事録を丁寧に書いてみることです。ただの記録ではなく、誰が何を懸念していて、どんな前提で話していて、何が決まって何が決まっていないのか、構造化して整理する。この作業を「面倒な事務作業」と感じるか、「情報を整理する面白い作業」と感じるか。それが、PMOとしての適性を示しています。
PMOは、合う人には本当に合う仕事です。複雑なパズルを解くような面白さ、多様な人と関わる刺激、プロジェクト全体を俯瞰する視点。でも、合わない人には本当につらい仕事でもあります。自分の適性を見極めて、納得できるキャリア選択をしてほしい。30年間PMOの現場を見てきた私からの、心からのアドバイスです。
コメント