【2025年決定版】クリティカルパス法（CPM）完全網羅ガイド：不確実性を伴う開発プロジェクトの工程管理と最新マネジメント戦略

2025年11月24日

第1章：序論：時間はなぜ管理できないのか

1.1 プロジェクトマネジメントにおける「時間」の不可逆性

現代のビジネス環境、とりわけソフトウェア開発やデジタルトランスフォーメーション（DX）の領域において、最も希少かつ代替不可能な資源は「時間」です。資金は調達可能であり、人材は採用や育成によって補充できますが、過ぎ去った時間は二度と戻りません。市場投入までの時間（Time to Market）が競争優位の源泉となる今日、プロジェクトの遅延は単なるスケジュールのズレではなく、ビジネス機会の喪失、あるいは企業の存続に関わる重大なリスクとなります¹。

しかし、多くのプロジェクトは依然として予定通りに完了しません。なぜでしょうか。それは、プロジェクトを構成するタスク間の複雑な相互依存関係（Dependencies）と、それぞれのタスクに内在する不確実性を、人間の直感だけで把握しようとするからです。ここで不可欠となるのが、**クリティカルパス法（Critical Path Method: CPM）**という科学的アプローチです。

本レポートでは、1950年代に誕生し、2025年の現在もなおプロジェクトマネジメントの根幹をなすCPMについて、その理論的背景から実務的な計算手法、ソフトウェア開発特有の課題への適用、そしてAIやアジャイル手法と融合した最新のトレンドまでを、エンジニアリングの専門家としての視点で徹底的に解説します。

1.2 CPMの定義と歴史的背景：化学プラントからSaaS開発へ

クリティカルパス法（CPM）とは、プロジェクトを構成する個々のタスク（活動）を洗い出し、それらの順序関係と所要時間を分析することによって、**「プロジェクトを完了させるために必要な最短の時間」を算出し、「遅延が許されない一連のタスク（経路）」**を特定する手法です¹。

この手法の起源は、1950年代後半にさかのぼります。化学大手のデュポン社（DuPont）とコンピュータメーカーのレミントンランド社（Remington Rand）が、化学プラントの保守・建設プロジェクトにおけるスケジュールの非効率性を解消するために共同開発しました³。彼らは、複雑なプラント建設において、どの作業がボトルネックになっているかを数学的に特定することで、工期短縮とコスト削減を実現しようとしたのです。

同時期、アメリカ海軍はポラリスミサイル開発プロジェクトにおいて、類似の手法である**PERT（Program Evaluation and Review Technique）**を開発しました⁶。CPMが「タスクの所要時間は確定している」と仮定するのに対し、PERTは「楽観値」「最頻値」「悲観値」という3つの見積もりを用いることで、時間の不確実性を確率的に扱います⁸。現在ではこれらは統合され、広義のCPM/PERTとして扱われることが一般的です。

1.3 なぜ「最長」の経路が「最短」の工期を決めるのか？

CPMの概念において、非専門家が最も混乱しやすいのが「クリティカルパスはプロジェクトネットワークの中で最も長い経路（Longest Path）である」という定義と、「それがプロジェクトの最短完了時間を決定する」という事実の関係性です⁶。

これを直感的に理解するために、卑近な例として「ディナーパーティーの準備」を考えてみましょう。

【アナロジー：ディナーパーティーの準備】

あなたは友人を招いてディナーを振る舞う計画を立てています。メインディッシュはローストビーフ、サイドメニューはサラダです。

タスクA： サラダの野菜を切る（所要時間：15分）
タスクB： オーブンを予熱する（所要時間：20分）
タスクC： 肉に下味をつける（所要時間：10分）
タスクD： 肉を焼く（所要時間：60分） ※予熱（B）と下味（C）が完了している必要がある
タスクE： 肉を休ませる（所要時間：20分） ※焼く（D）完了後
**タスクF：**盛り付け（所要時間：10分） ※肉（E）とサラダ（A）の準備完了後

このプロセスには複数の経路が存在します。

経路1（サラダ）： A（15分） → 待機 → F（10分）
経路2（肉）： B（20分）とC（10分）並行 → D（60分） → E（20分） → F（10分）

明らかに、肉の調理プロセス（経路2）の方が時間がかかります。具体的には、予熱（20分）と下味（10分）は並行できますが、焼く工程（D）に進むには遅い方の予熱完了を待つ必要があります。したがって、肉の経路の合計時間は 20 + 60 + 20 + 10 = 110分となります。

