Slackに関するルールや活用法
(※外部公開中)
チャンネル一覧パブリックチャンネルチャンネルを一部紹介プライベートチャンネルアーカイブ削除命名についてprefix#devチャンネル分報(#times)分報とは分報のメリット分報の内容分報のデメリットデメリットを解消するためのルールDM禁止の理由例外メンションメンションを送るタイミングについてユーザーグループ@here @channel よい行動は称賛しよう「OPEN」「OWNERSHIP」「LEAN」「USERFIRST」な行動にリアクションをつけようちょっとした感謝を積極的に伝えようその他社内向け案内
チャンネル
一覧
パブリックチャンネル
- 後述の命名規則に則った上で誰でも作成してよい
- 適切な話題の切り出しのために作成を推奨
- 作成者は必ずチャンネルの目的を書くこと
チャンネルを一部紹介
2022/10/05: 一部編集
- #attendance_general(出退勤報告)
- #corporate(管理チーム)
- #db(コスメデータベース関連)
- #dev_general(開発全般)
- #dev_sales(広告商品の開発)
- #general(全体)
- #general_new_product(新規事業の開発)
- #general_organization(組織についての議論)
- #general_picture(写真投稿チャンネル)
- #marketing(マーケティング)
- #misc_gohan(ごはんメイツ募集)
- #sales(セールスチーム)
- #club_(部活動)
- #misc_value(行動指針に沿ったナイス行動が流れるチャンネル)
プライベートチャンネル
- オーナーのみが作成可能。基本的に作成しない
- プライベートチャンネルがある場合は、その存在を以下で公開
アーカイブ
- チャンネルが不要であると判断した場合、 そのチャンネルにアーカイブ理由を残した上で、誰でもアーカイブしてよい
- 不要なチャンネルはアーカイブを推奨
削除
- 基本的にアーカイブで対応する
- 一切使用されておらず、作られただけのチャンネル(誤作成した等)は削除してよい
命名について
- カテゴリごとに共通のprefixをつける
- 検索・補完しやすい単位でわけ、でつなぐ(スネークケースにする)こと
- 検索・補完を阻害しない範囲でルールの逸脱を認める(例:)
- の以下の名前を で区切ることのみ許容する
- アルファベットで、できるだけ平易な英単語を使う
- 業務への関連が薄い や については自由
- 事情により日本語を使う場合、ローマ字にするのは検索性・一覧性が低いので、日本語のままを推奨
prefix
- prefixを増やす際には #slack_general で共有
- prefixは分かりやすい範囲で短めにする
以下のprefixを使用する
- attendance
- 2019/07/01 追加
- adops
- 広告運用
- appbrew
- 外部との共有チャンネル
- 共有チャンネルなら付けるというわけではなく、むしろ内容が分かりやすくなるので別の適切なprefixを付けることを推奨
- 共有チャンネルのrenameは反映に時間がかかることがあるらしく、1日くらい待つことがあるかもしれない
- biz
- bug
- bugsnag
- ceo
- 代表関連のチャンネル(2023/12/15 名称変更)
- club
- 部活制度適用対象のチャンネルで使用( )
- corporate
- cs
- daily
- 部署やユニット単位のデイリーミーティングやコミュニケーションの場となるチャンネル
- 2023/02/15 作成
- db
- database
- design
- dev
- searching
- exceptions
- general
- hr
- human_resouce
- lips
- どうにも分けづらいLIPS関係のチャンネルをまとめる
- marketing
- misc
- その他のチャンネル
- pr
- 2022/08/02 #biz_prから#prに変更され誕生。広報関連のチャンネル
- private
- プライベートチャンネルはプライベートになっていることを明示するためつける
- sales
- seo
- slack
- revision
- recruit
- 2019/07/12 追加
- test
- Slack botのテストなどに使うためのチャンネル
- times
- 分報。2020/12/19 misc_timeから変更
- remind
- で何らかの作業(評価入力など)が終わるまで繰り返しリマインドされ、終わったら抜けるタイプのチャンネル
- writer
- workshop
- 勉強会用
- workspace
- 2022/11/28 分報とは違い、自分だけが入って作業をするためのチャンネル
- 済
- アーカイブ済みかつもう戻さないと思われるもののうち、以下のような事情があるもの - 例1:少し使われているが、同様のチャンネルがあり使われなくなった(整理により名前が被る) - 例2:初期のチャンネルで、使われていないが、分類が難しい - 例3 : 共有チャンネルのつもりが、間違えて通常チャンネルにしてしまった、などの理由で閉じるもの
- 済_sp_
- 済_sales_proposalの略記で、使われなくなった案件ごとのチャンネルをまとめるためにのみ使用
廃止されたprefix
audio- huddles用のチャンネルとして 2021/07/29 追加
- 2022/02/08に 不要となったためアーカイブ
meol- 2020/05/21にcommerceから変更
- 2022/04/27 meol_email以外にないため、email_meolに変更して廃止
monitor- サーバー監視など
- 2022/04/27 使われているチャンネルがなくなったため廃止
notion- 2020/11/20追加
- 2022/04/27 使われているチャンネルがなくなったため廃止
#devチャンネル
- GitHubにリポジトリがあるものについては、 で統一する。複数のリポジトリを束ねるものはそれらのprefixを使う
- 対応するリポジトリがない開発関連のチャンネルは、必ずプロダクト名をprefixの次に付けて区別できるようにする(例: )
分報(#times)
分報とは
- 社内Twitterのように使う各自のチャンネル
- 今やっていること・困っていること・考えていることをつぶやく
- ストレスなく自由に発言してもらえる環境
分報のメリット
- 週報、日報よりスピード感がある
- 誰が知っているか分からない問題があったとき分報につぶやくと拾ってもらえる
- 他メンバーの考えを知れる
- どこに何をつぶやけば良いか分からない新メンバーのオンボーディングに向いている
分報の内容
- プライベートなこと・感情面をつぶやいても良い(コンプライアンスは遵守)
- 「分報」だからといって毎分書き込む必要はない、つぶやくペースは人それぞれ
- 全員が全員の分報を常に見ている必要もない
- 例
分報のデメリット
- チャンネルが細かく分かれるため情報が蛸壺化しやすく、オープン文化を阻害
デメリットを解消するためのルール
- 業務に関するディスカッションや連絡は分報ではなく当該チャンネルに移動する
- 意図せず分報で業務に関連する会話が始まってしまうのは仕方がないが、ディスカッションに発展するタイミングで気付いた人が当該チャンネルに会話を移す
DM
- 基本的に禁止
- SlackのDMに限らずLINE、メッセンジャー、SMSなどの二人きりで話せる媒体を含む
- 他メンバーからDMが来たが後述の例外に当てはまらない場合、「パブリックチャンネルでお願いします」と言う責任が受取側にもある
- 待ち合わせの連絡など、事業に関わらない事務連絡やプライベートな話はもちろんOK
禁止の理由
- DMに業務に関する情報が溜まっていくと社員間で情報格差が生まれる
- 特定の人に情報が集まると権力差が生まれ、本質的な仕事に集中する時間が減る
- 良いルール(シンプルで最低限かつ明確な規律)を作ることは良い文化を作ること
- 「使う必要がない状態を作るのが本質」は理想論で、人間は普段の行動やルールにどうしても影響されてしまう
例外
以下に当てはまる場合はプライベートチャンネル・DMでやり取りを行うか、適切なツールを使用すること
- プライバシーに関わる情報
- 機密情報
- ログイン情報・認証情報
- 事業と個人に関わり、パブリックチャンネルだと悪影響を及ぼしうる話(休職・退職に関する相談等)
メンション
メンションを送るタイミングについて
- 稼働中かどうかに関わらず、基本的にいつでも送ってよい
- タイミングを制御してより広く読んでもらうために、予約送信機能を使うのも便利
- 通知を受け取りたくない場合は受け取る側で制御すること
- 業務時間外にメンションが届いても一切対応する必要はなく、また業務時間外に素早く対応することが評価されることもない
ユーザーグループ
- 複数の人に繰り返しメンションを飛ばす場合は、ユーザーグループの作成を推奨する
- 業務に関わる人の変更・増減の際に、メンション漏れ等の事故を防止できる
- ユーザーグループで十分な場合には、 はできる限り避ける
- 重要な連絡や、全体に協力してほしいような内容に使う
- 無関係なメンションがよく飛んでくるせいで、ウォッチしておきたいチャンネルを抜けざるを得ないという状況は、オープンな文化を阻害するため、注意して使用する
- 明確なルール化が難しいので以下に例を挙げる(気になった場合は で相談)
- 適切な例
- オフィスに業者が立ち入る・休日にオフィスをイベントで使用するなどの全体への周知
- アンケートへの協力、記事の拡散など、人数を集めたい場合
- におけるやりとり
- 不適切な例
- みんなにお土産を買ってきたので#generalで@hereをつけて投稿
@here 【作業者立ち入りについて】 本日午前中に、集中ブースの設置のための事前調査が入ります。 業者出入りしますのでご協力お願いいたしますmm #general https://appbrew.slack.com/archives/C0KTHAFL7/p1611103670058100
@here デザイナーさんに草案を3つ出していただきました。 お気に入りのデザインに投票してほしいです 🙏 #marketing https://appbrew.slack.com/archives/C7HGBUBSS/p1610617535007000
→ #general_random でメンションをつけずに投稿、など
よい行動は称賛しよう
「OPEN」「OWNERSHIP」「LEAN」「USERFIRST」な行動にリアクションをつけよう
- 行動指針に沿ったナイスな行動にリアクションをつけると、#misc_value へ流れます。
- どんな行動が行動指針に沿った行動なのか、新しく入られた方も昔からいる方も全社で共通認識を醸成することを主な目的にしています。
ちょっとした感謝を積極的に伝えよう
以前導入していたHeyTacoの名残で、ちょっとした感謝を伝える際に 🌮 を送り合う文化が残っています。他にもありがとうの気持ちを表すリアクションはたくさんあるのでどんどん活用していきましょう