資源平準化：定義、手順、計算例

資源平準化とは？

資源平準化 は、各資源の需要が利用可能な量を決して超えないようにスケジュールの日付を調整する資源最適化手法です。資源が固定されている場合や不足している場合に使われます。人員の手が空くまで作業を待たせなければならないことがあるため、平準化によってプロジェクトの所要期間が延び、クリティカルパスが変わることがあります。

PMIのPMBOKガイド（第6版）では、資源平準化と資源円滑化をあわせて、スケジュール作成時に使う資源最適化手法として説明しています。英国英語では「levelling」と綴られますが、手法は同じです。

実務では、平準化は次の単純な問いに答えるものです： 実際にいる人員で、この作業は現実的にいつ終えられるのか？ 通常は、人をタスクに割り当てる リソース配分の後に行い、スケジュールが承認されベースラインとして設定される前の最後のステップの1つです。

スケジュールに平準化が必要な理由

タスクの論理関係だけで組み立てたスケジュール（ クリティカルパス法を使ったもの）は、資源が無制限であると仮定しています。 依存関係 が許せば、同じエンジニアに同じ週に4つのタスクを平気で計画してしまいます。実際の名前を割り当てると、ある期間には存在する以上の工数が必要になります。これが 過剰割り当て.

平準化が必要になるのは次のような場合です：

• 同じ人やスキルが重複するタスクに割り当てられている。
• 専門家や設備が他のプロジェクトと共有されている。
• 誰かが退職する、休暇を取る、より優先度の高い作業に異動する。
• スコープは増えたが、チームは増えていない。
• 遅れによって2つの作業が同じ期間に押し込まれる。

過剰割り当てを無視しても、作業が収まるわけではありません。たいていは期日の遅れ、品質の低下、疲弊した人々につながる一方で、スケジュール上はすべて順調であるかのように見え続けます。平準化によってトレードオフが可視化されるため、事後ではなく事前にスポンサーと話し合うことができます。

何に対して平準化するのかを把握しておくことも役立ちます。フルの勤務週ではなく、休暇、会議、サポート業務を差し引いた現実的な稼働可能時間を使いましょう。計算方法は キャパシティプランニング と フルタイム当量（FTE） で解説しています。

資源平準化と資源円滑化の比較

これは最もよく検索される比較であり、試験でもよく出題されます。どちらの手法も資源の需要を形を変えますが、違いは終了日が動くことを許すかどうかです。

覚え方： 平準化は人を守り、円滑化は日付を守る。多くのプロジェクトマネージャーはまず円滑化を試み、それで不十分な場合にのみフロートを超えて平準化します。

資源平準化と関連手法の比較

平準化と混同されがちな手法がほかにもいくつかあります。平準化の前に行うもの、平準化の代わりになるもの、平準化で日付が延びた後に行うものがあります。

ファストトラッキングとクラッシングは スケジュール短縮 の手法であり、平準化の手法ではありません。ただし、一緒に挙げている記事もあります。比較については次で説明しています： ファストトラッキングとクラッシング.

資源平準化の手順

1. 論理関係に基づくスケジュールを作成する。 アクティビティ、所要期間、 先行アクティビティと後続アクティビティを入力し、クリティカルパスとフロートを求めます。
2. 資源を割り当て、空き状況を設定する。 各タスクに各資源がどれだけ必要か、期間ごとにどれだけ利用できるか（たとえば開発者2人、または稼働率80%のデザイナー1人）を記録します。
3. 資源ヒストグラムを描く。 各資源について、1日または1週間ごとの需要をキャパシティの線と対比させてグラフにします。
4. 過剰割り当てになっている期間を見つける。 各期間でどのタスクが重なっているか、それぞれにどれだけのフロートがあるかを記録します。
5. まず円滑化を試す。 クリティカルでないタスクをフロートの範囲内で移動し、終了日を変えずに山を解消できるか確認します。
6. 必要に応じてフロートを超えて平準化する。 優先度の最も低い作業を遅らせる、分割する、または再割り当てし、終了日が遅れるのは必要な場合に限ります。
7. 再計算して確認する。 スケジュールを再計算し、ヒストグラムを再確認して、新しいクリティカルパスを特定します。このクリティカルパスは、論理関係ではなく資源によって決まっている場合があります。
8. 結果に合意し、ベースラインを設定する。 スポンサーにトレードオフを説明し、日付に合意してから、次を設定します： プロジェクトのベースライン.

