プロジェクト管理における作業分解構造（WBS）：完全ガイド

私は初めて新しいプロジェクトを割り当てられて、「ただ分解してください」と言われたことを今でも覚えています。 構造もツールもなく、ただ山積みのプロジェクトタスクと、差し迫っている期限があるだけでした。

これは数年前のことです。 それ以来、私は大規模なプロジェクトから複雑なプロジェクトまで管理してきました。 そして、私のワークフローに最も大きな影響を与えたのは、作業分解構造を正しく使いこなす方法を学んだことです。 

このガイドでは、作業分解構造の概要、それが非常に有用である理由、プロジェクトチーム向けに作成する方法についてご説明します。 また、弊社の既製のテンプレートを使ってWBSプロセスを迅速に開始する方法もお教えします。

長すぎるという方のために、 主なポイントを挙げておきます。

主なポイント：

• 作業分解構造（WBS）では、大規模なプロジェクトを小分けにするので、それぞれの計画と管理を効果的に行うことができます。
• 優れたWBSがあれば、プロジェクトの成果物の定義、作業の割り当て、進捗の追跡、ステップの見落としの回避が容易になります。
• WBSには主に、成果物ベースとフェーズベースという2つのタイプがあり、それぞれ適しているプロジェクトのスタイルや目標が異なります。
• プロジェクト範囲の設定に始まり、作業の分解、所有権の割り当てなど、6つのステップでWBSを作成できます。
• WBS辞書は、各タスクまたはパッケージに詳細を追加したもので、内容や期待事項に関して混乱が生じないようにします。
• Wrikeはすぐに使えるテンプレートをご提供しており、プロジェクトのニーズに合わせてカスタマイズできます。

目次

• 作業分解構造（WBS）とは？ 
• プロジェクト管理においてWBSが重要である理由とは？
• 作業分解構造の主要要素とは？
• WBSのレベルとは？
• 6ステップで作業分解構造を作成する方法とは？
• 作業分解構造のタイプ
• 作業分解構造の形式
• 作業分解構造の例
• 作業分解構造のベストプラクティス
• WBSをスキップすべきタイミング
• プロジェクトマネージャーに最適なWBSソフトウェアとツール
• 作業が流れるツールで作業分解構造を作成する

作業分解構造（WBS）とは？

作業分解構造は、プロジェクトやタスクを視覚的に表現したものです。 一般的に、大きなタスクを明確で管理しやすい構成要素に分割する方法です。 これを使用して、家の改装や、製品の発売、複数の重要なフェーズがあるタスクなどを計画することがあるかもしれません。

しかし、プロジェクト管理においては、作業分解構造はプロジェクトの完了に必要なすべての作業を整理するのに役立ちます。 プロジェクトマネジメント協会のプロジェクトマネジメント知識体系ガイド （PMBOK）では、 WBSが「プロジェクトチームがプロジェクト目標の達成と必要な成果物の構築を目的として実行する作業を細分化した、成果物重視の階層構造」と定義されています。

プロジェクト管理においてWBSが重要である理由とは？

私はプロジェクトに十分に取り組んできたので、構造がないと混乱が生じることは承知しています。 プロジェクト管理において作業分解構造は次のように役立ちます。  

プロジェクトチームに対してタスクを明示する

構造がないと、人は簡単に迷ってしまいます。 分割構造は責任を早期に割り当てるのに役立ちます。 プロジェクトチームのメンバーはいつ何をすべきかを把握できます。 これにより、後で重複作業や不必要な確認が発生することはありません。

プロジェクトの範囲を定義する

つい油断すると、大きなマイルストーンだけに焦点を当てて小さなステップを忘れがちになります。 WBSでは、ジョブの主要コンポーネントが明示され、プロジェクト作業のすべての部分が確実に説明されます。 

各段階の成果物を管理する

適切な構造が整っていれば、大きな目標を小さな成果物に分解できます。 これにより、プロジェクトの進捗を監視し、早期に遅れを察知することが容易になります。 

プロジェクトの範囲、スケジュール、コストを調整する  

