トラブルが起きて、原因を探す会議が開かれる。社内のメンバーが集まる。外部の協力者は、その会議に呼ばれない。

呼ばれない理由に悪意はない。単に、社内の会議に外部の人を毎回呼ぶ習慣がないだけだ。しかしこの会議の中で、原因の仮説がいくつか出る。「あの部分、外注先が対応した箇所じゃなかったっけ」。この一言が出た瞬間、会議室にいない人に、疑いの一票が入る。

反論できない人から、疑いが確定していく

会議室にいる人には、反論する機会がある。「いや、それは自分が最終確認した」「その仕様は途中で変更したはず」。その場にいる人の発言は、その場で検証され、間違っていれば訂正される。

会議室にいない人には、この機会がない。「外注先が対応した箇所」という仮説は、本人が何も言わないまま、会議の中で少しずつ既成事実になっていく。後で本人に確認が来たときには、既に「濃厚な原因」として扱われていることもある。

これは誰かが意図して外部の人を貶めているわけではない。反論できる人の声だけが、その場の結論に影響を与えるという、単純な力学だ。

疑われやすさは、実力とは無関係に生まれる

外部の協力者が疑われやすいのは、仕事の質が低いからではない。物理的に、あるいは慣習的に、原因究明の場にいないからだ。

同じミスが起きたとき、社内のメンバーが担当していれば、「Aさんに聞いてみよう」で終わる話が、外部の協力者が担当していると「外注先に問題があったのでは」という一段階抽象的な疑いに変わりやすい。名前ではなく「外部」という属性で語られ始めると、検証よりも先に、印象が固まってしまう。

外部の協力者からすれば、これは理不尽だ。自分の仕事の質は変わっていないのに、同じ状況で疑われる確率だけが上がっている。

疑いが確定する前に、本人の声を運ぶ

対応策は、原因究明の場に外部の協力者を毎回呼ぶことではない。それは現実的ではないし、必要以上に大きな会議になる。

必要なのは、外部の協力者に関する仮説が出た時点で、確定させる前に本人に確認を取る習慣だ。「その部分、〇〇さんが対応したはずだけど、経緯を知ってる人いる?」ではなく、「その部分について、〇〇さんに直接聞いてみよう」という一段階を挟む。

この一段階があるかないかで、疑いが「確認中の仮説」のまま止まるか、「ほぼ確定した原因」として広まるかが変わる。本人の声が届く前に結論が固まってしまうことを防ぐのが、この習慣の役割だ。

記録が、不在の代わりになる

もう一つ有効なのは、誰が何をいつ対応したかの記録を、会議の外にいる人にも見える形で残しておくことだ。

記録があれば、会議室にいない人の代わりに、記録がその人の立場を説明してくれる。「この部分は、この日にこの指示で対応している」という記録が残っていれば、印象だけで疑いが確定することを防げる。会議に呼べない代わりに、記録を会議に出席させる、という考え方だ。

不在は、罪ではない

会議に呼ばれないことも、リアルタイムでその場にいられないことも、外部の協力者にとって避けようのない構造だ。それ自体は悪いことではない。

問題になるのは、不在が「疑われやすさ」に静かに変換されてしまうことだ。この変換が起きていることに気づいていれば、原因究明のたびに一段階、本人への確認を挟む余地が生まれる。気づいていなければ、外部の協力者は、身に覚えのない疑いを何度も静かに引き受け続けることになる。


タスクの記録がPaqutに残っていれば、誰が何をいつ対応したかを、会議に呼ばれなかった人の代わりに示すことができます。不在が疑いに変わる前に、記録が事実を運びます。

Paqutを無料で試す →

関連記事

遅延と責任について:越境チームでプロジェクトが遅れるとき、誰も悪くない

ファイルと経緯について:ファイルは送れる。でも、なぜそうなったかは送れない。

「ゲスト」という扱いについて:「ゲスト」というラベルが、外の人に何を伝えているか

手柄の行方について:プロジェクトが成功したとき、手柄はその場にいた人に流れる

ミスの届き方について:社員のミスは、外に出る前に誰かが拾う。外部の協力者のミスは、直接届く。

存在の証明についての考え方:社内では席にいることが仕事の証明になる。外部の協力者には、返信の早さしか証明がない。

判断の出どころについての考え方:外部の協力者が出した結論は、社内の会議室でもう一度、別の人の名前で決められる

責任の線引きについての考え方:クライアントの前では会社の看板を背負わされる。トラブルのときは、個人の責任にされる。

中止の理由が伝わらないことについての考え方:社内の都合でプロジェクトが止まるとき、社員には理由が伝わる。外部の協力者には「見送りになりました」としか届かない。