一方で、サラダの準備（A）はたった15分で終わります。肉が焼けて休ませている間のいつでも実施可能です。つまり、サラダを作るのが5分遅れても、あるいは30分遅れても、ディナーの開始時間（110分後）には影響しません。

しかし、オーブンの予熱が1分遅れれば、肉を焼き始めるのが1分遅れ、結果としてディナーの開始も1分遅れます。この「予熱 → 焼く → 休ませる → 盛り付け」という最も時間のかかる経路こそが、プロジェクト全体を律速するクリティカルパスなのです¹。

第2章：クリティカルパス法の理論的枠組みと計算メカニズム

ソフトウェア開発におけるCPMの適用を論じる前に、その基礎となる数学的ロジックと計算手順を詳細に解説します。現代のプロジェクト管理ツール（JiraやAsanaなど）はこれらを自動計算しますが、その背後にある論理（アルゴリズム）を理解していなければ、ツールが出力する結果を正しく解釈し、適切な意思決定を下すことはできません¹¹。

2.1 ネットワーク図の構築：AONとAOA

タスク間の依存関係を視覚化する方法には、主に2つの表記法があります。

AON (Activity on Node): ノード（四角や円）がタスクを表し、矢印が依存関係を表す方式。現代のほとんどのPMソフトウェア（Microsoft Project, Primaveraなど）や解説書で採用されている主流の方式です¹¹。
AOA (Activity on Arrow): 矢印がタスクを表し、ノードはイベント（開始点・終了点）を表す方式。ダミー活動（所要時間0の点線矢印）を必要とするため、直感的な理解が難しく、現在はあまり使われません¹²。

本レポートでは、主流であるAON方式に基づいて解説を進めます。

2.2 タスクの依存関係（Dependencies）の分類

ネットワーク図を描く際、タスク間の関係性は単なる「前後関係」以上の意味を持ちます。AdobeやPMIの定義に基づくと、依存関係は以下の3つに大別されます¹⁴。

依存関係の種類	説明	ソフトウェア開発の例
強制的依存関係 (Mandatory)	物理的または論理的に避けられない制約（Hard Logic）。	「コードを書く前にテストすることはできない（TDDを除く）」「サーバーをセットアップする前にデプロイはできない」
任意的依存関係 (Discretionary)	ベストプラクティスや選好に基づく制約（Soft Logic）。チームが任意に設定可能。	「バックエンドの実装が終わってからフロントエンドを始める（本来は並行可能だが、混乱を避けるために分ける）」
外部的依存関係 (External)	プロジェクトチームのコントロール外にある制約。	「AppleのApp Store審査が完了しないとリリースできない」「サードパーティのAPIキーが発行されないと連携テストができない」

クリティカルパス分析において最も重要なのは、任意的依存関係と強制的依存関係を明確に区別することです。スケジュール短縮が必要になった際、任意的依存関係は変更・削除が可能だからです。

2.3 計算アルゴリズム：フォワードパスとバックワードパス

クリティカルパスを特定するためには、以下の4つの値を各タスクについて計算する必要があります¹¹。

ES (Early Start): 最早開始日。先行タスクが全て完了し、最も早く着手できる日。
EF (Early Finish): 最早終了日。ESにタスクの所要時間を足した日。
LS (Late Start): 最遅開始日。プロジェクトの納期を遵守するために、遅くとも着手しなければならない日。
LF (Late Finish): 最遅終了日。プロジェクトの納期を遵守するために、遅くとも完了しなければならない日。

2.3.1 フォワードパス（往路計算）

プロジェクトの開始点から終了点に向かって計算し、ESとEFを求めます。これにより、プロジェクト全体の最短完了期間が判明します。

ルール1: 最初のタスクのESは0（または1）とする。
ルール2: EF = ES + 所要時間 (Duration)
ルール3: 後続タスクのESは、直前の先行タスクのEFとなる。
ルール4（重要）: 先行タスクが複数ある場合（合流点）、それらのEFのうち最大値を後続タスクのESとする。「全ての準備が整うのを待つ」必要があるためです¹⁶。

2.3.2 バックワードパス（復路計算）

プロジェクトの終了点から開始点に向かって逆算し、LFとLSを求めます。

