ワークパッケージ：定義とWBSにおける役割

あらゆる作業分解構成図は、最終的に枝分かれをやめます。それが止まる地点がワークパッケージであり、そこで起きることが、WBSが本物の管理ツールになるのか、誰もそれに沿って管理しない見栄えのよい図で終わるのかを決めます。

ワークパッケージは、ToDoリストのタスクではありません。管理上の概念です。プロジェクトがコストを見積もり、1人の担当者を割り当て、計画に対する進捗を測定する、最下位のレベルです。そのレベルを誤る（大きすぎる、小さすぎる、あるいは担当者がいない）と、その上に築かれるすべての計画（スケジュール、予算、アーンドバリューのレポート）が、その誤りを引き継ぎます。

Key Facts

• 米国国防総省自身のアーンドバリュー用語集によれば、ワークパッケージとは「作業が計画され、進捗が測定され、アーンドバリューが算出される地点」であり、その親であるコントロールアカウントは、管理目的で予算と実コストをアーンドバリューと比較する実際の管理統制点として定義されています。
• 個別に測定可能な成果物を持たない、いわゆるLevel of Effortのワークパッケージは、PMIが公表しているプランニングパッケージに関するガイダンスによれば、一般に12か月を超えるべきではありません。
• 同じPMIのガイダンスは、プランニングパッケージは「その作業に対していかなる費用が発生する前にも、ワークパッケージに変換されなければならない」と述べています。これは、将来の予算項目が、誰も作業を計画しないうちに実際の支出を静かに吸収してしまうのを防ぐルールです。
• パーセント完了は、ワークパッケージの進捗測定手法として最も広く使われているものの1つですが、NASA自身のEVMリファレンスガイドは、これを単なる推測ではなく客観的な測定にとどめるために、Quantifiable Backup Data（定量化可能な裏付けデータ）による裏付けを求めています。
• 当社の作業分解構成図ガイドは、このページが土台とするサイジングの経験則をすでに示しています。ワークパッケージは8時間未満でも80時間超でもいけません。これは標準ではなく、経験則です。

ワークパッケージとは何か

ワークパッケージとは、作業分解構成図の最下位のレベルであり、そこで作業が計画され、見積もられ、1人の担当者に割り当てられ、完了まで追跡されます。成果物やサブ成果物の下に位置し、1人、あるいは1つのチームが、既知の工数・成果物・受け入れテストをもって完了できる程度に小さなスコープを表します。

この定義が重要なのは、ワークパッケージをめぐる混乱の大半が、この用語を特定の管理概念ではなく「作業の塊」の同義語として扱うことから生じるからです。ワークパッケージは、大きさだけで定義されるものではありません。そのレベルで何が起きるかで定義されます。そこでコストが見積もられ、そこで進捗が測定され、そこからスケジュールのアクティビティリストが作られます。米国国防総省のアーンドバリュー用語集はこの点を正確に述べており、ワークパッケージを、コントロールアカウントの「自然な細分化」、つまり作業が計画され、進捗が測定され、アーンドバリューが算出されるまさにその地点として説明しています。

だからこそ、ワークパッケージはToDo項目ではなく、管理上の概念なのです。ToDo項目は、誰かが何かをするのを忘れないために存在します。ワークパッケージは、プロジェクトがどの時点でも3つの問いに答えられるように存在します。このスコープのどれだけが完了したか、誰が責任を負っているか、そして予定していたコストに対して実際にいくらかかったか。ワークパッケージより上にあるもの（成果物、フェーズ、プロジェクト自体）は、これらの問いに直接答えません。ワークパッケージを積み上げることで答えているのです。

ワークパッケージ、成果物、アクティビティ、タスク、マイルストーンの違い

このページを探しに来る人のほとんどが抱えている混乱がこれです。5つの用語は、本当に異なる問いに答えているので、正確に押さえておく価値があります。

ほとんどの人がつまずく点があります。ワークパッケージは、それ自体がスケジュールアクティビティではないということです。ワークパッケージは、計画の段階で1つ以上のスケジュールアクティビティに分解されます。WBSの構築時に、成果物がワークパッケージに分解されるのと同じです。「家具の調達と納品」はワークパッケージです。「3社のベンダーにRFQを送る」と「納品時間帯を確認する」は、それを構成するスケジュールアクティビティです。この2つのレベルを混ぜると、Ganttチャートには何百もの項目が並び、コストと責任にとって本当に重要なレベルで誰が何を所有しているのかが、はっきりしなくなります。

