ＷＢＳ

ＷＢＳ

Work Breakdown Structure

「革新的生産スケジューリング入門」第２章ディスカッション１



プロジェクトは複数の人が協力して、ある定まった目的を達成するために行なう、１回かぎりの時限的営為である。一つのプロジェクトは、さまざまな作業（任務）から成り立っている。この作業をタスクないしアクティビティと呼ぶ。プロジェクトを構成する多数のタスクを階層的に分類し、管理番号を定義したものを、ＷＢＳ（Work Breakdown
Structure）という。



“階層的に分類”とは、次のような意味である：ある製品開発プロジェクトが、かりに「市場調査」「設計」「試作」「生産準備」そして「市場投入」の５タスクから成るとしよう。その「設計」を、もう少し子細に見ると、それは「概念設計」「基本設計」「詳細設計」の３つに分割することができる場合、これらは設計タスクの下位タスクに位置づけられる。「詳細設計」は、さらに「機械設計」「電気設計」「制御設計」「外装設計」にさらに分解できるかもしれない。「設計」は最上位のレベルにあり（ふつう、これをレベル０とする）、「詳細設計」が中位のレベル１、「機械設計」がレベル２、と階層化されるのである。



では、どこまでも設計タスクは分解可能かというと、「鉛筆を手に持つ」「線を引く」という動作レベルまで分割しても、もはやプロジェクト管理上はほとんど意味がない。そこまでの粒度では計画も進捗管理もできないからだ。この点が、標準動作までを問題にする製造管理と異なっている（製造では動作は繰返されるが、プロジェクトでは個別動作でしかない）。



“これ以上分割すると、管理の手間の方が管理の効果よりも上回る”と感じられる常識的な線引きが、どこかにあるはずだ。そこで分割は止める。この作業の最小単位を「ワークパッケージ」とよぶことがある。エンジニアリング産業の経験では、どんなに大きなプロジェクトであっても、タスクの階層はレベル４まで、総タスク数は数万程度である。



さて、プロジェクトを構成するタスクは、プロジェクトと同じく、完了条件ならびにインプットとアウトプットが定義されていなければならない。つまり、タスクは“小さなプロジェクト”と考えることもできる。



よくあるＷＢＳ構成の間違いとは、ここに完了条件のないタスクを持ってきてしまうことだ。たとえば、「週次ミーティング」などである。週次ミーティングは、これこれを達成すれば終わって良い、という条件がない。したがって、こうしたミーティング類は、設計なり試作なりのタスクの一部と考えた方がいい。



もう一つ、よくある間違いは、「プロジェクト管理」というタスクを入れ忘れることだ。これがないと、プロマネの仕事がなくなってしまう。



ＷＢＳは、つねにその裏側にコストの積算とスケジュールのネットワークがぶら下がっている。つまり、コストとスケジュールの管理の観点から、ＷＢＳの構造は整理されなければならない。このためにこそ、各タスクに管理番号を付番するのである。



そして、このＷＢＳのコード体系こそ、その企業におけるプロジェクト管理の思想そのものを表わしている。ＷＢＳのコード体系は、プロジェクト計画において、タスクを洗いだす際、「重複なく・落ちなく」（Mutually
Exclusive and Completely Exhaustive = MECE）にリストアップするためのガイドラインを示すからである。



ＷＢＳの整理番号は、したがってすべてのプロジェクトに共通に振らなければならない。たとえば私の勤務先では、ＷＢＳコード2158といえば回転機の調達のことであって、それはどのプロジェクトでも共通に用いられる。従業員は誰でも、その番号を言われれば意味がすぐに分かる。



よく、ＷＢＳに1.3.2などのシーケンシャル番号を振っている例を見かけるが、これでは同種のタスクの番号が、プロジェクトごとに異なる可能性が高い。このようなコード体系はＷＢＳの名前に値しないことを理解するべきである。

Follow me!