会社で、ＰＭがメンバーの休暇と成果でもめていた。メンバーの甘い見通しをＰＭがたしなめており、「を？やるじゃん」と思った。
ふと思い出したが、ＷＢＳ（ワールド・ビジネス・サテライトじゃなく、ワーク・ブレークダウン・ストラクチャ）を決める場合、みんなどうしているのだろう？あくまでも俺の場合だが、日を単位に成果を数える。少数は認めない。だって０．４とか残ってたら、みんな遊ぶし、そんな精度で仕事しないもん。細かい仕事が多い場合は、区切りが小さすぎることが多いように思う。
ＷＢＳの進捗状況は、あくまで俺の場合だが、お金で計算する。どういうことかというと、５０％の進捗なんて認めない。なぜならば、どんなプログ ラムであっても書きかけだと価値０。ひととおり書いて、まぁ動くかもね、で、価値９０％。テストして大丈夫です、で、資産価値１００％
このように計上すると、冒頭のＷＢＳを日単位とかみ合うのである。なぜならば、あまりに計画の粒度が粗いと、いつまでたってもリターンのない仕事をしている人間が出てくる。適切な周期でアウトプットを出さざるを得なくなるのである。
次に余裕の見方。最近こそ、ひそかにＴＣＯ（制約理論）を使うＰＭが出てきており、バッファをプロジェクト全体で数えるようになった。なかなかの進歩である。各工数にバッファを置くのは当たり前のようだが、「必ず食いつぶしてしまう」ことになるので、意味がないのである。工数に余裕を積んではいけない。必ずなくなる。
ＰＭはガントチャートに頼らないこと。Ｐｅｒｔ図を手持ちでいいから書いておく。小さいプロジェクト同士のランデブーが予定どおりにならない場合、さらに大きいクリティカルポイントにどう影響するか、見てないとリカバリー不能となる。
パート図と同様に絶対に見ておくべきなのが、ボトルネックの奴のＷＢＳ。ボトルネックとは出来ない奴のことではない。必ず中心で重要部分を作る奴がボトルネックになる。酷使すると、休みもとれず、連日残業になる。素人ＰＭがしばしば、特定の人を傷つけてしまうのは、ここの誤解である。そいつは実はプロジェクト内でのクリティカルリソースなのである。そいつのスケジュールを優先し、他を従わせないと破綻する。これに気づくのにずいぶんかかった。
たとえば、システム系のオブジェクトとかテンプレートを作る奴は注意して見ておいたほうがいい。優秀なプログラマーはもともと仕事は速いだけに、自分を過信する。
ＰＭはＷＢＳやドキュメントなどの大半に目をとおすべきである。が、内部仕様に口は出さないこと。それやってると、寝る時間がなくなる。が、作業粒度にだけ目を配ること。全体の粒度が均質かどうかは、ＰＭじゃないとわからない。
と思いつくままに、難しい技術系ＳＩが得意だった私の手の内の一部を書いておく。