どのタスクから先に動かすべきか？

複数のタスクが同じ人を取り合う場合、どれを待たせるかのルールが必要です。スケジューリングソフトウェアや計画担当者は、おおむね次の順序で、このような経験則をよく使います：

• 可能であればクリティカルパス上のタスクはそのままにし、 フロートが最も多い タスクから先に動かす。
• ビジネス上の 優先度を尊重する：重要度や緊急度の低い作業を待たせる。
• 原則として、 すでに開始している タスクは、中断と再開による非効率を避けるため継続させる。
• 残りのスケジュールへの影響が少ない 短いタスクを優先して動かす。
• 複雑な分析や設計など、分割すると効率が落ちる作業は中断しない。

計算例：小規模なソフトウェアのスケジュールを平準化する

ある 開発者が2人 のチームが小規模な社内ツールを構築しています。アクティビティは5つで、制約のある資源は開発者だけです。

論理関係が許す限り早くスケジュールすると、AとDは1～3日目と1～2日目、Bは4～7日目、Cは4～6日目、Eは8～9日目に行われます。プロジェクトが終了するのは 9日目の終わりです。クリティカルパスはA、B、Eです。Cのフロートは1日、Dは5日です。

平準化前

4～6日目は、B（2人）とC（1人）が重なるため、計画上3人の開発者が必要です。総工数は18人日です。

円滑化で解決できるか？

円滑化ではフロートしか使えません。Cのフロートは1日しかないため、動かせても5～7日目までで、5、6、7日目にはなおBと重なります。Dは競合に関わっていないため、Dを動かしても効果はありません。 3人目の開発者なしでは、円滑化で過剰割り当てを解消できません。したがって、9日目の終了日を守るにはキャパシティを追加するしかありません。

平準化後

平準化によって、CをBが終わるまで遅らせます。Cは8～10日目に行われ、Cを必要とするEは11～12日目に移ります。

需要が2を超えることはなく、総工数は変わらず18人日ですが、プロジェクトの終了は 12日目となり、3日遅れます。クリティカルパスも変わり、A、B、C、Eになりました。Cは論理関係ではなく開発者を待っているからです。これは資源によって決まるクリティカルパスであり、平準化していない計画では見えません。8日目からは開発者が1人空くため、そのキャパシティを他の作業に提供できます。

プロジェクトマネージャーは、スポンサーに明確な選択肢を示せるようになりました：

どの選択肢を選んだとしても、それは十分な情報に基づいた判断になります。

資源平準化の手法

最初の2つが厳密な意味での平準化です。その他は、遅れが許容できない場合に検討する代替策や補完策です。これらは古典的な プロジェクトの制約に対応しています。時間、コスト、スコープのいずれかを引き換えにすることはできますが、何も引き換えにしないで済むことはまれです。

複数のプロジェクトにわたる資源の平準化

教科書どおりの平準化は1つのスケジュールを対象とします。多くの組織では、人々は複数のプロジェクトと通常業務を掛け持ちしているため、過剰割り当てはプロジェクトを横断して見たときに初めて現れることがよくあります。