ルール1: 最後のタスクのLFは、そのタスクのEF（プロジェクト完了日）とする。
ルール2: LS = LF – 所要時間
ルール3: 先行タスクのLFは、直後の後続タスクのLSとなる。
ルール4（重要）: 後続タスクが複数ある場合（分岐点）、それらのLSのうち最小値を先行タスクのLFとする。「最も急いでいる後続タスクに合わせる」必要があるためです¹⁶。

2.4 フロート（Float）の概念と種類

計算されたES, EF, LS, LFを用いて、各タスクの「余裕時間（Float/Slack）」を算出します。フロートこそが、プロジェクトマネージャーがリスクを管理するための最も重要な指標です¹³。

2.4.1 トータルフロート (Total Float)

定義: プロジェクト全体の完了日を遅らせることなく、そのタスクを遅らせることができる最大時間。
計算式: TF = LS – ES または TF = LF – EF
意味: 「このタスクはあと何日サボっても納期を守れるか？」を示します。TFが0のタスクをつないだものがクリティカルパスとなります。

2.4.2 フリーフロート (Free Float)

定義: 直後の後続タスクの最早開始日（ES）を遅らせることなく、そのタスクを遅らせることができる時間。
計算式: FF = 後続タスクのES – 自タスクのEF
意味: 「後工程の担当者に迷惑をかけずに、あと何日遅れてもいいか？」を示します。トータルフロートがあってもフリーフロートがない場合、遅延はそのタスクだけの問題ではなく、後続タスクのスケジュール調整を強いることになります。

2.4.3 その他のフロート

高度な分析では以下のフロートも考慮されます²¹。

干渉フロート (Interfering Float): トータルフロートとフリーフロートの差（TF – FF）。この時間分だけ遅れると、プロジェクト全体の納期は守れますが、後続タスクのフロートを食いつぶす（干渉する）ことになります。
独立フロート (Independent Float): 先行タスクが遅れて終わり、かつ後続タスクが早く始まる場合でも確保される、極めて保守的な余裕時間。

第3章：実例詳解：Webアプリケーション開発プロジェクト

理論を現実に適用するために、具体的なソフトウェア開発のシナリオを用いてクリティカルパス分析を行います。ここでは、セキュアな「ユーザーログイン機能」を新規開発するプロジェクトを想定します²³。

3.1 ステップ1：WBSと見積もり

まず、プロジェクトに必要なタスクをWBS（作業分解構成図）としてリストアップし、依存関係を定義します。

プロジェクト概要： セキュリティ要件（SQLインジェクション対策、XSS対策）を満たしたログインページの開発²⁵。

ID	タスク名	所要時間 (日)	前提タスク (Predecessors)	備考
A	要件定義・仕様策定	3	なし	認証フロー、セッション管理仕様の決定
B	データベース設計	2	A	ユーザーテーブル、パスワードハッシュ設計
C	UI/UXデザイン作成	4	A	ログイン画面、エラー表示、レスポンシブ対応
D	バックエンドAPI実装	5	B	認証ロジック、JWT発行、DB接続
E	フロントエンド実装	4	C	フォーム作成、API繋ぎ込み、バリデーション
F	結合テスト・QA	3	D, E	E2Eテスト、セキュリティテスト
G	デプロイ・リリース	1	F	本番環境への反映

3.2 ステップ2：ネットワーク図と計算（フォワード・バックワード）

このプロジェクトには、主に2つの並行パスが存在します。

バックエンドパス: A → B → D → F
フロントエンドパス: A → C → E → F

【フォワードパス計算】

A: ES=0, EF=3
B: ES=3, EF=3+2=5
C: ES=3, EF=3+4=7
D: ES=5, EF=5+5=10 （B完了後）
E: ES=7, EF=7+4=11 （C完了後）
F（合流点）: D(EF=10)とE(EF=11)の両方を待つ。ES = Max(10, 11) = 11。EF=11+3=14
G: ES=14, EF=14+1=15

プロジェクト最短完了日数：15日

【バックワードパス計算】

G: LF=15, LS=14
F: LF=14, LS=11
E（分岐元）: FのLSが11なので、LF=11, LS=11-4=7
D（分岐元）: FのLSが11なので、LF=11, LS=11-5=6
C: EのLSが7なので、LF=7, LS=7-4=3
B: DのLSが6なので、LF=6, LS=6-2=4
A（分岐点）: B(LS=4)とC(LS=3)の最小値。LF=3, LS=0

3.3 ステップ3：フロート計算とクリティカルパスの特定

