page icon

Slackに関するルールや活用法

💡
Slackに関する最低限のルールのまとめ チャンネルのルールに関する理由や議論等は こちらの記録 を参照 相談や疑問があれば #slack_general
(※外部公開中)
 

チャンネル

一覧

パブリックチャンネル

  • 後述の命名規則に則った上で誰でも作成してよい
  • 適切な話題の切り出しのために作成を推奨
  • 作成者は必ず、チャンネルの目的を書くこと

代表的なチャンネル

2022/06/09: 一部編集
  • #attendance_general(出退勤報告)
  • #corporate(管理チーム)
  • #db(コスメデータベース関連)
  • #dev_general(開発全般)
  • #dev_lips_ios(LIPS iOSアプリの開発)
  • #dev_sales(広告商品の開発)
  • #general(全体)
  • #general_new_product(新規事業の開発)
  • #general_organization(組織についての議論)
  • #general_picture(写真投稿チャンネル)
  • #marketing(マーケティング)
  • #misc_gohan(ごはんメイツ募集)
  • #times_xxxx(皆の分報)
  • #sales(セールスチーム)
  • #misc_value(行動指針に沿ったナイス行動が流れるチャンネル)
  • #general_tacos_notify(みんなの日々のありがとうが流れるチャンネル)

プライベートチャンネル

  • オーナーのみが作成可能。基本的に作成しない
  • プライベートチャンネルがある場合は、その存在を以下で公開
 

アーカイブ

  • あるチャンネルが不要であると判断した場合、 そのチャンネルにアーカイブ理由を残した上で、誰でもアーカイブしてよい
  • 不要なチャンネルはアーカイブを推奨する

削除

  • 完全に一切使用されておらず、作られただけのチャンネルは削除してよい
  • 基本的にアーカイブで対応する

