クリティカルパスとは?最長の経路が最短の期間を決める理由——フロートの読み方と9作業の計算例

「クリティカルパスは最も長い経路のことだと書いてあるが、なぜ最も長い経路がプロジェクトの最短期間になるのか」——工程表を渡された方から、こうした問いをよく受けます。40行の作業表を前にして、どの行を見ていればいいのか分からない。定例では毎回「順調です」と言われる。それでも納期に間に合うかどうかは、自分では判断できない。用語の説明は読んだのに、目の前の表に当てはめられないという状態です。

結論から言うと、クリティカルパスとは、工程表の中で最も長く連続する作業の並びのことで、その長さがそのままプロジェクトの最短期間になります。作業は先行・後続の依存関係でつながっていて、複数の経路が合流する地点では遅いほうが揃うまで先へ進めません。だから全体の期間は「作業時間の合計」でも「一番重い作業」でもなく、「最も長い経路の長さ」で決まります。この経路の上にある作業は1日遅れれば納期が1日動き、外れている作業には遅らせても納期に響かない余裕(フロート)があります。

この読み方が身につくと、工程表の見方が変わります。40行を全部監視するのをやめて、納期を決めている数行と、その余裕の残量だけを見る。遅れの報告を受けた瞬間に「これは納期に効く」「これはあと3日は待てる」と判別できる。遅れてから騒ぐのではなく、余裕が減っていく速度で先に気づけるようになります。

本記事では、クリティカルパスの定義と依存関係の4種類、フロート(トータルフロートとフリーフロート)と最早開始・最遅開始の考え方、9作業の小さな工程表で全部の数字を出す計算例、クリティカルパスが動く瞬間と短縮する2つの手段(ファストトラッキングとクラッシング)、そして発注者が見積もり工程表のどこを見るかの順に解説します。定義は米国会計検査院(GAO)、NASA、IPAの公開資料で確認し、計算例は自分で検算した数値だけを載せています。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。納期がずれた案件をさかのぼると、開発側の実装が遅れたケースより、発注側の仕様確定・素材提供・検収が遅れたケースのほうが多いのが実情です。この記事を読み終えるころには、自社の工程表のどの行が納期を決めていて、そこに自社の作業が何日分乗っているかを確かめられるようになります。

クリティカルパスとは——工程表で最も長い経路が、プロジェクトの最短期間を決める

クリティカルパスは、日本語では「臨界経路」と訳されることもありますが、実務では英語のまま使われます。最初に押さえるべきなのは、これが「重要なタスクの一覧」ではなく「つながった一本の道」だという点です。作業を点として並べたものではなく、先行から後続へと連なる経路であり、その長さが数字として意味を持ちます。

定義——「最も長く連続する作業の並び」。公的機関の資料はどう書いているか

米国会計検査院(GAO)がスケジュール評価の基準としてまとめた「Schedule Assessment Guide」(GAO-16-89G、2015年12月)の用語集は、クリティカルパスを「スケジュール上で最も長く連続する一連の作業。プログラムの最早完了日、すなわち最短の所要期間を定義する」と記述しています(2026年9月15日確認)。NASAの「Schedule Management Handbook」(NASA/SP-2010-3403)の用語集も「ネットワーク工程表において、現時点からプロジェクト完了までの最長の所要期間を表す一連の作業。クリティカルパス上の作業が遅れれば、プロジェクト期間はその分延びる」としています(同日確認)。

日本の公的資料では、IPA(情報処理推進機構)のプロジェクトマネージャ試験シラバス Ver.7.0(2022年5月)が、「2-8 活動の順序付け」の中で「プロジェクト内の全ての活動は、ネットワーク図(作業工程図)を用いるなどして、クリティカルパスや適切な予備を決定できるように関係を明らかにする」と定めています(同日確認)。また、ITパスポート試験シラバス Ver.6.5 では、業務分析の用語例として「PERT(アローダイアグラム)、クリティカルパス分析」が挙げられています。つまり、経路を求めるには作業の順序関係が図として入っていることが前提であり、作業を並べただけの表からは求まりません。

