コラム「ミニ講座」

2011/09/01　第１６話「PMOの存在意義」

　私のコンサルティングコアサービスの一つに、PMO（プロジェクトマネージメントオフィス）支援があります。

　以前このコラム連載でPMOについて少し触れたことがありますが、その時の読者さんからの反響は、PMOの本来の存在価値を理解し、共感なりご意見なりいただいた方、その一方、PMOってどういう役割なのかわからない、PMOという言葉を初めて聞くという方もいらっしゃいました。まだまだPMOの役割や存在意義などは、社会に一般的には認知されていないようです。そこで改めて、今日はPMOについて書いてみようと思います。

　まずPMOを端的に言うと、「複数人のプロジェクトマネージャーによって、プロジェクト遂行のための様々なマネージメント業務を組織的にこなすグループ」のことです。さっぱりとした表現ですが、そのグループがこなす役割となると多岐にわたります。

　PMOは、ITシステム開発プロジェクトだけでなく、事業活動の中でたくさんの方が関わり一つの目標に向かって行動する（たとえば、売上改善に向けた特別施策の企画実行、大きな工事案件や医薬品開発など普段の事業活動そのものがプロジェクトとして行われる場合など）、そのどこにでも、いわゆるPMOという役目の組織は活躍します。私自身の経験の中では、ITシステム開発プロジェクト体制の中に設置されるPMOに関わることが多いので、このコラムでは主にこのケースを前提に実体験を踏まえてお話しますが、日本の企業ではまだまだPMOへの馴染みは薄く、プロジェクトが火を噴いてはじめてその役割の重要性をだんだん認識していただいているのが現実です。

　一般的にPMOの役割として、プロジェクト全体の進捗管理、チームや組織・部門・会社間にまたがる課題解決、情報共有ナレッジマネジメント、要員管理、会議の開催など上げられますが、実際にどんな役割を担うかは、プロジェクトの特性、規模、関わる開発ベンバーやパートナー企業、その構成メンバーによって適宜変化します。また、ユーザーの企業文化や経営陣の考え方なども考慮に入れ、柔軟に抜け目なくタスクとメンバーの選定が必要になります。この見極めが最初の鍵であり、その任に着いた者が自分の役割を理解し着々と遂行できるかどうかで、そのプロジェクトが成功するかどうかが決まると言っても過言ではないでしょう。

　PMOの設置は、システム開発ベンダーが中心と導入を進めるケースが多いのが現状ですが、本当はユーザー企業にこそ、PMOの価値を認識してもらい、ユーザー側主導でPMOメンバーアサインが出来るくらいの能力を持つべきだと思います。それは、システムを作ることではなく使いこなすことが目的であり、その中心がもちろんユーザー企業の方々だからです。

【PMOの役割と体制】
　PMOはどんな形でプロジェクト体制に組み入れられ、どんなことを行うのでしょうか。
　PMOの役割は、先ほど述べたようにプロジェクトにより内容も色も違い、それに応じたPMOメンバーが必要になります。

　ここ数年のシステム開発プロジェクトでは、上図のどちらかのPMOという体制（チーム）を設置することが多くなりました。図１と図２の大きな違いは、開発ベンダー以外の企業が、PMOタスクを担うメンバーとして参画するところです。開発期間も長くいろんな人が関わる大規模プロジェクトであれば、図２のような体制の良さが発揮されます。
第３者を入れることのメリットは、ユーザー企業、開発ベンダー、どちらの味方にもなれることです。味方という表現がおかしいかもしれませんが、一つ離れたところから冷静に判断をすることが出来る、両社の立場を理解する余裕があるということです。ユーザー企業は自社内の経営層や業務部門からのプレッシャー、大きな投資額に見合う目標達成など、様々な背景があるでしょう。また開発ベンダーは、まずは納期厳守。なるべく責任を開発側に残さないようにすることに精を出すでしょう。そんな中で、業務側とシステム側がお互いの事情を言いあうことにならないためにも、第3者がうまく潤滑油となり冷静な指南役になれば、いいバランスのPMOとして機能することになります。ユーザー企業は自分の土俵でない細かいシステム論で頭を痛めることもなく、また、開発ベンダーは得意分野である開発作業に集中することができるというメリットもあります。
プロジェクト全体のリスク（将来起こりうるものも含め）や、ユーザー社内の上層部との橋渡し、システム部門と業務部門の関係など、システム開発にどっぷりと長年ハマってきたメンバーより、ずっと冷静に見渡せるものです。
私の経験の中でも、かえって社員どうしだと発言を遠慮してしまう、社員じゃないから言いやすい、社内の人間が言っても無駄だと諦めている、こんなことも耳にすることはよくあります。そんな時こそ、いかに話しやすい（情報を引き出す）雰囲気を作り出すかも第三者として入るPMOメンバーとしての大切なスキルだと思います。

【プロジェクトの現場で思うこと】
（プロジェクト進捗会議で・・・）
まあ確かにウソではないんだけどなんだかごまかされているような気がする、そんな時ありませんか？根拠は曖昧だけど、開発ベンダーから発せられる言葉の最後は「でも、大丈夫です。問題ないです」。その言葉を信じるしかなく、気付いた時には課題が先送りとなっていただけで、しだいにお互いの不信感になる。開発ベンダー側にしてみれば、万一雲行きが怪しくても進捗会議では当たり障りのないことを言って取りつくろいたい、火種を増やしたくないと思うのが心理だと思います。PMOの役割は、そんなことにならないように、納得行くまで根拠を突き詰めることなのです。その時に、ちゃんと指摘し対応ができる人間をPMOに配置することを忘れてはいけません。

（プロジェクトの外でも・・・）
実際に動かなくなるプロジェクトも、実は開発現場だけの問題じゃないところがあります。企業文化や人の繋がり（しがらみ）、経営陣の考え方が、激しくプロジェクトに影響することがあります。普段から経営陣に対してプロジェクトの状況をちゃんと報告し認識してもらっていないと、経営陣もちゃんとした判断が出来ず、思いもよらないどんでん返しを食らうこともあります。
経営陣が考えることは、システム開発プロジェクトをうまく終えることではなく、その巨大投資に見合う売上が見込めるかどうか、目論む戦略に必要な投資であるかどうかだけなのです。投資に見合わなければ、NGを突きつけるのは当たり前だからです。今まで必死に頑張ってきた現場にとっては、経営陣の気まぐれに付き合わされていると誰もが不幸な思いをするかもしれません。ですから、IT部門と経営層の情報共有がもともと薄い会社であればなおさら、そこを手厚くフォローするのもPMOの重要な仕事となります。

　今日のコラムは少し長くなってしまいました。ここまでお付き合い頂いて、ありがとうございます（笑）。

　最後に、PMOは、そのプロジェクトに関わっているすべてのメンバーがいかに効率的に能力を発揮し、生産的に質の高い成果物を作るために円滑にプロジェクトをナビゲートしなければなりません。人の個性を見抜いて、モチベーションと生産性が上がるように誘導するのも大きな仕事です。PMは管理することが重要な仕事ですが、管理する人される人と、意味のない上下間で仕事のしにくい環境を作るのではなく、ちょっとした言葉の使い方で気持ち良く仕事が進む環境つくりも大切です。なかなか奥の深い仕事・・・。