進捗は「％」ではなく「個数」で測る
「基本設計は80％完了です」。定例でよく聞く報告ですが、この一言から得られる情報は、ほとんどありません。
何が終わっていて、何が残っているのか。残り20％にどれだけの作業があるのか。何も分かりません。そして翌週も「80％です」と報告されます。
■ 進捗率がぶれる理由
進捗率は、担当者の感覚で決まります。
作業量の半分をこなした人は「50％」と言う
難しいところを越えた人は、作業量が半分でも「80％」と言う
まだ不安がある人は、ほぼ終わっていても「90％」と言う
同じ状態でも、人によって数字が変わります。集めて平均しても、実態を表しません。
さらに厄介なのは、進捗率は後半で止まることです。80％から先は、レビューの指摘対応、他機能との整合確認、抜けの発見など、見えていなかった作業が出てきます。
■ 完了した「個数」で測る
代わりに、数えられるもので測ります。
「設計暆15本のうち12本がレビュー承認済み。残り3本は9月30日完了予定」
この報告なら、次のことが分かります。
終わったものと残ったものが明確
先週との差が出る（10本 → 12本）
完了の判定が、本人以外にもできる
残り3本にかかる時間が見積もれる
数えるためには、成果物が単位に分かれている必要があります。WBSを「担当者が決まり、完了を他人が判定できる」粒度まで分けておくのは、このためでもあります。
■ 途中のものをどう数えるか
それでも、作業中のものは出てきます。ここで感覚に戻らないよう、付け方のルールを先に決めます。
よく使われるのが「0／50／100ルール」です。
0％ 着手していない、または着手しただけ
50％ 成果物ができて、レビューを依頼した
100％ レビューで承認された
この3段階しか使いません。「70％くらい」という報告がなくなります。
期間の短い作業が多い場合は、「0／100ルール」（完了したものだけ数える）のほうが実態に近くなります。1〜2日で終わる作業なら、途中の状態を数える意味がありません。
■ 完了の定義をそろえる
「完了」の意味が人によって違うと、数えても意味がありません。プロジェクトの最初に決めます。
設計書は「レビューで承認されたら」完了
プログラムは「単体テストが終わり、コードレビューを通ったら」完了
テストケースは「実施して、結果を記録したら」完了（バグが残っていてもケースは完了）
とくに「レビュー承認まで含めるかどうか」は、はっきりさせます。ここが曖昧だと、「書き終わった」ものが完了として報告され、後でレビュー指摘の対応が積み上がります。
■ 報告での見せ方
数字を並べるだけでなく、推移を見せます。
「設計書 先遑10本 → 今遑12本（計画は13本）」
「テストケース 消化 420/800（先週比 +120）」
「課題 新規3件・解決5件・残12件（先遑14件）」
推移が見えると、ペースが足りているかどうかが判断できます。「残り3本を2日で」と言われても、これまで週2本のペースなら無理だと分かります。
■ ペースから終わりを予測する
完了数で測る利点は、終わりの時期を予測できることです。
「週2本のペースで、残り6本。このままだと3週間かかる。計画は2週間なので、1週間足りない」。進捗率ではこの計算ができません。
ペースが足りないと分かったら、早い段階で打ち手を検討できます。
■ まとめ
進捗は、％ではなく個数で測ります。完了の定義をそろえ、0／50／100のように付け方を機械的に決め、先週との差が見える形で報告する。
次の定例で「80％です」という報告があったら、「何本のうち何本が終わっていますか」と聞いてみてください。それだけで、見える景色が変わります。