スケジュール遅延のリカバリ方法とリカバリ計画の書き方

スケジュール遅延のリカバリとは、遅れた日数を「どの作業を、どの手段で、いくらかけて、何日縮めるか」に分解し、新しい完了日と判定日を書面で合意することです。 人を足す、残業する、といった打ち手を思いつきで選ぶ前に、縮めて効果が出る作業を計算で絞り込むと、少ない追加費用で日数を取り戻せます。

この記事では、架空の「備品予約システムの開発」を題材に、6作業の作業表からコストスロープ（1日縮めるための追加費用）を求めて縮める順番を決める手順を、Pythonのコードと実行結果つきで示します。あわせて、4つの手段の選び方の早見表と、そのまま貼って使えるリカバリ計画書のテンプレート・記入例を載せます。クリティカルパスの求め方やEVMの指標そのものには踏み込まず、「遅れが分かった後に何を計算し、何を提出するか」に範囲を絞っています。

確認環境：Python 3.11（標準ライブラリのみ、Linux）。記事中の日数・費用・日付はすべてこのコードの実行結果です。確認日は 2026-10-05 です。

この記事の結論

• 縮める対象は、クリティカルパス（全体の日数を決めている経路）上の作業だけです。それ以外の作業をいくら安く縮めても、完了日は1日も動きません。
• その中で、コストスロープ（短縮1日あたりの追加費用）が最小の作業から1日ずつ縮めます。 1日縮めるたびにクリティカルパスを求め直します。
• 費用をかけたくないならファストトラッキング、費用も手戻りも避けたいならスコープ削減、どれでも届かない分は納期再交渉と、条件で手段を選びます。
• リカバリ計画書には、遅延日数・原因・対策・短縮見込み・新しい完了日・判定日の6点を書きます。判定日は「この日に届いていなければ次の手に切り替える」日です。

スケジュール遅延リカバリの早見表

リカバリの手順（6ステップ）

手順2で原因が今後も続くもの（例：仕様の確定待ちが続く）だと分かった場合は、縮める計算の前にその原因を止める対策を先に置きます。原因が残ったまま日数だけ縮めても、同じ幅でまた遅れるためです。

用語：クリティカルパスとコストスロープ

例題：6日の遅れを取り戻す

題材は備品予約システムの開発です。実装の途中で仕様の確認に時間がかかり、残作業を積み直したところ29日（営業日）かかると分かりました。当初の完了日までの残りは23日なので、遅延は6日です。

作業表（標準と特急）

表計算ソフトに貼るときは次のタブ区切り版を使います。

記号  作業  先行作業    標準日数    特急日数    標準費用    特急費用
A   予約API実装     10  7   100 130
B   画面実装        14  11  140 185
C   通知機能実装  A   6   4   60  72
D   結合テスト   B,C 8   5   80  125
E   利用者マニュアル    B   5   3   30  36
F   受入テスト支援 D,E 5   4   50  70

経路は3本あります。

コストスロープが最も小さいのは E（3万円/日）ですが、E はクリティカルパス上にありません。最初に縮めるのは、クリティカルパス上で最も安い C（6万円/日）です。

Pythonで縮める順番を求める

次のコードは、1日縮めるたびにクリティカルパスを求め直し、最も安く1日縮められる作業（経路が複数あるときは作業の組み合わせ）を選びます。最後に全組み合わせを調べて、同じ追加費用になるかを検算しています。

# crash.py : クリティカルパス上の作業を、コストスロープの小さい順に1日ずつ縮める
# Python 3.11、標準ライブラリのみ
from itertools import combinations, product

# 作業: (名前, 標準日数, 特急日数, 標準費用[万円], 特急費用[万円], 先行作業)
TASKS = {
    "A": ("予約API実装",       10, 7, 100, 130, []),
    "B": ("画面実装",          14, 11, 140, 185, []),
    "C": ("通知機能実装",       6, 4,  60,  72, ["A"]),
    "D": ("結合テスト",         8, 5,  80, 125, ["B", "C"]),
    "E": ("利用者マニュアル",   5, 3,  30,  36, ["B"]),
    "F": ("受入テスト支援",     5, 4,  50,  70, ["D", "E"]),
}
TARGET = 23  # 残り日数の目標（営業日）


def slope(k):
    _, std, crash, c_std, c_crash, _ = TASKS[k]
    return (c_crash - c_std) / (std - crash)


