進捗率の出し方｜件数・工数・成果物の違いと誤解を防ぐ報告例
「進捗80％」なのに、残りの仕事で何週間もかかる。数字だけでは、何を数えたか、何を完了としたかが分かりません。進捗率は、対象・分母・完了判定・計算方法をセットで示す必要があります。
以下は説明用の小さな計算例です。数値は実績ではありません。進捗率で人を評価するのではなく、残作業と終了見込みを判断できる報告を作ることが目的です。
同じ作業でも、件数と重みで数字は変わる
三つの作業があり、そのうち案内文だけが完了したとします。作成済みではなく、各行の完了条件を満たした状態を数えています。
| 作業 | 計画上の重み | 完了したか |
|---|---|---|
| 入力画面 | 6 | いいえ |
| 権限設定 | 3 | いいえ |
| 案内文 | 1 | はい |
件数なら1÷3で約33％です。計画上の重みを使うなら、完了分1÷全体10で10％です。どちらも計算自体はできますが、同じ「進捗率」として比較できません。
重みを工数等で設定しても、得られる値は定義した作業の完成度の指標です。残り期間、費用の消化率、利用者への価値の達成率と同じではありません。納期は依存関係やレビュー待ちにも左右されます。
完了判定と、途中の状態を分ける
「ほぼ終わった」を90％とする運用は、担当者によって解釈が変わります。未着手・作成中・確認待ち・修正中・完了という状態を残し、完了条件を明示すると、数字だけでなく止まっている場所が見えます。
途中の割合を使うなら、組織で定義した基準に合わせます。例えば成果物の一部を完了として評価する場合は、どの部分が検証済みかを記録します。「時間を九割使ったから完成度も九割」と判断しないようにしてください。
件数の粒度もそろえます。一行が一つの小修正、別の一行が大きな新機能なら、件数だけでは全体を説明しにくくなります。大きな仕事の分解か、計画上の重みの使用を検討します。
作業が追加されたら、分母の変化を伝える
完了件数が増えても、対象が増えれば進捗率は下がることがあります。これは必ずしも作業が後退したという意味ではありません。当初の対象と、承認された変更後の対象を分けます。
報告では「対象10件のうち6件完了」だけでなく、「前回は8件、変更承認により2件追加」と説明します。新しい対象で計算する際も、変更前の計画を消さず、対象版と承認日を残します。
担当者が作業を細分化しただけで分母が増えた場合は、進捗の比較条件が変わったことになります。数値を良く見せるために、簡単な作業を増やしたり完了済みの仕事を分割したりしないようにします。
進捗率と一緒に、残りの仕事を報告する
説明用の報告なら、次のように書けます。
計画上の重みを使った完了率は10％です。
案内文は確認済み、画面は作成中、権限条件は回答待ちです。
権限条件が確定しないと該当箇所のテストを開始できません。
確定予定を確認し、残作業と確認者の予定から終了見込みを更新します。必要なのは、数字を高く見せることではなく、次の行動を判断する材料です。「完了率は上がったが、重要な確認が待っている」なら、その事実を目立つ場所へ書きます。
集計前に点検する五つの条件
- 対象範囲と計画版は、前回と同じか。
- 完了と判定した行は、確認や承認まで終わっているか。
- 同じ仕事を複数の表から二重に集計していないか。
- 途中の進捗と、完了した作業の集計を混ぜていないか。
- 数字を出した日時と、未回答・未更新の範囲を説明しているか。
未更新の行を自動的に未着手と見なすのも、前回の値で埋めて最新実績と見せるのも避けます。未確認なら未確認と示します。精密に見える数字より、条件が明らかな数字の方が判断に使えます。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
計画の基準と実績を比較する考え方を確認しました。進捗の計算表は独自の説明用です。 Atlassian：Project Baseline（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
週次報告書の書き方も必要な作業に合わせて参照してください。
アイキャッチ写真：Gabriel Cox / Unsplash。職場の実写ではなくイメージ写真です。