タスク	LS	ES	トータルフロート (LS-ES)	クリティカルパスか？
A	0	0	0	YES
B	4	3	1	NO
C	3	3	0	YES
D	6	5	1	NO
E	7	7	0	YES
F	11	11	0	YES
G	14	14	0	YES

分析結果：

このプロジェクトのクリティカルパスは A(要件) → C(デザイン) → E(フロント) → F(テスト) → G(デプロイ) です。

インサイト（第2次考察）：

多くのエンジニアは直感的に「バックエンド（API実装）の方が重い処理だから、そちらがクリティカルパスになるだろう」と考えがちです。しかし計算結果は、所要時間は短くともUIデザイン（C）とフロントエンド実装（E）のパスがボトルネックであることを示しています。

タスクB（DB設計）とタスクD（バックエンド実装）には合計で1日のフロートがあります。つまり、バックエンドエンジニアが1日体調不良で休んでもプロジェクトは遅れませんが、デザイナーやフロントエンドエンジニアの1日の遅れは、即座にリリース遅延に直結します。

第4章：PERT法との統合と不確実性の管理

ここまでのCPM計算は「タスクの所要時間が正確に見積もれる（確定的）」という前提に基づいていました。しかし、ソフトウェア開発は「やってみなければわからない」要素が強く、固定的な見積もりは危険です。ここで登場するのが PERT (Program Evaluation and Review Technique) です⁶。

4.1 3点見積もり（Three-Point Estimation）

PERTでは、1つのタスクに対して3つの時間を見積もります。

楽観値 (Optimistic Time, O): 全てが完璧に進んだ場合の最短時間。
最頻値 (Most Likely Time, M): 通常考えられる現実的な時間。
悲観値 (Pessimistic Time, P): トラブルが起きた場合の最長時間。

これらを用いて、期待所要時間（Expected Time, TE）を加重平均で算出します。一般的にベータ分布を近似した以下の式が用いられます⁸。

$$TE = \frac{O + 4M + P}{6}$$

4.2 標準偏差によるリスク評価

さらに、その見積もりの「不確実性の度合い」を標準偏差（$\sigma$）で計算できます。

$$\sigma = \frac{P – O}{6}$$

例えば、タスクD（バックエンド実装）の見積もりが以下だったとします。

楽観値 = 3日
最頻値 = 5日
悲観値 = 13日（未知のバグ遭遇リスク）

$$TE = \frac{3 + 4(5) + 13}{6} = \frac{36}{6} = 6 \text{日}$$

$$\sigma = \frac{13 – 3}{6} = 1.66$$

CPMでは「5日」として計算していましたが、リスクを考慮したPERTでは「6日」と見積もるべきであり、かつプラスマイナス1.66日の振れ幅があることがわかります。このように、CPMとPERTを組み合わせることで、単なる「遅れ」ではなく「確率的なリスク」としてスケジュールを管理できるようになります。

第5章：スケジュール短縮の戦略：クラッシングとファストトラッキング

プロジェクトマネージャーは、計算された「最短完了日数」よりも早い納期を経営層や顧客から要求されることが常です。スケジュールを圧縮するための2大技法と、ソフトウェア開発における特有のリスクについて詳述します²⁷。

5.1 クラッシング (Crashing)：リソースの追加投入

定義: クリティカルパス上のタスクに対して、追加のリソース（人員、資金、高性能なハードウェア）を投入し、タスクの所要時間を短縮する方法。コストと期間のトレードオフを伴います。

ソフトウェア開発における適用と限界（ブルックスの法則）:

建設現場であれば、作業員を倍にすれば工期が半分になる可能性があります。しかし、ソフトウェア開発には**「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」というブルックスの法則（Brooks’s Law）**が存在します31。

ランプアップタイム (Ramp-up Time): 新しく参加したエンジニアがコードベースや仕様を理解するまでには時間がかかり、その教育のために既存のベテランエンジニアの生産性が一時的に低下します。
コミュニケーションコストの爆発: チーム人数が $N$ 人の場合、コミュニケーション経路は $N(N-1)/2$ で増加します。人数が増えるほど、調整のための会議やチャットが増え、コーディング時間が奪われます。

推奨されるクラッシング戦略:

ソフトウェア開発でクラッシングを行う場合、単純なエンジニア増員は避けるべきです。代わりに以下のような「分割可能なタスク」へのリソース投入が有効です。

