WBS「わたしのこと嫌いなの?」エンジニア「…」

WBSは嫌い?好き?

 まー、これを書き始める前にツイートしたので結果は明日ですね。なぜアンケートを撮ってみようと思ったかというと、WBSが嫌いという書き込みを見たからなんですが。

WBSを勘違いしていないかな

もちろん、WBSのフルスペルについてはご存知だと思いますが若手のエンジニアでWBSの略称だけを日常使いしている方もいるかもしれないので念の為に書いておきましね。 WBSって Work Breakdown Structure の頭文字を取った略称ですよ。

ではWBSはなんのために使うかというと成果物を完成させるための作業を分解するものです。

言い換えれば、成果物を作るための作業の一覧です。

さて、このWBSに必要な要素と含まれてない要素はなんでしょうか。1分差し上げますので考えて見ましょう。



WBSに必要な要素はなんでしょうか。

もちろん、成果物を作るために分解した作業です。2つ目は、分解した作業の順序です。Aの作業が終わってAのアウトプットがあって初めてBの作業を始められる、というようなケースです。依存関係と呼んだりします。3つ目は分解した作業毎の工数です。

では、WBSに必要のない要素はなんでしょうか。

答えは日付です。WBSには日付の要素はありません。一般的にWBSというとガントチャートのようなイメージを持っていることが多いというかほぼ100%ではないかと思いますがWBSに日付の要素を含めたものはスケジュールです。日本語でいうと工程計画です。

WBSが嫌いな理由は

 WBSが嫌いな理由の一つは、まずスケジュールとWBSを取り違えているという冤罪が由来というものではないかと思います。

WBSが工程計画であるとしたときの本質的に嫌いなのは、工程計画の作り方ではないかと思いますがどうでしょうか。

どうでしょうかと言われてもピンとこないのは理想の形でWBSから工程計画に展開した後にスケジュールのテーラリングができているのか、スケジュールの締め切りに押し込むことが当たり前で鈍感になっているからかもしれません。

さて、どちらですか。

WBS嫌いにしているはエンジニア自身

WBSはあるべき姿で作業を分解して作業の依存関係をつなぎ、それぞれの作業で(見積もり上の)工数を積みます。

そこにプロジェクトの事情、外部からの制約条件、分かり易く言えば、納期に合わせるように要請が下りてきます。ここからWBS作成時には理想形で仕立てた作業体系を弄り回すテーラリングの(高度な)調整力が必要とされるのですが、WBSが嫌いなエンジニアは、十分な検討をせずにただ納期から圧縮された期間の中に詰め込むことをするから結果的にWBSと呼んでいる工程計画を嫌いになるのです。

見積もり上の工数が実際の実績工数と一致すると仮定をする場合、作業に必要な工数の合計は期間を圧縮しても同じにならなければウソです。いじり回している最中に収まらない作業工数をエンジニアが自らネグっているのです。

もちろん、エンジニアが工夫をして全パス試験をするところをテンプレート展開するモジュールについては代表をフルで通すことで同じロジックを通すテストは論理的に代表で試験済みと見做すとするなどの工夫をして作業をロジカルに削減するやり方を取るなら作業工数の面積は減ることもあります。

大原則として成果物を完成させるための作業を別物か生産手段を入れ替えない限り、作業工数の面積は変わりません。

 

現実的には感覚でこのくらいでできるだろうという期待値をでっち上げて納期という締め切りに合わせてやっているから嫌いになるんですよ。その結果が、できるだろうが出来なくて辛い思いをしているという…。

 

Keynoteで魅せる「伝わる」プレゼンテーションテクニック

Keynoteで魅せる「伝わる」プレゼンテーションテクニック