進捗管理はリーダーだけの仕事じゃない
――トップダウンとボトムアップで回す“二層管理”のススメ――
はじめに
「進捗管理 = リーダーの仕事」と思われがち。でも実際にはリーダーとメンバー双方の責任で成り立つものだ。
本記事では、リーダーとメンバーがそれぞれ担うべき役割を整理し、トップダウンとボトムアップの両面から進捗を“挟み撃ち”する方法を紹介する。
よくある誤解：進捗管理＝リーダー専任説
| 誤解 | 実態 |
|---|---|
| リーダーが細かく状況を把握し、遅れがあれば指示を出せばよい | リーダーは全体把握が限界。メンバーのタスク状況はメンバー自身が最も詳しい |
| メンバーはリーダーに報告さえしていればOK | 報告だけでは“遅れの芽”を潰せない。日々のセルフマネジメントが必須 |
役割分担：リーダー vs メンバー
リーダーが担うこと（トップダウン）
-
全体スケジュール設計
- マイルストーン設定・依存関係の明示
-
プロジェクト可視化
- ガントチャート、カンバン、バーンダウン等で進捗を“誰でも見える化”
-
リスク／課題の収束
- “赤信号”を検知したら即座にリソース調整・意思決定
-
報連相の流れづくり
- 報告フォーマットや定例ミーティングの設計
メンバーが担うこと（ボトムアップ）
-
自タスクの進捗管理
- 毎日“予定 vs 実績”をセルフチェック
- タスク分割・見積もり精度の継続改善
-
地面レベルのリスク発見
- 実装難易度の想定外、外部依存の遅れ……小さな違和感を即エスカレーション
-
情報のプル型共有
- REFS（Review・共有）を自発的に回し、他メンバーの進捗も補完
-
改善提案
- ツール選定や手順変更など“現場の知見”をトップにフィードバック
二層管理を機能させるコツ
1. 情報粒度を合わせる
- リーダー用：全体勝率を測るマクロ指標
- 例）完了ストーリー数、残タスク数、総バーンダウン率
- メンバー用：自タスクのミクロ指標
- 例）1日の作業時間実績、ブロッカー件数、レビュー待ち時間
2. 共通のプラットフォームを使う
- GitHub Projects / Jira / Notion など一元化
- 更新者（メンバー）と閲覧者（リーダー）が同じデータをリアルタイムで見られる状態に
3. “上から下へ・下から上へ”の定例サイクル
| 頻度 | トップダウン（リーダー発） | ボトムアップ（メンバー発） |
|---|---|---|
| 毎日 | デイリースタンドアップで全体状況共有 | タスク更新・阻害要因の即報告 |
| 週次 | マイルストーン進捗レビュー | 課題・改善案の提案 |
| 随時 | 重大リスクのエスカレーション | 想定外ブロッカーの報告 |
4. 仕組みで“サボれない”設計にする
- タスク未更新は自動リマインド
- レビュー遅延はダッシュボードで赤表示
- 仕組みが先、精神論は後
期待できる効果
-
遅延の早期発見
- ボトムアップで細かな遅れを検知
- トップダウンで全体最適な手当て
-
属人化の防止
- 進捗データが共有資産になることで“あの人しか知らない”を排除
-
メンバーの当事者意識向上
- “自分のタスク＝自分の責任”が明確になる
-
リーダーのマネジメント負荷軽減
- 手動で状況ヒアリングする時間を、意思決定や障害解決に回せる
まとめ
- 進捗管理をリーダー専任の仕事と捉えると、情報が遅れ・歪み・隠れる。
- リーダーは全体最適・メンバーは個別最適を追い、二層で管理することで“正確で素早い”プロジェクト運営が実現する。
- ポイントは「仕組みと可視化」。ツール・定例・指標を整え、トップダウン × ボトムアップのサイクルを回そう。
プロジェクト成功の原動力は、リーダーのリードとメンバーの自立が互いを補完しあうこと。
今日から“二層管理”を取り入れ、チーム全員で進捗を前へ押し進めよう！