ガントチャートは、美しさより『崩壊したときの直しやすさ』で選ぶ

プロジェクトの立ち上げ時に丁寧に作ったガントチャート、2週間後にどうなっているか。

きれいに色分けされたバーが並んでいたはずが、空白のセルが増えて、コメントが「要確認」だらけになって、そこだけ見るとまるで別のプロジェクトみたいな状態になっている。「私が作ったんだっけ」という気持ちになるやつです。笑えないのは、これがほぼ毎回起きていることで、作り方の問題というよりスケジュールが崩れること自体は避けられないのに、崩れたあとの直しにくさを最初から考えていなかったことが問題だった、と気づくまでに少し時間がかかりました。

若手のころ、「きれいなガントチャート」を作ることが仕事だと思っていた

ディレクターとして最初にプロジェクト管理を任されたとき、ガントチャートの作り方を先輩に教わって、まず感じたのは「これ、きれいに作らないといけない」という感覚でした。

タスクの行に色をつけて、担当者ごとに色分けして、進捗に応じてバーの長さが変わるようにして。フォントを揃えて、セルの幅を調整して、完成したものをクライアントやチームに共有したとき、「わかりやすいですね」と言われるのがうれしかった。

でも、スケジュールが1週間ずれると、その色分けされた美しい表が急に更新しにくくなる。バーのセルを動かすと条件付き書式が崩れたり、担当者の色が想定通りに反映されなかったりして、直すのが面倒になってしまう。

「直すのが面倒」になると、更新頻度が下がります。更新頻度が下がると、ガントチャートの情報が実態と乖離し始める。乖離し始めると、誰も信用しなくなる。誰も信用しなくなったガントチャートは、存在しているのに機能していない、という一番困った状態になる。

「きれいなガントチャートを作ること」と「機能するガントチャートを維持すること」は、意外と相反することがあります。それを知るまでの間、私は前者だけを追いかけていた気がします。

WBSとガントチャートの関係をここで整理する

少し話を広げますが、ガントチャートをうまく使うために知っておくといい概念として、WBSがあります。

WBS（Work Breakdown Structure） は、プロジェクトの全体作業を段階的に分解して、管理可能な単位まで細かくしたものです。「作業分解構造」と訳されます。プロジェクト全体を大きなカテゴリから小さなタスクまで階層化して一覧にしたもので、ガントチャートの「行に並ぶタスク」の一覧は、本来このWBSを元に作られます。

よく混同されるのが「WBS＝ガントチャート」という認識です。 WBSはタスクの一覧・構造の整理、ガントチャートはそれぞれのタスクのスケジュールを時間軸に乗せた可視化ツール、という違いがあります。WBSを先に作らずにガントチャートだけ作ると、後からタスクの抜けに気づいたり、粒度がバラバラで管理しにくくなったりします。

使いどころとして現場で重要なのは、「WBSを先に作ってからガントチャートを引く」という順序です。 この順序を守るだけで、ガントチャートの構造が整理されやすくなる。タスクの親子関係が明確になっているWBSを元にしていると、スケジュールが崩れたときも「このフェーズをまるごとずらす」という操作がしやすくなります。WBSなしにガントチャートを作ると、後の修正で行を追加するたびに全体のバランスが崩れる、という状態になりやすい。

話を少し砕いて言うと、WBSはガントチャートの「骨格」です。骨格がしっかりしていれば、表の見た目が多少シンプルでも、修正に強い構造になる。

崩壊したときの話をします

実際にガントチャートが「機能しない状態」になった経験を、もう少し具体的に書いておきます。

ある中規模のサイトリニューアル案件で、最初にきれいなガントチャートを作りました。Googleスプレッドシートで、フェーズごとに色分けして、チェックボックスを入れて進捗が視覚的にわかるようにして。スプレッドシートの関数をいくつか使って、チェックが入ると自動でバーの色が変わるようにもした。それなりに時間をかけて作った自信作でした。

