『WBSのワークパッケージ(末端作業)は8人時以上80人時以内』と聞いて感じることは？
プロジェクトの作業を段階的に詳細化し記述するWBS(Work Breakdown Structure)。その末端の作業（リーフノード）の予定工数を8人時以上80人時以下にするとよい、という話を聞いて自身の担当プロジェクトでWBSを作るとするならばどう思われるだろうか？状況にだいぶ依存するとは思うが、1つ選んでみてほしい。
- 数字ではかれるようなものではないので考慮しない。
- 自身の経験やこれまでの数値から、ある程度妥当と考えるので今後参考にする。
- 今後、WBSを作る際には予定工数を8～80人時の範囲に必ず詳細化する。
では、他の人が作ったWBSをレビューする立場になったら、どうだろうか。
- 数字ではかれるようなものではないので考慮しない。
- 怪しいと思ったり、レビューアとして自信がないときは、8～80人時の規模をある程度意識する。
- 8～80人時から、はずれているものだけをチェックする。
経験則という断り書きとともに、その末端作業の予定工数を8人時以上80人時以下にすることを推奨している記述をよく目にする（"80 hour rule"と呼ばれるようだ）。もちろん、この範囲をはずれていても、それ以上分解しても意味がない作業や自信をもって見積れる場合は例外だが、ある程度の参考になるだろう。
経験則を使った計測の場合、上の3-Cのような組合せになると、チェックが効かなくなるばかりか、このルールを使うことによる弊害のほうが大きくなる可能性がある。不具合密度や欠陥密度と呼ばれる指標をはじめとして、ソフトウェア開発に使われているメトリクスの多くはこの性質をもっている。1-Aの組合せを選ばれる方はひょっとするとこのパターンに陥ったご自身の経験からそれを選ばれている可能性もある。
個人としてはどれを選ばれただろうか？組織としてはどれを選ぶ傾向があるだろうか。また、それはどのような経過でそうなったか説明できるだろうか。
当ブログを読んでくださっている皆さま
今年もたいへんお世話になりました。また、駄文にお付き合いいただきありがとうございます。来年も引き続き何らかの気づきを提供できれば幸甚に存じます。今年の残りのエントリ、来年初頭のエントリでは今年のエントリを振り返ったり、私の身の回りのことを書ければと思っております。年内に無事業務を終えられる方、よいお年を。土曜日以降も残務がある方（私もですが。。）、引き続きお付き合いいただければ幸いです。