プロジェクトマネジメント

プロジェクトを構成する人たち-PMO

プロジェクトを構成する人たちとして、主な構成は前に書きましたが
その他にも色々な立場の人がいます。
その中で「PMOって何する人なんですか?」という質問を受けたので
今回はPMOについて少し書いてみます。

PMOは「プロジェクトマネジメントオフィス」の略で
プロジェクト全体の品質チェックだったり進捗確認をしてくれる人達になります。
ただ、ちょっと立ち位置が他のポジションと違う事が、
この役割をわかりにくく、活躍させにくくさせていると思います。

プロジェクトを進めていると突然、PMOを名乗る人たちから
・手順書の品質が悪いから是正してください
・WBSの引き方がおかしいので、妥当な線を引いてください
・開発プロセスは省略せずに、手順を守って下さい。
等々のダメ出しメールを受け取ったことがあるかもしれません。
「なんだ?突然現れたこの人たちは?いきなりメール送ってきて」
と思うのは、当たり前といえば当たり前で
この人たちは、プロジェクトの当事者という扱いではありません。
設計をするとかユーザーにヒアリングをするとか、
そういうプロジェクトの進捗を進める実務に携わるリソースとしてはカウントされない
言わば、お目付け役のような人たちです。

そんな彼らが設置される目的は

プロジェクトの健全性を保つこと

です。
平たく言うと、次から次へと湧き出るタスクに押されておろそかになりがちな
品質問題や、プロセスの健全性をチェックして、
システムがブラックボックス化するのを防いだり、
誰も承認していないような機能のリリースを防いだりする
といったところです。
会計監査のプロジェクト版みたいな感じと言ったらわかりやすいでしょうか。

プロジェクトに携わった人なら誰しも経験があると思いますが
カットオーバー間近になると、みんな最後の総仕上げでタスク山盛りで
一分一秒も無駄にできないような空気感が満載です。
そうなるとどうしても、
「あー、これチームリーダーに話を通しとかないといけないけど、そもそもプロジェクトリーダーに直接言われた奴だし、もういっか、端折っちゃお。」
とか
「あー、これ先に手順書作らないといけないんだけど、もう時間ないから手順書は後!どうせ誰も見ないでしょ」
っていう状況になりがちです。
この状況に対してストップをかけるのがPMOです。

いや、ちゃんと手順書書いて、それの承認を得たのちにリリースしてください。

PMO

いや、もう時間ないんだって。明日にはリリースしないといけないんだから!

担当

じゃあ、今日中に手順書を作って下さい。

PMO

!!

担当
というようなことを言ってくる人たちです。

べき論を主張してくる人達(立場)なので
立て込んでいるときに現れると、かなり神経を逆なでされます。
そして、間の悪い事にこの人達は立て込んでいるときに現れます(笑)

ここまで書くと
確かに煩わしい人たちのようですが、
必要性はある、というかとても大切な組織です。
上記の例でもそうですが、
手順書をその時に作らなければ、どうしても後回しになってしまい、実際の引継ぎの際などに相当困ることになりますし
然るべき人に承認を得ないで機能をリリースしたりすると、その機能が後で問題を起こした際に、深刻な責任問題になります。
ただ、問題は現実としてPMOが本来の役割としてあまり機能していないことになるでしょう。

ただこれも、考えてみれば当たり前と言えば、当たり前で
プロジェクトの健全性を保つのがPMOの役割でそれがきちんと機能していたら、
世間にこれだけ失敗プロジェクトが溢れかえっているはずはないはずです。

PMOという組織がきちんと機能していない理由は
そこに所属している人たちに問題があるというよりも
PMOという組織が言うは易し行うは難しの代表のような存在だからです。
成立させるのがとても難しいとも言えます。

その理由としては

第1の理由

PMOに適切な人材を配置しずらいという点

PMOはプロジェクトの健全性を保つのが仕事なわけですから、
管理する対象である「プロジェクト」の状況を適切に把握しないといけません。
その為にはプロジェクト管理とは?ということを、深く理解していなくてはいけません。
しかし、プロジェクト管理がきっちりできる人が社内にいた場合
その人をPMなりPLなりに据えずに、敢えてのPMO!
というような大胆な配置をする会社はなかなかありません。
例えていうなら、チームで最も打率も打点も高い選手をわざわざコーチに置くようなものです。
結果的に、PMOにはプロジェクト管理経験が豊富ではない人が配置されがちになっています。
となると、どうしてもマニュアル的に判断しがちなシーンが増え、
プロジェクトの健全性を担保したいはずなのに、
そこに貢献できず、ただ煙たがられるだけという結果になりがちです。

第2の理由

ステークホルダー達がPMOというものを正しく理解していないという点

PMOというのはプロジェクトマネージャ(以下、PM)、プロジェクトリーダー(以下、PL)の代わりにはなりません。
PMOはPMOとして存在するから意味があり、PM、PLの代替ではありません。
PM、PLがスキル不足だから、PMOを設置して何とかしようとするのであれば
その何とかさせようとしているPMOのメンバーからPM、PLを任命すればいいわけです。
にも拘わらず、PMOを設置して、プロジェクトを何とかしようとするのは、完全に目的を見失っているといっていいと思います。
彼らが期待してるようなことはPMOにはできませんし、するべきでもないと思います。

第3の理由

PMOという組織がいる前提でプロジェクトの体制が考慮されていないという点

