見出し画像

新米情シス的Slackの苦悩

#ポエム

こんにちは、a03です。

苦悩しています。
世の中のみなさん、諸先輩方は一体どうしているのでしょうか?

また、日本以外の国ではどうしているのでしょう?

そんな悩みをつらつら書き殴っています。


諸先輩方のありがたい記事

新米の苦悩よりも、これらの記事の方が有用と思いますので、先にご紹介させてください。


以下、自分の整理のためにもつらつら書いてみます。


組織の拡大とチャンネルのあり方〜単一責任・責務の分離

人数が10人くらいでチャンネル数も10個くらいなら、特にあれこれと気にせず使ってもまあそんなに支障はない。

しかし、徐々にごちゃごちゃしてくる。

そのゴチャゴチャの変遷を考えてみたのが以下のスライド画像である。

フェーズ1 牧歌期

人数が少ないうちは、適当でもチャンネル1個でもなんとかなる

フェーズ2 混沌期

人数が増える=情報量も増えると1つの塊の中で処理は困難になってくる

フェーズ3 成熟期

それぞれの責務に応じたチャンネルに分けて見通しをよくする。

※会社の規模、フェーズ、事業にもよるので、正解はない。ここに挙げたのはあくまで例ということで。また、ここに挙げた例は、実在の組織、団体とは一切関係ありません。

単一責任・責務を分離する、という考え方は幅広く使える。
この辺のことは、ミノ駆動本から考え方を学んだ。


チャンネル名称問題

#general名前変えるか変えないか

#generalの名前を変えない方が良い、という話を聞いたことがあります。
その意図として、#generalと#randomはSlackのワークスペースを新規作成した際にデフォルトで作られるチャンネルとして馴染みがある、generalは通常のチャンネルと異なりユーザーは退出が出来ないから、との意見を受けたことがあります。

これについては様々な意見があるかと思いますが、組織の命名規則に基づいてgeneralから名称変更することも仕方ないかと思っています。
generalから名称変更した際には、チャンネルの説明やトピックにその旨を書いておくと親切でしょうか。
旧名称を確認できるとはいえ、トピックや説明に書いておく方がわかりやすいかなと。

Slackが公式に#generalについて説明しているページはこちらです。


そのチャンネルがgeneralなのかどうかは"is_general"、変更前のチャンネル名称は"previous_names"でわかるといえばわかる。

連番使うか否か

これも決めの問題ではあると思いつつ。
番号使っておくと、番号順に並ぶのでわかりやすいといえばわかりやすい。

他方で、チャンネルの増減、改廃に伴って番号を振り直す手間はある。
加えて、連番を振っておいても、すべてのチャンネルに参加していない限り、歯抜けで表示されることになったりもするし、すべてのチャンネルに参加していたとしても、スター付きにしたりカスタムセクションを使っていたりするとまた表示がガチャガチャする。


使用する文字は英字のみ?

チャンネル名称には漢字やカタカナ、ひらがなも使える。

#channel_a
#channel_b
#channel_c
#channel_あいうえお
#channel_漢字

グローバル企業とか社内公用語が英語というところは、チャンネル名称は英語のみとしているところもあるかもしれない。
漢字を使った場合、表示されたときの圧が強いと感じる人もいるようだった。

なお、現時点(2023/02/23)では、チャンネル名称に絵文字は使用できない。

話は逸れるが、絵文字の使用を想定していない箇所で絵文字が使えてしまい、その絵文字が原因でエラーとなった例があった気がする(詳細失念した。バリデーションしておけ、という方向もあるとは思う)

ファイル名に空白やドットが入っていたことによるエラーも稀によくある(Excelのファイル名が2023.01.01.xlsxで、これをAccessで読み込もうとした時に変なことになるなど)が、絵文字も注意が必要である。

命名規則

プレフィックスを用いて整理するのが一般的と思う。

基本的にプレフィックスは
hoge_channel のようになる。

これ、スネークケースではなくhoge-channelのようにケバブケースがいいと言う人も世の中にはおられる。

スネークケース hoge_channel
ケバブケース hoge-channel

個人的にはどちらでも良いが、Slackのデフォルトでは[プレフィックス]- がサジェストされる。

DMについて

DMの考え方については下記の記事に完全同意。DMを受けた時は、この記事を送ることもある。

なんでDMになっちゃうんだろうね?を考えた先人の記事はこちら。

心理的な問題や、職務分掌や権限範囲が明確でないといった組織体制の影響もあり得る。オープンチャンネルの参加人数が多いと、そのチャンネルでは発言しづらいと聞いたこともある。この辺りの感覚は、自分は感覚がぶっ壊れているのか、あんまり気にしたことがなかった。

DM警察👮‍♂️👮‍♂️👮👮‍♀️気になっているが試していない


再有効化したユーザ

休職等により、一度無効化したユーザを再有効化することがある。
この再有効化した時に困るのが、無効化前にユーザが参加していたチャンネルやユーザーグループにオートで復帰されないことである。

チャットワークやasanaだと、停止中だったアカウントを有効にすればそのまま過去参加していたところに参加した状態になるらしい。いいなー。

アカウントを復活させると、そのメンバーはすぐにワークスペースにサインインできるようになり、アカウントを解除する前に送ったすべてのメッセージにアクセスできるようになります。ただし、以前参加していたチャンネルに再度追加されることはありません。

https://slack.com/intl/ja-jp/help/articles/360002061747-%E3%83%A1%E3%83%B3%E3%83%90%E3%83%BC%E3%81%AE%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%82%92%E5%BE%A9%E6%B4%BB%E3%81%95%E3%81%9B%E3%82%8B

要るかなあとは思いつつ、無効化する前に動作させることを念頭に、そのユーザが属しているチャンネルやユーザグループを取得するプロトタイプ的なGASを書いてはみたものの。

