DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

ご訪問ありがとうございます！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

システム開発の現場には、いわゆるＰＭＯと呼ばれる人たちが、発注側にも受注側にもいるのが普通になってきました。私は長年システム開発プロジェクトの現場に携わってきましたが、特にアイ・ティ・イノベーションに所属するようになってからは、いわゆるＰＭＯという立場で仕事をすることがほとんどです。

これまでの経験を通して感じることは、同じＰＭＯという立場であっても、ご支援するお客様によって求められること、というかご支援するお客様の状況に応じてご支援すべきことは千差万別であり、いわゆるＰＭＯとは何かを説明するのは、そんなに簡単なことでは無いということです。。。

【　変化しつづけるＰＭＯの役割　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
既にお気づきの通り、ここまでＰＭＯの前に「いわゆる」という修飾語をつけてきました。その理由は一般的に言われているＰＭＯの定義と実際のシステム開発現場でいわゆるＰＭＯと呼ばれている人たちが行っていること（または期待されていること）の間に、なんとなくずれが生じているように感じているからです。

これまで当ブログで取り上げてきた、たとえば、品質、リスクなどといった用語と同じように、ＰＭＯという用語も当たり前に使われるようになってくるにつれ、それぞれの立場の人たちによって都合の良い解釈が行われることで、さまざまな意味が付与されてきたと私は考えています。

その背景には、システム開発のプロジェクトをめぐる時代の変化が影響していることは言うまでもありません。そして、もちろんこれから先も時代は変化しつづけるのであって、その変化の中でいわゆるＰＭＯに求められるものも変化し続けるということを認識する必要があるのです。

【　ＰＭＯとは　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
まずはＰＭＯの一般的な定義から確認してみたいと思います。PMBOKガイド第5版には、ＰＭＯについて、次のように説明されています。（※１）

プロジェクトマネジメント・オフィス(PMO)は、プロジェクトに関連ずるガバナンス・プロセスを標準化し、資源、方法論、ツール、および技法の共有を促進するマネジメント構造である。PMOの責任は、プロジェクトマネジメントを支援することから、ひとつ以上のプロジェクトを直接マネジメントするまでの広範囲にわたる。
組織におけるPMOの構造にはいくつかのタイプがあり、それぞれが組織内でのプロジェクトに対し、異なる度合いのコントロール力や影響力を持っている。PMOには次のタイプがある。
・支援型　支援型PMOは、テンプレート、ベストプラクティス、トレーニング、他のプロジェクトからの情報や教訓へのアクセスを供給することにより、プロジェクトに助言を与える役割を担う。この種類のPMOは、プロジェクトのレポジトリとして機能する。PMOによるコントロールの度合いは低い。
・コントロール型　コントロール型PMOは、支援を行うと共に、さまざまな手段を通してコンプライアンスを要求する。コンプライアンスには、プロジェクトマネジメントの枠組みや方法論を採用すること、特定のテンプレート、フォーム、およびツールを使用すること、またはガバナンスへの適合を含むことがある。PMOによるコントロールの度合いは中程度である。
・指揮型　指揮型PMOは、プロジェクトを直接マネジメントすることでプロジェクトを掌握する。PMOによるコントロールの度合いは高い。

ここまでの説明を読んだだけでも、ＰＭＯの責任は広範囲にわたることがわかります。そして、プロジェクトへの関わり方も多岐にわたるのです。実際、私が実プロジェクトのご支援に携わってきた中でも、さまざまな関わり方をしてきました。

たとえば、受注側のＰＭＯとして、各チームや再委託先の進捗や品質状況を確認して発注側への進捗報告書や品質報告書をとりまとめたり、場合によっては受注側のプロジェクト・マネジャーの代わりに進捗報告を行ったりしてきました。また、発注側のＰＭＯとして、ユーザー部門の進捗フォローを行ったり、プロジェクト・マネジャーの参謀役を務めたり、プロジェクト・マネジャーに成り代わって直接プロジェクトメンバーへの指示やフォローを行ったり。。。

とにかく、そのプロジェクトが前に進むために必要なことを探り当てながら、その中で優先順位を判断し、時には立ち位置を変えながら、動いてきたという感じです。

もう少し、PMBOKガイドの記述を読み進めてみましょう。

ＰＭＯの最も重要な機能は、さまざまな方法でプロジェクト・マネジャーを支援することである。支援方法には次の事項が含まれるが、これらに限定するものではない。
・ＰＭＯ管轄下のすべてのプロジェクトで共有する資源のマネジメント
・プロジェクトマネジメントの方法論、ベストプラクティス、および標準の特定と開発
・コーチング、メンタリング、トレーニング、監督
・プロジェクト監査による、プロジェクトマネジメントの標準方針、手順、テンプレートの順守状況の監視
・プロジェクトの方針、手順、テンプレート、その他共有する文書（組織のプロセス資産）の策定とマネジメント
・プロジェクト間のコミュニケーションの調整

