作業分解構成図 (WBS) の概要

By Kate Eby | 2016年11月8日 (更新 2022年11月29日)

作業分解構成図 (WBS) を目にして、それがプロジェクト管理にどう役立つかを知りたいと思ったことはないでしょうか?作業分解構成図 (WBS) は、プロジェクト成果物と、それを生み出す上で必要となるすべての小さな構成要素を定義および追跡するための視覚的なツールです。作業分解構成図を使用すると、プロジェクトの期限に向けて進む際に達成しなければならないことに集中できます。

この記事では、作業分解構成図とは何か、作業分解構成図にあたらないものは何か、作業分解図を使用するメリット、および作業分解図の作成方法について説明します。また、プロジェクトに欠かせないこの強力な製品管理ツールを使いこなす方法について、一流の専門家から学びます。

プロジェクト管理における作業分解構成図とは

プロセスと知識の各領域を網羅したプロジェクト マネジメント知識体系は国際的に認知され、プロジェクト管理に携わるプロフェッショナルのベスト プラクティスとして受け入れられていますが、作業分解構成図 (Work Breakdown Structure) はその中で「プロジェクト目標を達成し、必要な成果物を作成するためにプロジェクト チームが実行する作業の全範囲を階層的に要素分解したもの」と定義されています。WBS では、まず望ましい結果または製品から始めて、それを生み出す上で必要となる小さな成果物やタスクに細分化または分解します。

 

IC work breakdown-c

WBS では、成果物はオブジェクト、サービス、またはアクティビティになります。作業分解構成図では方法でなく成果物 (「どのように」ではなく「何を」) に焦点を当てることで、不要な作業を排除し、意図した結果を得ることができます。十分に練られた WBS は、スケジュールの作成、コストの推定、リスクの判断に役立ちます。これは通常、プロジェクトのタイムラインとプロセスを詳しく説明する視覚的なチャートまたは図表であり、プロジェクト全体を通じて生み出され、実行される各タスク、サブタスク、および成果物を捕捉します。多くの場合、目次に似たアウトラインとして表示されますが、タブなどの視覚的な構成システムを用いて整理することもできます。

Value Generation Partners (バリュー ジェネレーション パートナーズ) の共同創設者であり、『Project Management for Success Handbook (原題)』の著者である Rod Baxter 氏は、WBS を「製品管理ライフサイクルに必要な要素」と呼んでいます。「作成にはスキルと練習が必要ですが、リリース日に間に合わせ、効率化する上で不可欠です」。

プロジェクト管理ガイド

プロジェクト管理のすべてが一元的に

Smartsheetのロゴと「プロジェクト管理への 101 ガイド」という文字が入ったイラスト

プロジェクト管理の取り組みを向上させる準備はできていますか?作業をより効果的に管理するためのヒント、ベスト プラクティス、無料のリソースについては、包括的なプロジェクト管理ガイドをご覧ください。

ガイドを見る

WBS の歴史: タイムラインと将来の展望

1957 年、米国海軍では潜水艦発射弾道ミサイル「ポラリス」の開発プログラムにスケジュールの遅れが発生していたため、解決策を必要としていました。チームは、タスクを決定し、結果に基づいてプロジェクトに必要な工数を推定する公式を開発しました。これは後に PERT (プログラム評価およびレビュー手法) として知られるようになります。

国防総省 (DOD) と NASA は PERT をモデルとして、1962 年に作業分解構成図プロセスに関する最初の説明を公表しましたが、その名前で初めて言及されたのは 1968 年になってからでした。防衛資材作業分解構成図 (MIL-STD-881) によって、作業分解構成図が国防総省全体の標準として確立されるとともに、航空機や船舶など特定の軍事用途向けのテンプレートが公開されました。国防総省と協力する民間の軍需企業も、適切な作業分解構成図テンプレートを使用する必要があります。

1987 年、プロジェクト マネジメント協会は PMBOK を通じて、さまざまな非軍事用途における標準的なプラクティスとしての作業分解構成図を確立しました。「作業分解構成図 (ワーク ブレークダウン ストラクチャー)」という用語は、企業やその他の組織プロジェクトで応用するために 1993 年に導入されたものです。

1999 年 6 月には PMI 標準プログラムによって、ワーク ブレークダウン ストラクチャー (WBS) 実務標準を策定するためのプロジェクト憲章が発行されました。PMI によれば、計画プロセス群は、スコープ計画 (3.2.2.2)、スコープ定義 (3.2.2.3)、WBS 作成 (3.2.2.4) という 3 つの重要なステップから始まります。

多くの組織は機敏性と俊敏性を重視しているか、または「飛行機を飛ばしながら組み立てる」ことを求められているため、WBS 計画または WBS 辞書の作成ステップを省略しています。適切な計画と可視性がなくてもプロジェクトを納品することは可能ですが、チーム メンバーに負担がかかり、最終的には成果物の品質が低下する可能性があります。そうしたリスクが時間の経過とともに受容可能になることはないため、可能な場合は常に WBS を使用することをお勧めします。

