WBSをせっかく作ったのに納期に間に合わない

on


WBS( Work Breakdown Structure)のレシピ
ウォーターフォールのシステム開発手法を取れば、工程に対応するdeliverableを定義して、そのdeliverableを構成する部品を作るために対応する作業に分解していきます。WBSは、作業で分解するものではなく、deliverableを管理できる部品単位までに分解し、その分解した要素を作るための、リソース、期間を割り当てるのです。

最小単位のWBS/deliverableを構成する部品


確か、2000年版のPMBOKだったか、deliverableを分解した作業はワークパッケージと称していた記憶もあるけど、一般的にWBSは全体でも一行のWBSでもWBSと言うのは不思議というか、何かWBSに対する理解が誤ったのかもしれないと変な邪推をしてしまうのですが。


最小単位のWBS、ワークパッケージは、一つひとつにたしてそれを作成するための工数を見積もります。単純にその一つのWBSを完了させるために「どのくらいの時間とそれを実現するための人的リソースを必要とするのか。」という情報が必要になります。

最小単位のWBS/deliverableを構成する部品/必要な時間/実現するための人的リソース


最小単位のWBSは、もともと一つのdeliverableだったわけですから最小単位ならいくつか寄せ集めて一つのdeliverableになるわけです。その一つひとつのdeliverableは全部後先なくバラバラに作っても作れるか、若しくは、あるものは作業する順番のある「依存関係」があるかもしれないので、そうした前後関係の有無は明らかにしておかなければいけません。

最小単位のWBS/deliverableを構成する部品/必要な時間/実現するための人的リソース/前後関係


deliverableはあるタイミングで顧客へ納めるとか、他のシステムへ機能を提供する、だとか、作ったものを必要とする需要に対してリリースしなければなりません。そのリリースする日前に作業を完了しておかなければ引き渡しができないですから、引き渡す日をマイルストーンとして設定し、その日に「引き渡しが完了した」という状態を目指した作業計画を作成することになります。


WBSとしては、先の前後関係までで十分なのですが、人は作業をするときに時間軸がないと作業のイメージを組み立てられないので、マイルストーンを軸として日付を入れていきます。通常、日付は一つの項目としてだけで持っていると計画値を実績値で上書きしてしまうことになって、計画と実績のズレを把握することが出来なくなってしまうので、予定と実績の値を分けて保持するのです。

最小単位のWBS/deliverableを構成する部品/必要な時間/実現するための人的リソース/前後関係/予定開始日/予定完了日/実績開始日/実績完了日


ここまでできて、初めてプロジェクトの日付のWBS、所謂、マスタープランが出来たわけです。


で、このままやったら予定どおりにできるの？
そのマスタープランに記載されている作業全てのリソース、それぞれの最小単位のWBSのインプットになる情報が自ら用意できるのであれば、予定どおりに出来るハズです。なぜ、ハズとつけるかと言うと、一つひとつのWBSに対して起きうる、でも起きたら手間のかかる面倒なこと＝リスクをどう認識して処理するつもりなのか、そうした備えを受け止めるだけの準備をしているなら、大体は予定どおりにできるでしょう。それでも「大体」とつけざるを得ないのは、未来を占うことは占い師じゃないんだから言い切れない、だけの話です。


じゃあ、計画どおり出来なくなる可能性はどこにあるのでしょうか。

予定どおり出来ない


一つはWBSに起因するものが考えられます。最小単位のWBSのdeliverableの仕様が明確でない。最小単位のWBSの仕様は明確だけど実現するための人的リソースが計画時点で過小である。最小単位のWBSを実行する人的リソースの要求レベルと実現レベルにギャップがある。最小単位のWBSを実現するための人的リソースが割り当てられない。最小単位のWBSを実装する人的リソースの性能が低い。最小単位のWBSを実装する人的リソースの作業品質が要求に満たない。


ちょっと上げただけでこれだけある……。

予定どおり出来ない/最小単位のWBSのdeliverableの仕様が明確でない。
　　　　　　　　　/最小単位のWBSの仕様は明確だけど実現するための人的リソースが計画時点で過小である。
　　　　　　　　　/最小単位のWBSを実行する人的リソースの要求レベルと実現レベルにギャップがある。
　　　　　　　　　/最小単位のWBSを実現するための人的リソースが割り当てられない。
　　　　　　　　　/最小単位のWBSを実装する人的リソースの性能が低い。
　　　　　　　　　/最小単位のWBSを実装する人的リソースの作業品質が要求に満たない。


これを見るとわかると思うのですが、WBSを作ったからと言って予定どおりに出来上がるなんてありえない、ということです。WBSを作るまでに手間もかかるけれど、WBSを作ったら作ったで一つひとつのWBSに問題がないかを注視しないといけないわけです。それも、見ているだけじゃなくて、おかしいと気づかないといけないし、気づいたら対策をしないといけない。


でも、こうやってレシピを手本にWBSを作るから最小単位のWBSまで目が行き届くし、イメージが作れるわけです。だから、リスクも識別できるし、対策も打てるわけで。WBSを作らなければどうなるかは言わずもがななわけです。


WBSを納期に間に合わせるようにするための原則は、「WBSを作る。時間軸を入れる。リスクの対策をする。WNSを監視する。予兆を知る。WBSを予定どおりに進められるように調整する。」です。


一言で言えば、「間に合うようにWNSを更新し続ける。」なのです。