ユーザーサイドのPMOについて仕事内容や求人要件の具体例を交えながら解説

PMOはProject Management Officeの略で、その名の通りプロジェクト管理が主な役割となります。

ただし単純にプロジェクト管理といってもその業務は多岐に渡り、現場によっても違いがあります。

たとえばPMO関連の資格試験では、アドミニストレータ、エキスパート、マネジャーという職種が出てきます。

PMOメンバーの役割を分けて業務を効率化していけるメリットがあるため、このように職種を分ける場合があります。

そしてこれとは別に一つのプロジェクトの中にユーザーサイドとベンダーサイドのPMOという二つの組織ができることもあります。

今回はユーザーサイドのPMOについて具体例も交えながら解説します。

ユーザーサイドのPMOとは

ユーザーサイドのPMOとは、システムなどを発注する企業側でタスクや課題を管理する組織です。

ユーザーサイドPMOの役割について

企業側の立場で業務内容をよく理解し、課題や要望を把握してその解決策を模索していくことになります。

具体例としては、以下のようなプロジェクトで組織されます。

• 新規事業立ち上げ
• 社内業務改善
• ITシステム開発・導入

目的の明確化、要件や課題の整理、ソリューションの検討、などユーザーサイドPMOの役割は多岐に渡ります。

企業の業務担当者の目線でモノを考え、経営層、プロジェクトオーナー、システム開発者などと交渉していくことがポイントです。

ユーザーサイドのPMOに必要なスキルとは

ユーザーサイドのPMOは主に業務担当者の課題を解決していくことが役割になるため、その対象となる業務関連の知識や経験を持っていることが望ましいです。

しかし、それ以上にコミュニケーションスキルや理解力が重要になります。

ではなぜ業務知識よりもそのようなスキルが重要なのでしょうか？

一番の理由は、そのプロジェクトでしかキャッチアップできない知識というものが必ず存在するからです。

企業はそれぞれが持つ特有の価値観、文化、考え方をもとに仕事を進めています。

そのため、たとえ以前に同じ業界の別の会社での業務経験があったとしても、別の会社に転職してしまえば全く違う方法で仕事をすることもよくあります。

ユーザーサイドのPMOは新しいプロジェクトに参画するたびに、その現場での役割を理解し業務を学んでいかなければなりません。

業務担当者から情報をうまく引き出せるコミュニケーションスキル、詳細に現場課題を把握するキャッチアップスキル、課題を解決するための問題解決能力、などが強く求められます。

ユーザーサイドのPMOになるには

ユーザーサイドのPMOとして採用されるには、特に経験が重視される傾向にあります。

転職エージェントのユーザーサイドのPMO関連の案件も参考になるので、確認してみましょう。

PMOそのものが採用段階で経験面をもとに合否判定されることが多い職種ですが、ユーザーサイドとなると一層その傾向が強くなります。

普段から一人ではなくチームで推進する仕事に慣れておくことがおすすめです。

なぜユーザーサイドとベンダーサイドがあるのか？

ユーザーサイドとベンダーサイドの2つのPMOが組織されるプロジェクトもあるということに関して、疑問がある人もいるのではないでしょうか？

複数のPMOが導入されるプロジェクトではどんなリスクが予想される？

PMOが複数に分かれることでむしろデメリットが増えると感じる人も多いでしょう。

たとえば、2つのPMOの役割分担が曖昧になるといったことなどが予想されます。

PMOという組織はプロジェクトを管理する役割があることから、各部署やメンバーへの指示出しも仕事の一つです。

そのため、2つのPMOが存在するプロジェクトでは、指揮命令系統が複数できてしまいバラバラの指示を出してしまった結果、現場が混乱してしまうといったことがリスクになるでしょう。

二つのPMOは立場が異なる

しかし、実際には発注側と受注側で企業が異なりそれぞれの立場での管理が必要になるため、二つのPMOが存在すること自体は必然になります。