企業はあらゆるプロジェクトでより多くのデータを蓄積しており、それらを解析し、プロジェクトの開始後にデータがプロジェクトにどのような影響を与えるかを予測する必要があるため、WBS と綿密な計画が今後も重要な要素となることは明らかです。今後発生し得るその他の変動要素として、グローバル化、為替変動、政治的変化、規制などが挙げられますが、強力なプロジェクトには、これらの潜在的な依存関係に対処するための事前の計画が必要です。

WBS に関する優れたリソースとしては、ポール・ビュレック (Paul Burek) 著『The ABC Basics of the WBS (原題)』やホーマーおよびガン (Homer & Gunn) 著『The Intelligent Structure of Work Breakdowns Is a Precursor to Effective Project Management (原題)』(1995) などがあります。

作業分解図の用途と目的

作業分解構成図または作業分解辞書は、計画プロセスで省略されることが多いですが、プロジェクトを効率的に、かつ期限内に完了させるための強力なツールです。WBS を作成する利点とメリットは以下の通りです。

  • プロジェクトのすべての部分を視覚的に表現できる
  • 経営陣とチーム メンバーにプロジェクト全体の進捗状況を継続的に提示できる
  • 具体的かつ測定可能な成果を定義できる
  • 作業を管理可能な規模に分割できる
  • 成功体験を再現する方法を提供できる
  • コストの推定と、人的資源をはじめとするリソースの割り当ての基盤を確立できる
  • 責任またはリソースの重複とギャップをなくすことができる
  • 作業範囲外のアイテムを追加したり、重要な成果物を忘れたりする可能性を最小限に抑えられる

さらに、組織は作業分解構成図を使用することで、その他のメリットも享受しています。これらのメリットは特定のプロジェクトを通じて実現しますが、組織全体のプロセスと文化の改善にも役立ちます。例として以下のものが挙げられます。

  • 各プロジェクトの WBS を考慮することで、組織は部門全体の予算を迅速に計算できる。
  • チームはプロジェクトのスケジュールと予算を迅速に決定できる。
  • プロジェクトの進行に応じて、チームは作業分解構成図の特定のセクションを追跡して、プロジェクトのコスト パフォーマンスを判断したり、組織内の課題や問題領域を通知したりすることができる。

十分に練られた作業分解構成図があれば、チームは以下に挙げるメリットを通じ、整備が行き届いた機械のように業務をスムーズに進めることができる。

  • 生産性が向上する
  • プロジェクト マネージャーがさまざまなシナリオに基づいて結果を予測できる
  • プロジェクトを整理できる
  • 関係者にプロジェクト スコープを説明するためのサポートが得られる
  • 責任を分担することができる
  • コスト、リスク、時間の正確な推定が可能になる
  • コミュニケーションが強化される
  • 創造性とブレインストーミングが促進される
  • 最終目標に集中することができる
  • 詳細を整理できる
  • 問題を予防できる可能性がある
  • スケジュールの問題に対処できる
  • リスク管理が可能になる
  • タスクを割り当てることができる
  • チームの柔軟性が向上する
  • 混乱が解消される
  • チーム メンバー全員に対してタスクを明確に説明できる
  • 作業明細書の作成とサポートが可能になる
  • 各作業パッケージは測定可能なユニットであるため、プロジェクトの明確なステータス レポートの基盤が得られる

作業分解構成図の視覚的メリット

作業分解構成図のチャートや辞書を使用すると、プロジェクトの詳細とステータスを簡単に表示できます。作業を提示するにあたっては、いくつかの選択肢があります。典型的な WBS ビューはツリー型の構造図ですが、番号付きリストや表を使用することもできます。アウトライン形式を選ぶと、作業分解構成図を一番簡単に提示できるでしょう。以下に、さまざまな種類のプロジェクトに役立つその他の形式を示します。

 

IC work breakdown-c

プロジェクトの実行中、作業分解構成図の各要素を色分けすることで、作業ステータスを示せます。たとえば、予定通りの場合は緑色、遅れている場合は赤色、リスクありの場合は黄色、完了済みの場合は青色で表示します。色分けにより、スケジュールのリスクを一目で識別できます。

作業分解構成図の主要構成要素

信頼性が高く有用な作業分解構成図や作業分解辞書には、プロジェクトの重要な要素とともに、タイムライン、コスト、リソースが記載されている必要があります。有用性が高い WBS 計画には、以下の構成要素が含まれています。

  • 特定の各作業を担当する組織、部門、または個人の情報
  • 予定されている開始日と終了日
  • 必要なリソース
  • プロジェクトの推定コスト
  • 請求番号
  • 契約の詳細、要件、マイルストーン
  • 品質管理、要件、標準に関するプロトコル
  • 望ましい結果を達成する上で必要となる技術情報とリソース

