バッファはタスクごとに積むか、末尾にまとめるか——置き方で変わるもの

スケジュールの余裕をどこに置くか、と聞かれたら、私は末尾にまとめる側に寄せています。ただし全部を末尾に集めるのではなく、他チームの作業が合流する手前にも別枠で置く。この2段構えにしてから、「各工程は予定どおりだったのに全体が遅れた」という説明をしなくて済むようになりました。

タスクごとの余裕は、余裕として残らない

各タスクに1〜2日ずつ足していく引き方は、見た目には安全です。問題は、その余裕がリスクではなく行動に食われることのほうにあります。

よく引かれるのが次の2つです。ひとつは、C. Northcote Parkinson が1955年に『The Economist』誌に書いた風刺エッセイに由来する「パーキンソンの法則」——work expands so as to fill the time available for its completion、つまり作業は与えられた時間いっぱいまで膨らむ、という観察です。もうひとつは、締切の直前まで着手を後回しにする傾向を指す「学生症候群」。前者は始まったあとの伸び方、後者は始めるタイミングの話で、原因が違います。

私自身、デザインと実装を一人で往復していた時期に両方やりました。3日と見た作業に1日足して4日にすると、3日目までは他の案件を見てしまう。そして4日目に想定外が出ると、足したはずの1日はもう残っていません。余裕を使ったのではなく、余裕の分だけ着手が遅れただけ、という状態です。

末尾にまとめると「誰の余裕か」が変わる

タスク単位の余裕を削って末尾に集める考え方は、Eliyahu M. Goldratt が1997年の著書『Critical Chain』で示したクリティカルチェーンの中で整理されています。最後に置く分をプロジェクトバッファと呼び、Goldratt はもとの見積もりを半分に切り、切った鎖の長さの半分をバッファに充てる、という単純な比率を示したとされています。

比率をそのまま採るかは案件によりますが、置き場所を変える効果のほうが実務では大きいと感じています。タスクに積んだ余裕は、その担当者の持ち物になります。末尾に置いた余裕は、案件全体の持ち物になります。持ち主が変わると、「今この余裕を使っていいか」を全員で判断できるようになる。私はこれを、遅れの報告が早くなる仕組みとして使っています。

合流点には別枠を置く

ただし全部を末尾に寄せると、途中の合流で詰まります。他チームや外部から来る作業が本線に合流する手前には、別途余裕を置く。クリティカルチェーンではこれをフィーディングバッファと呼び、本線でない作業のブレが本線に伝わらないようにする役割だと説明されています。

Web制作でこれが効くのは、だいたい次の3か所でした。

合流点	遅れると止まるもの
原稿・写真の支給	文字量調整、実装の確定、検証
先方の法務・監修チェック	公開判断そのもの
外部API・決済の審査	結合テストの開始

いずれもこちらの管理外なので、努力では縮みません。だから末尾ではなく、その直前に置きます。

クライアントに出す線と、手元に残す線

もうひとつ、社外に見せる余裕と見せない余裕を分けています。プロジェクトマネジメントの用語では、識別済みのリスクに対して基準線の中に持つ分をコンティンジェンシー予備、想定外のために基準線の外に持つ分をマネジメント予備として区別する、と整理されています。

実務に直すと、「原稿が1週間ずれる可能性がある」のように理由を説明できる余裕は、スケジュール表に書いて共有します。理由を説明できない分は、公開日の手前に無言で残しておく。これを混ぜて全部を表に出すと、余裕が交渉材料になって削られます。逆に全部を隠すと、原稿の締切が守られるべきものだと伝わりません。

明日から試せる一手

進行中の工程表を開いて、各タスクの日数から「念のため」で足した分を書き出してみてください。合計してみると、思ったより大きな数字になっているはずです。その合計を、まず公開日の手前に1本の帯として置き直す。そのうえで、原稿の支給や先方チェックが合流する箇所を1つだけ選び、そこに2〜3日を戻す。工程表の総日数は変えずに、置き場所だけ動かす——それだけで、次に遅れが出たときの会話が変わります。