WBSのワークパッケージとは？アクティビティ・タスクとの違いや粒度、例をプロPMが解説

WBSのワークパッケージとは、プロジェクトで必要な作業を階層的に分解したときに、管理できる単位まで落とし込んだ最下層の要素です。プロジェクトマネジメントでは、ワークパッケージを適切に設計することで、工数見積もり、担当者設定、スケジュール管理、進捗確認がしやすくなります。

一方で、「ワークパッケージとアクティビティの違いがわからない」「タスクと同じ意味で使ってよいのか迷う」「WBSの粒度をどこまで細かくすればよいのかわからない」と感じる方も多いのではないでしょうか。

この記事では、WBSのワークパッケージの意味、PMBOKにおける位置づけ、アクティビティ・タスクとの違い、適切な粒度の考え方、Webサイト制作を例にした作り方を解説します。WBSを作成した経験がある方や、プロジェクト管理の実務精度を高めたい方に向けて、スケジュール管理表やRACIにつなげる手順まで整理します。

WBSのワークパッケージとは？PMBOKにおける位置づけを整理

WBSやワークパッケージを理解するには、まず「WBSのどこに位置づけられる要素なのか」を押さえることが重要です。

ワークパッケージは、単なる細かい作業名ではありません。WBS上で管理可能な単位まで分解された要素であり、工数、期間、担当者、完了条件を考える土台になります。

ワークパッケージはWBSで分解した最下層の管理単位

WBSとは、Work Breakdown Structureの略で、日本語では作業分解構成図と呼ばれます。プロジェクトの成果物や作業範囲を階層的に分解し、必要な作業を見える化するための考え方です。

ワークパッケージとは、WBSで分解した最下層の管理単位です。PMBOKの文脈では、コストや期間を見積もり、担当者を割り当て、進捗を管理できる単位として扱われます。

実務では、WBSの最下層を「タスク」と呼ぶこともあります。ただし、厳密にはワークパッケージはWBS上の管理単位であり、スケジュール上のアクティビティや、日々の作業としてのタスクとは役割が異なります。

たとえば、Webサイト制作プロジェクトで「問い合わせフォーム制作」というワークパッケージを設定した場合、その中には「フォーム項目を決める」「入力チェックを実装する」「送信テストを行う」といった具体的な作業が含まれます。

つまり、ワークパッケージは「どこまでを1つのまとまりとして管理するか」を決める単位です。粒度が粗すぎると進捗が見えにくくなり、細かすぎると管理負荷が高くなります。

WBSは作業を見える化し、スケジュール管理表の土台になる

WBSは、プロジェクトに必要な作業を見える化するための土台です。

プロジェクトを進める際、いきなりスケジュール管理表を作ろうとすると、タスクの抜け漏れや粒度のばらつきが起こりやすくなります。そこで、まずWBSを使ってプロジェクトの成果物や作業範囲を分解し、必要な作業を整理します。

WBSでワークパッケージまで分解できると、その後の管理がしやすくなります。各ワークパッケージについて、担当者、所要期間、前後関係、完了条件を整理すれば、スケジュール管理表やガントチャートに落とし込みやすくなります。

たとえば、「Webサイト制作」という大きな単位だけでは、いつ誰が何をするのかが見えません。しかし、「トップページ制作」「下層ページ制作」「問い合わせフォーム制作」「公開前テスト」のように分けると、担当者や期間を設定しやすくなります。

WBSは作って終わりではありません。ワークパッケージをもとに、スケジュール管理表、担当者設定、RACI、進捗確認へつなげてこそ、実務で使える管理資料になります。

ワークパッケージとアクティビティ・タスクの違い

WBSを使っていると、ワークパッケージ、アクティビティ、タスクという言葉が混在しやすくなります。

この3つは似ていますが、プロジェクトマネジメント上の位置づけが異なります。違いを理解しておくと、WBSからスケジュール管理表へ展開するときの混乱を防ぎやすくなります。

比較表で見るワークパッケージ・アクティビティ・タスクの違い

