本ガイドラインはSlackを対象に利用方針についてのベースとなる規約を設け、Slackを用いてより良いコミュニケーションを促進することを目的とする。
位置づけ・適用範囲・免責事項は Introduction を参照。
管理者向け推奨設定
Workspace Access
チーム、プロジェクトでの利用の場合は リクエスト制（By Request） もしくは招待制（ Invite Only）の設定を推奨する。
デフォルトチャンネル
ワークスペースにメンバーを追加すると #general へ自動参加する。他にもメンバー全員に参加して欲しいチャンネルがある場合には、デフォルトチャンネルを追加する。
ユーザーグループに対してもデフォルトチャンネルを設定できるため、用途に応じて使い分けると良い。
表示名ガイドライン
ワークスペースごとにガイドラインを設定することを推奨する。後述の表示名設定や、その他チームコミュニケーションにおけるルールを設定する。設定できる権限を持つのはワークスペースのオーナーだけである点に注意する。
ワークスペースの管理者
ワークスペース内に複数のチームが混在する場合、それぞれのチームごとに管理者権限保持者を設定すること。
理由:
- 管理者権限を持った人しか実行できないオペレーションがあった際、チーム内で解決できる状態を作っておくことが望ましいため
ユーザー向け推奨設定
アカウントアイコンを設定する
デフォルトのアイコン利用は避け、アカウント登録時に各自のアイコン画像を登録する。
理由:
- チャットコミュニケーションにおいて、アイコン画像は個人識別に有用なため
また、GitHub/GitLab、Google Workspace、その他利用サービスも同様のアイコンを利用することで、個人を識別しやすくなる。
検索性の高い氏名（Full name）を設定する
表示名（Display name） もしくは氏名（Full name） にて、ローマ字及び漢字（無ければカタカナ）でのフルネームを登録すること。表示名はチームごとに書き方の異なるケースが多いので、本ガイドラインでは氏名に記載することを推奨する。例えば「未来 太郎」の場合、「Taro Mirai (未来 太郎)」という記載を推奨する。
理由:
- Slackではアカウント名のインクリメンタルサーチが強力であり、ローマ字と漢字のどちらでもサジェストされる状態にすることでユーザビリティの向上が期待できるため
ユーザーグループの推奨
ユーザーグループの利用を推奨する。ただし、ゲストユーザーは追加できない。該当するメンバーがチャンネルに在籍する場合は、その旨をメンバー全員が理解し、コミュニケーションから除外してしまわないように注意すること。
ユーザーグループを作成できない状態の回避策
ユーザーグループを作成できない状態（メンバーがワークスペース間にまたがっている場合等）でも、メンション先の対象者全員が個別に自分のSlack設定>Notification>My Keywordsに「＠〇〇チーム」と予約語を登録することで、擬似的にグループメンションが可能である
チャンネル命名規則
外部組織メンバーが在籍するチャンネルの命名
Slack コネクト等でチャンネル内に社外のメンバーが含まれる場合には、チャンネル名の先頭に ---ext をつける。
理由:
- 全社的に統一されたプレフィックスにより、内部の進行について相談する発言を、取引先メンバーが在籍するチャンネルに誤投稿してしまうような、外部コミュニケーションのミスを防ぐため
- チャンネルはセクションという単位でグルーピング可能となり、用途や組織を表現するプレフィックスで並び順を制御する必然性が薄れたため
投稿内容ポリシー
敬称は不要
敬称は省略して、 @mano メッセージ内容 といった形式でコメントすること。どうしても敬称を付けて欲しい場合、表示名をさん付けにするハックも存在するため、受信者側で調整する。
理由:
- コミュニケーションを迅速・シンプルにするため
絵文字や感嘆符を活用する
積極的に活用することを推奨する。テキストコミュニケーションは、画像や音声が伝わらない分、冷たく捉えられがちである。特にリーダーなど上位のポジションにいる場合は、メンバーから威圧的に捉えられないよう配慮するのが好ましい。
「では、Aの方針でよろしくお願いします！」「では、Aの方針でよろしくお願いします:ganbatte:」 など付けることで、不機嫌でないことがわかり、心理的安全性が保たれる。
カスタム絵文字の追加も推奨する。チーム内でしか通用しない（例えば内輪ネタのような）カスタム絵文字であっても気軽に追加して良い。
理由:
- より良いコミュニケーション手段を模索すること自体が、コミュニケーションを活性化させ、価値を向上させるため
- なお、他人の名誉を毀損するなど、社会人／プロフェッショナルとしてふさわしくない内容は登録しないこと
日付は絶対表記を用いる
Slackに閉じた話ではないが、「明日」や「来週」といった表記は、数日後に読むと期日の認識がズレてしまう可能性がある。そのため、2025.1.29 など絶対表記を用いる。
絵文字リアクションによる積極応答
非同期のコミュニケーションでは、発信者は「投稿内容を見てくれたのかどうか」が気になる。特に確認依頼は見ていればOKで、回答を急がないケースは想像以上に多い。
こういった場面は、::後で確認します:: といった絵文字リアクションで解決するため、積極的に活用する。
また、参加者が多いチャンネルでの発信は勇気がいる。コミュニケーションを活性化させるためにも、絵文字リアクションを積極的に行い推奨／礼賛することが望ましい。
「〇〇してほしい」 「〇〇について教えてほしい」（相談セクション）への対応は絵文字リアクションだけで済まさない
「投稿内容を見てくれたのか」ではなく、「投稿内容を理解して次のアクションをとってくれるのか」を知りたい場面も多い。 そのような場面では、絵文字リアクションのみで済まさず、対応可否をコメントでフィードバックする必要がある。
DMはなるべく避ける
基本的には、DMよりチャンネルでのやり取りを推奨する。チャンネルの中でも、より参加人数が多い（よりオープンな）ものを推奨する。
理由:
- 重複した質問を防ぐため
- 質問事項がチーム／組織に共有されることで、全体の効率が上がるため
- 後から類似の困りごとを持ったメンバーが、キーワード検索で見つけやすくするため
DMの利用を推奨するケース
- 人事相談、機密事項を含む場合（ 機密情報の流出に注意する 章を参照）
- 限られたメンバーのみに、ファイル共有をしたい場合
- 後から検索させる意味がないやり取り（ 「最近元気？」 と同期に投げる場合など）
timesの推奨
timesとは、分報や作業スレッドとも呼ばれ、今取り組んでいることや困っていることを投稿することを指す。
推奨は次のとおり。
- timesの利用を推奨する
- メンバーごとのtimesチャンネルではなく、スレッドでの利用を推奨する
- timesスレッドを他のメンバーが参照するかは任意で良い
理由:
- スレッド単位であれば、本チャンネル側のノイズになることはない。参加メンバーが多い場合は、times専用のチャンネルを作成すれば良い
- メンバーごとの times チャンネルは、チャンネルが必要以上に増えるので推奨しない
- 必要に応じて、作業状況を本人に確認（ポーリング）しなくても把握できる
- ハマったことや調べたことが、後々キーワード検索で見つかり、新規参画者の助けになることも多い
timesスレッドの注意
times内とはいえ、他の人が不快になるような発言や不適切な利用は避ける（チームメンバーが閲覧可能であることを忘れない）。
timesスレッドでのやり取りにこだわりすぎない
- timesスレッドのコメント数は100以上になることもある。その途中で他メンバーに相談事などでメンションを飛ばすと、呼ばれたメンバーには「該当のスレッドの全コメントをチェックしたほうが良いのか」といった迷いが生じる。そのため、相談はtimes内ではなく別メッセージに切り出して行うことを推奨する
- なお、timesの投稿を読んで欲しいときは、timesスレッドでメンションしても良い
- timesのメンションを受けたユーザーが、その後の投稿の通知を受け取りたくない場合は、そのスレッドの通知を切ることで対応する
スレッドのフォローは適当なタイミングで外す（外してもらう）
timesスレッドでメンションされると、その後にもスレッド内の投稿がメンション先のユーザーに通知が飛び続けてしまうのではないか？ という懸念がある。
- 必要に応じて該当スレッドのフォローを外せば良いので、上記観点でメンションを行う／行わないの判断は行わなくても良い
- 前述のとおり、timesのコメントを（全て）読んで欲しいか否かでスレッド内でメンションするかどうかを決める
メッセージ（スレッドのトップ）は具体的に書く
チャンネルのメッセージ（スレッド先頭の投稿）では、話題を端的に表現する。ただし、返信スレッドの中を確認しないと内容が分からないようなメッセージ（タイトル）は非推奨とする。
| メッセージ（スレッド先頭の投稿） | |
|---|---|
| ✅推奨例 | @mirai チケット #4191 foo bar failed のビルドエラーの解消についての相談です。スタックトレースはスレッド内に記載します |
| ❌非推奨例 | レビュー依頼 |
なお、メンションはメッセージ（スレッド先頭）に付けるか、返信スレッド内に付けるかは任意とする。
参考
メッセージのURLを活用する
Slackは本来、フロー情報向けのツールである。しかしこれをWikiなどのストック情報向けツールに転記する労力は高く、運用が形骸化しがちである。そのため、例えば設計方針について議論したスレッドのURLを作業チケットやWikiなどに記載し、トレース可能にする運用を取るチームも良く聞く。本ガイドラインもスレッドURLの活用を推奨する。
なお、決定事項の経緯や議論内容を数年後に確認することもしばしば発生する。そのため議論があればスレッドを利用し、かつ同一スレッドで複数のテーマを混ぜないことが望ましい。関連議論がいくつかのスレッドに分かれる場合、相互に関連スレッドのURLを投稿しておくと良い。
Slackにおける情報ストック機能
Canvas、ブックマーク、ピン留め機能を活用することで、Slack内にてストック情報を取り扱うことも可能である。ユースケースに合わせて使い分ける。
- ブックマーク: PJで利用している課題管理サービスのURLなどを共有したい場合
- ピン留め: PJメンバーに都度参照して欲しい特定のメッセージがある場合
- Canvas: 情報量が多く章立てて整理をしたい場合
Also send to channelは乱発しない
Also send to channel を利用することで、スレッド内の投稿をチャンネルのタイムライン側に重複投稿できる。
推奨は次のとおり。
- 過去のスレッドでやり取りを再開した場合に、チャンネルに在籍するメンバーへ通知する目的で用いる
- スレッド内で重要な決定事項に至った場合は、メンバーに周知する目的で用いる
- スレッド内のやり取りを細かくAlso send to channelすると、スレッドを用いる意味が薄れるので、利用頻度は抑えるように意識する
Canvasの利用について
Canvasは、Slack内で情報を作成、整理、共有するための機能である。
推奨は次の通り。
- 新規参画者向け情報をCanvasに集約する
- オンボーディングガイドライン: プロジェクト概要、チームメンバー紹介、主要なチャンネルリスト、開発環境へのリンク集など
- プロジェクト固有のルールや文化: コミュニケーションルール、定例会議の情報、勤怠連絡フロー、チャージコードなど
- 繰り返し利用する手順や手続きはCanvasに集約する
- 各種アカウントの申請方法やセットアップ方法など
理由:
- 新規参画者は、まずCanvasを見れば必要な情報にアクセスできる状態を目指すことで、オンボーディングコストを減らすため
- チャンネルのログに埋もれず、必要な時に誰でも手順を確認できるようにするため
- 情報は常に最新に保つ必要があるため、複数メンバーで編集できるCanvasが適している
ピン留めとの使い分けについて
ピン留めされた投稿は、投稿者しか編集ができない。そのため後から追記や修正が必要になりそうな情報は、最初からCanvasに記載することを強く推奨する。これにより、チャンネルに所属するメンバー全員で編集が可能となり、記載内容の変更依頼などの余計なやり取りを減らすこともできる。
広めの通知に注意する
@channel
緊急時を除き、原則利用を禁止する。
理由:
@channelはSlackを見ていないユーザーにも通知が飛び、休暇中のメンバー等にも影響があるため- 受取側で制御すべきという考えもあるが、システム障害対応など優先度の高い問い合わせのために、あえて通知をOFFにしていないメンバーも存在するため
@channel を利用して良い場合
システム障害時など、重大かつ緊急度が高い場合は @channel を使っても良い。
@here
メールのCCに似た意図で @here を使うことは禁止とする。
✅️推奨ケース
@真野 @村田 ○○の件ですが\~❌️NG（メールのCC的な形で @here を追加）
@真野 @村田 @here ○○の件ですが理由:
- メールのCC的な参考情報であれば、
@hereを付けずに、チャンネルの未読通知で後で見ることができるため - 真に必要ではないときの通知が常態化すると、
@hereの緊急性やアクションを求める意味合いが弱まり、真に必要なときに読み飛ばされてしまう可能性が上がるため（「狼少年」現象）
@hereを利用して良い場合
- 全員にアクションを促す連絡事項を行う場合
- 例: 「@here {チーム全体イベント} への出欠可否の回答を絵文字リアクションでお願いします」
- 例: 「@here 12/10までに評価入力を、忘れず対応をお願いします」
- 例: 「@here 経費精算は月末までなので、みなさん忘れずに対応をお願いします」
メンション範囲は適切に
過剰なメンションの抑制
原則、レビュー依頼や確認依頼など、行動してほしい時にメンションを付けるものとする。「@mirai ありがとうございます！」 「@mirai 承知しました！」等の挨拶にメンションを付けると、通知が来てノイズになるため非推奨とする。メンションを付けず ありがとうございます！ とすると良い。
情報提供依頼系など善意やり取りはきちんとフィードバックする
情報提供依頼はSlackと親和性が良いタスクである。依頼者は、回答してもらった人に 👍 絵文字だけのリアクションを取る場合があるが、フィードバック付きでコメントを返すことが望ましい。情報提供者としても、その情報が役立ったのかどうかへの関心は強いためである。
フィードバックが難しい場合や、スレッド投稿数をなるべく減らしたい場合は、複数のリアクションを返し感謝の意を強調すると良い。 👍️🎉☺[神] のようなイメージである。
メンションの宛先をできる限り絞り込む
単なる周知目的ではなく行動を促したい相手に絞ること。お見合いになってボールが浮いてしまう可能性がある。「@mirai @mano @murata @ozawa @tanimura AWSの設定で確認したいのですが～」などと広すぎる場合、宛先メンバーは自分よりもっと詳しい人がいるかも知れないと、回答すべきかどうか逡巡してしまう。できれば1、2名に宛先を絞り、宛先メンバーから別の有識者メンバーにディスパッチしてもらう運用を考えると良い。
予約投稿を活用する
特にリーダーからメンバーに対して、深夜（22:00-6:00など）や休日など業務時間外の投稿は原則禁止とし、予約投稿を推奨する。
理由:
- 仕事とプライベートにメリハリを持たせることで、成果の向上を期待できるため
- （システム障害等）緊急時の依頼と混同してしまうため。次回出勤時の対応で良いものと区別すること
- Slackのアップデートにより、チャンネル投稿に閉じずスレッドへの予約投稿が可能となった
受け取り側で制御する方針
「緊急時は電話連絡とし、メンションへの即対応を求めない」と取り決めるのであれば、受け取り側で通知時間を設定し、送る側は送信時間に気を遣わない運用も可とする。ただし、時間外の通知を翌営業日に対応しようと考えて忘れてしまう場合がある。受け取り側は、通知を受けた時点でリマインダーを仕込む、アクティビティ > @メンション を定期的に確認する、といった工夫をする。
不在の表明
表示名に不在情報を記載（例：@sato_11/8休）しておくことを推奨する。受信側は不在時の緊急性の低い通知を防げ、送信側は即レスを期待せずに済む。不在情報がGoogleカレンダーなど別のスケジュールアプリで管理されていたとしても、Slackでの依頼時に気付けるため。
ステータス機能で「休暇中🏝️」にすればよいのではないか
ステータス機能でもチームメンバーに不在であるという状態を表明できる。しかし、次の観点で表示名での表明を推奨する。
- いつから、いつまで休暇なのかステータスでは不明である
- 期間が分かれば、予約投稿で休暇明けに投稿するなどのアクションがすぐ取れる
- 休暇だけでなく出張中などの情報も提示できる
- 例えば、海外出張なので時差があると分かれば、チームメンバーにどれくらいでレスポンスが来そうか予想ができるようになる
- ステータス変更に気が付きにくい
- メンションを付けて投稿する時に常時表示されるわけではないので、ステータスは見過ごされる可能性が高い
復帰時に元に戻すことを忘れない
復帰時に表示名を元に戻すことを忘れがちであるため、注意すること。
可読性を上げるための書式設定
箇条書き、太字、引用などの装飾は、積極的に活用する。文章を構造化することで、読み手にとっての負荷が軽減されるため。Slackの書式以外にも、【すみかっこ】等の記号でセクションを表現することも推奨する。
エラーメッセージの画像添付非推奨、テキストスニペットの推奨
有識者にスタックトレースなどのエラー内容を画像添付して問い合わせることは原則として非推奨とし、テキストで共有することを推奨する。また、共有内容が長文の場合にはテキストスニペット使用が好ましい。
理由:
- 相談相手も裏取りとしてスタックトレースの内容を検索することが多々あるため
- 後から同様の困り事を持った人が、キーワード検索で見つけにくくなるため
- 長いログをそのまま貼り付けるとスレッドを広く埋め尽くしてしまうが、テキストスニペットを使えば1投稿あたりのデフォルト表示域を制限できる
スクリーンショットなどの画像で共有しても良い場合
- コピーできないエラー表示など、テキストでの情報提供が難しい場合
- （相談相手が、コピー範囲などを独自判断で狭められることを防ぐなどの理由で）スクリーンショットでの共有を希望する場合
テキストスニペット利用時は、タイトル（ファイル名）に拡張子をつける
Slackはテキストスニペットに設定されたタイトルをそのままファイル名としてダウンロードするよう動作する。この際拡張子が設定されていないとSlack内でそのままファイルを開くことができなくなってしまう。
機密情報の流出に注意する
営業情報、個人情報、人事情報など機密情報は、「最小権限の原則」に従い、なるべく宛先を狭めるべきである。センシティブな内容をやり取りする場合は、参加者を絞ったプライベートチャンネル／DMグループの活用を推奨する。
メッセージ通知にも気をつける
画面投影やWebミーティングでの画面共有時、意図しないメッセージ通知が見えてしまう事がある。Slackの通知設定にて次に示す設定を施すことで防ぐことが可能なので活用すると良い。
- 通知自体をOFFにする
- 通知はOFFにしないが、メッセージ内容は非表示にする
ファイルの共有に注意する
Slackのファイル共有は便利であるが、ファイルのオーナー（作成者）とチャンネルにメンバー追加できる担当者が必ずしも1:1ではない。そのため、推奨は次のとおり。
- Google Driveなどにファイルをアップロードする
- Google Drive側で適切な権限に絞り込む
理由:
- Google Drive側で権限設定が可能
- Slack上にアップロードされたファイルが、別のチャンネルに再アップロードされて収集がつかなくなるといったケースを防ぎ、統制を図るため
ファイルを直接アップロードしても良い場合
社外勉強会の登壇資料など、一般に「公開済み／公開予定 」のファイルはアップロードして良い。
Google Driveのアップロードしたpptxファイルの予期せぬ更新を防ぐ
Google Driveにアップロードしたpptxファイルのリンクを共有すると、Google Slideで開かれてしまい、スタイルが崩れて保存されてしまうという事象が後を絶たない。回避策として直接Slack上にpptxファイルをアップロードする流派もあるが、チャンネルの参加人数が多い場合は採用しにくい。
以下のように、URLを view(あるいは preview) と書き換えることで不用意な更新を防ぐことができる。Slack上のプレビュー表示も問題なく、目立ったデメリットが無いため、view にしたURLを共有することを推奨する。
https://docs.google.com/document/d/FILE_ID/edit
↓
https://docs.google.com/document/d/FILE_ID/viewURLは以下の手順Aまたは手順Bのどちらかの画面操作からも取得可能である。
- 手順A
- Google Drive上で3点リーダー
- アプリ＞新しいタブで開く、URLをコピー
- 手順B
- Google Drive上で3点リーダー
- アプリ＞プレビューで開く
- プレビュー画面の右上の三点リーダーをクリックし、「新しいウィンドウで開く」を選択し、URLをコピー
view と preview に大きな違いはない。view の方がファイルのメタ情報などが表示され、 preview はより表示領域が広くコンテンツに集中して確認できる点が異なる。preview から view への画面遷移は可能だが、view から preview への導線は無い。
Google DriveのURL共有時プレビュー表示のよるリスクについて
表紙がプレビューされるが、次の理由により問題ないという立場を取る。
- プレビュー表示されるのは1枚目（1シート目）であり、通常は表紙ページが見られるのみ
- ファイルが存在すること自体は知られて良い（チャンネルに投稿しているため）と考えられる
- なにか問題があれば、プレビューを表示しない操作がSlack上で可能なため
プレビューの表示数は抑える
Slackのリンク共有はプレビューが自動的に付与され、リンク先の情報が一目でわかり利便性が高い。しかし、複数のプレビューが表示されると投稿した本文側の注目度が下がり、またチャンネル全体の視認性も低下してしまう。
そのため、1ポストにつき1プレビュー程度になるよう送信者側で整理する運用が望ましい。リンクが重要でない場合はプレビュー表示そのものを削除した方が、読み手が投稿内容に集中できる。
なお、ニュースやブログ記事などのURLそのものを共有することが主目的であれば、1投稿で複数のプレビューを表示させたほうが良い場面もある。読み手に集中して欲しいコンテンツが何かによって適切に使い分ける。
プライベートチャンネルの投稿に対する引用
プライベートチャンネルの投稿コメントを、別のチャンネルにURL引用で投稿すると、該当チャンネルの権限を有していないユーザーにも参照権限を与えてしまう。引用時にはセンシティブな内容が含まれていないか確認するよう注意する。