Edited at

30人規模のチームでSlackの運用ルール

こんにちは。

先日Slackがダウンしましたが「Slackが落ちてて仕事出来ない」「Slackが落ちているから休もう」「Slackが無いと生きていけない!」というエンジニアは多いのではないでしょうか。

30人規模のチームの運用ルールです。


出入り

30人規模になるとそれなりにメンバーの出入りがあります。

出入りしてもチームが混乱しないよう、また既存、新規のメンバーがスムーズに馴染めるためのルール作りです。


プロフィールとユーザ名

10人ぐらいまでだとプロフィールも適当で良いのですが、30人規模になるとプロフィールにも運用ルールが必要です。

image.png


FullName

本名を入力します。

漢字を入力したくなりますが絶対にローマ字です。

漢字だったときには圧倒的にメンションが面倒になります。

漢字表記だと@(アットマーク)を入力した後に漢字入力に切り替える必要があるのでかなり面倒です。

漢字という文化は誇りに思っていますし、名前の漢字表記はユニークになるのですごく重要だと思っていますが、Slackについてはローマ字のほうが便利です。

今後「漢字」や「ローマ字」という別カラムが登場すると良いですね。


Display name(表示名)

表示名にはSlackでメンションを飛ばしてもらうための名前です。

(僕たちはWeb系ですが)Web系のチームであればGitHubやGoogle(Gmail)など、他のサービスで使っている名前にするととても便利です。

招待するときやチーム内での認識、通知系チャンネルとの相性が良いです。


Display name のルール

この「表示名」ですが、いくつかのルールをおすすめしています。


  1. 音読可能であること

  2. 英数小文字であること

  3. グローバルユニークであること

  4. 他のサービスと同じアカウント名であること

「音読可能であること」について

ほとんどの人は文章(や文字列リテラル)を読むとき、脳内で音読しています。

例えば「kpljkpzk」といった英字子音が続いたりする名前だと脳内音読できないので混乱します。

「英数小文字であること」について

GitHubで使えないなど、サービスごとの名前規則があるため、英数のみの名前がおすすめです。

特にアンダーバー、ハイフン、ドットは使わないほうが良いです。

(その昔、RFCの解釈を巡ってメールアドレスでアットマークの直前のドットを認めてしまうということがありまして…)

「グローバルユニークであること」について

グローバルでユニークな名前が良いです。

具体的には「その名前でググって(エゴサ)も出てこないこと」です。

「GitHubでアカウント名を取ろうとしたけど取れなかった」というこを防ぐことが出来ます。

「他のサービスと同じアカウントであること」について

招待や他のサービスで同一人物と認識しやすいので同じアカウント名推奨です。

SlackとGitHub、RedmineやJillaなど、連携したときのキーになります。Issueなどのコメント文などで@付きで呼んだ時、Slackにも良い感じに通知が来るようになります。

名前についていくつかの規約を挙げましたが、上記の例を使っていい感じにアカウント名を作ってくれたのが「 @say3no 」君です。

特にアカウント名の途中に数字を入れたのは効果的だったと思っています。


What I do

得意な分野、興味のある分野を入れています。

「〇〇さんってこういうことできるんだ』ということにつながるのでチームでお声がけしてもらえるようになります。

とはいえ、単なる自己紹介でも良いです。会話のきっかけになりますし、覚えやすくなります。

ただその場合にはカーディナリティが高いほうが良いですね。


Phone Number

電話番号はできるだけ入れてもらっています。

電話で呼び出したいために入れるわけではなく(エンジニアと電話は相性が良くないですよね)、特にiCloudとの連携を意識しています。

昨今はウェブ系エンジニアの98%ぐらいがMac使いなので、電話番号(やiCloud系のメールアドレス)を登録しておくとAirDropが使えて便利です。


写真

個人を認識しやすい写真を入れています。

30人ぐらいのチームでリモート作業も増えてくるとオンラインとオフラインの同一視ができなくなることが増えるので、できれば本人の写真が良いです。

写真が嫌なメンバーもいますので、そういう場合には似顔絵などにしてもらっています。

被りやすい上に区別し難い「猫😺」「有名アニメキャラ」は良くないです。

(猫認識エンジンやアニキャラ認識エンジンを積んでいない人も多いのです…)

デフォルトアイコンも会話での視認性が悪いのでよくないです。

image.png


チャンネル


Slack公式からの情報

Slackの公式でチャンネル作成のガイドラインが発表されています。

チャンネル名のガイドラインを作成する

