PMOは、企業内においてプロジェクト管理の支援を行う部署のことを指します。

PMOの主な役割としては、プロジェクトの進捗状況を把握し、問題が生じた場合に早期に対応し、プロジェクトの品質を向上させることです。

その中で、PMOの仕事内容はプロジェクトの内容やプロジェクトマネージャーから任される役割によって多種多様です。

Web系システム開発の管理、お客様の問い合わせ対応、業務効率化ツール作成、品質報告書の作成、システム移行推進・・・。

立ち上がったばかりのプロジェクトでは、思いも寄らない範囲まで業務を任される可能性もあります。

実はPMOの仕事の中には、資格や開発経験、サーバー構築経験などなくとも務まるものが多いです。

このような技術的な知識はプロジェクトアサイン時にキャッチアップできれば良く、PMOに必須なのはIT知識のないお客様やIT知識がMAXにあるエンジニアとの対話力・調整力となります。

本記事では、筆者の体験も含め、幅広く仕事内容を取り上げていきます。

記事を見て頂いている方ご自身の適正と合わせて向いている仕事かも見て頂ければと思います。

PMOの仕事内容

プロジェクトの管理の業務はどのプロジェクトも共通しているため、一度現場で流れを学ぶことができれば、他のプロジェクトでも応用可能です。

プロジェクト管理

プロジェクトの進捗管理

PMOは、プロジェクトの進捗状況を監視し、問題が生じた場合に早期に対応できるようにサポートします。また、システムの発注元へ定期的な報告を行い、プロジェクトの進捗状況や課題、リスクなどを報告します。

リスク管理

PMOは、プロジェクトのリスクを特定し、そのリスクに対する予防策や対応策を策定します。また、プロジェクトの進捗状況に応じて、リスクの評価や優先度付けを行い、プロジェクトのリスク管理に対する方向性を提供します。

プロジェクトの評価・改善

PMOは、プロジェクトの結果を評価し、プロジェクトの品質を改善するための施策を提案します。また、プロジェクトの評価結果に基づき、改善点を特定し、今後のプロジェクトに反映するための施策を提案します。このように、PMOは、企業内のプロジェクト管理において中心的な役割を果たし、プロジェクトの成功に向けた支援を行います。

プロジェクトマネジメント手法の策定・標準化

PMOは、企業のプロジェクトマネジメント手法を策定し、プロジェクトの管理プロセスを標準化することで、プロジェクトの品質を向上させます。このため、プロジェクトマネジャーやチームメンバーに対して、プロジェクトマネジメントの手法やツール、テンプレートなどを提供します。

資料・報告書の作成

システムの概要説明

PowerPointやExcelを駆使してお客様へシステムのフローを説明します。

こちらは文章の羅列でわかることでも、お客様はIT素人が多いため、図や表を用いて直感的にわかるような資料を作成する必要があります。

プロジェクトによっては、開発担当のエンジニアが作成する場合もあります。

週次・月次報告資料

プロジェクトの進捗状況や課題をお客様と共有し、随時解決できるよう提案していきます。

品質分析結果も一緒に報告するところも多いです。

工数見積もり

開発の規模やメンバーの工数などを見積もりとして提示します。

金額に対する妥当性の根拠を挙げる必要があり、内部での話し合いが重要です。

移行計画の策定

システムやサーバーを移行するためのスケジュールを提示します。

お客様の業務を停止する必要も出てくるため、お互いに認識の齟齬がないように作成していきます。

品質分析

システムの品質分析とは、システムがその目的を達成するための能力や信頼性、保守性、使いやすさ、安全性などの側面を評価するプロセスです。

品質分析は、システムの欠陥や問題点を特定し、改善のためのアクションを提供することが目的です。

システムを開発する工程またはリリース後に障害が発生した際、その原因や対策・再防止策を考えてお客様へ説明する必要があります。

大規模なプロジェクトでは品質管理部門が整備されている場合もあるのですが、中〜小規模の開発プロジェクトではそのようなものはなくPMOが担う場合があります。

私が実際にアサインしたプロジェクトでは、品質分析や障害に対しての横展開対策もお客様へ報告する必要があり、開発担当のエンジニアへよく障害発生原因についてヒアリングしてました。

また、私は幸運なことに開発経験があったため、設計書やソースもレビューしつつ、エンジニアとスムーズな会話ができてました。

システムの品質分析には、さまざまな手法や技法がありますが、一般的には以下のようなものになります。

開発レビュー結果の集計

設計や製造工程ではどのような障害が多いのか、集計して傾向を分析、横展開を指示したり注意点をまとめて共有したりします。

設計〜テストの工程で障害0件ということはよっぽど簡単なプロジェクトでない限りありえないため、大量に出てきても落ち着きましょう。

成果物（設計書・ソース）レビュー

ソフトウェアの設計文書やコードなどの詳細を精査することで、問題点を特定し、改善のためのアドバイスを提供します。ロジックの誤りや類似したバグが多い場合には横展開調査を命じることもあります。

レビューの前提としては、仕様を深く理解することが必須のため、短期のプロジェクトでは早期理解が求められます。

テスト観点の確認

単体テスト、結合テスト、システムテストなど実施する場合、各工程で確認する観点が正しいか確認します。

単体テストの場合にはデータパターンの網羅性の担保、結合テストの場合には機能同士のデータの受け渡しのケースに漏れはないかなど確認します。

また、PMOは開発エンジニアとエンドユーザーに寄り添う位置に立つことが多いため、ユーザー目線でも確認できるとベストです。

PMOは常に問題の顕在化と改善策のシナリオを考えよう

プロジェクトには必ず課題や問題が発生します。そして厄介なのがその問題に対し、100点満点の解決策がないことと、プロジェクトマネージャーも開発エンジニアもスケジュールに追われ、頼れるは自分だけという状況が多いです。（自分もスケジュールに追われてるのですがww）

そのようなシチュエーションが多いことからPMOという役割のもと、積極的に問題を解決してくれる方は重宝されます。

私の場合ですが、問題発生〜対策・再発防止や改善策はセットとみなし、一連のシナリオとして内部の方やお客様へ説明していました。

経験していくほどシナリオは思い浮かびやすくなりますが、最初はそううまく行かないため、ネットでも資格でも本でもなんでもよいので、日々自分の興味あるIT知識は蓄えておくのが吉です。