作業分解構造（WBS）は、プロジェクト管理文書の中でも最も重要なものの一つです。WBSの主な利点は、計画プロセスをサポートできることです。 WBSを利用すれば、範囲、コスト、スケジュールのベースラインを統合し、プロジェクト計画を確実に整合させることができます。 そのため、プロジェクトマネージャーは各フェーズに必要な資金を把握し、プロジェクトの総予算を計画することができます。

プロジェクト範囲が変わり始める時点を掌握する

変化は避けられません。 しかし、プロジェクトの範囲をすでに定義しており、それを構造化された作業パッケージに結び付けていれば、新しいリクエストがプロジェクト計画に適合しているのか、あるいは混乱を引き起こすものなのかが簡単に分かります。

作業分解構造の主要要素とは？

作業分解構成の良し悪しは、それを構成する各要素の質に左右されます。 したがって次のWBS要素を検討する必要があります。

プロジェクトの成果物

何を生み出そうとしているのか分からなければ、それを分解することはできません。 だからこそ、すべてのWBSはプロジェクトの成果物から始まるのです。 たとえば、新しいモバイルアプリのようなソフトウェア開発プロジェクトを提供している場合、二次的な成果物として以下が考えられます。

• アプリ
• ユーザーマニュアル
• ウェブサイトの立ち上げ
• テストレポート

想定される最終結果に関して混乱が生じないように、それぞれを明確にリスト化する必要があります。 主要成果物が確定したら、それらを管理しやすい要素に分割していくことができます。

タスクグループ

成果物を確定したところで、次のステップとして、各成果物の下で、関連するプロジェクト作業をグループ化します。 これにより、業務の構造が明確になり、目的のないタスクが放置されることはありません。 モバイルアプリの例をもう一度見てみましょう。 成果物「ウェブサイトの立ち上げ」において、次のような作業をグループ化している可能性があります。

• 設計
• コピーライティング
• テスト
• デプロイメント

私はいつもこの方法でWBSを整理していますが、それは全てがプロジェクト範囲に関連付けられて維持されるからです。

作業パッケージ 

グループ化された作業が明確になったら、それをさらに、作業パッケージと呼ばれる要素まで分解することができます。 この構造において、これは、他の人に渡して「これを担当してください」と確信を持って言える最小の単位です。 WBSの作業パッケージは、見積もり、スケジュール策定、分担が可能となるよう、内容が詳細に記述されている必要があります。 チームでガントチャートツールのようなプロジェクト管理ツールを使用している場合、作業パッケージは計画やスケジュールの策定に最適なサイズです。

タスクオーナー

親タスクや作業パッケージにはそれぞれオーナーが必要です。 タスクオーナーは必ずしも自ら作業をする必要はありませんが、作業の完了を保証する責任を負うべきです。 私の経験では、チームにおける最も一般的な問題の一つは責任者不明です。 この頭痛の種は、タスクオーナーを早い段階で追加しておくことで完璧に回避できます。

WBS辞書

WBS辞書では、WBSの各要素の名称、説明、割り当られたリソース、推定所要期間、コミュニケーションなどが説明されています。 プロジェクトマネジメント協会は次のように述べています。「コミュニケーションの簡易性と精度を確保するために、WBS全体で、そして理想的には1つの組織で実施されるすべてのプロジェクトにおいて、用語の定義が一貫していなければなりません。」

コントロールアカウント

コントロールアカウントとは、プロジェクトの実行中に追跡された作業パッケージ群と成果物群を表します。 私が働いてきたチームの大半において、予算追跡が早い段階で構造に組み込まれていないと、悪夢と化す可能性がありました。 すべての項目を一つ一つ追跡する必要はありません。 

コントロールアカウントは適切な可視性を提供します。 コストが上昇しているときや、特定のエリアが遅れているときに気づきやすくなります。 Wrikeの予算トラッカーを使用すれば、コストを見積もり、超過を回避できます。

WBSのレベルとは？

