PMOのスキルとは何か―現場で見えた真実
PMOに必要なスキルを検索すると、コミュニケーション能力、Excel操作、PMBOKの知識など、よく似た項目が並びます。確かにどれも間違いではないのですが、30年IT業界にいる私から見ると、もっと本質的で、現場でしか分からないスキルがあるんですよね。
私はプログラマーからスタートして、SE、そしてPMO・PMへとキャリアを積んできました。その過程で数十のプロジェクトに関わり、成功も失敗も経験しました。PMOとして機能するために本当に必要だったスキルは、研修資料やテキストには載っていないものばかりでした。
この記事では、私が30年かけて身につけてきたPMOに必要なスキルを5つに絞って語ります。PMOを目指している方、PMOとして成長したい方に向けて、現場で本当に効くスキルとその習得法をお伝えします。
PMOに求められるのは「見えない仕事」をする力
PMOの仕事は表に出にくいものです。プログラマーのように動くシステムを作るわけでも、営業のように契約を取ってくるわけでもありません。しかし、PMOがいないプロジェクトは確実に混乱します。
私が最初にPMOポジションについたとき、一番戸惑ったのは「何をすれば成果になるのか」が見えにくいことでした。進捗管理表を作っても、議事録を書いても、それが直接プロジェクトの成功につながっているのか分かりづらいんです。
でも、あるプロジェクトで開発チームとクライアントの間で大きな認識のズレが起きたとき、私が毎週記録していた議事録と決定事項の履歴が、問題解決の鍵になりました。そのとき初めて、PMOの仕事は「プロジェクトが崩れないように支える縁の下の力持ち」だと実感したんです。
一般論では通用しない現場の現実
PMOのスキルについて書かれた記事の多くは、一般論に終始しています。「コミュニケーション能力が大切」「Excelが使えること」「スケジュール管理能力」。どれも正しいのですが、現場ではもっと具体的で、泥臭いスキルが求められます。
たとえば、スケジュール管理といっても、単にガントチャートを引けばいいわけではありません。開発メンバーが「大丈夫です」と言っているのに、その表情や言い方から「実は遅れそうだ」と察知する力。これは教科書には載っていませんが、プロジェクトを救う重要なスキルです。
私が30年のIT業界、特にPMO 10年以上の経験で身につけたスキルを振り返ると、教科書通りではない『現場で本当に効く5つのスキル』に集約されます。1つ目は『観察力』。現場の温度を察知する力で、メンバーの表情、会議での沈黙、メールの文面の微妙な変化から、課題の兆候を読み取ります。2つ目は『ドキュメンテーション』。議事録ではなく『決定事項の言語化』が本質です。3つ目は『調整力』。対立する利害を着地させる技術。4つ目は『PMBOK実務翻訳力』。理論を現場で使える形に変換する力。5つ目は『忍耐力』。地味な作業を継続できる精神力。私自身、これらは20年以上かけて少しずつ身につけたものです。
こういった現場でしか分からない感覚的なスキルを、私はこれから具体的に5つ紹介していきます。PMOとして生き残るために、そしてプロジェクトを本当に支えるために必要な、実践的なスキルです。
なぜPMOに特殊なスキルが必要なのか
PMOに独特のスキルが求められる理由は、PMOの役割そのものが特殊だからです。30年この業界を見てきて、PMOほど「立ち位置が難しい職種」は他にないと思います。
板挟みになる構造的な宿命
PMOはプロジェクトマネージャーを支援する立場ですが、同時に開発メンバーとも、クライアントとも、経営層とも関わります。この「誰の味方でもあり、誰の味方でもない」という立ち位置が、PMOを難しくしています。
開発メンバーからは「管理されている」と警戒され、PMからは「もっと厳しく管理してほしい」と言われ、クライアントからは「進捗が見えない」と不安をぶつけられる。この板挟み構造の中で機能するには、単なる事務処理能力では足りません。
私が金融系の大規模プロジェクトでPMOを務めていたとき、開発側は「細かすぎる進捗報告が開発の邪魔になっている」と不満を持ち、クライアント側は「もっと詳細な報告がほしい」と要求してきました。両者の言い分を聞き、調整し、双方が納得する報告の粒度を見つけ出す。これがPMOの仕事でした。
見えない情報を可視化する難しさ
PMOのもう一つの構造的な難しさは、「見えないものを見えるようにする」ことが求められる点です。プロジェクトの進捗、リスク、課題、メンバーの疲弊度。これらは放っておくと誰にも見えません。
しかも、開発メンバーは自分の遅れを正直に報告したがらないし、PMは問題を小さく見せたがる傾向があります。その中で真実を見抜き、適切に可視化して関係者に伝える。これには独特のスキルが必要です。
私が経験した中で最も厳しかったのは、ベテラン開発者が「問題ない」と言い続けているのに、実は技術的に行き詰まっていたケースです。毎日の何気ない会話や、コードレビューの頻度、退社時間などから異変を察知し、PMに早めに報告することで、大きな遅延を防ぎました。これは「観察力」というスキルがなければできません。
PMBOKと現場のギャップを埋める役割
PMOにはPMBOKの知識が必要とよく言われますが、現場ではそのまま適用できないことがほとんどです。PMBOKは体系的で素晴らしいフレームワークですが、中小企業の小規模プロジェクトや、短納期のアジャイル開発には重すぎるんです。
私の役割は、PMBOKのエッセンスを取り出して、目の前のプロジェクトに合う形に翻訳することでした。たとえば、変更管理プロセスをフル装備で回すのではなく、「変更依頼は必ず文書化し、影響範囲だけは必ず確認する」という最低限のルールに落とし込む。この「翻訳力」がPMOには必須です。
なぜこんな翻訳が必要かというと、現場は常に時間に追われているからです。教科書通りの管理プロセスを押し付けると、開発メンバーから総スカンを食らいます。でも、何も管理しなければプロジェクトは崩壊します。その絶妙なバランスを取るのがPMOの腕の見せどころです。
現場で効く5つの本質的スキル
ここからは、私が30年の経験で身につけてきた、PMOに本当に必要な5つのスキルを紹介します。どれも現場で磨かれたもので、教科書には載っていない実践的なスキルです。
スキル1:観察力―現場の温度を察知する
PMOに最も必要なスキルは、観察力です。プロジェクトの状態を数字だけで判断していては、本当の危機を見逃します。開発メンバーの表情、声のトーン、会議での発言の変化。こういった「空気」を読み取る力が、プロジェクトを救います。
私が意識しているのは、毎日の朝会やデイリースタンドアップでのメンバーの様子です。いつも元気な人が無口になっている、いつも冷静な人が焦った口調になっている。こういった変化を見逃さないようにしています。
ある製造業向けのシステム開発プロジェクトで、あるエンジニアが3日連続で「順調です」と報告しているのに、目が合わないし、報告が短すぎると感じました。個別に声をかけたところ、設計段階でのミスに気づいて、どう報告すればいいか悩んでいたことが分かりました。早期に問題を共有できたおかげで、手戻りを最小限に抑えられました。
観察力を鍛えるには、まず「数字以外の情報」に意識を向けることです。進捗率やバグ件数だけでなく、誰が誰と話しているか、休憩時間の雑談の内容、ランチに行くメンバーの組み合わせ。こういった情報から、チームの状態が見えてきます。
スキル2:ドキュメンテーション力―決定事項を言語化する
PMOの仕事として議事録作成はよく挙げられますが、重要なのは単なる発言の書き起こしではありません。「何が決まったのか」「誰が何をいつまでにやるのか」を明確に言語化する力です。
会議では、参加者それぞれが違うことを理解して帰ることがよくあります。PMOの役割は、決定事項を誰が読んでも同じ理解になる文章にまとめることです。これができないと、後々「聞いていない」「そんな話はしていない」という水掛け論になります。
私が心がけているのは、決定事項を「5W1H」で必ず書くことです。誰が(Who)、何を(What)、いつまでに(When)、どこで(Where)、なぜ(Why)、どうやって(How)。特に「なぜ」が抜けると、後から「なんでこの仕様になったんだっけ?」となり、同じ議論を繰り返すことになります。
ドキュメンテーション力を高めるには、書いた文書を第三者に読んでもらうのが一番です。自分では分かりやすいつもりでも、他人が読むと意味が取れないことはよくあります。私も若い頃、PMに「この議事録、結局何が決まったの?」と何度も差し戻されました。そのたびに書き直すうちに、簡潔で明確な文章が書けるようになりました。
スキル3:調整力―対立する利害をまとめる
PMOは利害が対立する場面に頻繁に立ち会います。開発側は「仕様を減らしたい」、クライアント側は「機能を増やしたい」。双方の言い分を聞き、落としどころを見つける調整力は、PMOの生命線です。
調整力というと「交渉上手」をイメージするかもしれませんが、私が重視しているのは「双方の本音を引き出すこと」です。表面的な要求の裏には、必ず本当の目的があります。それを見抜けば、Win-Winの解決策が見えてきます。
ある小売業のシステム刷新プロジェクトで、クライアントが「ダッシュボードにグラフを10種類表示したい」と要求してきました。開発側は「工数が膨大になる」と反発しました。私が詳しく聞くと、クライアントの本音は「経営会議で使える資料がほしい」でした。そこで、必要なグラフ3種類に絞り、代わりにExcelエクスポート機能をつける提案をしたところ、双方が納得しました。
調整力を磨くには、「相手の立場で考える」訓練が必要です。開発側の立場だけでなく、クライアントの立場、PMの立場、それぞれで何が困っているのかを想像する。この視点の切り替えができると、対立を解消する糸口が見えてきます。
スキル4:PMBOK実務翻訳力―教科書を現場で使える形にする
PMOにはPMBOKの知識が求められますが、そのまま現場に適用しても機能しません。PMBOKは大規模プロジェクトを前提にした体系的なフレームワークで、中小企業の数ヶ月のプロジェクトには重すぎるんです。
私が得意としているのは、PMBOKのエッセンスを抽出して、目の前のプロジェクトに合う軽量版に翻訳することです。たとえば、PMBOKのリスク管理プロセスは詳細ですが、小規模プロジェクトでは「リスク一覧表を作り、週次で見直す」だけでも十分効果があります。
金融系の厳格な変更管理プロセスを経験した私は、その考え方を中小企業向けにアレンジして使っています。完全な変更管理委員会は設置しませんが、「変更依頼はメールではなく必ず書面で残す」「影響範囲の確認だけは省略しない」という最低限のルールは徹底します。これだけでも、後々のトラブルを大幅に減らせます。
PMBOK実務翻訳力を身につけるには、まずPMBOKの各知識エリアの「目的」を理解することです。手順を暗記するのではなく、「なぜこの管理が必要なのか」を理解すれば、どこを簡略化してどこを守るべきか判断できるようになります。私は資格取得のための勉強ではなく、現場で「このプロセス、PMBOKならどう管理するんだろう」と考える習慣をつけました。
スキル5:忍耐力―地味な作業を続ける精神力
最後に挙げるのは忍耐力です。PMOの仕事は華やかではありません。毎日同じような進捗確認、毎週同じような会議の議事録作成、毎月同じような報告書の作成。この地味な作業を淡々と続ける精神力が、実は最も重要なスキルかもしれません。
PMOは「やって当たり前」で、感謝されることが少ない仕事です。進捗管理が完璧でもプロジェクトが順調に進んでも、「PMOのおかげ」とは言われず、「PMが優秀だった」で終わります。でも、PMOがいなければ確実にプロジェクトは混乱します。この「縁の下の力持ち」に徹する忍耐力が必要です。
私が忍耐力を試されたのは、1年以上続いた大規模プロジェクトで、毎週50人規模の進捗会議の議事録を作成し続けたときです。正直、同じような内容の繰り返しで、「こんなこと意味があるのか」と思ったこともあります。でも、プロジェクト終盤で大きな仕様変更が発生したとき、過去の議事録を遡ることで、変更の影響範囲を正確に把握でき、大きな手戻りを防げました。
忍耐力を保つコツは、「小さな達成感」を見つけることです。議事録を1つ仕上げる、進捗管理表を更新する、こういった小さなタスクを「完了」することで、日々の達成感を得る。また、自分の作業が「プロジェクトを支えている」と信じることも大切です。PMOの仕事は地味ですが、確実にプロジェクトを支えています。
30年現場にいた私が思うこと
30年IT業界にいて、プログラマー、SE、PMO、PMと様々な立場を経験してきた私が、PMOに必要なスキルについて最も伝えたいのは、「教科書に書いてあることは出発点に過ぎない」ということです。
PMOは現場で育つ職種
PMOのスキルは、座学では身につきません。実際のプロジェクトで、板挟みになりながら、失敗しながら、少しずつ磨かれていくものです。私も最初は何をすればいいか分からず、PMに怒られ、開発メンバーに煙たがられながら、試行錯誤してきました。
だからこそ、これからPMOを目指す方には、「最初から完璧にやろうとしないこと」を伝えたいです。観察力も、ドキュメンテーション力も、調整力も、最初からできる人はいません。小さな失敗を重ねながら、少しずつ身につけていくものです。
私が若手PMOの方に勧めているのは、「毎日一つ、気づきをメモする」習慣です。今日の会議で誰がどんな表情をしていたか、議事録のどこが分かりにくかったか、調整がうまくいかなかったのはなぜか。こういった小さな気づきを積み重ねることで、自然とスキルが磨かれていきます。
中小企業こそPMOの力が活きる
大企業にはPMO専門の部署がありますが、中小企業ではPMOがいないことも多いです。でも、実は中小企業こそPMOの力が必要なんです。リソースが限られているからこそ、プロジェクトを効率的に回す必要があるし、失敗が会社の存続に直結するからです。
もしあなたが中小企業のIT担当者で、「PMOなんて自分には関係ない」と思っているなら、それは間違いです。PMOのスキルは、プロジェクトを円滑に進めるための実践的な技術であり、規模の大小は関係ありません。
明日から取り組めることとして、私が勧めるのは「会議の決定事項を3行でまとめる習慣」です。難しいフォーマットは不要です。(1)何が決まったか、(2)誰がやるか、(3)いつまでか。この3つを会議後すぐにメモし、関係者に共有する。これだけでも、プロジェクトの混乱は大きく減ります。
PMOは「人」を見る仕事
最後に、30年この仕事をしてきて一番実感しているのは、PMOは結局「人」を見る仕事だということです。プロセスやツールも大切ですが、それ以上に、一緒に働く人たちの気持ちや状態に目を向けることが重要です。
疲れているメンバーに気づいて声をかける。対立している二人の間に入って話を聞く。不安そうなクライアントに丁寧に説明する。こういった「人としての関わり」が、プロジェクトを支えています。
PMOのスキルを磨くことは、突き詰めれば「人を理解する力」を磨くことです。技術も管理手法も、最終的には人が使うものです。人を見て、人の気持ちを理解して、人と人をつなぐ。これがPMOの本質だと、私は思っています。これからPMOとして成長したいあなたに、心からエールを送ります。
コメント