ガントチャートの進捗率が嘘になる理由｜割合をやめて完了の数で見る
ガントチャートに進捗率の欄を作ったのに、そこに並ぶ数字が信用できない。会議で確認すると全部の作業が80%か90%で、それが何週間も動かない。進行をとりまとめる立場の人からは、この話が繰り返し出てきます。
原因は担当者が嘘をついていることではありません。進み具合を割合で書かせるという方法そのものが、嘘を生みやすい構造を持っているからです。この記事では、割合で書くと何が起きるのかを分解し、終わったかどうかだけで数える方法と、作業を細かく割って完了の数で見る方法を並べて比べます。読み終えたときに、いまの工程表のどこで数字が壊れているのかを見極めて、次に何を変えるかを自分で決められる状態を目指します。
工程表に進捗率の欄があるのは、誰の不安を消すためか
進捗率の欄は、たいてい誰かの不安から生まれます。とりまとめる側が「いま全体としてどのくらい進んでいるのか」を一言で言えるようにしたい。上位の報告先から「何%です」という形の答えを求められている。この2つが重なると、工程表の右側に進捗率の列が足されます。
ここで最初に確かめておくべきなのは、その数字を誰がいつ何のために見るのかです。用途によって、必要な精度も更新の頻度もまったく変わります。翌週の人の割り当てを決めるために見るのなら、必要なのは「この作業が今週中に終わるかどうか」の一点であり、それが60%なのか70%なのかは判断に一切影響しません。逆に、外部への報告資料に載せる数字なら、月に一度の集計で足りるのに、毎日更新させる運用になっていることがあります。
多くの現場で起きているのは、この用途の切り分けをしないまま、とりあえず進捗率という列を置いてしまうことです。列があれば埋めなければならず、埋めるためには数字を作らなければなりません。そして、作業を進めている本人にとって、自分の作業が何%進んだかを正確に答えることは、そもそも不可能に近い問いです。
進捗率が答えているのは、実は「あとどれくらいか」ではない
作業をしている人が「70%です」と答えるとき、その人の頭の中で計算されているのは、残りの作業量ではありません。使った時間の割合であったり、着手した部分の見た目の分量であったり、単に「そこそこ進んでいる感じ」を数字に置き換えたものであったりします。
残りの作業量を正確に見積もれるなら、そもそも工程の遅れは起きません。遅れが起きるのは、着手して初めて分かることがあるからです。仕様の確認漏れ、他部署の返答待ち、思っていたより複雑だった処理、修正が必要になった前工程の成果物。これらは着手前には見えていません。つまり進捗率は、まだ見えていないものを含んだ全体を分母にして計算されている数字であり、分母が動くたびに意味が変わります。
とりまとめる側が本当に知りたいことを言語化する
進行を預かる立場の人が知りたいのは、突き詰めると次の3つです。予定していた日に終わりそうか。終わらないとしたら、いつになるのか。誰かの手が止まっていないか。この3つに、進捗率の数字はほとんど答えていません。
「80%です」と言われても、来週終わるのか再来週になるのかは分かりません。一方で「レビュー待ちで止まっています」という一言は、この3つのうち2つに同時に答えています。数字の精度を上げる努力より、答えるべき問いを変える方が効きます。
割合で書いた瞬間に起きる4つのこと
割合による進捗管理には、それ自体に構造的な問題が組み込まれています。人の性格や真面目さでは打ち消せません。よく観察される順に並べます。
9割で止まる
もっとも有名な現象です。作業が90%まで一気に進み、そこから何週間も動かない。この現象はソフトウェア開発の世界では古くから知られていて、次のような言い回しで語られてきました。
最初の90パーセントのコードが、開発時間の最初の90パーセントを使う。残りの10パーセントのコードが、開発時間のもう90パーセントを使う。 出典: Tom Cargill（Bell Labs）による「90対90の法則」。Jon Bentley「Programming Pearls」1985年の記事で紹介されたもの
合計が180%になっているのは冗談ですが、指している中身は本当のことです。作業の後半には、確認、手直し、他の人との調整、細部の詰め、想定外の対応といった、見積もりに入りにくい仕事が集中します。前半で進むのは、量が多くて中身が単純な部分です。だから割合は前半で速く増え、後半で止まります。
この構造がある限り、90%という数字は「もうすぐ終わる」を意味しません。むしろ「これから一番読めない区間に入る」ことを意味している場合すらあります。とりまとめる側が90%を見て安心して人の配置を決めると、そこで計画が崩れます。
数字の作り方が人によって違う
同じ50%でも、意味は人ごとに違います。ある人は予定工数のうち使った時間の割合で答え、別の人は作るべき画面のうち着手した数で答え、また別の人は感覚で答えます。工程表の上ではどれも同じ50%という文字になります。
この違いは、数字を足し合わせたときに致命的になります。10個の作業の進捗率を平均して全体55%と出したとき、その55という数には、時間基準と分量基準と気分基準が混ざっています。混ざったものを平均しても、意味のある値にはなりません。
一度上げた数字は下げにくい
先週80%と書いた人が、今週60%に下げるのは、心理的にかなり難しいことです。前提が変わって作業量が増えたときや、手戻りが発生したときには、本来なら割合は下がるはずです。しかし報告の場では、下げた瞬間に説明を求められます。
そこで何が起きるかというと、数字を据え置いたまま止める、あるいは1%ずつ足すという行動です。よく聞くのは、3週間連続で85%と書かれ続けた行が、ある日いきなり完了になるという話です。この間、工程表は何の情報も持っていません。割合には「戻る」という考えが実質的に存在しないため、手戻りの情報が数字から消えてしまいます。
足し算しても全体にならない
作業ごとの進捗率を平均すると全体の進捗率が出る、というのは直感的ですが、実務ではほぼ成立しません。作業の大きさが違うからです。3日で終わる作業と30日かかる作業を同じ重みで平均すれば、全体像は歪みます。
重み付けをするなら、各作業の見積もり工数を掛けて計算することになります。ところがその見積もり工数自体が、着手後に変わっていく数字です。分母が動くものを重みにして加重平均を取ると、作業が進んでいるのに全体の割合が下がるという、報告しづらい現象が起きます。この計算を毎週やり直す手間も、とりまとめる人に丸ごとのしかかります。
進み具合の数え方は、大きく3つに分けられる
割合をやめるとして、では何で見るのか。実務で使われている数え方は、大きく3つに整理できます。それぞれの向き不向きを押さえると、自分のチームに合うものが選べます。
割合で申告する方法
各作業の担当者が、自分の感覚か何らかの基準で百分率を入力する方法です。表計算ソフトで工程表を作っている場合、この形が既定になっていることが多くあります。
利点は、報告資料の見た目が作りやすいことです。全体60%という一言は、社外や経営層への報告で受け入れられやすい形をしています。長期にわたる大きな作業を1行で扱いたい場合にも、行を割らずに済みます。
欠点は前章に書いた通りです。数字の意味が人によって違い、後半で止まり、下げられず、足し合わせられません。そして最大の問題は、この数字を作るために担当者が考える時間が発生することです。作業を進める代わりに、自分が何%進んだかを推定する時間を使わせている構造になります。
終わったかどうかだけで数える方法
進捗の状態を、未着手と進行中と完了の3つだけにする方法です。割合の欄そのものを廃止し、判断を二値に近づけます。全体の進み具合は「全40件のうち完了17件」という数え方で表します。
利点は、数字が壊れないことです。完了かどうかは基準を決めておけば誰が見ても同じ答えになり、人による解釈のぶれが消えます。入力も一瞬で終わるので、担当者に負担がかかりません。手戻りが発生したときは、完了から進行中に戻すだけで済みます。割合と違って、状態は自然に戻せます。
欠点は、大きな作業が長く進行中のままになることです。30日かかる作業が1行で置かれていると、その行は30日間ずっと進行中で、そこから何も分かりません。この欠点を打ち消すのが、次の方法です。
細かく割って、完了の数で見る方法
大きな作業を、それぞれが数日で終わる大きさに割り、割った1つ1つを完了か未完了かで扱う方法です。全体の進み具合は、完了した数を全体の数で割って表します。
この方法の本質は、割合を捨てているのではなく、割合の分母を「まだ見えていないものを含む作業量」から「数えられる項目の数」に置き換えている点にあります。分母が固定されるので、数字が意味を持ちます。項目を追加したときには分母が増えて全体の割合がいったん下がりますが、それは正しい動きです。作業が増えたという事実がそのまま数字に出ます。
さらに、この方法は90%で止まる現象を、止まったこととして可視化します。割った項目のうち最後の数個が終わらないなら、完了の数は増えません。増えないという事実が画面に出ることが重要です。割合の申告なら92、94、95と動いて、動いているように見えてしまいます。
欠点は、割る手間がかかることです。着手前にすべてを細かく割り切ることはできないので、直近2週間ぶんだけ割っておき、先の期間は大きな塊のまま置くという運用が要ります。この運用を回せるかどうかが、この方法を採れるかどうかの分かれ目です。
3つの方法を同じ表で比べる
| 見る観点 | 割合で申告 | 完了かどうかで数える | 細かく割って完了数で見る |
|---|---|---|---|
| 数字の作り方 | 担当者の推定 | 状態の選択 | 完了項目を数える |
| 人によるぶれ | 大きい | ほぼ無い | ほぼ無い |
| 入力にかかる時間 | 考える時間が要る | 数秒 | 数秒 |
| 90%で止まる現象 | 見えなくなる | 影響を受けない | 止まったことが見える |
| 手戻りの反映 | 下げにくい | 状態を戻せる | 項目を戻せる |
| 大きな作業の途中経過 | 一応出せる | 分からない | 分かる |
| 全体を足せるか | 足せない | 件数で足せる | 件数で足せる |
| 事前の準備 | ほぼ不要 | 完了の定義が要る | 分割と完了の定義が要る |
| 向いている場面 | 社外向けの報告 | 小さめのチーム | 数十人規模の進行管理 |
この表で注目してほしいのは、準備の欄です。割合による方法だけが事前準備をほとんど必要としません。だから最初に選ばれます。そして運用が始まってから、数字が信用できないという問題に全員が気づきます。準備の手間を先に払うか、後で信用できない数字を扱う手間を払い続けるかの選択になっています。
現場でしばしば見られるのは、この3つを場面ごとに使い分ける形です。チーム内の日々の進行は完了の数で見て、月次の対外報告のときだけ、完了数から割合を計算して出す。この使い分けなら、報告先が求める形式にも応えつつ、内部の数字は壊れずに済みます。重要なのは、割合を「入力する」のではなく「完了数から計算する」ことです。
細かく割るときの粒度をどう決めるか
分割は、細かすぎても粗すぎても機能しません。粒度の決め方には、いくつか使える基準があります。
目安は2日から5日で終わる大きさ
1つの項目が2日から5日で終わる大きさが、多くのチームで扱いやすい範囲です。この大きさなら、週に一度の確認で必ず何かが動いており、動いていなければそれ自体が止まっている合図になります。
1日未満の項目まで割ると、項目数が膨れて管理そのものが仕事になります。逆に10日を超える項目は、途中経過が分からない期間が長すぎます。判断に迷ったら、週次の確認で「先週から動いたかどうか」を見たときに、意味のある答えが出る大きさかを基準にしてください。
終わったと言い切れる形に割る
分割で失敗する典型は、作業の工程で割ってしまうことです。設計、実装、確認、という割り方をすると、それぞれが本当に終わったのかを判定できません。設計が終わったとは、何をもって言うのか。この問いに一言で答えられないなら、その割り方は使えません。
うまくいく割り方は、成果物や対象で割ることです。画面ごと、機能ごと、書類の章ごと、取引先ごと、といった単位なら、終わったかどうかが目に見えます。「申込画面の入力チェックまで動く状態にする」なら、動くか動かないかで判定できます。判定できる形に割ることが、完了の数で見る方法の前提条件です。
完了の定義を先に文字にしておく
割り方が決まっても、完了の意味がチーム内でずれていると数字は壊れます。ある人は自分の手が離れた時点を完了と呼び、別の人はレビューが通った時点を完了と呼びます。この差が積み重なると、全体の数字は実態より前に進みます。
完了の定義は、チームで1回だけ決めて、どこかに書いておけば足ります。書き方は短くて構いません。「レビュー担当者が確認済みと書き込んだ時点」「動作確認が終わって共有フォルダに置いた時点」といった、誰が見ても同じ答えになる書き方にします。この1行があるかどうかで、進捗の数字の信頼度が変わります。
割りすぎたときに起きること
分割は万能ではありません。項目が増えすぎると、更新の手間が積み上がり、結局は誰も触らなくなります。項目500件の板を毎日整える作業は、それ自体が1人分の仕事です。
現実的な運用は、先の期間を粗く、直近を細かくする形です。3か月先の作業は大きな塊のまま線を引いておき、着手が近づいた段階で割る。この段取りなら、割る手間が一度に来ません。工程表の上では、先の期間の塊が近づくにつれて複数行に分かれていくことになります。この形は、計画の精度が着手前には上がらないという事実とも整合しています。
割合をどうしても使わなければならない場面
報告先が割合の形式を求めていて、変えられない場合があります。その状況でも、数字の壊れ方を小さくする手はあります。
まず、担当者に割合を入力させないことです。割合は完了項目数から機械的に計算します。全40項目のうち17項目が完了なら42%と出す。この計算なら、人による解釈のぶれが入りません。分母が増えたときに割合が下がることは、報告の場で先に説明しておきます。「作業が増えたときは下がります」という前提を共有しておけば、下がった数字が非難の対象になりません。
次に、割合を刻まないことです。どうしても担当者に選ばせるなら、0%、50%、100%の3択にします。1%刻みで選ばせると、選ぶ側は精度の高い答えを求められていると感じて、考える時間を使ってしまいます。3択なら迷いません。そして50%が長く続いている行を探すだけで、止まっている場所が見つかります。
それから、割合の横に「その割合の根拠」を書く欄を1つ足すことです。書くのは一言で構いません。「画面8枚中4枚が動作確認まで完了」「原稿は書き終わり、確認待ち」といった内容です。この一言があるだけで、数字の意味が読み手に伝わります。とりまとめる側は、割合の数字ではなくこの一言を読んで判断することになります。実際のところ、根拠の欄を足した時点で、割合の数字はほとんど使われなくなります。それでも欄を残しておくのは、報告先が求めているのが割合の形式だからです。形式は残し、判断は根拠の一言で行う。この二重の運用は手間に見えますが、書く側の負担は数秒しか増えません。
最後に、割合と一緒に必ず「終わる見込み日」を置くことです。とりまとめる側が本当に必要としているのはこちらです。85%という数字より、「見込み日が先週から2回後ろにずれた」という情報の方が、次の判断に直結します。見込み日を動かした回数を残しておくと、どの作業が読めていないのかが後から分かります。
数字より先に壊れるのは、工程表そのもの
進捗率の運用を整えても、工程表自体が更新されなければ意味がありません。数え方の話の前に、更新が続く形になっているかを確かめる必要があります。
更新する場所が、仕事をする場所と離れている
作業はチャットや課題の一覧の上で進んでいて、工程表は別のファイルで管理されている。この状態だと、工程表の更新は転記作業になります。人は同じ情報を2か所に書き続けられません。必ずどちらかが腐ります。そして腐るのは、書かなくても仕事が進む方、つまり工程表の側です。
これを直す方向は1つしかありません。作業を動かす操作が、そのまま工程表の更新になる形にすることです。担当者が毎日開く画面でカードを次の列に動かしたら、工程表の線もその場で動く。この形なら、更新という独立した作業が消えます。進捗率の入力欄を作るより、この構造を作る方が先です。
引き直している間、ほかの人は見られない
表計算ソフトで工程表を管理していると、誰かが開いて編集している間、ほかの人はその表を見られないか、古い状態しか見られません。とりまとめる人が半日かけて線を引き直している間、チームの残り全員は先週の予定を見て動いていることになります。
この待ち時間は、チームの人数が増えるほど効きます。5人なら気づかない程度の摩擦ですが、20人になると、古い情報で動いた人の手戻りが目に見える量になります。進捗の数字を精緻にする前に、全員が同じ最新の表を同時に見られる状態になっているかを確かめてください。
入力する人が増えないと、表はすぐ嘘になる
進捗の数字を書き込む人が1人だけの状態は、その人が忙しくなった瞬間に情報が止まります。よく聞くのは、とりまとめ役が休んだ週に工程表が完全に止まり、復帰後に丸一日かけて実態を聞いて回るという話です。
書き込む人を増やすには、書き込みが軽い操作である必要があります。割合の入力は重い操作です。数字を考えなければならないからです。完了かどうかの切り替えは軽い操作です。だから、数え方を変えることは、そのまま入力する人を増やすことにつながります。この2つは別々の課題に見えて、同じ根を持っています。
週に一度、とりまとめる側がやること
数え方を整えたあと、運用として残るのは週に一度の確認です。手順を固定しておくと、時間が短くなります。
見るのは3点だけで足ります。1つ目は、先週から完了数が増えていない塊がどこかです。増えていない場所には、必ず理由があります。待ちなのか、想定外が出たのか、そもそも着手できていないのか。この3つのどれかを聞けば、次の手が決まります。
2つ目は、終わる見込み日が後ろにずれた行です。ずれた回数が多い行は、見積もりが読めていない領域を指しています。ここに人を足すか、範囲を削るかの判断が要ります。3つ目は、直近2週間ぶんの分割ができているかです。先の塊を割る作業を止めると、2週間後に数字が見えなくなります。
この確認を30分で終える形にしておくと、続きます。2時間かかる確認は、忙しい週に飛ばされ、飛ばされた週の情報は永久に欠けます。手順を短くすることは、精度を上げることより優先されます。
板の作りごとに、進捗の見え方はどう変わるか
道具を見直す段階に入ったときに確かめるべき点を、比較の観点として整理します。ここで大事なのは、いまの道具のままがよい場合を先に見極めることです。
工程表を引くこと自体が主目的で、担当者は基本的に見るだけという運用が回っているなら、いまの形を崩す必要はありません。カードを動かす操作と工程表が別物でも、更新する人が明確に決まっていて、その人の負担が許容範囲なら、それは機能している運用です。板の形と工程表の形をどう行き来させるかという観点はTrelloとの比較にまとめてあります。付箋を並べる形の板に慣れているチームが、線での見通しを足したいときの考え方を扱っています。
作業の依存関係を細かく設定して、自動化や外部サービスとの連携を前提に組んでいる場合も、乗り換える理由は薄くなります。その領域の考え方はAsanaとの比較とmonday.comとの比較で扱っています。文書やデータベースと一体で運用していて、工程表もその中の1つの表示として成立しているなら、Notionとの比較を見て、崩す必要があるかどうかを判断してください。開発の課題管理と工程管理を同じ場所で回している場合はBacklogとの比較、国内向けの板型の道具との違いはJootoとの比較で整理しています。全体を横に並べて見たい場合は比較の一覧から辿れます。
確かめるべきなのは、板と線が同じデータかどうか
進捗の数字を壊さないという観点で道具を見るとき、決定的な違いは1点です。担当者が毎日触る板と、とりまとめる人が見る工程表が、同じデータを別の形で見ているだけなのか、それとも別々に管理された2つの資料なのか。
同じデータなら、カードを完了の列に動かした瞬間に、工程表の側の完了数が増えます。担当者は進捗を報告したつもりがなく、ただ自分の作業を進めただけです。それでも数字は正しく更新されます。別々の資料なら、誰かが転記しなければならず、転記が止まった時点で数字は嘘になります。試用期間中に確かめるべきなのは、この一点です。板でカードを動かして、工程表の線がその場で動くかを実際に触って見てください。
料金の仕組みも合わせて確認しておきます。使える機能で段階を分ける形だと、進捗の管理に必要な部分が上の段階にあることがあります。区切り方の考え方は料金に書いてあります。機能で絞らず、区切るのは人数とボードの数だけという形なら、小さく始めても進捗の見方を変えずに済みます。金額と上限は変わるものなので、判断の当日に公式のページで確かめてください。
割り切っている点も先に書いておく
板にまとめる考え方の道具にも、できないことがあります。ソースコードを置く場所としての機能は持ちません。開発の課題と実装を同じ場所で完結させたいなら、そこは別の道具が要ります。自動化や外部サービスとの連携でも勝負していません。多数の外部サービスと自動で情報をやり取りする運用が中心なら、その領域が強い道具を選ぶ方が結果は良くなります。
画面は日本語のみです。海外のメンバーが日常的に触るチームでは、この点が実務上の障壁になります。既存の板から自動で取り込めるのも、限られた1つの道具からだけです。移行の手順はTrelloからの移行にまとめてあり、扱えることの範囲はできることで確認できます。データの保管と扱いについての考え方は安全性の考え方に、導入前に出やすい疑問はよくある質問に整理してあります。
数え方を変えるのが先か、道具を変えるのが先か
順番は決まっています。数え方が先です。道具を替えても、割合を人に入力させる運用のままなら、同じ現象が新しい画面の上で再現します。90%で止まる行が並ぶ画面が、以前より見やすくなるだけです。
完了かどうかで数える形に切り替えて、それでも更新が続かないなら、そこで初めて構造の問題になります。更新が続かない理由が、作業をする場所と工程表が離れていることにあるなら、道具の見直しに意味が出ます。切り分けの目安として、直近1か月に工程表を更新した人数を数えてください。1人だけなら構造の問題です。複数人が触れているのに数字が信用できないなら、数え方と完了の定義の問題です。
見積もりと実績の差を継続的に拾うことの重要性については、公的機関でも開発の実績データを集めた資料が公開されています。進捗の管理の考え方を整える段階では、情報処理推進機構が出している開発データの資料が参考になります。ただし、そこに載っている数値をそのまま自分のチームに当てはめることはできません。使い方は、自分たちの見積もりのぶれ幅を測る枠組みとして借りることです。
進捗率という数字は、それ自体が目的ではありません。目的は、遅れに早く気づいて、まだ手が打てるうちに調整することです。割合を精密にする努力より、完了したかどうかが誰の目にも同じに見える形を作ることの方が、この目的に直接効きます。数えられるものを数える。それが、進捗の数字を嘘にしないための最短の道です。
Q1. 進捗率をやめると、上への報告で困りませんか？
報告の形式は割合のままで構いません。担当者に割合を入力させるのをやめて、完了した項目数から機械的に計算する形に変えます。全40項目のうち17項目完了なら42%と出せば、報告の見た目は変わらずに、数字の作り方だけが人の推定から実測に変わります。作業が増えたときに割合が下がる点は、先に説明しておくと摩擦が減ります。
Q2. 作業を細かく割る手間が大きくて続きません。どうすればいいですか？
すべてを着手前に割り切ろうとすると必ず破綻します。直近2週間ぶんだけを2日から5日で終わる大きさに割り、それより先は大きな塊のまま線を引いておきます。着手が近づいた時点で塊を割る運用にすれば、割る作業が一度に来ません。週に一度の確認のときに、次の2週間ぶんが割れているかだけを見ます。
Q3. 進捗率が90%から動かない行があります。どう対応すべきですか？
数字を追及せずに、その作業を3つから5つの項目に割ってもらうのが早い方法です。割った時点で、何が残っているのかが本人にも見えます。多くの場合、残っているのは確認待ちや他部署の返答待ちで、本人の手では進められないものです。その場合は担当者ではなく、待ちを解消できる人に働きかける必要があります。
Q4. 完了の定義はどこまで細かく決めればいいですか？
1行で足ります。「レビュー担当者が確認済みと書き込んだ時点」のように、誰が見ても同じ答えになる書き方にします。工程ごとに細かい基準表を作ると、今度はその表を誰も読まなくなります。決めるのは1回だけで、チームの誰でも見られる場所に置いておけば、解釈のずれの大半は消えます。