WBSには欠かせないルールがある
WBSという言葉はすでに市民権を得ていて、マネジメントを行う役割を担っている人であれば経営者であれ末端のプロジェクトマネージャーであれ、知らない人はないというくらい知られている言葉です。
しかし、そのWBSを正しく理解して活用しているマネジメントというのはそれほど多くは見かけません。実践はしているけれども「なんとなく」の域を出ない
"なんちゃってWBS"
しかみかけない…というのが正直な感想です。
なぜならWBSには「絶対に欠かせないルール」というものがあるにもかかわらず、それらが正しく活用されずにWBSだけが独り歩きしていてこのルールが守られていないからです。
WBSとはその名の通り Work Berakdown Structure 。
簡単に言ってしまえば「仕事を分解し、整理すること」、そのことに間違いはありません。ですが、この当たり前にして基本中の基本であるひとことには次の意味も含まれています。
「分解した部品は、余すことなく組み立てれば仕事として完璧な形になる」
ということです。そもそもプロジェクトも通常は上流工程で理想とするイメージから分解して小タスクを実現します。その小タスクで出来上がった成果物を組み立てていって、最終的に完成品としていきます。
ソフトウェア開発などであればウォーターフォールであってもアジャイルであっても多かれ少なかれきれいにこの図のようになることでしょう。
ルール１「100％ルール」
「100％ルール」は、要素分解を行ううえで最も重要なルールであり、一言でいえば
「子要素をすべて足し合わせると親要素と等しくなる」
というものです。同じような意味で「子要素は親要素を100％満たすものでなければならない」というのもあります。例を見てみましょう。これは「コーラ」を要素に分解したものです。
これを見るとコーラは「カラメル色素、酸味料、甘味料、香料、保存料、カフェイン、炭酸水」を組み合わせて100％になることが分かります。分解したものをすべて組み合わせると元通りにならないようではWBSとして失格です。
これがWBSであることの基本にして究極。初歩にして絶対の条件となります。
しかし、100の仕事を分解してそれぞれ10ずつの部品に整理したにもかかわらず、組み立ててみれば70の仕事しかなかった…といった抜け漏れだらけのプロジェクトが後を絶ちません。その証拠に、みなさんが参画しているプロジェクトがあればWBSを見てみてください。ほぼ100%すべてのタスクが管理されておらず、抜けたタスクが別のどこかで生み出されているはずです。
特に、プロジェクトマネージャー自身のタスクは欠落が多いはずです。
また会議体についてもスケジュールには勘案されていないことでしょう。
たとえば、週に１度の内部定例と顧客との外部定例で会議を開くとしましょう。それぞれ１時間ずつ消費するとします。またそのためだけに事前資料を作成したり、議事録の作成ややり取りもあると仮定します。
全体で週単位で２時間。10人のプロジェクトチームであれば20時間。内１～２名は資料の作成にさらに半日（２名であれば１人日）ほどは消耗することでしょう。それが毎週のように発生することになりますが、そうしてメンバーが個々に遅れることに対して適切に計画を立てていないから、都度残業を強制することになります。
こうした遅れはメンバーの責任ではありません。ひとえに計画をそうさせたプロジェクトマネージャーと、それを承認した管理職にあります。
昔から言っていることですが、そうやってWBS作成の時点で分解すべきすべての部品を管理していない、あるいはそのせいで計画を形骸化させたプロジェクトのなんと多いことでしょう。
ルール２「8／80ルール」
分解の粒度の目安を示すルールです。
breakdown（分解）といってもプロジェクトマネージャーが自分勝手すればいいというものではありません。分解された部品の粒度が適当ではマネジメントできない可能性もでてきます。
考えてみてください。
プロジェクトマネージャーと一口に言ってもその力量はピンキリです。
人によっては２日に１回管理するだけでマネジメントできる人もいれば、１週間に１回の管理でマネジメントできる人もいます。毎日管理しなければまともにマネジメントできない人だっています。
そのため、分解するといってもその部品の規模はプロジェクトマネージャーごとに幅があるというのも頷けます。しかし、進捗管理の頻度を考えると無限に幅があっていいというわけではありません。過去の判例で取り上げられた『ＰＭ義務』にも定義されているように発注側…すなわちお客さまが安心できる範囲内で管理が行われていなければなりません。
被告は，システム開発の専門業者として，自らが有する高度の専門的知識と経験に基づき，本件電算システム開発契約の契約書及び本件電算システム提案書に従って，これらに記載されたシステムを構築し，段階的稼働の合意のとおりの納入期限までに，本件電算システムを完成させるべき債務を負っていたものである。
したがって，被告は，納入期限までに本件電算システムを完成させるように，本件電算システム開発契約の契約書及び本件電算システム提案書において提示した開発手順や開発手法，作業工程等に従って開発作業を進めるとともに，常に進捗状況を管理し，開発作業を阻害する要因の発見に努め，これに適切に対処すべき義務を負うものと解すべきである。そして，システム開発は注文者と打合せを重ねて，その意向を踏まえながら行うものであるから，被告は，注文者である原告国保のシステム開発へのかかわりについても，適切に管理し，システム開発について専門的知識を有しない原告国保によって開発作業を阻害する行為がされることのないよう原告国保に働きかける義務（以下，これらの義務を「プロジェクトマネージメント業務」という。）を負っていたというべきである。
そこで一般化されているのが
「要素への分解はワークパッケージがおよそ8時間以上、80時間以内になるまで」
実施するというルールです。
８時間といえばおよそ１日、80時間はおよそ２週間ですが、８時間を「１日」と読み替えることで24時間働かせて１日で終わらせる…といったブラック丸出しのマネジメントを行うプロジェクトマネージャーはいまだに数多くいらっしゃいます。これは無理に期限を守らせたというだけでマネジメントとしては最低です。所要日数ではなく、あくまで所要時間で考えてください。
それができない人はすでにハラスメント…コンプライアンス違反に手を染めている可能性があります。
もちろん8-80というのはあくまでも指標でしかありません。プロジェクトマネージャーによっては4時間でもかまいませんし160時間でも問題はないのですが、自分自身の力量で管理しきれる範囲内までとしましょう。ここでいう管理とは、
自身の力量において計画通りに進行させることが可能なこと
計画通りに進まなくても、自身の力量においてリカバリが可能であること
を意味します。それが遵守できないのであれば力量不足です。命令するだけ、偉ぶるだけでメンバーに頼るしかできないそれは管理とは呼びませんので注意してください。
ルール３「7×7ルール」
これは
「1つの親要素にぶら下がる子要素の数は7程度まで
WBS全体のレベルは7レベル程度まで」
という、子要素の数とレベルの深さについての目安を与えるものです。これも７×７にしなければならないのではなく、プロジェクトマネージャーの力量次第でもっと多くても少なくても問題はありません。
ただし、「７」という数字はビジネスの色々なところで相性が良かったりするので覚えておいて損はないでしょう。人事管理担当や管理職であれば聞いたことがあるかも知れません。これは"ミラーの法則"によって
「１人の人間が管理できる上限は７人」
とされており、同様に"マジカルナンバー７±２"という論文や脳科学の発表などによって、人間の「短期記憶」は７個前後が精一杯と言うことも報告されており、そういった観点に基づいていると言えます（曜日は７つ、ドレミの音階は７つ…とあるように、人間のワーキングメモリー限界は７桁であるという説）。
そういった事情から、子要素の数が多くなり過ぎるとWBSは途端に見づらくなります。ルールを適用し、同じ親要素を持つ子要素の数が8を超える場合は、１つ上のレベルに戻って親要素を増やしていかなければ管理しきれなくなる可能性が出てきかねません。
また、８レベル以上に分けなければいけないようなWBSは、総ワークパッケージ数が数千個にもなってしまって実用的ではなかったりもします。複数のプロジェクトに分割するか、分解の粒度を荒くしなければならないでしょう。
「プログラムのメソッドは50行まで、ネストは２つまで。
それ以上深くなる場合はメソッドを分割すること」
みたいなプログラムの構成を考える時に似ていますね。
ただし、厳密に適用しなければならないのは「100％ルール」のみです。
残りの２つのルールは目安と考えて良いでしょう。
これらのことが守れていないWBSというのは一気に価値が下がります。
実際、日頃から確認しようとするメンバーも少なくなっていたりはしないでしょうか。
「ご参考」程度のものであればいいのかもしれませんが、正しくマネジメントを行うには不十分です。プロジェクトを少しでも失敗させないようにするためにも、こうしたノウハウは使いこなせるようになっておきたいですね。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。