コントロールアカウント、プランニングパッケージ、ワークパッケージの階層

ワークパッケージは単独では存在しません。コントロールアカウントの2種類の子のうちの1つであり、この階層こそが、将来の計画を、詳細に見せかけた推測ではなく、誠実なものにしています。

米国国防総省のEVM用語集は、コントロールアカウントを「管理統制の目的で、予算（リソース計画）と実コストが累積され、アーンドバリューと比較される」地点として定義しており、プランニングパッケージを、「ワークパッケージやタスクのレベルではまだ詳細に計画できない」将来の作業として定義しています。プランニングパッケージの活用に関するPMIの論文は、このギャップに関するルールを平易に述べています。プランニングパッケージは、「その作業に対していかなる費用が発生する前にも、ワークパッケージに変換されなければならない」。プレースホルダーに対して予算を組むことはできます。しかし、プレースホルダーに対して支出することはできません。

これこそ、ローリングウェーブ計画が拠って立つ仕組みです。近い将来の作業は、詳細に計画できる程度に理解されているため、実際のワークパッケージに分解されます。遠い将来の作業は、その波が訪れて完全な分解に値するようになるまで、プランニングパッケージ、つまり予算とマイルストーンのままです。コントロールアカウントは両方を1つにまとめ、アカウントの半分が意図的に粗いままであっても、スポンサーに1つの誠実な数字を提供します。

WBS辞書のエントリ：フィールドごとの解説

辞書のエントリがないワークパッケージは、中身のないラベルです。当社の作業分解構成図ガイドは、すでに基本となるフィールド（説明、担当者、見積もり工数、必要なインプット、成果物基準、依存関係）を定めています。ワークパッケージのエントリは、さらに一歩踏み込みます。このレベルは、誰かがエントリを単に読むだけでなく、それに沿って実際に実行しなければならない場所だからです。

本ガイドの後半で使うオフィス移転の例について、記入済みのエントリを示します。

エントリの多くが、後で起きる特定の予測可能な議論を防ぐために存在していることに注目してください。前提の行は、アクセサリをめぐる争いを防ぎます。受け入れ基準は、「納品済み」が何を意味するかをめぐる争いを防ぎます。チャージコードは、このパッケージの実コストがここに属するのか、別の場所に属するのかをめぐる争いを防ぎます。

ワークパッケージのサイジング：8/80ルールとその先

作業分解構成図ガイドが述べる8/80ルールは、サイジングの経験則です。ワークパッケージの工数は8時間未満でも80時間超でもいけません。そのガイドがすでに述べている注意点を繰り返しますが、これは絶えず見失われるからです。8/80は経験則であり、PMIやいかなる標準化団体が発行した標準でもありません。短く動きの速い取り組みには4/40を使う組織もあれば、複数年にわたるプログラムでは160時間まで広げる組織もあります。数字は変わります。その背後にある理由は変わらず、組織がどの時間範囲を選んでも成り立ちます。

これら4つのテストのどれか1つに失敗するパッケージは、時間数に関係なくサイズが誤っています。3人が静かに分担している40時間のパッケージは、8/80の範囲内に収まっていても、担当者のテストに失敗します。何が含まれるのか実際には誰もまだ知らないために自信を持って見積もれない6時間のパッケージは、どれだけ小さく見えても、見積もり可能性のテストに失敗します。時間の範囲は最初のふるいとして使い、これら4つの問いを実際のテストとして使ってください。

実例：オフィス移転

抽象的なサイジングのルールは、実際の分解に当てはめたときに、より意味が通ります。ここでは、上のWBS辞書の例で使ったものと同じオフィス移転プロジェクトを、ワークパッケージのレベルまで分解します。

注目すべき点が2つあります。第一に、どの工数も妥当な範囲に収まっています。1日の午後で済むタスクもなければ、2営業週間を超えるものもありません。第二に、どの受け入れ基準も、第三者が担当者に「それで、終わっていますか？」と尋ねなくても確認できるものです。それが、ワークパッケージと、WBSにもう1行必要だからと入力されただけの項目との違いです。