各作業分解構造には4つのレベルがあります。 これらのレベルは、広範なプロジェクト計画から具体的で実行可能なタスクに移行する際に役立ちます。 以下は様々なWBSレベルです。

レベル1：プロジェクト目標

これは目指している最終結果です。 「新しい会社のウェブサイト」、「モバイルアプリの発売」、「Q3の製品展開」のようなものがあります。 プロジェクト計画の全体的な方向性を定めた要約で、1行にまとめます。 

レベル2：主要成果物

ここでは、プロジェクト目標を実現可能にする主要な成果物を明確にします。 これらは、作業の中の広範囲で影響力の高い部分です。 たとえば、プロジェクト目標がブランドキャンペーンの立ち上げである場合、レベル2には以下が含まれる可能性があります。

• デジタル広告
• PRとメディアのアウトリーチ
• ソーシャルメディアのコンテンツ
• キャンペーンのレポートと分析

それぞれが業務の大きな塊を表しています。 

レベル3：二次成果物

次に、各主要成果物が二次-成果物に分解されます。 「デジタル広告」を例にとりましょう。 二次-成果物には以下が含まれる可能性があります。

• 有料検索広告
• ディスプレイバナー
• ランディングページ
• A/Bテストセットアップ

それぞれがその上にある大きな部分を支えています。  

レベル4：作業パッケージ

先ほど説明したように、作業パッケージはWBSの最下位レベルです。 たとえば、「ランディングページ」の下に作業パッケージを作成する場合、以下を含めることができます。

• ランディングページのコピーを書く
• モバイル版とデスクトップ版のレイアウトをデザインする
• フォーム追跡を設定する
• 公開してQAを行う

各作業パッケージには1つのアウトプットがあります。 それは十分に具体的で、さらなる分解を要することなく誰かに引き渡すことができるものです。

6ステップで作業分解構造を作成する方法

優れた作業分解構造は、ステップとガイドラインに従って反復的なプロセスを使用して作成されます。 私がゼロから作業分解構造を構築するときに使用するステップバイステップのアプローチを以下に示します。

ステップ1：範囲明示書を書く

ツールを開いたりタスクをリストアップする前に、なぜこれを行っているのか、 最終結果は何の達成を意味するのかと自問してください。 この時点で範囲明示書を書きます。 

私が行ったあるプロジェクトでは、書かれた範囲がプロジェクト成果物に合致していませんでした。 しかし、利害関係者との簡単なチャットの後で、彼らが望んでいたものが異なっていることがわかりました。 これによって、WBSに盛り込まれる内容が完全に変わったのです。

そこで私は、何よりも先に、該当する人員に短い電話（15〜20分程度）をかけて次の3つのことを尋ねました。

1. 最終的にどのような成果を期待しているのか？
2. 「このプロジェクトは成功だ」と言える根拠となるのは、どのようなことか？
3. 厳密に範囲外となるのはどのようなことか？

大規模なチームで作業を行う場合、プロジェクト憲章や正式な承認プロセスを活用することで、物事を確実に進めることができます。 

ステップ2：成果物をリストアップする 

範囲を把握したので、すべてのプロジェクト成果物をリストアップしましょう。 この部分は急いで実行されることが多いのですが、このリストアップで将来の問題を回避できます。 ホワイトボード（またはデジタルボード）の周りにチームを集め、プロジェクト終了時に得られると想定している成果物を、一人ひとりに声に出して言ってもらいます。 判断や議論はしないですべてを書き留めます。 それから、それぞれについて次のように自問します。

• これは結果？それとも単なる活動？
• 承認者となるのは誰？
• 測定、レビュー、または引き継ぎは可能？

このテストに合格しないものはすべて、破棄されるか、見直されます。

ステップ3：成果物を階層状に整理する

ここで作業分解構造プロセスを開始します。 私はそれぞれの成果物について、「これを最初から最後までまでどう進めればよいのか？」と自問します。細かいタスクから始めるわけではありません。 二次成果物から取り掛かります。 プロジェクトの成果物の1つが「キャンペーン立ち上げ用コンテンツパック」だとしましょう。 私は自問します。

