夏休みとプロジェクト

会社で、PMがメンバーの休暇と成果でもめていた。メンバーの甘い見通しをPMがたしなめており、「を?やるじゃん」と思った。

ふと思い出したが、WBS(ワールド・ビジネス・サテライトじゃなく、ワーク・ブレークダウン・ストラクチャ)を決める場合、みんなどうしているのだろう?あくまでも俺の場合だが、日を単位に成果を数える。少数は認めない。だって0.4とか残ってたら、みんな遊ぶし、そんな精度で仕事しないもん。細かい仕事が多い場合は、区切りが小さすぎることが多いように思う。

WBSの進捗状況は、あくまで俺の場合だが、お金で計算する。どういうことかというと、50%の進捗なんて認めない。なぜならば、どんなプログ ラムであっても書きかけだと価値0。ひととおり書いて、まぁ動くかもね、で、価値90%。テストして大丈夫です、で、資産価値100%

このように計上すると、冒頭のWBSを日単位とかみ合うのである。なぜならば、あまりに計画の粒度が粗いと、いつまでたってもリターンのない仕事をしている人間が出てくる。適切な周期でアウトプットを出さざるを得なくなるのである。

次に余裕の見方。最近こそ、ひそかにTCO(制約理論)を使うPMが出てきており、バッファをプロジェクト全体で数えるようになった。なかなかの進歩である。各工数にバッファを置くのは当たり前のようだが、「必ず食いつぶしてしまう」ことになるので、意味がないのである。工数に余裕を積んではいけない。必ずなくなる。

PMはガントチャートに頼らないこと。Pert図を手持ちでいいから書いておく。小さいプロジェクト同士のランデブーが予定どおりにならない場合、さらに大きいクリティカルポイントにどう影響するか、見てないとリカバリー不能となる。

パート図と同様に絶対に見ておくべきなのが、ボトルネックの奴のWBS。ボトルネックとは出来ない奴のことではない。必ず中心で重要部分を作る奴がボトルネックになる。酷使すると、休みもとれず、連日残業になる。素人PMがしばしば、特定の人を傷つけてしまうのは、ここの誤解である。そいつは実はプロジェクト内でのクリティカルリソースなのである。そいつのスケジュールを優先し、他を従わせないと破綻する。これに気づくのにずいぶんかかった。

たとえば、システム系のオブジェクトとかテンプレートを作る奴は注意して見ておいたほうがいい。優秀なプログラマーはもともと仕事は速いだけに、自分を過信する。

PMはWBSやドキュメントなどの大半に目をとおすべきである。が、内部仕様に口は出さないこと。それやってると、寝る時間がなくなる。が、作業粒度にだけ目を配ること。全体の粒度が均質かどうかは、PMじゃないとわからない。

と思いつくままに、難しい技術系SIが得意だった私の手の内の一部を書いておく。

コメント