プロジェクトの作業とプロジェクトの成果物は、内訳に使用されるものです。 分解するレベルは小さくなり、管理しやすくなります。

1点目：理論上分割できないほど小さい

2 番目のポイント: ドメインごとに管理できる作業パッケージ。つまり、この作業パッケージを個別に割り当てることができ、そのコスト、スケジュール、リソースを見積もることができます。

機能構造ツリーは、システムの性能をさまざまな機能に分解する階層構造であり、各機能はさらにサブ機能に分解でき、独立して製品の形を形成することができます。

製品構造ツリーとは、システムを定められた機能に基づいて順次形成されるハードウェア製品とソフトウェア製品のすべてに分解する階層構造であり、WBS作成の基礎となります。

作業分解構造コードは、通常の数字と区切り文字の文字列による作業分解構造内の各単位の識別を指します。 WBS コードと WBS の間には 1 対 1 の対応関係があり、この識別により作業分解構造内のユニットの位置と所属を一意に決定できるため、コンピュータによる WBS の識別と検索が容易になります。

作業分解構造単位（WorkUnit）は、各作業パッケージから構成される作業ユニットと呼ばれる作業分解構造を構成するそれぞれ独立した部分です。

WorkPackage は、作業分解構造の最下位の作業単位であり、一連のジョブで構成されます。作業パッケージを使用すると、コストの予算編成とコストの概要統計を簡単に実行できます。

アクティビティは、さまざまなプロジェクトの成果物を完了するために実行する必要がある特定のアクティビティです。文書作成、設計・製図、製造、試験、最終組立、試験、検収、レビュー、引き渡し、飛行試験など。ジョブ間の論理関係を確立し、ジョブの期間とリソース要件を見積もって、詳細な技術プロセスと計画プロセスを形成します。

属性とは、タスクの種類、リスク レベル、プロジェクト内の優先度、品質コスト、および名前、モデル、ステージ、コード (WBS コード)、タスクの種類、完了単位、担当者など、作業単位、作業パッケージ、操作に関して編集されたその他の情報を指します。完成責任者、完成参加者、予算、完成形態、前任部隊（直前と後任の関係）、予定工期、実績工期など。

内容：プロジェクトの成果

原則: たとえば、内容は単純なトレーニング プログラムではなく、名前、性質、カテゴリ (プロジェクト管理のオールラウンド ツールボックス トレーニング プログラム) として記述する必要があります。

内容: 重要なコンポーネント

原則: 100% 完了している必要があります。100% 未満の場合、一部のコンテンツがプロセスで失われ、スコープ クリープが発生し、スケジュールの次のステップに影響します。

内容：詳細な構成

原則: 成果物の形式。それによってのみ、作業パッケージを特定の所有者に割り当てることができます。したがって、作業パッケージの最後の層には、実際にはタスク リーダー、時間、コスト (さまざまなリソース) などを含めることができます。

(1) プロジェクト作業における直接の知識または経験を持っている必要がある、コア プロジェクト チームのメンバーを集めます。

(2) プロジェクトの実施順序に従ってプロジェクトのライフサイクルの各段階を決定するか、納品される製品構造のコンポーネントに従って、またはプロジェクト管理を含むプロジェクト作業の性質に従ってプロジェクトの主な成果物を決定する。重要な作業を見逃さないように、このレベルからチェックを開始することが重要であることに注意してください。

(3) プロジェクトのライフサイクルの各段階における主要な作業を完了するための具体的なタスク、またはプロダクトのさまざまな構造を実現し、プロジェクトの成果を達成するための具体的なタスクを決定する

(4) それぞれの特定のタスクを完了するためのサブタスクを決定し、作業分解構造の第 3 レベルを形成します。

(5) 各サブタスクを完了するために必要な具体的なアクティビティを決定し、パフォーマンスの測定を容易にするために、各アクティビティの完了後に検証可能な結果を​​出力する必要があります。

分解が徹底的、完全、かつ正しいかどうかを検証する

欠落しているアクティビティはありますか? 各アクティビティの定義は明確かつ完全ですか? 下位レベルのアクティビティは、分解項目を完了するために必要かつ十分ですか?

各タスクに責任と役割を簡単に割り当て、適切な部門、プロジェクト チーム、または個人に割り当てることができますか? 各アクティビティに必要なリソースを簡単に決定できますか?

各タスクの期間やコストは簡単に見積もることができますか?

各タスクを完了するための手段は明確に理解されていますか?

WBS がその役割を果たすためには、何も省略することはできません。

このスケジュールを管理するには、大小のすべてのタスクの完全なリストが必要です。

WBS は詳細にする必要がありますが、わかりにくいほど詳細にする必要はありません。

番号付けに関しては、通常、1、1.1、1.1.1 などのように、段階的に数値レベルが下がることでレベルが区別されます。

番号の後の名前には名詞のみを使用でき、動詞は使用できません。

WBS では、成果物と、最終成果物につながるタスクに重点が置かれます。したがって、ここでは「方法」よりも「何を」が重要です。動詞はアクションを説明するのに適しており、説明に使用する必要がありますが、明確にするために、WBS の各ステップには名詞を使用する必要があります。

成果物

プロジェクトの段階

サブプロジェクト

地理上の位置

部門

関数

実装プロセス

作業成果物 (WorkingProduct) は、プロジェクトが生成する必要がある作業結果であり、プロジェクトの最終成果物のコンポーネントである場合もあれば、プロジェクトの中間プロセスの出力結果である場合もあります。

作業成果物は大小さまざまで、相互に関連しているものや従属的なものもあります。

作業成果物のリストを作成するプロセスは、プロジェクト チームによって完了するブレーンストーミング手法として使用できます。