• どのようなコンテンツが含まれている？
• それらの準備が整うまでに何が必要？
• それらを誰がレビューする？

ここから、次のような二次成果物が得られる可能性があります。

• 立ち上げ用コピーデッキ
• 有料メディアアセット
• メールマーケティングのテンプレート

この書式はツリー形式でもアウトライン形式でも構いません。 今は、完璧で明確な内訳を得ることに集中してください。

ステップ4：各二次成果物を作業パッケージに変換する

これがプロジェクト計画が実行可能なものになるポイントです。 各二次成果物が作業パッケージに分解されます。 ここで私が必ず守っているのは、「各作業パッケージは、1人（または少人数のチーム）に割り当てられるほど小規模であると同時に、意味を持つほど十分な大きさの規模であるべき」というルールです。 

たとえば、Syneos Health社のチームは、世界中のチームにまたがる数千のプロジェクトを扱い、毎日200件以上のタスクを処理していました。 彼らの転機は、さまざまなツールの寄せ集めからWrikeへの移行したときだったのです。

ステップ5：WBS辞典を作成する

作業パッケージが定義されたら、ドキュメントを追加する時です。 ここで私はWBS辞典を作成しています。 WBS辞典には、チャート上ではわからない小さなことをすべて含めます。 例えば次のような内容です。

• クライアントからのメモ
• リファレンス仕様またはブランド付けガイドライン
• 主要な意思決定者
• 関連ファイルリンク

作業分解構造の各要素は辞書に短い項目として記載します。 これにより、新しいプロジェクト参加者に責任を割り当てて、親タスクをすぐに理解してもらうことができます。 

ステップ6：視覚的なレイアウトを構築する 

最終ステップでは、構築したすべてのものをWBSチャートに変換します。 最終目標を頂点に配置し、そこから成果物、二次成果物、作業パッケージに分岐していくツリー型の図を作成します。 私は通常、オーナー別、フェーズ別、またはプロジェクトタイムライン別に色分けをします。 そのようにすれば、チーム外の人でもプロジェクト範囲を見て理解することができます。 

Wrikeを使用している場合は、組み込みの作業内訳構造テンプレートを使用すると、作成作業を迅速に進めることができます。 WrikeとKlaxoonのコラボレーションによりダッシュボードを作成できるようになりました。これにより、構造のマッピング、ワークショップの主導、チームの整合、同一認識の全員での共有が容易になります。 この簡単な方法を使えば、構造を誰もが実行できる形に変えることができます。

読むよりも見たいですか？ こちらのステップバイステップの動画チュートリアルでも、プロジェクト管理におけるWBSの作成方法をご紹介しております。

作業分解構造のタイプ

私がWBSを構築する際にまず行うのは、使用する構造のタイプを選ぶことです。 WBSは通常、成果物ベースとフェーズベースの2種類から選びます。 

どちらもうまく機能しますが、チームの運用方法によっては目的が異なります。

成果物ベースのWBS

成果物ベースのWBSでは、階層の最上位に成果物が配置されます。 この構造は、最終生成物が明確で独特であるプロジェクトに最適です。 

納品物ベースのWBSは、実行の時間や順序に関係なく行う必要がある作業に焦点を当てています。 つまり、ガントチャートでスケジュールを組む際に余分な作業が必要になるということです。

より明確にイメージできるように、以下の表にこの構造の主要要素を示します。

フェーズベースのWBS

フェーズベースのWBSの特徴は、階層の最上位にプロジェクトフェーズが配置される点です。 各フェーズは、そのステージを完了するために必要な作業パッケージに分解されます。 ソフトウェア開発や建設のような、ステージが明確に定義されているプロジェクトに最適です。 この構造から直接ガントチャートを構築できます。 時間別、ステージ別、またはチーム別に進捗を追跡するのに役立ちます。 また、コストをより細かい区分ごとに見積もるのも容易です。

以下は、この構造が一般的にどのように構成されているかを示した表です。

作業分解構造の形式