def finish(days):
    """前進計算で全体の所要日数を返す"""
    ef = {}
    for k in TASKS:  # 先行作業が先に並ぶ順で定義している
        ef[k] = max((ef[p] for p in TASKS[k][5]), default=0) + days[k]
    return max(ef.values())


def critical(days):
    """余裕0の作業（クリティカルパス上の作業）を返す"""
    total = finish(days)
    return [k for k in TASKS if finish({**days, k: days[k] + 1}) > total]


print("== コストスロープ ==")
for k, (name, std, crash, c_std, c_crash, _) in TASKS.items():
    print(f"{k} {name:<10} 短縮可能 {std - crash}日  ({c_crash}-{c_std})/({std}-{crash}) = {slope(k):.1f} 万円/日")

days = {k: v[1] for k, v in TASKS.items()}
print(f"\n標準日数のまま: {finish(days)}日  クリティカル: {''.join(critical(days))}  目標: {TARGET}日")

print("\n== 1日ずつ縮める ==")
added = 0
while finish(days) > TARGET:
    now = finish(days)
    cands = [k for k in critical(days) if days[k] > TASKS[k][2]]
    best = None
    # 経路が複数あるときは、同時に縮める作業の組み合わせも候補にする
    for r in range(1, len(cands) + 1):
        for combo in combinations(cands, r):
            trial = {**days, **{k: days[k] - 1 for k in combo}}
            if finish(trial) == now - 1:
                cost = sum(slope(k) for k in combo)
                if best is None or cost < best[0]:
                    best = (cost, combo)
    if best is None:
        print("これ以上は縮められません")
        break
    cost, combo = best
    for k in combo:
        days[k] -= 1
    added += cost
    print(f"{'+'.join(combo)} を1日短縮 (+{cost:.0f}万円) -> {finish(days)}日  クリティカル: {''.join(critical(days))}  累計 +{added:.0f}万円")

print("\n結果:", {k: f"{TASKS[k][1]}->{days[k]}" for k in TASKS if days[k] != TASKS[k][1]}, f"追加費用 {added:.0f}万円")

# 検算1: 全組み合わせを調べて最小の追加費用を求める
best_all = min(
    (sum((TASKS[k][1] - d) * slope(k) for k, d in zip(TASKS, combo)), combo)
    for combo in product(*[range(v[2], v[1] + 1) for v in TASKS.values()])
    if finish(dict(zip(TASKS, combo))) <= TARGET
)
print(f"検算（全{len(list(product(*[range(v[2], v[1] + 1) for v in TASKS.values()])))}通り）: 最小の追加費用 {best_all[0]:.0f}万円  日数 {dict(zip(TASKS, best_all[1]))}")

# 検算2: クリティカルパスを見ずに、スロープが小さい順に限界まで縮めた場合
days2 = {k: v[1] for k, v in TASKS.items()}
added2 = 0
print("\n== 参考: 経路を見ずにスロープの小さい順に縮めた場合 ==")
for k in sorted(TASKS, key=slope):
    if finish(days2) <= TARGET:
        break
    cut = TASKS[k][1] - TASKS[k][2]
    days2[k] -= cut
    added2 += cut * slope(k)
    print(f"{k} を{cut}日短縮 (+{cut * slope(k):.0f}万円) -> {finish(days2)}日  累計 +{added2:.0f}万円")

実行結果です（python3 crash.py）。

== コストスロープ ==
A 予約API実装    短縮可能 3日  (130-100)/(10-7) = 10.0 万円/日
B 画面実装       短縮可能 3日  (185-140)/(14-11) = 15.0 万円/日
C 通知機能実装     短縮可能 2日  (72-60)/(6-4) = 6.0 万円/日
D 結合テスト      短縮可能 3日  (125-80)/(8-5) = 15.0 万円/日
E 利用者マニュアル   短縮可能 2日  (36-30)/(5-3) = 3.0 万円/日
F 受入テスト支援    短縮可能 1日  (70-50)/(5-4) = 20.0 万円/日

標準日数のまま: 29日  クリティカル: ACDF  目標: 23日

== 1日ずつ縮める ==
C を1日短縮 (+6万円) -> 28日  クリティカル: ACDF  累計 +6万円
C を1日短縮 (+6万円) -> 27日  クリティカル: ABCDF  累計 +12万円
D を1日短縮 (+15万円) -> 26日  クリティカル: ABCDF  累計 +27万円
D を1日短縮 (+15万円) -> 25日  クリティカル: ABCDF  累計 +42万円
D を1日短縮 (+15万円) -> 24日  クリティカル: ABCDEF  累計 +57万円
F を1日短縮 (+20万円) -> 23日  クリティカル: ABCDEF  累計 +77万円