より高いレベルでは、WBS はガイドと整理にも役立ちます。綿密な WBS 計画は以下のことを可能にします。

  • 人事部門によるチームの割り当てをサポートする
  • スケジュールを管理し、プロジェクトのタイムラインを決定する
  • 品質を管理および測定する
  • 企業の環境的要因を予測する
  • 組織的プロセスの資産を特定する
  • バージョン履歴を追跡する
  • 依存関係を確立する
  • プロジェクトの全体的な進捗状況を追跡する

作業分解構成図の使用者

ビジネス プロジェクト マネージャーは作業分解構成図を使用して、プロジェクトとその構成要素を整理して視覚的に表示することができます。以下のチームも、作業分解構成図を使用することでメリットを得られます。

  • 顧客対応グループ: アカウント ディレクターは作業分解構成図を利用してクライアントに進捗状況 (または障害) を示せます。WBS によってプロジェクトの成果物とマイルストーンに関する「指針」を生み出すことができるため、クライアントに進捗状況を示す便利なツールとなります。
  • クリエイティブ グループ: デザイナー、ライター、あるいはコンテンツ ストラテジストといったクリエイターが、創造性を発揮するためにサポートを必要としていることは、誰もが知っています。作業分解構成図を使用することで、プロジェクトを中心に据えた有効な方法でアイデアがスムーズに流れるようにする、利便性の高いガードレールが生み出されます。
  • リモートおよび社内のプロジェクト グループ: WBS が持つ可視性により、誰がいつ何をしているかを、間接的に関与している人も含めた関係者全員が把握できます。
  • 技術グループ: 技術チームは開発タスクのロードマップとして WBS を使用できます。多くの場合、これらのチームは業務を進めるにあたり、視覚的な「スイムレーン」やその他の構造のプロジェクト管理マイルストーンをすでに使用しています。

組織や企業の現場だけでなく、他の分野でも作業分解構成図が活用されています。

  • 商業プロジェクト プランナー: WBS を使用することで、主要企業のプロジェクトやチーム メンバーのタスクだけでなく、ベンダーや下請け業者のタスクも含めた、大規模商業プロジェクトにおける進行中の要素をすべて捕捉できます。また、必要な許可の取得や、政府による承認の進捗状況の追跡などに関する依存関係も把握できます。
  • イベント プランナー: WBS では複雑なイベントをタスクとサブタスクに分割し、それらを割り当てることで、期限が厳しい作業を複数のチームで順調に進められます。
  • 住宅および建設プロジェクト マネージャー: 通常の商業プロジェクトに関係するタスクとチーム メンバーに加えて、建設プロジェクト マネージャーは WBS を使用して、電気/ガス/水道に関する作業、建築規制に関する承認、環境に関する承認などの段階を追跡できます。
  • スコープ プランニング マネージャー: 組織が新しいクライアントと作業を行う場合、リソース プランナーとディレクターは、プロジェクトに予算とスコープを割り当てる前に、プロジェクトのタイムラインと必要なリソースについて少なくとも大まかな見通しを持っている必要があります。
  • ソフトウェア開発者: 多くの場合、ソフトウェア開発者はプロジェクトをフェーズまたは段階に分割しています。組織の他のメンバーが記載された WBS を使用すると、開発者は最も重要な成果物を最初に把握しつつ、チームの他のメンバーに可視性を提供できます。
  • システム エンジニア: システム エンジニアは、システム一式の全体像を把握するとともに、最適なパフォーマンスを発揮できるよう、システム一式を確実に動作させ、最新の内容に更新する責任を負っています。WBS により、ごく小さな詳細を捕捉してより大規模なシステム運用にマッピングする、有機的なドキュメントが得られます。情報をいつでも入手できるとわかれば、運用上のより大規模な問題に集中できるため、安心できます。

長期にわたるプロジェクト計画や作業分解計画をすでに実施している組織では、作業分解構成図により、自分の不在中にプロジェクトがどのように進行したかをプロジェクトの前任者が確認できます。また、プロジェクトの後任者は WBS を使用することで、プロジェクトの初期段階で順調に進んだことと進まなかったことを把握し、依存関係とその結果を追跡することができます。つまり、プロジェクトにおける労働力の分担を計画しなければならない監督者なら誰であれ、作業分解構成図を使用することでメリットを得られるのです。

プロジェクトの分解構成とは

「作業分解構成図」と「プロジェクト分解構成図」という 2 つの用語は、同じ意味で用いられることがあります。事実、作業分解構成図は、プロジェクトを開始から終了まで管理するためのツールとして最も一般的に活用されています。しかし理論的には、作業分解構成図を使用することで、サブプロジェクト、サブタスク、ベンダーによる貢献、およびプロジェクト全体の管理とは特に関連しないその他の関連タスクの集合体を管理できます。したがって、プロジェクトの分解構成は、単一のプロジェクトに完全にマッピングされる作業の分解構成ということになります。

作業分解構成図または作業分解辞書の必須要素

