「遅れているのは分かっている。原因も、薄々は見当がついている。でも——では、いったいどうやって取り戻すのか」。スケジュール遅延に直面したプロジェクトリーダーが、いちばん答えに詰まるのがこの問いです。とりあえず人を増やしてもらったのに進みが速くならない。残業で押し切ろうとしても、メンバーの疲労と品質低下が見えてくる。そのあいだも関係者からは「結局いつ間に合うのか」を毎日のように問われます。
困るのは、世の中の情報が「遅延の原因リスト」か「クラッシングとは何か」といった用語解説に偏っていて、自分のプロジェクトに当てはめて巻き返しのプランを組む手順までは、なかなか示してくれないことです。原因は分かっても、そこから具体的な再計画に落とせなければ、結局は気合いと根性の火消しに戻ってしまいます。
遅れを取り戻すために本当に必要なのは、精神論ではなく「再現可能なリカバリーの型」です。どの作業に手を入れれば全体が縮むのかを見極め（ボトルネックの特定）、取り戻す手法を状況に応じて選び（クラッシング・ファストトラッキング・スコープ調整）、現実的な再計画に落とし込み、それを関係者に示して合意を取り、実行をモニタリングする——この一連の流れを回せれば、思いつきの対処から抜け出せます。
本記事では、スケジュール遅延が発生したプロジェクトで遅れを取り戻すリカバリープランの作り方を、ボトルネックの特定から手法の選び方、増員の落とし穴、関係者との合意形成、実行のモニタリングまで、実務の手順に沿って解説します。「で、どうやって取り戻すのか」に、できるだけ具体的に答えることをめざします。
本記事は「遅れをどう取り戻すか」という再計画の実務手法に主題を絞っています。その手前にある2つのテーマ——遅延を起こさないための日常的な進捗管理（予防）と、遅延報告を受けた直後の発注者としての初動・意思決定——は、それぞれ別記事で扱っています。遅延を未然に防ぐ管理体制づくりや、納期延長・スコープ削減・リソース追加という発注者目線の判断基準を整理したい方はシステム開発のスケジュール遅延を防ぐ進捗管理と対応の判断基準を、遅延報告を受けた直後の事実確認・契約や損害賠償の検討といった初動を急ぐ方はシステム開発のスケジュール遅延｜発注者が48時間以内にすべき対応をご覧ください。本記事はそれらの先にある「実際に遅れをどう取り戻すか」という巻き返しの実務、すなわちクリティカルパスの圧縮・クラッシング・ファストトラッキングといった手法とリカバリープランの設計に集中します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
スケジュール遅延が発生したら｜リカバリープランを作る前提を整える
巻き返しの手法に入る前に、まず足場を固めます。ここを飛ばして打ち手だけ探すと、的外れな増員や残業に流れがちです。リカバリープランを作る前提として、最低限おさえておきたいことを整理します。
リカバリープランとは｜「遅れた事実」を「取り戻す計画」に変えるもの
リカバリープランとは、遅延が発生したプロジェクトに対して「どこを・どの手法で・どれだけ縮め、いつ着地させるか」を具体的に示した再計画のことです。「遅れています」という事実報告と、「だからこう取り戻します」という計画は別物です。前者で止まっているあいだは、関係者の不安は解消されません。リカバリープランの役割は、漠然とした遅れを、説明可能で実行可能な計画へと変換することにあります。
ポイントは、リカバリープランが「もとの計画に戻す」ことを必ずしも意味しない点です。資源・品質・納期のすべてを当初どおりに満たせない状況だからこそ遅延が起きています。何かを足すか（コスト・人）、何かを削るか（スコープ）、リスクを取るか（並行作業）、そのトレードオフを明示して関係者と握り直すのがリカバリープランです。
着手前に固める3つの前提
リカバリープランの設計に入る前に、次の3つを確認しておきます。
1. 遅延の事実を定量的に把握できていること。 「なんとなく遅れている」では計画を組めません。どの作業（タスク）が、何日（あるいは何人日）遅れていて、その原因は何かを、できる範囲で数字に落とします。原因の見当だけでなく、計画と実績の差分が見えていることが出発点です。
2. これは「責任追及」ではなく「巻き返しの再計画」だという目的の共有。 遅延の場面では、つい「誰のせいか」に意識が向きがちです。原因分析は再発防止に必要ですが、リカバリーの局面で犯人探しに時間を使うと、メンバーが防御的になり、正直な情報が上がってこなくなります。今やるのは前を向いた再計画だ、という空気をリーダーが作ります。
3. 精神論からの脱却。 「もっと頑張れば間に合う」「とりあえず残業で」という発想を、いったん脇に置きます。残業や気合いは短期的には効きますが、後述するように品質低下や離脱という別のリスクを生み、持続しません。これから紹介するのは、どの作業に手を入れれば全体が縮むのかを論理的に選ぶ手法です。
ボトルネックを特定する｜どの作業を縮めれば全体が縮むか
リカバリーの出発点は、「すべての作業を一律に急がせる」ことではありません。全体の所要期間を決めている連続作業の連なり、すなわちクリティカルパスを見極め、そこに資源を集中することが効率的なリカバリーの鍵です。ここを外すと、いくら頑張っても全体の終わりは縮みません。
全体を縮めるのはクリティカルパス上の作業だけ
クリティカルパスとは、プロジェクトを最短で完了するために重要な、所要期間がもっとも長い作業の経路のことです（クリティカルパスとは？発注者がスケジュール遅延を防ぐための監視法で考え方を詳しく解説しています）。
重要なのは、プロジェクト全体の完了日は、このクリティカルパス上の作業の合計で決まるという点です。逆に言えば、クリティカルパスから外れた作業をいくら速く終わらせても、全体の完了日は1日も縮みません。それらの作業には余裕（フロート）があり、多少前後しても最終日に影響しないからです。
リカバリーで陥りやすいのが、「動かしやすい作業」「目に見えて遅れている作業」から手をつけてしまうことです。しかし手を入れるべきは、全体の長さを決めているクリティカルパス上の作業です。ここを縮めて初めて、着地日が前に動きます。
遅延作業がクリティカルパス上か並行可能かを見分ける
いま遅れている作業が、クリティカルパス上にあるのか、それとも余裕のある並行作業なのかで、打ち手の緊急度は大きく変わります。
- 遅延作業がクリティカルパス上にある場合: その遅れはそのまま全体の遅れに直結します。最優先で資源を投じる対象です。
- 遅延作業がフロートのある並行作業の場合: フロートの範囲内なら全体に影響しません。慌てて資源を移すと、かえってクリティカルパス側が手薄になります。
注意したいのは、リカバリーを進めるとクリティカルパスが移動することがある点です。元のクリティカルパスを縮めた結果、別の経路がいちばん長くなり、新たなボトルネックになることがあります。一度特定して終わりにせず、計画を更新するたびにどこが全体を律速しているかを見直します。
WBS・ガントチャートで計画と実績の差分を可視化する
ボトルネックの特定には、計画と実績の差分を目で見える形にすることが欠かせません。手元にWBS（作業分解構成）やガントチャートがあるなら、各タスクの「計画上の終了日」と「現状の見込み終了日」を並べ、ずれの大きいタスクを洗い出します。
このとき、各タスクの「残りどれだけで終わるか」を担当者に具体的な数字で確認します。「だいたい90%」のような感覚値ではなく、残作業を見積もり直すことが、現実的な再計画の土台になります。進捗報告の数字をそのまま信じてよいかの見極めについては、進捗報告の正しい読み方｜「順調です」を信じると危ない5つのシグナルも参考にしてください。差分が見えれば、「どこを・どれだけ縮める必要があるか」という巻き返しの目標が具体化します。
遅れを取り戻す3つの手法｜クラッシング・ファストトラッキング・スコープ調整
ボトルネックが見えたら、いよいよ取り戻す手法を選びます。代表的なのは、資源を足す「クラッシング」、作業を並行させる「ファストトラッキング」、取り戻す範囲そのものを絞る「スコープ調整」の3つです。それぞれを「どういう手法か・どんな状況で効くか・どんなリスクがあるか」のセットで見ていきます。
クラッシング｜クリティカルパスに資源を集中投入する
クラッシングは、クリティカルパス上の作業に資源（主に人員、ときに残業や外部リソース）を追加して、その作業期間を短縮する手法です。PMBOKでは「最小増分コストでプロジェクトスケジュールを短縮する方法」と定義されています（PMstyleコラム：クラッシングとファスト・トラッキングのスケジュール短縮技法）。
- 効く状況: 予算に余裕があり、追加した人員がすぐ戦力になれる（独立して切り出せる作業がある）場合。品質を落とさずに短縮したいケースに向きます。
- リスク・注意点: コストが増えます。さらに、人を足せば足すほど線形に速くなるわけではありません。教育やコミュニケーションの負荷が増え、増員が逆効果になることもあります（この落とし穴は後述します）。クラッシングは「クリティカルパス上の作業」に資源を集中するからこそ効く、という点も忘れないでください。
ファストトラッキング｜順次作業を並行化して短縮する
ファストトラッキングは、本来は順番に行う先行作業と後続作業を、一部重ねて並行で進めることで全体期間を短縮する手法です。たとえば「すべての開発が終わってからテストに入る」のではなく、完成したモジュールから順次テストに着手する、といった進め方が該当します（Asana：ファストトラッキングとクラッシング）。
- 効く状況: 追加コストをかけられない、あるいは増員する人がいない場合。先行作業が完全に終わっていなくても後続を始められる依存関係のときに有効です。
- リスク・注意点: 並行作業が増えるぶん、同時に管理・調整すべきことが増えます。そして最大のリスクは手戻りです。先行作業が固まりきる前に後続を始めるため、後から前提が変わると、後続作業をやり直すことになりかねません。品質リスクが上がる手法だと理解して使います。
スコープ調整｜取り戻す範囲そのものを絞る（段階リリース）
3つめは発想を変える手法です。クラッシングもファストトラッキングも「同じ量の作業を速く終わらせる」アプローチですが、スコープ調整は「終わらせる作業の量そのものを減らす」アプローチです。当初のスコープのうち、納期に間に合わせるべきコア機能を優先し、優先度の低い機能は後続リリースに回す（段階リリース）という考え方です。
- 効く状況: 納期が動かせず、コストも増やせない場合。機能に優先順位がつけられ、一部を後回しにしてもプロジェクトの価値が成立するケースに向きます。
- リスク・注意点: 何を削るかの合意が必要です。発注者・利用部門にとって「外せない」と思っている機能を削ろうとすると合意形成が難航します。だからこそ、後述する合意形成のパートが重要になります。また、削った機能をいつ・どう実現するかも併せて決めないと、単なる先送りになってしまいます。
手法の選び方と組み合わせ方｜状況別の判断軸
3つの手法が分かっても、「自分のプロジェクトではどれを選べばいいのか」が決まらなければ動けません。ここでは選択の判断軸と、実務での組み合わせ方を整理します。
選択の3軸（コスト・品質リスク・納期の絶対性）
どの手法が向くかは、おもに次の3つの軸で決まります。
- コストをかけられるか: 追加予算が確保できるなら、クラッシングが選択肢に入ります。予算が据え置きなら、ファストトラッキングかスコープ調整が中心になります。
- 品質リスクをどこまで許容できるか: 手戻りや品質低下を強く避けたい（基幹システムや対外サービスなど）なら、ファストトラッキングの並行化は慎重に。逆に多少のリスクを許容できるならファストトラッキングの効果は大きいです。
- 納期がどれだけ絶対か: 法令対応や対外公約などで納期が1日も動かせないなら、まずスコープ調整で「間に合わせる範囲」を確定するのが現実的です。
おおまかな目安として、品質重視で予算があるならクラッシング、予算据え置きで多少のリスクを許容できるならファストトラッキング、納期が絶対なら先にスコープ調整、と覚えておくと選びやすくなります。
3手法の比較表（短縮効果・コスト・品質リスク・向く状況）
手法 | 短縮の仕組み | コスト | 品質・手戻りリスク | 向く状況 |
|---|---|---|---|---|
クラッシング | クリティカルパスに資源を追加 | 増える | 増員のやり方次第（中） | 予算があり、切り出せる作業がある |
ファストトラッキング | 順次作業を並行化 | ほぼ増えない | 高い（手戻り） | 予算をかけられず、並行できる依存関係がある |
スコープ調整 | 取り戻す範囲を絞る | 減ることも | 低い（やる範囲が減る） | 納期が絶対で、機能に優先順位がつけられる |
単独でなく組み合わせる｜現実的な適用順序
実務では、いずれか1つだけで巻き返せることはむしろ少なく、複数を組み合わせるのが普通です。おすすめの順序は、まずスコープ調整で「本当に間に合わせるべき範囲」を確定し、それでも足りないぶんにクラッシングやファストトラッキングを当てる、という流れです。先に範囲を絞っておけば、資源を投入する対象も並行化する対象も小さくなり、リスクとコストを抑えられます。
「クラッシングとファストトラッキングはどちらを先にすべきか」という疑問もよく聞かれます。一般的には、追加コストのかからないファストトラッキングを先に検討し、それでも足りなければコストを伴うクラッシングを足す、と段階的に考えると無駄が出にくくなります。ただし手戻りリスクの高い領域でファストトラッキングを多用するのは危険なので、品質要件と相談しながら判断してください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
「人を増やすと逆に遅れる」を避ける増員のやり方
クラッシングを選ぶときに、もっとも踏みやすい地雷が「増員」です。「遅れているから人を足す」は直感的ですが、ソフトウェア開発では裏目に出ることが知られています。ここはリカバリーの成否を分けるポイントなので、独立して掘り下げます。
なお、発注者の立場で「納期延長・スコープ削減・リソース追加（増員）のどれを選ぶべきか」という上流の意思決定を整理したい場合は、システム開発のスケジュール遅延を防ぐ進捗管理と対応の判断基準で3択の判断基準をまとめています。本記事は「リソース追加（増員）を選んだあと、それを実際にどう機能させるか」という実行レベルの工夫に踏み込みます。
なぜ増員が裏目に出るのか（ブルックスの法則）
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」——これはフレデリック・ブルックスが著書『人月の神話』（1975年）で示した、いわゆる「ブルックスの法則」です（ブルックスの法則 - Wikipedia）。
裏目に出る理由は、おもに次の3つです。
- オンボーディングの負荷: 新しく加わった人がすぐに戦力になるわけではありません。設計や現状を理解するまでに時間がかかり、その間は既存メンバーが教える側に回るため、教える側の生産性が一時的に落ちます。
- コミュニケーション経路の増加: 人数が増えると、関係者間の調整経路が急激に増えます。一般にコミュニケーションコストは人数の2乗のオーダーで増えるとされ、メンバーを倍にすると調整の負荷は4倍近くにふくらみます。
- 分割できないタスク: 設計判断のように、本質的に一人または少人数でしか進められない作業は、人を足しても速くなりません。
つまり「人月」は単純に足し算できる資源ではない、というのがこの法則の核心です。
増員を効かせる3つの条件
とはいえ、増員が常に無意味なわけではありません。次の条件を満たせば、クラッシングとしての増員は機能します。
- 独立して切り出せる作業があること: 既存メンバーに頼らず進められるタスク（独立性の高い画面開発、テストケース作成など）が用意できるなら、新規メンバーをそこに当てられます。
- 教える側の余力を計画に織り込むこと: オンボーディングのコストはゼロにできません。最初の数日〜数週間は教える側の生産性が落ちる前提で、その負荷をリカバリープランに織り込みます。「足した人数ぶん、丸ごと速くなる」と見積もらないことが大切です。
- 投入のタイミングが早いこと: 残り日数が少ない終盤の増員ほど、立ち上がる前にプロジェクトが終わってしまい、効果が出ません。増員するなら、立ち上がりの時間を確保できる早い段階で判断します。
残業・気合いに頼らない持続可能なリカバリー
増員と並んで安易に選ばれがちなのが、残業による押し切りです。短期決戦のひと押しなら有効な場面もありますが、長期化すると確実に副作用が出ます。疲労による品質低下（バグの増加は、結局あとで手戻りを生みます）、そしてメンバーの離脱リスクです。せっかくの戦力が抜ければ、リカバリーは一気に苦しくなります。
増員も残業も難しいときは、ほかの選択肢も検討します。既存メンバーを最優先タスクに集中させて割り込みを止める、外部の即戦力をスポットで限定的に使う、そして前述のスコープ調整でやることを減らす、といった手です。持続可能でないリカバリーは、その場をしのげても次の遅延を呼びます。「走り切れる計画かどうか」を、手法を選ぶときの判断基準に加えてください。
リカバリープランを関係者に示して合意を取る
手法を選び、再計画を組んでも、それを関係者が納得して動いてくれなければ実行できません。ここは多くの解説記事が手薄にしている領域ですが、現場では巻き返しの成否を左右します。作ったリカバリープランを、上位者・関係部署・ベンダーまたは顧客にどう示して合意を取るかを整理します。
リカバリープランに盛り込む4要素
関係者に提示するリカバリープランには、最低限、次の4つを盛り込みます。
- 取り戻す対象と捨てる対象（スコープ前提）: 何を間に合わせ、何を後続に回すのか。スコープ調整をした場合は、ここが合意の核心になります。
- 新しい着地見込みと、その根拠: いつ完了する見込みか。そして「なぜその日付なのか」を、クリティカルパスや残作業の見積もりで裏づけます。根拠のない日付は信用されません。
- 採る手法と追加コスト: クラッシング（増員）なのかファストトラッキングなのか、それに伴う追加費用やリスクの増加を明示します。
- リスクと前提条件: 「この計画は何が成り立てば実現するか」という前提を明記します。前提が崩れたら計画も変わる、という共通認識を持つためです。
着地見込みはレンジで示す｜「必ず間に合う」と言わない
着地見込みを伝えるとき、つい安心してもらおうとして「必ず間に合わせます」と言いたくなります。しかし遅延中のプロジェクトで断定すると、外れたときに信頼を一気に失い、次の報告がますます苦しくなります。
おすすめは、レンジで示すことです。「順調にいけば◯月◯日（楽観）、想定どおりなら◯月◯日（現実）、リスクが顕在化すると◯月◯日まで（悲観）」というように、幅と前提を添えて伝えます。一見すると弱気に見えますが、これは「不確実性を正直に開示している」というメッセージになり、かえって信頼を高めます。関係者も最悪ケースを織り込んで意思決定できるようになります。
合意を記録し、再協議のトリガーを事前に握る
口頭で「分かりました」と言われただけでは、後で認識が食い違います。合意した内容——スコープの前提、着地見込み、追加コスト——は、簡潔でよいので記録に残し、関係者と共有します。
さらに踏み込んで、再遅延したときにどこで再協議するかのトリガーを、合意の時点で握っておきます。「次のマイルストーンで◯◯が完了していなければ、その時点で計画を見直す」というラインを先に決めておけば、再び遅れたときに慌てず、感情的な追及にもなりにくくなります。リカバリープランは一度作って終わりではなく、状況に応じて更新する前提で合意するのがコツです。
リカバリー実行のモニタリングと再発防止
プランに合意できたら、あとは実行です。ただしリカバリー局面では、平常時と同じ管理間隔では遅すぎます。最後に、実行のモニタリングと、今回を次に活かす再発防止について触れます。
リカバリー期間は確認間隔を短くする（効いているか早期に検知）
リカバリー中は、通常より短い間隔で進捗を確認します。週次で回していたなら、重要な局面では日次や隔日のチェックに切り替える、といった具合です。理由は、選んだ手法が実際に効いているかを早く見極めるためです。
増員やファストトラッキングは、効果が出るまでにタイムラグがあったり、思ったほど縮まなかったりします。確認間隔が長いと、「効いていなかった」と気づいたときには、次の手を打つ時間も失われています。早期に「縮んでいない」と分かれば、別の手法に切り替える、スコープをさらに絞る、といった次の一手を打てます。
このとき、遅延の兆候を早く掴む観点も役立ちます。報告の歯切れが悪くなる、テストが後ろ倒しになる、残作業が具体化されない——こうしたシグナルの読み取り方は、進捗報告の正しい読み方｜「順調です」を信じると危ない5つのシグナルで整理しています。
今回の遅延を次に活かす再発防止（バッファ・要件・可視化）
リカバリーを一過性の火消しで終わらせず、次のプロジェクトに活かすところまでが本当のゴールです。今回なぜ遅れたのかを振り返り、再発防止の仕組みに落とし込みます。代表的な観点は次の3つです。
- 見積りバッファ: 楽観的な見積もりが遅延の温床だった場合、不確実性の高い作業に意図的なバッファを設ける。
- 要件の固め方: 要件が後から変わって手戻りが生じたなら、上流での合意プロセスや変更管理のルールを見直す。
- 進捗の可視化: 遅れの発見が遅かったなら、完了基準の明確化や残作業の数値報告など、早期検知の仕組みを整える。
遅延は痛い経験ですが、組織にとっては見積もりや進め方を改善する貴重なデータでもあります。リカバリーが落ち着いたら、関係者で短くても振り返りの時間を持つことをおすすめします。日常的な進捗管理の仕組みづくりまで踏み込んで再発防止を設計したい場合は、システム開発のスケジュール遅延を防ぐ進捗管理と対応の判断基準が、予防の観点から週次・月次の管理実務とチェックリストを提供しています。
まとめ｜遅れは「ボトルネック特定」と「手法の選択」で取り戻す
スケジュール遅延のリカバリーは、気合いや残業ではなく、再現可能な型で進められます。本記事の要点を振り返ります。
- リカバリーはまずボトルネック（クリティカルパス）の特定から始める。全体を縮めるのは、クリティカルパス上の作業を縮めたときだけ。
- 取り戻す手法はクラッシング・ファストトラッキング・スコープ調整の3つ。コスト・品質リスク・納期の絶対性で選び、単独でなく組み合わせる（まずスコープを絞り、残りに他の手法を当てる）。
- 増員は条件を満たさないと逆効果（ブルックスの法則）。独立して切り出せる作業・教える側の余力・早い投入タイミングがそろって初めて効く。残業・気合い頼みは持続しない。
- 作ったプランは着地見込みをレンジで示し、合意を記録し、再協議のトリガーを事前に握る。
- 実行は確認間隔を短くしてモニタリングし、効いていなければ早めに次の手へ。今回の遅延は再発防止（バッファ・要件・可視化）に活かす。
この流れを回せば、思いつきの火消しから抜け出し、説明可能で再現可能な巻き返しができるようになります。
本記事は「実際にどう取り戻すか」という再計画の手法に焦点を当てました。同じ遅延というテーマでも、フェーズによって必要な情報は変わります。遅延を未然に防ぐ日常的な進捗管理や、発注者として納期延長・スコープ削減・リソース追加のどれを選ぶかという判断基準が知りたい方はシステム開発のスケジュール遅延を防ぐ進捗管理と対応の判断基準を、遅延報告を受けた直後の初動や契約・損害賠償を含む意思決定が必要な段階にいる方はシステム開発のスケジュール遅延｜発注者が48時間以内にすべき対応を、それぞれ併せてご覧ください。予防・初動・巻き返しの3つを補完的に使うことで、遅延に強いプロジェクト運営ができるようになります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
