業務もシステムも詳しい人がいる中でのPMOとしての価値の出しどころ

ソリューション・パートナーとシステム導入するプロジェクト。業務部門やIT部門として、PMもしくはPMOとして参画することになった際に「何をしたらいいの…？」と動き方に迷ったことはないだろうか？
ITやシステム的な知識・経験はソリューション・パートナーが詳しい。詳細な業務は業務部門、意思決定自体は管理職や幹部が行う。そんなプロジェクトの中で、PMもしくはPMOとしてどう振る舞えばいいのか？

私がコンサルトして転職したての頃も同様の迷いがあり、うまく振る舞えなかった。それまではSEとして自分で顧客と話しをして決め、自分で開発から導入まで行ってきた。そこから「PMO」としてプロジェクトの大海原に放り出され、知識・経験は他の人が勝っている中、何をすればいいのかわからなかった。

同様な状況に至る人も多いのではないだろうか？今回は、そんな「過去の自分」に向けて、こうしたらいいよ・こうしたらお客さんに勝ち出せるかもよというヒントを残しておこう。

そもそも、PMO（ひいてはPM）とは何をやる人なのか。それは、「プロジェクトが予定通りアウトプットする」ためのマネジメント及びサポートを行う人だ。
業務なりシステム実装方針の意思決定をバシバシ行う人ではない。それよりも「プロジェクトをどう率いるか」「プロジェクトを成功裏に進めるため何をするか」についての意思決定をする。

「プロジェクトが予定よりも遅れている」
「業務部門のムリな要求で、開発範囲・期間が拡大している」
「業務部門が参画できないことで、システム品質がイマイチ」
などの問題に対して、どうすべきか交通整理・調整・意思決定を行う。

この役割を担うために、PMOがやることは大きく3つ。
①現状や見通しを把握する
②先のことを見据える
③ボトルネックを解消する

それぞれについて詳しくどんなことをするか見ていこう。
「①現状や見通しを把握する」とは、今進めているタスクがどんな進捗なのか、このまま進めて終わりそうなのかを把握することだ。これによって問題が大きくなる前に、捉え解消に動ける。
PMOの基本はこれだ。プロジェクト推進上、何らしか問題は起きるはずなので、それが大きくなる前に処理する。
プロジェクトは目的地に向けて、延々と道を作り続ける作業に似ている。その作業中に発生したトラブル、例えば重機の手配がかかってない・整備用部品がそこをつきそう、などのトラブルの芽を小さいうちに見つけて摘んでおく。これをそのまま放置してしまうと、あとあと大問題になってプロジェクトが進まなくなる。
この際に、特に期間が長くかかるタスクや、不確実性高い・難しいタスクについて状況をウォッチし続ける。なぜなら、前者だと終了期間の間際になって問題が発生すると手戻りが大きくなる、後者だと「それができる人」が限られるため、人を追加してもタスク進行が早くならない、と問題が発生・大きくなったときの影響が大きくなるからだ。
「①現状や見通しを把握する」ときは、期間が長くかかるタスク・不確実性や難易度高いタスクがどれか把握しておく、それについて常に情報を得てどうなりそうか仮説を持っておくようにしよう。期間が長くかかるタスク・不確実性や難易度高いタスクは、半ばや納期の前に中身をつまびらかにし、品質や進捗をチェックしよう。

「②先のことを見据える」は、「①現状や見通しを把握する」よりももっと先のことを考えておくことだ。
先の目的地に向けて道を作り続ける作業に例えると、まだ作業・工事に着手していないが、この先にどんなものがありそうか見越しておく。「大きい岩があるから数m横に工事をずらしたほうがいい」「数日後大雨ぽいから切りのいいとこまで作業しておこう」という予測と工程の調整をしておく。
プロジェクトでいうと、マイルストーンやアウトプットから逆算して、必要なタスクを洗い出し、「今後どんなことが起きそうか」を予測しておく。「この領域はソリューションとのギャップが多く出て揉めそうだな」「この辺が既存システムとの連携の詰めで大変になりそう」「業務時繁忙と重なって、業務部門の時間がとれないかも」というようなことを「見込み」「推測」でいいので出しておく。
そしてその「見込み」「推測」が発生しないように、事前の策を講じたり準備を進める。「ギャップは途中途中でも経過を出してもらおう」「繁忙のタイミングとプロジェクトタスクのタイミングをずらすよう調整しておこう」などなど。基本は、どうなりそうか事前・早めに状況開示する、問題を軽減・回避・転嫁する策を講じる、のどちらかだ。
ただ、「②先のことを見据える」といってもどうなるか考えられない、という場合もあるだろう。そのときには2つのやり方がある。
1つはマイルストーンやアウトプットからひたすら逆算するやり方。「ここからここまでのシステム構築なら…」と必要な検討要素やタスクを分解していく。ロジカルにロジカルに考えていくやり方だ。
もう1つは、過去の実績などから「本来こうなる」「過去こんなことがあった」をベースに推測する。例えばシステム構築ならフェーズ別成果物一覧やフェーズ別タスクがだいたい決まっている、いろいろな書籍にプロセスや注意点は掲載されている。これらの情報をもとに「何が起きうるか」を考えていく。
「②先のことを見据える」は、考えて準備はしたものの、実際は発生せずに徒労に終わることもある。ただ、それは「起きなくてよかった」というだけで、考えなくてよかった、というわけではない。一度推測でも考えることで、不確実性の高いプロジェクトというものに、態勢・行動が伴うのだ。