なぜ「最長の経路」が「最短の期間」になるのか——合流地点では遅いほうを待つ

ここが多くの人がつまずく箇所です。最長と最短という正反対の言葉が1つの文に入っているため、言い間違いのように見えます。しかし理屈は単純です。

たとえば、画面デザインとサーバー側のAPI実装が並行して進み、両方が終わってから結合テストに入るとします。デザインが10日、APIが15日かかるなら、結合テストは15日目から始まります。デザイン側がどれだけ早く終わっても、遅いほうが揃わなければ先へ進めません。この「合流地点では遅いほうを待つ」が積み重なった結果が、プロジェクト全体の期間です。

つまり、全体の期間は作業時間の単純な合計ではありません(並行して進む分は重なるため)。かといって一番重い作業の長さでもありません(直列につながる分は足し算になるため)。開始から完了まで、依存関係をたどって足し算していったときに最も大きくなる経路——それが全体の期間を決めます。そして、その長さより短くは終われません。これが「最も長い経路が、最短の期間を決める」という言い回しの中身です。

先行と後続の依存関係4種類(FS・SS・FF・SF)——SFがほぼ使われない理由

経路をたどるには、作業同士がどうつながっているかを決める必要があります。GAO-16-89Gは、先行作業と後続作業を結ぶ論理関係を、終了-開始(FS)、開始-開始(SS)、終了-終了(FF)の3つの形とし、開始-終了(SF)を「理論上の4つ目」と位置づけています。

GAOは、SFについて「後続が先行の開始まで終了できないという奇妙な効果を持ち、順序の論理を逆転させる」と述べ、ベストプラクティスのチェックリストでも「スケジュールに開始-終了の論理関係を含まないこと」を条件に挙げています。実務では、FSを基本に、並行化したい箇所だけSSやFFを使うと考えておけば十分です。なお、GAOはSSとFFについても「多用すると意図しない論理の抜け(ダングリング)を生みやすく、クリティカルパスの特定を難しくする」と注意を促しています。ウォーターフォール型のように前工程へ戻らない前提の開発では依存関係がFSの直列になりやすく、その分クリティカルパスは読みやすくなります(工程の流れは「ウォーターフォール開発とは」の記事で扱っています)。

クリティカルパスが分かると何が変わるか——40行を全部見ずに済む

工程表が40行あっても、納期を決めているのはそのうちの数行です。残りの行には「遅れても納期に響かない幅」があります。この区別がつくと、監視の対象が絞れます。私は現場で、工程表は全部見ないほうがよいと伝えています。全部を等しく心配すると、本当に効く遅れを見逃すからです。では、その「遅れても響かない幅」はどう測るのか。次章で扱います。

フロート(余裕)の読み方——最早開始・最遅開始と、トータルフロート/フリーフロート

クリティカルパスは「余裕がゼロの作業が連なった経路」と言い換えられます。その余裕のことを、スケジュールの世界ではフロート(float)またはスラック(slack)と呼びます。余裕を数えるには、まず各作業について4つの日付を出します。

前進計算で最早、後進計算で最遅——4つの日付の意味

GAO-16-89Gは、4つの日付を次のように説明しています(2026年9月15日確認)。最早開始(ES)は「その作業が開始できる最も早い時点」、最早終了(EF)は「その作業が終了できる最も早い時点」で、いずれも前進計算(forward pass)で求めます。前進計算とは、開始日から順に所要期間を足していく計算で、これによってネットワーク全体を貫く最長の連続経路——すなわちクリティカルパス——の長さが出ます。

最遅開始(LS)は「プロジェクトを予定どおり終えるために、その作業が開始していなければならない最も遅い時点」、最遅終了(LF)は「同じく終了していなければならない最も遅い時点」で、後進計算(backward pass)で求めます。後進計算は前進計算の逆で、完了日から所要期間を引いていきます。

GAOは「作業の最早の日付と最遅の日付の差が、トータルフロート(スラック)として知られるものである」と述べています。つまり、トータルフロート = 最遅開始 − 最早開始(= 最遅終了 − 最早終了)です。引き算1回で出ます。

トータルフロートとフリーフロート——違いは「誰に迷惑がかかるか」

