WBSは有効ですか？

Question

WBSについて教えてください。

先日初めてある企業の常駐プロジェクトで、WBSを使う機会がありました。
それは単に作業を入力する共有するExcelファイルのようなもので、書くのが手間であるだけでなくて、作業の軽重と微妙にずれていて、無意味だなぁと感じました。
そのうえ、プロジェクトが佳境に入ると、だれも入力しなくなってしまい、放擲されてしまいました。結局口頭でのプロジェクト管理いうところに戻ってしまい、非常に泥臭い感じでした。
プロジェクトは約10人前後で、3カ月くらいの規模でした。

別のときに、WBSの目的について問われました。
経験上わたしは、WBSの目的がなにかを答えることができませんでした。だって、入力が手間であるだけでなくて、操作性が悪く、使いにくいので見ないし、最終的にはいちばん必要であろうときに放擲されてしまうのだから、そんなものには意味がない、としかいえなかったためです。

Googleで、「WBS 目的」と調べたところ、「WBS(Work Breakdown Structure)は、プロジェクトで作成する成果物を基準に、全体の作業を各作業レベルまで細分化しトップダウン的に階層化して表した一覧表である。各作業ごとに内容・日程・目標を設定することでプロジェクト管理をしやすくする手法として使用する」とありました。
これ、ほんとうですか? というかまあほんとうはほんとうなのだと思うのだけど、それがほんとうに有効であることはあるのでしょうか?
どうしたら有効にできるのですか?

Answer 1

まず初めに断っておきますが、私は開発系SEではなくインフラ系SEだったので、すこし様相が異なるかも知れません。少なくともインフラはアジャイル手法は使えない(長期計画なら使えないことも無いのですが、それは別の話で)ので、ウォーターフォール手法でやる開発みたいなものと思ってください。
(開発は全くしなかったと言うことでは無く、開発のプロジェクトも何度か入ったことがあります)
(なお、今はただの事務職員です。なぜか仕事でプログラミングもしていたりしますが・・・あれ？)

さて、WBSを使うと何ができるのかを見ると、どこが有効なのかが見えてくると思います。

###WBSを使ってうれしいこと

#####進捗管理ができる

きちんと管理されたWBSには、計画(スケジュール)と達成度(進捗状況)が記載されます。WBSのツールの中にはそこからスケジュール表まで作ってイナズマ線まで引いてくれる物もあります。これのいいところは、ぱっと見て、進捗が進んでいるのか遅れているのか、余裕なのかヤバイのかがわかるということです。良いツールであれば視覚的にわかりやすく、何が問題点なのかも把握できます。リスケすることも、遅れている言い訳を考える(え？)こともし放題です。

ぶっちゃけ、これは別にWBSを使わなくてもできます。工程が単純で小さなプロジェクトなら、適当なスケジュール表で十分です。少ないメンバーなら、各メンバーの進捗も日々の打ち合わせで済みます。そこそこの規模でない限り私もWBSなんて使いませんでした。エクセル(ガントチャートがかける適当なツールでも良いです)で適当なスケジュール表書いて、打ち合わせを反映したイナズマ線を書いて終わりです。

しかし、大きく複雑なると厳しくなります。一人で全メンバーの進捗を細かく把握することができなくなるからです。チームに分けて、それぞれに管理させるのが一つの手ですが、今度はそこからどうやって全体の進捗を把握するかが問題になります。やり方は色々ありますが、WBSを使って共通の資料として各チームから提出させ、それをまとめさせて全体を把握する…のは一つの手法としてありだと思います。

#####終わった後にそれぞれの工数がわかる

WBSの本質はむしろこっちです。プロジェクトが終わった後の分析にこそWBSが真価を発揮します。