たとえば、システム開発・導入プロジェクトの場合、ユーザーサイドのPMOはシステム委託側の企業で組織されます。

業務面のタスクを管理し、その課題を解決できるITソリューションの知識なども必要です。

システムベンダ側へ詳細に業務要件を伝え、成果物であるシステムが正しく動作するか確認する役割も担います。

PMOが分かれることはメリットもある

また、PMOが分かれることにはメリットもあります。

特にPMOメンバーの人選を行いやすいことやプロジェクトの生産性を高めやすいことなどがそのメリットです。

ユーザーサイドとベンダーサイドはそれぞれ必要とされるスキルに違いがあります。

ユーザーサイドは業務面に加え、その課題を解決できるITソリューションの知識、スキルおよび導入経験などが必要です。

それに対し、ベンダーサイドのPMOはシステムベンダ側で組織されます。

ユーザー企業へのシステム導入を進める上でのより細かなタスクを管理することになります。

PMOの1日の過ごし方、具体例①

ユーザーサイドのPMOはプロジェクトの企画当初から参加することが多いです。

プロジェクトはフェーズに分かれており、それぞれのフェーズごとで一日の流れに特徴があります。

まずはプロジェクトの企画や要件定義の段階でよくあるPMOの一日を見てみましょう。

プロジェクトの企画段階は多くの組織と連携する

たとえば、以下のようなスケジュールで経営、業務、IT部門など多くのチームとコミュニケーションをとっていく必要があります。

09:00～10:00	その日の予定を確認する
10:00～12:00	マーケティング担当者との打ち合わせ、議事録作成
12:00～13:00	お昼休憩
13:00～15:00	システム担当者との打ち合わせ、議事録作成
15:00～16:00	タスクの割り振り、各部門への対応依頼
16:00～17:00	明日の準備
17:00～18:00	作業報告（必要に応じて打ち合わせ）
18:00～19:00	夕食
19:00～22:00	残業時間（その日に終わっていないタスクがあれば対応）

企画段階ではコミュニケーションスキルや情報を正確に管理できる力が必要

プロジェクト初期の企画や要件定義の段階では、他のフェーズとは違い連携する組織やチームが多種多様になります。例えば、以下のように他部門との連携が多数発生します。

• 市場ニーズを探るため、マーケティング担当に分析を依頼する
• データ分析の結果などをまとめて報告資料を作成し、経営層に判断を委ねる
• 会社としての方針を決定された後、具体的にどう実現していくのか業務担当者と仮で決定していく
• 必要であれば本段階で決定した内容が技術的に実現可能かどうかなどをソリューションの提供側（システム担当者など）に確認する

既存の問題をしっかり把握し、プロジェクト計画をまとめていきます。

将来的なビジネス要件も視野に入れて検討していく必要があり、プロジェクトの中でも難易度が高く重要なフェーズです。

そのため基本的にはPMOとして長いキャリアを持つベテランのコンサルタントがアサインされることになります。

PMOの1日の過ごし方、具体例②

システム開発プロジェクトのテスト工程の場合、ベンダの開発担当者やユーザーとなる業務担当者と実際にテストデータでシステムを操作し想定通りの動きをするかどうか確認することになります。

本フェーズでは、テスト作業、テスト結果、発見された不具合などをかなり細かい粒度で管理していくことになります。

効率化を考え、テスト作業を進行していく

以下は大企業にERPシステムを導入するプロジェクトでのUAT（User Acceptance Test）でのスケジュール例になります。

ERPシステムだけでなく連携先のシステムのテストも行います。

そのため、定例会議には多くの開発ベンダと業務担当者が参加します。

