第16回WBS

WBS(Work Breakdown Structure)はプロジェクトマネジメントにおいて基本となるものであるが、思いのほか活用されている例は少ない。これまでいろいろなWBSを見てきたが、エンジニアリング業界やソフトウエア業界などのプロジェクトマネジメントがプロフェッショナルとして認識されている業界以外で、洗練されたWBS を見ることはほとんど無かった。　さらには、プロジェクトマネジメントは知っていてもWBSは知らないという人も多い。なぜ、これほどWBSが浸透していないのであろうかと、非常に不思議に思うものである。しかし、よくよく自分自身を振り返ってみると、あまり人のことは言えず、プロジェクトマネジメントはやっていてもWBSは使っていなかった時代があることも事実なので、筆者とWBSの出会いから話を進めることにする。

WBSとの出会い

筆者が最初にWBSに出会ったのはエンジニアとして海外プロジェクトを担当していた1980年代に遡る。エンジニアリング業界では、プロジェクト計画の重要性は誰もが認識しており、プロジェクト計画はリスク等を考慮し時間をかけて立案していた。しかし、プロジェクトマネジメントのほとんどは先輩方のやり方をまねて学んだものであり、私の入社当時は誰もWBSを使って計画を立てている人はおらず、WBSについては全くといって良いほど知識が無かった。

WBSを知るきっかけは、顧客である米国オイルメジャーの大規模プロジェクトを担当することになってからである。WBSの活用は顧客の要求であり、スケジュールの進捗だけに関わらず、プロジェクトの進捗やコストの状況をWBSベースで報告することを義務付けられたのがきっかけであった。プロジェクトコントローラーとして顧客といろいろと討議し、プロジェクトマネジメント体系をWBS中心に作り上げ、プロジェクトマネジメントシステムを活用したプロジェクトマネジメントを実践することとなった。今で言えばプロジェクトマネジメントオフィスのリーダーの立場である。

当時はWBSの作り方どころか、WBSの使い方さえ知らなかったので、海外の本や文献を読みあさり、他のエンジニアリング企業でWBSの知識のある方々にも教えを乞い、何とかプロジェクトマネジメント体系を作り上げ何とか顧客が求めるレベルのプロジェクトマネジメントを実践し、無事プロジェクトは成功裡に終えることができたが、今でも良くできたものだと冷や汗ものである。

しかし、スケジュールコントロールを中心にしたマネジメントしかやっていなかった当時の自分にとっては、WBSはとても新鮮でもあった。また同時に、プロジェクト計画の手順が間違っていることも理解し、WBSを中心にスコープ決めを行い、それをもとにプロジェクト計画を作り上げるやり方実践しながら始めて学ぶこととなった。

それまでのマネジメントはカンと経験の世界のマネジメントであり、当時は自分のような若手にはとても難しく、時間と経験を積むしかないと思っていたが、WBSやシステムを活用した科学的なマネジメントは新しいマネジメントの世界を自分に見せてくれ、その可能性と面白さに惹きつけられ現在に至っている。また、プロジェクトマネジメントのコンサルティングを続けていく中で、WBSが単に科学的なマネジメントのツールではなく、プロジェクトを成功に導くコミュニケーションツールであることにも気がつき始め、さらにはWBSがプロジェクトの戦略を作り上げる道具であることも理解するようになった。WBSの構造自体は簡単であるが、その活用次第では多くのものを引き出せる道具にもなる。以下、WBSについて自分が考えるところを解説する。

WBSの意味合い

WBSの形は業界ごとに異なり、また同じ業界でも企業にとって異なってくるものであり、必ずこう作らなくてはならないというルールがあるものでもない。プロジェクトを遂行するには作業(Work)が必要であるが、その実施すべき作業を特定するにはプロジェクトの達成目的・目標を明らかにし、それを達成するために必要な作業を明らかにしなくてはならない。 WBSはその作業を明らかにするためのツールであり、そこで明らかにされた情報をもとにプロジェクトをコントロールする体系でもあり、さらにはプロジェクトに関係する人々のコミュニケーションを円滑にするためのツールでもある。下記にいくつかのWBSをタイプごとに示すが、同時にWBSを作成するうえで重要なポイントを幾つか説明することにする。

プロジェクト目的、リスクの明確化

WBSを作成するための条件としてもっとも重要な点は、プロジェクトの目的と達成すべき目標を正しく把握することである。WBSはプロジェクトのスコープをあらわすが、スコープは目的によって決まってくる。そのプロジェクトがどういう目的で成立しているのか、プロジェクトによって獲得しようとしているものが何であるのかによってWBSは大きく変わってくる。建設プロジェクトだろうが製品開発プロジェクトであろうが業務変革プロジェクトであろうが、この点は共通である。

プロジェクトの本質は投資であり、プロジェクトに投資を行って、その投資に対して期待する成果を求めようとしている。その期待すべき成果に対してプロジェクトが成立しているのであって、期待すべき成果がわからなければやるべきこともわからないのは当然のことである。そのため、プロジェクトのWBSを作る前に実施すべきことは、このプロジェクトによって何を実現するのかを明らかにする必要がある。

たとえば、発電所建設プロジェクトにおいて、プロジェクトの目的は100万キロワットの火力発電所を建設するということだったとしても、ただそれだけではとても良いWBSを作ることは出来ない。100万キロワットの発電所となると2,000億円近くのコストが必要となってくるが、その莫大な費用負担をどのように返却し利益を計上できるかが成功か失敗かの鍵となる。運転効率は特に事業採算に大きく寄与する重要な要素であり、発電所の実現すべき稼働率、発電効率などの目標を達成しなければプロジェクトの投資目的は失敗に終わってしまう。

