日本語

クリティカルパス法（CPM）: クリティカルパスの見つけ方

最長経路をハイライトしたクリティカルパス法のネットワーク図

クリティカルパス法は、プロジェクト内の依存関係のある作業の最長シーケンスを特定することで、プロジェクトが取りうる最短の所要時間を算出するスケジューリング技法です。そのパス上の作業が1つでも遅延すれば全体の完了日がずれ込みます。逆に保護できれば、納期を守ることができます。

クリティカルパス法（CPM）とは何か

CPMは、プロジェクト内のすべてのタスクをマッピングし、依存関係で結び、各タスクの最早・最遅開始時刻を計算し、スケジュール上の余裕（フロート）がゼロのタスクの連鎖をクリティカルパスとしてフラグを立てるスケジューリングアルゴリズムです。その連鎖がプロジェクトの最短所要時間を決定します。

起源: DuPontのMorgan WalkerとRemington Randのジェームズ・ケリーが1957年に、複雑な化学プラントのシャットダウン管理のためにCPMを開発しました。高コストのダウンタイムを削減することが目的でした。CPMは実際にメンテナンス時間を大幅に短縮し、10年以内に業界全体に広まりました。

重要な洞察: すべてのタスクが等しく重要なわけではありません。一部のタスクには余裕時間（フロートまたはスラックと呼ばれる）があります。クリティカルパス上のタスクには一切余裕がありません。

タスク、所要時間、最長経路を通るクリティカルパスを示すシンプルなネットワーク

重要なデータ

DuPontの報告によると、CPMは1950年代後半に化学プラントのメンテナンスシャットダウンを推定25%短縮しました（DuPont社内報告、1959年）。

PMIのPMBOKガイドはCPMをスケジュールネットワーク分析の基本手法として位置づけており、初版から第7版まで全版に収録されています（PMI、PMBOK Guide 7th Edition、2021年）。

Gartnerの予測では、グローバルのプロジェクト管理ソフトウェア市場は2027年までに98億ドルを超えると見込まれており、CPMのようなスケジュール最適化機能が主要な成長要因のひとつです（Gartner、2023年）。

主要用語

計算を始める前に、これらの用語を頭に入れておきましょう。

用語 記号 意味
アクティビティ -- 明確な開始・終了・所要時間を持つ個別の作業
所要時間 d アクティビティを完了するのに必要な時間（日、時間など）
先行作業 -- 現在のアクティビティを開始する前に完了しなければならないアクティビティ
後続作業 -- 現在のアクティビティが終了するまで開始できないアクティビティ
最早開始 ES 先行作業を考慮した、最も早くアクティビティを開始できる時刻
最早終了 EF アクティビティが終了できる最早時刻（ES + 所要時間）
最遅開始 LS プロジェクトを遅延させずにアクティビティを開始できる最遅時刻
最遅終了 LF プロジェクトを遅延させずにアクティビティを終了できる最遅時刻
フロート / スラック F プロジェクトの終了日を延ばさずにアクティビティを遅延できる時間（LS - ES）
クリティカルパス -- フロートがゼロのアクティビティのシーケンス、プロジェクト所要時間を決定

フォワードパスとバックワードパス

CPMはネットワーク上の2回のスイープを使って、すべてのアクティビティのタイミングを計算します。

フォワードパス（最早時刻）

最初のアクティビティから終わりに向かって作業します。

  • ES = すべての直近の先行作業のEFの最大値（先行作業がない場合は0）
  • EF = ES + 所要時間

これによって、プロジェクト全体の最早完了日がわかります。

バックワードパス（最遅時刻）

最後のアクティビティから始点に向かって作業します。

  • LF = すべての直近の後続作業のLSの最小値（後続作業がない最終アクティビティはプロジェクト終了日）
  • LS = LF - 所要時間

フロートの計算

両方のパスが完了したら:

  • フロート = LS - ES（同等に、LF - EF）

フロートがゼロのアクティビティはクリティカルパス上にあります。

2つのタスクのES、EF、LS、LFを示すフォワードパスとバックワードパスの計算式

6ステップでクリティカルパスを見つける方法

ステップ1: アクティビティと所要時間を列挙する

プロジェクトを完了するために必要なすべてのタスクを書き出し、各タスクの所要時間を見積もります。

  • 作業を測定可能な個別のアクティビティに分解する
  • 各アクティビティに現実的な所要時間を割り当てる（過去データや専門家の見積もりを使用）
  • すべてのアクティビティに固有の識別子を付ける（A、B、Cまたはタスク1、タスク2など）

ステップ2: 依存関係を特定する

