“成果物に分解するWBS”を習得せよ
レベル2を「成果物一覧」で分解した場合は、成果物単位でワークパッケージが表されるため、責任の単位がWBSとして分解されているケースが多くみられます。欧米企業や、オフショアを活用している会社では、契約上、責任範囲をかなり詳細に記述する必要があるため、こちらのWBSを好む傾向にあります。 さて、実際のシステム開発プロジェクトにおける事例を見てみましょう。レベル1は顧客に納品する成果物であるXXXシステム（システムの名前など）が記入されます。レベル2を見ると一般的な成果物一覧の大項目が並びます。例えば、「ハードウェア」「ソフトウェア」「開発用ドキュメント」「ユーザードキュメント」「プロジェクト管理」などです。 留意事項として、「プロジェクト管理」だけは「作業分解型」のWBSと共通の項目になります。プロジェクト管理は厳密に言えば成果物ではありませんが、プロジェクトを円滑に進めるために必須となるため
WBSを学び、見積もり・進ちょくに役立てよ！
こういった状況に、企業も手をこまねいているだけではありません。PMBOKやISO 10006などのプロジェクト管理の方法論を適用し、改善を試みているようですが、劇的に効果が上がった、といった話はなかなか聞きません。 それはなぜでしょうか。 その理由はいくつかありますが、その理由の1つとして、いずれの方法論でも「プロジェクトの分解・構造化（WBSの作成）」という極めて難易度の高い作業がプロジェクトの初期段階で存在しており、その精度によって、プロジェクト管理の結果が大きく左右されてしまうことが挙げられます。 通常のプロジェクト管理の方法論は、 プロジェクトの分解・構造化（WBSの作成）WBSの作成） プロジェクトに必要な全作業の前後関係、平行関係を明らかにする 作業スケジュールの作成 進ちょく管理 と順を追って進めるのですが、プロジェクトの分解・構造化が非常に難しい作業であるため、WBSの精度
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