以下は、ワークパッケージ・アクティビティ・タスクの違いを整理した比較表です。まずは表でそれぞれの違いを整理しましょう。

	ワークパッケージ	アクティビティ	タスク
位置づけ	WBSの最下層の管理単位	ワークパッケージを実行するための作業単位	実務上の作業単位として幅広く使われる言葉
主な目的	スコープ・成果物・見積もり単位を明確にする	スケジュールに落とし込み、実行順序や所要期間を整理する	担当者が実行する具体的な作業を管理する
使われる場面	WBS作成、スコープ管理、見積もり	スケジュール作成、作業順序整理、進捗管理	日々の業務管理、チーム内の作業指示
例	問い合わせフォーム制作	フォーム項目を設計する、入力チェックを実装する、送信テストを行う	担当者がフォーム項目案を作成する
注意点	粒度が粗いと管理できない	細かすぎると管理負荷が増える	人や現場によって意味が変わりやすい

ワークパッケージは、WBS上で管理する単位です。

アクティビティは、ワークパッケージを実行するために必要な作業として、スケジュールへ落とし込む単位です。

タスクは、現場で幅広く使われる言葉です。

ワークパッケージをタスクと呼ぶこともあれば、アクティビティをタスクと呼ぶこともあります。そのため、プロジェクト内で用語の意味をそろえておくことが重要です。

ワークパッケージはWBS上の管理単位、アクティビティは実行手順

ワークパッケージとアクティビティの違いは、「管理する単位」と「実行するための作業」という視点で整理するとわかりやすくなります。

ワークパッケージは、WBS上で作業や成果物を管理するためのまとまりです。何を作るのか、どこまでを管理するのか、どの程度の工数や期間が必要なのかを考える単位です。

一方、アクティビティは、そのワークパッケージを完了させるために実行する作業です。スケジュールを作成するときには、ワークパッケージをさらにアクティビティへ展開し、作業順序や所要期間を整理することがあります。

たとえば、「問い合わせフォーム制作」というワークパッケージがある場合、アクティビティとしては「要件を確認する」「項目を設計する」「画面を実装する」「入力チェックを設定する」「送信テストを行う」などが考えられます。

ワークパッケージは「管理上のまとまり」、アクティビティは「実行上の作業」と考えると、違いを理解しやすくなります。

タスクは文脈によって意味が変わるため、本文内で定義をそろえる

タスクは、プロジェクトの現場で非常によく使われる言葉です。ただし、意味が広いため、文脈によって指している内容が変わります。

ある現場では、WBSの最下層をタスクと呼ぶことがあります。別の現場では、スケジュール表に登録された作業をタスクと呼ぶこともあります。また、担当者が今日対応する細かな作業をタスクと呼ぶ場合もあります。

そのため、「タスク」という言葉を使う場合は、プロジェクト内で何を指しているのかをそろえておくことが重要です。

たとえば、WBS上では「ワークパッケージ」、スケジュール上では「アクティビティ」、日々の作業管理では「タスク」と使い分けると、関係者間の認識ズレを減らしやすくなります。

もちろん、すべての現場で厳密に用語を分ける必要はありません。ただし、WBS、スケジュール管理表、課題管理表、RACIなど複数の管理資料を使うプロジェクトでは、用語の定義をそろえておく方が安全です。

用語が曖昧なまま進むと、「完了した」と言っている対象が、人によってワークパッケージなのか、アクティビティなのか、個別タスクなのかズレることがあります。これが進捗報告やスケジュール管理の混乱につながります。

ワークパッケージの例と適切な粒度の決め方

ワークパッケージを設計するときに難しいのが、粒度の決め方です。

粒度が粗すぎると見積もりや進捗管理が難しくなります。反対に、細かすぎると管理する項目が増えすぎて、WBSやスケジュール管理表が使いにくくなります。

ここでは、Webサイト制作プロジェクトを例に、ワークパッケージの考え方と適切な粒度の判断基準を整理します。

Webサイト制作プロジェクトにおけるワークパッケージ例

Webサイト制作プロジェクトを例にすると、WBSは次のように分解できます。

	項目例	位置づけ