テスト工程へのテスター増員
データ入力やドキュメント作成のアウトソーシング
ビルドサーバーの増強による待ち時間の短縮

5.2 ファストトラッキング (Fast Tracking)：工程の並行化

定義: 本来はシーケンシャル（順次的）に行うべきタスクを、並行して（オーバーラップさせて）実行する方法²⁸。

例:

UIデザインが全て完了する前に、確定したヘッダー部分からフロントエンドの実装を開始する。
APIの実装が終わる前に、インターフェース定義（Swaggerなど）だけを合意し、モックサーバーを使ってフロントとバックを同時開発する。

リスク:

最大のリスクは**手戻り（Rework）**です35。もし先行タスク（デザインやAPI定義）に変更が生じた場合、並行して進めていた後続タスク（実装）は無駄になり、修正作業が発生します。これにより、短縮したはずの時間が逆に増大する可能性があります。

比較表：クラッシング vs ファストトラッキング

特徴	クラッシング (Crashing)	ファストトラッキング (Fast Tracking)
アプローチ	コストをかけて時間を買う	リスクを取って時間を捻出する
主な手段	残業、増員、外注	並行作業、部分着手
コストへの影響	増大する	原則変わらない（手戻りがなければ）
リスク	予算超過、ブルックスの法則	手戻りによる品質低下、バグ増加
適した状況	単純作業、予算に余裕がある場合	依存関係が「任意的」である場合

第6章：アジャイル、CCPM、そして2025年のハイブリッド・トレンド

「ウォーターフォール型のCPMは時代遅れであり、アジャイルの時代には不要だ」という議論がありますが、これは誤りです。2025年に向けて、両者は対立するものではなく、補完し合う関係へと進化しています。

6.1 アジャイルとCPMの「ハイブリッド」運用

アジャイル開発（スクラムなど）は、反復的な開発には適していますが、長期的なロードマップやハードウェア製造、大規模なマーケティングキャンペーンとの同期が必要な場合、全体のマイルストーン管理が弱点となります³⁷。

2025年のトレンド：ハイブリッド・アプローチ

マクロ管理（CPM）: プロジェクト全体のマイルストーン（例：展示会デモ、法規制対応期限）はCPMで厳格に管理し、クリティカルパスを可視化します。
ミクロ管理（Agile）: クリティカルパス上の各タスク（例：機能Aの実装）の中身は、スプリント単位のアジャイルで柔軟に進めます。
このアプローチは、予測可能性（Predictability）と適応性（Adaptability）の両立を目指すもので、JiraのAdvanced Roadmapsなどのツールもこの運用をサポートしています39。

6.2 クリティカルチェーン・プロジェクトマネジメント (CCPM)

CPMの「リソース制約を無視しがち」「各タスクにサバ（余裕）を読みすぎる」という欠点を克服するために考案されたのがCCPMです⁴¹。

人間心理と時間の浪費メカニズム:

CCPMは以下の心理的現象に対処します。

学生症候群 (Student Syndrome): 余裕時間があると、ギリギリになるまで着手しない現象⁴⁴。
パーキンソンの法則 (Parkinson’s Law): 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」。つまり、5日で終わる仕事に10日の見積もりを与えると、必ず10日かかる現象。

CCPMの解決策：バッファ・マネジメント

CCPMでは、各タスクの見積もりから「余裕」を徹底的に削ぎ落とし（50%程度の確率で終わるギリギリの時間）、削った余裕をプロジェクトの末尾に**「プロジェクトバッファ」として集約します45。

また、非クリティカルパスがクリティカルパスに合流する地点には「合流バッファ（Feeding Buffer）」**を配置し、メインの工程を守ります。個々のタスクの遅れを責めるのではなく、「バッファの消費率」でプロジェクトの健全性を監視するのが特徴です。

6.3 2025年の最新トレンド：AIと「基本への回帰」

2024年から2025年にかけてのプロジェクトマネジメントにおける注目すべきトレンドは以下の通りです。

AIによる動的予測: 生成AIと機械学習の統合が進み、過去の実績データに基づいて「現在のペースだと、3週間後にクリティカルパスが変わる確率が80%ある」といった予測的洞察（Predictive Analytics）がツールから提供されるようになります²。
アジャイル・ファンダメンタルへの回帰: SAFeのような重厚長大なフレームワークへの疲れから、よりシンプルで本質的なアジャイルの実践や、基本的なエンジニアリングプラクティス（CI/CD、品質重視）への回帰が見られます⁴⁹。
VMO (Value Management Office): 従来のPMO（進捗管理事務局）から、プロジェクトがビジネス価値を生み出しているかを監視するVMOへの移行が進み、CPMも「時間の管理」から「価値提供スピードの管理」へと視座を変えています²。