どのアクティビティが他のアクティビティより先に完了しなければならないかを決定します。

  • すべてのタスクについて「これを始める前に何を完了しなければならないか？」を問う
  • 先行作業と後続作業の関係を表またはマトリクスで記録する
  • 終了から開始、開始から開始、終了から終了のリンクタイプに注意（デフォルトはCPMでは終了から開始）

ステップ3: ネットワーク図を描く

アクティビティをノード、依存関係を矢印として、プロジェクトを有向グラフとして視覚化します。

  • 依存関係に基づいてアクティビティを左から右へ順に配置する
  • 開始から終了までのすべてのパスが接続されていることを確認する
  • フローチャートや専用のプロジェクト計画ツールを使って図を明確に描く

ステップ4: フォワードパスを実行する

左から右へスイープし、すべてのアクティビティのESとEFを計算します。

  • 先行作業のないアクティビティはES = 0から開始
  • すべての合流点でES = max（先行作業のEF）を適用
  • 各アクティビティにEF = ES + 所要時間を記録

ステップ5: バックワードパスを実行する

右から左へスイープし、すべてのアクティビティのLFとLSを計算します。

  • 後続作業のないアクティビティはLF = プロジェクト終了日（最終アクティビティのEF）から開始
  • すべての分岐点でLF = min（後続作業のLS）を適用
  • 各アクティビティにLS = LF - 所要時間を記録

ステップ6: フロートゼロのアクティビティを特定する（クリティカルパス）

すべてのアクティビティのフロートを計算し、フロート = 0の連鎖をハイライトします。

  • 各アクティビティについてフロート = LS - ES
  • フロート = 0のアクティビティがクリティカルパスを形成
  • 2つの連鎖が両方ともフロートゼロの場合、プロジェクトには複数のクリティカルパスがある（下のFAQ参照）

実例: 7タスクプロジェクト

7つのアクティビティを持つソフトウェアリリースプロジェクトを考えます。

アクティビティ 先行作業 所要時間（日） ES EF LS LF フロート
A: 要件定義 -- 3 0 3 0 3 0
B: UIデザイン A 4 3 7 5 9 2
C: データベーススキーマ A 6 3 9 3 9 0
D: フロントエンド開発 B 5 7 12 9 14 2
E: バックエンド開発 C 5 9 14 9 14 0
F: 統合 D, E 3 14 17 14 17 0
G: テストとリリース F 2 17 19 17 19 0

クリティカルパス: A - C - E - F - G（合計所要時間: 19日、フロートは全体でゼロ）。

アクティビティBとDはそれぞれ2日のフロートがあります。つまり、UIデザインは2日まで遅延してもリリース日に影響しません。しかし、バックエンド開発（E）が1日でも遅れれば、後続のすべてのアクティビティも遅れます。マネジメントの注意を向けるべきはそこです。

7タスクのネットワークにフロートを計算し、ゼロフロートの連鎖をクリティカルパスとしてハイライトしたCPMの実例

CPMとPERTとガントチャートの比較

これら3つのツールはよく混同されますが、それぞれ異なる目的に使われます。

手法 最適な用途 所要時間の扱い 出力
CPM タスク所要時間がよく知られているプロジェクト 単一の確定的な見積もり クリティカルパス、フロート値、スケジュール短縮の選択肢
PERT 所要時間が不確かなR&Dや新規プロジェクト 3点見積もり（楽観、最多発生、悲観） 確率的な完了日、期待所要時間
ガントチャート スケジュールを視覚的に伝達する カレンダーベースのバーチャート タイムライン表示、リソース割り当て、マイルストーンマーカー

CPMとPERTはよく補い合います。所要時間が不確かな場合は最初にPERTを実行し、得られた見積もりをCPMに渡してクリティカルパスを特定します。ガントチャートとはは、多くの場合両者の上に載せる最終的なコミュニケーションレイヤーです。

構造化された納品アプローチに従う場合、CPMをWaterfallメソドロジーやKanbanボードと連携させることで、スケジュールを実際の進行中の作業と結びつけることができます。

クラッシングとファストトラッキング: クリティカルパスを短縮する方法

クリティカルパスが長すぎる場合、主に2つの選択肢があります。

クラッシング

クラッシングとは、クリティカルパス上のアクティビティにリソースを追加して所要時間を短縮することです。開発者を増員する、製造ラインにシフトを追加するなど。ほとんどの場合コストが増加するため、標準的なアプローチはコスト1単位あたり最も多くの時間を節約できるアクティビティからクラッシュさせ、その後クリティカルパスを再確認します（クラッシュ後にパスが変わる可能性があります）。

