ひとことで言うと#
特定の期間やメンバーにリソースが集中する「過負荷」を、タスクの開始時期をずらしたり分割したりして平準化するスケジュール調整手法。スケジュールは延びる可能性があるが、チームの持続的なパフォーマンスを維持できる。
押さえておきたい用語#
- リソースヒストグラム(Resource Histogram)
- 各期間のリソース需要を棒グラフで可視化した図のこと。キャパシティ上限ラインを超える部分が過負荷。
- フロート(Float / Slack)
- タスクを後ろにずらしてもプロジェクト全体の期間に影響しない余裕時間のこと。フロート内の調整ならスケジュール延長なし。
- リソーススムージング(Resource Smoothing)
- フロートの範囲内でのみ調整しプロジェクト期間を変えない平準化手法のこと。レベリングとの違いは期間固定の有無。
- 過負荷(Over-allocation)
- あるメンバーの稼働がキャパシティ上限を超えている状態のこと。品質低下やバーンアウトの原因となる。
リソースレベリングの全体像#
こんな悩みに効く#
- 特定のメンバーだけに作業が集中して疲弊している
- スケジュール上は問題ないのに、実際にはリソースが足りない
- 複数プロジェクトを掛け持ちするメンバーの稼働を最適化したい
基本の使い方#
各期間で必要なリソース量と利用可能なリソース量をグラフ化する。
- タスクごとに必要なリソース(人数・時間)を集計する
- 日・週単位でリソースの需要をヒストグラムにする
- 利用可能な上限ライン(キャパシティ)を引く
ポイント: 上限ラインを超えている期間が「過負荷」。ここを解消するのがリソースレベリングの目的。
過負荷が発生している期間に割り当てられたタスクを洗い出す。
- クリティカルパス上のタスクかどうかを確認する
- フロート(余裕時間)があるタスクを特定する
- 代替リソースで対応可能なタスクがないか検討する
ポイント: フロートがあるタスクを優先的にずらす。クリティカルパス上のタスクは最後の手段。
フロートの範囲内でタスクを後ろにずらし、過負荷を解消する。
- フロートが大きいタスクから順に移動を検討する
- タスクの分割(前半と後半に分ける)も有効な手段
- 調整後もリソースヒストグラムを再確認する
ポイント: フロート内の調整ならプロジェクト全体の期間は変わらない。フロートを超える調整が必要な場合はスケジュール延長を検討する。
調整後のスケジュールを関係者と共有し、合意を得る。
- リソースヒストグラムが上限ライン以下に収まっているか確認
- スケジュール延長が発生する場合はステークホルダーに報告
- 調整によって新たなリスクが生まれていないかチェック
ポイント: リソースレベリングはスケジュールとリソースのトレードオフ。スケジュール優先なら「リソーススムージング」(上限は守りつつ可能な範囲で平準化)を検討する。
具体例#
現状把握: 第3週に設計レビュー・プロトタイプ開発・テスト計画作成が重なり、エンジニアAの稼働が週60時間(上限40時間を超過)。
原因特定:
| タスク | CP上か | フロート | 代替可能か |
|---|---|---|---|
| 設計レビュー | No | 0日 | エンジニアBも対応可 |
| プロトタイプ開発 | Yes | 0日 | Aのみ対応可 |
| テスト計画作成 | No | 2週間 | Cも対応可 |
調整: テスト計画作成を第5週に移動(フロート内)。設計レビューの一部をエンジニアBに委譲。
検証: エンジニアAの第3週の稼働が38時間に収まり、全体スケジュールへの影響もゼロ。過負荷をフロート活用と委譲で解消し、品質と納期を両立した。
背景: IT企業のPM5名が合計12プロジェクトを管理。PM田中さんが3プロジェクトを掛け持ちし、月間稼働が220時間(上限180時間)に達している。
リソースヒストグラム分析(月間):
| 週 | PJ-A | PJ-B | PJ-C | 合計 | 上限超過 |
|---|---|---|---|---|---|
| 第1週 | 25h | 20h | 15h | 60h | +15h |
| 第2週 | 15h | 30h | 10h | 55h | +10h |
| 第3週 | 20h | 15h | 25h | 60h | +15h |
| 第4週 | 10h | 10h | 15h | 35h | なし |
調整策:
- PJ-Bの第2週のキックオフMTG(10h分)を第4週に移動(顧客と調整)
- PJ-Cの第3週のレビュー作業をPM佐藤さんに委譲(15h分)
- PJ-Aの第1週の報告書作成を第4週に分割移動
結果: 田中さんの月間稼働が220時間→175時間に平準化。残業時間が月40時間→ほぼゼロに改善。佐藤さんの稼働も上限内に収まることを確認。
背景: 商業ビル新築工事。80名体制、12ヶ月。電気工事の専門工(8名)が6〜8ヶ月目に集中配置され、月300時間の残業が発生する計画になっていた。
リソースヒストグラム分析: 電気工事は内装工事・設備工事と並行する期間に集中。特に7ヶ月目は電気工8名×週60時間(上限40時間)の計画。
レベリング調整:
| 施策 | 効果 | スケジュール影響 |
|---|---|---|
| 共用部の電気工事を5ヶ月目に前倒し | -80時間/月 | なし(フロート内) |
| テナント部分を8ヶ月目→9ヶ月目に分散 | -60時間/月 | 1週間延長 |
| 外部協力会社から2名追加投入 | -40時間/月 | なし |
Before/After:
| 指標 | 調整前 | 調整後 |
|---|---|---|
| 月間最大残業時間 | 300時間 | 40時間 |
| スケジュール | 12ヶ月 | 12ヶ月1週間 |
| 追加コスト | — | 120万円(外注2名分) |
結果: 1週間のスケジュール延長と120万円の追加コストで、月300時間の残業を解消。労働基準法の上限もクリアし、品質事故のリスクも大幅に低減した。
やりがちな失敗パターン#
- リソースの可視化をせずに感覚で調整する — 「忙しそうだからずらす」では最適化にならない。必ずリソースヒストグラムで定量的に判断する
- クリティカルパス上のタスクを安易にずらす — プロジェクト全体が遅延する。フロートのあるタスクから優先的に調整する
- 一度の調整で完了とする — プロジェクト中にタスクの追加や変更は起きる。定期的にリソース状況を再確認し、再レベリングを行う
- メンバーの稼働率を100%で計画する — 会議、問い合わせ対応、学習の時間を考慮していない。実効稼働率は70〜80%で計算するのが現実的
まとめ#
リソースレベリングは、リソースの過負荷をタスクの時期調整で解消する手法。リソースヒストグラムで需要と供給を可視化し、フロートのあるタスクから順に調整するのが基本。スケジュール延長とのトレードオフを意識しながら、チームの持続可能な働き方を実現する。定期的な再確認と調整が成功の鍵。