リソース平準化とスムージングの違いを解説

Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
リソース平準化とスムージングの議論は、チームの誰かが3週間連続で120%稼働を割り当てられた瞬間に始まります。どちらの手法も過剰配分を解消しますが、そのトレードオフはまったく異なり、選択を誤ると締め切りが崩れたり、チームが疲弊したりします。
リソース平準化とスムージングの違いとは
**リソース平準化(Resource Leveling)**は、過剰配分を解消するためにプロジェクトスケジュールそのものを調整する手法です。タスクを遅らせたり、終了日を後ろ倒しにしたり、場合によってはクリティカルパスすら変えることがあります。**リソーススムージング(Resource Smoothing)**は、利用可能なフロート(余裕時間)の範囲内でリソースの使用状況を調整し、需要のばらつきを平坦にする手法です。こちらはプロジェクトの終了日を一切変更しません。平準化における制約はリソースであり、スムージングにおける制約は締め切りです。
端的に言えば、平準化は締め切りを人に合わせて動かし、スムージングは人を締め切りに合わせて調整します。
重要なポイント
- PMBOKガイド第7版では、リソース平準化とリソーススムージングの両方を「スケジュールの作成」プロセスにおけるスケジュール短縮に関連するツールと位置づけています(PMI、2021年)。
- PMIの「Pulse of the Profession」レポートによると、プロジェクトの48%が当初の目標を達成できておらず、リソースの競合がスケジュール遅延の主要な原因の一つとされています(PMI、2021年)。
- PMIの調査によれば、スケジュール効率指数(SPI)が1.0を下回るプロジェクトは約37%にのぼり、この数値は管理されていないリソースの過剰配分と強く相関しています。
リソース平準化とは
リソース平準化とは、特定期間内でリソースに処理能力を超える作業量が割り当てられている場合の競合を解消するスケジューリング手法です。作業量の急増がほかの方法では解消できないとき、キャパシティが空くまでタスクを遅らせます。
実務上、これは終了日が動く可能性があることを意味します。クリティカルパス法(CPM)は最終締め切りを左右するタスクを示すもので、ボトルネックがまさにクリティカルパス上のタスクにある場合、平準化によってそれらのタスクがずれ込むことがあります。
平準化が適切な選択となるのは、次のような場合です。
- 特定の人材や設備がハードな制約となっている。
- プロジェクトの終了日に交渉の余地がある。
- 過剰配分があまりに深刻で、フローだけでは吸収しきれない。
Microsoft ProjectやPrimaveraのようなスケジューリングツールは、優先順位ルールに基づいて自動的に平準化を適用しますが、そのアルゴリズムの出力にはほぼ必ず人間によるレビューが必要です。自動平準化ツールは、タスクAとタスクBの開始日が同じであっても、Aの方が優先度が高いといった判断はできません。
リソーススムージングとは
リソーススムージングとは、フロートとスラックの範囲内でタスクの開始日・終了日をずらし、リソース需要の山と谷を緩和するスケジューリング手法です。プロジェクトの終了日は一貫して固定されたままです。
スムージングで動かせるのは、フリーフロートまたはトータルフロートを持つタスクに限られます。フロートをすべて使い切ると、リソースがまだ過剰配分の状態であってもスムージングはそこで止まります。これは不具合ではなく、締め切りを明確に守るための仕様です。
スムージングが最も効果を発揮するのは、次のような場合です。
- 契約や外部イベントによって納期が固定されている。
- 過剰配分が中程度で、大半のタスクに十分なフロートがある。
- マイルストーンを動かさずに残業を減らし、外部委託コストを抑えたい。
重要な違いとして、スムージングはすべての過剰配分を必ずしも解消できるとは限りません。プロジェクト全体としてリソースが不足している場合は、スムージングではなく平準化が適切な手段です。
リソース平準化とスムージングの比較
| 項目 | リソース平準化 | リソーススムージング |
|---|---|---|
| 目的 | 過剰配分を完全に解消する | フロートの範囲内で需要のピークを緩和する |
| 終了日への影響 | プロジェクトの終了日を延長する可能性がある | 終了日は保護され、動かない |
| クリティカルパスへの影響 | クリティカルパスが延びたりずれたりする可能性がある | クリティカルパスは変化しない |
| 制約 | リソースの可用性がハードな制約 | プロジェクトの終了日がハードな制約 |
| フローの使用 | ゼロフロートのタスクを含め、すべてのフローを消費し得る | フリーフロートとトータルフローのみを使用 |
| 使用場面 | リソースの上限が厳格で、締め切りに柔軟性がある | 締め切りが厳格で、過剰配分が中程度 |
| リスク | 締め切りの遅延、ステークホルダーとの摩擦 | 一部の過剰配分が未解決のまま残る可能性 |
どちらの手法を使うべきか
判断基準はシンプルです。「何が動かせないか」を問うことです。
リソース平準化を使うべきなのは、リソースこそが唯一動かせない要素である場合です。専門家が週に3日しか稼働できない、クレーンが決められた期間だけレンタルされている、規制当局のレビュアーの予定が固定されている、といったケースです。このような場合、スケジュールはリソースに合わせて調整されるべきであり、終了日は絶対条件ではなく交渉の対象になります。
リソーススムージングを使うべきなのは、締め切りが動かせない場合です。展示会に合わせた製品リリース、規制当局への申請期限、違約金付きの顧客契約など、日付が交渉不可能な状況です。スムージングを使えば、マイルストーンに触れることなくフローの範囲内で作業を再配分できます。
実際の多くのプロジェクトでは、まずスムージングを適用します。これは慎重なアプローチです。フローの範囲内でタスクを調整し、どの程度過剰配分が解消するかを確認したうえで、それでもヒストグラムに山が残る場合にのみ平準化にエスカレーションします。こうすることで、可能な限り長く締め切りを守ることができます。
どちらの手法も、事前にしっかりとしたリソース配分計画と組み合わせて使いましょう。初期スケジュールの過剰配分が少ないほど、平準化やスムージングで必要となる調整も緩やかで済みます。
平準化とスムージングの適用方法
ステップ1: ベースラインスケジュールとリソースヒストグラムを作成する
まず、タスクの依存関係を示す完全なネットワーク図とガントチャートを用意します。そこにリソースヒストグラム、つまり各リソースが1日あたり(または週あたり)何時間(またはどれだけの単位)割り当てられているかを示す棒グラフを重ねます。利用可能なキャパシティを超える棒があれば、それが過剰配分です。
ステップ2: 過剰配分を見つけ出す
各リソースを個別に確認します。週60時間稼働しているプロジェクトマネージャーは過剰配分です。3つの並行タスクに割り当てられた共有QAテスターも過剰配分です。急増を引き起こしているタスクに印をつけます。
ステップ3: 終了日が固定かどうかを判断する
ここが分かれ道です。締め切りが契約上固定されているならスムージングに進みます。ステークホルダーの承認があれば動かせる場合は、平準化も選択肢に入ります。
ステップ4: まずフローの範囲内でスムージングを適用する
過剰配分が発生している各リソースについて、該当するタスクにフリーフロートがあるかを確認します。タスクBに3日分のフローがあるなら、2日遅らせます。この調整により、終了日に触れることなくピークが緩和されます。すべてのリソースについて同様に対応します。作業分解構成図を使って、依存関係を誤って崩していないか確認しましょう。調整後のスケジュールが現実的なチームの限界に収まっているかどうかは、キャパシティプランニングのデータで確認します。
ステップ5: それでもヒストグラムに山が残るなら平準化する
スムージングだけでは過剰配分が完全に解消しない場合、平準化を適用します。優先度の低いタスクを、キャパシティが空くまで遅らせます。終了日はほぼ確実に動きます。新しいベースラインを文書化し、ステークホルダーが自分で気づく前に、日程変更を伝えましょう。
具体例
3人の開発チーム(Alex、Bea、Carlos)が機能リリースに取り組んでいるケースを考えます。当初のスケジュールでは、AlexがタスクCとタスクDに同時に割り当てられており、1週間だけ稼働率が140%に達しています。
スムージング適用前:
| 週 | Alexの稼働率 | タスク |
|---|---|---|
| 1週目 | 100% | タスクA |
| 2週目 | 140% | タスクC + タスクD(重複) |
| 3週目 | 60% | タスクE |
タスクDには4日分のトータルフローがあります。チームはタスクDの開始を3日ずらします。これによりAlexの2週目の稼働率は100%に下がり、余ったフローがその変化を吸収するため、終了日には影響しません。
スムージング適用後:
| 週 | Alexの稼働率 | タスク |
|---|---|---|
| 1週目 | 100% | タスクA |
| 2週目 | 100% | タスクC |
| 3週目 | 100% | タスクD(ずらした後) + タスクE |
もしタスクDにフローが全くなければ、スムージングでは対応できません。その場合チームは平準化を行い、タスクDを3週目まで遅らせ、終了日を2日延長し、クライアントに連絡することになります。
よくある間違い
2つの手法を混同すること。 最もよくある間違いは、この2つの用語を同じ意味で使ってしまうことです。両者は関連していますが別物です。スムージングは過剰配分に対処するという点で平準化の一部と言えますが、締め切りを動かせるのは平準化だけです。
締め切りが固定されているのに平準化を行うこと。 ステークホルダーが契約上のコミットメントをしている場合、承認なしに(終了日を動かし得る)平準化を適用するのは、重大なプロジェクトガバナンスの失敗です。平準化がマイルストーンを動かす前に、必ず承認を得てください。
フローがなくなるまで放置すること。 フローを丁寧に追跡していないチームは、小さなスムージングの判断の積み重ねが、利用可能なバッファをすべて消費してしまったことに手遅れになってから気づきます。8週目には、すべてのタスクがクリティカルパス上にあり、もう調整の余地がなくなっています。フローは計画時だけでなく、継続的に追跡しましょう。
ツールの自動平準化機能に頼りきること。 スケジューリングソフトウェアは優先順位の数値に基づいて平準化アルゴリズムを適用しますが、その数値が実際のビジネス上の優先度を反映していることはほとんどありません。自動平準化されたスケジュールは、共有する前に必ず手動でレビューしましょう。
よくある質問
リソース平準化は終了日を変更しますか?
はい、リソース平準化はプロジェクトの終了日を延長することがあり、実際によく起こります。過剰配分を解消するためにタスクが遅延すると、クリティカルパス上のタスクがずれ込み、最終的なマイルストーンが後ろ倒しになることがあります。だからこそ、固定されたマイルストーンに平準化を適用する前には、必ずステークホルダーの承認が必要なのです。
スムージングは平準化の前と後、どちらに行うべきですか?
スムージングは常に先に行うべきです。締め切りを維持したまま既存のフローだけを使う、リスクの低い選択肢だからです。スムージングだけで過剰配分が完全に解消しない場合に、平準化へとエスカレーションします。平準化を先に行ってしまうと、締め切りを守れたかもしれないステップを飛ばしてしまうことになります。
どちらの手法がクリティカルパスに影響しますか?
リソース平準化はクリティカルパスを変える可能性があります。クリティカルでないタスクがフローを超えて遅延すると、そのタスクがクリティカルになることがあります。リソーススムージングは、既存のフローの範囲内でしかタスクを動かさないため、クリティカルパスには影響しません。
同じプロジェクトで両方の手法を使えますか?
はい、使えます。一般的なアプローチとしては、フローのあるすべてのタスクにまずスムージングを適用し、それでも残る過剰配分に対して平準化を適用します。その結果、フローでは対応しきれなかったリソースの競合に対処しつつ、可能な限り締め切りを守るスケジュールが得られます。
スムージングを行っても過剰配分が残ってしまう場合はどうすればよいですか?
スムージングによってすべての過剰配分が必ず解消されるわけではありません。フローが不足していれば、スムージング後も一部のピークが残ることがあります。その場合の選択肢は3つです。平準化を適用して日程のずれを受け入れる、キャパシティを増やすためにリソースを追加する、あるいは需要を減らすためにスコープを縮小する、のいずれかです。
リソース平準化とスムージングは、どちらかを選ぶという競合する選択肢ではありません。それぞれ明確な役割を持つ、順序立てて使うべきツールです。スムージングは締め切りを守り、平準化はチームを守ります。まずスムージングから始め、何が残るかを確認したうえで、スムージングでは解決できない部分だけを平準化しましょう。
