キットPM奮闘記 改め キットビジネスアナリスト奮闘記 -175ページ目

キットPM奮闘記 改め キットビジネスアナリスト奮闘記

PMの世界からビジネスアナリストへ、キットPM2.0を目指して奮闘中です。BAを超上流とか言いますが、当たり前のようで難しいビジネス要件をどうやればちゃんとまとめられるのか、皆さんとご一緒に考えていきます。

しかった連休も終わり、今日から仕事開始です。仕事の感を取り戻すのに少々時間がかかるかもしれませんが、スタートダッシュできるよう頑張りましょう。と自分に言い聞かせているキットPMです。

 

{AEB6240B-F3A9-4BF5-88A1-33EC51186B2E}
近くの公園の藤棚です。

日は「改めてWBSを考える」の2回目です。

 

  前回キットPMはテンプレート化されたWBSはあまり推奨することはしないと申し上げました。これには多くの異論があるのは承知していますが、あえて申し上げています。

  そこで、キットPMはなぜテンプレートを好まないのかについて、ご説明しようと思いましたが、その前にプロジェクトマネジメントについてあまり馴染みのない方向けに、WBSとは一体何なのかについて、念のために簡単に説明しておくことにします。

 

 

 

WBS(Work Brekdown Structure)は、「仕事の中身を作業に細分化し、構造的に表したもの」ということになります。知らない方はこれだけでは何のことか分らないとおもいますので、もう少し詳しく見ていきましょう。

 

  通常何かの仕事をするときは業務マニュアルみたいな手順書が存在することは前回お話しました。

 

  手順書があれば、そこにある通りに作業を行っていけば、やるべきことを(誰もが)完遂できるというメリットがあります。もちろんその品質は作業者の能力に依存する場合もあります。

  また、文書化することで業務の不効率な部分を発見して見直すことが可能になるというメリットもあります。

 

  これに対してプロジェクトは、何度も繰り返し実行するものではなく、基本的に一回こっきりの作業となります。

  また、どのように似たプロジェクトであろうとも、その詳細部分や取り巻く環境は大きく異なっているのが普通です。例えば全く同じプロジェクトでも、それを実施するタイミングによって、外部環境の違いなどか全く異なるWBSとなる可能性が高いのです。

 

  つまり、同じプロジェクトは2つとはなく、同じWBSを使いまわせるほどプロジェクトマネジメントは甘くないということです。ですから、一つ一つのプロジェクトにはそのプロジェクト専用のWBSが必要となります。

 

 

 

WBSの作りかたにはいろいろな考え方がありますが、目的はプロジェクト完了に必要な作業を、漏らさず、解りやすく表すことにあります。

 

  そのために作業項目をカテゴリ別に分類して、分類の大きなものから順に詳細化する(Breakdown)という手法を取ります。

  必要なタスクを構造化し考えることで、タスクの漏れを”少なく”しようというアイデアです。

 

  次回はこの手法について具体的に考えていくことにします。