命名について

  • カテゴリごとに 共通のprefixをつける
  • 検索・補完しやすい単位でわけ、_でつなぐ(スネークケースにする)こと
    • 検索・補完を阻害しない範囲でルールの逸脱を認める(例:#writers
    • #times_ の以下の名前を - で区切ることのみ許容する( _ がbetter)
  • アルファベットで、できるだけ平易な英単語を使う
    • ただし業務への関連が薄い #workshop_#misc_ #times_ については自由
    • 文字数制限もあるので臨機応変に 制限が緩和され80文字までになったので、だいぶ文字数には余裕がありそう
    • 事情により日本語を使う場合、ローマ字にするのは検索性・一覧性が低いので、日本語のままを推奨

prefix

  • prefixを増やす際には #slack_general で事前に報告
  • prefixは分かりやすい範囲で短めにする
以下のprefixを使用する
  • attendance
    • 2019/07/01 追加
  • adops
    • 広告運用
  • appbrew
    • 外部との共有チャンネル
    • 共有チャンネルなら付けるというわけではなく、むしろ内容が分かりやすくなるので別の適切なprefixを付けることを推奨
    • 共有チャンネルのrenameは反映に時間がかかることがあるらしく、1日くらい待つことがあるかもしれない
  • biz
  • bug
  • bugsnag
  • club
    • 部活制度適用対象のチャンネルで使用(
  • cs
  • db
    • database
  • design
  • dev
  • email
  • exceptions
  • general
  • hr
    • human_resouce
  • lips
    • どうにも分けづらいLIPS関係のチャンネルをまとめる
  • marketing
  • misc
  • private
    • プライベートチャンネルはプライベートになっていることを明示するためつける
  • sales
  • seo
  • slack
  • revision
  • recruit
    • 2019/07/12 追加
  • test
    • Slack botのテストなどに使うためのチャンネル
  • times
    • 分報。2020/12/19 misc_timeから変更
  • remind
    • @channel で何らかの作業(評価入力など)が終わるまで繰り返しリマインドされ、終わったら抜けるタイプのチャンネル
  • writer
  • workshop
    • 勉強会用
    • アーカイブ済みかつもう戻さないと思われるもののうち、以下のような事情があるもの - 例1:少し使われているが、同様のチャンネルがあり使われなくなった(整理により名前が被る) - 例2:初期のチャンネルで、使われていないが、分類が難しい - 例3 : 共有チャンネルのつもりが、間違えて通常チャンネルにしてしまった、などの理由で閉じるもの
    • 済_sp_
      • 済_sales_proposalの略記で、使われなくなった案件ごとのチャンネルをまとめるためにのみ使用
廃止されたprefix
  • audio
    • huddles用のチャンネルとして 2021/07/29 追加
    • 2022/02/08に 不要となったためアーカイブ
  • monitor
    • サーバー監視など
    • 2022/04/27 使われているチャンネルがなくなったため廃止
  • notion
    • 2020/11/20追加
    • 2022/04/27 使われているチャンネルがなくなったため廃止
 

cs, bug, design, devについて

  • #dev_ は GitHubにリポジトリのあるものについては、#dev_{リポジトリ名をスネークケースにしたもの} で統一する。複数のリポジトリを束ねるものはそれらのprefixを使う
  • #dev_ に対応するリポジトリがないもので、プロダクトに直接関わるものはプロダクト名をprefixの次に付ける(例: #dev_lips_imageprocess
  • #cs_, #bug_, #design_#dev_ のリポジトリに紐付くものがあれば、同様に命名する

分報(times_)

分報とは

  • 社内Twitterのように使う各自のチャンネル
  • 今やっていること・困っていること・考えていることをつぶやく
  • ストレスなく自由に発言してもらえる環境

分報のメリット

  • 週報、日報よりスピード感がある
  • 誰が知っているか分からない問題があったとき分報につぶやくと拾ってもらえたりする
  • 他メンバーの考えを知れる
  • どこに何をつぶやけば良いか分からない新メンバーのオンボにも向いている

分報の内容

  • プライベートなこと・感情面をつぶやいても良い(コンプライアンスは遵守)
  • 「分報」だからといって毎分書き込む必要はない、つぶやくペースは人それぞれ
  • 全員が全員の分報を常に見ている必要もない
スクリーンショット 2019-06-08 4.05.09.png
スクリーンショット 2019-06-08 4.05.09.png
スクリーンショット 2019-06-08 4.11.11.png
スクリーンショット 2019-06-08 4.11.11.png

分報のデメリット

  • チャンネルが細かく分かれるため情報が蛸壺化しやすく、オープン文化を阻害

デメリットを解消するためのルール

  • 業務に関するディスカッションや連絡は分報ではなく当該チャンネルに移動する
  • 意図せず分報で業務に関連する会話が始まってしまうのは仕方がないが、ディスカッションに発展するタイミングで気付いた人が当該チャンネルに会話を移す

DM

  • 基本的に禁止
  • SlackのDMに限らずLINE、メッセンジャー、SMSなどの二人きりで話せる媒体を含む
    • 事業に関わらない事務連絡やプライベートな話はOK(待ち合わせの連絡など)
  • 他メンバーからDMが来たが後述の例外に当てはまらない場合、「オープンチャンネルでお願いします」と言う責任が受取側にもある

禁止の理由

  • DMに業務に関する情報が溜まっていくと社員間で情報格差が生まれる
  • 特定の人に情報が集まると権力差(政治)が生まれ、本質的な仕事に集中する時間が減る
  • 「使う必要がない状態を作るのが本質」は高々理想論で、人間は普段の行動やルールにどうしても影響されるものです→良いルール(シンプルで最低限かつ明確な規律)を作ることは良い文化を作ること

例外

  • プライバシーに関わる情報(個人情報など)
  • 機密情報
  • キー(エンジニア向け)
  • 事業に関わるが、公開チャンネルでは本人がどうしても発言しにくい場合
    • 休職、退職

メンション

メンションを送るタイミングについて

  • 稼働中かどうかに関わらず、基本的にいつでも送ってよい
    • タイミングを制御してより広く読んでもらうために、予約送信機能を使うのも便利

ユーザーグループ

  • 複数の人に繰り返しメンションを飛ばす場合は、ユーザーグループの作成を推奨する
    • 業務に関わる人の変更・増減の際に、メンション漏れ等の事故を防止できる
  • ユーザーグループで十分な場合には、@here @channel はできる限り避ける

@here @channel

  • 重要な連絡や、全体に協力してほしいような内容に使う
    • チャンネルに直接関わりがないがウォッチしておきたいのに無関係なメンションがよく飛んでくるために不便という状況は、オープンな文化を阻害しうる。注意して使用する
  • 明確なルール化が難しいので以下に事例を上げる(気になった場合は #slack_general で相談)
    • 適切な例
      • オフィスに作業者が立ち入る・休日にオフィスをイベントで使用するなどの全体への周知
      • アンケートへの協力、記事の拡散など、人数を集めたい場合
      • #misc_ におけるやりとり
    • 不適切な例
      • みんなにお土産を買ってきた
        • → #general_random でメンションをつけずに投稿、など

よい行動は称賛しよう

「OPEN」「OWNERSHIP」「LEAN」「USERFIRST」な行動にリアクションをつけよう

  • 行動指針に沿ったナイスな行動にリアクションをつけると、#misc_value へ流れます。
  • どんな行動が行動指針に沿った行動なのか、新しく入られた方も昔からいる方も全社で共通認識を醸成することを主な目的にしています。

ちょっとした感謝は🌮で伝えよう

  • ピアボーナスとして「HeyTaco!」というサービスを導入しています。
  • テキストコミュニケーションがメインになると、なかなか日々の感謝やちょっとしたありがとうを伝えづらいと思います。そこで、毎日の業務の中で同僚に感謝の気持ちを簡単に伝えチームの心理的安全性を醸成することを目的に導入しています。
  • 使い方:slackで @感謝を贈りたい相手へメンション + 🌮 するだけ!
タコスで感謝を伝えよう:ピアボーナス🌮タコスで感謝を伝えよう:ピアボーナス2022/1/25 19:202022/6/9 12:39