最初の計画となるWBSを作るのは実は簡単です。なぜなら、各作業内容と工数は既に見積もりを書くときに算出しているからです(人数固定の常駐型だとそうでもないかもしれませんが、少なくとも納期を決めるためには工数を見積もらないとできないはずです)。見積もりの時に作った作業内容と工数の表に、人員や工程が矛盾しない開始日を入れていくと、あら、簡単、WBSができあがります。
※ そのとき、見積もりよりも粒度を更に細かくする場合もありますが、ケースバイケースかと。

そう、WBSに書いてあるスケジュールの根拠は見積もりの時に出している想定工数です。実際にプロジェクトが開始すると、進捗が速かったり、遅かったり、工程や作業内容によって差が出てくるでしょう。もし、計画と大きくずれていれば、そこが見積もりが甘いところとなります。どうして進捗が良かったのか、どうして悪かったのかを分析することで、良かった点と悪かった点が見えてきます。これは次ぎの仕事に生かせます。また、見積もりについても甘い部分を減らせば、赤字になる可能性を減らしますし、ギリギリのラインが見極められるので、戦略的な価格交渉もしやすくなります。

また、WBSが実態にあってなかったら、それこそ見積もりが初めから破綻していたことを示します。なぜ、想定と違っていたのかを分析することは必須です。それができなければ、同じ案件は二度と取らない方がいいでしょう。想定から外れることは膨大な赤字を生み出す可能性があり、一番恐れなくてはならないことです。

もし、WBSがなく、適当なスケジュール表だけだったら・・・最終的な全体の工数がわかっても個々の工数は把握できません。会社としては利益率がどれぐらいだったかをそれで把握はできますが、残るのは全体的な感想だけで、次に生かせる細かい分析ができません。「あの客はつらいからやめよう」とか「あういう系の仕事は楽だから次も取りに行こう」とかおおざっぱな事だけでは、分析しているとは言えないのです。いや、それでも仕事はできまるんですけどね、ただ、そこから裏を感じ取って細かい調整ができる人だけ生き残る、ただそれだけです。

もうおわかりのように、上のことで嬉しいのは工数を見積もるプロマネだけです。現場の一作業員にとってはお金や工数の計算なんてどうでも良いことです(本当はよくありませんよ)。利益を追求する企業としてはこちらの方が重要です。もし、一から見積もりを作り、プロジェクト全体をまとめるプロマネになったとき、そして、プロジェクトが終わったとき、上司から「で、今回のプロジェクトの問題点は？」と聞かれたとき、一体何を根拠に語るつもりでしょうか？その問題点の分析とその根拠(と言う名の言い訳)としてWBSは有効です。

###なぜ失敗した(と思った)のか？

逆に質問者さんはなぜうまくいかなかった(と思った)のかを勝手に想像してみました。
※ プロジェクト自体は成功したそうなので、WBSが足を引っ張ったのかは私にはわかりません。

#####今までとは違うことへの反発

私も、最初はWBSなんて使ってませんでした。ですが、ある日突然、上から使えと言われました。書き方を示した細かい資料まで渡されて…。まぁ、初めは何こんなの書かなきゃあかんの？と思ってました。今までの手法でも、プロジェクトは十分回ってました。WBSの見方もよくわからない内から、七面倒臭いWBSを書かされて、やってられませんでしたね。

見方が変わったのは、見積もりを書くようになってからです。最初の頃の工数の根拠は経験に基づく勘にしか過ぎず、工数の根拠がおかしいと上司に何度もリテイクされました。でも、WBSを使ったプロジェクトが終わったとき、単なる勘が少しずつリアルな数字になっていきました。上司が工数がおかしいと言っても、自信を持ってここはこれだけかかるんだ！！！いっぺん自分で作って見やがれ！！！と主張できました。最終的に、全体的にも、それほど実工数との齟齬はでなくなったと思っています。

#####粒度が小さすぎても大きすぎても駄目

