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

menuclear
ホーム > ブログ > 工藤 武久の記事一覧 > 【第83回】PMOとレンガ職人


【第83回】PMOとレンガ職人


ご訪問ありがとうございます!          < 前回 | 目次 | 次回 >

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

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

 

【 変化しつづけるPMOの役割 】

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

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

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

 

【 PMOとは 】

~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~・~
まずはPMOの一般的な定義から確認してみたいと思います。PMBOKガイド第5版には、PMOについて、次のように説明されています。(※1)

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

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

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

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

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

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

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

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

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

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

 

【 PMOとレンガ職人 】

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

1.マスタースケジュール、WBSやプロジェクト計画書の検討・作成・更新
2.進捗管理、変更管理など、プロジェクト運営ルールの作成と徹底
3.進捗会議などの会議準備、ファシリテーション、議事録作成
4.進捗報告書、品質報告書などの作成、報告
5.各チームや委託先からの進捗報告、品質報告への指摘、フォロー
6.リスク管理表や課題管理表の更新、フォローやエスカレーション
7.テスト計画、移行計画などの検討・作成・更新
8.ステアリングコミッティなど経営層への報告ドキュメントの作成
9.RFP作成、委託先ベンダーの選定に関するアドバイスや評価
10.レビュー記録、障害管理表などをもとにした品質評価
11.工程完了、移行判定、レビューチェックリストなどの策定
12.要件定義や設計レビューにレビュアとして参加

・・・

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

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

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

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

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

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

それでは次回もお楽しみに!          < 前回 | 目次 | 次回 >

工藤武久

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

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

| 目次

採用情報
PM-waigaya
PM-WaiGaya
コンサルタントのトーク動画
PM Weekly Talk
PM Weekly Talk
コンサルタントが語る「PMBOK®12 の原理・原則」

Profileプロフィール

Avatar photo
工藤 武久
■株式会社アイ・ティ・イノベーション  ■コンサルティング本部 - 東日本担当 ■学歴:早稲田大学 - 第一文学部卒業 ■メーカー系のシステム子会社にて、主に官公庁向け大規模システム開発プロジェクトに、SE、PMとして携わる。立ち上げから運用保守フェーズに至るまで、システム開発プロジェクトの幅広い実務経験を重ねた。 ■2007年より株式会社アイ・ティ・イノベーションにおいて、大規模プロジェクトにおけるプロジェクトマネジメント支援や品質管理支援等のコンサルティングを手がける。 ■PMP、情報処理技術者試験(プロジェクトマネージャ、システム監査技術者他)など。 ■Twitter:https://twitter.com/iti_kudot  ~・~・~・~・~・~・~・~・~・~ ■ ブログランキングに参加しています! ◆人気ブログランキングにほんブログ村 ↑是非応援(クリック)お願い致します↑ ~・~・~・~・~・~・~・~・~・~ ■主なタグ:統合, スコープ, タイム, コスト, 品質, 人的資源, コミュニケーション, リスク, 調達, ステークフォルダ

Recent Entries最近の記事