リソースレベリング

英語名 Resource Leveling
読み方 リソース レベリング
難易度
所要時間 数時間
提唱者 プロジェクトマネジメント実務から発展(1960年代〜)
目次

ひとことで言うと
#

特定の期間やメンバーにリソースが集中する「過負荷」を、タスクの開始時期をずらしたり分割したりして平準化するスケジュール調整手法。スケジュールは延びる可能性があるが、チームの持続的なパフォーマンスを維持できる。

押さえておきたい用語
#

押さえておきたい用語
リソースヒストグラム(Resource Histogram)
各期間のリソース需要を棒グラフで可視化した図のこと。キャパシティ上限ラインを超える部分が過負荷。
フロート(Float / Slack)
タスクを後ろにずらしてもプロジェクト全体の期間に影響しない余裕時間のこと。フロート内の調整ならスケジュール延長なし。
リソーススムージング(Resource Smoothing)
フロートの範囲内でのみ調整しプロジェクト期間を変えない平準化手法のこと。レベリングとの違いは期間固定の有無。
過負荷(Over-allocation)
あるメンバーの稼働がキャパシティ上限を超えている状態のこと。品質低下やバーンアウトの原因となる。

リソースレベリングの全体像
#

リソースレベリング:可視化→特定→調整→検証の4ステップ
① 需要と供給を可視化リソースヒストグラムで過負荷期間を可視化する② 原因タスクを特定フロートの有無・CP上か代替リソースの可能性を確認④ 調整結果を検証・合意ヒストグラムが上限以下か確認スケジュール影響をSHに報告③ タスクを調整するフロートのあるタスクから開始時期をずらす・分割する持続可能なペースを守るスケジュールとリソースのトレードオフ
リソースレベリングの進め方フロー
1
リソース可視化
各期間のリソース需要と供給をヒストグラムで可視化し、過負荷期間を特定する
2
原因タスク特定
過負荷期間のタスクを洗い出し、フロートの有無と代替リソースを確認する
3
スケジュール調整
フロートのあるタスクから開始時期をずらし、必要に応じてタスクを分割する
検証・合意
ヒストグラムが上限以下に収まったことを確認し、関係者と合意を得る

こんな悩みに効く
#

  • 特定のメンバーだけに作業が集中して疲弊している
  • スケジュール上は問題ないのに、実際にはリソースが足りない
  • 複数プロジェクトを掛け持ちするメンバーの稼働を最適化したい

基本の使い方
#

ステップ1: リソースの需要と供給を可視化する

各期間で必要なリソース量と利用可能なリソース量をグラフ化する

  • タスクごとに必要なリソース(人数・時間)を集計する
  • 日・週単位でリソースの需要をヒストグラムにする
  • 利用可能な上限ライン(キャパシティ)を引く

ポイント: 上限ラインを超えている期間が「過負荷」。ここを解消するのがリソースレベリングの目的。

ステップ2: 過負荷の原因タスクを特定する

過負荷が発生している期間に割り当てられたタスクを洗い出す

  • クリティカルパス上のタスクかどうかを確認する
  • フロート(余裕時間)があるタスクを特定する
  • 代替リソースで対応可能なタスクがないか検討する

ポイント: フロートがあるタスクを優先的にずらす。クリティカルパス上のタスクは最後の手段。

ステップ3: タスクの開始時期を調整する

フロートの範囲内でタスクを後ろにずらし、過負荷を解消する

  • フロートが大きいタスクから順に移動を検討する
  • タスクの分割(前半と後半に分ける)も有効な手段
  • 調整後もリソースヒストグラムを再確認する

ポイント: フロート内の調整ならプロジェクト全体の期間は変わらない。フロートを超える調整が必要な場合はスケジュール延長を検討する。

ステップ4: 調整結果を検証・合意する

調整後のスケジュールを関係者と共有し、合意を得る

  • リソースヒストグラムが上限ライン以下に収まっているか確認
  • スケジュール延長が発生する場合はステークホルダーに報告
  • 調整によって新たなリスクが生まれていないかチェック

ポイント: リソースレベリングはスケジュールとリソースのトレードオフ。スケジュール優先なら「リソーススムージング」(上限は守りつつ可能な範囲で平準化)を検討する。

具体例
#

例1:5人チームでのWeb開発プロジェクトのリソース平準化

現状把握: 第3週に設計レビュー・プロトタイプ開発・テスト計画作成が重なり、エンジニアAの稼働が週60時間(上限40時間を超過)。

原因特定:

タスクCP上かフロート代替可能か
設計レビューNo0日エンジニアBも対応可
プロトタイプ開発Yes0日Aのみ対応可
テスト計画作成No2週間Cも対応可

調整: テスト計画作成を第5週に移動(フロート内)。設計レビューの一部をエンジニアBに委譲。

検証: エンジニアAの第3週の稼働が38時間に収まり、全体スケジュールへの影響もゼロ。過負荷をフロート活用と委譲で解消し、品質と納期を両立した。

例2:3プロジェクト掛け持ちのPMの稼働を最適化する(IT企業・PM5名)

背景: IT企業のPM5名が合計12プロジェクトを管理。PM田中さんが3プロジェクトを掛け持ちし、月間稼働が220時間(上限180時間)に達している。

リソースヒストグラム分析(月間):

PJ-APJ-BPJ-C合計上限超過
第1週25h20h15h60h+15h
第2週15h30h10h55h+10h
第3週20h15h25h60h+15h
第4週10h10h15h35hなし

調整策:

  • PJ-Bの第2週のキックオフMTG(10h分)を第4週に移動(顧客と調整)
  • PJ-Cの第3週のレビュー作業をPM佐藤さんに委譲(15h分)
  • PJ-Aの第1週の報告書作成を第4週に分割移動

結果: 田中さんの月間稼働が220時間→175時間に平準化。残業時間が月40時間→ほぼゼロに改善。佐藤さんの稼働も上限内に収まることを確認。

例3:建設プロジェクト(80名・12ヶ月)で専門工の稼働を平準化する

背景: 商業ビル新築工事。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時間の残業を解消。労働基準法の上限もクリアし、品質事故のリスクも大幅に低減した。

やりがちな失敗パターン
#

  1. リソースの可視化をせずに感覚で調整する — 「忙しそうだからずらす」では最適化にならない。必ずリソースヒストグラムで定量的に判断する
  2. クリティカルパス上のタスクを安易にずらす — プロジェクト全体が遅延する。フロートのあるタスクから優先的に調整する
  3. 一度の調整で完了とする — プロジェクト中にタスクの追加や変更は起きる。定期的にリソース状況を再確認し、再レベリングを行う
  4. メンバーの稼働率を100%で計画する — 会議、問い合わせ対応、学習の時間を考慮していない。実効稼働率は70〜80%で計算するのが現実的

まとめ
#

リソースレベリングは、リソースの過負荷をタスクの時期調整で解消する手法。リソースヒストグラムで需要と供給を可視化し、フロートのあるタスクから順に調整するのが基本。スケジュール延長とのトレードオフを意識しながら、チームの持続可能な働き方を実現する。定期的な再確認と調整が成功の鍵。