「勘」に頼らない、100件の進行中プロジェクトに対するキャパシティプラン

進行中のプロジェクトが100件あるという数字だけでは、同じプロジェクトマネージャーやエンジニアが複数のプランに重複して含まれているかどうか、通常業務（BAU）がチームの時間を多く占めているかどうか、あるいはどの新規依頼を優先すべきかといったことは判断できません。新規仕事を組み込むかどうかを決定するには、1つのプラン期間における役割ごとの需要を見積もり、総キャパシティからBAUやその他のコミットメントを差し引き、誰かが開始日を約束する前に、そのトレードオフを可視化してください。

この例では、架空の4週間の期間、4つの役割グループにまたがる20人のフルタイム相当（FTE）、および2つのサンプル要求を使用しています。人員配置および需要に関する数値はすべて説明用のものです。 英国政府のプロジェクト実施ガイダンスでは、リソースの制約の中で、分類、優先順位付け、バランス調整、および計画策定を通じてポートフォリオ業務を説明しています。このガイダンスは、政府のプロジェクト実施を目的として作成されたものであり、民間セクターのベンチマークではありません（第12章：ポートフォリオの管理、2024年7月29日公開、最終更新日：2026年7月1日）。

主なポイント

この記事の内容：チームからの声·4週間の期間を設定する·BAUとプロジェクトのキャパシティを区別する·バックログの要求を比較する·トレードオフを行う·最初の30日間·ワークシートをコピーする·決定

各チームからの声

提供された匿名化されたPMOのメモには、バックログに新たなリクエストが継続的に追加されている、約100件の進行中のプロジェクトからなるポートフォリオについて記載されています。また、リソースの割り当てが非公式であり、チームの知識に基づいていること、さらに導入状況、企業の支持、実装の複雑さに関する懸念についても記述されています。これらはデモから得られた定性的な情報であり、代表的なアンケート結果ではありません。以下のポートフォリオおよび数値は架空のものです。

まずは4週間の期間から始めましょう

有用な初期案では、100件のプロジェクトすべてにわたるすべてのタスクをスケジュール化しません。同じ4週間の期間において、役割ごとの残りの作業量を推定し、タスクレベルのスケジュール策定はデリバリーチームに委ねます。 第12章では、過度に詳細なポートフォリオ・ガントチャートの作成を避けるよう助言し、ポートフォリオの意思決定に有用な詳細レベルを維持することを強調しています（第12章、2024年7月29日公開、最終更新日：2026年7月1日）。

この例では、PMOのFTEは20名です。内訳は、プロジェクトマネージャー（PM）4名、ビジネスアナリスト（BA）4名、エンジニア8名、そして品質・データ・変更管理を統括するグループのメンバー4名です。計画期間は4週間で、各FTEはその期間中に160時間の総労働時間を提供します。これらはシナリオ上の仮定であり、顧客や企業の実際のデータではありません。

最初のワークシート作成では、すでに進行中の仕事、定期的なBAU、および承認されていない提案中の仕事を分類します。このシナリオは、100件の進行中のプロジェクトと、継続的に増加する受入バックログを前提としています。

BAUとプロジェクトのキャパシティを区別する

すべての役割グループに対して、同じ計算式を使用します：

正味プロジェクトキャパシティ ＝ 総時間数 － BAU － 予定されている休暇または研修 － 管理・サポート業務 － 予備

BAUには、プロジェクトと同様に人員を要する反復的な仕事が含まれます。プロジェクトの需要とキャパシティを比較する前に、これを記録してください。『政府プロジェクト実施（Government Project Delivery）』のリソース管理ガイダンスでは、需給、役割およびスキルの要件、実際の可用性、ローリング予測、スケジュールの調整、および前提条件が変更された際の優先順位の再設定について解説しています（第28章：リソース管理、2024年7月29日公開、最終更新日：2026年7月1日）。

2026年9月のPlaniswareガイドでは、需要と利用可能な人員、スキル、時間を比較する際に、プロジェクト以外の仕事も考慮に入れることを推奨しています。これはベンダーが作成したガイダンスであるため、ベンチマークではなく手法の比較として扱うようにしてください（『プロジェクト横断的なキャパシティ計画の管理方法』、2026年9月21日発行）。

