プロジェクトチーム崩壊

なんだかんだ言って、プロジェクトのチームは「やるときはやる」ものだと思っていました。少なくともワタシのチームはそうでしたし、私にはそう見えていました。

とあるプロジェクトで、今思い起こせば小規模のプロジェクトをいくつも経験してきた技術には長けているSEリーダ（プロジェクトマネージャと呼ぶよりは小規模でプレイングマネージャなので）が大規模な方のプロジェクトのPMにアサインされたプロジェクトがありました。

プロジェクト開始から数ヶ月が経ったところ「どうも様子がおかしい」と耳にしてプロジェクトのプレグレスレポートやウイークリーのレポートを見る限り全く問題がないようにしか見えないのです。スケジュールもなんとかオンスケ、コストは過少な位の実績、品質は特に目立ったクレームがついているわけではありません。

ふと、WBSを通期で見てみたら、なんともいびつなWBSにだったのです。ワタシはあのようなWBSは作らないので。最初の数ヶ月のWBS数が総数に対して非常に少ないのです。局面ごとの比重のせいかもしれないけれど、そうバイアスをかけてみても上流工程のWBSが極端に少ないのです。

そのWBS数が適切なのであるなら、次はコストとのバランスが奇異に見えてしまいます。人数が多いのです。少ない人数で期間を長くとっているならわかります。でも、SEの数は少なくないのです。このWBS数でそこそこの人数のシステムエンジニアが何をアウトプットしているのでしょうね。そう疑いたくなるのでした。

いろいろ情報を集めてみると公式に上がってくるレポートでは聞けていないことがゴロゴロと。たしかに各種レポートで報告されているとおり、レポートの断面としては嘘はないのです。少ない数のWBSがオンスケであること、大所帯のSEが計画コストどおり消化していること、目立った課題がないこと。

実態はちょっと違いました。

プロジェクトマネージャ自身のキャパの規模を超えていた
原因は標題のとおりです。PMの手から溢れていたんですね。だから、見積もりとおりの人数を入れて、WBSを渡せば仕事をしている人とアイドルしている人がでてくるんですね。でも、プロジェクトにいるわけでコストは出て行く。

もちろん、スケジュールはオンスケです。だってWBSに沿って仕事をしている人はいるんだから。それなりのレビューをしているからクレームが入るような品質にはならないわけで。

プロジェクトマネージャが掌握しなければならないプロジェクトの規模とプロジェクトマネージャ自身の目が届くキャパシティのギャップあったということです。

プロジェクトマネージャが見切られる
現場ではプロジェクトマネージャは忙しく働いています。だって、キャパオーバーしているんですから。メンバは忙しい人もいれば暇な人もいたわけです。その上、プロジェクトマネージャはキャパを超えていますからメンバの隅々まで目が届かないのですね。

どうなるかというと、メンバは諦めるんですね。このプロジェクトマネージャじゃだめだ、と。あとで聞いたらメンバは割と優秀だったらしいです。でも、プロジェクトマネージャに申し出るとかまでの関係を作るチームビルディングに失敗していたようです。

悲しいことです。プロジェクトマネージャがメンバから見放されている状態なわけですから。強引に引っ張るプロジェクトマネージャと健全にぶつかるケースはいくつか見てきましたし、そうしたプロジェクトマネージャの下で働いたこともありました。そういうケースはお互いムキになって仕事をするからそれはそれでいいんですが。

またそれとは違うのですよね。仕事なのでお互いやることをやればいいのですが、でもね…。自分一人でできないプロジェクトの仕事を役割分担してチームを作るんです。そこには相互に認め合う関係づくりは必要なのだと思うのです。それが欠けていたプロジェクトだったのです。

まるで学級崩壊したようなプロジェクトチームでした。

後日談
幸いにもプロジェクトに対して様々な関係者が手を入れ、プロジェクトとしてはQCDは確保するという「数字」としては優秀な成績となりました。見えないチームの関係を除いては。