アンソニー・ボーデン、有名シェフ、著者、 は厨房を切り盛りしていた 旅団方式を採用していた。彼は厨房を食事の構成要素を作るステーションに分けた。各ステーションにはスーシェフ、コック、アシスタントがいて、それぞれの食材、道具、作業スペースがあった。
この構造により、「大規模で多忙な厨房の多くのタスクは、夕食ラッシュの熱気の中でも、シェフ一人で管理・調整できるようになった」と彼は言う。
ビジネスの世界では、このような階層はリソース・ブレークダウン・ストラクチャーと呼ばれる。それは何ですか？それは何かって？
リソース分解構造を理解する
リソース・ブレークダウン・ストラクチャー（RBS）とは、プロジェクトを完了するために必要なすべてのリソースを階層的に整理したリストである。これらのリソースは、人的、物的、財政的、情報的リソース、さらには時間的リソースである。
リソース管理ツールであり、通常、プロジェクト目標を最上位に、各フェーズでさまざまなリソースカテゴリーがブランチアウトするように、複数の階層にわたって構成される。実際のお金そのものを除き、お金のかかるすべてのリソースを対象とする。
最も重要なことは、RBSは孤島ではないということである。RBSは、ワーク・ブレークダウン・ストラクチャー、リスク・ブレークダウン・ストラクチャーなど、さまざまなプロジェクトプランニング活動と密接に連携しています。その方法を説明しよう。
ワーク・ブレークダウン・ストラクチャー（WBS）は、仕事を小さく管理可能なタスクに区切る文書である。優れたRBSはこの文書に対応し、各フェーズでどのようなリソースが必要になるかを概説します。
例えば、あるソフトウェア開発プロジェクトが、MVP（minimum viable product）フェーズ、フェーズ1、フェーズ2......と分かれている場合、RBSは各段階で必要なリソースをリストアップします。MVPフェーズでは、次のようなものが必要になるでしょう：
- 開発者
- 品質アナリスト
- プロジェクト管理者
- プロジェクト管理ソフトウェア
MVPが完了し、製品が本番稼動すると、次のような追加リソースが必要になるかもしれません：
- テスト自動化ツール
- データパイプライン
- クラウドインフラ
- プロダクト・マネージャー
- ユーザー・エクスペリエンス・リサーチャー
RBSのもう一つの側面は、リスク・ブレークダウン構造である。仕事の各フェーズにはリスクが伴う。いくつかの ERPソフトウェア・ツール RBS、WBS、リスク・ブレークダウン・ストラクチャーを接続し、ビューを完了する。
例えば、MVPフェーズではパフォーマンスの問題があるかもしれません。複数のチームメンバーがMVPの仕事をしている場合、セキュリティリスクに直面するかもしれない。ユーザー情報を収集していれば、データプライバシーリスクがあるかもしれない。
リソース分解構造には、各フェーズでこれらのリスクを軽減するために必要なコンポーネントが含まれています。MVPフェーズでは、RBSはクラウドインフラのための追加リソースを含む可能性が高い。大きな牽引力があれば、RBSはセキュリティ・エンジニアやコンサルタントをリストに加えるかもしれない。
リソース・ブレークダウン・ストラクチャーの基本を概説したので、プロジェクト管理でどのように使われるかを見てみよう。
プロジェクト管理におけるRBSの役割と重要性
リソース・ブレークダウン・ストラクチャーは、プロジェクト管理者がプランニングと実行のために使用する数多くのフレームワークの一つである。プロジェクトのライフサイクルを通じて重要な役割を果たす。その方法について説明する。
リソース配分
プロジェクトを完了するために必要なリソースがわかっていれば、適切なリソースを適切なタイミングで採用、トレーニング、割り当てることができます。RBSは、以下のロードマップとして機能します。 リソースの割り当て クリティカルパス法とは、プロジェクト管理手法の一つで、依存関係のあるタスクの中で最も長いシーケンスを特定し、プロジェクトの最小期間を算出する方法である。RBSも同様に、最低限必要なリソースを決めるためにやることです。
プロジェクトのスケジューリング、作業負荷の配布、リスク管理などを最適化するには、強固なリソース・ブレークダウン構造が必要です。ここでは、その作成方法をステップ・バイ・ステップで説明します。
リソース分解構造の作成
RBSはプロジェクトを完了するために必要なリソースのリストです。簡単そうに聞こえるでしょう？しかし、プロジェクトの性質によっては非常に複雑になることもある。徹底するためには、以下のステップを試してみてください。 ClickUpのリソース管理ソフトウェア .
1.プロジェクトの成果物を特定する
プロジェクトの目標とそれに対応する成果物を明確に定義することから始めましょう。ある期限までにxの機能を持つMVPを提供することが目標なら、完了する必要のあるタスクとサブタスクを地図に書き出す。WBSがすでにあれば、それを使う。
なければ プロジェクトスコープ .プロジェクトの鍵となる利害関係者を一堂に集め、期待値と成果物について話し合う。
手っ取り早く始めるには ClickUpのプロジェクトスコープホワイトボードテンプレート .さまざまな利害関係者から活動、タスク、期限に関する情報を収集するために使用します。情報を要約し、後で参照できるように視覚的に整理します。
ClickUpのプロジェクトスコープホワイトボードテンプレート
2.リソースカテゴリの特定
RBSの最上位ブランチを形成するリソースの主要カテゴリーを決定することから始めます。これは次のようになります：
- 人的資源（プロジェクト管理者、開発者、設計者）
- 物質的または物理的リソース（コンピュータ、オフィススペース、機器、スペース）
- 情報リソース（データ、文書、プロジェクト概要）
- 時間リソース（期間、マイルストーン、期限）
- ソフトウェア資源（プロジェクト管理ツール、自動化ツール）
RBSは階層であることを忘れないでください。そのため、リソースをそれぞれの主要なリソースカテゴリーの下で特定の構成要素に分けます。例えば、人的資源はさらに次のように分けられる：
- プロジェクト管理：プロジェクト管理：プロジェクトマネージャー、ビジネスアナリスト
- ソフトウェア開発：フロントエンド開発者、バックエンド開発者、テスター
- ユーザー・エクスペリエンス・デザインUXリサーチャー、UIデザイナー
プロジェクトの規模が大きければ、さらにドリルダウンすることもできる。例えば、UIデザイナー、アニメーションデザイナー、ブランドデザイナーなどで構成されるUXチームをマネージャーするUXリードがいるかもしれない。
ClickUp リソースプランテンプレート
リソース・プランニングの初心者には、ちょうどいいものがあります。ぜひお試しください。 ClickUp リソースプランテンプレート を使えば、タスクとリソースを一箇所で可視化できます。このテンプレートを使って、作業時間の追跡、外注業者の管理、チームのワークフローの監視もできます。
3.リソースの詳細を含める
リソースの詳細を記載する。WBSやプロジェクトスコープ文書を使って、誰が何をやることについて質問する。見落としがないように。
最も一般的に必要とされる情報は、スキル、経験、報酬、稼働率などです。例
- フロントエンド開発者
- 名前ジェーン・やること
- スキルHTML、CSS、React
- 経験5年
- 時給: $80
- アベイラビリティ: 週40時間
また、番号を確認しましょう。ビジネスアナリスト、開発者、テスターが何人必要かを把握し、それを文書化してください。
4.役割に適した人材を特定する
この時点で、理論的なプランニングから実践的なシナリオの作成に移る準備ができたことになる。各役割について、その人の都合に基づいて適切な社員を選びます。 ClickUpの作業負荷ビュー は、チームメンバー全員の稼働状況を一度に見ることができる素晴らしい方法です。このビューでは、誰かが現在取り組んでいる仕事も見ることができます。そのため、すでに他の仕事に割り当てられているリソースが必要な場合は、プロジェクトマネージャーに相談して、再割り当てや共有をしてもらうことができます。
/イメージ https://clickup.com/blog/wp-content/uploads/2024/07/image-535.png ClickUpの作業負荷ビュー /クリックアップのワークロードビュー
きめ細かい可視性を実現するClickUpの作業負荷ビュー。
もう少し構造化されたものがお好みであれば ClickUp 従業員作業負荷テンプレート .この上級者向けテンプレートは、以下の作業に役立ちます。
/に役立ちます。 https://clickup.com/ja/blog/11793/undefined/ キャパシティプランニング /%href/
仕事の可視化、見積もり時間と実績の比較など。
あなたの 作業負荷管理 ClickUp従業員作業負荷テンプレートで簡単に。
5.点を接続する
優れたリソース分解構造は単なるリストではない。それは、プロジェクトを完了するために、すべてのリソースがどのように相互作用するかをビューするものである。先に見たように、これは階層的な方法で行われ、以下を支援する。 リソースの平準化 .
そのため、リソースを階層的に整理し、最も一般的なカテゴリーを最上位に置き、下に行くにつれて特定のサブカテゴリーに分類します。リソースの内訳構造の例は次のようになります：
- 人的資源
- プロジェクト管理
- プロジェクト管理者
- やること
- ビジネスアナリスト
- ジョン・スミス
- フロントエンド開発者
- サラ・キム
- ルーカス・ブラウン
- プロジェクト管理者
- プロジェクト管理
6.プロジェクトの設定
プロジェクトを リソース管理ツール のようなリソース管理ツール /%ref.ClickUpタスクを使って、仕事内訳構造を整理して公開する。そして、各タスクにリソースを追加し、期日を設定し、説明を追加します。必要に応じて添付ファイルや外部ファイルへのリンクを含めることもできます。
/画像 https://clickup.com/blog/wp-content/uploads/2024/08/image-198.png ClickUpタスク /クリックアップタスク
ClickUpタスクで楽々プロジェクト管理。
車輪を再発明する必要はありません。タスク管理ツール ClickUp リソース割り当てテンプレート プロジェクトに必要なすべての資材と人員を追跡するためのテンプレートです。この中級レベルのテンプレートを使用して、各リソースに関する詳細なメモを書き、それらの可用性を管理し、チーム構造を視覚化することなどができます。
ClickUp リソース割り当てテンプレート
次に、RBSとプロジェクトのセットアップを、クライアント、スポンサー、チームリーダー、チームメンバーなどの利害関係者と共有します。予測に食い違いがあれば指摘してもらいましょう。
ClickUpリストビューを使って、すべてのタスクとリソースを確認しましょう。クリックアップボードビューは、フェーズごとに仕事を整理するのに最適です。また、クリックアップガントチャートビューは、依存関係やタイムラインの視覚化に役立ちます。
/画像 https://clickup.com/blog/wp-content/uploads/2024/08/image-227-1400x929.png ClickUpのガントチャート /%img/
プロジェクトのタイムラインを管理するためのClickUpガントチャートビュー。
単純に聞こえるかもしれませんが、そうなのです。しかし、単純だからといって必ずしも簡単とは限らないことを覚えておいてほしい。リソース・ブレークダウン・ストラクチャーを作成する過程で、課題に直面するかもしれません。
ここでは、プロジェクト管理者が定期的に直面する課題と、それを克服するためのステップを紹介します。
RBS導入における課題と解決策
プロジェクトが複雑化したり、スコープクリープが起きたり、プロジェクトの枠組みを決めたオブジェクトがずれたりすることがあります。そのような場合にやることを見てみよう。
1.リソースの特定が不十分
プロジェクト管理者が直面する最大の課題の一つは、必要なリソースを正確に特定できていないことだ。これは、プロジェクトの可視性が不足していたり、仕事の範囲を見誤っていたり、必要なリソースを過小評価していたりすることが原因である。
いずれにせよ、RBSに必要なリソースがすべて含まれていなければ、予算超過や遅延のリスクに直面する可能性がある。これを避けるには
- 徹底的な調査
- 過去のプロジェクトをどのように構成し、どのような失敗をしたかを調べる。
- 活用するギャップ分析テンプレート 何が欠けているかを知る
- すべての利害関係者に、仕事の一部を見直し、アカウントを持ってもらう。
- バッファとなるリソースを確保する
2.プロジェクト要件の進化
アジャイルプロジェクトは本来、変化に対応できるものである。プロジェクト開始時に作成したRBSが、数回のスプリントの後に不適切になることがあります。これは リソース管理 しかし、それもやむを得ない。
これに適応するために
- RBSを定期的に見直す
- 追加リソースが必要ないか、必要以上のリソースを保持していないか確認する。
- 利用するリソースプランテンプレート を使用する
- RBSに変更を更新し、すべての利害関係者に知らせる
以下のようなツールを使用している場合 ClickUp ドキュメント を使えば、変更箇所をハイライトして関係者と共有し、共同で編集したり、コメントとしてフィードバックを残したりすることができます。例えば、プロジェクトコストの変更点を表示し、プロジェクトスポンサーや財務見出しが承認できるようにすることができます。
/イメージ https://clickup.com/blog/wp-content/uploads/2024/08/ClickUp-Docs-gif-1.gif ClickUp ドキュメント /%img/
クリックUpドキュメントを共同文書作成に活用しよう。
3.利害関係者の賛同の欠如
初期段階のプロジェクト管理者は、他の人に相談せずにリソース分解構造を作成するというミスを犯すかもしれません。良かれと思ったにもかかわらず、サイロで仕事をすることは、後に次のような事態を引き起こすかもしれない。 リソース制約 .
例えば、プロジェクト管理者は、UIデザイナーは1人で十分だと考えるかもしれない。しかし、UXリードは、マイクロアニメーションにも精通しているUIデザイナーを持っていないかもしれない。
このような事態を避けるには、あらゆるレベルで利害関係者の賛同を得ることです。すべての利害関係者がRBSをレビューし、最適なリソースの利用を確実にするために同意するよう奨励する。
4.混乱するチームメンバー
リソース分解構造は、プロジェクトの管理構造を定義する役割も果たす。これには、誰が誰に報告するか、誰が誰の仕事をレビューするか、などが含まれる。
明確な階層と積極的な承認がなければ、 チームマネージャー は混沌としてしまう可能性がある。例えば、あなたはフロントエンド開発者をUX階層に加えたかもしれませんが、リソースは開発責任者に報告すると考えているかもしれません。
透明性を確保することで、このような状況を防ぎましょう。リソース分解構造を公開し、チームメンバー全員に見てもらいましょう。誰もが理解しやすいように、きれいで視覚的なものにしましょう。懸念やフィードバックがある場合に備えて、コミュニケーションチャネルをオープンにする。
プロジェクトを構造化し、ClickUpでレベルアップしよう。
今日のアジャイルソフトウェアプロジェクトは、自主性と自己管理を優先しているため、ブルダンの旅団方式による仕事の組織化は逆効果になるかもしれない。しかし、学ぶべき、より深く、より根本的な教訓がある。
ブルダンの台所は、プロジェクトを効果的に、一貫して、そしてプレッシャーのかかる状況で遂行するためには、誰が何に責任を持ち、仕事がどのようにあるステップから別のステップに移るのかを明確に分解する必要があることを示している。
ClickUpのような強力なプロジェクト管理ツールを使えば、リソース分解構造をプランニングプロセスに統合することができます。Googleドキュメントやスプレッドシートを新たに作成することなく、ClickUpを使ってプロジェクト関連のドキュメントを一箇所にまとめることができます。
さらに？プラットフォーム内で様々な関係者と共有、編集、コラボレーションができます。将来使用するために、自分用にカスタマイズしたリソース内訳構造テンプレートを作成することもできます。
プロジェクトのワークスペースを統合。 ClickUpを今すぐ無料でお試しください。 .