一番やさしいWBS

on


というのはニーズがあるのかしら。プロジェクトでそこそこの経験を積まれているだろうシステムエンジニアの方でも「？？？」となるWBSを作ってくるのですよ。ふむむ。


WBSってなに？
WBS　(Work Breakdown Structure)　とは、作業を細かく分解したもの。

【例】カップラーメンを食べる　をWBSで細かく分解すると、
1)カップラーメンを買いにいく
2)お湯を沸かす
3)食べる
4)片付ける


「カップラーメンを食べる」だけで「1つ」の作業ではなく、「4つ」の作業に細かく分解できます。さらに、細かく作業を分解することもできます。


作業の分解はどこまで細かくすればいいですか？
どこまで、は、どのレベルまで作業を分解したいのか、要求する・される管理レベルに依存します。管理レベルに依存するとは、WBSに分解した作業のステータスをどの作業まで知りたいのか、と言い換えることができます。

【例1】カップラーメンを食べたか、食べていないか「だけ」知りたい
1)カップラーメンを食べる　[カップラーメンを食べていない/カップラーメンを食べた]

【例2】カップラーメンを食べる「経過」も知りたい
1)カップラーメンを買いにいく　[カップラーメンを買っていない/カップラーメンを買った]
2)お湯を沸かす　　　　　　　　[お湯を沸かしていない/お湯を沸かした]
3)食べる　　　　　　　　　　　[カップラーメンを食べていない/カップラーメンを食べた]
4)片付ける　　　　　　　　　　[カップラーメンの容器を片付けていない/カップラーメンの容器を片付けた]


ところでWBSって何に対する作業なの？
おっと、そこから、ですね。賜りました。
作業は、作りたい・作らないといけない「モノ」または「サービス」を作るために行う活動です。
気付きましたか。作業の前に「モノ」か「サービス」があるのです。

【例】
1)プロジェクト計画書　これがないとプロジェクトは始まりません
2)個別仕様検討資料　　システム要件の検討、システム方式の検討、実現仕様の検討などなど
3)設計書　　　　　　　※みんな大好き詳細設計書！！
4)プログラム　　　　　プログラムを「書く」ことまでがデザイン(設計)ですよね
5)テスト結果報告書　　エビデンスは必要ですが扱いに困りますよねぇ


これらの「モノ」や「サービス」を作成します。


WBSの作業量は作業前に見積もらないといけないんですか？
WBSは、作業を定義して、作業の計画を立てるためにWBSの最小単位ごとに「作業量」を見積もってください。
WBSである作業項目と作業量を掛け合わせて、全部を足したものが全体の作業ボリュームになります。
全体の作業ボリュームに見合う、リソースを準備する必要がありますので作業前にお見積もりください。
なお、いい加減なお見積もりをされるとリソースが足らなくなったり、余りがたくさん出てしまうことがあります。

【例】
1)情報収集・仕様検討・執筆　　ここがクリエイティブな時間ですね
2)内部レビュー・指摘反映　　　ここの作業量をちゃんと見ておかないとやる時間が取れなくなりますよ
3)外部レビュー・指摘反映　　　外部レビューアのレビュー方針に取られる作業量が変わりますね
4)リポジトリ登録　　　　　　　この作業で完了ですね


開始日や終了日はいつ設定するんですか？
時間軸を入れるとWBSは「工程」「スケジュール」にクラスチェンジします。
なんとなく、日付を入れたものもWBSって一括りにする方も居られますが、一応、別物です。
あまり厳密に分け隔てする意味はないので、そのくらいで結構です。


おしまい。