大小を問わず、多数の作業成果物がリストされています。大規模なプロジェクトには数百、数千の項目があります。

これらの作業成果物の属性と関係は、構造化された方法で編成され、トップダウンの段階的な作業成果物のブレークダウン ストラクチャ (PBS: ProductBreakdownStructure) を形成します。

これは、製造業における製品部品表 (BOM) であり、製品がいくつの部品で構成されているかを示します。

PBS では、作業成果物を取得するタスクが明確に定義されていれば、PBS の構造に従って WBS を取得できます。

注: 同じ作業成果物を取得するためのタスクが異なる可能性があるため、同じ PBS を異なる WBS で使用できます。

WBSのタスクが決まれば、そのタスクを遂行する責任者も明確になります。

したがって、WBS はプロジェクト全体の組織内訳構造を形成することができ、それらの人々がプロジェクトのタスクを完了し、作業成果物を取得してプロジェクトを完了します。

同様のタスクの WBS に基づいて、このタスクの作業分解構造を指定します

つまり、プロジェクトの最も大きな単位から始めて、それらを徐々に次のレベルの複数のサブ項目に分解します。このプロセスでは、レベルの数を継続的に増やし、作業タスクを洗練します。このアプローチは、プロジェクト マネージャーには広範な技術知識とプロジェクトに関する全体的な視点があるため、おそらくプロジェクト マネージャーにとって最良のアプローチです。

多様な考え方

関数ポイントを分類して上位レベルの関数パッケージを形成する

一歩一歩上向きに収束していく

ツリー構造図のWBSはレベルが明確で非常に直感的です。これは非常に構造的ですが、大規模で複雑なプロジェクトの場合は、主観的なため、プロジェクトの全体像を表現するのが難しく、小規模で中程度のプロジェクトでは一般的です。

実際のアプリケーションでは、特にプロジェクト管理ソフトウェアでは、タスク リスト スタイルの WBS アプリケーションが比較的一般的です。

1.施設の計画的な分解による管理。

2.結果に焦点を当てます。どのように達成したかではなく、何が達成されたかです。

3．作業分解構造を通じて、テクノロジーと人材、システムと組織の間で結果のバランスを取ることができます。

4．プロジェクトに関与するすべての部門間の役割、責任、協力関係を定義して契約を締結します。

5.簡潔な報告構造を採用します。

作業分解構造を使用すると、効果的なプロジェクト管理の 5 つの原則のうち最初の 3 つを満たしながら、作業を 1 つの詳細レベルでのみ定義するという計画上の落とし穴を回避できます。構造化された方法で仕事を定義すると、より良い結果が得られます。成果物によって作業が定義されると、プロジェクトが進むにつれて、生産設備に必要な作業のみが実行されるため、スケジュールがより固定的になります。環境が変化し続けるにつれて、プロジェクトに必要な作業も変化する可能性がありますが、それがどのように変化しても、最終結果にとって有益でなければなりません。

WBS の目的は製品を生産し、責任を割り当てながら各製品またはサービスに個別の部門を与えることであるため、WBS 内の作業パッケージは自然です。

作業が詳細なレベルでのみ定義され、作業パッケージにまとめられている場合、その作業パッケージは不自然であり、プロジェクト マネージャーは、人々に独自に作業を完了させる代わりに、日々いくつかの技術や手法を教えることに忙しいだけになります。 。

低いレベルで制御すると、仕事を完了するのに必要な時間よりも多くの時間を制御することになる可能性がありますが、高いレベルで制御すると、私たちが見ていないときに重要な状況がすり抜けてしまう可能性があります。

一般に、統制活動の長さは統制会議の頻度と一致している必要があります。

実際には、WBS の分解レベルは必ずしも固定されているわけではありません。リスクのレベルに応じて、WBS の最低レベルが決定されます。

リスクの低いプロジェクトでは、作業分解の最低レベルが作業パッケージになる可能性があります。

よりリスクの高いプロジェクトでは、プロジェクトの最も低いレベルの 1 つに進むことができます。

完全な WBS を作成することで、エンジニアリング プロジェクトの全体的な目標が決まり、個々の作業 (部分) とプロジェクト全体 (全体) の関係が決まります。

これらの大型プロジェクトは巨額の資金と数年に渡るプロジェクトであるため、プロジェクト開始時に想定していたプロジェクト環境はプロジェクトの進行に伴って大きく変化し、これがプロジェクト初期の不確実性であることは何度も述べてきました。 [pp1]。そのためには、すべての関連グループが共通の情報ベース、つまりすべての関連グループまたはユーザーがプロジェクトの開始から最終完了まで情報を伝達するために使用できるツールを持つ必要があります。

予算、スケジュールを作成し、プロジェクトのその他の側面を説明するための基礎として作業分解構造を使用すると、プロジェクトに関連するすべての人またはグループが、プロジェクトを完了するために必要な作業とプロジェクトの進捗状況を理解できるようになります。

一般的なプロジェクト管理システムには、スケジュール、経費、会計などのさまざまなサブシステムが含まれています。

サブシステムはある程度独立していますが、プロジェクト管理の目的を真に達成するには、サブシステム間のシステム情報の転送が不可欠です。

WBS コードを適用すると、システムに入力されるすべての情報を統一された定義方法で作成できるため、収集されたすべてのデータを同じベースラインと比較できるようになり、プロジェクト エンジニア、会計士、その他のプロジェクト マネージャーが WBS コードを参照できるようになります。同じ情報は同じ意味を持ち、プロジェクト管理への影響は明らかです。

WBS に基づいてさまざまなサブシステム間の接続が一般的であればあるほど、分析におけるシステムの差異を削減または排除できるため、プロジェクト管理にとって有益になります。