クリティカルパスを用いたタイムマネジメント
2020/02/27
プロジェクトマネージメント
プロジェクトマネージャーが管理しなければならないことは数多くあります。マネジメント知識の国際標準とされている PMBOK (Project Management Body of Knowledge) によれば、以下に示す10のマネジメント領域があり、マネージャーはこれらを的確に管理すべきである、とされています。
・統合マネジメント
・スコープマネジメント
・タイムマネジメント
・コストマネジメント
・品質マネジメント
・人的資源マネジメント
・コミュニケーションマネジメント
・リスクマネジメント
・調達マネジメント
・ステークホルダーマネジメント
今回はこれらマネジメント領域のうち、タイムマネジメントに用いられる一手法、クリティカルパス法についてご紹介します。
クリティカルパス法とは
プロジェクトの工数を見積もったり、プロジェクトの進捗管理においてどの工程がボトルネックとなるのか調べたりする際に、クリティカルパス法という手法が用いられることがあります。古くからシステム工学によって研究されている手法ですが、現在でも工場の生産ラインにおける工程管理や、ITシステムの開発における工程管理、製品開発の工程管理など、様々な分野で用いられています。
一般に、プロジェクトの内部では複数のタスクが同時に進行します。このときタスクの間には、前のタスクが終わらないと次のタスクを進めることができない、あるいは同時並行で進めることができない、といった依存関係があります。これらの依存関係を整理すると、全体の工期を決定づけている「タスクの経路」を割り出すことができます。この重要な経路のことを指してクリティカルパスと呼び、クリティカルパスを利用して工程管理や工期の短縮を図る手法をクリティカルパス法と呼びます。
なお、クリティカルパス法の実施に先立って、WBS(Work Breakdown Structure) などでプロジェクトにおけるタスクを細分化する必要があります。プロジェクトの計画にあたってガントチャートを作成する場合にはタスクを細分化するでしょうから、クリティカルパス法を実施する際のタスクはそれを流用すれば問題ありません。
クリティカルパスの求め方
ここからはクリティカルパス法を用いたプロジェクト管理について、例を用いてご紹介していきます。なお、今回の例では仕組みを根本から理解するためにネットワーク図の作成や計算を手作業で行っていきますが、今日ではガントチャートなどからクリティカルパスを発見してくれるソフトウェアも存在します。
以下に、新商品開発のプロジェクトを想定し、各工程の依存関係をネットワーク化したものを示します。
各ボックスのカッコ内に書かれた日数は、そのタスクを完了するために必要な日数を示しています。ボックス間を繋ぐ矢印は、そのタスクが完了した後に移行する次のタスクを示しています。
それぞれのタスクに必要な日数を見積もる手法は様々ですが、最も楽観的な日数、最も現実的な日数、最も悲観的な日数を算定し、加算平均や加重平均によって見積もることが一般的です。加算平均では楽観的な日数、現実的な日数、悲観的な日数をそれぞれ等しく扱い、加重平均では現実的な日数に適度な重みを与えて扱います。
例えば「商品コンセプト」のタスクにおける工期を見積もる際、最も楽観的な日数を30日、最も現実的な日数を40日、最も悲観的な日数を65日と算定したとしましょう。これらを加算平均すると、図中にある通り45日となります。加重平均の場合にはどの日数にどの程度の重みを付けるか、という課題がありますが、一般的にはPERT期待値と呼ばれる、現実的な日数に重みを付けた平均値を用いることが多いようです。PERT期待値は以下のように求められます。
PERT期待値 = (楽観的な日数 + 4 * 現実的な日数 + 悲観的な日数) / 6
標準偏差 = (悲観的な日数 – 楽観的な日数) / 6
したがって、PERT期待値に基づく「商品コンセプト」のタスクにおける工期は42.5±5.8日となります。
今回は簡単にするため、全てのタスクを加算平均に基づいて算出したものとします。
さて、クリティカルパスを特定する際には、最終タスクから逆算して日数が最も長くなる経路を辿っていくことになります。このプロジェクトにおけるクリティカルパスは、下図のようになります。
クリティカルパス上にある工程の日数を合算すると108日となり、これが新商品開発プロジェクトの全体工期ということになります。クリティカルパス上に存在するタスクは遅れることができません。なお、今回の図ではクリティカルパスが一本のみとなっていますが、クリティカルパスは必ずしも一本に収束するとは限りません。短い工期にタスクを詰め込むと、往々にしてクリティカルパスが数本になることもあります。この場合、複数のクリティカルパス上に存在するタスクのどれか一つでも遅れた場合、全体の工期が延長されることになります。
フロートとクリティカルパスの移動
クリティカルパス上に存在しないタスクには、日程的に余裕がある、ということになります。この余裕をフロート（浮き時間）と呼びます。フロートを調べるためには、先ほどの図にもう少し計算を加える必要があります。
まず、最初のタスクから順番に工程をたどることで、各タスクに最も早く取りかかれる日数（最早開始日）と、各タスクが最も早く終了できる日数を（最早終了日）を求めることができます。最早開始日には、前方に存在するタスクのうち最も遅い日数を割り当てます。最早終了日は、最早開始日に対してタスク自身の工期を足した日数になります。
先ほどの図から、各タスクの最早開始日と最早終了日を算出した結果が以下の通りとなります。下図のうち、左上の日数が「最早開始日」であり、右上の日数が「最早終了日」となります。
ぱっと見ただけでも各タスクにおけるフロートが見えてきます。例えば「機械構造設計」というタスクは、クリティカルパスにある「電気回路設計」と最早開始日が同じですが、最早終了日は5日ほど早いため、5日だけフロートがある、と読み取れます。
さて、最早開始日と最早終了日を算出できたら、今度は最後のタスクから逆順に工程をたどることで、各タスクが最も遅く終了する日数（最遅終了日）と、各タスクに最も遅く取りかかることになる日数（最遅開始日）を求めることができます。最遅終了日には、後方に存在するタスクのうち、最も早い「最遅開始日」を割り当てます。最遅開始日は、タスクの最遅終了日からタスク自身の工期を引いた日数になります。
先ほどの最早開始日と最早終了日を算出した結果から、最遅終了日と最遅開始日を求めた結果が以下の通りとなります。図中では左下の日数が「最遅開始日」であり、右下の日数が「最遅終了日」となります。
それぞれのタスクにおけるフロートは「最遅開始日」から「最早開始日」を引いた日数によって求めることができます。図中では左上の日数が最遅開始日、左下の日数が最早開始日となり、F=○○と表記している部分がフロートとなります。
以上の作業によって、全体の工程におけるフロートを把握することができます。クリティカルパス上に存在するタスクにはフロートがありません。フロートは、あるタスクにおける作業の猶予である、と見なすことができます。一方で、そのタスクがフロートを使い切ってしまうとクリティカルパスが該当のタスクへ移る、ということでもあります。
また、フロートを持つタスク同士が依存関係にある場合は、前の工程でフロートを使ってしまうと後の工程においてフロートが少なくなってしまう、ということにも注意しましょう。
例えば、図中における「市場調査」のタスクと「製品デザイン」のタスクはそれぞれフロートを持っていますが、「市場調査」のタスクが35日のフロートを全て使い切ってしまうと、「製品デザイン」のタスク開始日は75日目となり、「製品デザイン」におけるフロートがゼロとなってしまいます。
あるタスクが後続のタスクにおけるフロートへ影響を及ぼさない時間をフリーフロートと呼びます。フリーフロートの算出方法は、後続のタスクにおける最早開始日（各タスクの左上の日数）から、該当タスクの最早終了日（各タスクの右上の日数）を引いた日数となります。したがって、図中の「市場調査」のタスクが持っているフリーフロートは5日であり、それを過ぎた場合には「製品デザイン」が持っているフロートが縮まっていきます。
他にも、「技術調査」のタスクはフロートを15日持っていますが、後続のタスクである「材料調達計画」に着目すると、実際にはフリーフロートが0日であり、「技術調査」のタスクが遅れた分、「材料調達計画」のフロートが最大で15日減ることになります。このプロジェクトにおける「材料調達計画」のタスクはフロートを最大で45日持っていますが、「技術調査」にフロートを取られることを考慮して最大の安全を取るなら、30日のフロートを持つものと考えた方が良いでしょう。
以上のように、クリティカルパスを求め、フロートを算出することで、厳密に管理しなければならないタスクと、余裕を持って対応できるタスクを具体的に見出すことができます。また、様々なタスクの依存関係を視覚的に把握することができ、あるタスクの進捗が他のタスクへどれくらい影響を及ぼすか定量的に算出することができます。
なお、一旦クリティカルパスを見出したのちも、ネットワーク図はプロジェクトの進捗に合わせて随時更新する必要があります。仮にクリティカルパス上に存在するタスクが幸運にも想定より早く進んだ場合、他のタスクを通る経路へクリティカルパスが移る可能性があります。その際にネットワーク図が更新されていないと、管理すべき重要なタスクを見失ってしまうことになります。
クリティカルパス法を用いた工期管理や効率改善
先述したように、プロジェクトの工期はクリティカルパス上に存在するタスクの工期によって決定されます。大規模なプロジェクトになるとマネージャーが全てのタスクを管理することは困難になりますが、クリティカルパス法を用いることで優先的に管理すべきタスクを見出すことができます。
また、工期の短縮を狙う場合には、クリティカルパス上に存在するタスクへ対して効率的な業務改善や日程短縮の手法を検討すればいいことになります。逆に言うならば、フロートを持つタスクを短縮しても、全体の工期は全く縮まらず、効果を上げることができません。
タスクの具体的な短縮方法としては、リソースを投入することで工期の短縮を図る、本来は直列化しているタスクをあえて並列化して実行する、といった手法が挙げられます。
リソースの投入はシンプルですが、コストが増大します。また、工期短縮に失敗した場合はコストのみが費やされる結果となる、というリスクも生じます。
タスクの並列化は後に発生するタスクを事前に進めておくことになるため、管理が複雑になったり、前に発生しているタスクの結果次第ではやり直し（手戻り）が発生したりする、というリスクが伴います。
フロートを持つタスクにも注目しましょう。フロートを持っているタスクは後回しにすることができるため、他のタスクやプロジェクトへリソースを割り振ることができます。
一方で、あるタスクがフロートを使い切ってしまうと、クリティカルパスはそのタスクを通る経路に変更されます。また、フリーフロートを使い切ったタスクは、それだけ後続のタスクにおけるフロートを使ってしまうため、気づけば作業の余裕が無くなっていた、という事態になりかねません。したがって、ネットワーク図を進捗状況に合わせて随時更新し、プロジェクトの全体像を把握することが重要となります。
クリティカルパスを現場で活用するために
今回の例ではネットワーク図を手書きし、計算を手作業で行いました。クリティカルパス法は、覚えてしまえばそれほど難しい計算ではありません。ですが、多忙な現場ではネットワーク図を描く時間も惜しく、またネットワーク図の更新に伴って全ての数値が変動するため、導入に対して及び腰になる方もいらっしゃることでしょう。
幸い、今日ではガントチャートなどからクリティカルパスを発見してくれるソフトウェアが多く存在します。いったんタスクを細分化し、依存関係を適切に設定すればクリティカルパスを発見し、各タスクにおけるフロートも自動的に算出してくれます。また、実際の進捗状況を入力することで自動的に更新してくれます。
プロジェクト管理用のソフトウェアを導入する際は、どのような機能を持っているか、その機能がご自身の携わるプロジェクトに必要かどうか、よく検討することが望ましいでしょう。