リスク: コスト超過。アクティビティはある程度まで短縮できますが、その先は収穫逓減の法則が働きます。

ファストトラッキング

ファストトラッキングとは、当初は順番に計画されていたアクティビティを並行して実行することです。例えば、データベーススキーマが完全に承認される前にバックエンド開発を開始するなど。追加予算なしで大幅な時間節約になります。

リスク: やり直し。後続作業が開始した後に先行作業に変更が生じた場合、作業のやり直しが必要になる可能性があります。ファストトラッキングは重複が小さく依存関係が緩い場合に最もうまく機能します。

両方の技法は変更後にフォワードパスとバックワードパスを再実行する必要があります。クリティカルパスが変わるためです。

CPMのメリットと制限

メリット

  • 作業開始前にプロジェクトの真の最短所要時間を明らかにする
  • マネジメントの注意を向けるべき場所を特定する（フロートゼロのアクティビティ）
  • トレードオフの意思決定の基礎を作る: コスト対時間、リスク対スピード
  • リソース平準化やビジネスプロセスマネジメントフレームワークと自然に統合できる
  • PMBOKやPRINCE2を含む多くのプロジェクトマネジメントコンピテンシーフレームワークでサポートされている

制限

  • タスクの所要時間が既知かつ固定であることを前提とする（新規プロジェクトでは不安定な前提）
  • 大規模プロジェクトでは（数百から数千のアクティビティ）ネットワーク図が扱いにくくなる
  • デフォルトでリソース制約を無視する。リソース平準化のステップが別途必要
  • フロート計算は見積もりが不正確な場合、誤った安心感を生む可能性がある
  • 不確実性をうまく扱えない。所要時間が見積もりの場合はCPMと並行してPERTを使用する

よくある質問

CPMとPERTの違いは何ですか？

CPMは各アクティビティに単一の固定所要時間見積もりを使い、確定的なクリティカルパスを生成します。PERTは3つの見積もり（楽観、最多発生、悲観）を使い、確率加重の期待所要時間を生成します。同様の作業を以前に行ったことがある場合はCPMが適しており、所要時間が本当に不確かな場合はPERTが適しています。

プロジェクトに複数のクリティカルパスがありえますか？

はい。2つ以上のアクティビティの連鎖がそれぞれフロートゼロで同じプロジェクト終了日に達する場合、それらはすべてクリティカルパスです。複数のクリティカルパスはスケジュールリスクを高めます。どの連鎖でも遅延が発生すれば最終日がずれるためです。この状況では、管理者はどちらの連鎖も同時に遅延しないよう、リソースの優先配分を行うことが多いです。

クリティカルパスはプロジェクト中に変わりますか？

変わることがあります。しかも頻繁に変わります。非クリティカルなアクティビティがフロートを使い果たすほど遅延すれば、それはクリティカルになります。クリティカルなアクティビティが早めに完了すれば、別の連鎖が新しいボトルネックになる可能性があります。ベストプラクティスは、特にスコープ変更やリソース中断の後、すべてのステータス更新サイクルでクリティカルパスを再計算することです。

フロートとはどういうものですか、どう計算しますか？

フロート（スラックとも呼ばれます）とは、プロジェクトの終了日を延ばさずにアクティビティを遅延できる時間です。計算式はフロート = LS - ES（または同等に、LF - EF）です。フロートがゼロとはアクティビティがクリティカルパス上にあり、スケジュール上の余裕が全くないことを意味します。フロートが3日とは、そのアクティビティを最大3日遅らせてもプロジェクトを期限通りに完了できることを意味します。

クリティカルパスを計算するソフトウェアは何がありますか？

ほとんどのプロジェクト計画プラットフォームは、タスク、所要時間、依存関係を入力すると自動的にCPM計算を行います。一般的な選択肢には、Microsoft Project、Primavera P6（大規模エンジニアリングプロジェクト向け）、Smartsheet、TeamGantt、Reworkなどがあります。オープンソースツールのProjectLibreもフロートを計算しクリティカルパスをハイライトします。スプレッドシートベースのCPMも可能ですが、プロジェクトが成長するにつれてメンテナンスが煩雑になります。

クリティカルパスを理解することが第一歩です。次のステップは、それを継続的に監視するシステムを構築することです。RACIマトリクスでクリティカルパス上の各アクティビティのオーナーを定義し、トラッキングツールがリアルタイムでフロートを再計算するようにすれば、事後対応の消火活動から事前予防的なスケジュール管理へとシフトできます。プロジェクトが期限通りに実際に完了するのはそういう状態においてです。