レベル1	Webサイト制作	プロジェクト全体
レベル2	要件定義設計デザイン実装テスト公開準備	主要な作業領域
レベル3 （レベル2の「実装」を分解したタスク）	トップページ制作下層ページ制作問い合わせフォーム制作	ワークパッケージの候補
レベル4 （レベル3の「トップページ制作」を分解したタスク）	フォーム項目設計入力チェック実装送信テスト	アクティビティや個別タスクの候補

たとえば、「問い合わせフォーム制作」は、ワークパッケージとして扱いやすい単位です。成果物が明確で、担当者を設定しやすく、所要期間も見積もりやすいためです。

一方、「Webサイト制作」全体を1つのワークパッケージにすると、範囲が広すぎます。デザイン、実装、テスト、公開準備などが含まれてしまい、進捗管理が難しくなります。

ワークパッケージは、成果物や作業範囲が明確で、管理できる大きさに分解することが大切です。

WBSの8/80ルールとは？粒度を決める目安

ワークパッケージの粒度を考える目安として、8/80ルールがあります。

8/80ルールとは、1つのワークパッケージを、おおよそ8時間以上、80時間以内の作業量に収めるという考え方です。8時間未満では細かすぎ、80時間を超えると大きすぎる可能性がある、という目安として使われます。

ただし、8/80ルールは絶対的なルールではありません。プロジェクトの規模、業界、作業内容、チームの経験値によって、適切な粒度は変わります。

たとえば、大規模なシステム開発では、80時間を超える単位で見積もる場面もあります。反対に、短期間の小規模プロジェクトでは、より細かい単位で管理した方がよい場合もあります。

大切なのは、ワークパッケージが「見積もれる」「担当者を設定できる」「完了条件を決められる」「進捗を確認できる」単位になっているかどうかです。

8/80ルールは、粒度に迷ったときの判断材料として活用しましょう。

粒度が粗すぎるワークパッケージのNG例

粒度が粗すぎるワークパッケージは、管理しにくくなります。

たとえば、Webサイト制作プロジェクトで「サイト制作」というワークパッケージを設定した場合、範囲が広すぎます。デザイン、実装、原稿作成、テスト、公開準備など、さまざまな作業が含まれてしまいます。

この状態では、担当者を決めにくく、工数も見積もりにくくなります。進捗を「50％完了」と報告されても、何がどこまで終わっているのか判断できません。

粗すぎるワークパッケージでは、遅延の原因も見えにくくなります。デザインが遅れているのか、原稿が未確定なのか、実装に問題があるのかが把握しにくいためです。

NG例としては、以下のような単位が挙げられます。

• システム開発
• Webサイト制作
• 業務改善
• 社内研修実施
• AI導入

これらは、WBSの上位階層としては使えますが、ワークパッケージとしては大きすぎる場合が多いです。

粒度が細かすぎるワークパッケージのNG例

反対に、粒度が細かすぎるワークパッケージも問題です。

たとえば、「ボタン文言を1文字修正する」「会議URLを送る」「確認依頼メールを送信する」などをすべてワークパッケージとして扱うと、管理項目が増えすぎます。

細かすぎるワークパッケージは、更新負荷が高くなります。プロジェクトマネージャー（PM）やメンバーが管理表を更新するだけで時間を取られ、かえってプロジェクト運営が重くなることがあります。

また、細かい作業が増えすぎると、全体像が見えにくくなります。WBSは本来、プロジェクトのスコープや成果物を整理するためのものです。あまりに細かい作業まで入れすぎると、重要な管理単位が埋もれてしまいます。

細かい作業は、ワークパッケージではなく、アクティビティや担当者のタスクとして管理する方が適している場合があります。

ワークパッケージは、細かければ細かいほどよいわけではありません。見積もりや進捗確認に使える単位であり、かつ管理負荷が大きくなりすぎない粒度にすることが重要です。

適切な粒度を判断するチェックリスト

ワークパッケージの粒度に迷ったら、以下の観点で確認すると判断しやすくなります。

