Slackのユーザーアカウントの設計思想について

Question

###Slackを試用してみての感想

参加するチームごとにアカウント作成、パスワード設定が必要

Slackを試用してみましたが、ユーザーアカウントについて、どうもその設計思想が理解できず、質問させていただきます。

2つのチーム（自分だけがメンバーのテストチームですが）に参加した私は、すでに2度、下記の作業を繰り返しました。

• 招待メールから、PCでチームに参加
• プロフィール名設定、パスワード設定
• 携帯番号を登録
• 送られてきたSMSで番号を認証
• 2段階認証のためのコードを取得（Authy）
• もしもの時のための、復旧コード10桁の数字10パターンをテキスト保存
• スマホでチームに参加（チームアドレス入力、メールアドレス入力、ログインリンク取得）
• タブレットでチームに参加（チームアドレス入力、メールアドレス入力、ログインリンク取得）

「チームに参加する度に、この操作を繰り返すのか。他人に勧めづらい…」

それが感想です。

「Googleアカウントでログインできるよ～」で済む話ではない気がします。

「プロフィールをチーム毎に変えられるよ」というのも、やるならオプションで対応して欲しい。

###ユーザーのパスワード管理の仕方

私は、基本的にOpenIDによるID連携は使いません。
（不意に、本名、プロフィール写真が出たり、メールアドレスがバレたりなど）

こうした設計になった理由として考えられるのは、「1ID、1パスワードだけだと、もしIDパスワードが流出したら、全てのチームにアクセスできてしまい危険。」という理由だけでしょうか？

私は、LastPassというパスワード管理を使用しておりますので、アカウントごとにパスワードを変える事に、なんら抵抗はありません。

そんな私でも、チーム毎の携帯番号登録、2段階認証登録、復旧コードなどの管理には、目眩がする思いでした。

まだまだ大多数であろう、「そうしたパスワード管理ツールを使っていない人達」は、Slack内では、すべて共通のパスワードを使うであろう事は、想像に難くありません。

「Slackはパスワードを入力しなくても、ログイン認証済みのURLをメールで送ってくれるので、覚える必要はない。」
そんな風に考えて、自分の入力したパスワードを管理しないと割り切れる人は、少ないと思います。

まぁ、ユーザー認証の歴史は、紆余曲折ありますので、楽しんで見てます。

「アクセシビリティ」と「セキュリティー」のタグを付けましたが、その両者のせめぎ合いという普遍的なテーマであるようにも思いますが、このアプローチは、「なんか違うんじゃないか」という気がしています。

###伺いたい事

なぜ、このような設計になったと考えられますか？

1ID、1パスワードで自分の所属する（招待された）全てのチームにアクセスできるのは、不都合でしょうか？

さまざまなサードパーティーアプリと連携するには、この方が好都合なんだよとかいう、何か理由があれば、伺いたいです。

今後、このような設計のサービスは増えると予想されますでしょうか？

「パスワード入れなくていいから、メールに送ったリンクから入ってね」というのは、今後、流行ると思いますか？

Slack自体を、まだ理解しておりませんので、的外れな所があるかもしれませんが、よろしくお願いします。

###追記
「チームの作り方」について、間違った認識でいました。
いただいた回答のやり取りの中で、有償プランについて出てきて、それ見て納得できました。

Slackの利用については、いくつか協業している会社をまたいで、プロジェクト毎にチームを作っていけたらなと思っていましたが、認証の所で、尻込みしてしまいました。

プロジェクト毎に、毎回ほぼメンバーが同じ、5人中4人が同じで、残り一人がそれぞれ違う。つまりは「クライアントが変わる」のですが、それで毎回チームを作っていくのは変ですか？

1プロジェクトに2～3チャンネルずつくらい割り当てて、一つのチームだけでやっていくのは、難しいですよね？
クライアントから見たら、「同じチームの中に、よその全く知らない会社の人がいる」ってなってしまいますもんね？

「チーム」を、LINEのグループのような捉え方をしていたので、そこから間違ってました。
有償プラン入らないと、Slackを理解できなさそうというのが、結論だったっぽいです。

SAML認証って何…

Answer 1

slackというレンタルサーバに会員制サイト（チーム）を開くと考えればしっくりくるのではないでしょうか。会員制サイトのユーザIDを持っていたとしても他のレンタルサーバへのアクセスが出来たり、運営が別の会員制サイトのユーザが無制限にアクセスできるというのは会員制サイトとしてありえません。そういった意味でそもそもとしてチームをまたいでの情報（ユーザ）の共有というのが設計外なのだと考えています。

