進捗管理の苦い思い出 - 室長のひとりごち

進捗管理の苦い思い出
ずっと前のプロジェクトマネージャをしていたころのことだけれど、プロジェクトをキャリーしていた。プロジェクトメンバは、コアメンバは押さえていたが、すべてのメンバとは“初めて”のチーミングだった。
＃半分くらいは知ってはいたけれど

そのプロジェクトでのプロジェクトマネージャは、プレイングマネージャだった。プロジェクトのサイズは小さい方。アジャイルなら適当なサイズかもしれない。でも期間はそこそこの半年以上はあった。プレイングマネージャだからこそ、好きにできるけれど、好きにした分、自分も手を動かさなければならない。
上流工程なら顧客とのセッション資料を仕込み、セッションをファシリテートし、プロジェクトメンバにフィードバックする。この間にも課題管理、機能検証、メールコミュニケーション、コスト管理、そして進捗管理など、普通にあるプロジェクトマネージャの仕事が山積みになっている。

で、詳細設計からちょっとおかしくなってきた。あるメンバの進捗が上がらなくなってきた。ほんと、ジワ、ジワって。そのメンバは技術的なリーダでもあったので、だんだん困ったことになっていく。
＃今、考えればWork In Progress(WIP)を積み過ぎていたのかもしれない。

遅れ始めのころは、彼なら

「遅れを取り戻してくれるだろう」

と思っていたし、進捗ミーティングでキャッチアッププランを聞けば、

「今週末までに取り戻すから。」

応えてくれたので、“期待”をしていたわけだ。
それに応えてくれる“彼”の応え。
まぁ、新人ではないし、ベテランの言葉だからこそ、期待してしまうんだ。だって、それは自分には出来ないことだから。
でも次第に分かる。
進捗管理をしているから。deliveravblesをWBSを展開し、完了基準を決めて、メンバに展開していたから。それもオーバースペック気味だったくらいに。隣でやっていたプロジェクトより、メンバは面倒だったろう。自分のプロジェクトは、作業内容と作業の完了基準に曖昧さをなくしていたから。その上、進捗もモノづくりになったら週次から日次にきめ細かくポーリングするタイミングを変えたり、deliveravblesも全件レビューするなど、プロジェクトをコントロールするための策で知り得ることを全部やっていたから。

WBS一つひとつに対して、deliveravblesと完了基準を設けることは、当たり前のように思うかもしれないが、実は曖昧にしやすいところだ。特に、ウオーターフォールなら。だからWBSがマージするタイミングで、今まで“暗黙”で進めていたことが明るみに出てそれぞれのメンバが違うことを考えていたことを初めて知るものだ。
そんなことになりたくなかったわけではなくて、今までの経験から自然とできていたのは、今思えば不思議なことだったかもしれない。

話を元に戻して。
で、そのメンバの進捗の遅れがだんだんと積み重なる。1週間が2週間に。2週間が3週間に。これは顧客との問題ではなくて、自分のプロジェクト内の問題だから、自分で何とかしなくてはならなかった。プロジェクトマネージャだから。

スケジュールバッファは教えない
プロジェクトのメンバにWBSの工数を見積もらせることはよくあることだ。プリセールスでの工数見積もりと実際のプロジェクトの工数見積もりは違う。プロセールスでは、仮説を立てて見積もりをするし、実際のプロジェクトでは、deliveravblesが具体的だし、担当するエンジニアも目の前にいる。そして何を作らなければならないかもプリセールスのときより、顧客の要求仕様を知っているのだから。
プロジェクトのメンバにWBSの工数の見積もりをさせると、一つひとつのWBSに自分の経験でバッファを積む。これは自然なことだ。エンジニアレベルのリスクマネジメントでもあるし、そのWBSだけに専念できるわけではなく、ミーティングやら何やらを作業がWBSの他にもあることを経験的に知っているからだ。
プロジェクトマネージャの立場としては、一つひとつのWBSを曖昧にすることで一つひとつのWBSにスケジュールバッファを積まれたくない。一つひとつのWBSでスケジュールバッファを積まれると、全体に占めるスケジュールバッファがとてつもなく大きくなるからだ。だから、deliveravblesの完了基準を明示的にしていた。たとえば、

“仕様書はレビューでの指摘修正のプロジェクトマネージャの確認まで”

というように。だから、レビューを受けた仕様書は捨てられない。

“確認の時に消込をするから”

プロジェクトメンバに見積もりをしてもらったWBSは、ときどき鋭い質問をした。これは、どのdeliveravbleを作るのか。それはどのくらいのアウトプット量か。既に作り上げた他のどれと類似しているか、など。プロジェクトメンバを信用していないのではなく、見積もりの根拠の信頼性を確かめるためだ。数値で計算式に当てはめ、定量的に算出できるならそれでもいいが、そうはいかないから類推見積もりをするほかない。類推見積もりと言っても、とうらばリーチと言うわけにもいかない。コストオーバーランすることもスケジュールオーバーランすることも許されない。

プロジェクトマネージャとして、顧客の視点で全体を俯瞰する。この意識がなければそれはそれで大変なことになる。自分が担当するプロジェクトだけを見ていたら、外部組織に依存するタスクの足元を掬われることになる。大概にして、それは掬われる前から分かっているものだ。同じように自分のプロジェクト内でもタスクの依存関係を意識して、どこが遅れると致命的になるのか、それを意識しておかなければならない。それを知っているから先に手を打つことができるし、計画時にだって、スケジュールのバッファを組み込まなければならない場所が見えてくる。
＃一度、自分で痛い経験をしないとわからないかもしれない...。

スケジュールバッファの積み方
ならば、プロジェクトのスケジュールバッファは、どのように組み込むか。それは、

プロジェクトの工程ごとに塊として仕込んでおくのが良い。

プロジェクトマネージャなら、PERT図は書けないといけない。

いまさら、PERT図か？

と言うなら、それ以外でスケジュールのマイルストーンや外部組織がインプットのタスクやこちら側のタスクが外部と繋がるタスクを明確に示すチャートがあるだろうか。それをプロジェクトメンバと間違いなく共有できるチャートがあるだろうか。ワタシに言わせれば、

“excelの一覧形式のWBSなんてPERT図がなければ意味がない”

し、MS Projectだって、依存関係とマイルストーンがなければ価値がない。

プロジェクトのスケジュールバッファは、工程ごとの中にマイルストーンや依存関係を見ながら組み込む。名前づけは大切だ。決してバッファなどとしない。それをプロジェクトメンバが自由に使ったり、当てにしてもらっては困るからだ。これは、プロジェクトのバッファであって、プロジェクトマネージャがリスクが発現したときのへそくりなのだから。

当の遅れたWBSは、コントロールしきって、つじつまが合うように間に合わせた。間に合わせってもらった、ではない。これは、当人に任せておいて、そう収集を付けさせたのならそう表現するが、四方八方手を尽くして、組み換え、辻褄を合わせたのだから。