プロジェクトが始まってしばらくは問題なかったのですが、クライアントの事情で要件が途中で変更になり、タスクを2つ追加して1つ削除して、スケジュールを1週間全体的にずらすことになりました。

このとき、自動化していた部分が逆に足を引っ張った。チェックボックスと連動していた関数が、行を追加したことでズレてしまった。色分けの条件付き書式が、削除した行の影響で想定外の動きをした。直そうとすればできるのですが、「この関数、どう動いてたんだっけ」という状態になってしまい、修正に余計な時間がかかった。

結果として、「自動化の仕組みを外して、手動で管理できるシンプルな表に作り直す」という判断をしました。作り直しに使った時間は、最初にシンプルに作っていれば必要なかった時間です。

この経験から、「最初から直しやすい前提で作る」という考え方が自分の中に定着しました。

「直しやすいガントチャート」の条件

では、直しやすいガントチャートとはどういうものか。私が今持っている基準を3つ挙げます。

1. 自動化しすぎない

条件付き書式や関数での自動化は便利ですが、行を追加・削除・移動したときに崩れやすい。特に、何段階もネストした関数は、後から触ると挙動を把握するのに時間がかかります。「手で塗り替えるのが手間」という気持ちはわかりますが、直しやすさを取るなら手動で管理できる範囲に留める方が安定します。

2. タスクの粒度を揃える

粒度がバラバラだと、スケジュールがずれたときに「どこから直せばいいか」が見えにくくなります。「デザイン確認」という大きな括りと「バナーAのサイズ調整」という細かいタスクが同じ階層に並んでいると、全体像が把握しにくい。WBSで整理した粒度をガントチャートに反映させると、この問題が減ります。

3. 「フェーズ単位で動かせる」構造にする

スケジュールが崩れるとき、たいてい「このフェーズ全体が1週間ずれた」という動き方をします。そのとき「フェーズをまるごとずらせる」構造になっていると、修正が早い。タスクが細かくなりすぎていたり、フェーズの境界が曖昧だったりすると、1週間ずらすのに全行を手動で修正する必要が出てくる。

この3つを意識すると、見た目はシンプルになります。カラフルじゃなくなるし、自動で動く部分が減るから「地味なガントチャート」に見えるかもしれない。でもそのシンプルさが、崩れたときの直しやすさに直結しています。

ツール選択も「直しやすさ」で決める

ガントチャートを作るツールは、Excelやスプレッドシート、Asana、Notion、Backlog、その他プロジェクト管理ツールといろいろあります。どれが正解という話ではなくて、「崩れたときに直しやすいか」という観点でツールを選ぶ、という視点を持っておくといいと思っています。

私がスプレッドシートを今でもメインで使っているのは、「どこでも開ける・誰でも触れる・壊れにくい」からです。専用ツールの方が機能は豊富だし、見た目も整っている場合がある。でも、急いで修正が必要なとき、使い慣れていないチームメンバーでも触れる、という汎用性はスプレッドシートの強みです。

チームの状況によっては専用ツールの方が合う場合もあるので、「スプレッドシートが正解」という話ではないですが、ツール選択の判断軸として「崩壊したときにどう直すか」を最初から考えておくことが大事です。

ガントチャートは「更新され続けるもの」

最初に作ったガントチャートが最後まで完璧に機能することは、ほぼないと思っています。スケジュールは変わるし、タスクは増えるし、担当者が変わることもある。それが現場の実態です。

だとすれば、ガントチャートの評価基準は「最初の見た目の美しさ」より「変化に耐えてどれだけ更新され続けられるか」にある。崩れにくいことより、崩れたときに直しやすいことの方が、長期プロジェクトではずっと重要です。

シンプルで地味でも、毎週ちゃんと更新されているガントチャートの方が、美しくても誰も触っていないガントチャートより、プロジェクトに貢献しています。そういう表を作れるかどうかが、ディレクターのプロジェクト管理の質を決めると思っています。