結果: {'C': '6->4', 'D': '8->5', 'F': '5->4'} 追加費用 77万円
検算（全1152通り）: 最小の追加費用 77万円  日数 {'A': 10, 'B': 14, 'C': 4, 'D': 5, 'E': 5, 'F': 4}

== 参考: 経路を見ずにスロープの小さい順に縮めた場合 ==
E を2日短縮 (+6万円) -> 29日  累計 +6万円
C を2日短縮 (+12万円) -> 27日  累計 +18万円
A を3日短縮 (+30万円) -> 27日  累計 +48万円
B を3日短縮 (+45万円) -> 24日  累計 +93万円
D を3日短縮 (+45万円) -> 21日  累計 +138万円

結果の読み方

• 2回目で経路が2本そろいます。 C を2日縮めた時点で A→C→D→F と B→D→F がどちらも27日になります。ここから先は A だけ縮めても B→D→F が27日のまま残るので、両方の経路に乗っている D か F を縮めるか、A と B を同時に縮める（10 + 15 = 25万円/日）ことになります。D（15万円/日）が最も安いので D を選びます。
• 5回目で3本目の経路もそろいます。 B→E→F も24日になり、全作業がクリティカルになります。余裕がなくなるので、以降は小さな遅れがそのまま完了日に響きます。
• 追加費用の合計は77万円（C 12万円 + D 45万円 + F 20万円）で、全1152通りを調べた最小値と一致しました。
• 経路を見ずにスロープの小さい順に限界まで縮めると、E の6万円は日数に効かず、23日以内に届くまでに138万円かかりました（21日まで縮み、必要以上に費用をかけた形です）。

ファストトラッキングは期待値で見積もる

ファストトラッキングは費用がかからない代わりに、前の作業の変更が後ろの作業に波及して手戻りになることがあります。短縮見込みは「重ねた日数」ではなく、手戻りを含めた期待値で書くと判断しやすくなります。次は、D（結合テスト）を C（通知機能実装）の完了3日前から始める場合の計算です。

# ft.py : ファストトラッキングの短縮見込みを、手戻りを含めた期待値で見る
overlap = 3        # D（結合テスト）を C（通知機能実装）の完了3日前から始める
p_rework = 0.4     # 手戻りが起きる見込み（チームで見積もった値）
rework_days = 4    # 手戻りが起きたときのやり直し日数
expected = overlap - p_rework * rework_days
print(f"手戻りなし: {overlap}日短縮 / 手戻りあり: {overlap - rework_days}日 / 期待値: {expected:.1f}日短縮")

手戻りなし: 3日短縮 / 手戻りあり: -1日 / 期待値: 1.4日短縮

手戻りが起きる見込みを4割と置くと、3日重ねても期待できる短縮は1.4日で、手戻りが起きた場合はかえって1日延びます。リカバリ計画書の短縮見込みには、最良の値（3日）ではなく、期待値と最悪の値を並べて書きます。 手戻りの見込みを下げるには、重ねる前に前の作業の成果物のうち「もう変えない部分」（画面項目、APIの入出力など）を決めて書き出しておく方法が有効です。

完了日と判定日を日付に直す

日数を日付に直すときは、土日を除いて数えます。次のコードは開始日を1日目として数えています。祝日や会社の休日は含めていないので、使うときは自社のカレンダーに合わせて調整してください（下の結果は土日だけを除いた日付です）。

# dates.py : 営業日（土日を除く）で完了日を求める
from datetime import date, timedelta

def add_workdays(start, n):
    """start を1日目として n 営業日目の日付を返す"""
    d, count = start, 1
    while count < n:
        d += timedelta(days=1)
        if d.weekday() < 5:
            count += 1
    return d

start = date(2026, 10, 6)
for label, n in [("当初の完了日（残り23日）", 23), ("対策なしの完了日（29日）", 29),
                 ("判定日（10日目）", 10)]:
    d = add_workdays(start, n)
    print(label, d.isoformat(), "月火水木金土日"[d.weekday()])

当初の完了日（残り23日） 2026-11-05 木
対策なしの完了日（29日） 2026-11-13 金
判定日（10日目） 2026-10-19 月

