- 追加された行はこの色です。
- 削除された行はこの色です。
- 成果物/WBS へ行く。
Work Breakdown Structureの略で、タスク別のスケジュール表のこと。
1960年代前半に米国防総省とNASAにより生み出された概念で、プロジェクトマネジメントの中核を担う。
プロジェクト成果物や中間成果物を、より管理しやすい小さな単位に分割し、計画・実行・コントロール・Closeという各アクティビティ定義ができる程度に、充分詳細なレベルまで要素分解を行う。
----
#contents
----
* 作成目的 [#q534e575]
[[プロジェクト]]が持つタスクを漏れなく洗い出し、消化するために必要な期間や要員を管理し、納期通りに要求された品質の機能を全うすることを目的とする。
作業範囲全体を定義するため、プロジェクトスコープは全て網羅されていなければならないし、ここに記載されていない作業はスコープ外であるため実施してはならない。
段階的に分解することで重複や抜け漏れを防ぐことができる構造にはなっているが、書き忘れや考慮漏れといった人的ミスを許容しない考え方で構成されているため、作成や更新には細心の注意を払わなければならず、チームリードをはじめとした関係者のレビューを必ず実施し、完成度を上げること。
また、ある程度の精度を保つためには、タスクの洗い出しのみならずリソースを当てはめる必要があり、具体的に、いつ・誰が・どのタスクを・いつ着手し・いつ終わるか・・・これらを定めねば、ノリと勢いの計画になってしまったり、精神論が支配する世界になってしまったり、残業前提のスケジュールとなってしまう。
計画なんて、どんなに綿密に立てたところで、予想もしていないことが起きたり、対顧客との政治的な事情を加味しなければならなかったり、ベンダ間あるいはプライム社内などの要員問題やトラブルが発生したりするものなので、''基礎の基礎として保守的に立案しなければならない''わけで、こういった不安要素を抱えたまま実行の段になってしまうことは、即ち破綻の足音と考えていい。
* 作成単位 [#tebcb1e8]
フェーズごとに作成するという観点もあるが、残タスクを含めて鳥瞰的に見辛くなってしまうため、基本的には[[プロジェクト]]でひとつとする。
実際には、有耶無耶にしたいテーマや臭いものにフタしたいネタも往々にしてあるため、フェーズごと或いは次フェーズは別のものとした方が良いという見方もあったりもするが。
それはそうとして、プロジェクトタスクはベンダのみの作業だけでなく顧客側と分担して進めることもよくあるが、ユーザ側とベンダ側タスクを同一のWBSにするか否かというトピックがある。
顧客側がまともであれば、当然プロジェクト全体として共有し進捗を把握することが良いが、そうでない場合は、顧客側がまともでない場合は、顧客タスクのみ切り分け(隔離？)て別途Mtgで状況を共有するのも一案だろう。
ただしその場合、責任範囲が明確になる半面、先行タスクや後続の関連性がやや見えづらくなることは認識しなければならない。
* 作成担当 [#oa1e41fd]
基本的には、[[PM>プロジェクト/プロジェクトマネージャ]]のみが責任を持って更新する。
但し、末端のタスク状況やホットな話題の進捗などはチームリードが管理していることが多いため、各チームリードに更新を指示し、[[PM>プロジェクト/プロジェクトマネージャ]]が管理することが多い。
* 作成タイミング [#w3667485]
プロジェクト開始時点。
次フェーズ移行前。
* 更新ルール [#ye1d7f1a]
基本的には随時だが、最低でも2〜3dayごとに更新したいもの。
冒頭にも記載したが、WBSに載っていない作業をメンバがやるようになったら、その[[プロジェクト]]は残念な意味で末期と言っていい。
* 補足 [#tcc21699]
** WBSの用語 [#l118f49e]
-WBS要素
WBSの各レベルの項目で、いうなればタスクのグループ。
-ワークパッケージ
WBSの最下位の作業要素で、WBSの最下位の成果物構成要素。
アクティビティ定義、要員配置、責任を持つ組織がどこであるか等の根拠となる。
-アクティビティ
プロジェクトの過程で実行する作業の一要素で、ワークパッケージを要素分解したもの。
所要期間やリソースなどを定義する。
-タスク
ワークパッケージをさらに分解した一般的な作業レベルの項目。WBSの最小単位。
アクティビティとほぼ同義。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
