ガントチャートが更新されない理由｜引く人と動かす人が別だから
ガントチャートが更新されない。作った初日はきれいに線が並んでいたのに、1か月後に開いたら日付が全部過去のままだった。進行をとりまとめる立場の人からは、この話が繰り返し出てきます。そして多くの場合、次に打たれる手は「更新してくださいと全員に言う」ことです。それでは直りません。更新が止まるのは、誰かが怠けているからではなく、線を引く人と実際に作業を動かす人が分かれているという構造そのものが原因だからです。
この記事では、工程表の更新が止まるまでにチームの中で何が起きているのかを分解し、催促に頼らずに直すための手立てを段階で示します。読み終えたときに、いま使っている道具のどこで詰まっているのかを見極めて、次に何を変えるかを自分で決められる状態を目指します。
工程表が更新されない現象は、根性の問題ではない
工程表の更新が止まる話は、業種にもチームの規模にも関係なく出てきます。ソフトウェア開発でも、制作会社の案件進行でも、社内の業務改善プロジェクトでも、同じ形で起こります。共通しているのは、工程表を作った人と、そこに書かれたタスクを実際に手で動かす人が別だという点です。ここが同じ人であるうちは、工程表はほぼ確実に更新されます。自分が動いた結果を自分で書き込むだけだからです。
規模が小さいうちは、この分離が起きません。3人のチームなら、進行を見ている人が自分でも手を動かしているので、表と現実がずれる余地が小さいのです。ずれが出始めるのは、5人を超えたあたりからです。とりまとめる役の人が調整と確認に時間を取られて実作業から離れ、工程表は「その人が管理する資料」に変わります。この瞬間に、更新は誰かの追加業務になります。
追加業務になったものは、忙しくなると真っ先に落ちます。ここで起きているのは意志の欠落ではなく、優先順位の合理的な判断です。締切が迫っているときに、作業を進めるのと、作業の進み具合を表に書き写すのと、どちらを選ぶか。動かす側の人はほぼ全員が前者を選びます。そして、それは間違っていません。工程表を更新しても納品物は1ミリも進まないからです。
「見える化」が「書き写し」に変わる境目
工程表は本来、先の見通しを立てるための道具です。どの作業がどの作業を待っているのか、どこが同時に走るのか、誰の手が空くのはいつかを見るために線を引きます。ところが運用が始まると、多くの現場でこれが「終わった作業に印を付ける作業」に変わっていきます。見通しを立てる道具から、実績を書き写す帳簿になるわけです。
書き写しになった瞬間、その表は動かす人にとって二重入力になります。作業そのものはチャットや課題管理の画面、あるいは手元のメモの上で進んでいて、工程表はそれを転記する場所でしかない。人は同じ情報を2か所に書くことを続けられません。どちらか片方が必ず腐ります。そして腐るのは、作業が進まない方、つまり工程表の方です。
情報の鮮度は、更新の手間に反比例する
工程の遅れは、遅れが発生した瞬間ではなく、その遅れが誰の目にも入らないまま過ぎた期間の長さで被害が決まります。1日で共有された遅れは調整で吸収できますが、2週間気づかれなかった遅れは、後工程の人の予定をまとめて壊します。だからこそ、更新にかかる手間を下げることは、そのまま被害を小さくすることに直結します。
計画と実績の差を早いうちに拾うことの重要性については、公的な調査でも繰り返し指摘されています。情報処理推進機構が公開している開発データの分析資料でも、次のような趣旨のことが述べられています。
開発の実績データを継続的に収集し、計画との差異を早い段階で把握できる状態を作ることが、見積りと進捗管理の精度を高める土台になる。 出典: ipa.go.jp
ここで言われている「継続的に収集」ができるかどうかが、工程表が生きるか死ぬかの分かれ目です。収集の手間が大きいと継続しません。継続しない実績データは、無いのと同じです。
なぜ引く人と動かす人が分かれてしまうのか
分離は自然に起きます。誰かが悪いわけでも、体制の設計が下手なわけでもありません。次の3つが重なると、ほぼ必ずこの形になります。
工程表は設計図として生まれ、報告書として使われる
工程表が最初に作られるのは、たいてい案件が始まる前です。見積りを出すため、あるいは社内の承認を取るために、全体の流れと期間を一枚に描きます。この段階では読み手は発注側や上長で、書き手はとりまとめる人1人です。つまり、生まれたときの工程表は「外に見せる設計図」であって、チームで使う作業の道具ではありません。
案件が始まると、この同じファイルが今度は進捗報告に使い回されます。用途が設計図から報告書に変わったのに、書き手は最初のまま1人です。動かす人たちは、その表を作る過程に一度も関わっていません。自分が書いていない表を、自分の作業に合わせて直そうという気持ちは自然には湧きません。ここが最初のねじれです。
さらに、報告書として使われる表は、外向きの体裁を保つ必要が出てきます。線がガタガタだと見栄えが悪い、遅れが赤く並ぶと説明が要る。そうなると、とりまとめる人が体裁を整えるために表を握り続けます。握れば握るほど、他の人は触らなくなります。
引く技能と動かす技能が別物になっている
工程表を引くという行為には、それ自体に技能が要ります。どの作業が前提でどれが後続か、並行してよいのはどこか、バッファをどこに置くか。これは全体を俯瞰できる立場でないと判断できません。一方、動かす人が持っているのは、自分の担当範囲についての細かい現実です。あと半日で終わるのか、実は前提の資料が届いていないのか。
この2つの情報は、どちらも正しく、どちらも欠かせません。にもかかわらず、多くの道具では、この2種類の情報を書き込む場所が同じ画面になっています。全体の依存関係を触れる画面に、担当者を放り込むわけです。すると担当者は、自分の作業を1日ずらすだけのつもりで、後続の線をまとめて壊してしまうことを恐れます。恐れる人は触りません。触らないから、また1人が背負います。
表計算ソフトで組んだ工程表では、これが特に強く出ます。列が日付、行がタスク、セルの色で期間を表す形にすると、1行ずらすだけで数式や条件付き書式が崩れることがあります。壊した人が責められる空気が一度でもできると、その表は完全に1人のものになります。
更新の単位が、作業の単位と合っていない
工程表の行は、たいてい大きな単位で書かれます。「設計」「実装」「レビュー」「納品」のような粒度です。ところが動かす人が日々扱っているのは、もっと細かい単位です。「この画面の文言を確認する」「先方の返事を待つ」「テストデータを作る」といった単位で1日が進みます。
粒度が違うと、更新のしようがありません。「実装」の行に対して、いま何パーセント進んだかを聞かれても、正直に答えられる人はほとんどいません。だから多くの現場では、更新のたびに勘で数字が入ります。勘で入った数字が並んだ表は、見る側も信じなくなります。信じられていない表を、時間を使って更新し続ける人はいません。
ここには順番があります。まず粒度が合わなくなり、次に数字が嘘になり、最後に誰も見なくなる。更新が止まるのは最後の症状であって、原因はもっと前にあります。
更新が止まるまでの典型的な道筋
現場でしばしば語られる流れを、時系列で並べます。自分のチームがどこにいるかを当てはめてみると、次に打つ手が変わります。
最初の1週間はきれいな線が並ぶ
案件が始まった直後は、工程表がいちばん美しい状態です。全員が見に来ますし、キックオフの場で画面に映して説明もされます。この時点では、表と現実は一致しています。まだ何も起きていないからです。
この時期に見落とされがちなのが、「この表を誰がどうやって更新するか」を決めていないことです。作った人は当然のように自分が更新するつもりでいて、他の人は誰かが更新してくれると思っています。更新の担い手についての合意がないまま運用が始まります。
2週目から3週目にずれが出るが、直すのは1人だけ
最初のずれは小さなものです。前提資料の到着が2日遅れた、レビュー担当が別件で埋まっていた、といった程度です。動かす人はそれをチャットで報告します。報告は口頭やチャットで済むので、工程表には反映されません。
とりまとめる人がそれを拾って、自分で線を引き直します。ここで、更新は完全に1人の作業として固定されます。チャットに流れてくる断片を集めて、表に転記する係が生まれるわけです。この時点ではまだ表は正しいので、問題として認識されません。むしろ「ちゃんと管理できている」と見えます。
1か月後、会議の直前だけ直る表になる
転記係が続かなくなるのは、たいてい1か月前後です。案件が中盤に入り、とりまとめる人自身が調整や交渉で埋まり始めます。すると更新は、定例会議の前日にまとめて行われるようになります。週1回の会議のために、1週間分のずれをまとめて反映する作業が発生します。
この状態の工程表には、独特の性質があります。会議の直前だけ正しく、それ以外の日はずれている。つまり、日常の判断には使えません。誰かが「あの作業いつ終わる予定だっけ」と見に来ても、そこにある日付は先週のものです。一度そういう体験をした人は、次からは表を見ずに直接チャットで聞きます。表が使われなくなる決定打はここです。
数か月後、誰も開かない資料になる
最後は静かに終わります。誰かが「もう更新やめませんか」と言うわけではありません。ただ、開かれる回数が減り、会議でも画面に映されなくなり、話は口頭とチャットで進むようになります。ファイルはサーバーに残ったまま、日付だけが数か月前で止まります。
そして次の案件が始まるとき、また新しい工程表がゼロから引かれます。同じ道筋をもう一度たどることになります。多くのチームがこの循環を繰り返しているのは、原因を「今回はたまたま忙しかったから」と個別の事情に帰しているからです。構造が同じである限り、忙しさは毎回訪れます。
催促しても直らない理由
更新が止まったときに最初に出てくる案が、担当者への催促です。会議の場で「各自更新をお願いします」と伝える、リマインダーを設定する、更新率を管理指標にする。どれも効きません。理由は3つあります。
催促は更新にかかる手間を1ミリも下げない
人がある行動を続けるかどうかは、その行動にかかる手間と、そこから得られるものの釣り合いで決まります。催促は、この釣り合いのどちらにも触っていません。手間はそのまま、得られるものもそのままで、ただ「やらないと怒られる」という項目が増えるだけです。
短期的には効きます。言われた直後の1週間は更新率が上がります。しかし手間が変わっていないので、忙しさが戻ると同じ場所に落ちます。そして2度目の催促は1度目より効きません。効かない手を繰り返すと、とりまとめる人自身が疲弊します。
手を打つべきは手間の側です。工程表を開いて、行を探して、日付のセルを直して、依存関係が崩れていないか確認して、保存して閉じる。この一連の動作が3分かかるなら、それを10秒にする方法を探す方が、催促を10回繰り返すより確実です。
責める場になった表には、悪い情報が集まらない
工程表の更新を管理指標にすると、多くの場合、表の役割が変わります。進行を見る道具から、遅れている人を特定する道具になります。この変化は、書き込まれる情報の質を決定的に下げます。
遅れを書けば説明を求められる。それなら「順調」と書いておいて、追い込みで巻き返そう。この判断が積み重なると、表の上では全部が順調で、期限の直前に一斉に破綻するという最悪の形になります。進行をとりまとめる立場から見て、いちばん困るのは遅れそのものではなく、遅れを知るのが遅いことです。
だから、更新を評価に結びつけないという運用上の割り切りが要ります。遅れが書き込まれたときに最初にやることは、原因を聞くことではなく、後工程への影響を調べて調整することです。書いてよかったと思える経験が何回か積まれてはじめて、悪い情報が上がってくるようになります。
更新の主導権が1人にあると、待ち行列ができる
工程表のファイルを1人が握っている状態では、他の人が直したいと思っても直せません。表計算ソフトの共有ファイルでよくあるのが、誰かが開いていると読み取り専用になる、あるいは同時に編集すると片方の変更が消えるという事態です。1人が線を引き直している間、他の人はその表を触れません。
これは道具の制約に見えて、実際には情報の流れの詰まりです。動かす人が持っている最新の現実が、とりまとめる人という1本の管を通らないと表に届かない。管が詰まれば全部止まります。とりまとめる人が体調を崩したり、別案件に入ったりした瞬間に、工程表は完全に凍結します。
更新が止まる構造を、段階で直す
一度に全部を変えようとすると失敗します。道具を入れ替えても、粒度が合っていなければ同じことが起きます。順番があります。
段階1として、工程表で管理するものを削る
最初にやるのは、増やすことではなく減らすことです。いまの工程表に並んでいる行を全部見て、「これが遅れたら、他の誰かの予定が動くか」を1行ずつ問います。答えが「動かない」なら、その行は工程表から外します。
工程表が担うべきなのは、依存関係のある作業だけです。誰かの完了を待って始まるもの、期日が外部との約束で決まっているもの、複数人が同時に関わるもの。この3つに絞ると、たいていの工程表は行数が半分以下になります。残った行は、更新する価値が明確です。
外した作業は消えるわけではありません。個人のタスク一覧や、チームの作業板の側に移します。全部を1枚の工程表に載せようとすることが、更新を重くしている最大の原因です。全部載っている表は、全部が古くなります。
段階2として、更新の単位を作業する人の単位に合わせる
次に、残った行の粒度を見直します。「実装」のような大きな塊のままだと、進捗をパーセントで答えるしかなくなり、その数字は必ず嘘になります。行を、始まりと終わりが誰の目にも同じに見える単位まで割ります。
割る基準は、「終わったと言える瞬間が具体的に想像できるか」です。「設計」は想像できませんが、「画面遷移図を関係者に共有する」は想像できます。この単位まで割ると、進捗の入力はパーセントではなく「未着手」「進行中」「完了」の3択で足ります。3択なら、動かす人が数秒で答えられます。
割ることで行数は増えますが、更新の手間はむしろ下がります。パーセントを勘で決める判断が不要になるからです。そして3択で入った情報は嘘になりにくく、見る側も信じられます。
段階3として、入口を1つにして、線は結果として引かれるようにする
ここが構造を変える中心です。動かす人が作業の状態を書き込む場所と、工程表が線を引く元になるデータを、同じものにします。つまり、担当者は作業の板の上でカードを動かすだけで、その結果として工程表の線が動く形にします。
この形にすると、動かす人にとって工程表の更新という作業は消えます。自分の作業を進めるために当然やっていること、つまり「終わったカードを完了に動かす」だけで、とりまとめる人が見たい線が更新されます。二重入力が無くなるので、片方が腐るということも起きません。
とりまとめる人の側は、線を引き直す作業から、線を見て調整する作業に移ります。役割としては、これが本来の姿です。誰の手が空いたか、どこが詰まっているかを見て、順番を組み替える。転記係をやめて、判断する人に戻るわけです。
道具を選ぶときに、この「入口が1つになるか」は最も重要な条件です。工程表の画面と作業の板の画面が別々のデータを持っている道具では、どこかで必ず人が転記することになります。
段階4として、更新されていないこと自体を見えるようにする
入口を1つにしても、動かす人がカードを動かし忘れることはあります。ここで催促に戻らないために、更新が止まっていることを人ではなくデータの側で示す仕組みを入れます。
具体的には、最終更新からの経過日数を表示する、期日を過ぎているのに完了になっていないものを目立たせる、着手予定日を過ぎたまま未着手のものを別の場所に集める、といった見せ方です。とりまとめる人が全体を眺めたときに、「情報が古い場所」が一目で分かる状態を作ります。
この見せ方には副作用として、悪い情報を出しやすくする効果もあります。何もしていない状態が目立つのなら、「詰まっています」と書いた方が説明が楽になるからです。人を責める代わりに、情報の古さを可視化する。これが催促の代替になります。
道具を選び直すときに見るべきこと
段階1と段階2は、いまの道具のままでも進められます。段階3から先は、道具の作りに左右されます。選び直すときに確認する点を5つ挙げます。
動かす人が触る画面はどれか
まず、担当者が毎日開く画面を特定します。工程表の画面を全員が毎日開くという前提の道具は、たいてい定着しません。動かす人が見たいのは「自分がいま何をするか」であって、全体の線ではないからです。
自分の担当分だけが並ぶ一覧があり、そこで状態を変えられて、その結果が全体の線に反映される。この流れになっているかを見ます。カードを1枚動かすまでに何回クリックが要るかを、実際に触って数えると差が出ます。
同時に触れるか
工程表を1人が直している間、他の人が待たされる構造だと、段階3は実現しません。複数人が同時に別の場所を編集できること、そして誰かの変更が他の人の画面にすぐ反映されることが要ります。
ここは無料の試用期間中に、実際に2つの端末を並べて確かめるのが確実です。片方でカードを動かして、もう片方の画面が更新されるまでの体感を見ます。カタログの機能一覧では分からない部分です。
工程表と作業の板が同じデータか
道具によっては、工程表の表示と、作業の板の表示が別々の入力を必要とします。この場合、二重入力が残るので、更新は結局止まります。同じカードが、見る角度を変えると板にも線にも見える、という作りかどうかを確認します。
判定は簡単です。板の上でカードの期限を変えて、工程表の側の線がその場で動くかを試します。動かないなら、そこに人手の転記が挟まる設計です。各サービスの作りの違いについては、板と線の関係を軸に整理した比較の一覧にまとめてあります。
やめるときに持ち出せるか
道具を選ぶ場面では、入るときの話ばかりが検討されて、出るときの話が抜けがちです。工程表と作業の履歴は、案件が終わったあとも参照されます。契約が終わったときに、自分たちのデータをどの形式で持ち出せるかを、契約前に確認しておきます。
あわせて、いま使っている道具からの引き継ぎも見ます。手作業で入れ直すのか、書き出しと取り込みで移せるのかで、切り替えにかかる日数が変わります。取り込みの対応範囲は道具ごとに大きく違うので、公式の案内で確かめるのが確実です。既存の板をそのまま移す手順についてはTrelloからの移行で説明しています。ここは正直に書いておくと、自動で取り込めるのは限られた1つの道具からだけで、それ以外は書き出したデータを整えて入れ直す形になります。
値段のかかり方
料金は、金額そのものよりも「何で増えるか」を見ます。人数で増えるのか、案件やボードの数で増えるのか、機能ごとの上位プランで増えるのか。この3つのどれかによって、チームが増えたときの負担のしかたが変わります。
具体的な金額や上限は各社の公式ページで変わるので、比較記事の数字ではなく、必ず当日の公式ページで確認してください。掲載時点と現在で条件が違っていることは珍しくありません。板にまとめる考え方の道具の料金の考え方については料金に整理してあります。
板にまとめる考え方から見た、更新が続く条件
進行の道具をいくつも並べて観点ごとに整理してきた中で、更新が続くチームと止まるチームを分けている条件は、機能の多さではありませんでした。分かれ目は、動かす人が自分の作業を進めるためにやることと、とりまとめる人が見たい情報の更新が、同じ操作になっているかどうかです。
この観点で見ると、道具の分類は「機能が多いか少ないか」ではなく、「入口が1つか2つか」になります。板と線が同じデータを別の角度から見せているものは、担当者がカードを動かすだけで線が動きます。板と線が別の仕組みで、線の側に別途入力が要るものは、必ず転記係が生まれます。
板と工程表が同じカードを別の見え方で表しているだけという作りにしておくと、更新という独立した作業そのものが存在しなくなります。存在しない作業は、忙しくなっても落ちません。ここが、催促ではどうにもならない部分を構造で解く唯一の方法です。
いま使っている道具のままでよい場合
先に書いておくと、乗り換える理由が無い場合は多いです。カードを動かす文化が定着していて、工程の依存関係を厳密に見る必要がないチームなら、シンプルな板の道具のままで問題ありません。カードの並びと期限だけで進行が回っているなら、線を足すことがむしろ管理の手間を増やします。板の運用が中心のチームがどこで線を必要とし始めるかはTrelloとの比較で整理しています。
同じように、タスクの依存関係と担当の割り当てを細かく管理する運用がすでに回っていて、社内の他の業務システムとの連携が前提になっているなら、いまの道具を続ける方が合理的です。自動化や外部サービスとの連携を重視する場合の考え方はAsanaとの比較とmonday.comとの比較で扱っています。
文書とデータベースを一体で運用していて、工程表もその中の1ビューとして成立しているなら、そこを崩す必要はありません。文書中心の運用と板中心の運用の違いはNotionとの比較にまとめてあります。開発の課題管理と工程管理を同じ場所で回している場合の観点はBacklogとの比較で、国内向けの板型ツールとの違いはJootoとの比較で整理しています。
割り切っている点も先に書いておく
板にまとめる考え方の道具にも、できないことがあります。ソースコードを置く場所としての機能は持ちません。開発の課題と実装を同じ場所で完結させたい場合は、そこは別の道具が要ります。自動化や外部サービスとの連携でも勝負していません。多数の外部サービスと自動で情報をやり取りする運用が中心なら、その領域が強い道具を選ぶ方が結果は良くなります。
画面は日本語のみです。海外のメンバーが日常的に触るチームでは、この点が実務上の障壁になります。そして先に触れた通り、既存の板から自動で取り込めるのは限られた1つの道具からだけです。判断材料としてできることの範囲を確認したい場合はできることを、データの扱いと保管についての考え方は安全性の考え方を見てください。導入前に出やすい疑問はよくある質問にまとめています。
切り替えるかどうかの判断は、更新の回数で決める
最後に、判断の基準を1つに絞ります。いまの工程表が、直近1か月で何回更新されたか、そしてその更新を何人が行ったかを数えてください。この2つの数字で、いまの構造がどこにあるかがほぼ分かります。
更新が週1回以下で、更新した人が1人だけなら、すでに転記係の構造に入っています。段階1と段階2を先にやってから、道具を見直します。更新が週に何度もあり、複数人が触れているなら、構造は健全です。その場合に足りないのは道具ではなく、削っていない行の整理だけです。
数字を数えずに道具を替えると、同じ現象が新しい画面の上で再現します。工程表が更新されないという症状は、道具の問題であることもあれば、粒度と役割分担の問題であることもあります。どちらなのかを先に切り分けることが、次の一手を無駄にしないための最短の手順です。
Q1. 担当者に更新を依頼しても続きません。どう頼めばいいですか？
頼み方を変えるより、更新にかかる手間を下げる方が確実です。工程表の行を依存関係のあるものだけに絞り、進捗の入力を未着手と進行中と完了の3択にすると、数秒で終わる作業になります。作業の板でカードを動かせば線も動く形にできれば、更新という独立した作業自体が消えます。
Q2. 表計算ソフトの工程表のままでも直せますか？
行を削って粒度を揃える段階までは、表計算ソフトのままでも進められます。ただし複数人が同時に触れない、1人が編集中は他の人が待つ、という制約は残ります。更新が1人に集中している状態が続くなら、板と線が同じデータになっている道具への切り替えを検討する段階です。
Q3. 工程表の更新率を評価の指標にしてもいいですか？
おすすめしません。更新が評価に結びつくと、遅れを書くと不利になるため、表の上だけ順調という状態が生まれます。進行をとりまとめる立場で困るのは遅れそのものではなく、遅れを知るのが遅いことです。人を数えるかわりに、最終更新からの経過日数を表示して情報の古い場所を見えるようにする方が機能します。
Q4. 道具を選ぶとき、料金以外に何を確認すべきですか？
料金は何で増えるかの仕組みを見て、金額と上限は必ず当日の公式ページで確認してください。それ以外では、担当者が毎日開く画面がどれか、複数人が同時に編集できるか、板でカードを動かしたときに工程表の線がその場で動くか、契約終了時にデータを持ち出せるかの4点を、試用期間中に実際に触って確かめます。