プロジェクトが遅れると、人を探したくなる。

誰かが遅かったのではないか。誰かが確認を怠ったのではないか。誰かの対応が遅かったのではないか。

社内のチームであれば、少なくとも同じ場にいて、状況を共有できる。しかし越境チームでは、その感覚すら共有されていないことが多い。遅れの原因を探すと、「誰かが悪かった」というよりも、「構造がそう動かせた」という結論に至ることが多い。

越境チームで遅延が起きる、構造的な理由

遅延の多くは、情報の流れが途切れるところで起きる。

越境チームでは、同じ組織の人間と外部メンバーが混在している。全員が同じ場所にいない。リアルタイムで状況を把握できるメンバーと、できないメンバーがいる。

社員であれば、隣の席で何が起きているかを自然に把握できる。外部メンバーにはそれがない。何かが止まっていても、止まっていると気づくタイミングが遅れる。

また、外部メンバーは複数の案件を持っていることが多い。「この案件が詰まっているから、別の案件を進める」という動きをしたとき、発注側にはそれが見えない。返答がないと思っていたら、相手は別のタスクを進めていた、ということが起きる。

「待ち」が積み重なる

越境チームの遅延でよくあるのが、「待ち」の積み重ねだ。

Aがデザインをあげる。BがAに確認を求める。Aは別の案件で忙しい。2日後にAが返信する。BはAの返信を受けてCに共有する。CはBの共有を見て作業を始める。

この連鎖が複数走っていると、一つの待ちが次の待ちを生む。最初の数日の遅れが、締め切り直前に倍増して現れる。

誰が悪かったわけでもない。それぞれが自分のタイミングで動いていた。しかし構造として、「待ち」が見えにくく、積み重なりやすい状態になっていた。

承認が止まるところで、時間が消える

外部メンバーが何かを作る。発注側が確認する。発注側がクライアントに確認を求める。クライアントが返信する。発注側が外部メンバーに戻す。

この承認フローに、1〜2日かかることがある。案件の中でこのフローが5回あれば、それだけで1〜2週間消える。

外部メンバーからすると、自分は時間通りに動いている。発注側からすると、クライアントが遅い。クライアントからすると、確認依頼が急すぎる。全員が自分の立場では正しく動いているのに、全体が遅れる。

これは誰かの怠慢ではなく、承認の構造が時間を消費する設計になっているから起きる。

遅れを責めても、次の遅れは防げない

プロジェクトが遅れたとき、誰かを責める方向に動くと、次の遅れを防ぐことはできない。

責められた外部メンバーは、次からより慎重になる。確認の頻度が増え、作業スピードが落ちる。「怒られないように動く」という行動原理になる。

遅れの原因が構造にあるなら、構造を変えることが唯一の解決策だ。

具体的には、「待ち」を可視化することが有効だ。誰かが誰かの返信を待っている状態を、タスク上で見えるようにする。承認フローを短くする。確認に必要な情報を最初に集めておく。

「次はどう動くか」だけを話す

プロジェクトが遅れたあとに必要なのは、原因の追求ではなく、設計の見直しだ。

誰が遅かったかではなく、何が待ちを作ったか。誰の確認が遅かったかではなく、承認フローをどう変えるか。

越境チームで一緒に働く人たちは、それぞれ自分の文脈で最善を尽くしている。遅れを生んだのは人ではなく、そのチームが置かれた構造だ。

責める代わりに、その構造を変える会話をする。それが、次のプロジェクトを速くする唯一の方法だ。