作業分解構成図に含まれるものは何でしょう?WBS プロセスで生み出される機能と関連用語を以下に挙げます。

  • ターミナル要素 (作業パッケージとも): 通常は作業パッケージと呼ばれるターミナル要素は、WBS 内の最下位の部分であり、成果物をこれ以上分解することはできません。作業パッケージは他のタスクから独立している必要があり、プロジェクト内の他の箇所で重複しないようにする必要があります。作業パッケージは、個人またはチームが実行できる管理可能な最小のタスクと考えることもできます。タスクをこれ以上細分化すると、チーム メンバーを細かく管理してしまうリスクが生じます。

    一般的に、作業パッケージでは、レポート期間内にチームまたはチーム メンバーが完了できるように割り当てを行う必要があります。週次ステータス ミーティングを開催する場合、作業は 1 週間以内に完了する必要があります。工数を決定する別の方法として、サブタスクの完了に要する時間が 8 時間未満または 80 時間以上であってはならないという 8/80 ルールを使用することが挙げられます。

    効果的な作業パッケージでは、それぞれの成果物に必要なタスクの作業、期間、およびコストが定義されています。作業パッケージの期間が 10 日を超えてはいけません。作業パッケージは作業ストリーム内で互いに独立しており、プロジェクト全体で重複しておらず、一意である必要があります。
  • WBS コーディング: 作業分解構成図の各要素には通常、上から下へと一連の 10 進数の番号が付けられます。たとえば「1.1.1.3」というラベルのアイテムは、階層の 4 番目のレベルに位置しています。このような番号付けにより、WBS チャート以外の場所で各要素を参照する際に、その要素が表すタスクのレベルを識別しやすくなります。
  • WBS 辞書: WBS 辞書 (下記参照) は、WBS 階層内の各構成要素やタスクについて詳しく説明するものです。要素をさらに定義および補強するドキュメントへのリンクを含めることもできます。WBS 辞書は、作業の相互排他性の原則、つまり重複がないという原則に対応しています。これは、それぞれの成果物とサブ成果物が極めて明確に定義されているため、作業や責任の重複がほとんど発生しません。
  • 間接作業: 間接作業 (LOE) というプロジェクトの構成要素は、プロジェクトの主要機能をサポートするアクティビティです。これには、クライアントからの電話に応答して転送するという管理作業が含まれる場合もあります。
  • 結果指向ツリー: これは WBS に概説されているプロジェクトの各ステップの結果として望ましい成果を示すモデルです。
  • 契約作業分解構成図: これにはプロジェクトで実行されるすべての種類の契約とベンダー作業が記録されています。
  • プロジェクト サマリー分解構成図: これを使用することで、プロジェクトとサブプロジェクトの概要を示し、他の成果物をそれにマッピングすることができます。
  • 作業範囲記述書: 作業範囲記述書 (SOW) は、マイルストーンや各当事者が合意した予算など、会社が顧客に提供する内容を正確に概説した署名入りの合意文書です。
  • プロジェクト スケジュール: 順番に提供されるか重複しているかに関係なく、これはプロジェクトの全構成要素のスケジュールです。マイルストーンと成果物、および各構成要素のリソースのコストが記載されます。
  • 推定の根拠: 推定の根拠 (BOE) は、プロジェクト マネージャー、経営幹部、財務リーダーによって作成され、プロジェクトで必要になる可能性がある労働力とリソースのコストを考慮に入れたツールです。BOE を使用すると、企業はプロジェクトを作成して顧客に納品するのに要する費用を推定できます。
  • リソース分解構成図: プロジェクト全体で必要とされ、使用されるリソースの各階層を、プロジェクトへの参加と退出のタイミングを含めて視覚的にリスト化し、その役割を詳しく説明するものです。
  • リスク分解構成図: 優れた計画では依存関係とリスクが考慮されています。これには、チームが遅延した場合に発生し得るリスクや、自然災害などチームの制御外にあるリスクが含まれます。
  • 組織分解構成図: 組織分解構成図 (OBS) は組織図とも呼ばれます。そこではプロジェクト リーダーを列挙し、誰が誰をどのような役割においてサポートしているかを詳しく説明します。

作業分解構成図の形式とガイドライン

作業分解構成図のドキュメントに適用される形式には、いくつかの種類があります。例として以下のものが挙げられます。

  • チャート形式: プロジェクトを視覚的に表示することに重点が置かれています。
  • チャート形式: プロジェクトを視覚的に表示することに重点が置かれています。
  • 階層構造: プロジェクトの最も重要な要素を最上部に表示することで、可視性を高めます。
  • アウトライン構造: プロジェクトのより大きな要素の時間枠、依存関係、または構成要素を提示します。
  • 表形式ビュー: 自分に最も関連しているセクションをチーム メンバーが簡単に辿ることができるようにします。

どのようなプロジェクトであれ、同じ種類の形式が常に必要になるわけではありません。これはプロジェクトの種類や、アクセスする必要があるチーム メンバーの種類に合わせて調整できますし、また調整する必要があります。