チームという言葉に惑わされますが、slackのチームというのは部署や会社単位のものだと思います。
チームの下にチャンネルというものがありますのでチャンネルを小規模なチームに割り振ってコミュニケーションをすれば良いのではないでしょうか。特にチャンネルは公開、非公開を選べますので重宝するはずです。

Comments

[pack]

ありがとうございます。

現実世界に置き換えてみると、判りやすいですね。
病院の診察券、銀行の口座、就職の履歴書。
毎回、名前と住所と生年月日と…
キリがないですね。

ネットの世界では、そうした垣根を越えられるんじゃないかという理想を、私個人的には、持っているのかなと思います。

病院間でのカルテデータの共有、Felicaを使ったポイントカード、電子マネー、マイナンバーなどもそうですかね。
OpenIDがその最たる例だと思いますが。

どうしても、そうした時代の流れと逆行してる気がして、敏感に反応してしまいます。
というか、今まで見た事がなかったので驚いているという所ですが。
逆に、IDパスワードに対する認識の、何か転換点に来てるのかなという印象も受けましたが。
二段階認証も、一つの発明だといわれていますが、今後どのような認証方式が出てくるかも、楽しみです。

チャンネル毎に、細かくメンバーにアクセス権を付与できる、メンバー間のプライベートメッセージなど、オーバースペック気味かな、もっとシンプルでいいのに、とも思いましたが、これも一つの世界なんですよね。

一つのチームが、一つの宇宙、みたいな。

となりのチームは、平行宇宙なんだと。
それくらい壮大に考えて、バーチャルな宇宙空間への入り口としてのパスワード認証とすれば、納得できない事もないですが。

きっと、Slackの開発チームも、遠い未来を見据えて、バーチャル空間でのコミュニケーションがどうあるべきを、考えてるんでしょうね。

Slackの利用については、いくつか協業している会社をまたいで、プロジェクト毎にチームを作っていけたらなと思っていましたが、認証の所で、尻込みしてしまいました。
また様子を見ながら、勧めていければと思っています。

[pack]

すみません。ちなみに、チームの作り方として一点伺いたいのですが。

プロジェクト毎に、毎回ほぼメンバーが同じ、5人中4人が同じで、残り一人がそれぞれ違う。つまりは「クライアントが変わる」のですが、それで毎回チームを作っていくのは変ですか？

1プロジェクトに2～3チャンネルずつくらい割り当てて、一つのチームだけでやっていくのは、難しいですよね？
クライアントから見たら、「同じチームの中に、よその全く知らない会社の人がいる」ってなってしまいますもんね？

[matsu]

Slackのやり方ってサービスとしては新しいのでしょうけど今あるテクノロジー（枯れかけ？）でうまく動かすというのなんじゃないかと感じています。

確かにプロジェクト毎にクライアントが変わるというのであれば毎回チームを作るという運用をしたくなると思います。でも多分Slackではそういう運用を想定をしていないでしょう。

ちょっと気になったのはそのプロジェクトって同時進行なのでしょうか？
同時進行でなければユーザの追加と停止でまかなえないですかね？

[kaz.Suenaga]

横槍すみません。

> 1プロジェクトに2～3チャンネルずつくらい割り当てて、一つのチームだけでやっていくのは、難しいですよね？
> クライアントから見たら、「同じチームの中に、よその全く知らない会社の人がいる」ってなってしまいますもんね？

そこで有償プランのシングルチャンネルゲストや制限アカウントが活きてくるように設計されているんじゃないでしょうか。
参考） http://www.freia.jp/taka/blog/slack-faq-restricted-accounts-and-single-channel-guest/

[matsu]

なるほど、無料部分しか使ってなかったから知りませんでした。

[pack]

ファイアウォールかよ
って思いますね。
DMZ設けたり。あとネットワークセグメント分けたり。

これ、（人の）ネットワーク管理者一人立てないと、運用は無理ですね。

ありがとうございます。有償プランの方見て、納得できました。
正直言うと、このチームの作り方を先に聞きたかったんです。
前提となる、その辺のレイヤーの認識に違いがあるのかなと思っていたので。

でも、それ「Slackの使い方」であって、teratailで聞けることじゃないよなってのがあって、「設計思想について」と仰々しいタイトル付けてたりして、私自身も質問の方向が間違ってたなと思います。

なるほど。そこで課金の罠が待っていたという事ですね。
まぁ、課金サービスに対して抵抗がある訳ではないので、当初から有償プランの方で検討していきます。

[pack]

有料プランには、「SAML-based single sign-on (SSO)」とあるので、その辺が、Slackの答えなんでしょうね。

SAML認証が何かも解ってないので、ちんぷんかんぷんですが。