案件を進めていると、どこかで必ず止まる。クライアントからの承認を待っているからだ。デザイン案の確認、仕様の最終合意、予算の決裁。承認が下りるまで次に進めない、という状況は珍しくない。

問題は、その待機時間がチームの生産性に大きく影響することだ。外部メンバーが入る越境チームでは、一人の稼働が止まると次の工程全体が連鎖して遅れる。承認待ちが常態化しているチームは、スケジュールの見積もりも「そのうち来るだろう」という曖昧な前提で成り立っている。

「待つ」が当たり前になっているとき

承認待ちを許容しているチームには、共通のパターンがある。承認を依頼するタイミングが不明確で、いつ返答が来るかも確認していない。外部メンバーは「来たら教えてください」という受け身の状態で待ち続け、案件の優先度がクライアント側でどう扱われているか見えない。

この状態では、チームの稼働コントロールが難しくなる。何日待つか分からないまま他の案件を入れられず、かといって手を止めるわけにもいかない。

承認プロセスをクライアント任せにしている限り、この消耗は続く。

承認の「期限」を設計する

承認依頼を出すとき、多くのチームは「確認をお願いします」と送って終わる。返答期限を明示していないことがほとんどだ。

クライアントが忙しいのは事実だ。しかし期限がなければ、承認は後回しになる。「後で確認しよう」は、気づいたら一週間後、という結果を招く。

承認依頼には期限を設定する必要がある。「〇日までにご確認いただけると、〇日の作業開始が可能です」という形で、期限と次のアクションをセットで伝える。この書き方は催促ではなく、スケジュールの共有だ。クライアント側も「いつまでに見ればいいか」が明確になる。

「仮承認」で止まらない動き方

全項目の承認が揃わないと動けない、という構造が承認待ちの主要因になっていることがある。

部分的に固まっているものから進められないか、というのが問いになる。たとえばデザインの全体方向性が合意できていれば、細部の調整を待たずに技術的な実装を進められる場合もある。

「仮承認」の運用は、リスクを理解したうえで使うものだ。後から変更が生じたとき、手戻りのコストをどちらが負担するかを事前に合意しておく。その前提があれば、承認待ちで止まる範囲を最小化できる。

外部メンバーに「承認が来るまで待機」を続けさせるのは、コストの問題でもある。稼働を保留している間も時間は流れる。

並行して動ける工程を設計する

承認待ちを前提としたスケジュールを作るとき、並行して進められる工程を意図的に用意しておくことができる。

承認が必要な箇所と、承認なしで進められる箇所を案件開始時に仕分けておく。承認待ち期間に「やること」があれば、チームは止まらなくて済む。

この仕分けは、外部メンバーへの指示にも直結する。「承認が来たら次に進む」という受け身の設計ではなく、「承認待ちの間はこちらを進める」という能動的な設計に変わる。

タスク管理ツールで承認依頼の状態を可視化しておくことも有効だ。誰が何を待っているかが見える状態にすることで、詰まりに気づくのが早くなる。

クライアントを動かす「情報設計」

承認が遅れるのは、クライアントが判断材料を持てていないからであることが多い。何を確認すべきか、どこを見て何を決めればいいかが伝わっていないと、確認そのものが後回しになる。

承認依頼は「見てください」ではなく「この3点についてご判断をお願いします」という形にする。確認事項を絞り、判断に必要な情報をあらかじめ整理して渡す。クライアントが動きやすい状態を作るのは、受け取る側の仕事だ。

越境チームでクライアントワークを動かすとき、承認プロセスは外部の問題ではなく、設計の問題として扱う必要がある。待つことを前提にした仕組みは、消耗を当たり前にする。