余りにも粒度が小さいと進捗を書くだけが仕事になってしまいます。かといって、おおざっぱすぎるといつの間にか大遅延が起きて気付かなかったりもします。ここら辺は…うーん、私から有効なアドバイスは無いです。経験と勘とセンスで頑張ってください。

書くだけで大変だったというのであれば、粒度が細かすぎたのだと思います。自分で書いたものでは無いなら、書いた人に「細かすぎて入力するだけで大変だった」と伝えるべきです。たとえそれが、誰であってもです。私は最初にWBSを使い終わった後に、ズケズケとプロマネに愚痴のような感想(やりずらい、実態と合ってない、入れるだけで大変、工数の無駄)を述べました。ちゃんと次からは、それらの意見を取り入れて少しずつ良くなっていきましたよ。(まぁ、その人が優秀なプロマネだったというのもありますが)

#####一人一人にWBSを書かせるのは無駄

入力はそれぞれ個人がしていたのでしょうか？それはちょっと負担になって大変だったと思います。それなら、誰も書かなくなったことも納得がいきます。そこはもう少し工夫ができると思います。次の項目で述べます。

#####WBSがあるから打ち合わせをしない、ではなく、WBSを使って打ち合わせをする

口頭の打ち合わせは結構重要です。WBSやスケジュールには現れにくい問題点は打ち合わせでこそ発覚します。では、そのときに何を以て進捗を把握していたのでしょうか？そう、WBSがあればWBSを使えばいいのです。みんなでWBSを見ながら、どこまで終わったのかを聞けば楽です。

さて、打ち合わせの結果はどうやって残すのでしょうか？箇条書き？まさか、そんな二度と見ないようなまとめとも言えないメモを残してどうするのですか？そう、そこで、WBSに入力していけばいいのです。打ち合わせの時は入力しなくても、一時的に紙に書いといて、リーダーなりプロマネなりが後から入力すればいいのです。下々からしたら、一度報告した物をまた入力するのは無駄です。そんな面倒なことは上がやるべきです。WBSをみてニマニマしたり青ざめたりするのは上の仕事なのですから、上に全部投げちゃえばいいのです。少なくとも一人一人を把握しているリーダーレベルに書かせて、上へと報告する形にすれば、一番下も作業に没頭できるし、上もまとめと把握がしやすくなると思います。

#####最後まで使わなくてもいいじゃないか

プロジェクトが佳境に入るとタスクリストや課題管理の方が何が残っているかが把握できていいでしょう。私も最後の方はいつもぐだぐだでした…。でも、それでもいいと思います。そして、そんな最後だからこそ、WBSの役割が残っています。

最後の残タスクをどうやって出すのでしょうか？本当に漏れが無いのでしょうか？WBSの最後の進捗管理の仕事は残タスクの抽出です。WBSでまだ終わってない項目を抜き出せば、はい、残タスクのできあがりです。そこに、今まで発生している課題管理とあわせて、最後の直線を進めばゴールはもう目の前です。

プロジェクトが終わった後、記憶がまだある内に、最後の部分のWBSを適当に書けばいいのです。最後まで使う必要はありませんが、最後に完成される価値はあります。つじつまさえ合っていれば、文句は無いはずです。

進捗管理で重要なのは最後ではありません。最後は何だかんだと結構なんとかなるものです。むしろ、途中の段階で、きな臭くなっていないかを察知することが重要です。それだけで、最終的な利益率が大きく異なります。消火は早ければ早いほど有効です。小火で済むのか、全焼になるのかは、途中の進捗管理が重要な役割を持っています。最初から最後まで進捗が順調であったのであれば、使う意味があったかどうかという感想は結果論に過ぎません。

#####実態と合ってなかった

これが一番どうしようも無いパターンです。むしろ、それが発覚した時点で、WBSを実態に合わせて作り直すべきです。実態に合わないまま突き進むのが一番の無駄です。さすがにコレはなかったと思っています。(あったら、最初から破綻してますし…)

#####ツールが使いにくかった

