ガントチャートを先に引くと、なぜ計画が歪むのか
「ガントチャートが引けるツールを探している」という相談を、ときどき受けます。話を聞いていくと、本当に詰まっているのはガントチャートそのものではなく、その手前の「作業の分解」だったりします。そして、ここを飛ばしてガントから入ると、計画は目に見えて崩れるというより、静かに歪みます。今日はその歪み方から始めて、では正しい順で何が変わるのか、という順で書きます。
失敗①：棒が大きすぎて、進捗が読めない
分解が済んでいないままガントを引こうとすると、時間軸に置く棒が「設計」「実装」のような大きすぎる単位になります。すると、その棒は2週間ぶんの長さになる。
問題は、この長い棒からは途中の状態が読めないことです。設計の棒が2週間分あって、今ちょうど真ん中あたり。でも、それが順調なのか遅れているのかは、棒を見ても分からない。設計の中には「画面遷移を書く」「テーブルを決める」「レビュー対応」といった中身があるはずなのに、棒はそれを一本に潰してしまっているので、「2週間のうち1週間が経った」以上のことが言えない。ガントは本来「今どこが遅れているか」を見るための道具なのに、棒が粗いと、その肝心の機能が死にます。
棒の長さは WBS の粒度がそのまま出るので、分解が粗ければ、どれだけ丁寧にガントを描いても粗いままです。逆に、成果物やタスクまで割ってあれば、棒も成果物単位の手頃な長さになり、「基本設計書は終わったが、画面モックが遅れている」と、遅れの居場所まで見える。きれいなガントは、細かいガント機能ではなく、細かい分解から生まれます。
失敗②：日付が、分解を歪める（偽の精度）
こちらのほうが厄介です。ガントから入ると、人はつい日付を先に決めて、そこに作業を合わせにいきます。「この案件は今月末までだから、設計は来週まで、実装はその次の週で」。一見きれいに埋まる。でも、この順番だと、成果物の切り方そのものが締め切りに引っ張られます。
具体的に言うと、本当は成果物が3つに分かれるべき仕事を、「2週間で収めたいから」という理由で2つに丸めてしまう。あるいは、まだ中身の見えていない作業に、埋めるべき空欄があるからと、えいやで日付を振ってしまう。締め切りという「枠」が先にあると、人はその枠に収まるように分解を調整してしまうのです。
こうしてできたガントは、見た目は精緻でも、根拠のない精度です。日付が入っていると、いかにも計画が固まったように見える。でも、その日付は作業の実態から積み上がったものではなく、締め切りから逆算して割り振っただけ。分解より先に日程を置くと、計画は「正しく分かっている」のではなく「きれいに埋まっている」だけの状態になる。私はこれを偽の精度と呼んでいて、後半で必ず破綻します。破綻するのは、逆算で割り振った日付には、各作業が本当にどれくらいかかるかの根拠が入っていないからです。
では、正しい順だと何が変わるか
順番を逆にする――つまり分解を先にやると、この二つの失敗が両方消えます。
先に「何を作るか」を成果物・タスクまで割り切ってしまう。この段階では、まだ日付を一つも入れません。純粋に「この仕事は、どんな塊でできているか」だけを考える。締め切りを見ないぶん、成果物の切り方が実態に沿う。3つに分かれるべきものは、素直に3つになる。
そのうえで、割り切った各項目に開始日と期限を与えていく。ここで初めて時間軸が出てきて、同じ構造がガントとして並びます。すると、今度は逆に「この期間に、この分解を詰め込むのは無理がある」というズレが見える。分解が先にあるから、日程の無理が分解の側から検算できる。偽の精度のときは日程が分解を歪めていたのが、正しい順では分解が日程の無理を暴く。同じ二つの要素でも、置く順番でまったく逆の働きをします。
なぜ WBS が先なのか
ここまでを一つの原則にまとめると、こうです。「何を」が決まっていないのに「いつ」は決められない。
WBS は、やるべき仕事を構造として分解するものです。大きな塊を、フェーズ・成果物・タスクへ割っていく。ここで決まるのは「何を、どの粒度でやるか」で、時間軸はまだ出てきません。ガントチャートは、その分解した項目を時間軸の上に並べるもので、ここで初めて「いつやるか」が決まる。つまり WBS が「何を」を、ガントが「いつ」を担う。順番として、WBS が先、ガントは後です。
きれいなガントチャートは、きれいな WBS の結果であって、ガントを先に頑張っても骨格は出てきません。見積もりの精度が分解の粒度で決まるのも、まったく同じ構造です。分解が甘いと、その上に乗るものは全部甘くなる。ガントも、見積もりも、進捗も、土台の分解の質を超えられません。
だから、ツールも「分解できるか」で選ぶ
この順番が腹落ちすると、ツール選びの基準も変わります。ガントが引けるかを入口にすると、見た目のきれいなガント機能に引っ張られがちですが、本当に見るべきはその手前で WBS をちゃんと分解できるかです。分解の器がしっかりしていれば、ガントは自然にきれいになる。逆に、分解が弱いツールで立派なガントだけ描いても、失敗①②に逆戻りします。
LayerClock を作るとき、この順番はそのまま設計に反映しました。まず 4 階層（プロジェクト・フェーズ・成果物・タスク）で分解する WBS があって、ガントチャートはその WBS を時間軸に並べたビューとして出てくる。別々のモードではなく、同じ構造を「木として見るか、カレンダーとして見るか」の切り替えにしています。WBS で成果物を足せば、ガントにも棒が増える。二つは同じものの二つの顔だ、という設計です。
実務では、分解と日付を分けて時間を取る
具体的な回し方としては、最初に WBS で分解だけを済ませてしまうのがおすすめです。日付はまだ入れない。「何を作るか」の木がひととおりできてから、各項目に開始日と期限を与えていく。こうして分解に集中する時間と、日程を組む時間を物理的に分けると、失敗②の「日付に分解を合わせにいく」が起きにくくなります。頭のモードが、分解のときは「この仕事の構造は？」、日程のときは「これをいつやる？」と切り替わって、どちらも雑になりにくい。
日付を入れた瞬間に、同じ構造がガントとして時間軸に並び、そこで初めて「この期間に詰め込みすぎだ」という無理が見える。分解が先、日付が後、ガントは結果。この順番を守るだけで、計画はずいぶん歪みにくくなります。ガントを引くのがうまくいかないと感じているなら、たいてい問題はガントではなく、その手前の分解にあります。
関連記事
LayerClock では、4 階層 WBS で分解した構造が、そのままガントチャートのビューになります。 先に「何を」を木で分解し、あとから「いつ」を与えるとカレンダーに並ぶ――この順番を一つの構造で守れる使い方を無料から試せます。