連休真っ只中の今日は、すこぶるいい天気となったここ北摂地方ですが、全国的にも好天に恵まれた一日となるようです。もちろんこの時期が書き入れ時のお仕事をされている方はてんてこ舞いだと思いますが、お仕事頑張ってさい。
梅田の高層ビルからの夕景(真下は大阪駅)
さて前回まで「プロジェクトの終活」と題して、プロジェクトの終結プロセスを事前にどうデザインするかということについて考えてきましたが、一つ補足があります。
連載回数が長くなったので端折ったのですが、プロジェクトの目的の達成を評価する以外に、「プロジェクトマネジメントの評価」「プロジェクトメンバの評価」「メンバの自己評価」があります。それぞれについて、いろいろと考えることもあり、重要で面白い考察ができるのですが、それはまたの機会ということでお願いします。
ということで、今回から新テーマです。どんなテーマにしようかと悩んだのですが、プロジェクトに関わる誰もが当たり前のように知っていて、かつ上手く使いこなせていないWBS（Work Breakdown Structure）について、その合理t来な作成方法について考えようと思います。久々に実践的テクニックの話しとなります。
さて「わーく・ぶれいくだうん・すとらくちゃー」などどいっても、本質は作業手順一覧表なのですから、特別にプロジェクトマネジメントだけのために必要なものというわけではありません。
皆さんも日ごろの業務でマニュアルなどの手順書を利用されたことがあると思います。そこに記述されている”手順”が”WBS”そのものとなります。
ただ日ごろの業務を助けるための”業務手順書”とプロジェクトマネジメントで使う”WBS"とは少々性格が異なる面があります。
”業務手順書”も”WBS”も、仕事のでやるべき手順や作業を明らかにし、作業者がそれを参照しながら確実に、間違いなく作業を進め、終わらせるために利用するわけですから、最終目的は同じです。
”業務マニュアル”の場合、部署や業務単位で用意されていると思います。わかりやすいのは、マクドナルドなどの外食産業で使うマニュアルですね。
この場合、マニュアルの内容は業務を行いながらまずいところがあれば、修正をしたり業務改善がされればそれを反映したりと「育てていく」ことが重要になります。
これに対してプロジェクトのWBSでは、基本的にそのプロジェクトのためだけに存在する”手順書”となります。
基本的にはと但し書きが入るのは”テンプレート”と称するひな形を用いる場合があるり、同じWBSの内容を使いまわすことがあるからです。
ただしキットPMはこの「テンプレートの使いまわし」は推奨しません。その理由は、何度もブログで言っているようにそれぞれのプロジェクトは唯一無二の存在だからとうことです。
どのように似たような内容のプロジェクトであっても、プロジェクトを取り巻くビジネス環境などの外部環境や、異なるプロジェクト体制や利用技術の違いなどから、全く同じになることはありません。
それを前提としたとき、テンプレートを利用したWBSの作成は大きな危険を孕んでいることになります。
いつもと違うからプロジェクトであって、いつもと同じであればそれはプロジェクト化する必要のない”日常業務”となります。もちろん、過去の類似のプロジェクトで作成したWBSを参照することを否定するものではありません。
でもテンプレートととして使う利便性より、プロジェクトマネジメント上の危険性の方が大きいというのがキットPMの持論です。次回はどのような危険があるのか、掘り下げていくことにしましょう。