第7章：ツール活用ガイド：Jira, Asana, Monday.com

理論を実践するには適切なツールが不可欠です。主要なツールのCPM対応機能を比較・解説します。

7.1 Jira (Advanced Roadmaps / Plans)

エンジニアリングチームの標準ツールであるJiraは、Advanced Roadmaps (Plans) 機能によって強力な依存関係管理を提供します³⁹。

機能: タスク間の依存関係（Blockers）を視覚化し、「依存関係マップ」でボトルネックを特定できます。
クリティカルパス: 標準機能では明示的に「赤線」で表示されないこともありますが、設定で「依存関係のあるタスク」をフィルタリングしたり、BigPictureやStructure.Ganttといったアドオンを追加することで、ガントチャート上にクリティカルパスをハイライト表示できます⁵²。
ユースケース: 大規模なソフトウェア開発、複数のチームが絡む複雑なプロジェクト。

7.2 Asana

非エンジニアにも使いやすいUIを持つAsanaは、タイムラインビューで直感的なCPM管理を実現しています⁴。

機能: タスクをドラッグ＆ドロップで線で結ぶだけで依存関係を設定可能。
クリティカルパスのハイライト: タイムライン画面のオプションで「クリティカルパスをハイライト（Highlight critical path）」をオンにするだけで、遅延許容ゼロのタスクが強調表示されます。計算ロジックを知らなくても直感的にリスクを把握できる点が優れています。
ユースケース: マーケティングチームやデザインチームを含むクロスファンクショナルなプロジェクト。

7.3 Monday.com & ClickUp

これらのモダンなワークマネジメントツールは、柔軟性と自動化に強みがあります⁴⁵。

Monday.com: ガントチャートウィジェットにクリティカルパス表示機能があり、オンにすると即座に赤いラインでパスが表示されます。また、CCPM的なバッファ管理用のテンプレートも豊富です。
ClickUp: ガントビューでクリティカルパスを自動計算し、フロート（Slack Time）も表示可能です。UIのカスタマイズ性が高く、スタートアップから大企業まで幅広く対応します。

ツール	CPM機能の特徴	おすすめのユーザー
Jira	依存関係管理が詳細。アドオンで強化可能。	エンジニア中心の大規模組織。アジャイルとの併用。
Asana	最も直感的。ワンクリックで可視化。	非エンジニアを含むチーム。視認性重視。
Monday.com	自動化と連携が強力。CCPM対応も容易。	カスタマイズ性を求めるチーム。業務フローが多様な場合。
MS Project	歴史ある標準。機能は最強だが難解。	建設、公共事業、厳密なウォーターフォール管理が必要な場合。

第8章：ケーススタディ：失敗から学ぶCPMの重要性

最後に、CPMや適切なスケジュール管理を怠った、あるいは誤用したことによる実際のプロジェクト失敗事例から教訓を学びます。

8.1 バーミンガム市議会：Oracle ERP導入の失敗

概要: イギリスのバーミンガム市議会は、OracleベースのERPシステム導入プロジェクトにおいて、不適切な計画とリスク管理により大混乱に陥り、事実上の財政破綻（S114通知）に至りました⁵⁷。

CPM視点での失敗分析:

クリティカルパス上の欠陥の無視: 銀行照合システムなど、業務の根幹に関わる機能（クリティカルパス上のタスク）に重大な欠陥があることが判明していたにもかかわらず、「稼働日（Go-Live）」というマイルストーンを死守するために強行突破しました。
不適切なファストトラッキング: 遅れを取り戻すためにテスト工程やユーザートレーニングを開発と並行、あるいは省略しましたが、結果として稼働後にシステムが動かず、手作業でのリカバリに膨大なコストがかかりました。

教訓: クリティカルパス上のタスクが完了要件（Definition of Done）を満たしていない場合、決して次のフェーズに進んではいけません。

8.2 Stitch Fix：戦略なき技術導入

概要: オンラインスタイリングサービスのStitch Fixは、AI導入において戦略を欠いたままプロジェクトを推進し、期待した成果を得られませんでした⁵⁸。