【読書ノート】システム開発のためのWBSの作り方を読んで
【今回の内容】
業務において自分の作業のWBSをかいてね、ということがあった。
資格の勉強、pj内にての実物、研修などで参考となるwbsはみたことがあったが、
それが本来どうあるべきなのか、というしっかり考えたことがなかった気がするので
今回、以下の書籍を読んで学習した
【印象的だったところ】
①WBSのメリット
・pj全体の作業を俯瞰できる
・作業つながりが明確になる（親・子関係がみえる）
・全体作業を明確にした上でスケジュールを立てることができる
■メモ
たしかに、
・作業を分解してことによって思っていたより一つの作業をこなすのに必要な作業があることに気づく
・そもそも認知していなかった作業があったことに気づくことがある
②工数の出し方
一つの工程の見積もりだすときは、
・トップダウンで必要作業を洗い出す
・粗い作業をwbsによって砕いていって、積み上げで予定を立てる
※作業のネットワーク図などを使って、wBSではわからない作業実行順序の制約・クリティカルパスも把握する
■メモ
作業間の関係性（Aを行わないとBできないまたは、AとBが終わらないとCができないなど）を
把握せずに作業順序を決めているときがあるので、机上で図などを書いてもいいかも。
③工数削減の方法
①既存の作業員の稼働を増やす
②作業をスコープを縮小する
③ファストトラッキング（リスク（手戻り）覚悟で作業を同時並行する）
④クラッシング（要員を追加する）
■メモ
進捗が遅れたときもこの４択くらいしかないのかなと思う。
意外とPMに打てる手は少ないように思う。
④WBSはトップダウンで洗い出していくこと
①成果物単位
システムの納品に必要なものは、
・プログラム 分解していく（◯機能、）
・サーバー
・ネットワーク
②プロセス単位
システムの納品していくには、
・基本設計 分解していく（業務機能の設計、サーバの設計）
・詳細設計 （）
⑤粒度をそろえる
WBSに記載するツリー構造の作業の粒度をそろえる
プロジェクトのwbsについては粒度が細かすぎるとみづらい
■メモ
どこまで分解していくかはプロジェクトによって、作業工程によって判断が必要そう。
⑥下位の作業が上位の作業を構成していること
■メモ
当たり前なんだけど、この基本がなっていないと作業のモレが生まれる。
要注意だと思った
⑦上流工程でも下流の工程のものはざっくり洗い出しておく
プロジェクトがすすまないとわからない。だからWBS化しないのではなく、
ざっくりしたものでいいから洗い出しておくこと。
例→モジュールも洗い出し。
あとから具体化して、受注業務のモジュールの洗い出し
