クリティカルパスとCCPM|依存関係・余裕・バッファから遅延を判断する
一つの作業が三日遅れたとき、プロジェクト全体も三日遅れるとは限りません。逆に、長い作業を短縮しても完了日は変わらないことがあります。作業の依存関係をたどり、最早・最遅の時刻と余裕を計算すると、どこが全体を制約しているかを説明できます。担当者を共用する場合は資源の制約も必要です。
この記事で理解すること
前進・後退計算からクリティカルパスとトータル・フリーフロートを求める。
合流点の遅延、複数経路、短縮後の経路変化を判断する。
CPMと資源制約、CCPMのプロジェクト・合流・資源バッファを区別する。
WBSとスコープの合意は計画・変更管理の記事で扱います。ここでは受注システムの小さな変更プロジェクトを例に、日程の仕組みを中心にします。全作業は独自の教材例です。
作業の条件を固定してネットワークを描く
開始を時刻0とし、日数は同じ稼働日の単位で数えます。先行作業がすべて終わると後続が開始できる、終了‐開始関係です。待ち時間や開始日の外部制約はなく、まず異なる作業を並行実施できるだけの担当者がいると仮定します。
作業 | 内容 | 所要日数 | 先行作業 |
|---|---|---|---|
A | 設計方針の確定 | 2 | なし |
B | 機能設計 | 4 | A |
C | 移行設計 | 3 | A |
D | 機能実装 | 5 | B |
E | 移行準備 | 2 | C |
F | 結合確認 | 3 | D・E |
G | 受入確認 | 1 | F |
- 1. 完了後
- 2. 完了後
- 3. 完了後
- 4. 完了後
- 5. 両方を待つ
- 6. 両方を待つ
各数字は所要日数です。最後の枠はFとGの直列2作業をまとめています。矢印は完了を待つ依存関係を示し、期間の実寸ではありません。
全作業の所要日数の和は20日ですが、並行するBとC等を足した20日は最短の全体期間ではありません。開始から終了までの経路はA→B→D→F→Gが15日、A→C→E→F→Gが11日です。長い経路が完了までの下限を決めます。
前進計算:合流では最大を取る
最早開始時刻ESは先行作業の最早終了EFの最大、EFはES+所要日数です。先行がないAはES0、EF2です。BはES2、EF6、CはES2、EF5となります。DはEF11、EはEF7です。
FはDとEの両方が必要なのでES=max(11,7)=11、EF14です。GはES14、EF15です。合流で最小7を選ぶと、まだDが終わっていないのに結合確認を始める矛盾が生じます。
後退計算:分岐では最小を取る
全体の完了目標を最早完了15に置き、Gの最遅終了LF15、最遅開始LS14とします。LFは後続作業のLSの最小、LSはLF−所要日数です。FのLF14・LS11、DのLF11・LS6、EのLF11・LS9です。
BはLF6・LS2、CはLF9・LS6です。AはBとCへ分岐するのでLF=min(2,6)=2、LS0です。大きい6を選ぶと、Bを最遅開始2までに始められず全体が延びます。分岐先をすべて満たす側の値を選びます。
作業 | 日数 | 先行 | ES | EF | LS | LF | TF | FF |
|---|---|---|---|---|---|---|---|---|
A | 2 | — | 0 | 2 | 0 | 2 | 0 | 0 |
B | 4 | A | 2 | 6 | 2 | 6 | 0 | 0 |
C | 3 | A | 2 | 5 | 6 | 9 | 4 | 0 |
D | 5 | B | 6 | 11 | 6 | 11 | 0 | 0 |
E | 2 | C | 5 | 7 | 9 | 11 | 4 | 4 |
F | 3 | D・E | 11 | 14 | 11 | 14 | 0 | 0 |
G | 1 | F | 14 | 15 | 14 | 15 | 0 | 0 |
TFはトータルフロート、FFはフリーフロートです。表の時刻は日付ではなく、開始0から経過した稼働日の境界です。「第1日を時刻1」と混ぜると一日ずれるため、単位と基準を先に固定します。
二種類の余裕と、クリティカルパス
TF=LS−ES=LF−EFは、他の作業の時刻を調整できるとして全体の完了を遅らせない余裕です。FFは、後続作業の最早開始を遅らせない余裕で、後続ESの最小−自分のEFです。CはTF4ですがFF0、EはTF4・FF4となります。
Cの遅れでEの開始は動いても、Fの開始11までにEが終われば全体は維持できます。
CとEのTF4を足して8日遅らせてよいわけではありません。二つは同じ枝の4日の余裕を共有しています。TFが0のA・B・D・F・Gをつなぐ経路が、この条件でのクリティカルパスです。外部の完了制約等がある一般のネットワークでは負の余裕等もあり、条件を読み直します。
遅延と短縮は、変更後に再計算する
Cの所要日数が3から6へ増えると、CのEF8、EのEF10となり、Fは依然11開始、完了15です。Cが3から8へ増えるとEのEF12なのでFのES12、全体完了16です。短い枝の余裕4を超える部分だけが全体へ影響します。
Dを5から3へ短縮すると、長い経路は13日、もう一方は11日なので全体は13日です。Dを1まで短縮すると両経路とも11日になります。さらにDだけを短縮しても、C・E側の11日が残るため全体は短くなりません。クリティカルパスは固定の属性ではなく、条件の変更で変わります。
クラッシングは追加資源・費用等で期間を短縮し、ファストトラッキングは本来順に行う作業の一部を重ねる方法です。人を二倍にすれば必ず期間が半分とは限りません。重ねてよい成果物と承認条件、手戻り、追加費用と品質への影響を評価します。
資源制約:依存関係だけでは実行可能とは限らない
DとEを同じ専門担当者一人が実施すると、元の時刻ではDの6〜11とEの5〜7が重なります。技術的には並行できる作業でも、担当者が同時に二つを実行できなければ、この日程は実行できません。
一案としてDを6〜11に先に実施し、Eを11〜13へ置けば、Fは13〜16、Gは16〜17です。Eを5〜7に先行させ、Dを7〜12へ置く案なら完了16です。資源の割付順で日程が変わるので、17日を最適解とは断定しません。資源平準化で変わった依存・時刻を再計算します。
CCPMと三つのバッファ
クリティカルチェーンは、作業間の依存に加えて資源の制約を考え、完了を制約する連鎖を捉えます。CCPMはこの連鎖と集中したバッファを管理する考え方です。個々の作業に安全時間を隠して積み上げるだけでなく、合流や全体の完了を守る場所へ余裕をまとめます。
種類 | 置く場所・役割 |
|---|---|
プロジェクトバッファ | クリティカルチェーンの終端側で全体の完了を保護 |
合流バッファ/フィーディングバッファ | 非クリティカルな枝がチェーンへ合流する前で遅れを吸収 |
資源バッファ | 必要資源を開始時に用意する警告・準備。単なる待ち日数とは限らない |
トータルフロートはネットワークの時刻から求める余裕で、管理上配置するバッファとは同じものではありません。バッファの大きさも、常に各作業の半分を足せばよいという規則ではありません。不確実性と手法の前提を確認して設定します。
チェーンの実行を進め、バッファの消費を監視します。教材例としてバッファ4日のうち1日を消費したなら25%です。チェーンの進捗との関係を見て警戒や是正を決めます。25%という一数値だけで危険や安全を決めず、残り作業と消費の傾向を確認します。
遅延対策を答案にする
答案は「どの経路のどの作業に、何日分の余裕があり、後続と全体のどちらへ影響するか」を示します。対策は担当者・実行順・変更可能な依存と費用を具体化します。根拠のない残業や増員という一般論では、変更後の日程が成立する説明になりません。
管理時には残期間、実際の完了、依存と資源の変化を更新して再計算します。EVMの進捗差異は予算単位なので、直接の遅延日数ではありません。全体の完了予測は、ここで扱うネットワークと現時点の残作業を併せて判断します。
演習1:全体期間
条件:掲載の全作業20日分を、依存関係を守って並行実行できる。
問い:最早完了と経路を答える。
解答例:15日、A→B→D→F→G。
根拠と誤答の確認:全作業の和ではなく開始から完了までの最長経路です。
演習2:合流の開始
条件:Dは時刻11、Eは時刻7に終了する。Fは両方が先行。
問い:Fの最早開始はいつか。
解答例:時刻11。
根拠と誤答の確認:どちらも終える必要があるので最大値を取ります。
演習3:余裕の違い
条件:CのES2・EF5、LS6。後続EのES5。
問い:CのTFとFFを求める。
解答例:TF4日、FF0日。
根拠と誤答の確認:全体を遅らせなくてもEの最早開始を遅らせる場合があります。
演習4:遅延の影響
条件:他の条件を変えず、Cの所要日数を3から8へ増やす。
問い:全体の最早完了はいつか。
解答例:16日。
根拠と誤答の確認:C終了10、E終了12、F終了15、G終了16です。余裕4を1日超えます。
演習5:短縮の限界
条件:Dを5から1へ短縮すると、二つの経路はいずれも11日。
問い:Dだけをさらに短縮すれば全体も短くなるか。
解答例:ならない。C・E側の11日の経路も短縮しないと全体は11日を下回れない。
根拠と誤答の確認:クリティカルパスが複数になった状態を確認します。
演習6:資源とバッファ
条件:DとEの専門担当者が同じ一人になった。
問い:元のCPMの時刻表だけで実施可能といえるか。
解答例:いえない。重なる作業を資源制約で配置し直し、チェーンとバッファを検討する。
根拠と誤答の確認:依存関係上の並行可能性と、資源の同時利用可能性は違います。
参照資料とこの記事の範囲
事例・数値・図・演習は独自に作成した教材です。用語の範囲はIPAシラバス、仕組みは以下の一次資料で確認しました。特定年度の問題を読んでいなくても学べます。製品固有の動作と一般的な原理は本文で区別します。
GAO:Schedule Assessment Guide(前進・後退、余裕、資源、更新)
PMI:Critical path or chain or both
PMI:Resource buffer management
関連テーマを続けて学ぶ
プロジェクト計画と変更管理|スコープ・WBS・関係者の合意をつなぐ
この記事についてAIに深掘り質問する
ChatGPT、Claude、Perplexityにこの記事を参照させ、要点の確認や疑問点を自由に質問できます。
次におすすめの学習
編集・検証について
編集・検証:IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る