ファストトラッキング対クラッシング：スケジュール圧縮

プロジェクトが遅れると、ほとんどのマネージャーは同じ2つの選択肢を迫られます。タスクを並行して実行するか、問題にリソースを投入するかです。この2つのアプローチはプロジェクト管理において正式な名称があります。ファストトラッキングとクラッシングです。ファストトラッキング対クラッシングの違いを理解することは、プロジェクトマネージャーが身につけられる最も実践的なスキルのひとつです。誤った選択は、軽微な遅延をコストのかかる手戻りの連鎖に変えてしまう可能性があるからです。

このガイドでは両テクニックを詳しく説明し、直接比較したうえで、どちらを使うべきかを判断するための実践的なフレームワークを提供します。

ファストトラッキングとクラッシングとは？

ファストトラッキングは、本来順番に予定されていたアクティビティを並行して、またはタイムラインを重ねて実行するスケジュール圧縮テクニックです。追加の予算は使いません。代わりに、より多くの調整オーバーヘッドと、後のタスクがすでに開始されてから前のタスクが変更された場合の手戻りリスクを受け入れます。

クラッシングは、クリティカルパス上のタスクにリソースを追加してその期間を短縮するスケジュール圧縮テクニックです。これにはコストがかかります。追加の契約社員を採用したり、残業を承認したり、追加設備を借りたり、より高速なサービスを購入したりすることがあります。スケジュールは短縮されますが、予算は増加します。

どちらのテクニックもクリティカルパスを具体的にターゲットにします。Float（余裕）のあるタスクにどちらかを適用しても、プロジェクトの終了日は短縮されません。遅延した場合にプロジェクト全体が遅延するタスクに当てなければなりません。

主要データ

• PMIの Pulse of the Profession レポートによると、47%のプロジェクトが当初のスケジュール目標を達成できず、スケジュール圧縮は例外ではなく繰り返される現実となっています。
• Project Management Instituteの研究によると、圧縮を適用する前にクリティカルパスを特定したプロジェクトは、リソースを広範囲に適用したプロジェクトよりも成功率が測定可能なほど高いことが示されています。
• PMIのPMBOK Guideは、プロジェクトの早期完了が求められる場合、または遅延を回復する必要がある場合に利用できる2つの主要なスケジュール圧縮テクニックとして、ファストトラッキングとクラッシングを挙げています。

ファストトラッキング対クラッシング：並べて比較

使い分け

ファストトラッキングを使う場合：

• 予算が厳しくリソースの追加ができない。
• 2つの順次タスクが緩い依存関係のみを共有している。例えば、前のセクションがまだ下書き中ではなく最終レビュー中にレポートのセクションを書く場合など。
• 手戻りコストが低い。上流タスクが変更されて下流タスクに軽微な調整が必要になっても、節約された時間はまだ重複を正当化する。
• チームのコミュニケーションが強固で、リアルタイムで引き継ぎを調整できる。

クラッシングを使う場合：

• プロジェクトに法的または規制上の締め切りがあり、シーケンシングだけではギャップを埋められない。
• スケジュール回復のために特別に予算の余裕がある。
• クリティカルパス上のタスクを安全に分割したり重ねたりできない。ハードウェア製造、規制審査、負荷テストはしばしばこのカテゴリに該当する。
• ファストトラッキングのオプションをすでに使い果たした。

実践的なルール：ファストトラッキングをまず試みてください。コストが少ないからです。達成した圧縮量が十分でない場合は、最も良い時間対コスト比を示すクリティカルタスクにクラッシングを組み合わせます。

よくある失敗

クリティカルパス外で圧縮を適用する。 5日間のFloat and Slackがあるタスクを高速化しても、終了日には何の影響もありません。何かに着手する前に、ネットワーク図を使ってクリティカルパスを特定します。

収穫逓減点を超えてクラッシングする。 2人のタスクに3人目を追加しても、期間が3分の1に短縮されるわけではありません。コミュニケーションのオーバーヘッドが増加し、ある時点で追加リソースはメリットをもたらさなくなります。常にクラッシュコストスロープを計算してください。節約された1日のコストは実際にはいくらですか？

ハード依存関係のあるタスクをファストトラッキングする。 タスクによっては、前のタスクが100%完了するまで本当に開始できないものがあります。コンクリートスラブの打設は基礎がまだ掘削中には開始できません。ハード依存関係に並行処理を強制しても、スケジュールは圧縮されません。欠陥が生じます。

トリプル制約を忘れる。 スケジュール圧縮は常に1つの制約を別の制約とトレードオフします。ファストトラッキングは時間とリスクをトレードします。クラッシングは時間とコストをトレードします。どちらの動きも無料ではありません。

ベースラインを再設定しない。 圧縮を適用したら、元のスケジュールはもはや計画ではありません。Gantt チャートを更新し、チームに新しいクリティカルパスを伝達し、クラッシングが予算を変更した場合はコストベースラインを更新します。

スケジュールを圧縮する方法

ステップ1：クリティカルパスをマッピングする

ネットワーク図を使って、開始から終了まで Float がゼロのタスクのすべてのシーケンスを見つけます。この連鎖上のタスクだけが圧縮の候補です。

ステップ2：ファストトラッキングのオプションを評価する

クリティカルパスの各タスクペアをレビューします。2番目のタスクは本当に最初のタスクが100%完了してから開始する必要がありますか？そうでなければ、どれだけの重複が可能か、それがどれだけの手戻りリスクをもたらすかを見積もります。候補となる重複とそれぞれが節約できる時間をリストアップします。