4つの手段の違いと選び方

クラッシングとファストトラッキングは混同されやすいので、違いを先に整理します。

どれを使うかは、次の条件で決めます。上から順に当てはめ、足りない分を次の手段で補います。

納期再交渉は最後の手段として扱われがちですが、交渉する日数を「全部」ではなく「他の手段で届かない残り」に絞ると合意しやすくなります。例題なら「6日の遅延のうち4日は自分たちで取り戻し、2日だけ完了日を動かしたい」という形です。

リカバリ計画書のテンプレート

そのまま貼って使えるMarkdownのテンプレートです。A4で1〜2枚に収まる量にしています。

# リカバリ計画書

- 対象：
- 作成日：　　作成者：　　承認者：
- 版：

## 1. 現状
- 当初の完了日：
- 対策をとらない場合の完了日：
- 遅延日数：　　日（営業日）
- 遅れている作業：

## 2. 原因
| No | 原因 | 今後も続くか | 止めるための対処 |
|---|---|---|---|
| 1 |  |  |  |

## 3. 対策
| No | 手段 | 対象の作業 | 内容 | 短縮見込み（日） | 追加費用 | 担当 | 開始日 |
|---|---|---|---|---|---|---|---|
| 1 |  |  |  |  |  |  |  |

- 短縮見込みの合計：　　日
- 追加費用の合計：

## 4. 新しい完了日
- 新しい完了日：
- 当初の完了日との差：　　日

## 5. 判定日と切り替え
| 判定日 | 確認すること（達成の基準） | 届いていない場合の次の手 |
|---|---|---|
|  |  |  |

## 6. 対策に伴うリスク
| No | リスク | 兆候 | 対応 |
|---|---|---|---|
| 1 |  |  |  |

## 7. 合意してほしいこと
- 

対策の表だけを表計算ソフトで管理する場合のタブ区切り版です。

No  手段  対象の作業   内容  短縮見込み（日）    追加費用    担当  開始日
1                           

各項目の書き方

記入例：備品予約システムの開発

例題の計算結果を計画書に落とした記入例です。人名・日付・金額は架空です。

# リカバリ計画書

- 対象：備品予約システムの開発
- 作成日：2026-10-05　　作成者：佐藤　　承認者：鈴木
- 版：1.0

## 1. 現状
- 当初の完了日：2026-11-05
- 対策をとらない場合の完了日：2026-11-13
- 遅延日数：6日（営業日）
- 遅れている作業：予約API実装（A）、通知機能実装（C）

## 2. 原因
| No | 原因 | 今後も続くか | 止めるための対処 |
|---|---|---|---|
| 1 | 通知の送信条件の確定に、予定2日に対して8日かかった | 続かない（10/2に確定済み） | 確定した条件を仕様書 3.2 節に反映済み |
| 2 | 仕様の質問への回答が週1回の定例に限られていた | 続く | 10/6から、質問は当日中に回答する窓口を設ける |

## 3. 対策
| No | 手段 | 対象の作業 | 内容 | 短縮見込み（日） | 追加費用 | 担当 | 開始日 |
|---|---|---|---|---|---|---|---|
| 1 | クラッシング | C 通知機能実装 | 実装者を1名追加（6日→4日） | 2 | 12万円 | 高橋 | 2026-10-06 |
| 2 | クラッシング | D 結合テスト | テスト担当を2名追加（8日→5日） | 3 | 45万円 | 田中 | D の開始日 |
| 3 | クラッシング | F 受入テスト支援 | 支援担当を1名追加（5日→4日） | 1 | 20万円 | 佐藤 | F の開始日 |

- 短縮見込みの合計：6日
- 追加費用の合計：77万円

## 4. 新しい完了日
- 新しい完了日：2026-11-05
- 当初の完了日との差：0日

## 5. 判定日と切り替え
| 判定日 | 確認すること（達成の基準） | 届いていない場合の次の手 |
|---|---|---|
| 2026-10-19 | A が完了し、C が残り4日以内である | D を C の完了3日前から開始する（期待値1.4日短縮、手戻り時は1日延びる） |
| D の開始から3日目 | 結合テストの消化が全項目の6割以上 | 予約の一括取消機能を次の版へ回す（依頼側の同意が前提） |

