ここしばらく暑い日が続きましたが、今朝は小雨で気温はグッと下がったようです。でも湿度が高く通勤（最寄りの駅から15分歩きます）で汗だくでした。梅雨入り前の雨を「梅雨の走り」と言うそうですが、梅雨の不快さに耐える予行演習ということなのでしょうか。
さて、プロジェクトマネジメントに必須なアイテムであるWBSを作るとき、どのように構築していくのかについて考えています。
一つは作業基準のWBS構築の考え方でした。目的に到達するために必要となる作業を、基本的には時間の流れに沿って組み立てて行きます。まっ普通に考えるとこの方法が一番しっくり馴染んで、解りやすいやり方となります。
チャーハンの例で言えば、材料をそろえ、下ごしらえして、調理をして、盛り付けるという具合に一連の作業を実行することで、「チャーハンを食べる」という目的を達成しようとするものです。
もう一つは、目的の達成はそのために必要な要素を部品として組み合わせることで可能となるという考え方です。これが成果物基準のWBSでした。
チャーハンの例でいうと、下ごしらえされた材料と調理環境と技術があればチャーハンを完成することができるということになります。これらの要素を個別の部品と考えるやり方です。「部品＝成果物」となります。
この２つ、皆さんは目的達成のため似ているようで全く異なるアプローチをしていることにお気づきになったでしょうか。
後者は目的を達成するために必要な”成果物”という”モノ”を設定することで、作業工程自体を一度抽象化していることになります。具体的な成果物を上げているのに”抽象化とは此れ如何に”なのですが、ここで抽象化されているのは、プロジェクトの構造になります。
必用な作業工程をただ順番に並べていくことに対して、成果物を基準として全体工程をいくつかの工程の集合としてとらえ、プロジェクト作業を構造化しているわけです。
ではなぜわざわざこのような考え方をするのかというと、構造化（＝抽象化＝モデル化）することで物事の構造がとらえやすくなるからです。
構造を論理的に組み立てて、全体像を把握することができれば、WBSとして表す必要のあるタスクをより網羅し易くなります。
逆に考えると、WBSの弱点はタスクの網羅性を担保することが難しいということにあるということになります。
キットPMは、この弱点を克服するために「成果物基準のWBS」があると考えます。ただし、これだけではまだ不十分なのですが。
これについては、次回掘り下げていくことにします。