この例における「予備」は、標準的な割合ではなく、計画上明示的に確保された余裕分です。これを、PMOが確保することに合意したバッファに置き換えてください。この見積もりは、各役割の所有者が、通常業務（BAU）、休暇、サポート、および予備をそれぞれ1回ずつしかカウントしないことに合意している場合にのみ有効です。

次に、純キャパシティと今後4週間の確定済みプロジェクトの仕事量を比較します：

ポートフォリオには合計120時間の余裕がありますが、プロジェクト管理者はキャパシティを20時間超過しています。ある役割の時間を、別の役割の時間に自動的に振り替えることはできません。『House of PMO』の2026年9月23日付の実務者向け記事では、リソース情報を踏まえてタイミングと順序を決定すべきであると論じています。この記事は、管理された成果研究ではなく、更新された実務者向けモデルとウェビナーに基づいています（『PMOのためのリソース管理：ポートフォリオの視点を用いて最も重要な事項を優先順位付けする』）。

ソフトウェアカテゴリの概要については、「リソース管理に最適なキャパシティプランニングツール13選」をご覧ください。本記事では、ベンダー間の比較は行わず、1つの具体的な事例に焦点を当てています。

バックログのリクエストを、対応する役割プールに並べてください

すべてのリクエストで同じ計画期間と役割カテゴリを使用することで、バックログの比較が可能になります。以下の2つのサンプルリクエストは架空のものです。これらの見積もりは、タスクレベルのプランではなく、初期段階の役割レベルでの仮定です。

承認に先立ち、PMOは各リクエストの結果、スポンサー、タイミング、依存関係、見積もりの信頼性、および役割ごとの需要を確認します。その後、リーダーたちは合意済みの投資基準を適用します。第12章では、ポートフォリオ管理の一環として、分類、優先順位付け、バランス調整、および計画策定について解説しています。順位付けされたリクエストであっても、スケジュールとリソースの適合性チェックは依然として必要です。『House of PMO』の実務者向け記事では、すべてのイニシアチブを「開始日が固定されたコミットメント」として扱うのではなく、リソース情報を活用してタイミングや順序を決定することを推奨しています。

トレードオフを明確に示す

リクエストAは、現在のプランのままであれば組み込む余地がありません。プロジェクトマネージャーはすでに20時間の超過が発生しており、エンジニアリング部門の空き時間はわずか12時間しかありません。 この例では、ポートフォリオボードは、優先度の低い仕事のうち、プロジェクト管理チームの作業時間40時間とエンジニアリングチームの作業時間20時間を次のウィンドウに繰り越します。仕事はキャンセルされるのではなく、順序が再調整されるだけであり、ポートフォリオには依然として100件の進行中のプロジェクトが含まれています。このシナリオでは、次のウィンドウが再調整された60時間を吸収できると仮定し、繰り越しをコミットする前にそのキャパシティを確認してください。

このトレードオフを考慮すると、リクエストAは収まります。このリクエストは、当該期間に残っているプロジェクト管理およびエンジニアリングのキャパシティをすべて消費します。リクエストBは依然として収まりません。これを追加すると、プロジェクト管理の稼働時間は320時間に対し345時間、エンジニアリングは592時間に対し672時間となります。PMOは、このリクエストを延期するか、短期的なスコープを縮小するか、承認済みのキャパシティを確保するか、あるいは別のポートフォリオのトレードオフ案をボードに提示する必要があります。同じ人員をこっそりと二重にカウントするようなことは避けるべきです。

この既存のガイドでは、より広範なポートフォリオに関する会話を扱っています：『企業プロジェクト管理：すべてのプロジェクトを1つのポートフォリオとして運営する方法』。

リーダー向けの決定メモは簡潔にまとめられます。「優先度の低い仕事のうち、プロジェクト管理40時間分とエンジニア20時間分を次の期間に繰り下げれば、リクエストAをこの4週間の期間内に組み込むことができます。これにより、プロジェクト管理およびエンジニアの余裕時間はなくなります。リクエストBは、次回のレビュー、またはスコープ、人員配置、順序の変更が承認されるまで、引き続き延期となります。 」 ボードには、移動を承認した担当者、移動対象となった仕事、決定日、および予測の再確認時期を記録しておく必要があります。