ワークパッケージが下流に供給するもの

ワークパッケージは、計画の連鎖の終点ではありません。スコープ定義の後に来るほとんどすべてのものへの入力です。

最後の行は、よくある誤りの原因になるため、正確に押さえる価値があります。アーンドバリューは、そのパッケージに割り当てられた手法を使って、ワークパッケージで算出されます。しかし国防総省自身の定義によれば、個々のワークパッケージではなくコントロールアカウントが、報告と意思決定のために予算、実コスト、アーンドバリューが比較される実際の管理統制点です。苦戦している1つのワークパッケージが、それだけで対応を引き起こすことはまれです。集計されたCPIやSPIが悪化したコントロールアカウントには、差異分析と是正措置計画が課されます。その比較の仕組みについては、アーンドバリューマネジメントが計算式を解説しています。

ワークパッケージの進捗測定手法

ワークパッケージのパーセント完了をどう計算するかは、作業開始前に決められ、辞書のエントリに文書化され、パッケージの途中で変更されることはありません。NASAのEVMリファレンスガイドと国防総省のEVM用語集はどちらも、同じ中核的な手法群を挙げています。

裏付けデータのないパーセント完了は、報告上のフィクションが忍び込む場所です。誰にも気づかれずに楽観的に報告するのが最も簡単な手法だからです。0/100、完了単位、そして明確に定義された加重マイルストーンは、ごまかしにくい手法です。起きたか起きなかったかのどちらかである出来事に依存しているからです。Level of Effortは正直な例外です。実際の進捗を測るものではなく、明確なアウトプットを生む予定のなかった作業のための、簿記上の便宜です。PMIのガイダンスによれば、約1年以内の期間にとどめるのが最善です。

アジャイルの類似概念：エピック、ストーリー、サイジングの直感

アジャイルのエピックやユーザーストーリーは、ワークパッケージではありません。異なる計画の伝統から生まれ、サイジングの方法も異なり、責任を負う相手も異なります。しかし、どちらの根底にあるサイジングの直感は同じです。作業を、誠実に見積もれ、明確に所有でき、予測可能な期間内に終えられる小ささになるまで分解するのです。

ハイブリッドな組織は、一方をもう一方に絶えず対応づけており、どちらの側が判断を下すのかについて全員が合意している限り、それはおおむねうまくいきます。コントロールアカウントは、ワークパッケージの集合の上に置かれるのと同じように、リリース1回分のエピックの上にも置くことができ、ストーリーの受け入れ基準は、ワークパッケージの受け入れ基準と同じ役割を果たします。この対応づけが破綻するのは、ストーリーポイントを時間ベースのアーンドバリューの式に無理やり当てはめたときです。2つの世界を頻繁に行き来するなら、用語が実際にどう違うのかをエピック・フィーチャー・ストーリーの違いで確認してください。

ワークパッケージを定義する際のよくある誤り

ワークパッケージの問題のほとんどは、小さくて繰り返される一連の誤りに行き着き、どこを見ればよいかがわかれば、見つけるのは簡単です。

重複の誤りは、目視では最も見つけにくいため、もう一度見直す価値があります。2つのパッケージは、それぞれ単独では妥当に見えても、互いに照らし合わせなければ、同じ時間を二重にカウントしていることがあります。それこそが、100%ルールが捕まえるために存在する問題です。すべてのブランチを歩き、子の合計が親に等しいこと、欠けているものも二重にカウントされているものもないことを確認します。

関連記事

• 作業分解構成図（WBS）
• プロジェクト成果物
• ローリングウェーブ計画
• アーンドバリューマネジメント（EVM）
• プロジェクトコスト見積もり
• 作業範囲記述書（SOW）
• ネットワーク図
• RACIマトリクスとは

ワークパッケージがWBSの中で居場所を得ているのは、計画のほかの何にもできない仕事をしているからです。1人の担当者に、所有でき、誠実に見積もれ、誰かが確認できる期間内に終えられる大きさのスコープの一部を与えるという仕事です。サイジングのテストを正しく行い、辞書のエントリに本物の受け入れ基準を書き、詳細化されていないものについてはプランニングパッケージを正直に扱えば、計画の残りの部分は、プロジェクト計画の衣をまとった推測ではなく、築く価値のある土台を引き継ぎます。