プロジェクト管理における作業分解構成図

プロジェクト スコープが明らかになったら、WBS が最初の成果物になります。ひとたび WBS が定義されると、人的資源、特定のスキル セット、物理的リソース (機器やスペースなど)、および施設など、その他のリソースのスコープを定めることが可能になります。その後、チームはベースライン スケジュールとタスク リストを作成し、割り当てを行うことができます。

同様のプロジェクトを管理するにつれて、作業分解構成図を容易に作成できるようになり、納品管理の改善に向けた基盤にすることができます。あなたとチームがこれまで経験したことのない特殊なプロジェクトの場合は、作業分解構成図を使用することで、最終製品に必要な成果物とタスクをチームが正確に定義できるようになります。

作業分解構成図は単独では作成できません。プロジェクトを完了させるために必要なすべてのことを、1 人で把握できることはほとんどありません。特に、対象分野の専門家ではないプロジェクト マネージャーの場合はなおさらです。WBS の作成はチームの努力でなされます。

作業分解構成図にまつわる誤解

WBS には、タスクの実行方法や実行時期は記載されません。WBS は計画でもスケジュールでもありません。アクティビティや責任を網羅したリストでも、典型的な組織図でもないのです。チーム リーダーは、プロジェクトに必要なすべてのタスクを WBS 内に列挙しようとすることがあります。その結果、タスクが見落とされ、プロジェクトの実行が遅れる可能性があります。

また、WBS はプロジェクトで使用されるかどうかわからない殴り書きのドキュメントでもありません。これはプロジェクト管理ドキュメントの重要な一部です。WBS を会社の変更管理プロセスの対象とし、計画された成果物に対する変更があればそれを記録する必要があります。

作業分解構成図のベスト プラクティスと設計原則

作業分解構成図を描くのは簡単です。ただし、最良の結果を達成するのに役立つ設計原則として、次のヒントを活用することができます。

方法ではなく成果物に焦点を当てる。言い換えれば、行動ではなく結果を計画しましょう。「どのように」ではなく「何を」を考えてください。作業分解構成図の主な目的は、主要な成果物を、それを形作る小さな構成要素の観点から定義することです。成果物が製品でない場合は、具体的かつ測定可能な結果を提示する必要があります。たとえば、専門サービス用の WBS を作成する場合は、そのサービスから得られる製品または結果を定義します。

特定の成果物に焦点を当てることで、分解構成図のどのレベルであっても、何が期待されているか、優れた仕事とはどのようなものかを、担当するチームや個人が正確に把握できます。これにより、タスクのリストを作成するときに起こりがちな、プロジェクト スコープ外のアイテムを追加する可能性が低くなります。チーム メンバーが To-Do リストの各アイテムをチェックすることではなく、成果物に集中すると、自発性と問題解決能力を活用してイノベーションを促進するきっかけになります。

重複 (相互排他性) をなくす。スコープの定義においては、WBS 内のタスクが重複しないようにします。重複による結果として、チームの労力が二重になる、および責任、作業、会計に関して混乱が生じるという 2 つの結果が考えられます。各構成要素を詳細に記述した WBS 辞書は、相互排他性を無効にするのに役立ちます。

100 パーセント ルールに従う。成果物に貢献しない作業を排除するには、時間であれ、資金であれ、あるいはその他の要素であれ、WBS 内のすべてのリソースの合計が 100 パーセントになるようにします。つまり、レベル 2 の要素の合計は 100 パーセントとなり、レベル 3 以下の要素はレベル 2 の割合としてロールアップされます。完了したプロジェクトの合計が 100 パーセントを超えたり下回ったりしてはいけません。

詳細度に目を向ける。一般的に作業パッケージでは、レポート期間内にチームまたはチーム メンバーが完了できる作業を提供する必要があります。ステータス ミーティングを週次で開催する場合、作業は 1 週間以内に完了する必要があります。工数を判断するもう 1 つの方法は、上記の 8/80 ルールを使用することです。

要素の詳細度を決定する際に考慮すべきその他の要素は以下の通りです。

  • チームの経験が浅く、より綿密な監督が必要な場合は、作業パッケージを小規模にして期間を短くします。
  • 完了までに長時間を要する、あるいはコストが予算を上回る成果物がある場合は、プロジェクトを分解して作業時間が短い小規模な成果物にします。レポート作成とレビューの頻度を上げることで、問題をより早く発見し、解決に導くことができます。

最後に、プロジェクトを進める際は、以下の重要な原則を考慮してください。

  • プロジェクトの開始時に割り当てを行いますが、プロジェクトの進行中に必要に応じて新しい割り当てを作成できるようにします。
  • すべての成果物が標準に準拠していることを確認します。
  • 構造が完全に対称でなくても、またはバランスが取れていなくても、心配する必要はありません。多くのタスクや成果物では、他のものよりも詳細な情報が把握できます。
  • タスクを順番に列挙しないようにします。