「③ボトルネックを解消する」は①でわかった問題、②での推測で影響が大きい・推測でなく本当に発言しそうなものに対して、実際に手を打っていく。
冒頭に述べたような「業務部門のムリな要求で、開発範囲・期間が拡大している」という問題がわかったら、それが本当に必須か業務部門にかけあったり、開発しきれるかパートナーと確認したり、予算の調整をオーナーと行ったり、というベタなことを行っていく。
問題に手を打っていくといっても、プロジェクトでは無数に問題は発生していくる。その全てに手を打っていてはPMOのリソースが無尽蔵に必要となるか、PMOがパンクしてしまう。そのため、問題の中でも一番マズイ部分、進捗の遅れが大きくプロジェクトへの影響が大きいボトルネックに着目・集中する。
特にボトルネックになりやすいのが、「ポテンヒット」と「ブラックボックス」だ。「ボテンヒット」とは、例えば「受注は営業、部品手配は調達と決めていたが、納期調整をどうするかはどちらとも検討してなかった」というようなものだ。ボテンヒットは狭間の課題だが、ここが抜けると各々の業務やタスクがスムーズに進まない肝でもある。検討がなされてない・方針が決まってないとなるとプロジェクトへの影響が大きい。「ブラックボックス」は「検討を進めてます」と担当は報告していても、実態がよくわからない部分だ。これの何がマズいかというと、実際にそのタスクの期日になったときに「できてませんでした」となると急に大きな進捗の遅れとなり、プロジェクトの状況を悪化させる。ボトルネックが急に発生してしまうので注視が必要になる。
このボトルネックは問題やタスクだけで生じるものではない。よくあるのが「この人が」という人のボトルネックだ。この人が業務掌握しているが現場の業務もあり時間がとれない、この人に意思決定してもらう必要があるが忙しすぎる、この人が現行システム知っているのでお任せしたいが既に任せているタスクがあふれている、などなど。
この場合もPMOとしてはボトルネックの解消に介入する。人のボトルネックの場合は、タスクを割り振り直したり、負荷を下げる代替を行うなどだ。

冒頭に自分が陥ったような状況、ITやシステム的な知識・経験はソリューション・パートナーが詳しい、詳細な業務は業務部門が詳しい、そんなプロジェクトの中でPMOとしてどう振る舞るか？
それはいろんな人に聞き、頼り、調整して、「①現状や見通しを把握する」「②先のことを見据える」「③ボトルネックを解消する」に集中することだ。
相手の方が知見があるが、先の見通しを通せていない・目前のタスクに陥っていることはよくある。その代替として、プロジェクトをうまく進められるよう運営面にフォーカスする。またはその人が見切れていない部分や、一人だと解決しづらい部分に介入して手助けする。その場合も、自分だけではこのあとのタスクも進捗も、どう解消していいのかもわからない。だから愚直に聞き、頼り、調整していくのだ。
所詮コンテンツオーナーにはなれない。業務や要求は顧客、システムはパートナーの方が絶対詳しい。これを念頭に「その人だとやりづらいこと」「その人の代わりにやったら助かること」を見つけて動く。
一番動きやすい・わかりやすいのは、顧客側PMの補佐だ。顧客PMの負荷を下げ、意思決定や社内・パートナーとの調整・交渉の全面に立ってもらうことに集中させる。ここが一番ボトルネックになりやすいので。ステコミ報告用の資料を作成したり、現場の意見や状況をヒアリングして整理したり、パートナーからの質問回答の一次案作成したり。PMが先のことに頭が向けれていなければ計画づくりのサポートも行う。これによりPMの負荷が下がるならプロジェクト全体としては万々歳だ。
ただ情報を収集し整理するだけでなく、整理の中で「全体見るとこうした方がよさそう」「一般的にこうなるはずだが、このプロジェクトではそうなっていないのでマズい」などレコメンドや仮説を提示することで参謀として動き、プロジェクトをよりよい方向に導いていく。

ここまで書いて「PMOのやることって地味だな」と思われる方もいるかもしれない。たしかに、人に聞きまくって、人同士の認識齟齬やいざこざを収めたりと、「これをヤッてる！」「これが成果で作れた！」という実感は少ない。
ただ、地味だが誰かがやらなければプロジェクトが成功に至らず、他の人がやった労力や苦労は気泡に帰すことになる。みんなで目指した目的地に到達するために、重要で欠かせない仕事であり、プロジェクトが成功したときにその苦労が報われる貴重な仕事だ。