フロートには2種類あり、混同されがちです。GAO-16-89Gの用語集は次のように定義しています(2026年9月15日確認)。

• トータルフロート: 「その作業を、プログラムの完了日に影響を与える前にどれだけ遅らせたり延ばしたりできるかの量。正の値であれば、完了日を遅らせずに遅延できる時間を示す」
• フリーフロート: 「その作業のトータルフロートのうち、直後の後続作業に遅延が及ぶ前に使える部分。ネットワークの並びによっては、トータルフロートがあってもフリーフロートがない作業がある」

違いは「その遅れで誰が困るか」です。トータルフロートを使い切らない限り納期は動きません。しかしフリーフロートを超えて遅れると、直後の後続作業の開始が押されます。GAOはこの状態を「トータルフロートはあるがフリーフロートがない作業を遅らせても、プロジェクトの完了日には影響しないが、後続作業をかき乱す」と説明しています。

もう一つ、実務で効く指摘があります。GAOは「トータルフロートを使わせてしまうと、後続の作業が遅れる余地を失う。スケジュールの柔軟性を将来のリスクのために取っておかず、先に使ってしまうことになる」としています。余裕は共有の財産で、前の作業が使えばその分だけ後ろが苦しくなる、ということです。フリーフロートの計算は、直後の後続作業の最早開始 − 自分の最早終了で求められます。

フロート0がクリティカル、僅差がニアクリティカル——監視対象の決め方

GAOは「トータルフロートがゼロということは、その作業がどれだけ遅れても、その分だけプログラムの完了日が遅れるということである。トータルフロートが負またはゼロの作業はクリティカルとみなされる」と述べています。遅れが1対1で納期に伝わる——これがクリティカルの意味です。

さらに、「クリティカルパスのトータルフロートに近い、狭い範囲のトータルフロートを持つ作業は『ニアクリティカル』と呼ばれる。わずかなトータルフロートが遅延で使い尽くされれば、すぐにクリティカルになりうるからである」としています。監視対象は、フロート0の作業だけでなく、その一歩手前の作業までを含めるのが実務的です。

では、実際の工程表でこれらの数字はどう出るのか。次章で、9作業の小さなネットワークを使って全部計算してみます。

数字で追うクリティカルパス——9作業のネットワークで最早・最遅・フロートを出す

用語の説明だけでは、自分の工程表に当てはめられません。ここでは、ECサイト改修という架空の案件を9作業のネットワークにして、全部の数字を出します。作業の洗い出しそのものはWBS(作業分解構成図)の仕事なので、本記事では分解済みの状態から始めます(分解の粒度と列の作り方は「WBS テンプレート」の記事で扱っています)。

作業と依存関係の一覧——ECサイト改修の9作業

所要期間はすべて営業日です。開始時点を0日目とし、最早終了 = 最早開始 + 所要期間で数えます(この数え方なら日付のずれで混乱しません)。

依存関係はすべてFS(終了-開始)とします。AとDには先行作業がなく、どちらも0日目から開始できます。注目してほしいのは、9作業のうち3つ(A・D・H)が発注者の作業だという点です。実際の見積もり工程表では、この3つが書かれていないことが少なくありません。

前進計算・後進計算・引き算——全9作業のES/EF/LS/LF/TF/FF

前進計算から始めます。AはES=0、EF=10。DはES=0、EF=4。BはAの後なのでES=10、EF=18。CはES=18、EF=24。F1はES=18、EF=28、F2はES=28、EF=33。EはCとDの両方を待つのでES=max(24, 4)=24、EF=36。GはEとF2を待つのでES=max(36, 33)=36、EF=42。HはES=42、EF=47。総期間は47日です。

次に後進計算です。完了日47からさかのぼります。HはLF=47、LS=42。GはLF=42、LS=36。EはLF=36、LS=24。F2はLF=36、LS=31。F1はLF=31、LS=21。CはLF=24、LS=18。DはLF=24、LS=20。BはCとF1の両方に先行するのでLF=min(18, 21)=18、LS=10。AはLF=10、LS=0。