不明な成果物がある場合は、現在判明している情報をできるだけ入力し、詳細が判明したらドキュメントを更新します。

作業分解構成図の作成

 

IC team work together-c

作業分解構成図を作成する最初のステップは、チームをまとめることです。チーム全員がオンサイトで作業しているか、リモートで作業しているかに関係なく、サブ成果物の特定にメンバーを参加させることが重要です。Rod Baxter 氏はこのように述べています。「チーム内に対象分野の専門家 (SME) がいなければ、作業分解構成図は作成できません。事態を本当に理解している人材が、チームには必要なのです」。SME は、WBS に必要なすべてのタスクをリスト化し、完成したチャート内の重複している責任やギャップを特定するのに役立ちます。

WBS の作成を始めるには、プロジェクト憲章、プロジェクトの問題記述書またはスコープ定義文書、該当するすべての契約文書と合意文書、および自分の組織における既存のプロジェクト管理実践プロセスなど、重要なドキュメントをまとめる必要があります。

効果的な作業分解構成図を作成するには、以下の各要素または構成要素を含める必要があります。

  • プロジェクトのビジョン ステートメント
  • プロジェクトの規模に応じて定義されたプロジェクト フェーズ
  • 成果物を含むタスクのリスト

土木技術者およびプロジェクト マネージャーとして活動し、4 冊の本の著者でもあるラリー・ベネット博士 (Dr. Larry Bennett) は、チームが作業分解構成図を作成することによるメリットが少なくとも 2 つあると考えています。「さまざまな視点から大量のインプットが得られる可能性があり、参加することでオーナーシップが生まれます」。 

情報を捕捉するためのツールは、成果物や関連部分を書き留めるために使用する、名刺サイズのカードや付箋のような単純なものでかまいません。そうすることでホワイトボード、コルク ボード、さらには壁に貼ることができます。仮想チームの場合は、共同作業に適したホワイトボード ソフトウェアを通じて同様のアクティビティを実行できます。

WBS の作成を始めるには、プロジェクトの主要成果物であるレベル 1 を定義します。次に、レベル 2 に詳細をできるだけ多く追加してから、必要に応じてレベル 3 以降の小規模な作業に移ります。次のレベルに進む前に、必ず前のレベルで何が必要かをできるだけ詳細に定義してください。

WBS の作成方法: 大枠のビュー

作業分解構成図の詳細を深く掘り下げる前に、しっかりとした大枠を作り上げることが重要です。まず、以下の重要な準備ステップを実行します。

  1. プロジェクト ステートメントを決定し、記述する
  2. プロジェクトで必要となるすべてのフェーズを強調する
  3. 成果物を策定して列挙する (成功の測定方法も含む)
  4. 成果物を管理可能なタスクに分割する
  5. 各セクションを割り当て、それぞれの所有者に納品能力があることを確認する

WBS と、リンク可能な情報を作成するためのツール

インデックス カード、またはペンと紙で WBS を作成することもできますが、電子テンプレートや電子ツールを使用すると、チャートの記録、編集、およびチーム メンバーへの配布が容易になります。その後、ドキュメント管理設定を使用して保存することで、変更管理プロセスを通じて更新を記録できます。

テンプレートを使用すると作業が簡単になります。チームや会社がすでにテンプレートを使用している可能性もありますが、そうでない場合は独自の WBS を作成するか、テンプレートを Web からダウンロードしてカスタマイズします。テンプレートには、以下の便利な機能が備わっています。

  • WBS コードのフィールド
  • 構成要素ラベルのフィールド
  • 会社ロゴのブロック
  • チーム名を記載するスペース
  • プロジェクト マネージャーの名前を記載するセクション

