PMO案件の主な仕事内容
PMO案件では、プロジェクト全体や複数ラインの状況を可視化し、意思決定に必要な情報をそろえる役割が中心です。WBSの整備、進捗・課題・リスクの集約、定例会の運営、関係者へのエスカレーションなど、推進の土台を作る業務が多く見られます。
領域はアプリ開発からインフラ移行、基幹刷新、SaaS導入、運用立ち上げ、品質管理まで幅広く、プロジェクトのフェーズも要件定義寄りから実装・テスト・移行寄りまでさまざまです。特にテスト計画や移行計画の策定・実行管理、品質指標の収集と分析、ベンダー成果物のレビューを担うケースが目立ちます。
また、ユーザー側（情シス・業務部門）の社員代替として、ベンダーと業務部門の橋渡しをする案件も多い傾向です。要件調整の場づくり、合意形成のための論点整理、報告資料の作成などを通じて、現場が止まらないように実務を巻き取って前に進めます。
PMO案件で求められる必須スキル
必須として挙がりやすいのは、進捗・課題・リスク管理を中心としたプロジェクト管理の実務スキルです。単に表を更新するだけでなく、遅延要因の特定やフィージビリティの確認、打ち手の提案まで踏み込めることが期待されます。会議体の設計、ファシリテーション、議事録からアクション管理までを一連で回せる力も重要です。
次に、ドキュメンテーション能力が強く求められます。定例報告、上位層向けの説明資料、計画書や管理資料の整備など、読み手に合わせて要点を構造化し、判断しやすい形にまとめるスキルが評価されやすいです。Excel関数や集計、PowerPointでの可視化が前提となる現場も見られます。
さらに、利害関係者が多い環境での調整力が欠かせません。顧客・業務部門・開発ベンダー・運用部門などの間で前提や言葉のズレを整え、決めるべきことを期限内に決めるための段取りを組む力が必要です。案件によっては、開発やインフラの基礎理解、要件定義からテストまで工程の成果物イメージを持っていることも必須条件として扱われます。
歓迎要件・評価されやすい経験
歓迎要件としては、ベンダーコントロールやマルチベンダー統制の経験が挙がりやすい傾向です。成果物レビュー、是正指示、品質や進め方の改善提案など、開発・インフラいずれの案件でも「相手のやり方を尊重しつつ、必要な基準に揃える」経験があると強みになります。
テスト・移行に強いPMO経験も評価されやすく、テスト計画の策定、品質指標の設計と分析、不具合傾向の可視化、UAT運営、移行手順の整備と実行管理などが該当します。品質管理PMOとして数値収集から分析・報告を担う案件もあり、定量で語れる経験は応募時の説得力になりやすいです。
ドメイン面では、金融（生保・損保・銀行・カード）、小売・EC、公共、製造などの業務知見が歓迎されることがあります。また、英語での調整や海外ベンダー対応、グローバル拠点との会議運営が求められる案件も見られるため、読み書きだけでなく会議でのファシリテーション経験があると選択肢が広がります。
開発環境・技術スタックの見方
PMOは実装を担当しない案件も多い一方で、技術スタックの理解が求められる現場が一定数あります。たとえばAWSやAzureなどクラウド移行のPMOでは、ネットワークや移行設計、設計書・手順書のレビューを行うため、構成要素や用語を理解しているほど意思疎通が速くなります。
アプリ開発寄りのPMOでは、ウォーターフォールの成果物（要件定義書、設計書、テスト計画/仕様書など）をレビューする場面が多く、JavaやSQL、Webアプリの基本構造を把握していることが前提になりやすいです。Gitやチケット管理ツール（Jira、Backlog、Redmine、Confluence等）が環境として登場するため、進捗・課題の見える化をツール運用に落とし込めるかがポイントになります。
また、SaaS導入や業務基盤系では、Salesforce、ServiceNow、Zendesk、kintone、Microsoft 365、Google Workspaceなどの名前が出ることがあります。PMOとしては製品操作よりも、Fit&Gapや運用設計、データ移行・連携方針の整理、関係者への説明責任を果たすための理解が重視されるため、どこまで踏み込む役割かを読み解くことが大切です。
参画前に確認したいポイント
まず、PMOの立ち位置を確認することが重要です。全体統制型（横串で標準化・品質管理を担う）のか、ラインPMO型（各チームの実態を収集し全体へ連携する）のか、あるいは事務局寄り（会議運営・資料整備中心）なのかで、求められる深さが変わります。担当範囲が進捗・課題管理までか、品質・変更・構成管理まで含むかも事前に合わせておくとミスマッチを減らせます。
次に、フェーズと成果物の責任範囲を具体化しておくのがおすすめです。要件定義の支援や仕様整理を求められるのか、設計～テストでのレビュー推進が中心なのか、移行・運用立ち上げまで関与するのかで、必要な準備が異なります。特にテスト計画・移行計画の策定が含まれる場合、誰が最終責任を持ち、PMOがどこまで作るのかを確認しておくと動きやすくなります。
最後に、関係者構造とコミュニケーションの前提を確認します。マルチベンダーか、ユーザー側社員代替か、海外ベンダーや英語会議があるか、定例体の頻度と意思決定者は誰かといった点で、求められる調整の難易度が変わります。ツール面では、課題管理・ドキュメント管理の運用ルールが既にあるのか、これから整備するのかを押さえると、参画直後から優先順位を付けて動けます。