ガントチャートの作り方｜作業を並べる前に決めておく4つのこと
ガントチャートの作り方を調べている人の多くは、線の引き方そのものが分からないわけではありません。棒を横に並べる、開始日と終了日を入れる、依存する作業を後ろにずらす。手順としてはそれだけです。それなのに、引いた工程表が2週間もしないうちに実態と合わなくなり、誰も開かなくなる。この記事が扱うのは、その手前の話です。作業を並べる前に決めておくことが4つあります。誰に見せる工程表なのか、どの粒度で割るのか、動かせる日と動かせない日をどう区別するのか、余裕をどこに置くのか。この4つを決めずに引いた工程表は、引いた瞬間から崩れ始めます。逆に言えば、この4つさえ先に決めておけば、道具が表計算ソフトであっても専用のツールであっても、工程表は最後まで生き残ります。
工程表が続かない原因は、線の引き方より前の段階にある
ガントチャートという形式そのものは、100年以上にわたって使われてきた古い道具です。横軸に時間、縦軸に作業を置き、期間を棒で表す。この形が今も残っているのは、進行の全体像を一目で共有できる形式が他にほとんど無いからです。会議の口頭説明でも、箇条書きの一覧でも、「いま全体のどこにいるか」は伝わりません。
一方で、工程表を作ったチームが必ずぶつかるのが更新の問題です。よく聞くのは、初回だけは丁寧に引いたものの、実作業が始まって数日で予定と実績がずれ、直すのが面倒になり、そのまま放置されるという流れです。放置された工程表は、単に役に立たないだけでは済みません。古い予定が残っていることで、見た人が誤った前提で判断してしまいます。更新されない工程表は、無い状態より悪くなります。
なぜ更新が止まるのか。原因は大きく2つに分かれます。ひとつは物理的な手間です。表計算ソフトで作った工程表は、作業がひとつ後ろにずれると、その先の棒をすべて引き直すことになります。行が80行を超えたあたりから、この引き直しは目視と手作業では追いきれません。もうひとつは、そもそもの設計が更新に耐えない形になっていることです。誰に見せるか決めずに作った表は、細かすぎたり粗すぎたりして、更新する意味が本人にとって薄い。意味の薄い作業は続きません。
道具を替えれば前者はかなり軽くなります。後者は道具では解決しません。作る前の設計の問題だからです。5人から数十人のチームで工程を預かっている人が最初にやるべきなのは、道具の比較ではなく、これから引く工程表の性格を4つの観点で確定させることです。
現場でしばしば起きるのは、道具を入れ替えたのに同じ場所で詰まる、という状況です。前の道具で更新されなかった工程表は、新しい道具に移しても同じ理由で更新されなくなります。移すべきなのは表ではなく、決めごとです。
決めておくこと1・この工程表は誰に見せるのか
最初に決めるのは読み手です。ここを曖昧にしたまま作ると、あとから来る全ての判断がぶれます。粒度も、余裕の置き方も、更新の頻度も、読み手が誰かで変わるからです。
工程表の読み手は、実務上おおむね3種類に分かれます。社外の発注元や顧客、社内で進行を合わせる関係者、そして実際に手を動かす担当者本人です。この3者は、同じ工程表を見ても求めているものが違います。
社外に出す工程表
発注元や顧客が工程表に求めるのは、納品物がいつ手元に来るか、その前に自分たちが何をいつまでにやればいいかの2点だけです。内部の作業分担や、途中の細かい手順には関心がありません。むしろ細かく出すと不都合が起きます。内部の1作業が遅れただけで「予定と違う」という指摘が入り、説明のための時間が発生します。
社外向けの工程表は、大きな区切りと、相手にお願いする日だけを載せます。素材の支給日、確認と戻しの期限、検収の期間。この3つが相手の欄に入っていれば、工程表としての役目は果たします。棒の数は多くても15本程度に収めると読めます。
社内で進行を合わせる工程表
進行担当や他部署の関係者が見るのは、自分の担当がいつ始まっていつ終わるか、その前後に誰がいるかです。ここでは担当者名と受け渡しの日が要ります。誰から誰へ、何が渡るのか。この受け渡しの線が見えていないと、待ちが発生していることに誰も気づきません。
社内向けは社外向けより細かくなりますが、それでも作業の1つ1つを全部載せる必要はありません。受け渡しが発生する単位まで割れば足ります。
作業する本人が見る工程表
担当者本人が見るのは、自分の今週と来週です。全体の棒よりも、自分の手元にある作業の順番と期限のほうが重要になります。ここまでの粒度を全体の工程表に持ち込むと、行数が一気に増えます。
多くのチームで機能しているのは、全体の工程表と手元の作業リストを分けておく形です。全体の工程表には受け渡し単位の棒だけを置き、その下にぶら下がる細かい作業はカードや一覧で管理する。ボード型のタスク管理ツールが工程表と併用されているのは、この2階建てが実務に合うからです。ボードで日々の作業を動かし、その動きが工程表側にも反映されれば、更新の二度手間が消えます。ボードと工程表の関係についてはできることのページで、どこまでを1つの板の上で扱う設計にしているかが整理されています。
1枚で3者を兼ねようとしたときに起きること
一番よくない結果になるのが、1枚で全部を兼ねようとした工程表です。社外に出せる粗さと、担当者が使える細かさは両立しません。兼ねようとすると、たいてい細かいほうに寄ります。行数が増え、社外の人は読まなくなり、更新の負担だけが残ります。
読み手を決めるというのは、載せないものを決めることでもあります。誰に見せるかを先に1つに絞り、必要なら別の粒度の表をもう1枚作る。この判断を最初にしておくだけで、後の作業量が大きく変わります。
決めておくこと2・どの粒度で割るか
読み手が決まったら、次は棒1本をどのくらいの大きさにするかを決めます。ここが工程表の寿命を最も大きく左右します。
棒1本の長さの目安
実務でよく使われる目安は、棒1本が3日から10日に収まる範囲です。この幅には理由があります。工程表を更新する頻度と釣り合うからです。週に1回更新する運用なら、1本の作業が1週間前後で終わる粒度になっていれば、更新のたびに何本かが「終わった」に変わります。進んでいる感覚が出て、更新する意味が生まれます。
逆に、更新の頻度と粒度が合っていないと、更新作業が空振りします。毎週見ているのに1か月間ずっと同じ棒が「進行中」のままなら、更新している人は「見なくても同じ」と判断します。
細かく割りすぎたときに起きること
割りすぎの工程表は、初回の作成コストが跳ね上がります。200行の工程表を引くのに数日かかり、引き終わった頃には前提が変わっている、という話は珍しくありません。
さらに悪いのは、細かい表ほど遅れが目立たない点です。1日単位の棒が並んでいると、1日の遅れが200か所で少しずつ発生します。それぞれは誤差に見えるので、誰も報告しません。積み上がって初めて、月末に「2週間遅れています」と分かります。
細かい作業を管理したい気持ちは正当ですが、それは工程表の仕事ではありません。日々の作業は作業リストの側に置き、工程表には受け渡しの単位だけを残します。
粗すぎるときに起きること
反対に、棒1本が1か月を超えると、進捗が測れなくなります。「制作」という棒が1本だけ引かれていて、期間が6週間ある。この棒に対して担当者が言えるのは「進んでいます」だけです。半分終わったのか、まだ入り口なのかが外から見えません。
粗い工程表の危険は、最後の週まで問題が表面化しないことです。締切の直前に「間に合いません」が出てくる工程表は、たいてい棒が粗すぎます。
粒度を決めるときの実務的な手順
粒度を決める手順は単純です。まず、全体を大きく区切ります。設計、制作、確認、納品といった段階です。次に、それぞれの段階の中で「別の人に何かを渡す瞬間」を探します。原稿を渡す、データを渡す、確認結果を返す。この受け渡しの前後で棒を切ります。最後に、切った結果が3日から10日の範囲に収まっているかを見て、長すぎるものだけをもう一段割ります。
この手順で割ると、棒の数は自然に決まります。全体で30本前後になるのが、5人から数十人のチームでよく見る規模です。この程度なら、1画面に近い形で見渡せます。
決めておくこと3・動かせる日と動かせない日を分ける
3つ目の決めごとが、日付の性格の区別です。工程表に並んだ日付は、見た目にはすべて同じ点に見えますが、実際には性格が3種類あります。ここを区別しないまま引いた工程表は、遅れが出たときに全体をどう組み直せばいいのか判断できません。
外から決まっている日
こちらの都合では1日も動かせない日です。契約で定めた納品日、イベントの開催日、法令や制度の施行日、先方の社内会議の日程。これらは工程表の中で固定の柱になります。
外から決まった日は、工程表の上で明確に区別できるようにします。色を変える、記号を付ける、行を分ける。方法は何でも構いませんが、見た人が一目で「ここは動かない」と分かる必要があります。区別が付いていないと、遅れが出たときに「じゃあ納品を1週間ずらしましょう」という、実際には不可能な案が会議に出てきます。
こちらの都合で決めた日
社内の確認会の日、担当者間の受け渡し日、中間レビューの日など、必要があれば動かせる日です。工程表の大部分はこちらに属します。
この区別が効くのは、遅れが出た瞬間です。どこかの作業が3日遅れたとき、後ろの日付を全部3日ずらす必要はありません。動かせる日だけを詰め、動かせない日は保ったまま、その間の作業を組み替えられないかを検討する。この判断が、区別を付けてある工程表なら数分で終わります。
前工程が終わらないと始まらない日
3つ目が依存関係で決まる日です。前の作業が終わらない限り着手できないため、日付そのものよりも「何が終わったら始まるか」が本体になります。
依存を書き込むときに気をつけたいのは、本当に依存しているのかを1本ずつ確認することです。工程表の上では順番に並べているだけで、実は同時に進められる作業がかなり混ざっています。よく聞くのは、依存を見直したら全体の期間が縮んだという話です。並べる前に「これは本当に前が終わるまで待つのか、それとも待つ習慣になっているだけか」を担当者に確認しておくと、工程表を引く時点で無駄な直列が消えます。
見分けをつける具体的な方法
3種類を区別する方法は、道具によって変わります。色分けができる道具なら色で分けるのが最も速いです。表計算ソフトなら、日付の列の横に「固定」「調整可」「依存」の1列を足すだけでも効果があります。重要なのは、区別が工程表の上に残っていることです。頭の中にしかない区別は、引いた本人が休んだ瞬間に失われます。
決めておくこと4・余裕をどこに置くか
4つ目が、余裕の置き方です。工程表の作り方で最も差が出るのがここで、そして最も雑に扱われるのもここです。
各作業に少しずつ盛るのが一番効かない
一般的にやられているのが、各作業に少しずつ余裕を盛る方法です。3日で終わる作業を4日と書く。これを全部の作業でやると、全体では相当な余裕が積み上がります。それなのに、この方法で引いた工程表はよく遅れます。
理由は2つあります。ひとつは、余裕を盛った期間が「その作業に許された期間」として扱われることです。4日と書いてあれば4日使われます。3日で終わっても、余った1日が次の作業の前倒しに使われることはほとんどありません。もうひとつは、余裕がどこにどれだけあるのか、工程表を見ても分からなくなることです。全体で何日の余裕があるのか誰も答えられない状態になります。
まとめて後ろに置く
より機能するのは、各作業からは余裕を抜き、まとめて工程の後ろに1本の枠として置く方法です。各作業は「順調にいけば終わる期間」で書き、遅れの吸収は共有の枠で行います。
この形にすると、余裕の残量が数字で見えます。10日の枠を置いていて、序盤で3日使ったなら残りは7日。この残量が、進行を預かる人にとって最も重要な指標になります。作業の進捗率より、余裕の残量のほうが早く危険を教えてくれます。
余裕の枠の大きさは、全体の期間や不確実さの度合いで変わりますが、実務では全体の15%から20%程度を目安にしているチームが多く見られます。初めて組む種類の仕事や、社外との受け渡しが多い工程では、この比率を上げます。
余裕を使ったら記録する
枠を置いただけでは足りません。使ったときに記録が要ります。いつ、どの作業のために、何日使ったか。この記録が残っていると、次の工程表を引くときの精度が上がります。毎回同じ工程で余裕が溶けているなら、その工程の見積もりが甘いということです。
記録は凝る必要がありません。工程表の脇に日付と作業名と日数を1行書くだけで足ります。手間を増やすと続きません。
人の残業で吸収する設計にしない
余裕の話で必ず出てくるのが、遅れを稼働時間で吸収するという発想です。工程表の上では期間が変わらないため、一見すると解決したように見えます。しかしこれは工程表の設計としては破綻しています。吸収できる量に上限があり、その上限は労務の制度で定められているからです。
時間外労働の上限は、原則として月45時間・年360時間となっています。 出典: mhlw.go.jp
具体的な適用の条件や例外の扱いは業種や契約の形態によって変わるため、実際の運用にあたっては所管の労働局や社会保険労務士など専門家への確認が必要です。工程表を引く側として押さえておくべきなのは、稼働時間は無限に伸ばせる調整弁ではない、という前提です。余裕は期間として工程表の上に確保しておくものであり、人の時間で後から作るものではありません。
業務委託の相手が混じる工程では、この前提はさらに重くなります。委託先の稼働は指示できる範囲が限られるため、遅れを相手の稼働で吸収する設計は成り立ちません。委託が絡む工程ほど、余裕の枠を明示的に置いておく必要があります。
4つを決めてから、はじめて線を引く
読み手、粒度、日付の性格、余裕の位置。この4つが決まったら、線を引く作業に入ります。手順としては次の順番が最も手戻りが少なくなります。
第1に、動かせない日を先に置きます。納品日、イベント日、先方の締切。ここが工程表の骨格です。逆算の起点になるため、必ず最初に置きます。
第2に、大きな段階を区切ります。設計、制作、確認、納品のような段階を、動かせない日の間に配置します。この時点ではまだ日数は概算で構いません。
第3に、受け渡しの単位で棒を割ります。決めておいた粒度に従って、各段階を3日から10日の棒に分解します。分解しながら、誰から誰へ何が渡るのかを1本ずつ確認します。
第4に、依存関係を引きます。本当に前が終わらないと始まらないものだけを繋ぎます。同時に進められるものは並べて置きます。
第5に、余裕の枠を置きます。各作業からは余裕を抜き、動かせない日の直前にまとまった枠を確保します。
第6に、担当者に見せて、期間の妥当性を確認します。ここで必ず出るのが「この期間では無理」という指摘です。この指摘を工程表に反映するかどうかが、その後の更新率を決めます。指摘を無視して引いた工程表は、担当者にとって他人の作った予定でしかなくなり、更新されなくなります。
この6つの手順を踏むと、工程表を引く作業そのものは半日から1日で終わります。時間がかかるのは決めごとのほうで、線を引く作業ではありません。
引き終わったあとに、更新の約束も同時に決めておきます。いつ、誰が、何を見て更新するのか。この約束が無い工程表は、引いた人の善意だけで維持されることになり、その人が忙しくなった時点で止まります。実務でよく機能しているのは、週の初めか終わりに15分だけ時間を取り、担当者それぞれが自分の棒の状態を更新する形です。全員で集まって口頭で報告し合う会議にすると1時間近くかかり、続きません。更新は各自が個別に行い、集まるのは食い違いが出たときだけにします。
もうひとつ決めておきたいのが、遅れの報告の基準です。「何日ずれたら報告するのか」を数字で決めておかないと、報告は担当者の感覚に委ねられます。感覚に委ねると、報告は遅れます。2日以上ずれたら工程表を直して一言添える、といった基準を先に共有しておくと、遅れは早い段階で表に出ます。早く出た遅れは余裕の枠で吸収できますが、遅く出た遅れは吸収できません。工程表の価値は、遅れを無くすことではなく、遅れを早く見えるようにすることにあります。
引いたあとに崩れる3つの場面
決めごとを固めて引いた工程表でも、進行の途中で崩れかける場面があります。あらかじめ想定しておくと、崩れる前に手を打てます。
途中で作業が増えたとき
最も多いのが、当初なかった作業が途中で追加される場面です。仕様の変更、追加の確認依頼、想定外の修正。これらは避けられません。
崩れるのは、追加された作業を工程表に書かずに進めたときです。実際には人が動いているのに工程表には出てこないので、遅れの理由が説明できなくなります。追加は必ず棒として工程表に足し、その分の期間を余裕の枠から引きます。枠から引くという処理をしておくと、追加が積み重なったときに「これ以上は受けられない」という判断が数字で示せます。
担当が変わったとき
途中で担当者が替わると、その人が持っていた前提が失われます。工程表の上に依存関係と受け渡しの内容が書かれていれば引き継ぎは短く済みますが、頭の中にしかない場合は再確認から始まります。
この場面に備える意味でも、依存関係と受け渡しの内容は工程表に書いておく価値があります。書いてある工程表は、そのまま引き継ぎ資料になります。
誰も更新しなくなったとき
3つ目が更新の停止です。前兆があります。会議で工程表が開かれなくなる、進捗の確認が口頭とチャットだけで行われるようになる、担当者が自分用の別の一覧を作り始める。この3つのどれかが見えたら、工程表の設計が実態と合っていません。
対処は、粒度を粗くする方向です。細かすぎて更新が追いつかないケースが大半のため、棒をまとめて数を減らします。更新する人の手間が減れば、更新は戻ります。工程表は正確さより、生きていることのほうが価値があります。
引き直しの手間をどこまで許容するか
4つの決めごとを固めても、更新の物理的な手間が重すぎると運用は続きません。ここで初めて道具の話になります。
表計算ソフトで工程表を作る利点は、誰でも開けることと、追加の費用がかからないことです。社外に出す粗い工程表であれば、表計算ソフトで十分に成立します。棒が15本程度で、更新も月に数回であれば、引き直しの手間は許容範囲に収まります。
手間が問題になるのは、棒の数が増え、更新の頻度が上がったときです。作業が1本ずれたら後続を全部ずらす、という作業を週に何度も行うことになると、更新は担当者1人の作業になり、その1人が忙しくなった瞬間に工程表は止まります。さらに、1人が引き直している間、他の人はその表を見られません。
専用の道具に移す判断をするなら、見るべきは機能の数ではなく、次の3点です。ひとつ、依存関係を持つ棒を動かしたとき、後続が自動で追随するか。ふたつ、担当者が自分の作業を自分で動かせるか。みっつ、その動きが全員に同時に見えるか。この3点が満たされていれば、更新は1人の仕事ではなくなります。
道具の候補を並べるときは、いま使っているものとの違いを軸で比べたほうが早く決まります。ボード型の道具からの移行を検討しているならTrelloとの比較が、作業の割り当てと期限の管理を中心に据えた道具との違いを見たいならAsanaとの比較が、文書とデータベースを同じ場所に置く道具との違いならNotionとの比較が、それぞれ判断の軸を整理しています。国内の開発現場でよく使われる道具との違いを見るならBacklogとの比較、ボードと工程表を併せ持つ国産の道具との違いならJootoとの比較、大きめの組織向けの道具との違いならmonday.comとの比較が参考になります。どこから見ればいいか決まっていない段階なら比較の一覧から入ると、比較の軸そのものが見えます。
費用の判断も同時に必要になります。工程表を見る人と入れる人の数が違う場合、人数の数え方が料金に直結します。課金の考え方は料金のページで確認できます。プランの内容は変わるため、実際の金額や上限は必ず公式のページで最新の内容を確かめてください。
移行の負担を心配する場合は、既存の板をどこまで自動で運べるかが判断材料になります。Trelloからの移行では、取り込みの対象と手順が説明されています。自動で取り込めるのはTrelloだけで、それ以外の道具からは手作業での移し替えになります。工程の情報を外部に置くことへの懸念があるなら、データの扱いについての考え方が安全性の考え方にまとまっています。導入前に出てくる細かい疑問はよくある質問にひととおり集められています。
工程表は「見る人」と「入れる人」が分かれた瞬間に嘘になる
工程表の作り方をめぐる話は、最終的に1点に収束します。誰が数字を入れるのか、という点です。
工程表が実態と合わなくなる過程を分解すると、ほぼ例外なく同じ形をしています。最初は進行担当が全員に状況を聞いて、自分で工程表に反映していました。人数が増え、作業が増え、聞いて回る時間が足りなくなります。聞けなかった分は推測で埋めるようになります。推測が積み重なり、工程表と実態がずれます。ずれに気づいた担当者が工程表を信用しなくなり、自分用の一覧を別に作ります。この時点で工程表は、見る人だけがいて、入れる人がいない状態になります。
入力する人が増えないと、進捗の表はすぐ嘘になります。逆に言えば、工程表を長く生かす条件は単純で、作業をしている本人が自分の分を動かせる状態を作ることです。そのために必要なのは、全員が同じ板を開けることと、開くのに躊躇が生まれないことです。
ここで効いてくるのが、道具の区切り方です。機能ごとにプランが分かれている道具では、工程表を見せたい相手に見せるために上位のプランを選ぶ判断が必要になります。結果として、閲覧だけの人を招くかどうかで迷いが生まれ、招かれなかった人は工程表から外れます。機能で絞らず、区切るのは人数とボードの数だけという設計であれば、この迷いは消えます。誰を招くかは進行の都合だけで決められ、機能の制限を理由に人を除く判断が不要になります。工程表に関わる人を減らさない、という一点において、この区切り方には意味があります。
一方で、道具にできないこともはっきりしています。ボードと工程表をひとつの場所にまとめる作りは、外部のサービスと細かく連携させる用途や、自動化の仕組みを組み上げる用途には向きません。開発のリポジトリと一体で扱いたい場合も、専用の道具のほうが適します。画面が日本語のみである点も、海外のメンバーが混じるチームでは制約になります。工程表の更新を軽くすることと、開発の周辺すべてを1つに集めることは別の目的です。前者だけを求めているのか、後者まで必要なのかを先に決めたほうが、道具選びは短く済みます。この線引きはできることで明示されています。
もうひとつ、道具では埋められない部分があります。この記事の前半で扱った4つの決めごとです。誰に見せるか、どの粒度で割るか、どの日が動かせないか、余裕をどこに置くか。これらはチームの事情に依存する判断であり、どの道具を選んでも自分たちで決めるしかありません。決めごとが定まっていない状態で道具を替えると、更新されない工程表が場所を変えて再生産されます。
順番としては、決めごとを先に固め、その運用に合う道具を後から選ぶ形になります。決めごとは紙1枚に書けます。読み手を1つに絞り、棒1本を3日から10日に収め、動かせない日に印を付け、余裕を後ろにまとめて置く。この4行をチームで共有してから線を引くと、工程表は最初の1か月を越えて生き残ります。越えた工程表は、進行を預かる人にとって、状況を説明するための最も速い資料になります。
Q1. ガントチャートは表計算ソフトで作っても問題ありませんか？
棒が15本程度で、更新が月に数回であれば表計算ソフトで十分に成立します。問題になるのは棒の数が増え、週に何度も引き直しが発生する場合です。1本ずれるたびに後続をすべて手で動かす作業が発生し、更新が1人の担当者に固定されます。その状態になったら道具の見直しを検討してください。
Q2. 棒1本はどのくらいの期間で区切るのが適切ですか？
3日から10日に収まる範囲が目安です。更新の頻度と釣り合うためで、週1回の更新なら1週間前後の棒が適します。1日単位まで割ると初回の作成に数日かかり、遅れが分散して見えなくなります。逆に1か月を超えると進捗が測れず、締切直前まで問題が表面化しません。
Q3. 工程表に入れる余裕はどのくらい見ておけばよいですか？
全体の期間の15%から20%を目安に、各作業に少しずつ盛るのではなく、まとめて後ろに1本の枠として置く形が機能します。各作業に盛ると許された期間として使い切られ、残量も分からなくなります。まとめて置けば残り日数が数字で見え、進捗率より早く危険を教えてくれます。
Q4. 引いた工程表が更新されなくなったときはどうすればよいですか？
まず粒度を粗くして棒の数を減らしてください。更新が止まる原因の大半は細かすぎて手間が追いつかないことです。あわせて、作業をしている本人が自分の分を動かせる状態になっているかを確認します。進行担当が全員に聞いて回って入力する形は、人数が増えた時点で必ず破綻します。