通常は以下の情報を WBS 内の各要素にリンクさせ、WBS をチームにとってさらに有用で、動的で、共有しやすいものにします。

  • WBS 番号: プロセス内の各構成要素またはステップに割り当てられたアウトラインもしくはインデックス番号です。たとえば、「1」という番号を振ったセクションでは、プロジェクトのそのセクションまたはフェーズに続くタスクと成果物に「1.1」や「1.2」といった番号が割り振られます。
  • 各要素のタイトル: 各マイルストーンまたは成果物の合意済みの略称であり、整理された上で WBS に記載されます。
  • 定義: 人目を引く短いラベルは、関係者にとって意味がわかりにくければ意味がありません。そのため、それぞれの名称の意味をできるだけ簡潔に説明することが重要です。たとえば、「プロジェクトの終了」の意味を明確にする必要があるかもしれません。それは最終請求書の支払いが行われたことを意味するのでしょうか?最終プロジェクトが、補足情報と併せて納品されたということでしょうか?タイトルの意味を理解していない人がいると想定される場合、または WBS ごとにタイトルを調整する場合は、定義を明記しましょう。
  • 関係者の名前と役割: 各関係者の名前を列挙し、役割 (例: 参加者、責任者、最新情報を共有すべき人、承認を得るべき人) を指定します。
  • アクティビティとタスク: 各マイルストーンを完了させるために必要なステップと、そのマイルストーンを割り当てられている人 (特に、コア チーム以外の貢献者が含まれている場合) を明記します。
  • 「完了」の定義: 各タスクとマイルストーンの完了要件を説明します。完成像、含むべき内容、確認すべき人、および今後のステップを明記しましょう。
  • 成果物の形式: 成果物がどのようなものになるかを説明しています。たとえば、電子的手段で提供される約 10 ページの Word ドキュメント、または電子メールによって、もしくは共有ドキュメントとして納品される PDF ないし UX テンプレートなどとなります。
  • 依存関係またはリスク: 各マイルストーンの納品に影響を与える可能性があるすべてのリスクと依存関係を記載しています。内部リスク (例: クライアントが追加のレビューを求める) の場合もあれば、外部リスク (例: 停電が発生し、特定の構成要素の納品に影響が及ぶ) の場合もあります。
  • 推定予算: ここでは、関連するすべての要求、人員配置のコスト、ハードウェアおよびソフトウェア リソース、およびその他の要素を考慮する必要があります。
  • プロジェクトのフェーズまたはライフサイクル: これは任意ですが、長期のプロジェクトや複雑なプロジェクトの場合に役立ちます。特定の成果物について、プロジェクト内の他のコンポーネントやマイルストーンには必要のないフェーズまたはライフサイクルを詳細に構築できます。

最も有用な WBS を作成するためのヒントとベスト プラクティス

作業分解構成図には柔軟性があり、各プロジェクトに合わせて調整することができます。または、そのような作業分解構成図を作成する必要があります。最も有用な WBS を作成する際に役立つ、プロジェクト マネージャーと組織向けのヒントを以下に紹介します。

  1. プロジェクトに関与するさまざまな部門間のブレインストーミング セッションを実施する。
  2. 必要に応じ、プロジェクト チームがホワイトボード、メモ カード、付箋などの原始的なツールを使用して、主要な成果物、サブ成果物、および特定の作業パッケージを識別できるようにする。
  3. マインド マッピングとブレインストーミングのサポート ツールを活用する。
  4. WBS 辞書内でそれぞれの WBS 要素を説明するにあたり、標準的な構造を採用して一貫性を維持する。
  5. 詳細の量を調整する。提示する際の詳細度は、階層の上位にある WBS 要素に対しては低く、下位レベルの要素に対してはより詳細にする必要があります。
  6. 頻繁にレビューを実施する。WBS は有機的なドキュメントなので、その内容を頻繁に見直し、それに応じて調整を加え、プロジェクトのパフォーマンスと納品を適正化する必要があります。
  7. ドキュメント化とレビューのサイクル、それに要する時間、およびプロジェクト開始時のトレーニングと終了時のテストを必ず記載する。
  8. プロジェクト計画の作成を含む、プロジェクト管理の成果物を記載する。顧客または外部関係者が満たす必要のある、または納品する必要のある成果物を明確にする。また、WBS に含める必要があるアクティビティについては、プロジェクト憲章に記載されているプロジェクト アプローチを確認する。

効果的な作業分解構成図の特徴

効果的な作業分解構成図は、一夜で、あるいは 1 人の人間によって作成できるものではありません。WBS の効果を最大にするには、次の条件を満たしている必要があります。

  • すべての成果物とマイルストーンを含め、プロジェクトの作成と提供に関連するあらゆる内容が詳しく説明されている。
  • プロジェクト マネージャーや、プロジェクトに直接関与するその他の関係者によって作成されており、たとえば「上から」、またはクライアントからプロジェクト マネージャーに提供されたものではない。こうすることで、責任者は自分たちが行うことを具体的に説明するとともに、それによって何がどのように提供されるかについて、完全に受け入れることができます。
  • すべての情報が視覚的手段で表現されており、概念の把握と整理が容易です。
  • 生きたドキュメント。依存関係やリスクはタイムライン、スコープ、またはその両方に影響を与える可能性があるため、WBS を必要に応じて適応および変更しつつ、プロジェクトの「指針」として機能する有機的なガイドとして扱う必要があります。
  • あらゆる形式やプラットフォームに適応でき、チーム メンバーがどこにいても、あらゆるデバイスからすぐにアクセスして対応することができる。

 

Work Breakdown Structure Dictionary Template

作業分解構成図辞書テンプレートをダウンロード

WBS 辞書: 前進する上で重要となる用語と手順

