いまさら聞けない上手なWBSの展開の仕方
WBSとは、Work Breakdown Structure の略称です。日本語にすると作業分解構造です。そのままだな。
ところで中堅のシステムエンジニアがプロジェクトのサブリーダになって担当するブロックのWBSをPMから詳細に展開するように指示がでて、「WBSを作ったのを見てください(ハート*)」とお願いされることがあります。
*注記 現実にはハートはありません。書いてみたかっただけです。
お願いされるのはいいのですが、これがまた十中八九「がんばろう」のレベルだったりします。じゃあ、ベテランのシステムエンジニアのWBSなら「大変よくできました」となるかと云うとそれがまた「もう少しがんばろう」だったりします。
「なんでかなー」とずっと不思議だったんですが、先日、わかりました。なるほど。ひとり、合点していました。いやーよかったよかった。
自分でWBSを作ったり、いけてるプロジェクトマネージャが作るWBSは、「あぁ、こんなもんだよね」とまるで関心のないくらいあっさり見切れるというか、「んっ」と疑問に思って「なんでこのWBSこうなっているの」と尋ねると明快に回答がくるのでその返答を聞けば納得できるんですよ。
その差がでるのがイミフだったわけです。中堅のシステムエンジニアだって、ベテランのシステムエンジニアだってそれまで少なくても自分のWBSは作ってきただろうし、ブロックのリーダをやっていたらメンバのWBSだって見ていただろうと。経験はしているよね。でもなんで差が出るのかな、と。
その差がわかった(確信)。例えば、基本設計書を作成するWBSを展開するとします。イメージは下表のとおりです。
WBS ID | level-1 | level-2 | level-3 |
1 | 基本設計 | システム化範囲 | 概要 |
このとき、いけてるプロジェクトマネージャは、WBS IDが1番のWBSを展開するときに2つのことを頭の中に入っています。1つは、成果物。もう1つは作業プロセス。
一方、いけていないWBSを作る中堅システムエンジニアは、とにかく作業を思いつくところから書いていきます。思いつくところから書き出すので経験していること、知っていることがネタです。あれ書かなきゃ、これ書かなきゃ、と行が増えていきます。
いけてるプロジェクトマネージャは、この作業でどんな成果物を作ればいいかイメージしながら作業を展開します。
WBS ID | level-1 | level-2 | level-3 | プロジェクトマネージャの頭のなかにあること |
1 | 基本設計 | システム化範囲 | 概要 | ← システム界面で責任範囲を線引きしよう ← 執筆から外部レビューの反映までやる |
1つのWBSに対して成果物とやる具体的な作業を定義しているわけです。だからワタシが質問してもすぐに答えられるわけなんです。ところが中堅の「がんばろう」なシステムエンジニアは成果物も作業プロセスも頭に「明確に」ないから展開するWBSがちぐはぐになるわけです。それが進むとWBSのレベルもWBSによってlevel-2だったりLevel-3だったりとLevel感もバラバラになっちゃう。作業プロセスが決まっているなら同じ作業なら同じLevelで分解されるのに。
じゃあ、どうすればいいか。WBSを展開するときに「成果物を記載する列をはじめに入れておきましょう」です。
WBS ID | level-1 | level-2 | level-3 | 成果物 |
1 | 基本設計 | システム化範囲 | 概要 | 基本設計書 |
作業プロセスはどうしましょうか。もうWBSにしちゃいましょう。
WBS ID | level-1 | level-2 | level-3 | 成果物 | メモ |
1-1 | 基本設計 | システム化範囲 | 概要 | 基本設計書 | ↑ここから |
1-2 | 基本設計 | システム化範囲 | 内部レビュー | 内部レビューメモ | |下までを |
1-3 | 基本設計 | システム化範囲 | 外部レビュー | 外部レビュー記録 | ↓プロセスに |
上表のイメージの場合は、3行でプロセスを表しているので、成果物の分だけコピペすればいいわけです。WBSが2000も3000もあるなら3行を1つのWBSにして1行のWBSの作業プロセスを定義しておくのがいいですけどね。