梅雨入り宣言の後雨らしい雨は降っていませんでしたが、今週も13日の火曜日に振って以来、降りそうで降らない日が続く南関東地方です。雨不測が心配ですが、今週も残り２日、雨ニモ負ケズ 頑張りましょう。
今回はWBSを作成する上で、重要でありながら結構難しい問題である、タスク間の関係性について考えていきます。
成果物基準でWBSを作成するということは、プロジェクトが作り出す全ての成果物を構造化するということです。また出ました、構造化ですね。（笑）
ちょっと考えてみてください。プロジェクトが作り出すはずの成果物、それも中間成果物を含む、時には膨大な数となるものの全てを、事前に網羅して構造化することが、いかに難しいかということは簡単に想像がつくかと思います。
ではどうやってこの問題をクリアするのでしょうか。一つの考え方として、以前に行った類似のプロジェクトを参考にし、そこから必要な成果物を導き出すという方法があります。
この方法は過去に実践したという保証付きで現実感があり、とても信頼がおける方法です。このようにいくつかの実例からテンプレートを作成するということは、特にプロジェクト基準で仕事をするSIerなどではよくおこなわれており、とてもプラクティカルなアプローチとなっています。
ただ、この方法にもいくつかの問題があります。もっとも気になるのが、テンプレートと実際のプロジェクトのギャップをどう埋めていくかです。
モデルになった類似のプロジェクトとはいっても、それは似ているだけで同じものではありません。たとえ同じものであったとしても、プロジェクトを実施するタイミングやメンバー構成などの条件が異なると、成功へのアプローチが異なってくることがあるのは、もう何回もこのブログでお伝えした通りです。
「２つと同じプロジェクトは存在しない」というのは、プロジェクトの前提条件ですが、ときどきこのことを忘れてしまうことがあるのは寂しいものです。
なにが言いたいかというと、個々のプロジェクトのオリジナリティを把握することは、WBSを作成する上でとても重要であるということです。テンプレートがあることに依存しすぎると、手痛いしっぺ返しをくらうことがありますので、くれぐれもご用心ください。
もう一つの方法として、ゴールから成果物の要素を分解しながら、必要な成果物を抽出して行くという方法があります。
チャーハンの例でいうと、ゴールは「チャーハンを食べる」でそれに向かって、「完成したチャーハン」「チャーハンを乗せる食卓」「チャーハンを食べるスプーンか蓮華」「水の入ったコップ」という具合です。
それぞれの要素は更に、チャーハン＞器に盛り付け、食卓＞ランチョンマット、などのように中間成果物に分割されます。その上で、これらの成果物を作成するための実際の行動であるアクティビティに落とし込むことになります。
次回はこのテーマ、そろそろ収束に向かおうと考えています。