進捗管理は下っ端がやる仕事、あるいはファシリテーターとしてのPMO
プロジェクト内に「PMO」という部署を設けるケースがある。
大規模プロジェクトではPM（プロジェクトマネージャー）のタスクがあまりにたくさんあり、とうてい1人PMではやりきれない。だから何人かで分業するためのチームを作る。それをPMO（プロジェクトマネジメントオフィス）と呼ぶ。
で、もちろんプロジェクトの成功にとって大事なのは、PMOを作ることではなく、PMOが何をやるかだ。
他社の人とこの話をしていて、全然咬み合わないことが多い。僕らの考えるPMOの仕事よりも、彼らの考えるPMOタスクはかなり狭いのだ。
もっとはっきり言うと、普通の人が考えるPMOのタスクって、僕らが考えるPMOタスクのうち、一番簡単で、普通は下っ端（PMOチーム内で一番経験が浅い人）にやってもらう仕事だけのことが多い。
「いや、違うんです。プロジェクトの成否を分けるのは、その先なんです」と言いたくなる。
僕らは、この狭い方のPMOの仕事定義を「事務局型PMO」と呼んでいる。
そして、プロジェクトを成功へ向けてファシリテーションする、もっと広い仕事を「ファシリテーター型PMO」と呼んで、区別している。
★事務局型PMO
その名の通り、プロジェクト全体にまつわる事務を担当する。
大規模プロジェクトは通常いくつかのチームに別れるが、どこのチームの仕事でもない仕事、いわば雑用みたいなことも含まれる。
・全体会議の招集、準備
・各チームから進捗報告を受け、全体資料に反映させる
・偉い人への報告資料をまとめる
・課題の発生状況のトラッキング
・メンバーへのパソコンの手配、入館手続き
などなど。
誰かがやるべき仕事なのだが、必ずしも優秀でクリエイティブな人でなくてもつとまる。だから「事務局」なのだ。
以前、PMをやっている人から「7割の時間をこの手の雑務に費やしている」と聞いてびっくりした。確かに、パソコンの手配なんかは、しないと仕事が進まない。とは言え、プロジェクトで一番優秀であろうPMの時間をそんなことに使うなんて、あまりにもったいない。
若手にとっては、この手の雑務から学ぶことだって多いんだから、なるべくそういう人に仕事を振ろう。
そこまで雑用っぽい仕事じゃなくても、進捗の把握や報告資料の取りまとめだって一種のルーティーンワーク。本当はプロジェクトで一番優秀な人がやる必要はないと思っている。
決められた通り、まずはきっちりと情報を集め、記録し、他の人が判断しやすいように整理する仕事。こういう仕事は、判断の余地はあまりない。遅れているチームに「遅れていますね。リカバリープランを提出してください」と言うだけならなんの価値もない。
そういうことしかやってないのに「PMOです！指示に従って」とプロジェクトの他の人達に対してえばったりしてないですよね？
★ファシリテーター型PMO
あの手この手で、ふんづまっているプロジェクトを前に進めるのがプロジェクトファシリテーターの仕事。それをチームでやるのが、ファシリテーター型PMOだ。キーワードは「チーム横断」「課題解決を助ける」「監視しないけど担保する」というあたり。
以下、具体的な役割ごとに、少し丁寧に説明しよう。難しい順に並べてある。100人を超えるような大規模プロジェクトだと、それぞれごとに専門家を立てる。PMOだけでも7,8人のチームになる。
20人くらいの中規模プロジェクトならば、幾つかの仕事を2,3人が兼任しながら、カバーすることになる。
a)計画系
プロジェクト全体の先読みをして、何ヶ月も前から計画を立てていく仕事だ。
先読みのためには、次フェーズ以降に何が起きて何をすべきかを見通す力が必要。
経験も必要だが、それ以上に「プロジェクトのしっかりした方法論」を理解し、他の人にも教えられるようになっていないといけない。
・マスタースケジュールの立案／修正
・コミュニケーション計画
・教育計画
・コンティンジェンシープランの立案
・業務／システムの切り替え計画
一番大事なことは、「実際に取り組む3,4ヶ月前には、計画を立てておく」ということだ。
例えば、教育計画であれば、
・10月にシステムを稼働させる
・そのためにはユーザー受け入れテストを8月にはやる
・そのためには7月からユーザー教育をする
・そのためには5月からマニュアルを作り始める
・でもシステムの画面が完成するのは5月末だから・・
・と言ったことを考えるために、どこまで教育を熱心にやるのか、
教育方針は4月には明確にしておこう！
みたいに、逆算で考えて、期間と人を確保していかなければならない。
方針から緻密な日程表まで、すべての分野の計画をPMがすべて作るのは無理なので、
教育とコミュニケーション計画はAさん、切り替え計画とコンティンジェンシープランはBさん、みたいに分業することが多い。
b)横串課題
大規模プロジェクトでは幾つものチームをつくり、仕事を分担する。それぞれのチームを別の部署、別の会社が担当することも多い。
しかし1つのプロジェクトとしてやっていることだから、当然「チームをまたぐ課題」はたくさん発生する。「Aチームの事情でこう変更したいが、そうするとBチームに大きな影響が出て・・」みたいなケースとか、「Aチームがこれを決めないとBチームは仕事を始められないが、それにはあと1ヶ月くらいかかるので・・」みたいな感じ。
こういった、チームをまたぐプロジェクト全体の課題は、解決するのが難しいから、放置される事が多い。ふんづまっているプロジェクトを観察すると、たいていこの手の厄介な課題が何個もあって、にっちもさっちもいかない事になっている。
これらを1つ1つ意思決定し、仕事を前に進めるファシリテーションは、PMOの極めて大事な仕事だ。
PMOの仕事として、「課題を管理する」というのは普通にやられている。でも、課題リストを作って、解決の期限を記入しているだけではダメだ（やらないよりずっといいけど）。
管理しただけでは、貯まるだけなので、1つ1つ解決していかないと。プロジェクトメンバーに任せて解決出来るならばもちろん放っておくけれども、たいていはそうじゃない（だからふんづまっているのだ）。
僕らが「プロジェクトは管理するだけじゃなくて、ファシリテーションしないと進まない」と常々言っているのは、この糞詰まりをやっつけるのが、本当に大事だからだ。
優れたPMOメンバーは優れた課題解決人でなければならないし、そのためには優れたファシリテーターでなければならない。立場、利害が異なる多くの関係者を集めて、プロジェクトとしての意思を定めていく。
各チームが自分の利害ばっかり主張したら、意見は絶対にまとまらないから、プロジェクトを個々の利害を超えた「OneTeam」に普段からして置かなければならない。
これについては、このブログを書き始めた頃、2つの記事にしたことがある。
http://blogs.itmedia.co.jp/magic/2011/04/one-team-419e.html
http://blogs.itmedia.co.jp/magic/2011/04/oneteam-5878.html
c)担当大臣
大規模プロジェクトでいつもややこしい仕事には、「○○大臣」という名前をつけて、調整を一手に担わせる。
例えば「環境大臣」と呼ぶ役職を僕らは常に任命するのだが、これは本番環境、開発環境、テスト環境・・などのインスタンスを管理する専門職のことだ。100人を超えるプロジェクトだと、環境を8個や10個作ることもある。そして、それぞれの環境ごとに、入っているデータやプログラムのバージョンが異なっている。
各チームが好き勝手に環境を作り、使うと大混乱になるので、それを仕切りまくるのが仕事となる。
他にもデータ移行大臣なんかも任命することが多い（業務と、新システムと、旧システムのすべてを知らないとうまく指揮命令できないから）。
d)リスク管理
いい加減この記事も長くなってきたし、前にも書いたことがあるので繰り返さないが、徹底したリスク管理もファシリテーション型PMOの仕事になる。
多くのプロジェクトでは、「リスク管理」の名のもとに、プロジェクトの最初の頃にリスクのリストアップだけを行い、そのあと放置してしまう。それでは時間を割く価値が全く無い。リスクは将来の見通しなのだから、プロジェクトが進むに連れ、変化するからだ。
多くのリスクは杞憂に終わり、以前は気にも止めていなかったことが、新たなリスクとして深刻な影を落とす。断続的に監視し、ヤバイやつには手を打って、はじめてリスクを管理する意味がある。そのためには当然、プロジェクト全体に指示を出してイヤイヤ何かをやらせる、ということもあるだろう。
こんな感じで、ファシリテーター型PMOは、事務局型PMOよりもずっと難易度が高い。僕らはプロだが、それでも難しいので、社内に方法論やフォーマットなどを蓄積して、誰がやってもそこそこのサービスレベルでやれるようにしている。
それでも「まとめる力」「問題解決力」はやはり人によって差がでる。
できるヤツはできるし、できないヤツはできない。育成には3,4年はかかる。近道は無いよね。
ダイヤモンド社
売り上げランキング: 20,160