最後に引き算です。トータルフロート = LS − ES、フリーフロート = 後続の最早開始 − 自分の最早終了。

クリティカルパスは、トータルフロートが0の作業をつないだ A → B → C → E → G → H です。総期間は47日。この6作業のどれか1つが1日遅れれば、納期は1日動きます。

3本の経路を足し算で検算する——47日・44日・27日

計算が合っているかは、経路ごとの足し算で確かめられます。このネットワークには開始から完了まで3本の経路があります。

経路1が最長の47日で、これが総期間と一致します。経路2は44日なので余りは3日——これがF1とF2のトータルフロート3日と一致します。経路3は27日で余りは20日——これがDのトータルフロート20日と一致します。表の数字と足し算が合いました。計算例はここまで自分で検算してから使ってください。数字が合わない工程表は、依存関係のどこかが抜けています。

この表から読み取れること——トータルフロートはあるのにフリーフロートが0の作業

表の中でF1(API設計・実装)を見てください。トータルフロートは3日ですが、フリーフロートは0日です。つまり、F1が1日でも遅れれば、直後のF2(バッチ処理実装)の開始は必ず押されます。それでも納期は動きません。ただし、F2が使える余裕は3日から目減りします。3日全部を上流のF1が使ってしまえば、F2は1日も遅れられなくなります。

一方、D(素材提供)はトータルフロートもフリーフロートも20日です。素材の提供が20日遅れるまでは、誰にも迷惑がかかりません。この2つの違いを読み分けられると、「遅れました」という報告を受けたときに、納期に効くのか、後続を圧迫するだけなのか、どちらでもないのかを、その場で判別できます。

クリティカルパスが動く瞬間と、短縮する2つの手段——ファストトラッキングとクラッシング

クリティカルパスは一度求めたら終わりではありません。GAO-16-89Gは「クリティカルパスと最長経路は、状況を更新するたびに再評価しなければならない。経路を構成する作業の並びは変わるからである」と述べています(2026年9月15日確認)。前章の9作業の表を使って、実際にパスが移る様子を数字で見ます。

遅れでパスは移る——素材提供が4日から25日になると、納期を決めるのは別の経路になる

D(素材提供)はトータルフロート20日を持っていました。ここで、社内の権利確認が長引き、素材の準備に4日ではなく25日かかったとします。再計算すると、DのEFは25、EのESは25、EFは37、GのESは37、EFは43、HのEFは48。総期間は47日から48日になり、1日遅れます。

このとき、クリティカルパスはA→B→C→E→G→Hではなく、D → E → G → H(25+12+6+5=48日)に移っています。これまで「余裕20日」で誰も見ていなかった作業が、納期を決める作業に変わりました。もとのクリティカルパスだったA→B→C→E→G→Hは47日となり、余裕1日を持つ経路に降格します。

逆方向も同じです。F1(API設計・実装)が10日から14日に延びると、経路2は48日となって最長になり、クリティカルパスはA→B→F1→F2→G→Hに移ります(トータルフロート3日を4日超過したのではなく、3日を1日超えた分だけ納期が1日動く計算です)。余裕を持っていた経路が余裕を使い切った瞬間、監視対象が入れ替わる。これが「クリティカルパスが動く」ということです。

短縮する2つの手段と、それぞれの副作用

納期を縮めたいときの手段は、大きく2つに整理されています。GAO-16-89Gの表6「回復と短縮の戦略」は次のようにまとめています(2026年9月15日確認)。

NASAのSchedule Management Handbook 7.10「Duration Compression」も同じ2手段を挙げ、クラッシングについて「この方法は確実にコスト増を招くため、時間とコストのトレードオフを評価すべきである」、ファストトラッキングについて「必ずしもコスト増になるとは限らないが、とくに手戻りによる遅延という点でプロジェクトのリスクを確実に高めうる」としています(同日確認)。どちらも「短くなるが、何かを差し出す」手段です。