第2にも関連しますが、PMOはPM、PLの代わりにはならず(なってはいけない)
プロジェクトのピーク・オフピークを問わず、
健全性を保てるように助言する、サポートする立場でなくてはいけません。
PMOは何をする人という定義をプロジェクト開始時にきちんと定義し、PM、PL、メンバーにきちんと理解させ、プロジェクト初期からきちんと参画させなくてはいけません。
なんとなくプロジェクトの健全性を保つために、組織化したはいいものの
PMOに任命された人も含め、具体的に役割についての指示をされていないというシーンはよく見ます。
結果、周囲はPMOをどう頼ったらいいのかわからないし、PMO自身もどこにどこまで介入したらいいかわからないという状況になってしまったりします。
ありがちなのが、プロジェクト終盤になって突然、成果物やプロジェクトの品質が気になった偉い人が、PMOに品質チェックしろと指示を下して、PMO自身も「あ、今からそれをすればいいのね。」解釈し、突然介入し始めるというケースです。

これらの理由からPMOは非常に機能させにくい組織ではあるのですが
その意義自体は重要です。
あくまで私見になりますが、この難しいPMOを正しく運用するためには

会社としてITプロジェクトが立ち上がる際にはPMOが必ず設置されるという前提で体制構築をするという「文化」が必要

だと思っています。
プロジェクトに必須の組織としてPMOがいる。体制図の最初に何はともあれPMOは記載するみたいなことですね。

PMOはPMOとしてプロジェクト初期から参画し、自社標準に沿った開発プロセスを踏襲しているかチェックします。それは会社の中に動いているプロジェクトの大小を問わず、やらなくてはいけません。PMOという存在がITプロジェクトには必ず存在していて、彼らがルールブックであり、プロジェクトの作法などは彼らに確認すべきという文化が醸成されて初めてPMOはPMOとして機能します。

そういう意味でPMOを社外の人間に発注することもあります。
PMOの活動自体は上に述べたようにルールブックとしての役割ですから、極端な話、自社の業務に精通していなくても、「プロジェクトは何か?」が理解できていれば務まるからです。プロジェクト管理に精通した人間・組織を社内で調達するのは難しくても、外部からであれば調達可能なシーンはあります。

しかし、これはこれで別の問題があります。
それは社外の人間はあくまで社外の人間だからです。
ただでもPMOは口うるさい監査役の立場で物を言ってくるので
プロジェクトの実務を進めている人間からすれば、
「そんなことはわかっている。わかっているが、リソースも時間も足りない現実を見ろ!」と言いたくなるような事を言ってきて、煙たがられ、嫌われやすい立場の人間です。
これをよそからやってきた人間がやり始めると、その思いはさらに加速します
「は?何も知らないくせに、よそからやってきて何言ってんの?」
と思われ、聞く耳を持たなくなります。
こうなると最早、組織としてそこにあるだけで役に立たず、ただただコストがかかるだけになってしまいます。

PMOは口うるさく、正論を振りかざす役割なので
プロジェクトメンバーとの信頼性が必要です。

これを外部の人間に委託しようとすると、さらに難易度は上がってしまうため
設置するのであれば、内部の人間のほうがいいと個人的には思います。
そして「プロジェクト管理とは?」ということがよくわかっている人間であり
つらい時にメンバーに寄り添い、励まし、耳に痛いことを口にする
そういう人間でなくては、なかなか務まりません。

さて、ここまで書くと、PMOってその特性や役割を考えると、組織化するのは会社としてある程度覚悟のある組織であるということがわかってもらえるのではないかと思います。
じゃあ、

思い切って、もうPMOは設置しない。という選択肢はないのか?
というと、そういう選択肢は十分にあると思います。

正直、今の日本のITプロジェクトにおいてPMOって必要か?
と思うと個人的にはそうは思いません。
ここまでに述べたように、PMOというものが機能する文化が醸成されていませんし
そんな中でPMOを設置しても、コストパフォーマンス悪すぎますし、乱暴な言い方をすると優秀なPM、PLがいれば組織としてPMOが存在しなくても、PLの子分を増やしておけばいいだけというシーンも多いはずです。

PMOが有効に機能し始めれば、社内で発生するITプロジェクトの品質は確実に向上しますし、メリットも多いですが、PMOという組織を固定の組織として抱えるだけのマネーリッチな会社でなくては実現は難しいでしょうし、PMOが活躍するほど、ITプロジェクトが乱立している会社もそこまで多くもないと思います。
あったとして、それらの企業の中にPMOをどう機能させたらよいか?をまじめに考えている企業がどれだけいるか?となるとさらにその数は限定的になると思います。

なので、ここまで「PMOとは?」を書いてきましたが
それを踏まえた上で、日本の企業の大半には必要ない組織だと思っている。
というのが私なりの考えを付け加えて、終わりにしたいと思います。

こちらの記事もオススメ
プロジェクトマネジメント

プロジェクトリーダーに向いている人

2021年5月20日
プロ社内SEになろう
私の経験では優秀なプロジェクトリーダー(以下、PL)は大きく分けて2種類いると思います。 それぞれにメリットデメリットというか特性があります。 カリスマ型のメリットは  …
プロジェクトマネジメント

チームが有機的に動き出すことによる影響

2021年9月19日
プロ社内SEになろう
システムの仕事はサッカーのようなチームスポーツと似ています。 チームワークが非常に求められる点や 監督にあたるプロジェクトリーダーの資質で成否が大きく変わる部分などです。  …
プロジェクトマネジメント

プロジェクトのフェーズごとにおけるPLの立ち位置の変化(その2)

2021年10月24日
プロ社内SEになろう
前回の記事に引き続き、 プロジェクトリーダーがシステム導入の際に 運用保守の事も考えて実装をしないといけない という話をしたいと思いま …