「承認待ちが10件以上たまっていて、どれから督促すればいいか分からない」
受託開発の中盤以降、こういう状況に陥ることがあります。顧客への確認を重ねているうちに、承認待ちが積み重なって全体が止まっている状態です。
承認待ちは「顧客が動いていない」問題に見えますが、PMの視点では「どの承認が最も急ぐか」「誰に督促すれば動くか」の判断が必要です。全件を同じ優先度で扱うと、精力を分散させてどれも進まなくなります。この記事では、増えた承認待ちを整理して優先順位をつける方法を解説します。
顧客承認待ちが増えると何が起きるか
承認待ちが積み重なると、プロジェクト全体が止まり始めます。
承認がないと進められない作業が増え、担当者が「待ちの状態」になります。待っている間に別の作業をしていても、最終的に承認が遅れた分だけスケジュールが押します。
また、承認待ちが多くなると「どれが最も影響が大きいか」が見えにくくなります。すべてを並列で督促しようとすると、顧客への連絡が頻繁すぎる印象になり、逆効果になることもあります。
整理の目的は「いくつかに絞って重点的に督促する」ことです。
承認待ちを一覧化する項目
まず手元にある承認待ちを一覧化します。確認する項目は次の5つです。
- 判断事項：何についての承認か（具体的な内容）
- 意思決定者：誰に判断してもらう必要があるか
- 依頼日：いつ依頼したか
- 影響範囲：この承認が遅れると何が止まるか
- 期限：この承認が必要なデッドラインはいつか
この5点が分かれば、優先順位をつけられます。一覧にしていない場合は、まずここから整理します。
影響範囲で優先順位をつける
一覧化した後は、影響範囲で優先順位をつけます。
優先度が高い承認待ちは次の条件に当てはまるものです。
- 後続作業がブロックされている：この承認がないと開発が進められない
- スケジュールのクリティカルパス上にある：遅延がそのままリリース遅延に直結する
- 他の承認待ちとセットになっている：これが解決しないと他の承認も意味がない
逆に優先度が低い承認待ちは、「承認が遅れても現時点では作業に影響しない」ものです。今週中に督促しなくても良い承認待ちは、後回しにして問題ありません。
意思決定者を確認する
「誰に督促するか」が明確でないと、督促が空振りになります。
「担当者への依頼」と「決裁者への依頼」は別です。担当者が「確認します」と言っていても、実際の判断は上長が持っているケースがあります。
「この判断は〇〇さんが最終決定者ですか？」「〇〇さんに直接確認してもよいですか？」という確認を行います。意思決定者が分かれば、督促の連絡先が明確になります。
期限と未回答時の影響を伝える
督促するときに伝えるべきことは「回答をお願いします」だけでは不十分です。なぜ今週中に回答が必要かを伝えることで、顧客側の優先度が上がります。
伝えるのは2点です。
期限：「〇月〇日（水）中にご回答いただけますか」
未回答時の影響：「ご回答がない場合、〇〇の作業を〇日保留することになります。その場合、現時点の見込みでリリースが〇週間ほど後ろにずれる可能性があります」
「困ります」という感情表現ではなく、「〇〇の影響が出ます」というファクトで伝えます。顧客批判にならず、かつ伝わりやすい形です。
承認待ち管理表の例
一覧化するときは、以下のような表を使うと整理しやすくなります。
| No | 判断事項 | 依頼日 | 意思決定者 | 期限 | 影響範囲 | 優先度 | 次アクション |
|---|---|---|---|---|---|---|---|
| 1 | A画面の追加機能仕様確認 | 5/7 | 田中部長 | 5/10 | 結合テスト開始がブロック | 高 | 5/9に電話確認 |
| 2 | デザイン修正案の採否 | 5/5 | 鈴木担当 | 5/14 | UIの実装スタート | 中 | 5/12にメール再確認 |
| 3 | 追加費用見積の承認 | 4/28 | 田中部長・経理 | 5/15 | 5月末リリースに影響 | 高 | 5/10に現況確認 |
各列の見方：
- 期限：この承認がなければいつ以降に影響が出るか（承認依頼の締め切りではなく、後続への影響日）
- 影響範囲：後続のどの作業がブロックされるか
- 優先度：影響範囲の大きさ・期限の近さを組み合わせて判断
- 次アクション：誰が・いつ・何をするか
この表は「顧客が悪い」を可視化するためではなく、PMが何に集中するかを判断するための内部管理ツールです。
顧客へ確認するときの文例
督促のトーンは、責める形ではなく「事実・期限・影響・次の確認」を淡々と伝える形にします。
期限を再確認する文例
○月○日に〇〇についてご確認をお願いしておりましたが、進捗はいかがでしょうか。今週中（〇月〇日まで）に方向性をいただけますと、〇〇の準備を進めることができます。引き続きよろしくお願いいたします。
未回答時の影響を伝える文例
〇〇のご判断を○日よりお待ちしております。○月○日（○曜日）中にご回答いただけない場合、〇〇の作業を保留することになり、現時点の見込みではリリースが〇〜〇週間後ろにずれる可能性があります。ご状況をお知らせいただければ幸いです。
意思決定者を確認する文例
〇〇のご判断について、現在〇〇さんにご確認いただいておりますが、最終的なご判断は〇〇さんがされるという理解でよろしいでしょうか。場合によっては直接ご説明する機会もご検討いただけますと、スムーズかもしれません。
文例はあくまで参考です。実際の文章は個別の関係性や契約の状況に応じて調整してください。
エスカレーションを検討する基準
以下の条件が重なるときは、PM個人での判断ではなく、社内でのエスカレーションを検討します。
- 期限を過ぎても回答が得られていない
- 後続工程の作業が止まっている
- リリース日や顧客業務に実質的な影響が出始めている
- 担当者では判断できないことが明確になっている
- 同じ承認待ちが複数回持ち越されている
エスカレーションの方法（上長を通じた連絡・定例への参加依頼・確認会議の設定など）は、個別の契約・体制・顧客との関係性を踏まえて判断します。「期限を過ぎたから自動的にエスカレーション」ではなく、影響の大きさと関係性のバランスで決めるのが実務的です。
まとめ
承認待ちが増えたとき、全件を同じ優先度で督促するのは非効率です。
一覧化→影響範囲で優先順位づけ→意思決定者の確認→期限と影響の伝達、という手順で整理すると、重要な承認に集中できます。顧客への連絡も「全件まとめて確認のお願い」より、優先度の高い件に絞った方が動いてもらいやすくなります。
顧客対応や受託開発PM実務を体系的に学びたい方は、受託開発PM向けの課題別パックやITエンジニア向けビジネススキル講座をご覧ください。