これはなんとも言えません。もっと使いやすい物を探すしかないと思います。私が使ってたツールも少しずつ改良を重ねて良くなっていきましたし、他にもっと良いものが無いか探したりしました。ツールが使いにくいならむしろツールを作ってやる！ぐらいの気合いで頑張ろうとした事もありました…。使いにくいなら、使いにくいで上に意見を述べるできです。ツールの所為で作業効率が落ちるのであれば、誰も幸福にはなりません。

---

以上、元インフラ系SEの戯れ言です。開発畑ではないので、少し異なるかも知れません。WBSも銀の弾丸ではありませんから、良い点も悪い点もあります。たぶん、今回は悪い点だけが見えたのかと思います。私がやっていたところでも最初WBSを取り入れたときは無駄に大変で悪いことだらけに見えました。ただ、少しずつ使い方ややり方を工夫していって、改善していったと思います。現場の今までのやり方や実態もあるかと思いますので、質問者さんは、なぜ、今回は駄目だったのか、では、次はどうしたらもっと生かせるようになるかを考えてみてはいかがでしょうか？

色々考えた結論として、今のチームではWBSは使えないというのもあると思います。ただ、会社の方針として、WBSを使えとなったとき、工夫して使える物にできないかを考えるべきです。もし、全く使い物にならないと結論づけられるのであれば、その理由をまとめてレポートとして報告すべきでしょう。現場の建設的意見を聞かないような会社は伸びることはありませんので、きっと聞いてくれるはずです。

Answer 2

WBSはプロジェクトの進捗状況を可視化するためにあるものです。
とすれば、他の手段でプロジェクトの状況をチームメンバー全員が把握できていれば、WBSは不要なわけです。

今回、チームの規模が10人×3ヶ月ということでしたが、この程度の規模なら日次の進捗報告及び口頭でのコミュニケーションで全員がプロジェクトの状況を把握することはそれほど難しいことではありません。

入力コストより口頭コミュニケーションのほうがコストが小さいですから、結果としてWBSが形骸化してしまったのでは。

Comments

[startnote]

あ。やっはりそうですね。
すばらしい。そうすっぱりおっしゃっていただけて、もやもやしていた気持ちがすっきりしました。

とはいえ、あれはなんだったんだろうな、無駄なことをしていたな～、という気持ちがすこししこりとなっています。
というのは、WBSの入力に、毎日1時間くらいは時間を費やしていました。ディスプレイのサイズが小さくて見通しが悪く、表のサイズは巨大すぎ(A3でプリントして米粒くらいの文字で読めない)、作業性がおそろしく悪かったからです。
1時間/日×20日×3カ月=60時間/1人なので、まあざっくり600時間くらいは無駄に使っている感じですね。
プロジェクトって、コード書いているよりも、遊んでいる時間のほうが長いな～、というのが印象なのですけれど。
ほかに方法は、ないんですよね?

[yohira0616]