この既存のガイドは、「プロジェクトを管理するためのプロジェクトポートフォリオダッシュボードの構築方法」という、より広範なレポート作成に関する疑問の解決に役立ちます。

最初の30日間を仕事のサイクルとして確立する

1日目～7日目： 進行中のプロジェクトとリクエストを洗い出します。それぞれについて、所有者、成果、現在の状況、役割別の次期ウィンドウにおける需要、依存関係、および見積もりの信頼度を把握します。重複しているリクエストや所有者が未定のリクエストについては、そのステータスを推測するのではなく、フラグを立てておきます。

8日目～14日目： 役割の所有者に、総労働時間と控除時間を確認してもらいます。BAU、既知の休暇、研修、サポート、および予備時間を区分します。見積もりがまだ大まかな場合は、範囲または信頼度ラベルを記載しておきます。

15日目～21日目： 現在のポートフォリオと提案されたリクエストを一緒に確認します。期限に縛られたリクエストを守るために優先度の低いワークパッケージを移動させるなど、少なくとも1つの現実的なシナリオを検証します。制約のある各役割への影響を記録します。

22日目～30日目： トレードオフ案を意思決定権限を持つ関係者に提示します。承認された順序、先送りされたアイテム、前提条件、および次回の予測のトリガーを記録します。スコープ、人員配置、休暇、または優先度に変更があった場合は、決定を再検討します。

チームがすでにClickUpで日付指定の作業をプランしている場合、「ワークロードビュー」を使用すると、時間の経過に伴うチームの作業状況やキャパシティを可視化できます。 開始日または期日があり、対応するグループ分けが設定されたタスクがキャンバスに表示され、タスクの作業量は推定工数を表します。空き状況とキャパシティの使用状況はワークスペースの営業日および営業時間を基準としており、休業日はゼロとして扱われます（リソース管理、「ワークロードビューでのタスクの追加と管理」、および「ワークロードビューでの空き状況またはキャパシティの測定」はすべて2026年11月5日に確認済み）。このビューは入力された作業内容を反映するものであり、役割ごとの見積もりの妥当性を検証したり、ポートフォリオのトレードオフを承認したりするものではありません。

PMOは、ワークシートと各チームがすでに管理しているデータから着手できます。プロセスに必要なフィールド、意思決定事項、更新所有者が明確になってから、システムを選択してください。より広範な概要については、「効果的なプロジェクト管理のための2026年ベストPMOツール10選」をご覧ください。本記事では、ベンダーのランキングではなく、キャパシティに関する意思決定に焦点を当てています。

ワークシートをフィールドごとにコピーしてください

各役割および計画期間ごとに1つのキャパシティ行を割り当て、各現行プロジェクトまたは提案されたリクエストごとに1つの需要行を作成します。架空の数値を、実際の見積もりに置き換えてください。

キャパシティのフィールド

必須フィールド

ワークシートを作成する担当者は、各リクエストの横に、見積もりの出典と信頼度を明記する必要があります。信頼度の低い見積もりについては、でっち上げた正確な数値ではなく、範囲を示すか、追って確認を行うべきです。ポートフォリオ所有者は決定事項とトレードオフを記録し、プロジェクトリーダーはプランに変更があった際に、次の期間の需要を更新する必要があります。

チームが繰り返し活用できる決定を下して締めくくります

大規模なポートフォリオのキャパシティ計画は、数値が具体的な選択の余地を示している場合に有効です。この例では、総計には余裕がありますが、プロジェクトマネージャーとエンジニアリングの各レーンには余裕がありません。次のステップは、スケジュールの再調整を承認するか、納期が迫っているリクエストを繰り下げるかです。キャパシティや作業負荷のテンプレートを使用すれば、ワークシートのフィールドを次回のレビューに引き継ぐのに役立ちますが、採用する前に、そのフィールドがPMOに必要な役割や意思決定と合致しているかを確認してください。

テンプレートを入手する。

出典