作業分解構造がプロジェクトごとに異なる場合があります。 プロジェクトマネージャーとして、どのタイプのWBSチャートが自身とチームに最適かを実験してみる必要があります。 目標は、プロジェクトを視覚的な階層で示すことです。

作業分解構造の形式の一部を例として以下に示します。

• WBSスプレッドシート：スプレッドシートを使えば、WBSを効率的に構築できます。プロジェクトのさまざまなフェーズ、タスク、成果物を列と行に記載します。 WBSスプレッドシートの作成・管理にMicrosoft Excelのようなツールを使用できます。
• WBSフローチャート：図式のワークフローでWBSを構成することができます。 プロジェクト管理における作業分解構造のほとんどのテンプレートや例はフローチャートで、多くの場合はツリー構造です。
• WBSリスト：WBSをタスクや成果物（サブタスクや二次成果物を含む）の単純なリストとして構成することができます。 これは最も単純なWBS作成アプローチです。
• WBSガントチャート：スプレッドシートとタイムラインの両方が示されるガントチャートとしてWBSを構成することができます。 たとえば、ウェブサイトのリニューアルのような新しいプロジェクトを開始する際に、WBSガントチャートを使えば、関係する様々なステージを概説し、タスクの依存関係をリンクさせ、プロジェクトのマイルストーンを示すことができます。

作業管理ソフトウェアツールは、Wrikeなど多数存在しており、プロジェクトの全フェーズに渡ってWBSの作成・管理に利用できます。

作業分解構造の例

作業分解構造の理論を理解することと、実際のプロジェクトでそれが具体的にどのように構成されているのを目の当たりにすることは、まったく別のことです。 こちらに、作業分解構造の一般的なレイアウトを示した単純な視覚的階層があります。 最上位の結果がフェーズや成果物に分解され、次に作業パッケージに、そして最終的に具体的な活動へと分解される様子を見ることができます。 この種のビューは、各レベルにおけるチームの状態を明確に示します。

次のプロジェクトのためにWBSを構築する必要がありますか？ ウェブ開発プロジェクトにおけるWBSプロジェクト管理の例を以下に示します。

1. 開始フェーズ
   • 作業範囲を定義する
   • プロジェクトの範囲明示書を書く
   • WBSプロジェクト計画を作成する
   • 役割と責任を割り当てる
   • プロジェクト憲章を作成する
2. 発見フェーズ
   • 市場調査を行う
   • 利害関係者から要求事項を集める
   • ユーザーペルソナとユーザーストーリーを定義する
   • 競合分析を行う
3. デザインフェーズ
   • ワイヤーフレームとプロトタイプを開発する
   • ビジュアルデザインコンセプトを作成する
   • フィードバックに基づいてデザインのレビューと改良を行う
4. 開発フェーズ
   • 開発環境を設定する
   • フロントエンドのレイアウトとUIコンポーネントを構築する
   • バックエンド機能を開発する
   • データベース構造を実装する
   • サードパーティのAPIやサービスを統合する
5. テストフェーズ
   • ユニットテストを実施する
   • 統合テストを行う
   • ユーザー受け入れテスト（UAT）を実施する
   • バグと問題を特定して修正する
6. デプロイメントフェーズ
   • デプロイメントの準備をする
   • ウェブサイトを本番環境に移行させる
   • ライブ環境で最終テストを実行する
   • ウェブサイトを一般公開する
7. メンテナンスフェーズ
   • ウェブサイトのパフォーマンスを監視する
   • ユーザーフィードバックとバグレポートに対処する
   • アップデートと改善を実施する
   • 定期的にバックアップとセキュリティチェックを実行する 

これはフェーズベースのWBSであり、タスクはプロジェクトライフサイクルのさまざまなステージやフェーズに応じて構成されています。 

Wrikeのようなツールを使用している場合については、同じ構造を直接ガントチャートツールにマッピングする方法を以下に示します。 各フェーズは、開始日、終了日、依存関係、オーナーと明確に結び付けられています。 これにより、タイムラインの管理、プランの調整、進捗の追跡が容易になります。

