なぜPMPの「スケジュール短縮技法」は現場でそのまま使えないのか？
「スケジュールが遅れている？ じゃあクラッシングで人を突っ込むか、ファストトラッキングで先行して作らせちゃおう！」
もしあなたが現場でこんな指示を出しているなら、今すぐその考えを改めた方がいいかもしれません。
PMP（プロジェクトマネジメント・プロフェッショナル）の勉強をしていると、必ず出会うのがこの2つのスケジュール短縮技法です。試験問題（4択）では、条件に合わせて綺麗に解けるようになっていますよね。
ですが、ITインフラの泥臭い現場で30年、数々の修羅場やデスマーチを潜り抜けてきた私から言わせてもらえば、教科書通りのクラッシングやファストトラッキングは、現場では「劇薬」どころか「毒薬」になりかねないんです。
なぜ、PMPの綺麗事（理論）と現場のリアルにはこれほど大きなギャップが存在するのでしょうか？
PMBOKが教える「クラッシング」「ファストトラッキング」の基本定義
まずは整理として、PMBOK（プロジェクトマネジメント知識体系ガイド）における2つの技法の「公式な定義」をおさらいしておきましょう。試験対策としては、ここを正しく頭に入れておくことが大前提ですからね。
| 技法 | 概要 | 主なトレードオフ（代償） |
|---|---|---|
| クラッシング（Crashing） | リソース（人員や残業など）を追加投入し、最小限のコスト追加でスケジュールを短縮する | コストの増加（追加予算が必要） |
| ファストトラッキング（Fast Tracking） | 通常は順番（シーケンシャル）に行う作業を、一部または全体的に並行して実施する | リスクの増加（手戻り・リワークが発生しやすい） |
どちらの手法を適用するにしても、絶対に忘れてはならない大原則があります。
「クリティカルパス上のアクティビティ」に対して行わなければ、1日たりとも全体の納期は縮まらない。
これがPMBOKの教えです。ここまでは非常にロジカルですし、納得感もありますよね。
30年選手が見た「教科書のきれいごと」と「現場の地獄」
ですが、ここからが「現場の真実」の話です。
教科書には「クラッシング＝コストをかければ期間が縮む」とサラッと書かれています。しかし、現実のITインフラ現場で遅れているプロジェクトに10名のエンジニアを追加投入したらどうなると思いますか？
答えはシンプル。さらに遅れます。
ソフトウェア開発やインフラ構築の世界には、有名な「ブルックスの法則（人月の神話）」というものがあります。「遅れているプロジェクトへの要員追加は、さらに遅らせるだけである」というアレですね。
新しく入ってきた要員に対して、既存のメンバーが「このネットワーク構成はこうなっていて」「このサーバのアクセス権限は…」とレクチャー（オンボーディング）しなければなりません。結果として、エース級エンジニアの手が止まり、現場の進捗は一時的に「完全ストップ」するわけです。
ファストトラッキングも同様です。「設計が完了する前に構築を始める」なんてことをインフラ現場でやれば、後から設計変更が入った瞬間に、すでに組んだ配線や設定パラメータを全て破棄して作り直す「手戻り地獄」が待っています。
教本に書いてある通りにボタンを押すと、爆破スイッチを押すことになる。それが現場の怖さなんですね。
クラッシング（Crashing）の真実：お金を積んでも時間が買えない理由
ここからは、2つの技法をさらに深堀りしていきましょう。まずは「追加予算を投じて人を増やす」クラッシングの裏側から見ていきます。
「予算はあるから、とにかく増員してリバース（挽回）しろ！」
経営陣や顧客からそう言われると、一見ラクな解決策に見えますよね。ですが、インフラ現場におけるクラッシングには、教科書に載っていない「大きな壁」が3つ存在します。
クラッシングを成功させる3つの前提条件と現実の追加コスト
クラッシングは、どんな作業にも適用できるわけではありません。成功させるためには、以下の3つの前提条件をクリアしている必要があります。
- 作業が「相互依存しない小さなモジュール」に分割されていること
- 作業手順書（SOP）が完全に整備されており、誰がやっても同じ品質が出せること
- 新規要員の「立ち上げ期間（オンボーディング）」を考慮しても、短縮できる時間が上回ること
例えば「LANケーブルを1,000本敷設する」といった単純作業なら、人を2倍に増やせば時間はほぼ半分になります。しかし、「複雑なBGPルーティング設計を固める」といった頭脳労働や整合性が問われる作業は、人数を増やしても議論が紛糾して時間が延びるだけなんですね。
また、クラッシングにかかる「現実の追加コスト」は単なる人件費にとどまりません。
| コスト項目 | 概要 | 現場で忘れがちな隠れコスト |
|---|---|---|
| 直接人件費 | 追加エンジニアの単価（単価×人月） | 緊急調達による「割高なスポット単価」 |
| 環境構築費 | 追加メンバー用の作業端末・ライセンス | 検証環境のキャパシティ超過に伴う追加設備費 |
| オンボーディング費 | 既存メンバーのレクチャー工数 | エース級エンジニアの生産性低下（約30〜50%ダウン） |
| 管理コスト | PM/TLによる進捗管理・指示出し工数 | コミュニケーションパスの増加に伴う会議時間の増加 |
このように、単に「月額100万円のエンジニアを5人増やす＝500万円」では収まらないのが、クラッシングのリアルな原価計算です。
ISMS審査員補の視点：増員が引き起こすセキュリティ・情報漏洩リスク
私はISMS（情報セキュリティマネジメントシステム）の審査員補としての視点も持っていますが、セキュリティの観点から見ても、急激なクラッシングは「極めて危険な行為」と言わざるを得ません。
納期に追われている現場で急に人が増えると、現場のセキュリティ統制（ガバナンス）はあっけなく崩壊します。
- 「手続きに時間がかかるから」と、共有の特権ID（rootやadmin）を全員で回し使い始める
- 急遽用意した作業用PCのウイルス対策ソフトやパッチ適用が漏れている
- 外部パートナーへのデータ受渡ルールが形骸化し、USBメモリや個人クラウドが使われる
安全が担保できないクラッシングは、プロジェクトどころか「会社の信用」まで吹き飛ばすリスクを孕んでいるわけです。
クラッシング発動判断のチェックリストと失敗回避手順
では、どうしてもクラッシングを選択せざるを得ない場合、PMはどう動くべきでしょうか。私が現場で実践している「発動判断チェックリスト」と手順を提示します。
【クラッシング発動判断チェックリスト】
- [ ] 短縮したい作業は「クリティカルパス上」にあるか？
- [ ] 追加する作業は、他の作業と独立して進められるか？
- [ ] 既存の作業手順書（マニュアル）は、初見の人間が見ても理解できるレベルか？
- [ ] 新規要員の教育に裂く「レクチャー要員（既存メンバー）」の工数をスケジュールに織り込んだか？
- [ ] 追加メンバーに対する個別アカウントの発行やアクセス権限申請のリードタイム（日数）を計算したか？
このチェックリストで1つでも「NO」があるなら、そのままクラッシングを強行してはいけません。
【失敗を回避するための具体的適用手順】
- 作業の「切り出し」を行う: クリティカルパス上の作業のうち、定型化できる部分（例：パラメータシートの転記、機器のラッキング、単体テストコードの作成）だけを切り出す。
- バッファを組み込んだオンボーディング計画を立てる: 追加メンバーが現場に入ってから1週間は「生産性0.5」として計算し、既存メンバーのレクチャー工数（1日1〜2時間）をあらかじめ予定表にブロックする。
- 権限管理の最小化（最小権限の原則）: どんなに急いでいても、共有IDの発行は絶対に禁止。必要最小限の権限を付与した個別IDを事前に準備する。
「ただ人を増やせば早くなる」という甘い考えを捨て、精密機械を組むように体制を整えること。これが、クラッシングで死なないための絶対条件です。
ファストトラッキング（Fast Tracking）の真実：並行作業が引き起こす手戻り地獄
クラッシングが「金で時間を買う（そして失敗する）」手法だとすれば、ファストトラッキングは「リスクを冒して未来の前払いに賭ける（そして爆死する）」手法と言えます。
PMBOKでは、「通常は順番（シーケンシャル）に行うアクティビティを、並行して実行する（オーバーラップさせる）」と説明されますよね。
例えば、ITインフラ構築であれば「基本設計が終わる前に、詳細設計や構築作業をスタートさせる」「テスト仕様書が完成する前に、実機テストを開始する」といった具合です。
一見すると追加予算もかからず、スマートな納期短縮術に見えるかもしれません。ですが、現場で長年冷や汗をかいてきたベテランの視点から言えば、ファストトラッキングは「手戻り（リワーク）」という悪魔に魂を売る行為なんです。
設計未完了での施工・構築発進がなぜデスマーチを生むのか
なぜ、前工程が終わっていないのに後工程を走らせると地獄を見るのでしょうか？
理由はシンプルです。前工程の「決定事項」が覆った瞬間、後工程で作ったものがすべて「ゴミ」になるからです。
インフラ構築の現場を例に考えてみましょう。
- 基本設計フェーズ: サーバの台数、ネットワーク帯域、ストレージ容量を策定中（未確定）。
- ファストトラッキング強行: 納期がないため、基本設計の完了を待たずに「たぶんこうなるだろう」という予測で、ラック調達・機器発注・ケーブル配線作業（構築フェーズ）を並行して開始。
- 設計変更の発生: クライアント側の要件追加により、必要なサーバ台数が1.5倍に増え、電源容量と耐荷重がオーバーすることが判明。
- 手戻り発生: すでに設置したラックの再レイアウト、配線の引き直し、機器の再発注が発生。作業はやり直しになり、費用もスケジュールも当初より大幅に悪化。
これが、ファストトラッキングによって引き起こされる「手戻りの雪だるま現象」です。
最初から順番通りにやっていれば発生しなかったはずの「破壊と再構築」の工数が加算され、結果的にスケジュール短縮どころか、大幅な納期遅延とチームの精神崩壊を招くわけですね。
クラッシング vs ファストトラッキング徹底比較表
ここで、現場視点における「クラッシング」と「ファストトラッキング」の現実的な相違点を、多角的な軸で表に整理しておきます。試験問題のきれいな表とは一味違う、リアルな代償を網羅しました。
| 評価軸 | クラッシング（Crashing） | ファストトラッキング（Fast Tracking） |
|---|---|---|
| 主な手段 | 要員の追加投入、残業・休日出勤の適用 | 工程のオーバーラップ（前倒し並行実施） |
| 主なリスク | コスト超過、オンボーディングによる一時的停滞 | 手戻り（リワーク）による品質崩壊とさらなる遅延 |
| 追加費用 | 非常に高い（人件費、端末・ライセンス費） | 見かけ上は0円（※手戻り発生時に倍増） |
| 現場の疲弊度 | 新人教育による既存メンバーのストレス | 「作ったものを壊して作り直す」精神的ダメージ |
| ガバナンス影響 | 特権ID貸与など、セキュリティの形骸化 | 変更管理・構成管理の破綻、ドキュメント乖離 |
| 適用すべきタイミング | モジュール化されており、手順が確立している時 | 前工程の「変動要素」が極めて少ないと確信できる時 |
表を見てもわかる通り、どちらも「無傷」では済みません。
特にファストトラッキングの怖いところは、「発動した時点ではコストが増えないように見える」点です。だからこそ、浅はかなPMや経営陣が安易に選んでしまい、後から手戻り費用という巨大なツケを払うことになるんですね。
ファストトラッキングを安全に走らせるための「仮決め（フリーズ）」技術
では、ファストトラッキングは絶対にやってはいけない悪手なのかと言えば、そうとも言い切れません。土壇場の現場では、どうしても工程を前倒しせざるを得ない局面が存在するからです。
現場の修羅場を潜り抜けてきた私が実践している、ファストトラッキングを「爆弾」にしないための技術。それが「インターフェースの段階的フリーズ（固定）」です。
- 全体を「絶対に変わらない部分」と「変わりやすい部分」に分離する例えば、ネットワーク構築なら「IPアドレス体系やVLAN設計（変わりやすい）」と「物理的なラック位置や電源配線（変わりにくい）」を切り離します。
- 「インターフェース」だけを先行して仮決め（フリーズ）する前工程のすべての詳細が決まっていなくても、「前工程と後工程の接続部分（インターフェース）」のルールだけを双方の担当者で固め、合意書（仕様凍結書）を交わします。
- 変更不可の「デッドライン」を設定する「〇月〇日以降の設計変更は、理由の如何を問わず受け付けない。変更する場合は追加費用と納期延期をセットで適用する」というルールをステークホルダーと握っておきます。
「なんとなく並行して作業を進める」のは自殺行為です。「どこまでを固定し、どこからが変更リスクなのか」を切り分ける技術があって初めて、ファストトラッキングは安全な短縮技法となり得るわけです。
ベテランが実践する「第三の選択肢」と現場の交渉術
PMPの教科書を開くと、スケジュール短縮技法として「クラッシング」と「ファストトラッキング」の2つがドカンと鎮座しています。
しかし、30年現場にいるベテランの感覚からすると、「納期が遅れていて、予算も増やせず、手戻りリスクも負えない」という八方塞がりの状況で、この2択から選ぼうとすること自体が間違いなんですね。
真にプロジェクトを救うのは、PMBOKの枠組みを超えた「第3の選択肢」と、泥臭いステークホルダー交渉術です。
スコープ削減（デスコープ）という最も強力で安全な短縮術
プロジェクトの制約条件には「品質（Quality）」「コスト（Cost）」「スケジュール（Schedule）」「スコープ（Scope）」があります。
スケジュール（納期）が絶対で、コストも増やせない（クラッシング不可）、品質も落とせない（ファストトラッキングの手戻り不可）となった場合、動かせる変数は「スコープ（提供する機能や作業範囲）」しかありません。
現場を炎上させないPMは、迷わず「デスコープ（機能の削り落とし・段階リリース）」を提案します。
- 本番稼働時に必須な「コア機能」だけを最優先で構築する
- 運用管理ツールや自動化スクリプトなど、後からでも導入できる機能は「Phase 2（二次リリース）」へ先送りする
- データ移行の対象範囲を「過去5年分」から「過去1年分」に絞り、残りはアーカイブ参照とする
スコープを削ることは、決して「敗北」ではありません。
未完成の欠陥システムを無理やり納期通りに納品して全社障害を起こすくらいなら、機能を絞って完璧に動くシステムを期日通りに届ける方が、顧客にとっても100倍価値があるんです。これが「インフラ屋のプライド」というものです。
ステークホルダー（特に頑固な顧客）の心理を解きほぐす説得のステップ
「そんなことを言っても、うちの顧客（あるいは役員）は『全機能を予定通り作れ！人を入れてでも間に合わせろ！』と聞く耳を持たないんだよ…」
そんなため息が聞こえてきそうですね。ええ、痛いほどよく分かります。私も若い頃は、そうやって無茶振りを叩きつけられて途方に暮れていましたから。
そういった「頑固なステークホルダー」を説得するためには、精神論ではなく「事実（データ）とリスクの可視化」で交渉する必要があります。私が実際に現場で使っている3ステップの説得術をお伝えしましょう。
【ステップ1：クラッシングの試算とリスクの可視化】
「ご要望通り人員を5名追加した場合の試算です。追加費用は〇〇万円かかります。
ただし、オンボーディング工数により、最初の3週間は進捗がさらに15%低下します」
【ステップ2：ファストトラッキング事故率の可視化】
「予算をかけずに工程を並行処理した場合、過去の類似トラブル事例から見て、
構築完了後に約40%の確率で大型の手戻りが発生します。結果、本番稼働が〇ヶ月遅延するリスクがあります」
【ステップ3：段階リリース（デスコープ）という救済策の提示】
「提案です。今回の期日には『コア業務機能A』のみを100%の品質で稼働させます。
これで御社の業務は止まりません。残りの『機能B』は1ヶ月後のPhase 2で安全にリリースしましょう」
客観的なリスクを示し、相手の「失敗したくない」という心理に寄り添いながら逃げ道（段階リリース）を用意してあげること。これがベテランの交渉術です。
PMP試験対策としての「割り切り」と現場での「使い分け」
ここまで、PMP教科書の正論を現場目線でバッサリと斬ってきました。
「じゃあ、PMPの知識なんて現場じゃ役に立たないってこと？」と思われるかもしれませんが、決してそういうわけではありません。
大切なのは、「PMP試験に合格するための頭（試験用思考）」と「現場でプロジェクトを生き残らせるための頭（現場用思考）」を、明確に切り替える（使い分ける）ことなんです。
試験で100点を取るための回答パターン（4択問題の解法テクニック）
まず、PMP試験を受験・勉強中の方へのアドバイスです。
試験問題を解く際、「現場の泥臭い苦労」や「ブルックスの法則」を考慮してはいけません。
PMP試験の世界（PMBOK）は、ある種の「理想郷（パラダイス）」です。前提条件として「作業手順は完璧に定義されており、リソースは即座に調達でき、追加すれば素直に期間が縮む」という前提で問題が作られています。
したがって、試験では以下の「割り切りルール」で機械的に正解を選んでください。
- 問題文に「追加の予算・コストに余裕がある」「費用は問わない」とある場合⇒ 正解は クラッシング（Crashing）
- 問題文に「追加の予算はない」「コストを増やすことはできない」とある場合⇒ 正解は ファストトラッキング（Fast Tracking）
- 問題文に「手戻りのリスクを避けたい」「品質を最優先したい」とある場合⇒ 正解は クラッシング（Crashing）（※ファストトラッキングはリスクが増えるためNG）
- 共通の大原則⇒ どちらの手法も、「クリティカルパス上のアクティビティ」に適用している選択肢を選ぶこと。
試験は試験と割り切って、PMBOKの理論通りにサクッと正解を選び、PMP資格を取得してしまいましょう。資格を取ること自体は、あなたのプロフェッショナルとしての証明になり、キャリアの大きな武器（反撃の狼煙）になりますからね。
現場で生き残るためにPMが胸に刻むべき「インフラ屋の意地」
しかし、ひとたびPMPバッジを胸に付けて現場に戻ったら、その知識をそのまま振りかざすのはやめましょう。
PMBOKに書かれている手法は、あくまで「ツール（道具箱に入っている工具）」に過ぎません。ドライバーや金槌そのものが家を建てるわけではないのと同じで、ツールを使う「PM自身の人間力と現場感」こそがプロジェクトを成功させるんです。
30年間、インフラ屋として現場の冷や汗をかき続けてきた私から、若手や中堅のPM・TLの皆さんに最後に伝えたいことがあります。
プロジェクトが遅延し、納期が迫り、周りからのプレッシャーで頭がどうにかなりそうな時。
PMBOKのテキストを開いて「クラッシングか？ ファストトラッキングか？」と焦る前に、一度立ち止まって、自分の目で現場のエンジニアたちの顔を見てください。
- 現場のメンバーは疲弊しきっていないか？
- 手順書もないまま、急に追加された人に無茶な指示を出していないか？
- 「形だけの納期」を守るために、システムの安全性やメンバーの健康を犠牲にしていないか？
ツールや理論に使われるな。ツールを使いこなす側になれ。
本当のPMP（プロフェッショナル）とは、教科書の用語を暗記している人のことではありません。
現場の泥臭い現実を泥臭く泥臭く泥臭く受け止め、時に顧客とタフに交渉し、現場のエンジニアの命とシステムの安定を守り抜く覚悟を持った人のことです。
この記事が、日々現場の修羅場で戦うあなたの「反撃の狼煙」となることを、心から願っています。