• 成果物や完了状態を説明できるか
• 担当者または担当チームを設定できるか
• 所要期間や工数を見積もれるか
• 開始条件と終了条件を決められるか
• 他のワークパッケージとの前後関係を整理できるか
• 進捗を確認できるか
• 細かすぎて更新負荷が高くなっていないか
• 粗すぎて遅延理由が見えなくなっていないか

これらを確認し、複数の項目で判断しにくい場合は、粒度を見直す必要があります。

たとえば、担当者を決められないほど大きい場合は、さらに分解した方がよいでしょう。逆に、数十分で終わる作業を大量に並べている場合は、まとめた方が管理しやすくなる可能性があります。

ワークパッケージの粒度は、プロジェクトの規模や目的によって変わります。重要なのは、WBSを見た関係者が「何を、どこまで、誰が、いつまでに行うのか」を理解できる状態にすることです。

ワークパッケージをWBSからスケジュール管理表へつなげる手順

ワークパッケージは、WBS上で定義しただけでは十分に機能しません。

スケジュール管理表、RACI、WBS辞書、担当者設定、完了条件へつなげることで、実務で使える管理単位になります。

ここでは、ワークパッケージをWBSからスケジュール管理表へつなげる手順を整理します。

手順1：プロジェクトのスコープと成果物を確認する

最初に確認すべきなのは、プロジェクトのスコープと成果物です。

スコープとは、プロジェクトで対応する範囲のことです。何を作るのか、どこまで対応するのか、反対に何は対象外とするのかを明確にします。

スコープが曖昧なままWBSを作ると、ワークパッケージの範囲も曖昧になります。結果として、必要な作業が漏れたり、不要な作業まで含まれたりします。

たとえば、Webサイト制作プロジェクトであれば、対象ページ、対応デバイス、CMS設定、問い合わせフォーム、原稿作成、公開作業などがスコープに含まれるのかを確認します。

ワークパッケージは、スコープと成果物をもとに設計します。先に作業名を並べるのではなく、まず「何を完成させる必要があるのか」を明確にしましょう。

手順2：作業を分解し、ワークパッケージまで落とす

次に、プロジェクトの作業を階層的に分解します。

大きな成果物や作業領域を分けたうえで、管理できる単位まで細かくしていきます。この最下層がワークパッケージです。

たとえば、Webサイト制作であれば、以下のように分解できます。

• Webサイト制作
• 設計
• デザイン
• 実装
• 問い合わせフォーム制作
• 公開前テスト

このうち、「問い合わせフォーム制作」や「公開前テスト」は、ワークパッケージとして扱いやすい単位です。成果物や完了条件が比較的明確で、担当者や期間も設定しやすいためです。

一方で、「実装」だけでは範囲が広すぎる場合があります。その場合は、「トップページ実装」「下層ページ実装」「フォーム実装」のように分解します。

分解の目的は、細かくすることではありません。見積もり、担当者設定、進捗管理ができる単位まで整理することです。

手順3：前後関係と所要工数を確認する

ワークパッケージを洗い出したら、前後関係と所要工数を確認します。

前後関係とは、どの作業が終わらないと次の作業に進めないのかという関係です。たとえば、要件定義が終わらないと設計に進めない、デザインが確定しないと実装に進めないといった関係があります。

所要工数とは、そのワークパッケージを完了するために必要な作業量です。工数を見積もることで、スケジュールや担当者の負荷を検討しやすくなります。

前後関係や工数を確認しないままスケジュール管理表を作ると、無理な日程になりやすくなります。たとえば、前工程が終わっていないのに後工程が始まる計画になっていたり、1人の担当者に作業が集中していたりすることがあります。

ワークパッケージをスケジュールに落とす前に、作業順序、依存関係、所要工数を整理しておくことが大切です。

手順4：担当者・完了条件・WBS辞書を整える

ワークパッケージごとに、担当者と完了条件を決めます。

担当者が曖昧なワークパッケージは、進捗が止まりやすくなります。また、完了条件が曖昧だと、担当者は完了したと思っていても、PMや関係者は完了と判断していないというズレが起こります。

たとえば、「問い合わせフォーム制作」の完了条件として、以下のように定義できます。