前章の9作業で試します。ファストトラッキングとして、C(画面デザイン)→E(フロントエンド実装)のFSをSS+3日に変え、デザインが3日進んだ時点で実装に着手する形にします。EのESは21になり、EFは33。GのESは33、総期間は44日——3日短縮します。ただし、デザインが後から変わればフロント実装は手戻りします(仕様変更が追加費用になる線引きは「仕様変更 追加費用」の記事で扱っています)。当社がこの場面で置いているのは、日本人PMの設計レビューとGitプルリクエストによるコードレビューの標準化、そしてリリース前のダブルチェックです。並行させるなら、ずれを早く見つける仕組みを先に用意しておかないと、短縮した3日を手戻りで失います。

短縮は途中で効かなくなる——12日を9日にすれば3日縮むが、6日にしても1日も縮まない

クラッシングも試します。E(フロントエンド実装)に1名増やして、12日を9日に縮めたとします。EのEFは33、GのESはmax(33, F2のEF=33)=33、総期間は44日。やはり3日短縮します。

ここで、さらに人を足してEを6日まで縮めたとします。EのEFは30。しかしGのESはmax(30, 33)=33のまま変わらず、総期間は44日のままです。1日も縮みません。 Eを9日にした時点でクリティカルパスはA→B→C→E→G→Hだけでなく、A→B→F1→F2→G→Hにも移っており、44日を決めているのはF1→F2の経路だからです。さらに縮めたければ、今度はF1かF2に手を入れる必要があります。

「人を増やせば間に合う」という見立てが外れるのは、この構造のためです。増員が効くのはクリティカルパス上の作業に限られ、しかもそこを縮めると別の経路が最長になって効き目が止まります。加えて、作業には人を足しても分割できないものがあります(工数と工期が別物である理由は「工数とは」の記事で詳しく扱っています)。現実の制約もあります。当社の場合、増員にかかる期間は約1週間、新規の立ち上げは打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始という流れで最短2週間です。納期の1か月前に増員を決めても、間に合う範囲は限られるのが実情です。

PERTとの関係——1点で置くか、幅で置くか

PERTは、作業の順序関係を図にして所要期間を評価する手法です。IPAのITパスポート試験シラバス Ver.6.5では、業務分析の用語例として「PERT(アローダイアグラム)、クリティカルパス分析」が並記されており(2026年9月15日確認)、日本ではPERTとアローダイアグラムがほぼ同義に扱われています。プロジェクトマネージャ試験シラバス Ver.7.0でも、順序付けの手段として「ネットワーク図(作業工程図)」が挙げられています。

本記事の計算例のように、所要期間を1つの数字で置く方法には限界があります。GAO-16-89Gは、期間の不確かさを扱う方法として「3点見積もり」(最小・最頻・最大の3つで置く)とモンテカルロ・シミュレーションを挙げ、住宅建設の例で「決定論的なスケジュールが算出した2月10日ではなく、期待される完了日は2月25日になる」と示しています(同日確認)。1点で置いた工程表の完了日は、実は達成確率が低い日付であることが多い——この視点を持っておくと、「クリティカルパスの長さ=約束できる納期」と考えるのが危ういことが分かります。クリティカルパスの長さは最短の期間であって、確からしい期間ではありません。

発注者はクリティカルパスをどこで使うか——見積もり工程表の読み方と、外部チームとの共有

ここまでは計算の話でした。発注する側にとって、クリティカルパスは自分で引くものというより、開発会社から出てきた工程表を読むための道具です。納期が動かせない開発を任せるなら、契約前の工程表の段階でリスクの所在が分かっていたほうがよい。何を見ればよいかを整理します。

見積もり工程表で最初に確かめる5点——依存関係、発注者タスク、フロート、合流、バッファの置き場所

5番について補足します。GAO-16-89Gは「ある作業や経路に不合理に大きいトータルフロートがあることは、スケジュールの論理が欠けているか無効であることを示す」としています(2026年9月15日確認)。余裕が100日ある行が並んでいる工程表は、余裕があるのではなく、依存関係がつながっていないだけ、という見方です。きれいに見える工程表ほど疑ってください。

発注者自身の作業がクリティカルパスに乗っているとき——仕様確定・素材提供・検収

