クリティカル パス法 (CPM) とは？
プロジェクト マネジメント知識体系 (PMBOK: Project Management Body of Knowledge) は、プロジェクト管理のベスト プラクティスとして受け入れられているプロセスや知識分野を含む国際的に認められたコレクションであり、クリティカル パスを「プロジェクトの期間を決定する一連のスケジュールされたアクティビティ (活動)」と定義しています。クリティカル パスは、プロジェクト計画において最長の一連タスクであり、プロジェクトの期限を守るためにはこれらのタスクをスケジュールどおりに完了しなければなりません。 クリティカル パス上にあるタスク (クリティカル パス タスク) に遅れが生じた場合、プロジェクト全体に遅れが生じることになります。 多くのプロジェクトにはクリティカル パスが 1 つだけ含まれていますが、1 つのプロジェクトに複数のクリティカル パスが存在することもあります。
クリティカル パス法は、クリティカル パス上のアクティビティを識別する段階的なプロジェクト管理手法です。 このアプローチでは、プロジェクトを複数の作業タスクに分割してフロー チャートに表示し、各タスクの見積もり期間に基づいてプロジェクトの期間を算出することにより、プロジェクト スケジューリングを行います。 すると、プロジェクトを時間どおりに完了させるのに重要なタスク、つまりクリティカル タスクを把握できるようになります。
土木技師でプロジェクト マネージャーでもあり、4 冊の書籍の著者でもある Larry Bennett 博士は、1978 年に出版した彼の著書『Critical Path Precedence Networks (原題)』の中で、クリティカル パス法が 2 つの異なる方法でプロジェクト管理に役立つとして、次のように述べています: 「クリティカル パス法は、プロジェクト チームを導く計画されたスケジュールを生み出し、タスクの進捗状況について計画と実績を比較することによってプロジェクト スケジュールのパフォーマンスを追跡する基盤を形成します。
プロジェクト管理ガイド
プロジェクト管理のすべてが一元的に
プロジェクト管理の取り組みを向上させる準備はできていますか？作業をより効果的に管理するためのヒント、ベスト プラクティス、無料のリソースについては、包括的なプロジェクト管理ガイドをご覧ください。
クリティカル パスの背景と歴史
Bennett 博士はクリティカル パスに精通しており、 1965 年以来さまざまなプロジェクトにクリティカル パス スケジューリングを適用してきました。 また米国アラスカ大学フェアバンクス校工学部の学部課程と大学院課程で 29 年間、プロジェクト管理とスケジューリングを含む技術管理を教えた経験もあります。
書籍以外にも Bennett 博士は、コンストラクション マネジメントから、プロジェクト スケジューリングのためのネットワーク図の書き方まで、幅広いトピックの専門論文や記事を 50 以上も発表しています。
元来のクリティカル パス法が手動だったことを考えると 非常に大きな進歩を遂げたクリティカル パスについて、 Bennett 博士は次のように説明しています。
「オリジナルのクリティカル パス法では、矢印を使用してタスクを表し、ノードの開始と終了をつなげることによってタスクを結び付けてシーケンス (順序) が作成されるようにしていました。 このアプローチが 10 年間ほど続いた後、結果は同じでも違った方法に人気が集まり始めました。 米国スタンフォード大学でコンストラクション マネジメントを教えていた John W. Fondahl 教授が 1961 年に書いた論文の中で、各タスクを四角形、円、または楕円のノードで表し、タスク間のシーケンスを表す線や矢印を使用してノードを結び付けるようにすることを提案したのです。 このアプローチは、アクティビティ オン ノード (AON: Activity On Node) またはプレシデンス ダイアグラム法 (PDM: Precedence Diagramming Method) と呼ばれており、以前のアクティビティ オン アロー (AOA: Activity On Arrow) つまりアロー ダイアグラム法 (ADM: Arrow Diagramming Method) に取って代わるものとなりました。」
クリティカル パス法が生まれたきっかけ
クリティカル パス法を使用したプロジェクト スケジューリングは、1950 年代後半に 2 つの無関係のプロジェクトでほぼ同時に開始されました。 当時アメリカ海軍では、潜水艦発射弾道ミサイル「ポラリス」の開発プログラムにスケジュールの遅れが発生していたため、解決策を必要としていました。 そこで提案されたのが、プロジェクトを何千ものタスクに分割して各タスクを矢印で表し、これらの矢印を正しいシーケンスで結び付け、各タスクの期間を見積もると同時に、プロジェクトの期間と各タスクのスケジュール重要度を判断するという方法でした。
これと同時期に、アメリカの化学会社 E. I. du Pont de Nemours and Company (デュポン) では、工場でのターンアラウンドに遅れが発生する問題があったため、製造施設を別の製品用に再編成するプロジェクトを立ち上げることになり、 解決策を求めた結果、上記と同様の方法が提案されました。
アメリカ海軍のアプローチはパート (PERT: Program/Project Evaluation and Review Technique)、デュポン社のアプローチはクリティカル パス メソッド (CPM: Critical Path Method) とそれぞれ呼ばれました。 これら 2 つのアプローチは似ているものの、タスク期間の見積もりには異なる手法が使用されました。
PERT では、各タスク期間に対して 3 つの異なる時間見積もりを使用して、特定時点までにプロジェクトを完了できる確率が計算されました (「三点見積もり」を行う手法)。 CPM では、プロジェクトの完了までにかかる時間だけでなく、プロジェクト期間を短縮した場合にかかる追加のコストを分析することも考慮に入れて、各タスクには 1 つの時間見積もりが使用されました。
現在、PERT と CPM という用語は区別せずに使われることが多いのですが、これについて Bennett 博士は、「どちらもネットワーク図を用いてスケジューリングを行うことから、併せて PERT/CPM と呼ばれることもあります。オリジナルの PERT のように三点見積もりを行って確率的にスケジュールを算出しなくなっただけです。」と述べています。
クリティカル パスを日常的に使用することで得られるメリット
クリティカル パスは、生まれてから 50 年以上経った今も、プロジェクト マネージャーが重宝するツールです。 クリティカル パスを使用すると、プロジェクトのアクティビティを視覚的に表示して、タスクの完了に必要な時間を明確に示し、スケジュールに遅れが発生しないようにアクティビティを追跡できるようになるからです。 また、クリティカル パス法では、各アクティビティの完了までにかかる最短時間と最長時間を計算する必要があるため、不確実性も減ります。 タスクに影響を与える可能性がある予想外の要素を必然的に考慮するようになれば、プロジェクト中に何か予期せぬことが発生して驚くことも少なくなります。
Bennett 博士によれば、プロジェクト マネージャーがクリティカル パス法を使用すると以下の 3 つのメリットがあるとのことです。
- 最も重要なタスクを把握する: まず最初に、しっかり管理しなければならないタスクが明確に特定されます。 クリティカル パス上のタスクが (1) 見積もり期間よりも長くかかった場合、(2) 予定よりも遅く開始した場合、または (3) 予定よりも遅く終了した場合、プロジェクト全体が影響を受けることになるため、これは非常に重要です。
- タイムライン/スケジュールの短縮に役立つ: 2 つ目に、「初期分析でプロジェクト完了時間を予測した後に、より短い期間でプロジェクトを完了させる必要性が生じた場合でも、どのタスクなら期間の短縮につながるかがすぐに分かります。」と、Bennett 博士は言います。 クリティカル パス法に基づく結果をガント チャートのような棒グラフとして表示すると、タイムフレーム (時間枠) 全体におけるタスクの位置づけが一目で分かるようになって便利です。 これは、クリティカル パス上のアクティビティ/タスク、およびタスクの期間とシーケンスを視覚化することにより、 プロジェクトのスケジュールに関して高い洞察力が提供され、変更できるタスク期間と変更できないタスク期間がはっきりするからです。
- 計画と実績を比較する: 最後に、Bennett 博士は次のように述べています: 「プロジェクトが開始すると、最初のクリティカル パス分析 (CPA: Critical Path Analysis) で立てたオリジナルのスケジュールを使用して進捗状況を追跡していくことになります。 これにより、マネージャーはプロジェクトの遂行中に、既に完了しているタスク、進行中のタスクに必要とされる残りの予測期間、および将来におけるタスクのシーケンスと期間に対する変更予定を把握することが可能です。 プロジェクトが進行するにつれてスケジュールが更新されても、オリジナルのスケジュールと比較して視覚表示されれば、進捗状況が一目瞭然になります。」
クリティカル パス法における主要手順
クリティカル パス法には、6 つの主なステップが含まれます。
ステップ 1: 各アクティビティを指定する
まず、ワーク ブレークダウン ストラクチャ (WBS: Work Breackdown Structure) を作成して、プロジェクトに関連する各アクティビティ/タスクを識別する必要があります。 この際、大まかなアクティビティのみをリストアップするようにしてください。 ここで詳細なアクティビティを指定すると、クリティカル パス分析が複雑になり、管理と維持が大変になるためです。
ワーク ブレークダウン ストラクチャを作成すると、プロジェクトを管理可能なセクションに分割できます。
最初にプロジェクトの主要成果物を識別したら、 大まかなアクティビティを詳細な作業に分割することが可能になります。
ワーク ブレークダウン ストラクチャの表現方法はいくつもあり、 ツリー形式、表形式、アウトライン形式 (箇条書き) が一般的に使用されていますが、 アウトライン形式を選ぶと一番簡単でしょう。
ステップ 2: 依存関係 (アクティビティ シーケンス) を確立する
特定のアクティビティが、他の指定のアクティビティの完了に依存している場合があります。 各アクティビティの先行アクティビティ (特定のアクティビティよりも先または同時に開始あるいは終了するアクティビティ) をリストアップすると、正しい順序の識別に役立ちます。 アクティビティと優先順位を正しく識別するためには、ステップ 1 で作成したリストに含まれる各アクティビティに対して、以下の 3 つの質問をしてみましょう。
- このタスクの前に実行しなければならないタスクはどれか？
- このタスクと同時に終了しなければならないタスクはどれか？
- このタスクの直後に実行しなければならないタスクはどれか？
ステップ 3: ネットワーク図を描く
アクティビティと依存関係を識別すると、ネットワーク図の作成が可能になります。 ネットワーク図とは、依存関係に基づいてアクティビティの順序を視覚的に示したものです。
以前はこのクリティカル パス図を手書きで作成する必要がありましたが、現在はソフトウェア プログラムで簡単に作成できるようになりました。
ステップ 4: アクティビティの完了時間を見積もる
次に、自分の過去の経験または経験者の知識に基づいて、各アクティビティの完了までに必要な時間を見積もる必要があります。 小規模のプロジェクトなら数日で十分かもしれませんが、 複雑なプロジェクトの場合は何週間もかかる可能性があります。
ベストの推測を使用するのに抵抗がある場合は、現実的なタイムフレームに重みを置くように設計された「三点見積法」を使用するのも手です。
三点見積もりでは、過去の経験や推測に基づいて、各タスクに対して 3 つの見積もりを指定する必要があります。 時間の長さをより正確に計算するために、この見積法は数式で記述されています。
a = 楽観値
m = 最頻値
b = 悲観値
「楽観値」にはトラブルなく作業できた場合にかかる日数、「最頻値」には通常かかる日数、「悲観値」にはトラブルが発生した場合にかかる日数をそれぞれ指定します。
これら 3 つの値を特定すると、2 つの数式で使用できるようになります。 1 つ目の数式では、加重平均で見積もりを算出できます。この場合、最頻値に重みが置かれています。 数式は、下に示すとおりです。 E (Estimate) は見積もり (期待値) で、数値の 4 と 6 は、最も現実的な値に重み付けを行うための標準的な手法です。
E = (a + 4m + b) / 6
2 つ目の数式では、三角分布で見積もりを算出できます。 1 つ目の数式との大きな違いは、最頻値に重みが置かれていないことにあります。 数式は、下に示すとおりです。 E (Estimate) は見積もり (期待値) で、数値の 3 は標準的な手法です。
E = (a + m + b) / 3
ステップ 5: クリティカル パスを識別する
クリティカル パスの識別方法は 2 つあります。 1 つ目の方法は、ネットワーク図を見て、最長経路 (パス上にあるアクティビティの最長シーケンス) を判断する方法です。 箱などで表されたノードの数が最も多いパスではなく、日数にして一番長い期間になるパスを探すようにしてください。
また、往路時間計算 (フォワード パス) 分析や復路時間計算 (バックワード パス) 分析を使用して、各アクティビティの最早開始日と最早終了日、または最遅開始日と最遅終了日を求めることにより、クリティカル アクティビティを特定することも可能です。
クリティカル パスが複数あると、ネットワークにおける感度 (影響を受ける可能性) が高くなります。 プロジェクトの開始後にクリティカル パスが変更することが予想される場合、このプロジェクト スケジュールの感度は高いといえます。 プロジェクトに含まれるクリティカル パスの数が多くなればなるほど、スケジュールに変更が発生する確率も高くなります。
ステップ 6: クリティカル パス図を更新して進捗状況を反映する
プロジェクトの進行に伴って実際のアクティビティ完了時間がはっきりしてきたら、 見積もりのままにしておくのではなく、ネットワーク図を更新しましょう。
新しい情報が分かり次第ネットワーク図を更新すると、クリティカル パスを再計算できるようになります。 また、プロジェクト完了期日を現実的な観点から見れるようになり、スケジュールどおりに順調に進んでいるかどうかを判断することも可能になります。
クリティカル パス法を使用するその他のメリット
クリティカル パス法を使用する最大のメリットの 1 つは、遅れが生じるとプロジェクトの完了日に影響を与える重大なタスク、つまりクリティカル タスクを識別できることです。 また、プロジェクトのステータスが明確になるため、スケジュールどおりに進んでいるかを把握できるようにもなります。
スケジュールの短縮
クリティカル パス法を使用している際に、プロジェクトの期間をもっと短くしたり、期限を守るためにプロジェクト スケジュールを圧縮したりする必要性が生じることがあります。 スケジュールを短縮するには、「ファスト トラッキング (Fast Tracking)」または「クラッシング (Crashing)」という手法を使用できます。
ファスト トラッキング
ファスト トラッキングでは、通常なら順番に行うアクティビティを並列実行させることによって、プロジェクト全体の期間短縮を図ります。 ファスト トラッキングは、アクティビティを並行することで期間短縮が望める場合にのみ有効な方法です。
ファスト トラッキングを行うと、プロジェクトのタイムフレームを削減することはできますが、先行アクティビティが完了する前に後続アクティビティを進めることになるため、管理が難しくなったり、手戻り (前の段階に戻ってやり直すこと) のリスクがあったりします。
クラッシング
クラッシングでは、 リソース (ヒト・モノ・カネ) を追加投入することによって、プロジェクト全体の期間短縮を図ります。 クラッシングは、クリティカル パス上にあるアクティビティに対してのみ行います。コストとスケジュールのトレードオフを分析し、最小のコスト追加で最大の期間短縮を得る方法ですが、リスクやコストが増大する可能性があります。
リソース制約の管理
プロジェクトを管理していると、クリティカル パスの変更原因となるリソース制約問題が生じることがあります。 複数のアクティビティを同時にスケジュールしたことで、リソース制約、つまり特定の人的資源の利用上限を超えてしまった場合、 これらのアクティビティをスケジュールし直して、この条件を超えないようにリソース割り当てを調整する必要があります。 リソース競合問題を解決するこのプロセスは、リソース平準化/資源平準化/リソース レベリング (Resource Leveling) と呼ばれています。
拡張されたクリティカル パス法: リソース平準化とクリティカル チェーン
リソース平準化を行うと、リソース割り当てにおける競合は解決できます。 しかし、リソースを平準化したスケジュールでも、リソース ボトルネック (必要なときに必要なリソースを使えないこと) による遅延が発生することがあります。
また、リソース平準化を行ったことで、以前は短かったパスが長くなって「リソース クリティカル」なパスに変わってしまうこともあります。 この状況は、クリティカル パス上のタスクがリソース制約によって影響を受ける場合に発生します。
クリティカル パスではアクティビティの依存関係が考慮されますが、リソース制限も考慮に入れた場合のパスをクリティカル チェーン (Critical Chain) と呼んでいます (リソース競合がなければ、クリティカル チェーンはクリティカル パスになる)。リソース制約に合わせてスケジュールを調整するクリティカル チェーン法では、リソース制約が原因で発生する予期しない遅延からアクティビティとプロジェクトの期間を守るために、実作業のないアクティビティであるバッファー (余裕) を追加します。
最終的なプロジェクトの評価
プロジェクトで予期しない変更が発生した場合、クリティカル パスにも影響する可能性があることは、上記で説明しました。 変更の可能性は常にあるとはいえ、オリジナルのプロジェクト スケジュールから何が変わって、最終的なプロジェクトにどのような影響があったのかを追跡して確認することは可能です。
柔軟性と遅延評価の重要性
クリティカル パス法ではベストな推測に基づいて時間を計算するため、スケジュールは作成後に変動しがちです。 アクティビティの完了時間を 1 つ間違えただけでも、クリティカル パスのスケジュール全体が変わってしまうことはあります。 また、リソース制約が原因で、プロジェクトのアクティビティを遅らせなければならなくなる可能性もあります。
そこで、遅延を評価して原因を特定するようにすると、同様の問題が発生するのを将来防ぐことにつながります。 プロジェクトの事後計画における重要な要素として、アズ ビルト クリティカル パス (ABCP: As Built Critical Path) があります。 アズ ビルト クリティカル パスは、アクティビティが実際に行われた日が示されていて、クリティカル パス上の遅延の責任を特定することによって時間が割り当てられたスケジュールであるため、計画と実績との間に生じた差異の具体的な原因と影響を分析するのに役立ちます。
PMP 試験対策: クリティカル パス法について押さえておくべきポイント
PMP (プロジェクトマネジメント・プロフェッショナル) 資格を取得するには、PMI (プロジェクトマネジメント協会) によって実施される PMP 試験 (4 時間で 200 問の四者択一式) に合格する必要があります。
クリティカル パスについては PMP 試験でも多く出題されます。 ネットワーク図の作成、クリティカル パスの識別、往路時間計算分析と復路時間計算分析の使用、スラック/フロートの計算は必ず学習しておくようにしましょう。
PMP 試験対策としてクリティカル パス法について押さえておくべき重要ポイントは、以下のとおりです。
ネットワーク図を作成する方法
PMP 試験では通常、ネットワーク図の作成が必要となります。 質問では、サンプル プロジェクトのすべてのアクティビティと、各アクティビティを開始できるタイミングがリストアップされており、 これらの情報に基づいてクリティカル パスと期間を識別することが求められるからです。
ネットワーク図の作成方法を説明するために、Bennett 博士は、次のように 8 つのタスクから構成されるプロジェクトを例として使用しています。
- 期間が 10 日の「Design Tank Project (タンク プロジェクトをデザインする)」は、直ちに開始できます。
- 期間が 25 日の「Construct Tank Foundation (タンク基礎を構築する)」と、期間が 8 日の「Select Tank Supplier (タンク サプライヤーを選択する)」は、「Design Tank Project (タンク プロジェクトをデザインする)」が終了すると直ちに開始できます。
- 期間が 10 日の「Manufacture Tank Components (タンク部品を製造する)」は、「Select Tank Supplier (タンク サプライヤーを選択する)」が終了すると直ちに開始できます。
- 期間が 4 日の「Deliver Tank Components (タンク部品を配達する)」は、「Manufacture Tank Components (タンク部品を製造する)」が終了すると直ちに開始できます。
- 期間が 3 日の「Prepare Installation Drawings (タンク設置図を準備する)」は、「Select Tank Supplier (タンク サプライヤーを選択する)」が終了すると直ちに開始できます。
- 期間が 15 日の「Assemble Tank (タンクを組み立てる)」は、「Deliver Tank Components (タンク部品を配達する)」、「Prepare Installation Drawings (タンク設置図を準備する)」、および「Construct Tank Foundation (タンク基礎を構築する)」がすべて終了すると直ちに開始できます。
- 期間が 4 日の「Test & Commission Tank (タンクをテストして作動させる)」は、「Assemble Tank (タンクを組み立てる)」が終了すると直ちに開始できます。
- 「Test & Commission Tank (タンクをテストして作動させる)」が終了すると、プロジェクトが完了します。
それでは、クリティカル パスと期間を識別するためにネットワーク図を作成してみましょう。
方法は次のとおりです。
- 箱を描き、最初のアクティビティ「Design Tank Project (タンク プロジェクトをデザインする)」として表記します。 この箱には、アクティビティにかかる期間 (10 日) も記入します。
- 最初のアクティビティの「Design Tank Project (タンク プロジェクトをデザインする)」と、それに続くアクティビティの「Construct Tank Foundation (タンク基礎を構築する)」および「Select Tank Supplier (タンク サプライヤーを選択する)」との依存関係を示すように、図を描き始めます。 この際、後続アクティビティに対して箱を描き、アクティビティ名も表記したら、矢印で最初のアクティビティと結び付けます。各アクティビティにかかる期間も入力してください。
- 残りのアクティビティに対しても同様に箱を描き、アクティビティ名とアクティビティ期間を表記して、アクティビティ間の依存関係を矢印で示します。
ネットワーク図を描き終わったら、クリティカル パスを見つけることができるようになるはずです。 箱の数が最も多いパスではなく、日数にして一番長い期間になるパスが、クリティカル パスです。
この例では、期間が 10 日の「Design Tank Project (タンク プロジェクトをデザインする)」→期間が 25 日の「Construct Tank Foundation (タンク基礎を構築する)」→期間が 15 日の「Assemble Tank (タンクを組み立てる)」→期間が 4 日の「Test & Commission Tank (タンクをテストして作動させる)」の合計期間が 54 日で最長経路であり、これがクリティカル パスになります。
クリティカル パスを識別するには、ネットワーク図を見て最長経路を判断する方法以外に、往路時間計算分析や復路時間計算分析を使用する方法もあります。これについては、次のセクションで紹介します。
往路時間計算分析と復路時間計算分析を使用する方法
往路時間計算 (フォワード パス) 分析と復路時間計算 (バックワード パス) 分析は、クリティカル パスを見つけるもう 1 つの方法です。 この方法は、アクティビティに対して複数の分岐 (エントリ ポイント) がある場合に最適です。
アクティビティの最早開始日と最早終了日、または最遅開始日と最遅終了日を識別する必要がある場合にも、往路時間計算分析や復路時間計算分析を使用します。 また、各アクティビティのスラック/フロートを計算する場合にも、往路時間計算分析や復路時間計算分析を使用できます。
往路時間計算分析や復路時間計算分析を使用し始める前に、以下の用語を理解しておきましょう。
- 最早開始日 (ES: Earliest Start Time): (依存関係にある先行アクティビティが完了した後で) 最も早くアクティビティを開始できる日。
- 最早終了日 (EF: Earliest Finish Time): アクティビティの最早開始日に、アクティビティの完了に必要な時間を加えた日。
- 最遅終了日 (LF: Latest Finish Time): プロジェクト全体を遅らせることなくアクティビティを完了できる最も遅い日。
- 最遅開始日 (LS: Latest Start Time): 最遅終了日から、アクティビティの完了に必要な時間を引いた日付。
ネットワーク図で往路時間計算分析や復路時間計算分析を行う場合は、次の凡例に従って各値を算出してください (SL は Slack、つまり「スラック」の略で、後ほど詳しく説明します)。
往路時間計算分析: 最早開始日と最早終了日を求める方法
往路時間計算分析と復路時間計算分析には、 異なる数式が 1 つずつあります。 往路時間計算 (フォワード パス) 分析では、ネットワーク図で開始から終了 (最初のアクティビティから最後のアクティビティ) に向かって分析することで、各アクティビティの最早開始日 (ES) と最早終了日 (EF) を判断します。
往路時間計算分析を開始するには、最初のタスクの ES をゼロにします。 残りのすべてのタスクでは、ES は先行タスクの EF と同じになります。
EF を計算するには、次の数式を使用してください。
EF = ES + 期間
Bennett 博士の例を使用すると、最初のタスクである「Design Tank Project (タンク プロジェクトをデザインする)」の ES は 0、期間は 10 日であるため、EF は「0 + 10 = 10」になります。 すると、2 つ目のタスクである「Select Tank Supplier (タンク サプライヤーを選択する)」の ES は 10、期間は 8 日であるため、EF は「10 + 8 = 18」になります。 このようにして、ネットワーク図で各タスクの EF を計算していきます。
復路時間計算分析: 最遅開始日と最遅終了日を求める方法
復路時間計算 (バックワード パス) 分析では、ネットワーク図で終了から開始 (最後のアクティビティから最初のアクティビティ) に向かって分析することで、 各アクティビティの最遅開始日 (LS) と最遅終了日 (LF) を判断します。
往路時間計算分析を開始するには、最後のアクティビティの LF を EF と同じにします。 残りのすべてのタスクでは、LF は先行タスクの LS と同じになります。
LS を計算するには、次の数式を使用してください。
LS = LF - 期間
ここでも Bennett 博士の例を使用します。最後のタスクである「Test & Commission Tank (タンクをテストして作動させる)」の LF は 54、期間は 4 日であるため、LS は「54 - 4 = 50」になります。 すると、その前のタスクである「Assemble Tank (タンクを組み立てる)」の LF は 50、期間は 15 日であるため、LS は「50 - 15 = 35」になります。 このようにして、ネットワーク図で各タスクの LS を計算していきます。
最初のアクティビティ (Bennett 博士の例では「Design Tank Project (タンク プロジェクトをデザインする)」) の LS が 0 であれば、復路時間計算分析が正しいことになります。
これで、往路時間計算分析と復路時間計算分析の完了です。
往路時間計算分析と復路時間計算分析で覚えておきたい 2 つのルール
往路時間計算分析では、複数のアクティビティが合流している (1 つのアクティビティに流れ込む複数のアクティビティがある) 場合、各エントリ ポイントに対して指定の数式を実行し、それらの結果の中から最大値を使用する必要があります。
また、復路時間計算分析で複数のアクティビティが合流している場合は、各エントリ ポイントに対して指定の数式を実行した後、それらの結果の中から最小値を使用する必要があります。
PMP 試験でスラック/フロートを計算する方法
各アクティビティの ES と LS を識別したら、スラック/フロートを計算することができます。
アクティビティのスラック (SL)、つまりフロート (余裕時間) とは、最早開始日または最早終了日を過ぎてからプロジェクト全体の期間に影響することなくアクティビティを遅らせることができる時間の合計で、最早開始日と最遅開始日の間、または最早終了日と最遅終了日の間の時間を計算することで特定できます。 クリティカル アクティビティ (クリティカル パス上のアクティビティ) にはスラックがありません。
往路時間計算分析と復路時間計算分析を使用して識別した値に基づいてスラックを計算する 2 つの数式は、以下のとおりです。
スラック = LF - EF
スラック = LS - ES
PMP 試験でアクティビティのスラックを求める問題が出題されたら、このプロセスを使用してください。 また、クリティカル パス上にあるアクティビティが分からない場合でも、スラックがゼロであるということを覚えておけば、上記の数式に基づいて各アクティビティのスラックを計算すれば良いのです。
Bennett 博士の例を使用して各タスクのスラックを計算すると、 4 つのクリティカル パス タスクである「Design Tank Project (タンク プロジェクトをデザインする)」、「Construct Tank Foundation (タンク基礎を構築する)」、「Assemble Tank (タンクを組み立てる)」、および「Test & Commission Tank (タンクをテストして作動させる)」ではスラックがゼロになります。
PMP 試験に役立つクリティカル パス用語集
PMP 試験を受験するにあたり、クリティカル パス法について覚えておくべき重要用語は、以下のとおりです。
- クリティカル パス法 (CPM): プロセス プランニングのためにクリティカルなタスク (遅延が許されないタスク) とノンクリティカルなタスク (遅延が許されるタスク) を識別する段階的なプロジェクト管理手法で、タイムフレーム (時間枠) に関する問題やプロセス上のボトルネックを取り除くことができます。
- クリティカル パス DRAG (Devaux’s Removed Activity Gauge): クリティカル パス上の特定のアクティビティによってプロジェクトの期間に追加される時間の合計。 または、アクティビティをクリティカル パスから外れない程度または期間がゼロにならない範囲内で短縮できる最大時間。
- クリティカリティ インデックス (重大度指標): 主にリスク分析に使用され、分析中に特定のタスクがクリティカル パス上にあった頻度が示されます。 クリティカリティ インデックス値が高いタスクは、クリティカル パス上に乗る可能性が高いため、このタスクに遅れが生じた場合はプロジェクトの終了日にも影響を与える可能性が高くなります。
- 最早開始日 (ES): (依存関係にある先行アクティビティが完了した後で) 最も早くアクティビティを開始できる日。
- 最早終了日 (EF): アクティビティの最早開始日に、アクティビティの完了に必要な時間を加えた日。
- 最遅終了日 (LF): プロジェクト全体を遅らせることなくアクティビティを完了できる最も遅い日。
- 最遅開始日 (LS): 最遅終了日から、アクティビティの完了に必要な時間を引いた日付。
- トータル フロート: (最早開始日を過ぎてから) プロジェクト全体を遅らせることなくアクティビティを遅らせることができる時間の合計。
- フリー フロート: 後続アクティビティの最早開始日を遅らせることなく、特定のアクティビティを遅らせることができる時間の合計。
- 往路時間計算 (フォワード パス): クリティカル パス法にて、アクティビティの最早開始日と最早終了日を判断するプロセス。
- 復路時間計算 (バックワード パス): クリティカル パス法にて、アクティビティの最遅開始日と最遅終了日を判断するプロセス。
- ネットワーク図: プロジェクトのアクティビティ間の依存関係を示した図で、プロジェクトのアクティビティの順番は左から右へと描かれます。
- ネットワーク分析: 複雑なプロジェクトを複数のコンポーネント (アクティビティや期間など) に分割して相互依存性と相互関係を示すプロセス。
クリティカル パスを見つける最も簡単な方法
シンプルなタスク管理やプロジェクト プランニングから、複雑なリソース計画やポートフォリオ マネジメントまで、Smartsheet は共同作業の改善と作業速度の向上に役立ち、より多くの成果を上げるのに効果的です。 Smartsheet プラットフォームなら、いつでもどこでも簡単に作業の計画、保存、管理、およびレポート作成が可能なため、チームはより効率的かつ効果的に仕事を進めることができるようになります。作業に関して主要なメトリックを表示したり、リアルタイムの可視性を提供したりするために、ロールアップ レポート、ダッシュボード、および自動化されたワークフローを作成する機能も装備されており、チーム メンバーをつないで情報共有を促進することが可能です。 やるべきことを明確にすると、チームの生産性と作業達成能力が向上します。ぜひこの機会に Smartsheet を無料でお試しください。