部門間のコミュニケーション問題をどう解決するか：情報共有とエスカレーションの仕組みを整える
部門をまたぐ仕事が止まったら、まず不足しているものを確かめます。必要な相手に情報が届いていないのか、同じ言葉を別の意味で理解しているのか、それとも状況は共有できているのに決める権限がないのか。催促を増やしても、この三つを同時には解決できません。 最初は進行中の仕事を一つ選び、既存の共有記録に変更点、影響、必要な返答、判断期限を書きます。担当者だけでは決められないことは、組織の既存ルートで判断できる人に相談します。
「連絡済み」の先を確認する
説明用の例として、デザイン部門がイベント画像の納品を水曜から木曜に変更したとします。運営側が水曜の確認作業を予定したままなら、通知先を調べます。デザイン部門内だけに投稿されていたなら、依存する担当者への連絡が必要です。
運営側も読んでいたものの、「完成」を公開可能なデータだと思い、デザイン側は初稿を意味していたなら、納品条件をそろえます。双方が確認時間の不足を理解していても、イベント日を動かせないなら判断の問題です。相手の協力姿勢を評価する前に、実際の記録でどこが止まったかを確認します。
最新の結論を探せる場所に置く
既存のタスクやプロジェクト文書に、成果物、合意した納期、担当者、後工程を残します。変更時は「公開用画像は木曜に変更、文章は予定どおり、運営の確認期間は一日短くなる」と差分を明示します。部署ごとに別の添付資料を持つより、同じ記録へのリンクを知らせる方法を検討してください。
チャットで知らせ、必要なら短く話し合い、その結論を記録に戻します。GitLab も対面などの会話の結論を文書に残す方針を公開しています。ただし、共有範囲は自社のアクセス規則に従います。
何を返してほしいかを書く
情報を知るだけの人、日程を再確認する人、選択肢を決める人は同じではありません。「ご確認ください」だけでは、その違いが伝わりません。「木曜に画像を受け取った場合、金曜午前に確認を終えられるか回答してください。難しい場合は不足する時間や資料を教えてください」と依頼します。
回答期限は後工程に必要な時点から決め、勤務時間も考慮します。全員の了承返信が常に必要なわけではありません。Atlassian の案内も、仕事への貢献者と影響を受ける人を区別し、情報、連絡手段、頻度を決めています。
判断が必要な形で相談する
権限を超える日程や資源の衝突は、確認済みの条件と実行可能な案を整理して相談します。イベント日を守って最初の素材数を減らす案と、素材をそろえて日付を変更する案では、負担が違います。未合意の部分も残し、好みの案だけを唯一の答えとして出さないようにします。
誰に相談するかを相手にも伝えます。Atlassian の手順も双方の選択肢と各案の利点・不利益を理解した上で、適切な判断者につなぐ形です。外部の推奨日数を一律の待機期間にせず、既存の期限と影響に合わせます。
決定を実行につなげる
決まった内容、判断者、実行担当者、適用時点を元の記録に戻し、旧予定が無効になったことを知らせます。「読みました」は新しい納品責任の引き受けとは限りません。必要な担当者には明確な確認を取ります。
次の確認では、情報が見つかり、返答が明確になり、判断が適切な人に届き、新しい予定で仕事が進んだかを見ます。一つの更新と短い相談で足りるなら、その簡潔さを保ちましょう。