Slackに招待されると、名前の横に「(ゲスト)」と表示される。招待されたチャンネル以外は見えない。ワークスペース全体のメンバー一覧を見ることもできない。

これは意地悪な設計ではない。情報の範囲を区切るという、まっとうな目的のための仕組みだ。

ただ、区切り方には選択がある。「この案件のことだけ知っていればいい人」として扱うか、「この案件については、うちのメンバーと同じ立場の人」として扱うか。多くのツールは前者を選んでいる。ラベルという形で、それを毎回、相手の目に見えるところに置く。

ラベルは、機能であると同時にメッセージだ

権限を制限すること自体は、悪いことではない。むしろ必要な場面は多い。

問題は、その制限のかけ方が「あなたは内側の人間ではない」というメッセージを、意図せず発信してしまうことだ。招待された側は、自分の名前の横に付いたラベルを見て、自分がどう扱われているかを理解する。ラベルは静かだが、雄弁だ。

そしてこの扱われ方は、実際の働き方に影響する。

「自分はゲストだから、これ以上は口を出さない方がいいかもしれない」。「聞きたいことがあるけど、メンバー一覧を見られない自分がここで質問していいのか分からない」。「この情報は自分には共有されていないのかもしれないから、確認してから動こう」。

こうした一瞬のためらいが、外部の協力者の仕事の速度と質を、少しずつ削っていく。技術的な制限ではなく、心理的な距離として。

「管理する」という言葉が先に立つと、設計もそうなる

外部の協力者について語るとき、私たちは「招待する」「管理する」「アクセスを許可する」という言葉を使う。この言葉づかい自体が、すでにある前提を含んでいる。外の人は、デフォルトでは信頼されておらず、都度、範囲を許可されることで初めて動ける存在だ、という前提だ。

この前提から設計を始めると、自然と「まず制限し、必要な分だけ開放する」という形になる。安全側に倒すという意味では合理的に見える。だが、実際に一緒に仕事をする相手に対して、この前提を常に運用することが本当に必要なのかは、別の問題だ。

外注先やクライアントの多くは、こちらが対価を払って仕事を任せている、あるいは対価を受け取って仕事を任されている、対等な協力者だ。潜在的なリスクとしてまず疑い、次に必要な分だけ信頼を割り当てる、という順番でしか設計できないわけではない。

信頼を、都度証明させる設計をやめる

Paqutを設計するとき、外部の人を「案件(グループ)に招待された人」として扱うことにした。グループの中では、社内のメンバーと同じようにタスクを見て、コメントを残し、進捗を更新できる。「ゲストだからここまで」という別枠の権限体系を、あえて作らなかった。

これは無防備な設計ではない。グループの外の情報は最初から見えない。他の案件、他のクライアント、社内の別の会話には触れられない。境界線は引かれている。ただしその境界線の内側では、その人を「格下の参加者」として扱う仕組みを持たせなかった。

外の人を、都度信頼を証明させる対象として扱うのをやめる。招待した時点で、その案件については仲間として扱う。これだけのことだが、実際に体験すると違いがわかる。

自分の名前の横に何も付いていない。メンバー一覧を隠されていない。「ここから先は見せられません」という表示に何度も当たらない。これだけで、外の協力者が委縮せずに動けるようになる。

価格ではなく、この前提の話をしたい

外部の人を招待するときの料金がどうなっているか、という話は確かに実務上重要だ。私たちもその情報を整理してきたし、これからも続ける。

しかし、それだけでは伝わらないことがある。多くのツールが外部の人を扱うときの根底にある前提——「まず疑い、必要な分だけ許可する」——に、私たちは同意していない。

対価を払って、あるいは対価を受け取って一緒に仕事をする相手は、都度資格を証明させる対象ではなく、その案件の中では対等な仲間だ。Paqutの設計は、この考え方の上に立っている。


案件に招待された人は、その案件の中では仲間として扱われます。ゲストという別枠のラベルは、Paqutにはありません。

Paqutを無料で試す →

関連記事

創業のきっかけ:タスク機能はあった。それでも、仕事は流れて消えた。

「念のため」の連絡について:「念のため」のCCが、外部の協力者との仕事を渋滞させている

越境チームという考え方:会社の垣根を超えたチームで仕事をする時代の、新しいタスク管理の定義