【PMBOK第8版】RBS（資源ブレークダウン・ストラクチャー）とは？WBSとの違いと実践的な作り方

計画には「やるべきこと」だけでなく「必要なもの」のリストが不可欠

プロジェクトの計画を立てる際、多くの人が「WBS（作業分解図）」を作成してタスクを細かく洗い出します。
しかし、「タスクは洗い出したけれど、それを誰がやるのか、どんな機材やシステムが必要なのかが不明確なまま進めてしまい、後から慌てて手配した」という経験はないでしょうか。

PMBOKにおける「資源ブレークダウン・ストラクチャー（Resource Breakdown Structure：RBS）」は、まさにこうした「手配漏れ」を防ぐためのツールです。
RBSはPMBOK第8版に登場する「資源の見積り」プロセスの主要なアウトプットとして作成されます。このRBSについて、その構造や、紛らわしい他の用語との違い、そして実務におけるリアルな活用方法を解説します^[1]Project Management … Continue reading。

RBS（資源ブレークダウン・ストラクチャー）の基本構造

RBSとは、プロジェクトで必要なすべての資源（人、モノ、環境など）を、「カテゴリー」と「タイプ」別に上から下へとツリー状にブレークダウン（要素分解）して整理した図表のことです。

具体的には、以下のように階層化していきます。

• 最上位（レベル0）: プロジェクト全体
• レベル1（カテゴリー）: 資源の大分類。例：「労働力（人）」「資材」「設備」「ソフトウェア」など。
• レベル2（タイプ・役割）: 具体的な機能や職種。例：「プログラマー」「デザイナー」「テスト用サーバー」「デザインツール」など。
• レベル3（等級・スキル・資格）: さらに詳細な分類。例：「シニアエンジニア」「品質等級Aの部品」「AWS認定資格保持者」など。

このように階層化することで、プロジェクトに必要なすべてのリソースの全体像を視覚的に整理することができます。

紛らわしい「3つのブレークダウン・ストラクチャー」の違い

PMBOKを学んでいると、アルファベット3文字の「ブレークダウン・ストラクチャー」が複数登場し、混乱しがちです。それぞれの分解の軸と目的を整理しておきましょう。

名称	英語の略称	分解の軸	主な目的・問い
WBS	Work Breakdown Structure	作業・成果物	何を作るか・何をやるか（What）
OBS	Organizational Breakdown Structure	組織・部署	誰が・どの部署が担当するか（Where / Who）
RBS（資源）	Resource Breakdown Structure	資源の種類・等級	どんな種類・スキルのリソースが必要か（With What）
RBS（リスク）	Risk Breakdown Structure	リスクの発生源	どこに不確実性の要因が潜んでいるか（Why）

「資源（Resource）」と「リスク（Risk）」は同じRBSという略称になるため、文脈で判断する必要があります。

WBSが「やるべき仕事の図鑑」であるのに対し、RBS（資源）は「その仕事に必要な道具や人手のカタログ」のような役割を果たしているとイメージすると分かりやすいでしょう。

RBSを作成する3つのメリット

必要な資源をカタログのように整理（RBS化）しておくことで、プロジェクトマネジメントには以下のようなメリットが生まれます。

1. 漏れ・ダブりのないリソース把握:
   カテゴリー別に階層化することで、「デザイナーはアサインしたが、デザイン用の有料ソフト（ライセンス）を手配し忘れていた」といったミスを防ぎます。
2. コスト見積りや調達計画との連動:
   「シニアエンジニアが何人」「この機材が何個」と等級ごとに整理されているため、単価の掛け算や調達先の割り出しがスムーズになり、精度の高い予算が組めます。
3. 責任分担マトリクスのベースになる:
   この後、WBS（作業）の各タスクに誰をアサインするかを決める際、RBSのカタログから「このタスクにはこのスキルレベルの人が必要だ」と紐付けることで、効率的なアサインが可能になります。

実務におけるRBSの作り方：WBSとエクセルを組み合わせる

さて、ここまでPMBOKにおけるRBSの理論を解説してきましたが、実務の現場ではどうでしょうか。

正直なところ、よほどの大規模プロジェクトでもない限り、WBS（作業のツリー図）とは別に、わざわざRBS専用の美しいツリー図を作り上げて別々に管理する、というのはあまり現実的ではありません。管理の手間が倍増してしまうからです。

しかし、RBSの「どのような資源が必要で、誰が担当するのかを明らかにする」という概念自体は、すべてのプロジェクトに必須です。

そこで実務においては、WBSをベース（主軸）にしつつ、その補足資料としてエクセルやスプレッドシートを活用して資源を紐付ける方法をおすすめします。

1. WBSでタスクをツリー化する: まずは視覚的に「やるべき作業」を洗い出します。
2. スプレッドシートでタスクを縦に並べる: 洗い出したタスクをエクセルやスプレッドシートの行（縦軸）に並べます。
3. 横軸に「資源（RBS要素）」を足していく: 各タスクの横の列に、「担当者（スキル要件）」「必要な機材・ツール」「必要なライセンス」といった資源の情報を入力していきます。

このように、WBSのタスク一覧に対して、RBSのカタログ要素（人やモノ）を紐づけて一覧化することで、「作業」と「資源」の不整合を視覚的に防ぐことができます。

まとめ：仕事と道具はセットで計画する

「タスク（WBS）は決まったけれど、それを誰が、何の道具を使って実行するのか（RBS）が決まっていない」という状態は、設計図だけがあって大工さんと木材が手配されていない家づくりと同じです。

PMBOKがRBSという概念を定義しているのは、タスクとリソースは常にセットで考えなければならないという鉄則を教えてくれているからです。
専用のツリー図を作るかどうかはプロジェクトの規模によりますが、「この作業にはどんなスキルと環境が必要か？」というRBSの視点を常に持ち、スプレッドシート等を活用して「手配漏れ」のない盤石な計画を立てていきましょう。