社外の人が仕事に関わるようになると、チームのコミュニケーションに新しい問題が生まれる。社内のSlackに外部の人を招待するのは少しためらう。メールだと反応が遅い。LINEは個人的すぎる。結果として「とりあえずメールで」という運用になり、社内とは全く別のコミュニケーションラインが生まれる。これが積み重なると、「社内では把握されているが外部メンバーには伝わっていない」という状態が頻発するようになる。
社外メンバーが入った瞬間に起きること
社外の人がチームに加わると、情報の流れが複数に分かれる。社内では「あの件、Aさんに確認した」という会話が走る。でもAさん(社外)はそれを知らない。後から「そんな話は聞いていない」というすれ違いが起きる。もう一つよくあるのが、「誰に何を伝えたか」がわからなくなることだ。社外メンバーへの連絡がメールやLINEに分散していると、「Bさんにはもう変更の件を伝えたっけ?」という確認が発生する。
最初に決めておくべきこと
社外メンバーをチームに加えるとき、最初に決めておくべきことは3つだ。一つ目は「社外メンバーが見る場所」を一つに決めること。複数のラインを使い分けると、どこを見ればいいかが相手にとって不明確になる。二つ目は「社外メンバーに見せる範囲」を決めること。その人が関わるプロジェクトのタスクとコメントだけが見える設計にする。三つ目は「相手の参加コスト」をゼロに近づけること。招待リンクを送るだけで参加でき、届いたタスクをその日から確認できる状態が理想だ。
社外メンバーの追加コストを気にしない設計
社外メンバーをチームに招待するとき、ツールによっては「ゲストを追加するとライセンス費が増える」という問題が出る。外注先が増えるたびにコストが増えると、「呼ぶか・呼ばないか」を経費で判断するようになる。本来共有すべき相手に共有のためらいが生まれることで、チームの連携に摩擦が生まれる。社外メンバーを何人招待してもコストが変わらない設計があると、この判断から解放される。
社外メンバーの参加初日に整えておく受け入れ手順
連絡手段を決めただけでは、社外メンバーはすぐには動けない。参加した初日に何を見ればよいかが分かる状態にしておくと、その後のすれ違いが減る。
- 参加の目的と担当範囲を一文で伝える。何を、いつまでに、誰と進めるのかを最初に共有する。
- 見てほしい場所を一つだけ案内する。あわせて、それ以外の場所では依頼をしないことも伝える。
- 連絡の窓口になる社内の担当者を一人決める。質問が来たときに誰も答えない状態を避けるためだ。
- 返信の目安を決める。たとえば「その日のうちに確認する」「急ぎのときは電話する」など、緊急度ごとの手段を分けておく。
- 最初のタスクを一つ渡す。小さな依頼でも、実際に使ってもらうと操作の迷いがその場で分かる。
社外メンバーに見せる情報を切り分ける判断基準
見せる範囲を決めるとき、迷いやすいのが「どこまで共有してよいか」である。次の表のように、情報の種類ごとに考えると整理しやすい。
| 情報の種類 | 共有の考え方 |
|---|---|
| 担当プロジェクトのタスク・期限 | 共有する。作業に直接必要なため |
| 作業に必要な資料・仕様 | 共有する。ただし、その案件に関係するものに限る |
| 社内の評価・人事・費用の話 | 共有しない。別の場所で扱う |
| 他の取引先に関する情報 | 共有しない。契約上の秘密保持にも関わる |
| 過去のやり取りの履歴 | 案件に関係する範囲のみ。参加前の会話が見えてよいかは事前に確認する |
判断に迷うものは、「この人が今の作業をするのに必要か」で決める。必要でなければ見せない。後から追加で見せることはできるが、一度見せた情報は取り消せない。契約が終わった時点でアクセスを外す手順も、参加時にあわせて決めておきたい。
受け入れの手順は、文書にして残しておくとよい。次に社外メンバーが増えたときも、同じ手順を繰り返すだけで済む。手順書には、招待の方法、最初に渡す情報、連絡の窓口、終了時の対応の四つを書いておけば十分だ。
まとめ
社外メンバーをチームに入れるとき、コミュニケーションの設計を最初に決めないと、情報が複数のラインに分散してすれ違いが増える。「社外メンバーが見る場所を一つに決める」「見せる範囲を決める」「相手の参加コストをゼロに近づける」この3つを最初に設計するだけで、社外との連携が安定する。
FREE TO START
社外メンバーを、招待リンク1本でチームに入れる
外部ゲストは何人でも無料。プロジェクトごとにアクセス範囲を分けられます。3分でセットアップできます。
Paqutを無料で試してみる →