前章の計算例に戻ります。クリティカルパス A → B → C → E → G → H のうち、A(要件確定)とH(受入テスト)は発注者の作業でした。トータルフロートはどちらも0日です。つまり、要件確定が3日延びれば納期は3日、検収の着手が2日遅れれば納期は2日動きます。一方、D(素材提供)は余裕20日でした。同じ発注者の作業でも、性質がまったく違います。

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、納期がずれた案件をさかのぼると、開発側の実装が遅れたケースより、発注側の仕様確定・素材提供・検収が遅れたケースのほうが多いのが実情です。原因は能力ではなく、構造です。発注者の作業は工程の先頭と末尾に集中し、そこには余裕がない。しかも社内の承認や他部署の確認を挟むため、開発会社側から見えにくく、催促もしにくい。「来週まとめて確認します」という一言が、そのまま納期の一週間になります。

具体的には、次の3つを工程表の行として立て、所要期間と担当者名を入れてください。

• 仕様確定: 誰が最終承認するか。承認に社内の会議体を通すなら、その会議の開催日まで含めて所要期間に入れる
• 素材提供: ロゴ・画像・原稿・マスタデータ。権利確認や他部署の手配が必要なものは、着手を前倒しする。余裕があるうちに動かすのが基本
• 検収(受入テスト): テストシナリオと担当者、判定基準を先に決めておく。ここが遅れると、直前まで順調だった案件がそのまま納期超過になる(準備の具体は「UATとは」の記事で扱っています)

誰の作業かを図で固定しておくと、この会話は進めやすくなります(登場する役割の整理は「プロジェクト体制図」の記事で扱っています)。

外部チームに任せるときのクリティカルパスの共有——当社の場合

開発を外部のチームに任せる場合、クリティカルパスの共有は「進捗の共有」より先にやるべきことです。順調かどうかを報告し合う前に、どこで詰まると納期が動くのかを両者で握っておく。握れていれば、報告の中身が変わります。「A画面の実装が2日遅れています」ではなく「2日遅れましたが、この行はフロート5日なので納期は動きません」と言えるようになります(報告の粒度と頻度の設計そのものは「進捗管理 とは」の記事で扱っています)。

当社はベトナム・ホーチミンを拠点にしていて、日本との時差は2時間です。日本の9時がベトナムの7時、日本の18時がベトナムの16時にあたるため、日本側の午前中とベトナム側の夕方までが重なります(時差の詳細は「ベトナム 時差」の記事で扱っています)。当社では、この重なる時間帯に日次の短い確認と週次の判断を置き、クリティカルパス上の作業と、発注者側の宿題(仕様の決定待ち、素材待ち、レビュー待ち)を同じ場で見るようにしています。時差が2時間しかないことの実務的な意味は、「納期を決めている作業が詰まった当日のうちに相談できる」という点にあります。

体制としては、日本人PM/ブリッジSEをフロントに置くパターンA(推奨)と、エンジニアのみのパターンBがあります。納期が動かせない開発では、パターンAを勧めています(日本人PMを置く判断基準は「オフショア開発 日本人PM」の記事で扱っています)。理由は単純で、クリティカルパスの読み替えと、発注者側の宿題の催促を日本語で行う役が要るからです。当社は2,000名以上のIT人財データベースから直接アサインしており、協力会社を挟まないため、誰がどの作業を持っているかが工程表の行と一対一で対応します。公開している単価は実務3年目安で1,500USD(約22.5万円、1USD=150円換算目安)、5年で2,000USD、10年・ブリッジSEで3,000USD、最小構成は日本人PMフロント+2〜3人月の月額約80万円〜です。増員は約1週間、縮小・交代は1か月単位で調整できます。

介護記録SaaS「CareViewer」では、日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、週次の優先順位判断を回しています。要件が動くプロダクトでは、クリティカルパスもその都度動きます。毎週「今週、納期を決めているのはどの作業か」を確かめ直すほうが、固定した工程表を守ろうとするより結果的に早い。あなたの手元の工程表では、納期を決めている行はどれで、そこに自社の作業は何日分乗っているでしょうか。

クリティカルパスに関するよくある質問

クリティカルパスについて、相談の場で繰り返し聞かれる質問を5つにまとめました。社内説明にもお使いください。