• 1つのプロジェクトだけでなく、各人の割り当て全体を表示する共有の作業負荷ビューや資源ビューを使う。
• ポートフォリオの優先順位に合意し、人員が競合したときにどのプロジェクトのタスクを待たせるかを明確にしておく。
• 長期計画では役割やスキルのレベルで、直近の数週間は指名した個人のレベルで平準化する。
• あるプロジェクトの遅れが別のプロジェクトの過負荷を生むことがあるため、定期的に再平準化する。
• 繰り返し起こる競合は、 キャパシティプランニングにフィードバックする。単に需要に対してチームが小さすぎることを意味している場合が多いからです。

当サイトの 複数プロジェクトの管理 では、共有チームが過負荷にならないようにするための幅広い習慣を紹介しています。

プロジェクト管理ソフトウェアでの資源平準化

Microsoft Project

Microsoft Projectには自動平準化の機能があります。Microsoftのドキュメントによると、資源の平準化のオプションには次のものがあります：

• 手動または自動の平準化：手動（既定）では［すべて平準化］を選んだときだけ平準化し、自動では変更によって過剰割り当てが生じるたびに平準化します。
• 過剰割り当てを検出する基準（分単位から月単位まで）。
• 平準化の順序：IDのみ、標準の基準（先行タスク、スラック、日付、優先度、制約）、または優先度を最優先。
• タスクの優先度 は0から1,000で、1,000はそのタスクを決して平準化しないことを意味します。既定値は500です。
• 利用可能なスラックの範囲内でのみ平準化：平準化によって終了日が動かないようにするもので、実質的には円滑化の設定です。
• 平準化で残りの作業を分割できるかどうか 、または個々の割り当てを調整できるかどうか。
• 平準化のクリア：Projectが追加した平準化による遅延と分割を取り除きます。

クラウド型のワークマネジメントツール

クラウド型ツールの多くは、より視覚的な方法を採用しています。作業負荷ビューで割り当てが過剰または不足している人が強調表示され、タスクを別の日付や人にドラッグして再調整します。 Wrike（当サイトで最高評価のツール）は、割り当てが過剰または不足している人を示す作業負荷チャートを備えており、上位プランでは工数配分、職務ロール、キャパシティプランニングも利用できます。Asana、ClickUp、monday.comも作業負荷ビューを提供していますが、一般に有料プランが必要です。

自動平準化の結果を確認する

• まずスケジュールのコピーを平準化し、前後の日付を比較できるようにする。
• クリティカルなタスクや契約上固定されたタスクが予期せず遅れていないか確認する。
• 細かく分割されすぎたタスクがないか探す。そうしたタスクは現実にはうまくいかないことがほとんどです。
• 資源カレンダー（休暇、パートタイムの勤務時間）が正しいことを確認する。誤っていると、間違ったキャパシティに基づいて平準化されてしまいます。

資源平準化の利点と欠点

よくある間違いと実践的なヒント

• 作業開始後に平準化すること。 ベースラインが承認される前に平準化し、その後は何かが変わったときだけ再平準化しましょう。
• 稼働率を100%とすること。 すべての時間をプロジェクトのタスクに費やす人はいません。現実的なキャパシティを使いましょう。
• 自動平準化をそのまま受け入れること。 結果とマイルストーンへの影響を確認しましょう。
• 影響を隠すこと。 平準化によって終了日が動く場合は、上の例のようにスポンサーに伝え、選択肢を示しましょう。
• 競合を避けるために架空の論理関係を作ること。 資源の競合は依存関係ではありません。競合がなくなった後も、偽の関係が作業を遅らせ続けます。
• 1つのプロジェクトだけを切り離して平準化すること （同じ人が他のプロジェクトにも携わっている場合）。
• 人以外の資源を忘れること （テスト環境、設備、会議室なども限られています）。

資源平準化は、 プロジェクトのスケジューリング のガイドで説明しているより広いプロセスの一部であり、次を把握していることが前提になります： プロジェクトのリソース。無料の プロジェクトスケジュールテンプレート と クリティカルパステンプレート は、平準化するスケジュールを作成するのに最適です。

このトピックの無料テンプレート

すべてのテンプレートを見る

よくある質問