09:00～10:00	メールチェックなど
10:00～10:30	朝会（テスト定例）
10:30～12:00	タスク・課題に関する情報の確認および作業指示など（主にツール）
12:00～13:00	お昼休憩
13:00～14:00	不具合の報告と対応方針決定のための打ち合わせ
14:00～15:00	説明会の議事録作成、ToDo・依頼事項の対応
15:00～16:00	日時報告資料の作成
16:00～17:00	夕会（テスト定例）
17:00～18:00	明日の準備
18:00～19:00	夕食
19:00～22:00	残業時間（その日に終わっていないタスクがあれば対応）

特に大規模なシステム開発プロジェクトの場合、朝会、夕会を設定しテストを進めることが多いです。

テストデータの準備は開発担当者、実際にシステムを操作してテストするのは業務担当者、といった形で役割を分担し進めます。

朝会ではその日に実施するテストとその段取りの確認、夕会ではその日のテストの結果報告や不具合の報告および実施できなかったテストのリスケの相談などを行います。

他のフェーズとは違い、細かいマネジメントが求められる

テストフェーズでは、業務担当者が納得のいくテストができるようテスト要件やタスクを効率的に管理していくことがPMOの役割となります。

テストで確認したいポイントをはっきりさせ、検証すべき点を漏れなくスケジュール期間内で完了させるための段取りを組みます。

ある程度ITの知識、スキル、経験が必要です。

また、万が一大きな不具合が見つかってしまった場合、その対応を支援していくことも求められます。

PMOの1日の過ごし方、具体例③

業務改善プロジェクトやシステム導入プロジェクトでは、最後の方でトレーニングを実施します。

業務担当者が新しい仕組みやシステムを活用できるよう練習しておくことがポイントです。

成果物の適切な導入および問題点の洗い出しがPMOの役割

トレーニングの段階では、業務担当者が必要な資料やシステムを利用できるように準備することや、トレーニング段階で見つかった課題を管理することがPMOの役割になります。

09:00～10:00	メールチェック
10:00～12:00	資料を参照しながら業務担当者とトレーニングの実施
12:00～13:00	お昼休憩
13:00～15:00	トレーニングの振り返りと改善点の洗い出し
15:00～16:00	業務責任者への改善提案やシステム担当者へのフィードバック
16:00～17:00	システム操作説明書の修正確認
17:00～18:00	作業報告など
18:00～19:00	夕食
19:00～22:00	残業時間（その日に終わっていないタスクがあれば対応）

PMOには業務担当者と開発担当者の橋渡しの役割が求められます。

ユーザーにシステムを使ってもらうと問題が出てくることがあります。たとえば、以下がその具体例です。

• 開発者が作成した説明書がわかりづらいことがある
• 業務運用上そのロジックを詳細に確認すべき機能がある
• 使ってみた結果、機能改善が必要なことがある

PMOは業務担当者からの疑問や要望を把握し、開発者に相談・交渉をしながらシステムを適切に導入していくことが役割になります。

プロジェクトの目的を達成できているか確認する

基本的にトレーニングのフェーズはプロジェクトの最後で実施されます。

システム稼働前に業務担当者がわからないことを解消できることがトレーニングのメリットです。

なお、トレーニングの前にUATなど業務観点のテストは行っていますが、それでもトレーニング段階でシステム上の課題が見つかってしまうことはあります。

その場合、稼働前に修正することは現実的でない場合が多いです。

PMOの立場としては、プロジェクトオーナーなど責任者にエスカレーションし判断を仰ぐことになります。

よくある対処方法としては、システムで対応が難しい部分は業務側が手動で対応する、あまりにも業務負荷が高く手動対応が困難な場合は追加予算を投入してシステムを修正する、といった方法などが検討されます。

記事まとめ

今回はユーザーサイドのPMOについて解説しました。

ユーザーサイドのPMOはプロジェクトの根幹となる目的や要件定義を管理する組織であり、成功のカギを握っています。働きがいを感じやすい業務が多いことが特徴です。

ユーザーサイドのPMOを目指す場合は、ここで取り上げた具体例を参考に業務をイメージしながら資格試験などで学習を進めましょう。

【関連記事】合わせて読みたい