要約

  • 単一チャンネルのゲストは有料プランで無料となり、有料のアクティブメンバー一人につき最大五人を追加できる。複数チャンネルのゲストは通常のメンバーと同様に課金される。
  • 追加チャンネルの申請、管理者の承認、実際の役割とアクセス変更は別の状態である。期限の通知だけで仕事の引き継ぎ完了は証明できない。
  • アクティブメンバー数の変化は招待計画を見直す理由になるが、既存ゲストの自動削除や猶予期間を公開ルールから推定してはならない。

一人のままでも必要な範囲は変わる

外部の協力者が納品用チャンネルで仕事を進め、稼働開始の段階で調整用チャンネルにも参加する必要が出てくる。人が増えたわけではない。契約期間も変わらないかもしれない。それでも、参加すべき情報の範囲は一つから二つへ広がっている。

Slack のゲスト説明では、単一チャンネルのゲストは無料で、一つのチャンネルだけにアクセスできる。複数チャンネルのゲストは指定されたチャンネルにアクセスし、通常のメンバーと同様に課金される。有料の役割であっても、アクセス範囲は限定できる。

このため、調達を人数だけで説明するのは不十分だ。同じ協力者でも、仕事に必要な参加範囲によって期待される課金の扱いが異なる。役割を記録せず、外部人員一人という予算項目だけを残すと、判断の条件が抜け落ちる。

これは隠れた料金の存在を示す話ではない。二つの役割の違いは公開されている。重要なのは、仕事の要件が管理者や調達担当者に届く前に、単なるチャンネル追加という小さな操作として扱われてしまわないことだ。

一つのまとまった作業範囲なら、無料の役割は適切に機能する。異なる情報範囲を分けて保つ必要があり、その両方に協力者が参加するなら、有料の役割にも合理性がある。無料にすることではなく、必要な境界を正しく選ぶことから始めたい。

無料枠には有料の基礎がある

Slack は、有料のアクティブメンバー一人につき最大五人の単一チャンネルゲストを追加できるとしている。説明の例では、十人のメンバーに対し最大五十人を招待できる。ゲストアカウントは有料プランで提供され、無料ゲストだけを独立して拡張できるプランではない。

ここで基礎になるのは、古い社員名簿の人数ではなく、有料のアクティブメンバー数である。外部協力者の招待計画と、社内の利用されていないメンバーを確認する作業には、共通の計画条件がある。

ただし、公開された式から運用の細部まで読み取ることはできない。いつ招待可能数が再計算されるのか、上限を超えた状態をどう扱うのか、猶予期間があるのか、既にいるゲストのアクセスがどうなるのかは、このルールだけでは確定しない。

したがって、人数が減れば既存ゲストが自動的に外される、と書くのは行き過ぎだ。言えるのは、新たな招待を計画するとき、その基礎を再確認する必要があるということまでである。公式の上限、管理者が確認できる現在の状態、未解決の利用資格を分けて扱うべきだ。

課金上の非アクティブと無効化は違う

Slack のフェアビリングポリシーには適用範囲がある。Slack のウェブサイトで購入し、カードまたはセルフサービスの請求書払いで支払うプランと追加サービスが対象だ。個別交渉で締結されたすべての契約に、そのまま当てはめることはできない。

この範囲では、オーナー、管理者、通常のメンバー、複数チャンネルのゲストが有料の役割に含まれる。単一チャンネルのゲストとボットは無料である。メンバーが28日を超えて Slack を利用していなければ、課金上は非アクティブになる。再び利用を始めると、その変化が検知され、請求期間の残り日数に応じた課金が再開する。

これは支払いの分類であり、アクセスを終了した証明ではない。非アクティブなアカウントが必ず無効化されているとは限らない。また、利用がないことだけで、仕事が完了した、残りの課題が引き継がれた、維持されている権限が適切だとも言えない。

