「現在、顧客確認待ちです。」
「レビュー待ちです。」
「他チームの回答待ちです。」
プロジェクトを進めていると、「確認待ち」という言葉をよく耳にします。
一つひとつを見ると、それほど大きな問題には見えません。
担当者は決まっている。タスクも登録されている。期限もまだ過ぎていない。
それなのに、気がつくと「確認待ち」のタスクが増え、プロジェクト全体の進みが悪くなっている。
私自身、PMOとしてプロジェクトに関わる中で、こうした状況を何度も見てきました。
振り返ってみると、問題だったのは「確認に時間がかかったこと」だけではありませんでした。
確認待ちのタスクが増えることで、後続の作業まで動かなくなっていたことが大きな原因でした。
「確認待ち」は、タスクが止まっているとは限らない
例えば、設計書を作成している担当者がいたとします。
設計書はほぼ完成していて、最後に顧客へ確認を依頼しています。
WBS上では、「設計書作成：90％」となっている。
進捗会議でも、「ほぼ完了しています。現在、顧客確認待ちです。」という報告になります。
一見すると、順調に見えます。
しかし、その設計書が完成しないと、後続の開発タスクを開始できないとしたらどうでしょうか。
設計書の確認が1日遅れる。すると開発の開始も1日遅れる。開発が遅れれば、テストの開始も遅れる。
つまり、「確認待ち」という小さな停止が、後続工程に連鎖していくことになります。
「90％完了」がプロジェクトを安心させてしまう
確認待ちが怖い理由の一つは、進捗率だけを見ると順調に見えてしまうことです。
例えば、「設計書作成：90％」「レビュー：80％」「仕様確認：90％」といったタスクが並んでいると、プロジェクト全体としてもかなり進んでいるように感じます。
しかし、実際にはすべて「誰かの確認待ち」だったとします。
この場合、作業量としては進んでいても、次の工程へ進むための条件が満たされていない可能性があります。
プロジェクトでは、「どれだけ作業したか」だけでなく、「次の工程へ進める状態になったか」を見る必要があります。
「確認待ち」が増えると、ボールが見えなくなる
もう一つの問題は、責任の所在が曖昧になりやすいことです。
例えば、「設計担当が顧客に確認を依頼した」「顧客から回答が来ていない」「回答が来ないので設計担当は作業を進められない」という状況になったとします。
このとき、WBS上の担当者は設計担当者のままです。
しかし、実際には設計担当者が作業する段階ではありません。
今、ボールを持っているのは顧客側です。
この状態を整理しないまま進捗会議を続けると、「○○さん、あの件どうなっていますか？」「まだ確認待ちです。」というやり取りが毎週繰り返されることになります。
「確認待ち」と「確認依頼中」は違う
ここで重要なのが、「確認待ち」という言葉だけで状況を管理しないことです。
例えば同じ「確認待ち」でも、
- まだ確認を依頼していない
- 確認を依頼したばかり
- 相手が確認中
- 回答期限を過ぎている
- 回答内容に追加確認が必要
- 回答は来たが、判断できない
では、対応方法がまったく違います。
そのため、PMOとしては「確認待ち」というステータスだけを見るのではなく、誰に、何を、いつ確認していて、いつまでに回答が必要なのかまで把握する必要があります。
特に怖いのは「確認待ちの連鎖」
確認待ちが一つだけなら、それほど大きな問題にならないこともあります。
怖いのは、複数の確認待ちがつながってしまうケースです。
例えば、「仕様確認待ち」→「設計開始できない」→「設計レビューできない」→「開発開始できない」→「テストケースを作れない」という状態です。
それぞれの担当者は、自分のタスクをサボっているわけではありません。
むしろ、「前の工程が終わるのを待っています。」という正当な理由があります。
それでも、プロジェクト全体としては前に進みません。
個々の担当者が正しく動いているのに、プロジェクトが遅れる。
これはプロジェクト管理では特に注意したい状態です。
PMOが見るべきなのは「待ち時間」
こうした状況では、タスクの進捗率だけではなく、「待ち時間」を見ることが重要になります。
例えば、「顧客確認待ち：3日」「レビュー待ち：2日」「他チーム回答待ち：5日」といった形です。
作業そのものに何日かかっているのか。それに対して、確認や回答を待つ時間が何日あるのか。
ここを分けて見ると、プロジェクトが遅れている本当の原因が見えてくることがあります。
特に、同じ種類の「確認待ち」が何度も発生しているなら、個別のタスクの問題ではなく、プロセスそのものに問題がある可能性があります。
「確認を早くしてください」だけでは解決しない
確認待ちが増えてくると、「確認を早くお願いします。」「回答を急いでもらえませんか？」と催促することがあります。
もちろん必要な場面もあります。
ただ、それだけでは根本的な解決にならないことがあります。
例えば、毎回レビューに3日かかっているのであれば、「レビュー担当者が忙しい」だけではなく、「レビュー依頼の出し方が悪い」「レビュー対象が大きすぎる」「確認する人が多すぎる」「判断基準が決まっていない」といった原因が隠れているかもしれません。
確認待ちが繰り返されるなら、単純に催促するのではなく、なぜ確認待ちが発生しているのかを考えることが重要です。
「いつまでに確認が必要か」を伝える
確認を依頼するときに、「確認をお願いします。」だけで終わってしまうケースがあります。
しかし、受け取った側からすると、いつまでに確認すればよいのか分かりません。
その結果、優先順位が下がってしまうことがあります。
例えば、「○月○日までに確認いただけない場合、後続の開発開始に影響します。」と伝えれば、確認する側も重要度を判断しやすくなります。
つまり、確認依頼では、「何を確認してほしいか」だけでなく、「いつまでに必要なのか」「遅れると何に影響するのか」まで伝える。
これだけでも、確認待ちの長期化を防ぎやすくなります。
PMOが確認したい5つのポイント
確認待ちのタスクが増えてきたとき、私は次のような点を確認するのが有効だと考えています。
- 誰の確認待ちなのか
- いつ確認を依頼したのか
- いつまでに回答が必要なのか
- 回答が遅れると、どのタスクに影響するのか
- なぜ確認に時間がかかっているのか
特に重要なのは、最後の「なぜ確認に時間がかかっているのか」です。
ここまで確認すると、「単純に忙しい」のか、「判断する人が決まっていない」のか、「確認材料が不足している」のか、「そもそも誰が承認するのか決まっていない」のかが見えてきます。
「確認待ち」はプロジェクトの温度計
「確認待ち」は、それ自体が悪いわけではありません。
プロジェクトでは、顧客確認やレビュー、他チームとの調整が必要になるのは当然です。
問題なのは、確認待ちが増えているのに、それを単なる個別タスクの状態として扱ってしまうことです。
確認待ちが増えているということは、「意思決定が遅れている」「依存関係が多い」「レビューがボトルネックになっている」「情報共有が不足している」など、プロジェクト全体の問題が表面化している可能性があります。
だからこそ、「確認待ち」は単なるステータスではなく、プロジェクトの状態を知るための一つの指標として見ることができます。
まとめ
プロジェクトが遅れ始めたとき、まず「遅れているタスク」を探すことがあります。
しかし、その前に「確認待ちになっているタスク」を見てみるのも有効です。
担当者が作業している。期限もまだ過ぎていない。進捗率も90％ある。
それでもプロジェクトが前に進んでいない。
そんなとき、原因は「作業」ではなく「待ち時間」にあるかもしれません。
PMOにとって重要なのは、タスクの進捗率だけを見ることではありません。
「今、誰のボールなのか」
「そのボールは、どれくらいの時間止まっているのか」
「なぜ止まっているのか」
まで見ることです。
「確認待ちだから仕方ない」で終わらせず、「なぜ確認待ちになっているのか」を一段深く見てみる。
そこに、プロジェクトが遅れ始めた本当の原因が隠れているかもしれません。
所属会社（エンジニア積極採用中）
ITエンジニアに、IT業界に貢献する企業
株式会社ONE WEDGE
株式会社ONE WEDGEは、Webシステム開発・SES・AI/DX支援を行うIT企業です。生成AIを活用した業務効率化や次世代システム開発にも注力しており、企業の課題解決だけでなく、エンジニア一人ひとりの成長にも本気で向き合っています。また、技術は「一人で学ぶもの」ではなく「仲間と成長するもの」と考え、社内外でのコミュニティづくりにも力を入れています。