プロジェクトマネージャーが最もよく聞かれる質問は何でしょうか？おそらく、「このプロジェクトは具体的にどのような内容ですか？」「何人の人員が必要ですか？」「費用はいくらかかりますか？」といった質問でしょう。これらの質問に答える前に、まず最初にやるべきことが一つあります。それは、プロジェクトを明確に細分化することです。
プロジェクトを明確に細分化できないと、不正確な見積もりをしてしまい、不正確な見積もりは管理の失敗につながります。ワークブレークダウンストラクチャ（WBS）は、プロジェクトを明確に細分化するための主要なツールです。
新任のプロジェクトマネージャーであろうと、大規模プロジェクトを率いてきたベテランプロジェクトマネージャーであろうと、ワークブレークダウンストラクチャ（WBS）は避けて通れない必須スキルです。今回は、WBSの概念や手順から、WBSとガントチャートの違い、そしてチャート作成ツールを使った作成方法まで、すべてを分かりやすく解説します。
WBS（ワークブレークダウンストラクチャ）とは、プロジェクトの成果物を、それ以上分割できなくなるまで、論理的に階層ごとに分解していくことを指します。
簡単に言うと、WBSは大規模なプロジェクトをいくつかの小さなモジュールに分解し、さらにこれらの小さなモジュールをより小さな作業パッケージに分解していくことで、各作業パッケージを特定の担当者に明確に割り当て、その時間とコストを見積もることができるようにする手法です。
WBSの3つの主要な特徴：
成果物指向：WBSは「行動」ではなく「結果」を分解します。例えば、「ログイン機能の開発」は行動ですが、「ログイン機能モジュール」は成果物です。
100%原則：各レベルの作業内容は、次のレベルの作業内容を完全に網羅していなければならず、過不足があってはならない。ある作業が次のレベルに反映されていない場合は、分解に漏れがあることを示し、次のレベルの内容が前のレベルの範囲を超えている場合は、過剰分解を示している。
明確な階層構造：通常は、少なくとも「作業パッケージ」レベル（つまり、担当者に割り当てることができ、時間とコストを見積もることができる最小単位）まで細分化する必要があります。
ワークブレークダウンストラクチャ（WBS）を作成するプロセス自体が、プロジェクトに対する理解を徐々に深めていくプロセスです。標準的なWBS分解の6つのステップは以下のとおりです。
分析を始める前に、まず明確に答えておくべきことがあります。このプロジェクトは何をもたらすのか？その範囲はどこにあるのか？
必要な参照文書には、プロジェクト憲章、スコープ記述書、契約書が含まれます。スコープが不明確な場合、WBS分解において、項目の漏れや過剰な分解が生じる可能性があります。
プロジェクトの種類に基づいて、適切な分解次元を選択してください。
成果物ごとに分解する：例えば、ソフトウェア開発プロジェクトは、「フロントエンドモジュール」、「バックエンドモジュール」、「データベース」などに分解できます。
ライフサイクル段階ごとに細分化する。例えば、「計画段階」「設計段階」「建設段階」「承認段階」などだ。
業務を機能別に細分化する。例えば、「マーケティング部門の業務」、「研究開発部門の業務」、「オペレーション部門の業務」など。
ほとんどのプロジェクトでは、フェーズごとの分解と成果物ごとの分解など、複数の分解手法を組み合わせて使用します。
プロジェクトで作成する必要のある主要な成果物をすべてリストアップしてください。自問自答してみましょう。プロジェクト完了後、クライアントに納品する必要があるものは何ですか？社内でアーカイブする必要があるものは何ですか？
例えば、建設プロジェクトにおいては、設計図、基礎、主要構造、内装、検収報告書など。
最上位レベルから始めて、各成果物を段階的に洗練させていきましょう。洗練の各段階で、次のことを自問自答してください。「この成果物はどのような下位成果物で構成されているのか？」
分解作業はどのくらいの期間で完了とみなすべきでしょうか？ 基準として「80時間ルール」があります。作業パッケージの完了時間は、理想的には80時間（つまり2週間）以内に抑えるべきです。長すぎると管理が難しくなり、短すぎると過剰管理につながる可能性があります。
「100%原則」を使って、次の点を確認してください。次のレベルのコンテンツの合計は、前のレベルのコンテンツの合計と等しいか？漏れはないか？過剰はないか？
また、以下の点も確認してください。各作業パッケージに責任者を割り当てることができますか？時間とコストを見積もることができますか？内容は明確で理解しやすいですか？
各作業パッケージに固有のコード（例：1.1.1）を割り当て、その後のタスク追跡とコスト計算を容易にします。次に、WBSをプロジェクトチームと関係者に公開し、今後の作業の基準とします。
プロジェクト初心者の中には、WBSとガントチャートを混同しがちで、両者が同じものだと誤解している人も少なくありません。しかし実際には、これらはプロジェクト管理における相互に関連する2つのツールであり、それぞれに独自の役割があります。簡単に言えば、WBSは「何をすべきか？」という問いに答えるものであり、ガントチャートは「いつすべきか？」という問いに答えるものです。
ワークブレークダウンストラクチャ（WBS）の主要機能は、プロジェクトの成果物を階層的に分解することです。プロジェクトで作成する必要のあるすべての成果物と、それらの関係性をツリー図形式で表示します。例えば、ソフトウェア開発プロジェクトの場合、WBSにはフロントエンドモジュール、バックエンドモジュール、データベースなどが含まれており、フロントエンドモジュールにはホームページ、リストページ、詳細ページなどのサブ成果物が含まれることが示されます。WBSは時間的な要素を一切考慮せず、プロジェクトコンテンツの完全な分解のみに焦点を当てています。
一方、ガントチャートは全く異なります。その主な機能は、タスクのタイムラインと進捗状況を表示することです。水平棒グラフ形式を使用し、作業分解構造（WBS）から細分化された作業パッケージをタイムライン上に配置し、各タスクの開始、終了、所要時間、およびタスク間の依存関係（例えば、「フロントエンド開発はUIデザインが完了した後にのみ開始できる」など）を示します。ガントチャートの核心は時間管理です。
正しいワークフローは次のとおりです。
まず、プロジェクトを徹底的に分解するために作業分解構造 (WBS) を作成します → WBS に基づいて、各作業パッケージの時間とリソースを見積もります → ガントチャートを作成し、依存関係に基づいてプロジェクトのスケジュールを立てます。
作業分解構造（WBS）がない場合、ガントチャートを直接作成すると、特定のタスクが漏れたり、タスクの粒度が不均一になったりしやすく、計画が制御不能になる原因となる可能性があります。
ワークブレークダウンストラクチャ（WBS）を作成する際の鍵は、階層的な関係と包含ロジックを明確に示すことです。作成方法は以下のとおりです。
1. ProcessOnのプロフィールページを開き、 「新しいフローチャート」を選択します。
2. 長方形をキャンバスにドラッグして中心ノードとし、中心ノードにプロジェクト名（「ソフトウェア開発プロジェクト」など）を入力します。
要件調査、システム設計／開発、テスト／修正といった第1レベルのブランチを追加します。次に、各第1レベルのブランチの下に第2レベルのブランチを追加します。担当者、推定作業時間、受け入れ基準などの注記がある場合は、データ属性や注記を各ブランチに個別に追加できます。
3. ステージグラフを選択すると、上部のツールバーを使用して、色を使って異なるステージを区別したり、クリティカルパス上の作業パッケージをマークしたりできます。
4. WBS（作業分解構造）図の作成が完了したら、高解像度画像としてエクスポートしたり、共有リンクを設定して同僚や顧客と共有したりできます。
ProcessOnのテンプレートコミュニティでは、参考となるWBS（作業分解構造）テンプレートと例を豊富に提供しており、作図を容易にするためのコピー機能もサポートしています。以下に、共有されているテンプレートの一部をご紹介します。
プロジェクトマネジメントとは「管理する前に障壁を取り除くこと」だと言う人もいます。もしその障壁を取り除くことが明確でなければ、その後の計画、実行、監視はすべて空想に過ぎません。
ワークブレークダウンストラクチャ（WBS）は、プロジェクトをツリー図に分解するだけの単純な作業のように思えるかもしれませんが、それを適切に作成するのは決して容易ではありません。プロジェクトに対する深い理解、チームメンバーとの度重なる調整、そして分解プロセス中に予期せぬ詳細を継続的に発見していくことが求められます。しかし、まさにこのプロセスこそが、WBSの価値を「単なる図」以上のものにしているのです。WBSは、チームがプロジェクトについて合意に達するための出発点となり、その後のすべての管理活動の基盤となるのです。
無料のオンライン共同マインドマップフローチャート