## 6. 対策に伴うリスク
| No | リスク | 兆候 | 対応 |
|---|---|---|---|
| 1 | 追加メンバーへの説明で既存メンバーの手が止まる | 追加後2日間の完了数が増えない | 説明は半日にまとめ、手順書と環境構築スクリプトを先に渡す |
| 2 | 短縮後は全作業に余裕がなく、1日の遅れが完了日に響く | いずれかの作業が予定より1日遅れる | 毎日の朝会で残日数を確認し、遅れた当日に判定日の手を前倒しで検討する |

## 7. 合意してほしいこと
- 追加費用77万円の承認
- 質問への当日回答の窓口の設置（10/6から）
- 判定日に届かない場合、予約の一括取消機能を次の版へ回すことの事前了承

対策の表のタブ区切り版です。

No  手段  対象の作業   内容  短縮見込み（日）    追加費用    担当  開始日
1   クラッシング  C 通知機能実装    実装者を1名追加（6日→4日） 2   12万円    高橋  2026-10-06
2   クラッシング  D 結合テスト テスト担当を2名追加（8日→5日）   3   45万円    田中  D の開始日
3   クラッシング  F 受入テスト支援   支援担当を1名追加（5日→4日）    1   20万円    佐藤  F の開始日

確かめて分かったこと

コードを動かして分かった、見落としやすい点です。

1. コストスロープが最小の作業が、最初に縮める作業とは限りません。 例題で最も安い E（3万円/日）は余裕のある経路にあり、2日縮めても全体は29日のままでした。
2. クリティカルパスは縮める途中で増えます。 C を2日縮めた時点で経路が2本、D を3日縮めた時点で3本がそろいました。1日縮めるごとに求め直す手順が必要です。
3. 経路が複数そろった後は、共通の作業を縮めるのが安くなりやすい。 A と B を同時に縮めると25万円/日ですが、両方の経路に乗る D は15万円/日で同じ1日を縮められました。
4. 経路を見ずに安い順に縮めると、費用は約1.8倍になりました（77万円に対して138万円）。日数に効かない短縮と、必要以上の短縮が混ざるためです。
5. 目標まで縮めきると、余裕が残りません。 23日に届いた時点で6作業すべてがクリティカルになりました。計画書の「対策に伴うリスク」にこの点を書き、判定日を早めに置く理由になります。
6. ファストトラッキングの短縮は、重ねた日数より小さく見積もる必要があります。 3日重ねても、手戻りの見込み4割・やり直し4日の条件では期待値は1.4日でした。

つまずきやすい点と直し方

よくある質問

Q. クラッシングとファストトラッキングの違いは？ A. クラッシングは資源を足して作業の日数を縮める手段、ファストトラッキングは作業の順序を並行に変えて全体の日数を縮める手段です。前者は追加費用、後者は手戻りのリスクが代償になります。

Q. コストスロープとは？ A. 作業を1日縮めるためにかかる追加費用で、(特急費用 − 標準費用) ÷ (標準日数 − 特急日数) で求めます。例題の C は (72 − 60) ÷ (6 − 4) = 6万円/日です。

Q. リカバリ計画書には何を書きますか？ A. 遅延日数・原因・対策・短縮見込み・新しい完了日・判定日の6点です。加えて、対策に伴うリスクと、承認してほしい事項を最後に書くと判断が進みます。

Q. クリティカルパス以外の作業を縮める意味はありますか？ A. 完了日を早める効果はありません。ただし、短縮の途中でその作業がクリティカルになった場合は候補に入るので、1日縮めるごとに経路を求め直します。

Q. 遅れを取り戻せないときはどうしますか？ A. 取り戻せる日数と届かない日数を分け、届かない日数だけを納期再交渉かスコープ削減の対象にします。「何日は自分たちで縮め、何日を相談したいか」を数字で示すと話が進みやすくなります。

まとめ

• リカバリは、遅延日数を確定し、原因を止め、縮める作業を計算で選ぶ順に進めます。
• 縮める対象はクリティカルパス上の作業だけ。 その中でコストスロープが最小の作業から1日ずつ縮め、毎回クリティカルパスを求め直します。
• 経路が複数そろったら、共通の作業か、作業の組み合わせで縮めます。
• クラッシングは追加費用、ファストトラッキングは手戻りのリスクが代償です。 ファストトラッキングの短縮見込みは期待値で書きます。
• スコープ削減と納期再交渉は、他の手段で届かない日数に絞って相談します。
• リカバリ計画書には、遅延日数・原因・対策・短縮見込み・新しい完了日・判定日を書き、承認事項を最後に置きます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。