一通り目を通しておくとよいです。

上記のページにもある内容ですが、30人を超える辺りから個人的に良いなと思っている運用方法やTipsについて列挙していきます。


チャンネル名の長さ制約

Slackのチャンネル名の長さは21文字です。1

それほど長くないので注意が必要です。


案件チャンネル

プロジェクトや案件2のチャンネル名には 日付+案件スラッグ(固有ID)を付けています。

例えば「2018年12月23日に始まった、SlackのHuBotを使ったプロジェクト」の場合には #20181223slack-hubot としています。

案件チャンネルに日付を付けるメリットについてです。


  1. 日付+スラッグであればユニークになり被らない

  2. GitリポジトリやRedmineのプロジェクトなど、他のシステムと連動して同じ名称を使える

  3. 案件チャンネルが順に並ぶため、古い案件がすぐに分かる (=> 探しやすい)

逆にデメリットとしては


  1. 日付降順で並ぶため、上に古い案件が来る

  2. チャンネル名が長くなるため、長さ制限に引っかかる

  3. Notifyや関連チャンネルを並べるときに長くなる

ことです。

Slackだと日付降順固定なので少し辛いですが、Gitのリポジトリ名と同じにしておくと手元のリポジトリが「コレなんだっけ?」となったときに日付があると認識率がかなりよくなります。

関連チャンネルを作ろうとすると長さ制限に引っかかる場合には略称も使います。

また重要なことですが、接頭語は並び順を決定するので注意が必要です。安易に01_全般 02_連絡用 といったチャンネル名を付けて後から後悔しました😪


プリフィックスを付ける

Slack公式にもありますが、プリフィックス(接頭語)は良いです。

プリフィクス
使い方

help_
〇〇について聞きたい

times_〇〇
一時期話題になった分報です3。便利!

study_〇〇
勉強系チャンネル


サフィックスを付ける

チャンネル名の後ろにサフィックス(接尾語)も使っています。

案件チャンネルで利用するGitHubやCIサービスの通知系チャンネルや、定期実行で来る通知チャンネルを作っています。

先ほどの#20181223slack-hubotのを例にとってみます。

日付プリフィクスがついているため、そのまま-notify-logsなどといったサフィックスを付けると21文字のチャンネル名の長さ制限にかかってしまいます。

長さ制限を回避するためにslack-hubotを省略化してshとします。

その上でサフィックスを付けていきます。

#20181223sh-notify
GitHubのコミットやコメント、CIの結果などを投げるチャンネル。

#20181223sh-logs
定期実行された結果を出力するチャンネル。

日付省略形+サフィックスであれば関連チャンネルであることが一目瞭然です。

(もし1日に大量のチャンネルを作るぐらいの大規模組織であれば別かも知れないですが :rolling_eyes: )


通知系チャンネルはミュートで

通知(Notify)系のチャンネルはひたすら流れて行くので、ずっと見ていると大変です。

そこで基本は通知系チャンネルをミュート(非通知)にしておき、自分の名前にだけ反応するようにしています。

image.png

こうすることで流れすぎを防ぎつつ、GitHubやSlackで自分宛てにメンションが飛んできたときには気づけるようになります。

image.png

先のSlackのユーザ名はGitHubなどに揃えると相性が良いです。

参考 GitHubとSlackを連動させて通知を受け取る@2018年版 - Qiita


一時的なチャンネルを使う

最近知ったTipsなのですが、一時的チャンネル良いなと思いました。



  • Slackの2要素認証設定のお願い

  • セキュリティ研修を受講してください

Slack のチャンネルを使うと、

それ用のチャンネルを用意する

チャンネルの説明欄やトピック、ピン留め発言などの目立つところに「これを済ませたら抜けてね」と書いておく

全員をそのチャンネルに招待する

期日まで、毎日の適当な時間に「@channel やってね!」と発言する

こんな感じになります。未完の人リストはチャンネルのメンバーそのものになるのでリスト作成の手間がゼロになるのと、未完の人だけを対象にリマインドするのが簡単になる点がよいです。

ほいで、無事に全員が完遂できたら「ご協力ありがとうございました〜」と言ってそのチャンネルはアーカイブするなり捨てるなりするだけです。


https://june29.jp/2018/12/21/slack-instant-channel/

最近ですと年末調整の申告書の提出ですとか、期日のあるタスクに対しての運用は良いなと。チャンネルに呼び出して閉じ込める感ありますが… :smile:


その他

チャンネルの運用ルールなど、その他のルールも追記していきます。