WBSを作るときに知っておきたい7つのこと

WBSを作る目的は
プロジェクトでdeliverableを作る作業をするとき、システムエンジニアなら無意識にWork Breakdown Structure (WBS)を作ることだろう。もう、すっかりおなじみだ。プロジェクトの開発手法がウォーターフォールでもスクラムでも同じ。それを記録するツールは、Microsoft Project、excel、若しくは、tracなどのチケット管理システムかもしれない。

どのような開発手法であっても、どのようなツールを使っても、WBSを作成してdeliverableを作るということには変わりはない。WBSを作る目的は、deliverableを作るための作業を明らかにするためだからだ。

WBSの目的：deliverableを作成するための作業

deliverableとは届けるもので、契約形態で言い換えれば、成果物、提出物、又は、アウトプットの何れかになる。面倒なのでひっくるめてdeliverableである。WBSは、そのdeliverableを作るための作業を分解したものだから、たとえば、設計書であれば設計書を執筆するための作業に分解する。

WBSはいくつかの作業に分解する

一人プロジェクトであっても、仕事のスポンサーが必ずいるわけで、deliverableを作るエンジニアの他、deliverableの仕様を提示したり、仕様を確認したり、出来上がったdeliverableを受け入れ検査したりするスポンサーと役割分担することになる。それは、作業には必ず作業の“主担当”が割り当てられると言える。

WBSには主担当が割り当てられる。

分解されたWBSは、deliverableを構成する作業であるから、その作業が終わったら、何等かアウトプットされないとdeliverableが組みあがらない。言い換えれば、分解されたWBSを終えたとき、何某か出来高があるということになる。そのアウトプットされたものの状態は、一つひとつのWBS毎に決めておかないといけない。形、色、大きさ、重さ、匂い、質感と誰が見ても同じイメージを持てるように、作業が完了したときの状態を“作業を始める前に”関係者全員で知っておく必要がある。

WBSは、作業が完了した状態を定義しておく。

なぜ、プロジェクト関係者全員でしておく必要があるのか。それは、作業を分解しているため、一つのdeliverableを作成するための作業が一貫して“一人”でするとは限らないからだ。

一つのdeliverableを複数のエンジニアで分担するときに次工程のエンジニアは、前工程から受け取るときの状態を○○という状態で受け取りたいと期待する。前工程のエンジニアも△△の状態で渡したいと思う。そこに作業工程間のギャップが生じる可能性があり、実際にギャップが発生したとき、プロジェクトとして困ったことになる。そんなことは誰でも知っていることだ。○○や△△と言う暗黙は作らない、ということであり、なら最初から明示しておきなさい、ということである。

WBSの作業が完了した状態を明示する。

一つひとつのWBSは、deliverableを作るために作業を分解したものであるから、ひとつのdeliverableを作るためのWBSは最終的に一つに収斂していく。いくつも分岐したままで終わりはしない。ひとつのdeliverableを作るために分解したWBSは、一人でやるにしても分担するにしても、deliverableになるまでは連続することになるから、それはWBSに前後関係があるということになる。だから、WBSは作業の塊を意識して順番に並べておく必要がある。

WBSは作業の前後関係がある。

WBSを作るときに悩むこと
WBSをつくるときに悩むことは、一つのWBSをどのくらいにしたらよいか、と言うことをよく聞く。それはチケットでも同じように相談をよく聞く。人には把握しやすい感覚があり、それを大切にした方が良い。

ひとつのWBSが1か月だったらどうか。一つの作業が1時間ならどうか。大きすぎるWBSは、日々何をやっているのか、自分が担当している作業の位置がわからなくなってしまう。特に、プロジェクト全体の進行度合いと自分の担当している作業の進捗が把握できないようなエンジニアには絶対向かない。逆に、時間単位で区切るWBSでは、そのWBSを起こし、更新するための作業ばかりに時間を取られてしまい煩雑になってしまう。なので、WBSは1週間程度で、その中のプロセスをプロジェクト関係者で共有する。

WBSは、1週間を目安に。ただし、1週間の中のプロセスと完了の状態は明示的に。