WBSを書き慣れたころのシステムエンジニアを襲うWBSにまつわる悩みどころ

新しい道具を手に入れると最初はうれしいのと関心が高いので弄り回すものですが、少し慣れ始めると悩みを持つものです。とはいって、周りを見ても誰がWBSのオーソリティだかわからないし、何より他人が作るWBSを見る機会なんて一緒のプロジェクトに入らないとなかなか見られないものですよね。
それに、その一緒のプロジェクトメンバやプロジェクトマネージャがWBSの参考になったりするほど都合よくないです。

ワタシは、新人のエンジニアがワタシのメンバに配属されたとき、1年間続けさせることがあります。それが個人用のWBSを毎週作成して、週次でワタシに報告してもらうことです。で、ポイントはワタシの他にチームメンバ「にも」宛先に入れてもらいます。

新人にはメンターを付けるのでそのメンターは必ず毎週見るのは勿論のこと、チームメンバも宛先に入っていますから関心を持っている人は「ちょっと見てみよう。」とチェックをしてくれるわけです。そうした遣り取りを見ていてWBSに不慣れなシステムエンジニアがWBSを書く際にどのあたりで悩んでいたり躓いていたりするか、いくつか例を上げますので参考にしてください。

何をWBSにしていいかわからなくなったら
WBSを設定してもらう間はどういった単位でWBSの項目(＝1行)にすればいいかなんて考えません。だって、指示されるんだもの。それをWBSの項目定義からしなさい、とデレゲートされた途端どうしていいかわからなくなる人もいます。そうした場合にどうしたらいいか、です。

WBSは、Work Breakdown Structureの略称だけあって、作業を分解した構成情報です。言い換えれば、何かを作るときの作業の段取を一つひとつに分けたものです。

ここで出てくるアイテムは、「作る何か」「段取」です。みんな、頭では分かっているのにWBSを作るときに忘れるのが「何を作るのか」という対象のモノです。これから何を作るのか、それが明確になっていないといくらWBSを書いても完成できないWBSを書くことになるのです。

なぜWBSの対象のモノが明確に、具体的になっていないと完成できないのでしょうか。それは、完成させようとしていても作っている途中で仕様を確認してみたら最初のイメージと違うものだったとか、違うイメージのモノを要求されてしまう、といったように何が出来たらそのWBSが「完了した」と証明するための比較元がないから、なのです。

なので、WBSを定義するときに新人エンジニアに必ず尋ねるのは、「そのWBSで作ろうとしているモノの色、大きさ、形、重さ、香り、質感は『具体的に』どういうものか説明して。」というものです。手順書なら、既存の手順書で同じものがあるのか、画像は貼るのか、何ページくらい書くつもりなのか、目次構成は他のどの手順書と似ているのか、というようにです。

期限にまで終わらなくなったら
WBSには予定の開始日と予定の終了日、あと、実績の開始日と終了日の項目があるものです。それは、開始日と終了日しかなければ予定の日付を実績で上書きしてしまうので、予定の(のべ)工数よりどれだけ早い、又は、遅れて終わったのかがわからなくなってしまうからです。

で、WBSがいつまでたっても終わらないときは何が原因なのでしょうか。もともとの予定開始日と終了日の期間が短い場合が考えられます。その場合、終わらないWBSの作業の段取りが十分分解できていなかった、と言うケースがあります。当初、WBSを定義したときに想定していた手順より多くの手順が実際にはあった、と言うことの裏返しですね。だから、終わるつもりでも、実際には手順が足らずに追加で手順を足すのでWBSが終わらない、と言うことになるわけです。

もう一つのケースがあって、手順は十分だったけれど、作業時間が想定よりかかってしまった、というケースです。これはホント、だれでも起こすケースですね。想定より時間が掛かっているのですから、単純に手数が多いのか、手間の難易度が高いのか、になります。これを、時間が足りないかどうかも、作業に起因する場合の他にそのWBSを実行する自分自身の経験、パフォーマンスにも作用されるのです。簡単に言えば、自分がやったことが無ければ頭で考えているより時間が掛かるとか、自分では1日で終わるつもりだったけど自分が1日で終わらすことが出来なかった、というように。自分の力を見誤ると言うわけです。

手順が足らない、作業時間が十分かどうか見極めが出来ないときは、一番最初に手を付けるWBSに余裕を持たせた日程にしておくことです。この最初のWBSをモデルケースにして実際の実績値を採るんです。で、そのWBSの実績によって継続するWBSの期間を見直す、ようにします。

一つのWBSの期間の長さはどのくらいにしたらいい？
幾らベテランのシステムエンジニアになっても予定後どおり仕事の実績を積み上げられないケースに1つのWBSの期間が長い、と言うものがあります。過去にビックリしたモノに3ヶ月とか6ヶ月とかバーンと賤をひっぱていたのを見て思わず「壮観だなぁ。」と変に感心したことがあります。直ぐに分解させましたが。

大規模プロジェクトのように高い品質を求められるプロジェクトでは、1つのWBSは管理スパン、つまり、どのくらいのインターバルで進捗を測るかを決めて、そこから最長のWBSの期間をルールとして決めるケースがあります。週次で進捗をはかる場合、WBSの最長は5日です。半日とか1日とか短い期間のWBSは作業タイミングが近いものは5日になる様に括ったりします。

今のWwbアプリのような作業スピードを求められるWBSの場合は、単位が日から時間に変わります。ただ、WBSをあまりにも分解しすぎると分解する手間と、進捗を計る手間などWBSの実績に結び付かない間接的な作業に時間を取られるきらいがあります。WBSを理想時間＝実作業時間で厳密に見積もることはベロシティを把握するために必要ですが、やり過ぎるよりは、リリースするまでの手順を共通に定義して、その手順ごとに作業時間を見積もって、WBSは手順の一塊にする方が煩雑にならなくてよいでしょう。