Q1. ガントチャートとクリティカルパスはどう違いますか?

ガントチャートは作業を横棒で時系列に並べた表示形式、クリティカルパスはその中で納期を決めている経路です。依存関係が入っていないガントチャートからはクリティカルパスを求められません。多くのツールはクリティカルパスを色分け表示できますが、それは各行に先行作業が設定されている場合に限られます。

Q2. クリティカルパスは必ず1本ですか?

いいえ。同じ長さの経路が複数あれば複数本になります。本記事の計算例でも、フロントエンド実装を12日から9日に縮めた時点で、クリティカルパスは2本になりました。GAO-16-89Gも、クリティカルパスが複数の並びに枝分かれしうることを前提に記述しています。

Q3. 医療で聞く「クリニカルパス」とは違うものですか?

別のものです。クリニカルパス(クリティカルパスと呼ばれることもあります)は、医療機関で使われる標準的な診療計画表を指します。工程表のクリティカルパスとは用途も指すものも異なるため、社内で誤解が起きそうな場合は「工程表のクリティカルパス」と補って呼んでください。

Q4. 工程表を見たら余裕(フロート)が100日ある行ばかりでした。安心してよいですか?

要注意です。GAO-16-89Gは、不合理に大きいトータルフロートはスケジュールの論理が欠けているか無効であることを示すとしています。余裕があるのではなく、その行が他の行とつながっていないだけ、という可能性が高い状態です。まず依存関係を確かめてください。

Q5. 人を増やせば納期は縮みますか?

クリティカルパス上の作業で、かつ人を足して分割できる作業であれば縮みます。それ以外では1日も縮みません。加えて、縮めると別の経路が最長になって効き目が止まります。現実の制約もあり、当社の場合は増員に約1週間、新規の立ち上げには最短2週間かかります。納期の直前に人を足すという判断は、効く範囲がきわめて限定的。

まとめ: 工程表は全部見ない——納期を決めている数行と、余裕の残量だけを見る

クリティカルパスとは、工程表の中で最も長く連続する作業の並びのことで、その長さがそのままプロジェクトの最短期間になります。作業は先行・後続の依存関係でつながり、複数の経路が合流する地点では遅いほうが揃うまで先へ進めません。だから全体の期間は作業時間の合計でも一番重い作業の長さでもなく、最も長い経路の長さで決まります。この経路の上にある作業はトータルフロートが0で、1日遅れれば納期が1日動きます。外れている作業には余裕があり、その余裕には納期に影響しない幅(トータルフロート)と、直後の後続に影響しない幅(フリーフロート)の2種類があります。本記事の9作業の計算例では、総期間47日、クリティカルパスはA→B→C→E→G→H、素材提供の余裕は20日、API実装の余裕は3日でフリーフロートは0日でした。

クリティカルパスは固定されたものではありません。余裕を使い切った経路が最長になれば監視対象が入れ替わり、短縮すれば別の経路が最長になって効き目が止まります。計算例では、フロントエンド実装を12日から9日に縮めれば3日短縮できましたが、さらに6日まで縮めても1日も縮みませんでした。短縮の手段はファストトラッキング(直列の依存を並行に緩める)とクラッシング(資源を追加する)の2つで、前者は手戻りのリスク、後者はコスト増と品質低下という副作用を伴います。人を増やせば間に合う、という見立てが外れるのはこの構造のためです。

発注する側にとって、クリティカルパスは自分で引くものではなく、出てきた工程表を読むための道具です。依存関係が入っているか、自社の作業(仕様確定・素材提供・検収)が行として載っているか、各行の余裕がいくつかを確かめてください。要件確定と検収は工程の先頭と末尾にあり、そこに余裕がないことが多いのが実情です。作業の洗い出しと粒度はWBSテンプレート、進捗の測り方と報告の粒度は進捗管理とはもあわせてご覧ください。外部のチームに任せるなら、進捗を共有する前に「どこで詰まると納期が動くか」を先に握っておくことをお勧めします。現在の体制と要件をお聞かせいただければ、納期が動かせる案件かどうかの見立てと概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。