良いWBS、わるいWBS

先日、「プロジェクトマネージャ合格論文集 改訂版 」(齋藤登志勝・編、リックテレコム刊)の読者の方からご質問があった。内容は、小生の執筆した論文で「・・・WBSを成果物(サブモジュール)中心ではなくプロセス中心に構成した・・・」と記載しているが、WBSの構成を変更した意図がわからない。WBSの構成変更のメリットは何か? というご質問である。

これはとても良い質問だと思うので、ここに取り上げさせていただこう。WBS(Work Breakdown Structure)構築の中心課題があるからだ。最近WBSという用語・概念が業種の枠を超えて広まったのは、とても良いことだと思っている。しかし、その結果(?)、奇妙なWBS、不思議なワークパッケージを見かける機会もでてきたように感じる。この論文では、その点をやんわり取り上げたつもりだった。

WBSは、誰でも作れる。プロジェクトを種々の作業の階層構造に展開することは、ちょっと頭が働く人間ならば、可能である。しかし、時計を部品に分解していくのとちがって、展開のやり方には、いろいろなアプローチがありううる。つまり良いWBSも、わるいWBSもありうるのだ。後者を作ってしまうと、その後のプロジェクト・コントロールが混乱しがちになる。

米国PMIは"Practice Standard for Work Breakdown Structure"というモノグラフを出している(2001年刊)。本文がたった18頁で、付録が58頁もある、珍しい本だ。本文では、WBSの説明として、PMBOK Guideを引用して、"A deliverable-oriented grouping of project elements"だと書いている。このまま訳すと、『プロジェクト要素の、成果物指向によるまとめ上げ』ということになる(ちなみにPMBOK Guide第3版では"A deliverable-oriented hierarchical decomposition of work")。

前の「WBSのつくり方」にも述べたように、WBSへの分解は大別して、成果物中心と、プロセス中心の方法がある。両者は一長一短あり、成果物中心は“もれなく・重複なく”ワークを数え上げるのには適している(いわゆるMECEな展開だ)。後者はWBSのマスタを作りやすいという長所がある。そして、PMIの本は前者を推薦しているように見える。しかし、この本の付録にあげられた、数々のプロジェクトのWBS例では、必ずしも、いや、ほとんどがそうなっていない。たとえばAppendix OにはSoftware Implementationの事例がついているが、Level 1をリストアップすると、

1 Project Management
2 Product Requirements
3 Detail Software Design
4 System Construction
5 Integration & Test

という具合だ。私が本の論文に書いた事例のケースとよく似ている。でも、いったい何故こうなのか?

じつは、このモノグラフの本文第4章には、WBS作成上の留意点がいろいろと説明されている。その一つに、「WBSが作業間のロジカルな依存関係を十分規定していること」という要件がある(ロジカルな依存関係が何かについては、『ロジック・ネットワーク・スケジュールとは何か』を参照してほしい)。また、「すべての作業は、見積・配員・スケジュール・予算化が行われ、コントロールされなければならない」とも書かれている。WBSを作成する目的はプロジェクト・スコープを、コントロール可能な作業要素に分解することにある。このとき、WBSはあくまでも、枝葉だけではなく木や森が見えるようになっていなければならないことを、この節は告げている。

これはすなわち、コストやスケジュールの進捗実績情報を集計していくときに、WBSの構造にしたがってロールアップされるということだ。だとしたら、プロマネであるあなたは、基本設計→詳細設計→実装、という方向で進捗やコストを見たいのか。あるいは、画面モジュールA・画面モジュールB・帳票モジュールC、という風に見たいのか、ということに帰結してくる。

もしも大規模なシステムを開発していたら、基本設計の全体性integrityが固まらないうちに、いくつかのモジュールの詳細設計に進むことなど、普通は許さない。そんなことをしたら、あとで設計の手戻りの危険性が高くなる。だから、プロセス中心のWBSが望ましいのだ。これが、パッケージソフトのマイナー・バージョンアップ程度の仕事なら、ばらばらにモジュールに手を入れてもかまわないだろう。だから、成果物中心WBSでもまったく問題ない。

ちなみに余談だが、中国のオフショア開発で私が経験した事例では、個人がそれぞれ決められたスコープの縄張りの中で(他人は一切お構いなしに)猛スピードで突っ走っていく仕事のやり方だった。これがその会社だけの慣習なのか、あるいは中国全体に共通するマネジメント・スタイルなのか、即断は避けたい。しかし、このような状況では、個人別にモジュールを渡し個人単位にWBSを切って進捗を稼いでいたら、統合テストがめちゃくちゃになるのは目に見えている。

PMIのモノグラフの付録は、実務家が集まってワークショップ形式で作り上げたものだ。だから、おのずからコントロールの方向性が定まっているのだろう。それは、たまたまかもしれないが、プロセス指向がメインだった。とくに、目に見えないものを作り上げるプロジェクトでは、最初はなかなか航空機の部品表のように構造は決められない。したがってプロセス指向にならざるをえないのである。WBSの良しあしが、プロジェクトを左右する--ここが、プロジェクトマネジメントの難しさでもあり面白さでもあるのだ。

(末筆ながら、本参考書の編著者である齋藤登志勝先生は本年11月、若干42歳の若さで急逝された。人柄・能力・経験、いずれの点でも惜しまれてあまりある人材だった。先生のご冥福をお祈りしたい)