作業分解図（WBS）は、プロジェクト管理の分野で使用されているツールです。プロジェクトを定義し、プロジェクトの各要素を定義済みのグループエンティティに分割して、より効率的な方法で割り当ておよび完了できるようにします。要素には、販売指向プロジェクトの製品、建築プロジェクトのコンポーネント、管理プロジェクトの権限の委任などがあります。
意義
作業分解図構造では、要素が定義され、次にツリーシステムに分割されます。このシステムは、プロジェクトの各部分に異なる優先順位を与え、その重要度をツリー上の場所に一致させます。このツリーは、プロジェクトのさまざまな部分を、それを完了するように割り当てられているさまざまな作業者に委任するのにも役立ちます。こうすることで、混乱が解消されます。さらに、プロジェクトマネージャは、作業者が作業を完了するのにかかる時間に基づいて、各プロジェクトピースに期日を割り当てることを希望する場合があります。ツリーの各部分は、プロジェクトの特定の部分を割り当てられた従業員によって、より小さな作業詳細構造に分割される場合があります。
歴史
仕事の内訳の構造は軍から始まりました。 1950年代後半にポラリスミサイル計画を開発したとき、米国国防総省は概念を作成しました。プロジェクトを完了した後、DODはそれが使用した作業内訳構造を公表し、この手順がこの範囲と規模の将来のプロジェクトで従うことを義務付けました。その後、このプロジェクト管理方法は民間部門に吸収され、企業プロジェクトが完成する最も一般的で効果的な方法の1つであり続けています。
特徴
作業分割構造をできる限り効率的にするために、ツリーの開発で一般的に従ういくつかの規則があります。これらの最初のものは100％ルールです。これは、内訳構造に、プロジェクトで要求される目標指向の作業の100％を含める必要があることを示しています。ただし、これとは別に、作業分解の構造は、プロジェクトの成果にのみ焦点を当てる必要があります。プロジェクトを実現させる方法には焦点を当てないでください。さらに、この構造は、ツリー内に相互に排他的な要素のみを含めるようにする必要があります。これにより重複を防ぎ、全員が自分に割り当てられたタスクを確実に認識できます。
誤解
作業内訳の構造は、プロジェクトに入るすべての作業の完全なリストではありません。プロジェクトに入れるべき責任と工数の効率的な委任を可能にするのは単なるツリーです。また、ワークブレークダウン構造は、人事組織の目的には使用されません。プロジェクトの範囲は、従業員の委任がツリー自体によって定義されるのではなく、ツリーから流れることができるように概説されるべきです。内訳構造内で各グループの責任を定義するために、別々の組織階層図を使用することができます。
検討事項
多くの企業やプロジェクト管理者は、構造によって要求される詳細レベルに追いついていないため、仕事の内訳構造に圧倒されています。これが、WBSをできるだけ単純にすることが重要である理由です。この忠告には、80時間ルールを守ることの重要性が含まれています。これは、プロジェクトのどの要素も、プロジェクトに割り当てられた1人当たり80時間を超えてはならないことを意味します。これは、プロジェクト管理者がプロジェクト要素をどこでいつ2つ以上のサブ要素に分割するかを知るのに役立つ経験則です。
