Loading article…
プロジェクト管理およびシステムエンジニアリングにおけるワークブレークダウンストラクチャ（WBS）[ 2 ]は、プロジェクトをより小さなコンポーネントに分解したものです。これは、チームの作業を管理しやすいセクションに整理する重要なプロジェクト管理要素です。プロジェクト管理知識体系では、ワークブレークダウンストラクチャを「プロジェクトチームがプロジェクト目標を達成し、必要な成果物を作成するために実行する作業範囲全体の階層的分解」と定義しています。[ 3 ]： 434 [ 4 ]
WBSは、詳細なコスト見積もりと管理に必要な枠組みを提供すると同時に、スケジュールの作成と管理に関するガイダンスも提供する。[ 5 ]
WBSは、プロジェクトを成果物（フェーズなどの主要なものから、ワークパッケージと呼ばれることもある最小のものまで）に階層的かつ段階的に分解したものです。これはツリー構造であり、プログラム、プロジェクト、契約などの目的を達成するために必要な作業の細分化を示します。[ 6 ]プロジェクトや契約では、WBSは最終目標から始めて、それを規模、期間、責任の観点から管理可能なコンポーネント（システム、サブシステム、コンポーネント、タスク、サブタスク、ワークパッケージなど）に順次細分化することによって作成され、これには目的を達成するために必要なすべてのステップが含まれます。
作業分解構造は、契約全体の計画と管理を自然に進めるための共通の枠組みを提供し、作業を明確な増分に分割するための基礎となります。そこから作業明細書を作成し、技術、スケジュール、コスト、労働時間に関する報告を確立することができます。[ 6 ]
作業分解構造では、タスク、材料などの下位コストを、より上位の「親」タスク、材料などに合計することができます。作業分解構造の各要素について、実行されるタスクの説明が生成されます。[ 7 ]この手法（システム分解構造[ 8 ]と呼ばれることもあります）は、プロジェクトの全体範囲を定義し、整理するために使用されます。
WBSは、製品を生成するために必要な作業（計画されたアクション）ではなく、プロジェクトの主要な製品（または計画された成果）を中心に構成されています。計画された成果はプロジェクトの望ましい最終目標であるため、それらを達成するために必要な計画されたアクションのコストを収集できる比較的安定したカテゴリのセットを形成します。適切に設計されたWBSでは、各プロジェクトアクティビティをWBSの1つの末端要素にのみ簡単に割り当てることができます。WBSは、コスト計算における機能に加えて、システム仕様のあるレベルから別のレベルへの要件のマッピングにも役立ちます。たとえば、機能要件を高レベルまたは低レベルの設計ドキュメントにマッピングする相互参照マトリックスなどです。WBSは、アウトライン形式で水平に表示することも、ツリー構造（組織図など）として垂直に表示することもできます。[ 9 ]
WBSの作成は通常、プロジェクトの開始時に行われ、詳細なプロジェクト計画およびタスク計画に先行します。プロジェクト管理の知識における反復プロセスである段階的精緻化により、プロジェクト管理計画の詳細と情報量が増加し、 [ 10 ]プロジェクト範囲の説明、計画、予算などの項目の初期見積もりがより正確になります。 [ 11 ]また、プロジェクトチームがより詳細なプロジェクト計画を作成するのにも役立ちます。 [ 12 ]
PMIの作業分解構造に関する実践基準では、作業分解構造の主要な2つのタイプが特定されています。
成果物指向型WBS（製品分解構造とも呼ばれる）は、主要な成果物を用いてプロジェクト内の各作業をグループ化する。
フェーズ指向型WBSは、プロジェクトライフサイクルの主要なフェーズまたは段階に基づいて作業をグループ化します。
作業分解構造の概念は、米国国防総省(DoD)のプログラム評価レビュー技法(PERT)によって開発されました。PERT は、1957 年に米海軍がポラリスミサイル計画の開発を支援するために導入しました。[ 13 ]「作業分解構造」という用語は使用されませんでしたが、この最初の PERT の実装では、タスクを製品指向のカテゴリに整理しました。[ 14 ]
1962年6月までに、国防総省、NASA、航空宇宙産業は、WBSアプローチを説明したPERT/COSTシステムの文書を公開した。[ 15 ]このガイドは、国防長官によって全軍での採用が承認された。[ 16 ] 1968年、国防総省は「防衛資材品目の作業分解構造」（MIL-STD-881）を発行し、国防総省全体で作業分解構造の使用を義務付けた軍事規格とした。 [ 17 ]
この文書は複数回改訂されています。2023年5月現在、最新の改訂版は2022年5月13日に発行されたF版です。規格のバージョン履歴と最新の改訂版は、国防兵站局（DLA）のASSISTウェブサイトに掲載されています。 これには、特定の防衛資材商品システムに関するWBS定義が含まれており、すべてのシステムに共通するWBS要素についても説明されています。
MIL-STD-881Fに基づく防衛資材品目のカテゴリーは以下のとおりです。
MIL-STD-881Fの付録Kで特定されている共通要素は、統合、組立、試験、チェックアウト、システムエンジニアリング、プログラム管理、システム試験および評価、データ、特殊支援機器、共通支援機器、運用／サイト活性化、請負業者ロジスティクスサポート、産業施設、初期予備部品および修理部品です。この規格には、宇宙システム、ロケットシステム、戦略ミサイルシステムに特有の追加共通要素も含まれています。
1987年、プロジェクトマネジメント協会（PMI）は、これらの手法を非防衛組織に拡大したことを文書化した。プロジェクトマネジメント知識体系（PMBOK）ガイドはWBSの概念の概要を示しており、「作業分解構造の実践標準」は国防総省の標準に匹敵するが、より一般的な適用を目的としている。[ 18 ]
作業分解構造の重要な設計原則は、100%ルールと呼ばれています。[ 19 ]これは次のように定義されています。
相互排他性：100%ルールに加え、作業分解構造の異なる要素間でスコープ定義に重複があってはなりません。このような曖昧さは、作業の重複や責任・権限に関する誤解を招く可能性があります。また、このような重複はプロジェクトの原価計算を混乱させる可能性もあります。
作業分解構造の設計者が、WBS にアクション指向の詳細を記述しようとすると、アクションが多すぎるか少なすぎるかのどちらかになる可能性が高い。アクションが多すぎると親スコープの 100% を超え、少なすぎると親スコープの 100% に満たない。100% ルールに従う最善の方法は、WBS 要素をアクションではなく成果または結果の観点から定義することである。これにより、WBS が方法を過度に規定しないことも保証され、プロジェクト参加者の創意工夫と創造的思考がより促進される。プロジェクトが専門サービスを提供する場合、一般的な手法は、計画されたすべての成果物を記述して、成果物指向の WBS を作成することである。[ 21 ]プロジェクトのフェーズ (たとえば、予備設計フェーズ、クリティカル設計フェーズ) で作業を細分化する作業分解構造では、フェーズが成果物によって明確に区切られ、また、開始基準と終了基準の定義にも使用される(たとえば、承認された予備設計レビューまたはクリティカル設計レビュー)必要がある。
新製品開発プロジェクトにおいて、成果重視のWBS（作業分解構造）を確実にするための最も一般的な手法は、製品分解構造（PBS）を使用することです。
機能主導型のソフトウェアプロジェクトでは、WBSと同様の手法、つまり機能分解構造を用いる場合がある。
作業をより小さな要素に分割するのをいつ止めるかを決定する必要があります。ほとんどのプロジェクトでは、2～4レベルの階層構造で十分です。これにより、WBSで定義された成果物を作成するために必要なアクティビティの期間を決定するのに役立ちます。WBSで定義された特定の成果物を作成するために必要なアクティビティまたはアクティビティ群の適切な期間を決定する際には、いくつかの経験則または「経験則」が使用されます。
プロジェクトマネジメント協会によると、ワークパッケージとは「コストと期間が見積もられ管理されるワークブレークダウン構造の最小レベル」である。[ 4 ]
アクティビティレベルのワークパッケージとは、次のようなタスクのことです。
WBS要素名が曖昧な場合は、WBS辞書がWBS要素間の区別を明確にするのに役立ちます。WBS辞書は、マイルストーン、成果物、アクティビティ、スコープ、場合によっては日付、リソース、コスト、品質を使用して、WBSの各コンポーネントを説明します。プロジェクトマネジメント協会によると、WBS辞書は「作業分解構造の各コンポーネントに関する詳細な成果物、アクティビティ、スケジュール情報を提供する文書」と定義されています。 [ 4 ]
作業分解構造の要素には、階層構造を明らかにするために、順番に番号が付けられるのが一般的です。番号付けの目的は、ベンダーやサービスに関係なく、同様のシステム全体で WBS を識別および管理するための一貫したアプローチを提供することです。[ 22 ]例えば、1.1.2 推進 (以下の例) では、3 つの数字が 2 つの小数点で区切られているため、この項目はレベル 3 WBS 要素として識別されます。コーディング スキームは、進捗状況の追跡、スケジュール、請求など、あらゆる文書のコンテキストで WBS 要素を認識するのにも役立ち、WBS ディクショナリへのマッピングを可能にします。作業明細書やその他の契約記述書に、WBS と同じセクション用語と階層構造を含めること が推奨される慣行です。
WBSコーディングスキームの実例は[ 23 ]である。
1.0 航空機システム
ツリー構造の最下位要素である末端要素は、それ以上細分化されない要素です。作業分解構造では、このような要素（アクティビティまたは成果物）は、作業パッケージとも呼ばれ、リソース要件、予算、期間の観点から見積もられ、依存関係によってリンクされ、スケジュールが定められます。WBS要素と組織単位の接点では、管理勘定と作業パッケージが設定され、パフォーマンスが計画、測定、記録、管理されます。[ 24 ] WBSは、関心のある任意のレベルまで表現できます。推奨される最小レベルは3レベルで、高コストまたは高リスクの項目にのみ追加のレベルがあり、[ 25 ]システムエンジニアリングやプログラム管理などのケースでは2レベルの詳細があり、[ 26 ]標準では、ソフトウェア開発が5レベルまで[ 27 ]、消防システムが7レベルまで[ 28 ]など、深さが異なるWBSの例が示されています。
上位のWBS構造は、組織またはドメイン内に存在する規範やテンプレートの指示と整合していなければなりません。たとえば、米国海軍の造船では、MIL-STD [ 29 ]に規定されている航海用語とその階層構造が海軍建築[ 30 ]に組み込まれており、海軍の対応する部署や手順がこの海軍建築構造に合わせて構築されていることを尊重しなければなりません。したがって、階層内のWBS要素の番号付けや命名に大きな変更を加えることは許容されません。
隣の図は、100%ルールと「段階的詳細化」手法を示す作業分解構造（WBS）の構築手法です。WBSレベル1では、カスタム自転車の設計と製造というプロジェクト全体の範囲として、100単位の作業が示されています。WBSレベル2では、100単位が7つの要素に分割されます。各作業要素に割り当てられる単位数は、労力またはコストに基づいて決定され、作業期間の見積もりではありません。
WBSレベル2の3つの主要要素は、レベル3でさらに細分化されます。レベル3の2つの主要要素は、それぞれプロジェクト全体のスコープのわずか17%を占めるにすぎません。これらの主要要素は、前述の段階的詳細化手法を用いてさらに細分化することができます。
これは、段階的アプローチ（正式なシステム開発ライフサイクルにおける段階的なプロセス）、強制イベント（四半期ごとの更新や会計年度の予算再編成など）、またはスキル／役割ベースのアプローチと比較した、製品ベースのアプローチ（最終製品、成果物、または作業ベース）の一例です。
WBS設計は、ポイント値の自動集計を可能にするソフトウェア（スプレッドシートなど）によってサポートできます。作業量やコストの見積もりは、プロジェクトチームメンバー間の議論を通じて作成できます。この共同作業手法により、スコープ定義、前提条件、およびプロジェクト管理に必要な粒度レベルに関する合意についての理解が深まります。[ 31 ]
{{cite book}}: CS1メンテナンス: 場所の発行元が見つかりません (リンク)
ウィキメディア・コモンズにある作業分解構造に関するメディア