「先週から進捗が止まっているんですが、担当者に聞いても『進めています』としか返ってこない」——そう感じながら、どう確認すればいいか分からずに数日過ぎていく。進捗の急停止は、炎上の前段階でよく見られるパターンです。
進捗が止まったときの初動確認が遅れると、詰まりは複合化します。技術的な問題が依存関係に波及し、それが納期に影響し始めてから気づく、というルートをたどるのが典型です。本記事では、進捗が止まった案件で最初に確認すべき4つの観点を整理します。
進捗が止まるときに起きていること
進捗報告が「進めています」のまま何日も変わらないとき、実際に起きていることはいくつかのパターンに分かれます。
完了条件が曖昧で、どこで終わりかが分からない。タスクが「〇〇を実装する」という書き方になっていて、何ができれば完了かが定義されていない。担当者は「まだ終わっていない感じがする」まま作業を続けています。
前工程や他タスクの完了を待っている。依存しているタスクが止まっているのに、それを表明できていない。もしくは担当者自身が依存関係に気づいていない。
技術的に詰まっていて、誰にも言えていない。PMや先輩に聞けば解決できる問題なのに、「自分で解決しないといけない」と抱え込んでいる。特に経験の浅いメンバーや、チームの雰囲気が固いときに起きやすい。
確認や承認を待っている。顧客確認、社内レビュー、ツールのアクセス権など、自分では動けない状態になっているのに、アクション待ちが見えていない。
確認1：完了条件が曖昧ではないか
まずWBSやタスク一覧を開いて、止まっているタスクの「完了条件」を確認してください。
「〇〇機能の実装」とだけ書かれていて、単体テスト通過なのか、コードレビュー済みなのか、動作確認が終わっているのかが明示されていない場合、担当者は「何ができれば報告していいか」が分からない状態にあります。
担当者に聞くときは「どこまで終わっていますか」ではなく、「〇〇の実装で、今どのフェーズにいますか」と聞いてみてください。完了条件を一緒に確認しながら話すと、詰まっている場所が自然に出てきます。
確認2：依存タスクが止まっていないか
次に、止まっているタスクの前後関係を確認します。
WBSやガントチャートで、止まっているタスクが何に依存しているかを見てください。依存元が遅延していたり、待ちの状態になっていたりすると、連鎖で止まります。こちらは担当者の問題ではないため、PMが状況を把握して解除アクションを取る必要があります。
「〇〇の確認待ちで進められていない」という状況が、担当者から言い出しにくいこともあります。「他に何か待っているものはありますか」と一言聞くだけで出てくることがあります。
確認3：技術的に詰まっていないか
「できると思っていたが、実際にやってみたら複雑だった」という詰まりは、プロジェクトの中盤以降に頻繁に起きます。特に初めて扱う技術、外部連携、データ変換まわりでよく見られます。
確認のポイントは「何が難しいか」を具体的に聞き出すことです。「うまくいっていますか」という漠然とした質問では「はい」しか返ってきません。「〇〇の連携で、どんなエラーが出ていますか」「どこで時間がかかっていますか」という聞き方をすると、詰まりの実態が見えてきます。
技術的な詰まりが確認できたら、解決の手段を一緒に考える（あるいは社内の技術者を巻き込む）ことがPMの役割です。「なぜ今まで言わなかった」という指摘は最後にしてください。まずは詰まりを取り除くことが優先です。
確認4：相談しづらい状態ではないか
これは確認というより観察です。進捗報告の回答が短い、眼が合わない、会話が続かない、という状態が数日続いている場合、メンバーが「言いづらい状態」に入っています。
原因はPMの関わり方だけとは限りません。案件の複雑さからくる精神的な疲弊、チーム内の人間関係、社内の別件との兼務など、複数の要因が絡んでいることがほとんどです。
相談しづらい状態への対応は、1対1の短い会話が有効です。進捗確認ではなく「最近どうですか」から始めて、詰まりや困りごとを引き出す時間を作ってください。問題が深刻になる前に対話できると、リカバリのコストが大きく変わります。
確認結果をリカバリに変える
4つの確認を終えたら、止まっている理由に応じたアクションに移ります。
- 完了条件の曖昧さ → タスクを再定義してから再開
- 依存関係の詰まり → 解除アクションをPMが取る
- 技術的な詰まり → 解決リソースを当てる（相談先・技術者・外部ドキュメント）
- 相談しづらい状態 → 対話と心理的安全の回復
「なぜ止まったか」を責める前に「どうすれば動くか」を優先してください。責任の追及は、立て直しが完了してから振り返りの場で行うべき話です。
リカバリ後も「止まりやすさ」を残さない
4つの確認でリカバリに動けたとしても、同じパターンが翌月に繰り返されることがあります。「止まった原因への対処」と「止まりやすい構造への対処」は別物だからです。
止まりやすい構造への対処で効果が高いのは2点です。
完了条件の定義を起票時のルールにする。タスクを課題管理票に登録するとき、「完了の定義（何ができれば報告してよいか）」を必ず一行書く習慣をチームに定着させます。これがあるだけで、担当者が「どこで終わりか分からない」状態に陥りにくくなります。
相談のハードルを下げる定例構造を作る。週次の進捗確認に「詰まっていることを1件だけ言う」時間を5分設けるだけで、技術的な詰まりや依存関係の待ちが早期に表面化します。全員が「詰まりを言える場がある」と認識することが、相談しづらい状態を予防します。
1週間後も止まっている場合の判断基準
4つの確認をして対応に動いても、1週間後に同じタスクが止まったままの場合は、対応が機能していないか、別の詰まりが発生しているサインです。
この時点での判断ポイントは2つです。
担当者を変えるか、別リソースを当てるかを判断する。技術的な詰まりが解消できない場合、担当者を変えることは責めではなく役割の再設計です。「このタスクには別の技術者が合っている」という判断を早めに下すことが、全体のスケジュールを守ります。
上位のステークホルダーに共有する。1週間対処しても動かない問題は、PMだけで解決できない場合が多いです。上司やPMOに状況を共有して、判断権限・リソース・依存関係の解除を依頼するタイミングです。「上報告するほどの話ではない」と抱えたまま2週間経つのが最悪のパターンです。
「進捗が止まった」という状況は、PMの仕事の質を問うものではなく、プロジェクトの構造的な問題が表面化したサインです。責任を感じて一人で解決しようとせず、4つの確認と適切なエスカレーションを組み合わせることが、結果として最も早い立て直しにつながります。日々の進捗確認の中で「ちょっと止まっている気がする」という直感を無視しないことが、次の炎上を防ぐ第一歩です。
進捗の急停止を早めに検知する方法は、炎上予防・立て直しパックの中で体系的に学べます。「遅延の兆候をどう見るか」「担当者との会話をどう設計するか」について、受託開発PMの実務に合わせた講座を揃えています。PJ炎上 初動ナビでは、現在の案件の炎上リスクを診断してアクションを確認できます。