WBS 構成図、または WBS 辞書は流動的なドキュメントですが、常に特定の情報が含まれています。綿密で信頼性の高い WBS 辞書の要素を以下に示します。各フェーズで展開される要素は、必要に応じて移動または調整できます。ここではソフトウェア開発に関する一例を示しますが、このプロジェクトは単にソフトウェアの作成フェーズとテスト フェーズに関するものではないことに注意してください。

  1. プロジェクトのタイトル
  2. 開始
  3. プロジェクト憲章の策定
    A - 成果物: プロジェクト憲章の提出
    B - プロジェクト スポンサーによるプロジェクト憲章のレビュー
    C - プロジェクト憲章の署名と承認
  4. 計画立案
    A - 予備的なスコープ記述書の作成
    B - プロジェクト チームの決定
    C - プロジェクト チームによるキックオフ ミーティング
  5. プロジェクト計画
    A - プロジェクト計画の作成
    B - プロジェクト計画の提出
    C - マイルストーン: プロジェクト計画の承認
  6. 実行
    A - プロジェクト キックオフ ミーティング
    B - ユーザー要件の確認と検証
    C - システムの設計
    D - ハードウェアとソフトウェアの調達
    E - 開発システムのインストール
  7. テスト段階
    A - 本番用システムのインストール
    B - ユーザー トレーニングの実施
  8. 稼働開始
  9. 管理
  10. プロジェクト管理
    A - プロジェクト ステータス ミーティング
    B - プロジェクト管理計画の更新
    C - リスク管理
  11. 終了
  12. 調達の監査
  13. 教訓のドキュメント化
  14. ファイルと記録の更新
  15. フォーマットの承認の取得
  16. ファイルとすべてのドキュメントのアーカイブ

辞書の追加項目:

  • 完了日: WBS の成果物が引き渡された日付。
  • 納品のステータス: これは、プロジェクト内の個々の成果物やマイルストーンに適用することも、プロジェクト全体の成果物のステータスを反映させることもできます。
  • 依存関係とリスク: 成果物の完成に影響を及ぼす依存関係について説明します。
  • 完了予定日: 妥当だと考えられる作業の完了日。
  • 問題ログ: 現在成果物に影響を及ぼしている問題のリスト (受動的関与)。
  • 現時点の完了率: 特定の日付における成果物の完成状況をパーセントで表したもの。例: 2020 年 12 月 14 日時点で 20 パーセント。
  • 進捗コメント: 毎日/毎週の進捗状況を記録できる備考欄。
  • 責任者: 成果物を完成させる責任を負う人物。これは必ずしも作業を行っている個人またはチームではなく、機能マネージャーである場合があります。
  • リスク ログ: 成果物や計画の代替案に悪影響を及ぼす可能性がある要素または要因のリスト (積極的関与)。
  • 開始日: プロジェクトの開始日を指定します。これは作業範囲の署名日である場合もあれば、プロジェクト憲章の作成や正式な作業開始など、その他の「開始日」である場合もあります。

Microsoft Project による WBS の作成方法

  1. Microsoft Project で、主要成果物の名称を [タスク名] フィールドに入力します。
  2. サブ成果物のリストを [タスク名] フィールドに入力します。サブ成果物をインデントするには、Project の前向き矢印キーを使用します。
  3. 作業パッケージのレベルに達するまで、リスト アイテムの追加とインデントを続けます。
  4. Microsoft Project では、各タスク/アクティビティのアウトライン構造に基づいて、WBS コードが自動的に追加されます。ただし、[プロジェクト] タブをクリックし、メニュー バーで [WBS] を選択して [コードの定義] をクリックすることにより、特定のコードを作成できます。

 

プロジェクト管理の作業分解構成図をマスターする: 専門家のヒント

To-Do リストを避け、作業パッケージを管理可能、測定可能、成果物指向にしたいと考えている新任のプログラム マネージャーや作業分解構成図の新規ユーザーは、どのようにすればそれを実現できるでしょうか?

 

IC Michelle Watkins-c1

Michelle Watkins, a solutions consultant for Smartsheet, has over 20 years’ experience in project management. “Start with templates,” she suggests. “Something with a baseline, and make your adjustments from there.”

 

IC Rod Baxter-c1

Rod Baxter says, “You just keep practicing.” According to Baxter, a good project manager needs training and skill in risk management, communications management, and work breakdown structure. Project managers can gain confidence through mentoring newbies as they work their way through the ranks from such positions as project analyst to associate program manager.

 

IC Larry Bennett-c1

Dr. Bennett echoes this notion that practice is the key to mastering work breakdown structures.

“How does one develop confidence in any new endeavor?” he asks. “There are no magic formulae. But confidence is built through a combination of study, getting close to those who are using the method successfully, watching, asking questions, doing it oneself, soliciting feedback, learning from that feedback, and doing it again.”

Bennett says the best way to learn is probably from finding out where and how the WBS was used to create a good result. This type of information probably isn’t in scholarly publications. “Look for ‘real world’ practitioners who discuss their experience at professional meetings,” he says.

プロジェクト管理に Smartsheet を活用して作業分解構成図を改善する

ニーズに合わせ変化に対応できるようデザインされた、柔軟性のあるプラットフォームで、チームの能力を最大限に引き出しましょう。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。

 

シンプルで使いやすいプラットフォームで、従業員、プロセス、ツールをつなげましょう。

Smartsheet を無料で試す Get a Free Smartsheet Demo