はじめに：「進捗どう？」の問答は、なぜバグったままなのか

GitHub Copilotがコードを爆速で書いてくれる時代になっても、「進捗どう？」の問答だけは昔からバグったままです。

「あのタスク、進捗どう？」
「いま8割がた終わってます」

火曜日にそう言っていたメンバーが、木曜日も「8割です」、金曜日も「8割くらいですね……」。気づけば翌週になっても、そのタスクは「8割完了」のままカレンダーに居座り続けている——。

この記事は、将来PMやTech Leadも視野に入れているけれど、「人の進捗を見る側になるの、正直ちょっと怖い…」というエンジニア向けに、進捗率の罠と、その代わりに使える実務ツール（DoD / AC / DoR）を整理します。

PMは、現場を根性で監視する仕事ではありません。「構造と仕組みで現場をハックする技術職」です。

1. 進捗率（％）は、そもそも“仕様として”バグりやすい

なぜ進捗の認識はこれほどズレるのでしょうか。前提として、進捗率（％）は仕様として非常に不安定な指標です。

「実装完了＝50%、レビュー待ち＝80%」とルールを決めても、ズレは消えません。なぜなら、メンバーが口にする「80%」の前提が、結局は体感に委ねられているからです。

罠1：分母（時間の規模）のバグ

100時間かかるタスクの80%（残り20時間）
10時間で終わるタスクの80%（残り2時間）

どちらも「80%」ですが、残りの重さはまったく違います。

罠2：分子（成果物 vs 消費工数）のすり替わり

成果物のボリュームが8割できた
予定工数の8割を消費しただけ

後者は進捗ではなく、単なる「工数の消費率」です。

ここが曖昧なまま自己申告に頼ると、数字の見た目と実態が乖離し始めます。

2. パーセンテージを捨て、「客観的な状態」をツールとして使う

進捗率をメイン指標にするのをやめて、「状態」を見るようにします。ここで、スクラムの3つの用語を“軽いツール”として使います。

ツール① 完了の定義 (DoD) ― 「終わったつもり」を防ぐチェックリスト

例：

CIでテストが全件グリーン
PR作成済み
ドキュメント更新済み

ツール② 受入基準 (AC) ― 「作ったけど違う」を防ぐ条件

例：

管理者権限のみ /admin/* にアクセスできる
一般ユーザーは 403 Forbidden

ツール③ 準備完了の定義 (DoR) ― 「そもそも今週やれるの？」を確認するフィルタ

例：

仕様がFixしている
必要なAPIが利用可能
スプリントで終わるサイズになっている

2.5 実践：Jira / GitHub IssuesでのMarkdown実装例

課題: ユーザー認証認可機能の認可ロジック実装

DoR（着手するための条件）
- 認可仕様書（Admin/User権限）がFixしている
- 依存する認証APIがテスト環境で利用可能である
  　
DoD（完了の条件）- 全チケット共通
- CIでの全件グリーン（自動テスト）通過
- OpenAPIの定義（Swagger）が更新されている
- main ブランチに対するPull Requestが作成され、レビュー待ち状態である
  　
AC（受入基準）- このチケット固有の要件
- 管理者（Admin）のみが /admin/* エンドポイントにアクセスできること
- 一般（User）がアクセスした場合は 403 Forbidden が返却されること

これだけで、

「今どれくらい進んでる？」

↓↓↓↓↓客観的な表現↓↓↓↓↓

「どの条件まで終わった？」

という、事実ベースの建設的な会話に変わります。

3. 明日から試せるミニワーク

現場に導入する際に、大掛かりなプロセス変更は不要です。
まずは1タスクだけで試してみてください。

直近のタスクを1つだけ選ぶ
「今できていること」「まだのこと」を数字なしで書き出す
メンバーに聞く：「このタスクが“完了”したと言えるのは、どんな状態？」

出てきた答えを整理し、チケットの「完了条件」として書き直す。これを1タスクだけでもやると、「進捗率って、なくても困らないな」という感覚が掴めてきます。

4. エンジニアがPMを怖がらなくていい理由と、その先の「沼」

進捗率を問い詰めるのではなく、「どういう状態を定義すれば、チームが迷わず動けるか」を設計する。

「進捗のバグ」を定義で減らすこのアプローチに納得感を持てるエンジニアは、すでにPMやTech Leadの素養が十分にあります。

「進捗率の罠」をDoD / AC / DoRでハックするところまでは、このQiita記事で一気に掴めるはずです。

しかし、その先の、

会議が増えるほど現場が止まる理由
「あの人がいると現場が回る」PMの秘密
完遂の型を、属人技ではなく組織の仕組みにする方法

これは、PM・PMO寄りの“構造の沼”になるので、別の場所（Substack）でかなり深く書きました。

「問題はないはずなのに、なぜか現場が重い」。そんな違和感の裏側で何が起きているのか。

▼ もっと深い構造の話はこちら

ここまで読んで下さったエンジニアのあなたなら、その先の実践知も絶対に面白く感じていただけるはずです。

あなたの誠実さが、孤独な戦いで終わらないように。