ガントチャートを作っただけでは管理できない——クリティカルパスとバッファで動かすスケジュール管理

ガントチャートを作っただけでは、スケジュールは管理できない

プロジェクト開始直後に美しいガントチャートを作り上げ、それを眺めて「計画はできた」と安心したことはないでしょうか。しかし数週間後に振り返ると、当初の計画と現実がかけ離れていて、誰もガントチャートを参照しなくなっている——そんな光景がIT現場には溢れています。

ガントチャートはスケジュール管理の「地図」ではなく「写真」です。作った瞬間は現実を反映していますが、時間が経てば古くなります。スケジュール管理の本質は、ガントチャートを作ることではなく、計画と現実の差異をリアルタイムに把握し、対処し続けることです。本記事では、スケジュール管理のプロセスと、現場で機能するクリティカルパス管理・バッファ設計の実践手法を解説します。

スケジュール管理の全体プロセス

PMBOKにおけるスケジュール管理は、計画フェーズから実行フェーズにまたがる以下のプロセスで構成されます。

このプロセスで最もよく省略されるのが「アクティビティの順序設定」です。タスクをリストアップして期間を割り当てただけでは、タスク間の依存関係が曖昧なままになり、「Aが終わらないとBができない」という制約が計画に反映されません。その結果、計画上は問題なく見えても、実際には特定の作業が詰まって後続すべてが止まるという事態が起きます。

依存関係の4類型を理解する

タスクの順序を設計するうえで、依存関係には4つの類型があります。最も一般的なのはFS（Finish-to-Start）で、先行タスクが完了してから後続タスクを開始するというシンプルな依存関係です。要件定義が終わってから設計を始める、という関係がこれにあたります。

SS（Start-to-Start）は、先行タスクが開始されたら後続タスクも開始できる関係です。「コーディングを始めたら、ユニットテストの準備も並行して進める」というケースです。FF（Finish-to-Finish）は両方が同じタイミングで完了する必要がある関係、SF（Start-to-Finish）は先行が開始されてから後続が完了する、という非常に稀な関係です。

実務上は、FSとSSを組み合わせることで並行作業の設計が可能になります。すべての作業をFSで直列に繋いでしまうと、理論上は正しいスケジュールが組めても、現実的な短縮の余地がなくなります。「どこを並行して進められるか」を考えることが、スケジュール圧縮の第一歩です。

クリティカルパス：プロジェクトの「背骨」を把握する

クリティカルパスとは何か

クリティカルパス（Critical Path）とは、プロジェクト内のすべての作業経路の中で、最も所要期間が長い経路のことです。この経路上にあるタスクは、1日でも遅延するとプロジェクト全体の完了日が1日遅れます。逆に言えば、クリティカルパス上にないタスクには「余裕時間（フロート）」があり、多少の遅延があっても全体には影響しません。

たとえば10個のタスクがあるプロジェクトで、クリティカルパス上にあるのが4つだとします。PMとしてリソースや注意を集中すべきは、この4つのタスクです。残りの6つは余裕があるため、問題が発生した場合の予備として活用できます。しかしこの「どこに集中すべきか」が見えていないと、緊急でないタスクに過剰なリソースを注ぎ込む一方、クリティカルな作業への手当てが遅れるという逆転が起きます。

クリティカルパスの計算

クリティカルパスを求めるには、各タスクの最早開始日・最早完了日を前向きに計算し（フォワードパス）、その後最遅開始日・最遅完了日を後ろ向きに計算します（バックワードパス）。最早と最遅の差がゼロのタスクがクリティカルパス上にあります。

現代のプロジェクト管理ツール（MS Project、JIRA Advanced Roadmaps、Asanaなど）はこれを自動計算しますが、原理を理解していなければ、ツールが出した結果を正しく解釈できません。PMとして「このタスクにフロートはあるか」「クリティカルパスはどこか」を即座に判断できることが、スケジュール管理の基礎体力です。

クリティカルパスが変わることを知っておく

プロジェクト進行中に、クリティカルパスは変化します。当初はクリティカルでなかったタスクが遅延すると、そのタスクが新しいクリティカルパスになることがあります。これを「クリティカルパスのシフト」と呼びます。

定期的にスケジュールを更新し、クリティカルパスが変わっていないかを確認することが、スケジュール管理のルーティンとして必要です。「先週はここがクリティカルだったが、今週はあそこがクリティカルになった」という変化に気づかなければ、注意を向けるべき場所を間違え続けます。

バッファ設計：不確実性を計画に組み込む

「余裕を持たせると作業が膨らむ」問題

スケジュールに余裕を持たせると、パーキンソンの法則（仕事は与えられた時間を使い切る傾向がある）が働き、結果として余裕がなかった場合と同じ時期に完了する——そんな経験をしたPMは多いはずです。各タスクに個別にバッファを持たせる従来の方法では、バッファが「使われて当然のもの」として消費されてしまいます。

クリティカルチェーン・プロジェクトマネジメント（CCPM）ではこの問題に対して、個別タスクのバッファを削除し、代わりにプロジェクト全体の末尾に「プロジェクトバッファ」を集約するという考え方を提唱しています。バッファを集約することで「全体の保険」として機能させ、個別タスクでの消費を防ぎます。

現場で使えるバッファ設計の原則

CCPMの厳密な実装は難しくても、バッファの考え方は現場に応用できます。まず、各タスクの所要期間を見積もる際に「安全に完了できる時間（50%の確率で達成できる期間）」を基準にします。次に、プロジェクト全体または主要フェーズの末尾に、削減した個別バッファの合計の約50%をまとめてバッファとして配置します。

このバッファは「使うな」ではなく「使用量を見える化する」ものです。バッファの消費率をスケジュールの進捗率と比較することで、「バッファを20%消費した時点でプロジェクト進捗は40%」なら健全、「バッファを60%消費して進捗30%」なら危険信号と判断できます。

スケジュールのコントロール：計画と現実を繋ぐ

進捗更新を「儀式」にしない

多くの現場でスケジュールの進捗更新が形骸化する理由は、更新した結果を誰も意思決定に使わないからです。毎週ガントチャートを「何%完了しました」と塗り替えているだけでは、それは記録であって管理ではありません。

スケジュールのコントロールで本来すべきことは、計画との差異を測定し、差異が生じている原因を特定し、是正アクションを決定することです。「予定より2日遅れている」という事実より、「なぜ遅れているか」と「それをどう取り戻すか、あるいは後続計画をどう調整するか」の判断が重要です。

短いサイクルで「小さな問題」を拾う

スケジュール管理で有効なのは、進捗確認のサイクルを短くすることです。2週間に1度の確認では、問題が発覚したときにはすでに取り返しのつかない状況になっていることがあります。1週間以内の短いサイクルで「今週の予定に対して実績はどうか」を確認することで、小さな遅延を早期に捉え、まだ対処できる余地があるうちに手を打てます。

まとめ：スケジュール管理は「計画を守る」ではなく「現実を読む」仕事

スケジュール管理の目的は、最初に作った計画通りに物事を進めることではありません。計画を起点にしながら、現実との差異を読み取り、プロジェクトを完了に向けてナビゲートし続けることです。

クリティカルパスを把握し、バッファを戦略的に設計し、短いサイクルで現実と向き合う——この三つが揃ったとき、スケジュール管理は「管理のための管理」から「プロジェクトを動かすための羅針盤」に変わります。