これらは、目標であると同時に、成功を阻む可能性のあるリスク要因でもあり、これらのリスク対応を加味したWBSが作れないとプロジェクト目標の実現は厳しいものとなる。さらにリスク要因として、環境汚染対応や周辺住民説明など直接には発電所の機能に関係はないが、それが上手くいかないとプロジェクトが危機に陥るようなものも存在する。WBSはこのようにプロジェクトの目的やプロジェクトの成功を阻害する要素(Killing Factor)に対して、対応が取られたものでなくては良いWBSとはいえないのである。

安定的な形を持つ

プロジェクトの目的やリスクは正しく理解したとして、次にどのような視点でWBSを作ればよいかを説明する。WBSはコストコントロールだけでなく、プロジェクトコントロールを行うための器となるため、安定していることがとても重要であり、WBSの構成要素が頻繁に変わってしまっては、コントロールするための器としての役割は果たせなくなる。WBSのベースがしっかりして安定しているものは、プロジェクトの進捗が遅れていてもリカバリーできる可能性が高いが、WBSのベースが不安定なものは容易に遅れをリカバリーできないことが過去の経験から知られている。

では、安定したWBSを作るためにはどうすれば良いかであるが、いくつかポイントがある。1つは成果物を軸にWBSを作りあげることである。WBSの WはWorkの意味であるが、Workを決めるものは成果物である。成果物はイメージしややすくプロジェクト関係者のなかで議論もしやすい。作るための費用も見積もることもでき、出来たかどうかを測定することも可能である。成果物を中心にWBSを作りあげ、その成果物を具体化する作業（Work）を洗い出すことによって、WBSは安定した形を見せることになる。

もう1つ重要なポイントをあげると、100％ルールと呼ばれるもので、WBSは階層構造を示すが、上位のWBSのパッケージはその子供の下位のパッケージの内容を100％網羅するような関係となっていることである。上位で定義したパッケージを実現するために必要なことが、下位のパッケージで100％表現できているかどうかをチェックすることである。そうでなければ、WBSはプロジェクトのスコープを100％表現したものにはならず、必ず抜けが存在しその抜けがプロジェクトの遂行を危うくすることにつながるからである。

チームによる作成

次に、WBSを作成する手順において重要なポイントがあるので説明する。それは、誰がどのように作るかである。

たとえばプロジェクトの要求、条件をすべて細かく記載したプロジェクト仕様書なるものを作成して、10人の経験者に配り、それぞれWBSを作ってもらったとしよう。10名の経験者は、それぞれがWBSを作ってくるが果たして同じものが出てくるだろうか？　答えはNOである。すべてが異なるWBSを作って持ってくることになる。人は、自分の経験に照らし合わせてものごとを考えるものである。10人の経験者は自分の経験をもとにWBSを展開するが、同じ経験をしてきた者など一人もいないはずである。それに、人の性格というものが加わればさらにバラエティーに富む。チャレンジ的な人もいれば、保守的な人もいるし、粗い人もいれば、細かい人もいる。その人のパーソナリティーから来る思考と経験によってWBSは出来上がってくるとなると、インプットが同じでも各人のプロセスがすべて異なるので、当然アウトプットも違ってくるのは至極当然のことである。

同じプロジェクトでも結局10種類の異なるWBSが出てくることになるが、それを評価すると、良いWBSもあれば、なかには問題があるWBSもあるだろうし、10個のWBSには優劣がつくことになる。つまり、誰がWBSを作るかかということは非常に重要な意味を持ってくる。プロジェクトコントロールのベースとなるWBSの良し悪しはプロジェクトの結果を左右してしまう。できるだけ安定した、プロジェクトの持つリスクにも耐性を持った、かつ経済的な WBSを作りたいが人によって大きくバラツキがあるとなると、どうすれば良いかやり方を工夫するしかない。経験を持ったプロジェクトのチームのメンバーを集めて、それぞれが自分の経験と知恵を出し合い、議論しながらWBSを作ることが高い確率で良いWBSを作る唯一の方法なのである。そのためにはチームメンバーには最初からプロジェクトに参加してもらい、WBSを作るための時間を与えなくてはならない。このプロセスが組織として機能している企業と機能していない企業には大きな差が出てくることになる。

WBSの作成は計画を作るうえもっとも重要な作業であるが、その重要性を理解して時間をとるのか、仕事が忙しいという理由で十分な時間が取れず誰かがなんとなくWBSを作ってしまうか、この時間の使い方がプロジェクトの成果に大きく差をつけるが、そこに気がつかないまたは気がついてもできていない企業は驚くほど多いこともまた事実である。

さらに、WBSの作成において、プロジェクトチームのメンバーだけでは不充分と思う場合は、組織において経験のある人たちを積極的にWBSの作成に参加させることも1つの方法である。計画フェーズはできるだけ多くの知恵を入れるところであり、ここに労力を惜しんではならない。プロジェクトの成果を考えた場合、外部の経験者の知恵を借りてでも質の高いWBSを作ることは、決して高い投資ではない。プロジェクトマネジメントの本質として「源流管理」という言葉があるが、まさにプロジェクトの立上や計画ステージにおいて、組織として知恵と時間を使うべきであり、時間の使い方を間違えてはいけない。プロジェクトの上流側にこそ価値の源泉が存在している以上、そこに注力すべきなのである。

また、WBSのもう1つの側面であるコミュニケーションツールとしての性格を考えた場合もチームでの共同作業によるWBS作成は理にかなっている。 WBSを作る過程でWBSの内容を誰もがよく理解することで、WBSが出来上がったあとはそのWBSベースに容易にコミュニケーションを行うことができるようになる。チームによる作成は、WBSの質を確保し、コミュニケーションのベースを築きあげるためにも重要な方法といえる。