請求額が小さくなったことを、アクセスできる範囲が小さくなった証拠として扱うべきではない。費用の確認は権限確認のきっかけになり得るが、代わりにはならない。必要な仕事のために利用が再開したことも、再課金されたという理由だけで問題行動とみなせない。

未使用期間に対するクレジットは将来の支払いに充当される。譲渡や返金はできず、有料プラン終了時に失効する。予算上の意味はあっても、別の購入にすぐ使える現金が戻ったわけではない。

全員が非アクティブになった場合にも、無料版へ変更しない限り、少なくとも一人分が課金されると説明されている。この最低課金は、実際にアクティブな一人が存在する証明でも、その一人に基づくゲスト枠の保証でもない。無料版でゲストアカウントを利用できる根拠にもならない。

承認後の状態まで確かめる

メンバーは単一チャンネルゲストに追加のチャンネルが必要だと申請できる。ワークスペースのオーナーと管理者は、その変更申請を受け取り、承認または却下する。要望を出すことと、アクセス拡大を許可することは別である。

仕事を担当するチームが必要性を説明し、管理者が範囲の拡大を判断する。その後に、実際のアカウントの役割とアクセスできるチャンネルを確認する段階が残る。承認のメッセージだけでは、変更が正しく完了し、期待される課金の扱いも理解されているとまでは証明できない。

長い購買手続きを新設する必要はない。必要な範囲、承認責任者、予定する役割、適用プランや契約の根拠を短く残し、完了後の確認結果を加える方法がある。現在の招待可能数や契約上の扱いが未確認なら、その点も未確認のまま明示する。

これは編集上の提案であり、Slack が義務づける機能ではない。特定の顧客の管理不足を認定するものでもない。プロジェクトの急ぎの要望と、権限や支出の結果が、担当部門をまたぐ間に切り離されるのを防ぐための考え方だ。

期限の通知は引き継ぎを証明しない

管理者は一定期間後の自動無効化、指定日の無効化、期限なしのアクセスを選べる。Slack は、無効化の五日前にゲストと日付を設定したオーナーまたは管理者へ通知すると説明している。

この通知は準備の機会になる。しかし、成果物の受け入れ、残る課題の担当者、協力者なしで仕事を続けるための背景情報までは確認しない。近づいているアクセス変更を知らせるものであり、作業終了の証明書ではない。

期限を設定しても、複数チャンネルのゲストは通常のメンバーと同様に課金される。請求期間の一部だけアクティブであれば、比例したクレジットの扱いがあるという説明だ。アクセス期間を短くすることと、役割を無料にすることは違う。

正当な残作業があれば、承認を得て期限を延ばす判断はあり得る。ただし、誰も引き継がないために延長を重ねると、外部の人への依存を維持しているだけかもしれない。ログインできる状態の存続だけで、仕事の継続能力を証明することはできない。

無料に合わせて情報を混ぜない

複数の仕事を一つのチャンネルへ集めれば、無料の役割を維持できる場合がある。分離すべき情報まで集めるなら、各参加者が見られる範囲を広げることにもなる。これは組織設計上の仮定のリスクであり、Slack で起きた事件を示すものではない。

Slack のゲストと Slack Connect の比較では、ゲストは受け入れ側のワークスペースへ入り、Slack Connect の参加者は自分のワークスペースを利用する。また、ゲストの期限後に受け入れ側が通信やファイルへアクセスする形と、接続されたチャンネルを切断した後に各社が記録を保てる形を区別している。

これは協働の構造と情報を管理する側の違いである。あらゆる場合の保存、削除、書き出し権を保証するものではない。Slack Connect のどんな利用も無料で、すべてのプランで可能だという結論にもならない。別の構造を選ぶなら、その利用条件と情報管理を別に確認する必要がある。

必要な仕事の範囲を決め、その範囲に合う役割を承認し、実際の変更と予想される支払いを一緒に確認する。無料アクセスは、この境界の中で役立つ利点であって、境界そのものを決める理由ではない。

出典