プロジェクトマネジメントにおいて、参加メンバー全員でプロジェクトの規模や進捗などを確認するためには「ガントチャート」の活用が必須です。
この「ガントチャート」の作成には、下記のステップを踏む必要があります。
今回は、おそらく多くの人が省略してしまっている「CPM：クリティカルパスメソッド」について説明します。
クリティカルパスの把握がプロジェクトの成否を決める
「WBS：work breakdown structure」を問題なく抽出できていれば、ガントチャートの作成自体は実施可能です。ただ、実際に作業を行う上では下記の2つを行う必要があります。
- タスク全体の流れを把握する
- タスク同士の相関関係を確認する
プロジェクト進行中には、特定のタスクが終了しないと次のタスクを実行できないケースもあります。全体の流れやタスク同士の関連性を、「ネットワーク図」によって確認した上で「クリティカルパス・メソッド」によって重要なタスクの流れを把握する必要があります。
厳密なCPMを行わないまでも「ネットワーク図／クリティカルパス」の把握は重要です。多くの人がないがしろにしがちな、この2つの工程について説明していきます。
作業のつながりと長さを示す「CPM（クリティカルパスメソッド）」
「WBS（ワークブレイクダウンストラクチャー）」の後に実施することは「ネットワーク図」の作成と「CPM」です。
「ネットワーク図」はタスク同士のつながりを可視化するためにも、必ず使い方を習得しなければなりません。
それに対し「CPM＝クリティカルパス・メソッド」は、ガントチャートを作成・活用する上では必ずしも必要ではありません。
ただ、タスク間の関係性を明確にしたり「プロジェクトの時間短縮」の考察には必須です。
以上のようなことを、プロジェクト実行前に調査する際に効果を発揮しますので、できれば活用してほしい分析手法です。現在では、ガントチャート作成ソフト内で「ネットワーク図」はもちろん、「クリティカルパス」も自動的に計算してくれるものがあります。
ここでは「ネットワーク図」や「CPM」の意味や具体的な作り方をしっかり学んで、実務レベルではツールを活用していきましょう。
注意「クリティカルパス」の算出には「PERT」と呼ばれる手法もありますが、本レポートでは、ガントチャートへの適用がしやすい「AON（Active on Node）」方式のネットワーク図を使用して説明します。
「CPM＝クリティカルパス・メソッド」とは？
クリティカルパスメソッド（以下「CPM」）は、抽出したタスクの「期間」や「つながり」に基づいて、プロジェクト全体の所要期間を算出する方法です。このCPMを行うことによって、プロジェクトの遅れを防ぐために「絶対に遅れられないタスクはどれか？」を特定することができます。
CPMの中の「クリティカルパス」とは、プロジェクトが完了するまでのタスクのつながりが最も長い期間を要する工程を指します。決して「最も早く終了するパス」ではありませんので注意してください。
クリティカルパスは、以下の図では「赤い太線」が該当します。
プロジェクトによっては、必ずしも全てのタスクが繋がっているとは限らないため、クリティカルパスが複数発生するケースもあります。
また、クリティカルパス上にある重要なタスクのことを「クリティカル・タスク」と呼ぶ場合もあります。
「CPM」を実施するために必須の「ネットワーク図」
クリティカルパスを見つけるために、必ず構築しなければならないものがあります。それが「ネットワーク図」です。「ネットワーク図」とは、「WBS」で抽出したタスクの中で最も小さなタスクである「ワークパッケージ」を、目標を達成するまでのルートに並べる方法です。
ネットワーク図の作成にはさまざまな手法がありますが、最もベーシックな方法がタスク同士の前後関係を「作業手順シート」にまとめる方法です。
例として、「サイト作成」というプロジェクトの中で実施するタスクを使用してみましょう。
「100：記事作成」「200：記事投稿」「300：アクセス解析導入」といったタスクに着目した場合、ワークパッケージは以下のように設定します。
「直前先行作業」とは、その名の通り、そのタスクが行われる前に終了されるべきタスクのことを指します。それぞれのタスクNo.の「直前先行作業」を元に、ネットワーク図に起こしたものが以下になります。
「タスク110」「タスク310」のタスクは同時に開始しても問題がないもので、「210」などの記事投稿のタスクに関しては、記事が無いと投稿ができないため「後続タスク」となっています。
ネットワーク図を作成する際には、「そのルートでタスクを消化していけば目標は達成されるのか？」ということを、しっかり考えるようにしましょう。
ルートの作成も慣れが必要なことですので、反復を行うことが重要です。
【プロマネ必読】クリティカルパスの算出方法
複雑に感じるクリティカルパスの算出法ですが、簡易的な方法としっかりと算出する2つの方法があります。
単純手法編：「タスク時間の積算」
一見複雑な「CPM」ですが、簡単に設定する方法があります。それは、「タスク時間の積算」という方法です。
作成したネットワーク図の流れに沿ってタスク時間を積算し、最も時間が掛かるルートが「クリティカルパス」のルートになるという考え方です。方法は非常に簡単で、作成した「ネットワーク図」に所要時間を記入して、ゴールに至るまでのルートの所要時間を積算するだけです。
前述の「サイト作成」の例からクリティカルパスを計算してみましょう。「作業手順シート」の数値（期間値）をネットワーク図に記載してみました。
この赤字の部分を積算すると、「サイト作成」というプロジェクトのクリティカルパスが算出できます。
この場合「1＋3＋1＋1＋2＋1＋1＝10」がクリティカルパスの期間になります。
最も簡単な方法ですが、これをやるだけでもプロジェクト全体の時間感覚は掴めます。
詳細手法編 ：「往路時間計算と復路時間計算」
正式なクリティカルパスの算出には「往路時間計算（フォワードパス）」と「復路時間計算（バックワードパス）」という手法を用います。
前述の単純なクリティカルパス算出だけでは判断できない、以下のような点を明確にすることができます。
初めて計算を実施する人には難しく見える算出方法ですが、一度計算に慣れてしまえば算出自体は非常に簡単です。
「CPM」を作成するために必須のキーワード
「往路時間計算」と「復路時間計算」を実行するためには、必ず知っておくべき「キーワード」があります。これらの言葉の意味を理解し、クリティカルパスを算出しましょう。
「最早開始（ES：Early Start）」
言葉の通り、タスクを開始するための最も早い期間を意味します。つまり、そのタスクを開始するのに最速でいつ着手できるかということを指します。
「最早開始」で作業を開始すれば、タスクの作業時間に余裕時間（フロートタイム）が生まれ、プロジェクトの遅延といった問題に直面した際に修正が可能になります。
当然ですが、タスクは「最早開始」の期間で始めるべきであり、最も早く着手することで「自由時間（フロートタイム）＝最遅終了ー最早終了」を増やすことができます。
もしもプロジェクトの途中に遅れが発生したとしても、余裕分の時間を割り当てることで挽回が可能となるのです。プロジェクトの最初の作業の場合は「最早開始＝0」となります。
「最早終了（EF：Early Finish）」
最も早くタスクが終了する期間のことを意味します。
タスクを達成するための所要時間を「T」とすると、最早終了は、最早開始にタスク時間を加えた「EF=ES+T」となります。
「最遅終了（LF：Late Finish）」
プロジェクトを遅らせないために許容できる、最も遅いタスクの終了期間を表しています。
つまり、プロジェクトを進行させる場合には、どんなに作業が遅れても「最遅終了」期間内に該当のタスクを終わらせなければならないのです。
「最遅開始（LS：Late Start）」
プロジェクトを遅らせないために許容できる、最も遅いタスクの開始期間を指します。
つまり、遅くとも「最遅開始」時期には作業を開始しないと、プロジェクトに遅れを生じさせてしまいます。
「フロート（スラック）」
複数のパスを有したタスクがある場合、タスクが終了した後に、他のタスクの終了を待つという「自由時間（フロートタイム）」が生じるケースがあります。
例えば、2人で部屋の掃除をしているとしましょう。台所と部屋の清掃を別々に実行した後に一緒にゴミを捨てに行くとすれば、部屋の掃除が先に終わった人は、台所の清掃が終わるまで待たなければいけません。
この場合、部屋の掃除をしていた人は、台所掃除が終わるのを待つという「フロートタイム」ができるわけです。
「フロートタイム」は「余裕時間」に当たりますので、他のタスクが遅れている際に「フロートタイム」があるタスクで余裕ができた人員を、クリティカルパスのタスクに回すといった調整を行うこともできます。
ノード
実際に「往路・復路時間計算」を行う時には、ネットワーク図のタスク項目を、以下のような「ノード」に記入し、それぞれの期間を算出していきます。
「往路・復路時間分析」の実施例
それでは「往路・復路時間計算」によるクリティカルパスの算出例として、以下のような作業工程を持つプロジェクトを利用してみましょう。
この「作業手順シート」を元に作成した「ネットワーク図」は、以下のようになります。
往路時間計算（フォワードパス）
「往路時間計算」では、「プロジェクトの開始」から計算を実施し、「最早開始（ES）」「最早終了（EF）」を算出します。
タスク110,310
「タスク110」「タスク310」は先行作業がないので、どちらも「ES＝０」となります。EFは「ES＋所用期間」なので、以下のようになります。
- EF@110＝0＋3
- EF@310＝0＋3
タスク120,220
「タスク120」「タスク220」はどちらも先行作業が「タスク110」なので、2つとも「ES＝３」となります。
- EF@120＝3＋2＝5
- EF@220＝3＋1＝4
タスク140
同様に計算を進めていくのですが、注意すべきなのは「タスク140」です。「タスク140」の前には、EFが異なる2つのタスク「タスク130」「タスク230」があります。こういった場合は、最も時間のかかるタスクの数値を適用するため、「タスク130」の「EF@130＝9」を「タスク140」のESに適用します。
そして、終了直前タスクの中でEFで最も高いものが、このプロジェクトでの「総所用時間」となります。このケースの場合は、終了直前にある3つのタスクが該当します。
- EF@210＝8
- EF@140＝11
- EF@310＝2
この中で最も大きい「EF@140＝11」が総所用期間となります。
復路時間計算（バックワードパス）
「往路計算」の後には、「復路時間計算」によって最遅開始（LS）,最遅終了（LF）を求めることになります。
「復路計算」を行う際には“終了”から遡って計算を行うことになります。
タスク140,210,310
終了直前のタスクである「タスク210」「タスク140」「タスク310」のLFには、「総所用期間」である”11″を入力します。
さらに、それぞれのタスクの「LS＝最遅終了ー期間」を求めます。
- LS@210＝11−3＝8
- LS@140＝11−3＝9
- LS@310＝11−2＝9
タスク130,230
「タスク130」「タスク230」は、どちらも「タスク140」の直前タスクとなっているため、「タスク140」の最早終了である”期間９”を、最遅終了の欄に入れます。
タスク110,120
「復路計算」で、複数のタスクが１つのタスクに遡る場合には、「LSが小さい方の数値」を入力するようにしてください。
今回のケースでは「タスク110」「タスク120」が複数タスクからの遡りに該当します。
フロート（余裕時間）の算出
「フロート（余裕時間）」は、「往路時間計算」で求めた最早終了（EF）と、「復路時間計算」で求めた最遅終了（LF）との差で算出します。
つまり、タスクが「最も遅く終わるタイミング」と「最も早く終わるタイミング」の差を求めることで、そのタスクが最大限持っている”余裕時間”を算出することになります。そして、先の図を見てわかるように「フロート＝０」、つまり“余裕時間がまったくない”ようなタスクの流れが見えてきます。
これが「クリティカルパス」になるわけです。今回の例で言うと「110→120→130→140」が、プロジェクトのクリティカルパスとなります。
「クリティカルパス」上にあるタスクの遅れはそのままプロジェクトの終了の遅れにつながるので、節目でこれらのタスクの進捗をしっかり管理する必要があるのです。
逆に「フロート」があるタスクは、フロートの数値分だけ余裕があるわけですので、ゆとりを持った作業ができることになります。
余裕時間の詳細解釈：「トータルフロート」と「フリーフロート」
「余裕時間（フロート）」に対する考え方で非常に重要なのが、「トータルフロート」と「フリーフロート」の考え方です。
トータルフロート
「プロジェクトの終了日」を遅らせることなく、最早開始を超えてタスクを遅らせることができる最大値。
トータルフロート＝「開始-終了」のパスのフロートの合計値
フリーフロート
「直後の後続作業」の最早開始を遅らせることなく、タスクを遅らせることができる期間。
フリーフロート＝該当タスクのEFー直後の複数タスクのESの最小値
これらのフロートについての絶対に守らなければならないルールは、どちらも算出された期間以下しか時間延長はできないということです。
例題のネットワーク図には4つのルートがあります。
- 【ルート1】 開始→110→120→210→終了
- 【ルート2】 開始→110→120→130→140→終了
- 【ルート3】 開始→110→220→230→140→終了
- 【ルート4】 開始→310→終了
それぞれのルートでのフロートは以下のようになります。
トータルフロートに着目してみると、【ルート1】のパスラインは、クリティカルパスの次に短い「3」となっています。
この余裕期間を超えてしまうと、今度は【ルート1】がクリティカルパスへと変わってしまい、クリティカルパスの次に遅延発生に注意が必要なパスラインとなります。このようなパスのことを「準クリティカルパス」と呼んでいます。
また、【ルート3】は、トータルフロートは「4」ですが、フリーフロートに着目すると「タスク220＝2」「タスク230＝2」となっています。
トータルとしては4期間の余裕があるのですが、タスクに着目すると2期間ずつしかありません。実質的に短縮できる余裕は2以下しかないため、各タスクのフロートの数値に注意する必要があります。
【ルート4】は、「トータルフロート＝フリーフロート」となっており、どちらも「9」の余裕があります。したがって、最も余裕のあるルートとなります。他のルートが遅れている場合には、タスクの開始日や終了日を遅らせたり、一旦中断するといった対応を取ることが可能になります。
この「フロートの考え方」は、進捗管理の際にも役立つ重要な考え方です。クリティカルパスはもちろん、各パスラインのフロートの把握も行い、表にまとめるか算出に使用したネットワーク図をいつでも確認できるようにしておきましょう。
まとめ：クルティカルパスの書き方
クリティカルパスを書く事は難しそうに見えますが、実際にフロート計算をしてみると算出自体は比較的容易です。
それよりも、クリティカルパスに重要なタスクの繋がり（相関関係）の明確化や、そのタスクの見積もり時間などが重要となってきます。とにかくWBSとネットワーク図に神経を使ってください。
プロジェクト管理も、こういったタスクの繋がりが可視化できてクリティカルパスが分かると、いざ進行中にトラブルが発生した場合にも対処しやすくなります。
多人数で仕事をしていると、明確な理由がないと動いてくれない人もいます。そういった人たちを納得させる意味でも、煩わしいかもしれませんが「クリティカルパスメソッド（CPM）」を利用してみましょう。