ステップ3：クラッシングのオプションを評価する

ファストトラッキングできないクリティカルパスの各タスクについて、クラッシュコストスロープを計算します：

クラッシュコストスロープ = （クラッシュコスト - 通常コスト） / （通常期間 - クラッシュ期間）

これにより節約された1日あたりのコストがわかります。タスクを最低から最高のクラッシュコストスロープ順にランク付けし、最も安いものから先にクラッシングします。

ステップ4：最適な組み合わせを適用する

手戻りリスクが許容できる場合はファストトラッキングを、そうでない場合はクラッシングを組み合わせて、最小限の総コストでスケジュールギャップを埋めます。コミットする前に、プロジェクトコスト見積もりで予算の余裕を確認します。

ステップ5：ベースラインを再設定してモニタリングする

スケジュールを更新し、クリティカルパスをリセットし、アーンドバリューマネジメント（EVM）のベースラインを再計算します。ファストトラッキングした場合は手戻り時間を追跡し、クラッシングした場合はコストパフォーマンスを監視します。

ファストトラッキング対クラッシングの例

20週間のスケジュールで予定されていたソフトウェア製品のリリースを想定します。第8週に、クリティカルパスタスクが3週間遅れていることが監査で明らかになりました。

チームは3週間のギャップに対して3.5週間を回復します。UIの重複はバックエンドインテグレーションに若干の手戻りリスクをもたらしますが、開発リードが毎日インテグレーションポイントをレビューできるためチームはそれを受け入れます。QAとデプロイメントのクラッシングはプロジェクト予備費から支払われます。

これらの決定を行う前に、3点見積もりを使って圧縮された期間を楽観的・悲観的シナリオに対してストレステストします。

ベストプラクティス

意思決定のロジックを文書化する。 スポンサーが予算が増加した理由を尋ねた場合、明確な記録が必要です。ギャップ、評価されたオプション、計算されたコストスロープ、選択されたパスを示す記録です。「リソースが必要だった」という曖昧な説明は信頼を損ないます。

ファストトラッキングの引き継ぎルールを明確にする。 タスクAとタスクBを重ねる場合、タスクBが開始できる正確な条件を定義します。「タスクAが70%完了していてインターフェース仕様が確定している」は明確なトリガーです。「Aがほぼ完了しているように見える」はそうではありません。

手戻りを別途追跡する。 ファストトラッキングは、呼び出さない限り手戻りを通常のタスク工数に隠します。手戻り時間を記録することで、圧縮が手戻りを差し引いても実際に時間を節約したかどうかを評価できます。

スケジュール圧縮をステークホルダーに伝達する。 重複するタスクに取り組むチームメンバーは自分たちが吸収しているリスクを知る必要があります。予算が増加する場合はスポンサーも知る必要があります。沈黙は驚きを生み出します。

人的コストを考慮する。 残業によるクラッシングは Sprint の間は機能します。4か月連続では機能しません。燃え尽き症候群は元の遅延よりもプロジェクトを遅らせます。

よくある質問

ファストトラッキングとクラッシングの主な違いは何ですか？ ファストトラッキングは、順次計画されていたタスクを重ねることでスケジュールを圧縮し、手戻りリスクを加えますがコストはほとんどかかりません。クラッシングは、クリティカルパスタスクにリソースを追加することでスケジュールを圧縮し、期間を短縮しますが予算が増加します。どちらもクリティカルパスのみをターゲットにします。

どちらのテクニックがより安価ですか：ファストトラッキングとクラッシング？ ファストトラッキングは一般的により安価です。リソースを追加しないからです。しかし、重複が大幅な手戻りを引き起こした場合、隠れたコストがクラッシングのコストを超えることがあります。正しい選択は特定のタスク、その依存関係のタイプ、および手戻りの可能性に依存します。

同じプロジェクトでファストトラッキングとクラッシングの両方を使用できますか？ はい。ほとんどのプロジェクトマネージャーはそれらを組み合わせます。安全に重複できるタスクはファストトラッキング、そうでないタスクはクラッシングします。このハイブリッドアプローチは、クラッシングだけよりも低コストでより大きなスケジュールギャップを埋めます。

ファストトラッキングはプロジェクトリスクを高めますか？ 高めます。タスクを並行して実行すると、後のタスクは前のタスクが変わった場合に修正が必要になる可能性があります。チームがよくコミュニケーションをとり、依存関係がハードではなくソフトである場合、リスクは管理可能です。

クラッシングで十分な時間を回復できない場合はどうなりますか？ クラッシュの限界に達した可能性があります。リソースをさらに追加しても期間がそれ以上短縮されないポイントです。その時点では、スコープ削減（成果物の削除）または交渉による締め切り延長が残りのオプションです。

---

締め切りが固定されていてスケジュールが滑っているとき、ファストトラッキングとクラッシングは構造的な対応方法を提供します。まずクリティカルパスをマッピングし、両方のオプションを見積もり、意味がある場合は組み合わせます。予算を吹き飛ばさずに失われた時間を回復するチームは、通常これらの決定をエンジニアリング上の問題として、パニック的な動きではなく対処するチームです。

関連記事

• クリティカルパス法
• プロジェクトスケジューリングにおけるFloat and Slack
• ネットワーク図
• トリプル制約
• Gantt チャートとは
• 3点見積もり
• プロジェクトコスト見積もり
• アーンドバリューマネジメント（EVM）