Slackに招待されると、名前の横に「(ゲスト)」と表示される。招待されたチャンネル以外は見えない。ワークスペース全体のメンバー一覧を見ることもできない。
これは意地悪な設計ではない。情報の範囲を区切るという、まっとうな目的のための仕組みだ。
ただ、区切り方には選択がある。「この案件のことだけ知っていればいい人」として扱うか、「この案件については、うちのメンバーと同じ立場の人」として扱うか。多くのツールは前者を選んでいる。ラベルという形で、それを毎回、相手の目に見えるところに置く。
ラベルは、機能であると同時にメッセージだ
権限を制限すること自体は、悪いことではない。むしろ必要な場面は多い。
問題は、その制限のかけ方が「あなたは内側の人間ではない」というメッセージを、意図せず発信してしまうことだ。招待された側は、自分の名前の横に付いたラベルを見て、自分がどう扱われているかを理解する。ラベルは静かだが、雄弁だ。
そしてこの扱われ方は、実際の働き方に影響する。
「自分はゲストだから、これ以上は口を出さない方がいいかもしれない」。「聞きたいことがあるけど、メンバー一覧を見られない自分がここで質問していいのか分からない」。「この情報は自分には共有されていないのかもしれないから、確認してから動こう」。
こうした一瞬のためらいが、外部の協力者の仕事の速度と質を、少しずつ削っていく。技術的な制限ではなく、心理的な距離として。
「管理する」という言葉が先に立つと、設計もそうなる
外部の協力者について語るとき、私たちは「招待する」「管理する」「アクセスを許可する」という言葉を使う。この言葉づかい自体が、すでにある前提を含んでいる。外の人は、デフォルトでは信頼されておらず、都度、範囲を許可されることで初めて動ける存在だ、という前提だ。
この前提から設計を始めると、自然と「まず制限し、必要な分だけ開放する」という形になる。安全側に倒すという意味では合理的に見える。だが、実際に一緒に仕事をする相手に対して、この前提を常に運用することが本当に必要なのかは、別の問題だ。
外注先やクライアントの多くは、こちらが対価を払って仕事を任せている、あるいは対価を受け取って仕事を任されている、対等な協力者だ。潜在的なリスクとしてまず疑い、次に必要な分だけ信頼を割り当てる、という順番でしか設計できないわけではない。
信頼を、都度証明させる設計をやめる
Paqutを設計するとき、外部の人を「案件(グループ)に招待された人」として扱うことにした。グループの中では、社内のメンバーと同じようにタスクを見て、コメントを残し、進捗を更新できる。「ゲストだからここまで」という別枠の権限体系を、あえて作らなかった。
これは無防備な設計ではない。グループの外の情報は最初から見えない。他の案件、他のクライアント、社内の別の会話には触れられない。境界線は引かれている。ただしその境界線の内側では、その人を「格下の参加者」として扱う仕組みを持たせなかった。
外の人を、都度信頼を証明させる対象として扱うのをやめる。招待した時点で、その案件については仲間として扱う。これだけのことだが、実際に体験すると違いがわかる。
自分の名前の横に何も付いていない。メンバー一覧を隠されていない。「ここから先は見せられません」という表示に何度も当たらない。これだけで、外の協力者が委縮せずに動けるようになる。
価格ではなく、この前提の話をしたい
外部の人を招待するときの料金がどうなっているか、という話は確かに実務上重要だ。私たちもその情報を整理してきたし、これからも続ける。
しかし、それだけでは伝わらないことがある。多くのツールが外部の人を扱うときの根底にある前提——「まず疑い、必要な分だけ許可する」——に、私たちは同意していない。
対価を払って、あるいは対価を受け取って一緒に仕事をする相手は、都度資格を証明させる対象ではなく、その案件の中では対等な仲間だ。Paqutの設計は、この考え方の上に立っている。
案件に招待された人は、その案件の中では仲間として扱われます。ゲストという別枠のラベルは、Paqutにはありません。
関連記事
創業のきっかけ:タスク機能はあった。それでも、仕事は流れて消えた。
「念のため」の連絡について:「念のため」のCCが、外部の協力者との仕事を渋滞させている
越境チームという考え方:会社の垣根を超えたチームで仕事をする時代の、新しいタスク管理の定義