https://github.com/ymgcmnk/Slack_users.conversations

https://github.com/ymgcmnk/Slack_usergroups.list

※プランによっては、プライベートチャンネルやDMグループの情報は取れないです。

うーん、しかし。これを情シスがやるのは過剰サービスな側面もある。

再度、新たな気持ちで、必要なチャンネルやユーザグループに各自で入っていただけば良いかなあと思いつつ。
チャンネル参加は入社時のオンボーディングと同じで、各自、各チームにやってもらうのが筋かなあ。
必要があればメンションされるからね。

コネクト

ほとんどヤスムラさんの記事だったりSlack公式に書いてあるので、二番煎じですが、ツラツラしています。

コネクトできない問題

当方がEnterprise Grid未満の有料のワークスペースを使っていても、先方が無料のワークスペースだとコネクトできない。

Enterprise Gridならできる。
力 is Power
金 is Money

当方がEnterprise Grid未満の有料のワークスペースで、先方が無料ワークスペースの場合、当方が先方とSlackでやりとりしようとなると、しょうがないのでシングルチャンネルゲストまたはマルチチャンネルゲストになる。


承認誰がするんだ問題

コネクトの承認を情シスだけがやるのか、そもそもワークスペースの管理者をどういうルールで組織内の誰に持たせるかっていう話になってくる。


オーナー誰がなるんだ問題

コネクトしましょう〜いいですよ〜!と当事者間ではサクッと合意したとしても、そのコネクトのオーナーをどちらが持つべきか?
基本的には業務を依頼する側がオーナーを持つと思う。


パブリックチャンネルだとワークスペース内で情報丸見え問題

コネクトチャンネルがオープンチャンネルになっている場合、ワークスペースに参加しているユーザもそのコネクトチャンネルの中で扱っている情報にアクセスできる。そのコネクトチャンネルで扱う情報の種類にもよるが、オープンチャンネルになっている場合のリスクは認識しておいた方が良いだろう。

一般的にはプライベートチャンネルで運用することが多いと思われる。
これまではプライベートチャンネルに一度変換してしまうと、パブリックには戻せないという不可逆性があったが、それは無くなるようである(要出典)



チャンネルのアーカイブ

非アクティブなチャンネルは、自動的にアーカイブさせるとスッキリできそうでいいなあと思いつつ、手を付けられていない。

メール転送

チャンネルにメールを転送する方法は色々ある。が、「チャンネルまたは DM 用メールアドレスを作成する」が一番良いと考えている。


すべてのプランで利用できる、と書いてあるが、下図のように無料プランではダメそう。

無料ワークスペース


有料ワークスペース



↓このアプリでメール転送設定していると、個人のユーザに紐づいた形になるので、そのユーザが無効化された時に転送もされなくなるので注意が必要。


チャンネルで扱われる情報をどう考えるか

オープンチャンネルの場合、そのワークスペースにいるメンバー全員がアクセスできるわけで。

メールを転送してきたり、サービスの通知をさせたりと、外部連携もしていたりするわけで。

そのチャンネルで扱われている情報は、誰が見て良いのでしたっけ?を考える必要が出てくる。

Slackに限らず、情報への対応、セキュリティの考え方としては
契約、文化(教育や啓蒙)、仕組みの3方向があるのではないかと個人的に思っている。


プランとお値段

特にスタートアップや中小企業は悩むところである。
プロからビジネスプラスに、ビジネスプラスからEnterprise Gridに、アップするタイミングや根拠をどうするか?

テキストコミュニケーションとHRT

こんにちは。
こんにちは!
こんにちは〜

テキストコミュニケーションにおいては、出力される文字は一定のフォントである。ゆえに、冷たい印象を与えがちになる。らしい。

情報を発信する側としては、下記のような点を意識すると良さそう。
・絵文字を使う😀
・文末を「です〜」「でした!」とするなど柔らかくする
・箇条書きを効果的に使う
・結論を最初に述べる
・SVO(特に主語、目的語)や5WnHを意識する

情報を受け取る側としては、下記のnoteが良かった。

コミュニケーションにおいては、認知特性も多少なりとも関わっている気もする。

HRTの概念については下記の書籍で述べられているらしい(ちゃんと読んでない


退職時

これを書いた時よりも、今ならもう少し深掘りできるかなあ?

各社のSlackガイドライン

もう、基本的には公開されているこれらを見といてね!で良い気もしている。Slack公式にも色々と情報があるし。
差分となる各社、各組織での運用について決めていけば、とか。
その差分が難しい、か。



番外編:情シスSlackの歩き方


ビジネスチャット色々あるよ問題

西暦2023年——企業のネットが星を被い、電子や光が駆け巡っても電報やFAXが消えてなくなるほど、情報化されていない近未来

各社はSlackだったりTeamsだったりLINE WORKSだったりと、それぞれ独自の生態系でコミュニケーションを取っていたりする。

あっ、えっ、そこ、なんでFacebookのメッセンジャー使ってるの??友達なの??

それらのビジネスチャットを開設する際の基盤としても、電話やメールはいまだ強力なプロトコルでもある。

社内はビジネスチャット、社外はメールというのが現時点の大きな枠組みであるような気もする。

複数のビジネスチャットを跨いで各組織間が統合的にコミュニケーションできる日は来るだろうか?

経営者にしてみれば、チャットツールなんてのは、なんでも良いのかもしれない。
しかし、最近ではこんな記事もあったりする。


そんなわけで、コメントや、スキを頂けたら嬉しいです!!!

#ポエム
#Slack
#情シス
#コーポレートエンジニア
#苦悩

いただいたサポートで、書籍代や勉強費用にしたり、美味しいもの食べたりします!