クリティカル パス手法はどこから来たのですか?
クリティカル パス法は、1957 にモーガン R. ウォーカー (デュポン) とジェームス E. ケリー ジュニア (レミントン ランド) によって、産業メンテナンスの停止をスケジュールするために開発されました。最初の適用により、デュポン工場の操業停止時間が 125 時間から 93 時間に短縮され、25% 改善されました。アメリカ海軍は、ポラリスミサイル計画のために同時期に独自にPERTを開発した。それ以来、CPM と PERT は共存してきました。
クリティカル パス法 (CPM) は 1957 に誕生し、デュポン社の モーガン R. ウォーカー とレミントン ランドの ジェームズ E. ケリー ジュニア によって開発されました。彼らの目標は、時間やお金を無駄にすることなく、複雑な産業メンテナンスの停止をスケジュールする方法という具体的な問題を解決することでした [1]。
デュポンは 1956 年にレミントン ランド ユニバックと合弁会社を設立し、UNIVAC I コンピューターを使用してスケジューリング アルゴリズムをテストしていました。最初に成功した CPM の適用はプラント保守プロジェクトに適用され、停止期間が 125 時間から 93 時間に短縮され、25% 改善されました [1][2]。
同じ頃、アメリカ海軍は、ポラリスミサイル潜水艦計画のためにブーズ・アレン・ハミルトンと共同で PERT (計画評価およびレビュー技術) を開発していました。 PERT は確率的な時間推定 (楽観的、最も可能性が高い、悲観的) を使用しましたが、CPM は決定論的な単一点推定を使用しました。これにより、タスク期間が予測可能なプロジェクトにとってより実用的になります [1][3]。
現在、CPM は PMI PMBOK® ガイド (プロジェクト管理知識体系)、特に「スケジュールの作成」プロセス グループの基礎となるテクニックとして認識されています [4][5]。
クリティカル パスとは一体何でしょうか?
クリティカル パスは、プロジェクト内の依存タスクの最長のチェーンであり、可能な最小プロジェクト期間を決定します。クリティカル パス タスクが遅延すると、プロジェクト全体の終了日も同じだけ後ろにずれます。クリティカル パス上にないタスクには「フロート」があり、フロート量までは期限に影響を与えることなくスリップする可能性があります。
このように考えてください。プロジェクトが道路ネットワークである場合、クリティカル パスは最初から最後までの最長ルートになります。短い道路をどれだけ速く走っても、そのルートの長さよりも移動距離を短縮することはできません。
主要な概念
| 期間 | 定義 |
|---|---|
| クリティカル パス | プロジェクトの開始から終了までの依存タスクの最長チェーン |
| フロート (スラック) | プロジェクトの終了日に影響を与えずに、重要ではないタスクを遅延できる時間の長さ。 |
| 早期スタート (ES) | 先行タスクに基づいて最も早くタスクを開始できる |
| レイトスタート (LS) | プロジェクトを遅らせることなく、最も遅いタスクを開始できる |
| 早期終了 (EF) | タスクが最も早く終了する可能性がある |
| レイトフィニッシュ (LF) | プロジェクトを遅らせることなく最後のタスクを完了できる |
| 総フロート | LF − EF (または LS − ES)。 float = 0 の場合、タスクはクリティカル パス上にあります |
CPM は段階的にどのように機能するのでしょうか?
CPM は 4 つのステップで機能します。(1) すべてのタスクをその期間と依存関係とともにリストする、(2) フォワード パス – 各タスクが開始および終了できる最も早い時間を計算する、(3) バックワード パス – プロジェクトを遅らせることなく各タスクが開始できる最も遅い時間を計算する、(4) フロートがゼロのタスクを特定する – これらはクリティカル パスを形成します。以下の例は、8 タスクの小さなソフトウェア プロジェクトで動作します。
ステップ 1: すべてのタスクと期間をリストする
プロジェクトを個々のタスクに分割し、それぞれのタスクの期間を見積もります。
| タスク | 期間 (日) | 依存関係 |
|---|---|---|
| A — 要件 | 5 | — |
| B — UI デザイン | 8 | あ |
| C — データベース設計 | 4 | あ |
| D — バックエンド開発 | 10 | C |
| E — フロントエンド開発 | 12 | B |
| F — 統合 | 6 | D、E |
| G — テスト | 5 | F |
| H — 導入 | 2 | G |
ステップ 2: フォワードパス (早期スタート/早期終了を計算)
最初のタスクから始めて、各タスクが開始および終了できる最も早い時間を計算します。
- A: ES=0、EF=5
- B: ES=5、EF=13
- C: ES=5、EF=9
- D: ES=9、EF=19
- E: ES=13、EF=25
- F: ES=25、EF=31 (D と E の両方を待機)
- G: ES=31、EF=36
- H: ES=36、EF=38
プロジェクト期間: 38 日間。
ステップ 3: 後方パス (遅延スタート/終了を計算)
最後から逆算して、プロジェクトを遅らせることなく各タスクを開始できる最新の時刻を計算します。
- H: LS=36、LF=38
- G: LS=31、LF=36
- F: LS=25、LF=31
- E: LS=13、LF=25 → Float = 0 ✅ クリティカル
- D: LS=15、LF=25 → Float = 6
- B: LS=5、LF=13 → Float = 0 ✅ クリティカル
- C: LS=11、LF=15 → Float = 6
- A: LS=0、LF=5 → Float = 0 ✅ クリティカル
ステップ 4: クリティカル パスを特定する
ゼロフロートのタスクはクリティカル パスを形成します。
A → B → E → F → G → H (38 日)
これらのタスクに遅れがあると、プロジェクト全体が遅れます。タスク C と D には 6 日間のフロート期間があり、期限に影響を与えることなく最大 6 日間遅れる可能性があります。
なぜ CPM が重要なのでしょうか?また、データは何を示していますか?
時間通り、予算通り、範囲内で出荷されるプロジェクトはわずか約 31% であるため、CPM が重要です (Standish Group CHAOS レポート 2020 — ペイウォール レポートの独立したレビューを通じて広く引用されている数字)。失敗の主な原因 — 定義が不十分な要件、不適切なコミュニケーション、進捗状況の可視性の弱さ — はまさに CPM が対処することを強いるものであり、明示的な依存関係、視覚的なタイムライン、およびどのタスクが見逃せないかの明確なマーカーです。実証研究では、一貫して CPM に基づいたスケジューリングがプロジェクト超過の削減と関連付けられています。
プロジェクトの失敗は蔓延しています。 スタンディッシュ グループの CHAOS レポート (2020) によると、プロジェクトの 31% のみが予定通り、予算内で、範囲内で納品されています。 50% は問題に直面しています (遅延または範囲の削減を伴う配信)、19% は完全に失敗します [7]。
PMI Pulse of the Profession® (2021) では、プロジェクト失敗の主な原因が特定されました [8]。
| 原因 | 影響を受けるプロジェクトの割合 |
|---|---|
| 組織の優先順位の変更 | 39% |
| プロジェクトの目標の変更 | 37% |
| 要件が不十分に定義されている | 35% |
| コミュニケーション不足 | 30% |
| 進捗状況の可視性の欠如 | 29% |
CPM は最後の 3 つの原因に直接対処します。つまり、タスクの依存関係を明確に定義すること**(要件)を強制し、コミュニケーション ツールとして機能する視覚的なタイムラインを提供し、チームがどこに注力すべきかを正確に把握できるようにクリティカル パスを強調表示します。
ResearchGate で公開された調査によると、CPM を利用したプロジェクトは、正式なスケジューリング技術を使用していないプロジェクトと比較してタイムライン順守が大幅に向上し、適切なモニタリングと組み合わせることでプロジェクトの超過が最大 20 ~ 30% 削減されることが確認されています [9]。
CPM と PERT をいつ使用する必要がありますか?
タスクの期間が予測可能な場合 (建設、製造、IT リリース) には、CPM を使用します。単一点の見積もりは十分に正確で、コスト/時間の明確な最適化が必要です。 期間が不確実な場合 (研究、研究開発、新規エンジニアリング) には、**PERT を使用します。その 3 点推定値 (楽観的 / 最も可能性が高い / 悲観的) は、分散をより適切に処理します。ほとんどのソフトウェア チームが CPM を使用しているのは、タスクの範囲が十分に限定されているため、PERT の統計機構がオーバーヘッドに値しないためです。
CPM と PERT はどちらも 1950 年代後半に登場しましたが、それぞれ異なるシナリオに対応します。
| アスペクト | CPM | パート |
|---|---|---|
| 所要時間の目安 | 単一 (決定的) | 3 つの推定 (楽観的、最も可能性が高い、悲観的) |
| こんな人に最適 | 予測可能で反復的なプロジェクト | 不確実で研究の多いプロジェクト |
| 集中 | 時間とコストの最適化 | 不確実性の下での時間の見積もり |
| 複雑さ | 下位 — タスクごとに 1 つの期間 | より高い - 統計的計算 |
| 産業用途 | 建設、製造、IT | 研究開発、防衛、製薬 |
International Journal of Applied Engineering Research に掲載された比較事例研究では、情報システム プロジェクトの場合、CPM は 50 日で完了すると見積もったのに対し、PERT は 52 日で完了すると見積もっていました。研究者らは、予測可能な範囲のプロジェクトにおける精度と費用対効果の観点から CPM を推奨しました [10]。
ほとんどのソフトウェア開発チームにとって、CPM が現実的な選択です。タスクは一般的に明確に定義されており、確率分布ではなく実用的なスケジューリングが必要です。
GanttFather はどのようにして CPM を簡単にしますか?
GanttFather は、タスク、期間、依存関係に基づいて クリティカル パスを自動的に計算します。手動による前方/後方パスは必要ありません。重要なタスクは、編集中にリアルタイムでガント タイムライン上で点灯します。クリティカル パスは 無料枠 に含まれています (ほとんどの競合他社は、ユーザーあたり月額 12 ~ 30 ドルのビジネス レベルまたはプロ レベルに料金を支払います)。 What-if シナリオは即座に実行されます。期間を変更して、クリティカル パスの再計算をライブで監視します。
従来、クリティカル パスを計算するには、手作業による計算か、専用の (そして高価な) エンタープライズ ツールが必要でした。 GanttFather はこれを変更します。
クリティカル パスの自動検出
GanttFather は、タスクの依存関係と期間に基づいてクリティカル パスを 自動的に計算します。手動による前方/後方パスは必要ありません。重要なタスクはガント チャート上で即座に強調表示されます。
視覚的な依存関係管理
タスク間の依存関係の矢印をチャート上で直接ドラッグします。 GanttFather は、依存関係を追加、削除、または変更すると、クリティカル パスをリアルタイムで更新します。
What-If シナリオ
タスク E に 12 日ではなく 15 日かかるとどうなるか疑問に思いませんか?期間を変更するだけで、クリティカル パスが再計算されるのを確認できます。これにより、スプリントの計画とリスク評価が直感的に行えるようになります。
お手持ちのツールと連携
チームが Azure DevOps を使用している場合は、作業項目を GanttFather に同期して、クリティカル パスをすぐに視覚化できます。これは Azure DevOps がネイティブに提供していないものです。
CPMを効果的に使用するための実践的なヒントは何ですか?
5 つの実用的なルール: タスクの粒度を 1 ~ 10 日にする (WBS が詳細すぎるとクリティカル パスがうるさくなる)、期間を毎週更新する (古いクリティカル パスは誤解を招く)、クリティカルに近いパスを監視する (フロートが 1 日あるタスクは実質的にクリティカルであり、それがずれた瞬間に新しいクリティカル パスになります)、フロートを戦略的に使用することで範囲が不確実なタスクを吸収し、クリティカル パスを他のユーザーと共有する関係者* をサポートするため、チームはどこに最も重点を置くかがわかります。
-
WBS を詳細にしすぎないでください。 マイクロタスクが多すぎると、クリティカル パスにノイズが発生し、実行が困難になります。タスクはそれぞれ 1 ~ 10 日かかる粒度でタスクを実行してください。
-
期間を定期的に更新します。 クリティカル パスの正確さは、そのデータによって決まります。タスクの見積もりを毎週確認して更新します。
-
クリティカルに近いパスに注意してください。 フロートが 1 日しかないタスクは、実質的にクリティカルです。滑ると新たなクリティカルパスとなる。
-
フロートを戦略的に使用します。 フロートが大きい非クリティカルなタスクは遅延を吸収できます。範囲が不確実なタスクにはこの柔軟性を使用してください。
-
クリティカル パスを伝達します。 関係者と共有して、プロジェクトを遅らせずにどのタスクを見逃してはいけないかを全員が理解できるようにします。
結論
クリティカル パス法は、70 年近くにわたってプロジェクトのスケジューリングの根幹となってきましたが、それには十分な理由があります。これにより、複雑で相互依存するプロジェクト計画が明確な答えに変換されます: **このプロジェクトにかかる最小時間はどれくらいですか?どのタスクをスケジュール通りに進める必要がありますか?
ソフトウェア スプリント、建設プロジェクト、製品発売のいずれを管理している場合でも、クリティカル パスを理解することが、遅延への対応と遅延の防止の違いとなります。
GanttFather は自動的にリアルタイムで無料で計算します。無料プランには、所有する 1 プロジェクト、2 つの編集者シート、無制限の閲覧者とゲストが含まれます。全文を見る 価格ページ または読む GanttFatherとは何ですか? 製品の詳細については、
参考文献:
- ウィキペディア。 「クリティカル パス メソッド — 歴史」。
- ケリー、J.E. ジュニア & ウォーカー、M.R. (1959)。 「クリティカル パスの計画とスケジューリング」。 東部合同コンピュータ会議の議事録。
- マルコム、D.G.ら (1959)。 「研究開発プログラム評価手法の応用」 オペレーションズリサーチ、7(5)、646–669。
- プロジェクト管理協会 (PMI)。 (2021年)。 プロジェクト管理知識体系ガイド (PMBOK® ガイド) — 第 7 版。
- スマートシート。 「クリティカル パス メソッド (CPM) の完全ガイド」。
- プロジェクトマネージャー.com。 「クリティカル パス手法: プロジェクト管理の要点」。
- スタンディッシュ・グループ。 (2020年)。 「CHAOSレポート2020:無限の彼方」。
- プロジェクト管理協会 (PMI)。 (2021年)。 「パルス・オブ・ザ・プロフェッショナル® 2021」。
- リサーチゲート。 「建設プロジェクトにおけるCPMとスケジュール遵守」。
- アンワル、N. 他 (2014)。 「プロジェクトスケジューリングにおけるCPMとPERTの比較研究」。 国際応用工学研究ジャーナル。