• フォーム画面が実装されている
• 必須項目の入力チェックが動作している
• 送信テストが完了している
• 関係者レビューで承認されている

このように完了条件を具体化すると、進捗確認がしやすくなります。

また、必要に応じてWBS辞書を作成します。WBS辞書とは、各ワークパッケージの内容、担当者、完了条件、成果物、前提条件、制約条件などを補足する資料です。

WBS辞書を整えると、ワークパッケージの意味が関係者間でズレにくくなります。特に、複数部門や外部パートナーが関わるプロジェクトでは有効です。

手順5：スケジュール管理表とRACIに反映する

ワークパッケージを整理したら、スケジュール管理表に反映します。

スケジュール管理表には、ワークパッケージ名、担当者、開始日、終了日、進捗状況、依存関係、マイルストーンなどを記載します。これにより、WBSで整理した作業を実際の進行管理に使えるようになります。

また、責任範囲を明確にするために、RACIへ反映する方法も有効です。RACIとは、Responsible（実行責任者）、Accountable（説明責任者）、Consulted（相談先）、Informed（情報共有先）の頭文字を取ったフレームワークです。実行責任者、説明責任者、相談先、共有先を整理するために使います。

たとえば、「問い合わせフォーム制作」というワークパッケージについて、実装担当者、承認者、相談先、情報共有先を整理しておけば、誰が何に責任を持つのかが明確になります。

WBSは作業を分解する資料、スケジュール管理表は予定と進捗を管理する資料、RACIは責任範囲を整理する資料です。これらをつなげることで、ワークパッケージが実務で機能しやすくなります。

ワークパッケージ設計でよくある失敗

ワークパッケージ設計でよくある失敗は、WBSを作っただけで終わってしまうことです。

WBS上に作業を並べても、担当者、完了条件、所要工数、前後関係が整理されていなければ、実務で使える管理資料にはなりません。

よくある失敗は以下です。

• 粒度がバラバラで進捗を判断できない
• 完了条件が曖昧で、完了判断が人によって異なる
• 担当者が設定されていない
• ワークパッケージとアクティビティが混在している
• WBSをスケジュール管理表へ反映していない
• 責任範囲が不明確で、確認や承認が止まる

ワークパッケージは、WBS上で定義するだけではなく、スケジュール管理、担当者設定、完了条件、RACIへつなげて運用することが重要です。

PMは、WBSの見た目を整えるだけでなく、プロジェクトを進めるために使える状態になっているかを確認する必要があります。

ワークパッケージを正しく設計し、プロジェクト管理の精度を高めよう

ワークパッケージは、WBSで分解した最下層の管理単位です。粒度を適切にそろえることで、工数見積もり、担当者設定、完了条件の明確化、スケジュール管理表への展開がしやすくなります。

一方で、粒度が粗すぎると進捗が見えにくく、細かすぎると管理負荷が高まります。WBSを実務で機能させるには、ワークパッケージをアクティビティやタスクと混同せず、RACIやスケジュール管理にもつなげることが重要です。

タカハマプロジェクトでは、プロジェクトマネジメントについて学べるトレーニングコースを、ビギナー向け・PM経験者向けにご用意しております。WBS作成やスケジュール管理を実務に近い形で学びたい方は、トレーニングメニューもご確認ください。

監修者紹介

高濱 幸喜（たかはま ゆきよし）
タカハマプロジェクト株式会社 代表取締役／PMP®資格保有者

20年以上にわたり、IT・通信・金融・製薬業・製造業・建設業など多様な業界でプロジェクトマネージャーとして活躍。PMBOKに基づくプロジェクトマネジメント手法を現場で実践し、数百件を超えるプロジェクトを成功に導いてきた実績を持つ。現在は研修やセミナーを通じて、次世代のプロジェクトマネージャー育成に注力。プロマネ道場では記事監修を担当し、読者に信頼性の高い情報を届けている。

タカハマプロジェクトでは、プロジェクトマネジメントについて学べるトレーニングコースを、「ビギナー向け」「PM経験者向け」にそれぞれご用意しております。まずはお気軽にお問い合わせください。