作業分解構造のベストプラクティス

長年にわたって多くのWBSを作成してきましたが、ここでは作成する際のベストプラクティスと避けるべき一般的なミスをいくつかご紹介します。 

WBSをスキップすべきタイミング 

私はしっかりとしたWBSが好きです。 それは、私が複雑なプロジェクトで使用した最も有用なツールの1つです。 しかし、それが必要にはならない場合があることも学びました。 あらゆるものに作業分解構造が必要というわけではなく、無理に使うと遅くなる場合があるのです。 プロジェクトが数ステップで構成され、すでに関係者全員が流れを理解している場合、正式なWBSは必要ないかもしれません。 短いタスクリストや共有されたドキュメントがあれば十分という場合もあるのです。

時間が限られている場合もあり、そんな時にはとにかく何かを仕上げて出すことだけが最優先となります。 そのような場合、WBSを作成する時間を作業の進行に充てる方がよいかもしれません。

プロジェクトマネージャーに最適なWBSソフトウェアとツール

次のプロジェクトのWBSを作成中ですか？ 役立つWBSツールと機能について、以下をぜひご参照ください。

ガントチャート 

視覚的なタイムラインに分解する必要がある場合はガントチャートツールが最適です。 タスクの依存関係を整理し、期間を追跡し、リアルタイムでスケジュールを調整するのに役立ちます。

カンバンボード

カンバンボードは、作業の流れの可視化を好むチームにとって、優れた代替案です。 作業パッケージがステージを移動するカードとして示されます。 この形式は更新が簡単で、アジャイルチームや、優先度が頻繁に変わるような環境に最適です。 また、ボトルネックを迅速に表面化するのにも役立ちます。

タスク管理

WBSソフトウェアは、主要な構成要素が二次成果物や作業パッケージに分解しやすくなるものを使用しましょう。 さまざまな業界に対応し、ドラッグ＆ドロップによる順序変更が可能な多階層タスク構造をサポートするプラットフォームを探してください。 タスクの引き渡しを自動化することもでき、1つのタスクが完了とマークされたら、すぐに次のタスクが開始され、手動でのフォローアップなしでワークフローが進行します。

ダッシュボード

内蔵されているレポート機能（ダッシュボードなど）を使えば、作業の進行状況や遅延が発生している箇所、構造内でさらなる注意が必要と思われる部分を確認することができます。 ダッシュボードを利用すると、完了率と作業負荷と期限に関する高レベルの洞察が得られます。

リソース配分

リソース配分機能を備えたWBSソフトウェアは、チーム全体の作業負荷をバランスよく調整します。 これは燃え尽き症候群と期限超過の予防に役立ちます。

コラボレーション

最新のWBSツールを使えば、チームメンバーによる構造内での直接的なコラボレーションが容易になります。 具体的には、コメントの書き込み、タスクのリアルタイム更新、インプットを目的とした人員へのタグ付け、進展に合わせた優先度の調整が可能です。

作業が流れるツールで作業分解構造を作成する

ここまで、しっかりとした作業分解構造によって、散漫なプロジェクトが整理されたものへとどのように変わるのかを見てきました。 チームが処理できるパッケージ単位に作業を分解し、構造を構築し、適切な成果物を定義する方法をご説明しました。 しかし、実際のところ構造化は全体の半分に過ぎません。 あと半分は実行です。 だからこそWrikeをぜひご利用いただきたいのです。 

Wrikeを使用すると、ワークフローに合わせたフォルダーとタスクを使用して、高レベルの成果物から詳細な作業パッケージまでの全体を可視化した階層を構築できます。 もっと詳しく知りたいですか？ オーナーの指名、期限の設定、依存関係の追跡、作業負荷の監視、これらすべてを1か所で実行できます。 ゼロから始める場合でも、Wrikeを使えば簡単です。 すでに使えるテンプレートがあれば、一から構造を築く必要はありません。 テンプレートは、プロジェクトに合わせたカスタマイズ、将来の作業への再利用、チーム間での拡張が可能です。