昨日の北摂地方はいい天気となり、気温もぐんぐん上昇し26度まで上がり今年初の（たぶん）夏日となりました。これから梅雨に向かってまっしぐらですが、それもまた楽しからずや、です。
WBS（Work Breakdown Structure）の構造について考えています。
前回WBSは、いくつかのカテゴリと一つのアクティビティで表現されると述べました。
カテゴリは実行すべき作業（タスク）をある関連する項目で集めたもので、いくつかのレベルに分かれた階層構造となります。カテゴリ Level1＞Level2＞Levelnとなります。
Levelはいくつあっても構いませんが、多ければいいというものではありません。最終的にActivityとして具体的な作業手順に落とし込めるかが重要です。
さてカテゴリですが、どのような基準で捉えたらいいのでしょうか。普通に考えると、時系列に従って仕事を順に書き出すイメージになります。前回のチャーハンの例だと＜レシピを決める＞＜材料をそろえる＞＜調理する＞＜盛り付ける＞という順番になります。
これらレベル１のタスクの下にブレイクダウンしたタスクが続くことになることは前回シミュレーションしました。
このようにタスクを積み上げて、それをレベル分けして行くことで、WBSを作ることができますが、プロジェクトで必要な作業内容について、過去によく似たプロジェクトの経験があるとかではないと、必要な作業を完全に網羅することは難しいものです。ましてや、新規性のある過去に例のないプロジェクトだとなおさらですね。
プロジェクトをWBSに従って実施しようとすると、そのWBSに抜け漏れがあると、プロジェクトに致命的なインパクトを与える可能性があることは、お分かりいただけると思います。WBSによる問題の多くはここにあります。
この問題を解決するために、いろいろな方法が考え出されたわけですが、その一つが成果物基準でWBSを構築するという方法です。
これは、プロジェクトタスクをもう少し構造的に捉えて作業内容を論理的にチェックすることができるようにしたものです。
ここで少し周り道してタスクの本質について考えてみます。ご承知のようにどのような仕事であっても、一つの作業だけで成り立つものはまずありません。ある作業の結果は別の作業のインプットとなり、それを基に作業を実施することになります。
つまり、「Input<>Job<>Output」の関係が成り立ちます。プロジェクトにおけるすべての作業は。このOutput→Input→Job→Outputを繰り返すことで目的達成まで到達します。
次回も成果物とWBSの関係を掘り下げていくことにします。