プロジェクト進捗管理の手法としてはWBS以外にもいろいろなものがありますね。
今流行りのアジャイル開発だと「かんばん」とか(参考：http://lean-trenches.com/one-day-in-kanban-land/)
いろいろ手段はありますが管理手法どうこうが問題の本質ではなく、「どのようにこのプロジェクトを進めたら、品質の高いプロダクトを納期通りに納品できるか」が本質だと思います。（しかし、決められた手法を遂行することにこだわるプロマネが多いのも現実です。。。）

私ならWikiツールだけ入れて、口頭ベースの進捗管理と開発のドキュメント化は開発者に任せます。当事者のほうが「ここは忘れやすいから文章化しておこう」という勘が効くと思うので。

Answer 3

数十～数百人規模のプロジェクトであれば、この手の物は必要です。
口頭やメモで情報共有が出来る規模のプロジェクトであれば、特に要らないかと思います。

入力が手間であるだけでなくて、操作性が悪く

これはWBSの問題点では無く、ツールの問題点ですね。

Comments

[startnote]

なるほど。たしかに、数十人～数百人の規模では、ツールが必要だということはたしかだと思います。前述の通り、わたしの参加していたのは10人前後なので、なくても可能な規模でした。というか最終的にはなしで運用していたので、ある意味を見いだせなかったのですけれども。
ツールの問題点ということですね。おっしゃるとおりだと思います。WBSを楽にするツールってあるんですか?

Answer 4

マネージャーになればわかると思いますよ。無いと管理できません。

Comments

[startnote]

え～と、マネージャー経験はあります。複数回あります。
プログラムではないですが、かなりベテランです。
たしかにツールは使いましたが、それはWBSではなく、WBSでないとできないなどということはないと思います。
WBSのどこが有効なのか、教えてほしいです。

[退会済みユーザー]

請負契約において、契約の主体は成果物です。
当然プロジェクトは成果物からの逆算で計画され、細分化されます。
そこにリソースを分配することがプロジェクトマネージャの役割です。
これを表現するフォーマットがWBSになります。
WBSを追わないということは、成果物の進捗を追わない事と等価なので、プロジェクトマネージャとしては仕事放棄になります。
ということで、有効、無効というより、必須ですね。
一般的な契約だと、成果物としてもWBSが入ってくるんじゃないかなぁ。

[startnote]

なるほどね。そのわたしの参加していたプロジェクトでは、途中で使わなくなってしまったので、必須ではなかったし、成果物にも入っていなかったわけです。
WBSを追わなくても、プロジェクトは完了したのです。プロジェクトマネージャが仕事を放棄したとは思わないです。仕事が上手だとも思いませんでしたが。
WBSを使っている(ろくなツールもない状態でプロジェクトメンバーに入力を強制する)時点で、プロジェクトマネージャーとしては、まあたいしたことがない、とわたしは評価していました。
わたしにはぜんぜんWBS信仰がないので、te2jiさんの考えとすごく隔たりを感じています。
どこにそんなにWBSの魅力があるんでしょう?
素朴な疑問です。
もしわたしがプロジェクトリーダーだったら、WBSは使わないし、WBSを成果納品物にはしないです。

[退会済みユーザー]

WBSをツールの名称と勘違いしているのでは？

再記となりますが、プロジェクトは請負契約上の成果物に対して逆算から計画されます。
マネージャの仕事は、その逆算からタスクを割り出し、そこにリソースを割り当て、進捗を管理することです。
入力を誰が行うか？ツールになにを使用するかは本質ではありません。
タスクの割り出しを行い、リソースを割り当て、進捗を管理していれば、それを表現するものが必要となります。それがWBSです。

プロジェクトマネージャーの役割は、成果物の完成とそのためのプロジェクトの計画に責任を持つことです。
成果物の完成に対しての計画を立てず、進捗を管理しないプロジェクトマネージャーはプロジェクトマネージャーではありません。
また、プロジェクトマネージャーであれば、立てた計画を全て頭のなかで管理してドキュメントにしない、とか、ドキュメントで報告しないということもありません。

そのため、プロジェクトマネージャーにWBSは必須となります。

逆にお聞きしたいのですが、WBSを使用しない場合、どのように計画を担保する報告を行ったのでしょうか？

[startnote]

なるほど。WBSはツールではなくて、進捗の手法だというわけですね。
ツールを使うとしても、入力をだれがするかは問題ではないと。
それなら、
・WBSといって共有するExcelの表を(途中まで)使っていた
・全体のタスクの入力はリーダーが行った(が乖離が大きかった)。
・進捗はプロジェクトメンバーが入力した。
・プロジェクトの佳境で、だれも使わなくなって、口頭ベースの報告に変わった。
という場合、成果物の計画は立て、進捗の管理もありました。
途中まで存在したWBSの表はなにだったのでしょう? 張り子の虎?

ご質問にお答えします。WBSなどというものは使ったことがありません。プロジェクトリーダーのわたしはチェックリストと達成リストを作って計画をマネージメントしました。それをWBSと呼びたい人がいるのならWBSと読んでもよいですが、それはExcelの表のようなものとはかけ離れておりますし、共通点もほとんどありません。だいたいわたしがWBSを知ったのはこの半年程です。プロジェクトマネジメントをしていたのは、25年前からです。

すごく議論がかみ合っていないですね。
WBSの魅力や有効性についてお話いただきたいです。
あるいは、そのプロジェクトでWBSとして使っていたExcelの共有表が放擲されたことに関して、どう理解したらよいのか、ご示唆いただけたら幸いです。
念のためくり返しますが、プロジェクトは成功裏に終了しました。じっさいに運用に供しています。ですからなおさら、途中まで存在したWBSと呼んでいたExcelの表の無意味さが、よくわからないのです。
途中までは進捗を表で管理し、最後は口頭で管理する。それも進捗管理の方法ではありますが、それなら最初から口頭では駄目なのだろうか、というのが素朴な疑問ですね。

[退会済みユーザー]

WBSの魅力も何も、プロジェクトマネージャーの仕事には必須だと何度も言っているのですが。。。

今更ですが、今回WBSと呼んでいるものを確認します。
・元々のWBSの定義する「作業分解/分割を表現したもの」にスケジュール/進捗を足したもの
という認識で、回答しています。
（プロジェクト中、一般的にWBSと呼ばれるものがこれだと思っています）

こちらも何度も言っていますが、成果物の完成のための、タスクの整理とリソースの割当、進捗管理を表現するものがWBSです。プロジェクトマネージャーが、それを行わなくなったら職務放棄です。プロジェクトの佳境でメンバーが進捗報告をしなくなったら、ヒアリングを行い、別フォーマットで管理を行っていたはずです。フォーマットと入力者が変わっただけで、WBS自体はプロジェクトマネージャーが作成していたと思いますよ。

議論がかみ合わないのは、プロジェクトマネージャーの定義がずれているからだと思います。プロジェクトマネージャとは、成果物の完成のための、タスクの整理とリソースの割当、進捗管理をする役割だと、何度も言っていますが、ここがズレているのでしょう。

本来、プロジェクトマネージャーはメンバーと兼任してはいけません。それは炎上した際にプロジェクトマネージメントができなくなるからです。しかし、小さなプロジェクトでは兼任してしまっているケースも見受けます。その場合、プロジェクトの佳境で、マネージャーがメンバーとして動いてしまい、プロジェクトマネジメントを行わなくなることがあります（マネージャーとしての職務放棄です）。そうなるとWBSは機能しなくなり、本来のマネジメントの形から外れます。結果として、成果物を納めることが出来たとしてもプロジェクトマネージャーの責務としては放棄された形です。

マネージャーが機能している限り、成果物の完成のための、タスクの整理とリソースの割当、進捗管理を行うし、それをドキュメント化したWBSも存在します。
逆に言えば、WBSが書けなくなった時点で、マネージャーは機能しておらず、職務放棄です。

Answer 5

そもそもの疑問で、WBSの作業工数は誰が見積もりましたか。

Comments

[startnote]

プロジェクトリーダーです。maybe.

[yona]

多分、そこが誤りですね。
まず、プロジェクトリーダーはWBSでタスクを細分化、タスクの完了条件、成果物、作業担当者の割り当てまでを行います。
その後、作業担当者が工数を見積もりし、WBSの破綻箇所が無いかをチェックします。
作業担当者の工数見積もりから、プロジェクトマネージャーは全体工数を見積もったり、破綻している箇所を修正したり、リソースの増減を行います。

Answer 6

WBSは知らなかったので調べてみました。
で、率直に言って「夢見がちな管理者がトップダウンで
導入して失敗するやつだ」って印象を持ちました。

なにごとに限らず「前提条件」てやつはありますよね。
WBSを有効利用するためにはTPOに合わせた内容策定や
プロジェクト参加者の意識合わせが必要っぽい。

例えば、○○言語を使えばハッピー！
みたいな話はウソではないかもしれないけど、
そんな簡単な話でもないはずです。

冷静に考えれば分かりそうなことでも、
流行りに乗せられて勢いやっちゃった
みたいなことありますよね。
そこからどうつなげていけるかは、
たぶん引っぱっていける人の有無が大きいんじゃないかなあ、と。

Comments

[startnote]

うんうん。わたしもそう思いました。夢だよな～、っていう。
事実、いちばん必要であろう佳境で放擲するのでは、使えないってことではないかと、強く感じたのです。

Answer 7

ちょっと別の視点からの回答となりますが。

WBSは比較的伝統的なプロジェクトマネジメント手法だとは思いますが、その後に新たな手法が提起され続けていることからも、WBSはベストで常に使える、といったようなものではないのは明らかですよね。
WBSがベストな場合があることを否定するものではありませんが、現在の多くの開発現場では使い勝手の悪いものとなっているのも確かです。

しょせん手法なので成果物の性質によって向き不向きがあるので、状況に応じて適切な手段をとればいいのは当然ですね。

ウォーターフォールのような、最終成果物に対して手戻りや修正がない前提で進むためならWBSで充分でしょう。
別の方が「建築現場で」というお話をされていますが、まさに建築のように設計から手戻りのない形式で進めていく開発工程であれば、進捗も遅れも明らかになりますので良い手法だと思います。

しかし、今どきのアジャイルな手法の中でやるには硬直化しすぎて結局管理できなくなる手法です。
そういった環境であれば、カンバン方式や課題管理とガントチャートといった管理手法でなければ成果物にたどり着きにくいでしょう。

現実的には、現場レベルの本来の進捗管理は課題管理で行い、そのもう少し粒度の荒いレベルでのスケジュールの認識合わせのためにWBS的なスケジュール管理をして見せることが多いのではないでしょうか。

いずれにせよ、プロジェクトマネジメントの「標準的な手法の1つ」ではありますが、それしかない、とかそれじゃないとできない、ではなく、自分の頭で状況に適切な手法を選ぶ類のものと思います。

Answer 8

WBSの利点は、クリティカルパスがわかる点です。

クリティカルパスとは、完成から前提条件を手繰っていくと一番時間がかかると考えられるパスです。
つまり、プロジェクトの完成は最短でもこれだけかかるという状態がわかります。

例えばカレーライスを作る際、ご飯を炊くのに１時間かかり、レトルトカレーがお湯をわかすを入れても１０分で済むとしたら、クリティカルパスはご飯を炊く一連の作業に有ります。デミグラスソースを入れるのであれば、１２時間の煮込みとして、準備も含め１５時間はかかりクリティカルパスはこちらにあり、この作業を優先すべきということになります。

これによって、クリティカルパスに余裕がない場合は、能力の高いメンバーをクリティカルパス上の作業に当たらせるなどして納期の遵守させます。更にはクリティカルパスを精査して、隠れた問題点作業の洗い出し漏れが無いか検討します。さらに、クリティカルパス上の作業を分割し平行作業可能なものが無いか検討します。

逆にクリティカルパスに余裕があるにもかかわらずスケジュールが遅れている場合は、人員の追加で遅れは取り戻せると考えられます。ただしこの場合、WBSにない作業が発生していないか確認する必要が有ります。

というように、WBSはある程度直列した大規模な作業に向いた管理方法です。もし、少人数だったり並行作業が可能なものが多い場合は、タスクリストを作ってバーンダウンチャートを書いたほうが管理がし易いです。

追記ーWBSは建築関係では、非常に有効らしく実際使用されているのを見たことが有ります。