はじめに：「進捗どう？」の問答は、なぜバグったままなのか
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）でかなり深く書きました。
「問題はないはずなのに、なぜか現場が重い」。そんな違和感の裏側で何が起きているのか。
▼ もっと深い構造の話はこちら
ここまで読んで下さったエンジニアのあなたなら、その先の実践知も絶対に面白く感じていただけるはずです。
あなたの誠実さが、孤独な戦いで終わらないように。
