もう一度、WBS (Work Breakdown Structure)


WBSの作り方が腹落ちしていないエンジニアのみなさんと一緒に、もう一度WBSの作り方をおさらいしましょう。


はじめに
WBSとは、成果物(又は提出物とも言う。ここでは成果物に統一します)を作るための作業のことです。PMBOKではワークパッケージなどと呼びますがココでは作業に統一します。


WBSを作るために必要な情報
WBSを作るためには、その作業で作る成果物が何かを決める(又は知る)必要があります。何を作るかわからないのでは作業内容を決められないのでWBSにはなりません。


WBSの作業を決めるために必要な情報は、作業をするための参照する情報と作業で作成する成果物です。図式にすると、


参照する情報 → 作業(処理) → 成果物


になります。参照する情報と成果物は1つの場合も、複数の場合もあります。


作業を分解する
このWBSを分解、展開する最小の多淫をどうしたら良いかが、WBSを作り慣れていないエンジニアの手を止めてしまう一つの要因になっています。次に様に考える軸を持ちましょう。


作業は大項目、中項目、小項目(以下小項目の繰り返し)…と言うように作業の単位で分けていきます。一般的に、

大項目 工程、要件定義、基本設計、詳細設計…などウォーターフォールならではの工程、又は、アジャイルのスプリントの単位。
中項目 工程を構成する項目。設計局面なら目次の章。開発・構築局面ならサブシステム。
小項目 設計局面なら節、開発・構築局面なら機能単位


のように分解していると思います。でもこれでは担当するエンジニアが日常的に使うWBSとしては荒すぎるし、WBSで作業の予実を把握するという趣旨からも管理メッシュがあっていません。なので、もう1つか2つレベルを落として展開する必要があります。


作業分解の目安
WBSで作業の予実を管理する場合、人の生活サイクルと合わせるのが体感的に馴染みやすいです。ですので、


最終的なWBSの展開は最長でも、5営業日以内。


これより長いWBSを引いていたら分けてください。


では「どこまで最小に分解すればいいのか」と疑問を持つと思います。答えは、WBSを管理する人が管理しきれるのであれば、管理できるところまで作業内容、プロセスで分けてください。設計局面であれば、



事前検討 → 執筆 → 内部レビュー(指摘反映) → 外部レビュー(指摘反映/確認) → コミット


だいたいこんな作業プロセスになると思います。問題は、カッコ書きの中までWBSに起こすかどうか、です。プロジェクトの規模によっては、上記の箱を1つのWBSまでしか分解しないかもしれません。


ポイントは、管理レベルをどうするか、です。WBSでプロセスの進度を計りたいときは、WBSの数がとても多くなり人の把握する量を超えるかもしれないですが、展開が必要です。プロジェクトが小規模とかそこまではいいのであれば、


事前検討 → 執筆 → 内部レビュー(指摘反映/) → 外部レビュー(指摘反映/確認/コミット) → コミット


のくらいで良いと思います。ただし、プロジェクトメンバには、カッコ書きの中を含めたプロセスで進めるのがルールであることを徹底する必要がありますし、エンジニアの方は守らなければなりません。


作業工数の見積
作業内容を定義できたので、次は工数、作業に当てられる時間を設定します。この時間は割と工程の期間から割り当てられることが多いと思います。つまり、やる人が見積もっていないということです。これを無理強いして作業期間を押し付けると納期までに出来なかったときに「自分が見積もったのではない」と言い訳する人が出てくるので、プロジェクトマネージャやリーダが作業の工期を決めた場合は合意プロセスを踏む目的もあるので、出来そうか期間を調整した方がいいかを聞くことをオススメします。


ここでのポイントは、正味で、割り込みなしでやったらどのくらいの時間が必要かで聞きましょう。その時に必要になる情報が、作業のインプットとなる参照する情報と成果物の具体的なイメージです。


作業の関係
WBSで何をするかの作業内容、作業時間が明確になりました。あとは作業に後先の順番があるかどうかの前後関係です。作業を分解してるので


事前検討 → 執筆 → 内部レビュー(指摘反映) → 外部レビュー(指摘反映/確認) → コミット


は前後関係があるのは明白なので、それより上のレベルで確認します。開発・構築局面であれば、サーバセットアップ、OS導入、設定などが作業としてあるもので、それは中項目か、1番目の小項目のレベルでなっているかもしれません。そうしたサーバの導入、設定は、その後のサーバ試験のあとにミドルウェアやアプリケーションの担当が待っているのでそうした担当が違う人が同じリソースを使用する観点で作業の関係の有無を確認するのが良いでしょう。


おわりに
これでWBSとしては終わりです。え?開始日と終了日を決めていないじゃないか、ですって?それはスケジュールと言いますよ。大項目レベルので日程の譲歩が入ったものがマスタースケジュールです。


スケジュールには、予定開始日、予定終了日、実績開始日、実績終了日、担当、予定工数、実績工数の項目を追加すると良いです。


みなさんが見慣れているのはこの状態なのです。