結論：クライアントの「急ぎ」に振り回されるのは、緊急対応の構造がないから。急ぎの定義の共有・影響の可視化・対応体制のバッファ設計・急ぎを生む構造の解消、4 つの原則で、緊急対応を「構造の中に飲み込む」体制が作れる。
水曜の午後 3 時。「今週中にどうしても必要で」とクライアントから連絡が来る。
担当のデザイナーは今日中に別の案件の納品がある。エンジニアは明日の MTG に向けて実装を詰めている。PM は、この「急ぎ」をどこに差し込めるかを考え始める。
誰かが今やっていることを止める。または、誰かが今夜残業する。
翌週、また「急ぎで」が来る。
クライアントの急ぎの連絡は避けられません。問題は、急ぎが来るたびにチームが揺れることです。揺れないためには、設計が要ります。
この記事は、クライアントの「急ぎ」を振り回されずに捌く、4 つの原則を整理します。
1. なぜ「急ぎ」でチームが振り回されるか
クライアントの急ぎの連絡がチームを揺らす理由は、3 つあります。
1 つ目は、緊急対応の体制がない。全員が常時 100% の稼働で動いていると、急ぎが来た瞬間にどこかが詰まります。バッファがなければ、急ぎは誰かの仕事を押しのけることでしか入れられません。
2 つ目は、急ぎの定義が共有されていない。クライアントが「急ぎ」と言うとき、その背景は様々です。「実は翌週の会議で使いたい」のに「急ぎ」と言っている場合もあれば、本当に翌日必要な場合もある。定義が共有されていないと、全ての「急ぎ」を最高優先で受けることになります。
3 つ目は、急ぎを生む構造が解消されていない。クライアントが急ぎの連絡を送る背景に、見えないことへの不安がある場合があります。進捗が見えていれば「急ぎで確認したい」が消える案件も、見えないから急ぎになります。
これらを整理する設計が、急ぎに振り回されない体制の基盤です。
2. 原則 1：「急ぎ」の定義をクライアントと共有する
最初の原則は、「急ぎ」の定義を事前にクライアントと合わせておくことです。
多くのクライアントは「急ぎ」の定義を考えたことがありません。「少し急いで」が翌日なのか翌週なのか、本人も明確でないことがある。
案件開始時に確認します。
- 「緊急案件の場合、どれくらいのリードタイムを想定しますか？」
- 「通常の修正依頼は 3 営業日でお届けしていますが、緊急の場合は 1 営業日での対応が必要ですか？」
- 「急ぎ対応が発生した場合、他の作業との優先順位はどう考えますか？」
この会話を一度することで、クライアント自身が「急ぎ」の意味を整理します。「翌日でなくてもよかった」案件を「急ぎ」として扱う頻度が下がります。
急ぎの定義が共有されると、「急ぎ」が来たときに「今回の急ぎは何日以内に必要なものですか」と確認できます。背景を把握した上で対応の組み立てができます。
3. 原則 2：対応の影響を具体的に見せる
2 つ目の原則は、急ぎの依頼を受けたとき、対応することで起きる影響を具体的に示すことです。
「承知しました、対応します」と即答すると、クライアントには「急ぎが通じる」という学習が起きます。次の急ぎも同じように依頼してきます。
代わりに、影響を具体的に伝えます。
- 「この週の急ぎ対応には対応できますが、〇〇さんが今進めている A タスクが来週に遅延します。それで問題ありませんか？」
- 「今週中の対応は可能ですが、品質は通常対応より確認の時間が取れないため、修正が発生する可能性があります。了解いただけますか？」
- 「今週中はキャパシティがありませんが、来週初めであれば通常の品質でお届けできます。タイミングはいかがでしょうか？」
影響を伝えることは、断ることではありません。クライアントが「急ぎで依頼することのコスト」を理解した上で判断できる材料を渡すことです。クライアント自身が「来週でも間に合う」と判断できる場合があります。
クライアントと丁寧に合意形成する設計は クライアントの窓口担当者を、外部から支える 3 つの動き でも扱っています。
4. 原則 3：緊急対応バッファをキャパシティに組み込む
3 つ目の原則は、チームのキャパシティの一定割合を「緊急対応バッファ」として意識的に確保することです。
100% の稼働でチームを計画すると、急ぎが来た瞬間に誰かが詰まります。バッファを前提に計画すると、急ぎが来てもチームが揺れません。
現実的なバッファの作り方：
- チームの週次稼働の 20〜25% を「予定に入れない時間」として確保する
- 急ぎがなかった週は、そのバッファをクオリティ改善・技術的な負債の解消に使う
- 急ぎが来た週は、そのバッファを緊急対応に充てる
「毎週 20% 何もしない時間を作る」のではなく、「20% は予定に入れない。急ぎが来たときのためにある」という設計です。
外注メンバーを含む越境チームのキャパシティ管理は、各メンバーの稼働可能時間を事前に把握した上で設計する必要があります。
5. 原則 4：急ぎを生む構造を解消する
4 つ目の原則は、クライアントが急ぎの連絡をしなければならない構造的な原因を解消することです。
急ぎの連絡の多くは、「見えないことへの不安」から来ています。進捗が分からないから、確認が急ぎになる。締め切りが近づいているのに状況が分からないから、急いで聞く。
この不安の根本を解消する設計：
- クライアントが進捗を自分でいつでも確認できる状態を作る（タスク管理ツールに招待する）
- 次の動きの予定を先回りで共有する（「月曜に v2 を共有します」と事前に知らせる）
- マイルストーンごとに状況を定期共有する（「現在 60% 完了、予定通り来週納品見込みです」）
これらが機能すると、クライアントが急いで確認を入れる動機が消えます。急ぎの連絡を「断る」のではなく、「急ぎの連絡を送る理由をなくす」ことが、最も穏やかで持続的な解決です。
進捗の可視化で急ぎの連絡を構造的に減らす設計は 金曜夕方のクライアント連絡で、土曜朝が消える人へ でも整理しています。
まとめ
クライアントの「急ぎ」に振り回されるのは、緊急対応の設計がないからです。
4 つの原則：
- 「急ぎ」の定義をクライアントと事前に共有する
- 対応の影響を具体的に見せる
- 緊急対応バッファをキャパシティに組み込む
- 急ぎを生む構造を解消する
これらが機能すると、急ぎが来てもチームが揺れなくなります。「急ぎが多いクライアント」ではなく、「急ぎが少なくなる関係性」に変わります。
関連記事
進捗の可視化で急ぎを減らす：金曜夕方のクライアント連絡で、土曜朝が消える人へ
クライアント担当者への伴走：クライアントの窓口担当者を、外部から支える 3 つの動き
仕様変更の管理：クライアントの仕様変更に振り回されない設計
Paqut で、急ぎの連絡が来ない状態を作る
Paqut なら 3 ステップで、クライアントが進捗を自分で確認できる環境を作れます。
- 無料プランで自社のワークスペースを 3 分で作る
- クライアントを招待リンクで呼び、進捗タスクをリアルタイムで見せる（追加料金 0 円）
- 1 ヶ月運用して、急ぎの連絡がどれだけ減ったかを実測する
3 分で立ち上がります。