プロジェクト・マネジャーとＰＭＯとは異なる目標を追い求めており、それゆえに異なる要求事項に基づいて行動する。両者の行動はすべて組織の戦略のニーズに沿ったものである。プロジェクト・マネジャーとＰＭＯの役割には、以下の相違がある。
・プロジェクト・マネジャーは、特定のプロジェクト目標に焦点を当てる。一方、ＰＭＯはビジネス目標をよりよく達成する潜在的な好機として、主要なプログラム・スコープの変更をマネジメントする。
・プロジェクト・マネジャーは、最もよくプロジェクト目標を達成するために、割り当てられたプロジェクト資源をコントロールする。一方、ＰＭＯは、すべてのプロジェクトに対して、組織内の共有資源の使用を最適化する。
・プロジェクト・マネジャーは、個々のプロジェクトの制約条件（スコープ、スケジュール、コスト、品質など）をマネジメントする。一方、ＰＭＯは、組織体レべルでの、方法論、標準、包括的リスクや好機、メトリックス、およびプロジェクト間の相互依存関係などをマネジメントする。

ＰＭＯはプロジェクト・マネジャーを支援するものであり、その目標は個々のプロジェクトの成功に閉じたものでなく、より広範なもの、別な言い方をすると、客観的視点を持ち合わせるものといったところでしょうか？

確かに、私がアイ・ティ・イノベーションで行ってきた仕事を振り返ると、発注側でも受注側でも、ご支援を行うお客様のプロジェクト・マネジャーの方をご支援するということが多く、そのご支援内容としては、私がこれまでの長いシステム開発プロジェクトに携わった経験で得られた知識やノウハウなどを活用して、客観的な視点でアドバイスをしたり、プロジェクト計画書やマスタースケジュールなどのドキュメント作成のお手伝いなどをしてきました。

こうしてPMBOKガイドの記載内容と照らしてみると、私が行ってきたことは、PMOの活動が中心だったと考えても間違いなさそうですね。。。とすると、前章で説明した一般的なＰＭＯといわゆるＰＭＯが行っていることにずれがあると私が感じているのは、どこから来ているのでしょうか？

【　ＰＭＯとレンガ職人　】

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
いったん、PMBOKガイドのＰＭＯの定義から離れて、これまで私がＰＭＯの立場で主に実施してきたことを思いつくままに列挙してみます。

１．マスタースケジュール、ＷＢＳやプロジェクト計画書の検討・作成・更新
２．進捗管理、変更管理など、プロジェクト運営ルールの作成と徹底
３．進捗会議などの会議準備、ファシリテーション、議事録作成
４．進捗報告書、品質報告書などの作成、報告
５．各チームや委託先からの進捗報告、品質報告への指摘、フォロー
６．リスク管理表や課題管理表の更新、フォローやエスカレーション
７．テスト計画、移行計画などの検討・作成・更新
８．ステアリングコミッティなど経営層への報告ドキュメントの作成
９．ＲＦＰ作成、委託先ベンダーの選定に関するアドバイスや評価
１０．レビュー記録、障害管理表などをもとにした品質評価
１１．工程完了、移行判定、レビューチェックリストなどの策定
１２．要件定義や設計レビューにレビュアとして参加

・・・

とりあえずこれぐらいにしておきましょう。なんとも雑多にいろいろなことを行ってきた感じです。この中で、たとえば、テスト計画、移行計画や最後のレビュアとして参加などは、一般的なＰＭＯの役割から少しずれているようにも感じられませんか？どちらかというと、システム・エンジニアとかプロジェクト・リーダとかが実施するもので、ＰＭＯが行うものでは無いような気もします。

逆の見方をすると、テスト計画、移行計画やレビュア以外についても、必ずしもＰＭＯが実施しないといけないタスクではなく、システム・エンジニアとかプロジェクト・リーダが実施しても不思議ではないように思えます。

ということは、ＰＭＯが行うタスクという明確な範囲は無く、システム開発プロジェクトの中で共通的に実施するようなタスクで、特に引き取り手があまり明確ではないタスクをひろうのがいわゆるＰＭＯの役割である、またはそう期待されているのが現実なのではないでしょうか？ＰＭＯはいわゆる「なんでも屋」であるというのが、事実なのではないでしょうか？

ＰＭＯは「なんでも屋」では無いという論調もよく耳にしますが、私は逆にＰＭＯは「なんでも屋」であるべきではないかと考えたくなるときがあります。プロジェクトを成功に導くため、また、組織としてのプロジェクト成功率を高めるためにできることは何かを探って、それを実践していくこと。これがＰＭＯに求められることでは無いかと考えています。

たとえば当ブログの　【第６６回】プロジェクトを動かす「攻めの議事録」　で示したように、議事録作成という事務的とも思われる仕事であっても、プロジェクトを成功に導くための「攻めの議事録」として活用することもできるのです。要は、イソップ物語に出てくる「３人のレンガ職人」の教訓のように、ＰＭＯの役割を考えるときには、何を行っているかということよりも、何のために行っているか、目的や目標をしっかり意識することが大切なのです。

「ＰＭＯとして最も大切なことは、プロジェクトを成功させるという目的を見失わないこと！」

それでは次回もお楽しみに！　　　　　　　　　　＜　前回　｜　目次　｜　次回　＞

工藤武久

～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～
応援してくださる方は、クリックよろしくお願いします！
◆　人気ブログランキング
◆　にほんブログ村
～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～・～

※１　Project Management Institute, Inc.(2013)『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）』（第5版）Project Management Institute, Inc.