ガントチャートは「線」ではなく「依存」を描く道具——引き方の順番

ガントチャートで最初に決めるのは日付ではなく、どの作業がどの作業に依存しているかです。依存が決まっていれば日付は後から機械的に置けますが、日付から引いたガントは、遅れが1本出るたびに全部引き直しになります。

Web制作会社、事業会社のWeb担当、大手ITのテクニカルディレクター、そして独立後の一人体制。どの立場でも、線を引き直す時間が一番むだでした。順番を変えるだけで、その時間はかなり減ります。

線は「結果」であって「入力」ではない

ガントの棒は、作業の期間と順序を表示したものです。表示なので、入力である依存関係が変われば自動で変わってほしい。実際、Microsoft Projectは自動スケジュールのタスクについて、依存関係・制約・リソースから開始日と終了日を計算する仕組みになっていて、手動スケジュールにすると他が動いても日付は固定されると説明されています（How Project schedules tasks）。

ツールがProjectでもスプレッドシートでも、考え方は同じです。日付を手で置いた瞬間、そのガントは「計算されない表」になります。私は表計算で引くときも、日付欄の隣に必ず「先行タスク」の列を作ります。列があるだけで、日付を直す前に依存を見る癖がつきます。

依存の型は4つ、実務で使うのは2つ

依存関係には終了-開始（FS）、開始-開始（SS）、終了-終了（FF）、開始-終了（SF）の4種類があり、既定はFSです（Link tasks in a project）。

Web制作で私が使うのは、ほぼFSとSSの2つです。

型	意味	制作での例
FS	前が終わらないと始められない	ワイヤー確定 → デザインカンプ着手
SS	前が始まれば始められる	実装開始 → 原稿の流し込み準備

FFとSFは、書けはしますが読み手が減ります。関係者に口頭で説明できない依存は、ガントに載せても運用されないというのが私の実感です。迷ったらFSで書き、どうしても並行させたい箇所だけSSにする。それで足ります。

引く順番は「終わり→依存→期間→日付」

私の手順は4段階です。

1. 公開日と、そこから逆算して動かせない日を1つ決める（検収日、印刷入稿日など）
2. 各タスクの先行タスクを1行ずつ書く（「これが終わらないと始められないのは何か」だけを考える）
3. 期間を入れる（日付ではなく「5営業日」のような長さ）
4. 最後に日付を置く

3までが終われば、いちばん長くつながった経路が自動的に見えます。これが遅れると全体が遅れる経路で、Microsoftのドキュメントでも、クリティカルパスは終了日を決めるタスクの連なりで、余裕（スラック）がないタスクだと説明されています（Show the critical path）。

順番を守る利点は、遅れたときの判断が速くなることです。クリティカルパス上のタスクが遅れたら公開日の相談、そうでなければ社内の調整で吸収する。この判断を毎回ゼロから考えなくてよくなります。

クライアント確認は「依存」として書く

制作で線が伸びる原因の多くは、作業ではなく確認待ちです。私は確認を独立した行にして、期間を入れています。「カンプ確認（3営業日）」のように書くと、確認が遅れたときに何が押されるかがガント上で見えます。

作業の中に確認を含めてしまうと、遅れの原因が「デザインが遅い」に見えてしまう。誰の責任かを争うためではなく、次にどこを短くできるかを話すために、確認は分けて書く価値があります。

明日から試せる一手

いま動いているガントを1本開いて、先行タスクの列があるかを見てください。無ければ、各行に「この行の前に終わっていないといけない行」を1つだけ書き足します。全部の行に書く必要はありません。

書き終えたら、つながった経路を目でたどってみる。いちばん長い経路が、そのプロジェクトで守るべき線です。線を引き直す前に、そこだけ見れば判断できるようになります。