「スケジュールが崩れる瞬間」を設計に織り込む——バッファ管理とクリティカルチェーンで”崩れにくい計画”を作る実践技法

＜目次＞

なぜ「丁寧に作ったスケジュール」ほど早く崩れるのか
「個人バッファ」がスケジュールを食い潰すメカニズム
1. 解決策：バッファを「個人」から「プロジェクト」へ移す
バッファ管理を「日常業務」にする3つの仕組み
「バッファを守る文化」をどう作るか
まとめ：崩れにくい計画は「崩れること」を想定して作られる

なぜ「丁寧に作ったスケジュール」ほど早く崩れるのか

プロジェクトマネジメントの現場でよく耳にする嘆きがある。「あれだけ時間をかけてスケジュールを作ったのに、開始1週間で既に遅れている」——。

皮肉なことに、丁寧に作り込んだスケジュールほど、崩れやすい傾向がある。その理由は、「崩れないこと」を前提に設計されているからだ。現実のプロジェクトには、仕様の微妙なズレ、メンバーの体調不良、外部ベンダーの遅延、想定外の承認待ちなど、無数の「小さな乱れ」が発生する。それらを一切織り込まずに作られた計画は、最初の乱れが連鎖した瞬間に全体が崩壊する。

本記事では、「崩れること」を前提にした設計思想——特にバッファ管理とクリティカルチェーンの考え方を軸に、現実に機能するスケジュール設計の実践技法を解説する。

「個人バッファ」がスケジュールを食い潰すメカニズム

スケジュールが崩れる根本原因のひとつは、各タスクの担当者が個別に”安全マージン”を積み込んでいることにある。

例えば、実際には3日で終わるタスクを「5日」で見積もる。これ自体は合理的な自己防衛だ。しかし問題は、その余裕がパーキンソンの法則（仕事は与えられた時間をすべて使い切る）によって消費されてしまう点にある。5日の余裕があれば5日使う。結果として、個人バッファは「完了を早める」のではなく「完了を先送りにする」機能を果たしてしまう。

さらに悪化させるのが学生症候群だ。締め切りまで余裕があると感じた担当者は、意識的・無意識的に着手を遅らせる。5日あるうちの最初の2日は実質ほぼ動かず、残り3日で本来の作業量をこなそうとする。個人バッファは、緊張感を下げる副作用を生む。

解決策：バッファを「個人」から「プロジェクト」へ移す

クリティカルチェーン・プロジェクトマネジメント（CCPM）の核心的なアイデアは、個人バッファを取り除き、プロジェクト全体のバッファとして集約することだ。

具体的には次のように設計する。

各タスクの見積もりを「50%確率で完了できる積極的な期間」に圧縮する
削減した余裕を積み上げて「プロジェクトバッファ」としてスケジュールの末尾に配置する
クリティカルチェーン（制約資源を含む最長経路）の合流点に「フィーディングバッファ」を設ける

この設計により、個人の遅れが即座に全体遅延に直結するのを防ぎながら、バッファの消費状況をプロジェクト全体の健全性指標として可視化できる。

バッファ管理を「日常業務」にする3つの仕組み

CCPM的な考え方を理解しても、それを日々の管理に落とし込めなければ意味がない。以下の3つの仕組みが実践の起点になる。

1. バッファ消費率をプロジェクトの「体温計」にする

プロジェクトバッファのうち何％が消費されたかを、進捗率と並べて毎週確認する。例えば「進捗40%、バッファ消費20%」であれば健全。「進捗40%、バッファ消費60%」であれば、計画の見直しや追加リソースの投入を検討するシグナルだ。

この指標は、担当者の「感覚的な報告」ではなく、数値として議論の場に上げられるため、PMとチームの間に共通言語が生まれる。

2. 「残り作業量」で進捗を測る

進捗を「何%完了したか」で測ると、最後の10%が永遠に終わらない”90%シンドローム”に陥りやすい。代わりに「あと何日（何時間）かかるか」という残余作業量で把握する習慣をつけると、実態が見えやすくなる。週次の進捗会議では「今週は何を終えたか」より「完了までの残工数はいくつか」を問う設計にするだけで、報告の質が変わる。

3. クリティカルタスクへの集中を「構造」で保証する

クリティカルチェーン上のタスクが遅れると、プロジェクトバッファが直接削られる。したがって、クリティカルタスクを担当するメンバーが、並行する非クリティカルな作業に引っ張られないよう、優先度を明示的に「構造化」することが重要だ。タスク管理ツール上でクリティカルフラグを立てる、週次の1on1でクリティカルタスクの状況を最初に確認する、などの工夫が有効だ。