From 65c22d63bdce6888160785d54da604b9c04d566f Mon Sep 17 00:00:00 2001 From: Junki Mano Date: Fri, 13 Dec 2024 14:59:46 +0900 Subject: [PATCH] Update slack_usage_guidelines.md --- documents/forSlack/slack_usage_guidelines.md | 225 ++++++++++--------- 1 file changed, 113 insertions(+), 112 deletions(-) diff --git a/documents/forSlack/slack_usage_guidelines.md b/documents/forSlack/slack_usage_guidelines.md index e958571c..56841aa6 100644 --- a/documents/forSlack/slack_usage_guidelines.md +++ b/documents/forSlack/slack_usage_guidelines.md @@ -120,45 +120,6 @@ Slack コネクト等でチャンネル内に社外のメンバーが含まれ * コミュニケーションを迅速・シンプルにするため -## 広めの通知に注意する - -### `@channel` - -緊急時を除き、原則利用を禁止する。 - -理由: - -* `@channel` はSlackを見ていないユーザにも通知が飛ぶため、休暇中のメンバー等にも影響がある。受取側で制御すべきという考えもあるが、システム障害対応など優先度の高い問い合わせのために、あえてOFFにしていないメンバーも存在することを考えると、なるべく利用を避けた方が無難である - -利用して良い場合: - -* システム障害時など、重大かつ緊急度が高い場合は `@channel` を使っても良い - -### `@here` - -メールのCCに似た意図で `@here` を使うことは禁止とする。 - -推奨ケース - -```txt -@真野 @村田 ○○の件ですが\~ -``` - -NG（メールのCC的な形で `@here` を追加） - -```txt -@真野 @村田 @here ○○の件ですが -``` - -理由: - -* メールのCC的な参考情報であれば、`@here` を付けずに、チャンネルの未読通知で後で見ることができるため -* 真に必要ではないときに通知が飛ぶことが常態化すると、`@here` の緊急性やアクションを求める意味合いが弱まり、真に必要なときに読み飛ばされてしまう可能性が上がるため（「狼少年」現象） - -利用して良い場合: - -* 全員にアクションを促す連絡事項を行う場合。例えば、チーム全体イベントへの出欠可否を確認する連絡など - ## 絵文字や感嘆符を活用する 積極的に活用することを推奨する。テキストコミュニケーションは、画像や音声が伝わらない分、冷たく捉えられがちである。特にリーダーなど上位のポジションにいる場合は、メンバーに威圧的に捉えられないように配慮するのが好ましい。 @@ -175,61 +136,18 @@ NG（メールのCC的な形で `@here` を追加） * なお、当然ながら他人の名誉を毀損するなど、社会人／プロフェッショナルとしてふさわしくない内容は登録しないこと -## 機密情報の流出に注意する - -営業情報、個人情報、人事情報など機密情報は、「最小権限の原則」に従い、なるべく宛先を狭めるべきである。センシティブなやり取りを行う場合は、参加者を絞ったプライベートチャンネル／DMグループの活用を推奨する。 - -:::tip メッセージ通知にも気をつける -画面投影やWebミーティングでの画面共有時、意図しないメッセージ通知が見えてしまう事がある。Slackの通知設定にて次に示す設定を施すことで防ぐことが可能なので活用すると良い。 - -* 通知自体をOFFにする -* 通知はOFFにしないが、メッセージ内容は非表示にする -::: - -## ファイルの共有に注意する - -Slackのファイル共有は便利であるが、ファイルのオーナー（作成者）とチャンネルにメンバー追加できる担当者が必ずしも1:1ではない。そのため次の運用が望ましい。 - -推奨する運用: - -* Google Driveなどにファイルをアップロードする -* Google Drive側で適切な権限に絞り込む - -理由: - -* Google Drive側で権限設定が可能 -* Slack上にアップロードされたファイルが、別のチャンネルに再アップロードされて収集がつかなくなるといったケースを防ぎ、統制を図るため - -該当しないケース: - -* 社外勉強会の登壇資料など、一般に「公開済み／公開予定 」のファイルはアップロードして良い - -Google DriveのURL共有時プレビュー表示について: - -* 表紙がプレビューされるが、次の理由により問題ないという立場を取る。 - * プレビュー表示されるのは1枚目（1シート目）であり、通常は表紙ページが見られるのみ - * ファイルが存在すること自体は知られて良い（チャンネルに投稿しているため）と考えられる - * なにか問題があれば、プレビュー表示を行わない操作がSlack上で可能である - -## メンション範囲は適切に +## 絵文字リアクションによる積極応答 -### 過剰なメンションの抑制 +非同期のコミュニケーションにおいて発信者が気になる点として、「投稿内容を見てくれたのかどうか」がある。特に確認依頼については見ていればOKで、回答は急がないケースは想像以上に多い。 +こういった場面では、::後で確認します:: といった絵文字リアクションを付けることで解決するため、積極的に活用する。 -原則、レビュー依頼や確認依頼など、行動してほしい時にメンションを付けるものとする。「@mirai ありがとうございます！」「@mirai 承知しました！」等の挨拶にメンションを付けると、通知が来てノイズになるため非推奨とする。メンションを付けず「ありがとうございます！」とすると良い。 +また、参加者が多いチャンネルでの発信は勇気がいることなので、コミュニケーションを活性化させるためにも絵文字リアクションを積極的に行い推奨／礼賛することが望ましい。 -::: tip 情報提供依頼系など善意やり取りはきちんとフィードバックする -情報提供依頼はSlackと親和性が良いタスクである。この際、情報提供の依頼者は、回答してもらった人に対して、:+1: 絵文字だけのリアクションを取る場合があるが、フィードバック付きでコメントを返すことが望ましい。情報提供者としても、その情報が役立ったのか、またそうでないかの関心は強いためである。 -もし、フィードバックが難しい場合や、スレッド投稿数をなるべく減らしたいなどの意図がある場合は、複数のリアクションを返し感謝の意を強調すると良い。 👍️🎉☺\[神\] のようなイメージである。 +::: warning 「〇〇してほしい」「〇〇について教えてほしい」（相談セクション）への対応は絵文字リアクションだけで済まさない +「投稿内容を見てくれたのかどうか」ではなく、「投稿内容を理解して次のアクションをとってくれるのか」を知りたい場面も多い。 +そのような場面では、絵文字リアクションのみで済まさず、対応可否をコメントでフィードバックする必要がある。 ::: -### メンションの宛先をできる限り絞り込む - -単なる周知目的ではなく行動を促したい相手に絞ること。お見合いになってボールが浮いてしまう可能性がある。「@mirai @mano @murata @ozawa @tanimura AWSの設定で確認したいのですが～」などと広すぎる場合は、宛先メンバーは自分よりもっと詳しい人がいるかも知れないので、回答すべきかどうか逡巡してしまう。できれば1、2名に宛先を絞り、宛先メンバーから別の有識者メンバーにディスパッチしてもらう運用を考えると良い。 - -## プライベートチャンネルの投稿に対する引用 - -プライベートチャンネルの投稿コメントを、別のチャンネルにURL引用で投稿すると、該当チャンネルの権限を有していないユーザーにも参照権限を与えてしまう。引用時にはセンシティブな内容が含まれていないか確認するよう注意する。 - ## DMはなるべく避ける 基本的には、DMよりチャンネルでのやり取りを推奨する。チャンネルであっても、より参加人数が多い（よりオープンな）チャンネルでのやり取りを推奨する。 @@ -242,7 +160,7 @@ Google DriveのURL共有時プレビュー表示について: DMの利用を推奨するケース: -* 人事相談、機密事項を含む場合 +* 人事相談、機密事項を含む場合（「機密情報の流出に注意する」章を参照） * 限られたメンバーのみに、ファイル共有をしたい場合 * 後から検索させる意味がないやり取り（「最近元気？」と同期に投げる場合など） @@ -277,6 +195,7 @@ timesスレッドでメンションを飛ばすと、その後の投稿によっ * 該当スレッドのフォローを外せば良いので、上記観点でメンションを行う／行わないの判断は行わなくても良い。前述の通り、timesのコメントを（全て）読んで欲しい否かで決める + ## メッセージ（スレッドのトップ）は具体的に書く チャンネルのメッセージ（スレッド先頭の投稿）では、話題を端的に表現する。ただし、返信スレッドの中を確認しないと内容が分からないようなメッセージ（タイトル）は非推奨とする。 @@ -293,6 +212,16 @@ timesスレッドでメンションを飛ばすと、その後の投稿によっ * [Slackで要件を書かずに「質問があります。詳細はスレッドに記載」をやめたほうがいい理由 \- CARTA TECH BLOG](https://techblog.cartaholdings.co.jp/entry/better_slack_communication) * [リモートワーク時代を生き抜くAI・機械学習チームの働き方 \- エムスリーテックブログ](https://www.m3tech.blog/entry/2024/12/07/110000) +## メッセージのURLを活用する + +Slackは本来、フロー情報向けのツールである。しかしこれをWikiなどのストック情報向けツールに転記する労力は高く、運用が形骸化しがちである。そのため、例えばあるスレッドで設計方針について議論したのであれば、そのスレッドのURLをコピーして、作業チケットやWikiなどに記載し、トレース可能にするような運用にするチームも良く聞く。本規約もスレッドURLの活用を推奨する。 + +なお、決定事項の経緯や議論内容を数年経過したのちに確認することもしばしば発生する。そのため議論があればスレッドを利用し、かつ同一スレッドで複数のテーマを混ぜないことが望ましい。関連議論がいくつかのスレッドに分かれる場合、相互に関連スレッドのURLを投稿しておくと良い。 + +::: tip Slackにおける情報ストック機能 +Canvas、ブックマーク、ピン留め機能を活用することで、Slack内にてストック情報を取り扱うことも可能である。PJで利用している課題管理サービスのURLを共有したい場合にはブックマーク、PJメンバーに都度参照して欲しい特定のメッセージがある場合にはピン留め、情報量が多く章立てて整理をしたい場合にはCanvas、などといった形でユースケースに合わせて使い分ける。 +::: + ## Also send to channelは乱発しない Also send to channel を利用することで、スレッド内の投稿をチャンネルのタイムライン側に重複投稿ができる。 @@ -303,6 +232,60 @@ Also send to channel を利用することで、スレッド内の投稿をチ * スレッド内で重要な決定事項に至った場合は、メンバーに周知する目的で用いる * スレッド内のやり取りを細かくAlso send to channelすると、スレッドを用いる意味が薄れるので、利用頻度は抑えるように意識する +## 広めの通知に注意する + +### `@channel` + +緊急時を除き、原則利用を禁止する。 + +理由: + +* `@channel` はSlackを見ていないユーザにも通知が飛ぶため、休暇中のメンバー等にも影響がある。受取側で制御すべきという考えもあるが、システム障害対応など優先度の高い問い合わせのために、あえてOFFにしていないメンバーも存在することを考えると、なるべく利用を避けた方が無難である + +利用して良い場合: + +* システム障害時など、重大かつ緊急度が高い場合は `@channel` を使っても良い + +### `@here` + +メールのCCに似た意図で `@here` を使うことは禁止とする。 + +推奨ケース + +```txt +@真野 @村田 ○○の件ですが\~ +``` + +NG（メールのCC的な形で `@here` を追加） + +```txt +@真野 @村田 @here ○○の件ですが +``` + +理由: + +* メールのCC的な参考情報であれば、`@here` を付けずに、チャンネルの未読通知で後で見ることができるため +* 真に必要ではないときに通知が飛ぶことが常態化すると、`@here` の緊急性やアクションを求める意味合いが弱まり、真に必要なときに読み飛ばされてしまう可能性が上がるため（「狼少年」現象） + +利用して良い場合: + +* 全員にアクションを促す連絡事項を行う場合。例えば、チーム全体イベントへの出欠可否を確認する連絡など + +## メンション範囲は適切に + +### 過剰なメンションの抑制 + +原則、レビュー依頼や確認依頼など、行動してほしい時にメンションを付けるものとする。「@mirai ありがとうございます！」「@mirai 承知しました！」等の挨拶にメンションを付けると、通知が来てノイズになるため非推奨とする。メンションを付けず「ありがとうございます！」とすると良い。 + +::: tip 情報提供依頼系など善意やり取りはきちんとフィードバックする +情報提供依頼はSlackと親和性が良いタスクである。この際、情報提供の依頼者は、回答してもらった人に対して、:+1: 絵文字だけのリアクションを取る場合があるが、フィードバック付きでコメントを返すことが望ましい。情報提供者としても、その情報が役立ったのか、またそうでないかの関心は強いためである。 +もし、フィードバックが難しい場合や、スレッド投稿数をなるべく減らしたいなどの意図がある場合は、複数のリアクションを返し感謝の意を強調すると良い。 👍️🎉☺\[神\] のようなイメージである。 +::: + +### メンションの宛先をできる限り絞り込む + +単なる周知目的ではなく行動を促したい相手に絞ること。お見合いになってボールが浮いてしまう可能性がある。「@mirai @mano @murata @ozawa @tanimura AWSの設定で確認したいのですが～」などと広すぎる場合は、宛先メンバーは自分よりもっと詳しい人がいるかも知れないので、回答すべきかどうか逡巡してしまう。できれば1、2名に宛先を絞り、宛先メンバーから別の有識者メンバーにディスパッチしてもらう運用を考えると良い。 + ## 予約投稿を活用する 特にリーダーからメンバーに対して、深夜（22:00-6:00など）や休日など業務時間外の投稿は原則禁止とし、予約投稿を推奨する。 @@ -317,18 +300,6 @@ Also send to channel を利用することで、スレッド内の投稿をチ システム障害時などの緊急時は電話連絡とし、メンションに対する即対応を求めない取り決めを行うのであれば、受け取り側で通知時間を設定し、送る側は送信時間に気を遣わない運用も可とする。ただし、時間外に通知を受け翌営業日に対応しようと考えたが翌営業日には忘れているような場合、受け取り側で通知を受けた時点でリマインダーを仕込んだり、アクティビティ \> @メンション を定期的に確認するような工夫をする。 ::: -## 絵文字リアクションによる積極応答 - -非同期のコミュニケーションにおいて発信者が気になる点として、「投稿内容を見てくれたのかどうか」がある。特に確認依頼については見ていればOKで、回答は急がないケースは想像以上に多い。 -こういった場面では、::後で確認します:: といった絵文字リアクションを付けることで解決するため、積極的に活用する。 - -また、参加者が多いチャンネルでの発信は勇気がいることなので、コミュニケーションを活性化させるためにも絵文字リアクションを積極的に行い推奨／礼賛することが望ましい。 - -::: warning 「〇〇してほしい」「〇〇について教えてほしい」（相談セクション）への対応は絵文字リアクションだけで済まさない -「投稿内容を見てくれたのかどうか」ではなく、「投稿内容を理解して次のアクションをとってくれるのか」を知りたい場面も多い。 -そのような場面では、絵文字リアクションのみで済まさず、対応可否をコメントでフィードバックする必要がある。 -::: - ## 不在の表明 表示名に不在情報を記載（例：`@sato_11/8休`）しておくことを推奨する。受信側が不在時に緊急性の低い通知を防げたり、送信側が即レスを期待しなくて済む。不在情報がGoogleカレンダーなど別のスケジュールアプリで管理されていたとしても、Slackでの依頼時に気付けるため。 @@ -344,16 +315,6 @@ Also send to channel を利用することで、スレッド内の投稿をチ * メンションを付けて投稿する時に常時表示されるわけではないので、ステータスは見過ごされる可能性が高い ::: -## メッセージのURLを活用する - -Slackは本来、フロー情報向けのツールである。しかしこれをWikiなどのストック情報向けツールに転記する労力は高く、運用が形骸化しがちである。そのため、例えばあるスレッドで設計方針について議論したのであれば、そのスレッドのURLをコピーして、作業チケットやWikiなどに記載し、トレース可能にするような運用にするチームも良く聞く。本規約もスレッドURLの活用を推奨する。 - -なお、決定事項の経緯や議論内容を数年経過したのちに確認することもしばしば発生する。そのため議論があればスレッドを利用し、かつ同一スレッドで複数のテーマを混ぜないことが望ましい。関連議論がいくつかのスレッドに分かれる場合、相互に関連スレッドのURLを投稿しておくと良い。 - -::: tip Slackにおける情報ストック機能 -Canvas、ブックマーク、ピン留め機能を活用することで、Slack内にてストック情報を取り扱うことも可能である。PJで利用している課題管理サービスのURLを共有したい場合にはブックマーク、PJメンバーに都度参照して欲しい特定のメッセージがある場合にはピン留め、情報量が多く章立てて整理をしたい場合にはCanvas、などといった形でユースケースに合わせて使い分ける。 -::: - ## 可読性を上げるための書式設定 箇条書き、太字、引用などの装飾は、積極的に活用する。文章を構造化することで、読み手にとっての負荷が軽減されるため。Slackの書式以外にも、【すみかっこ】等の記号を使うことでセクションを表現することも同時に推奨する。 @@ -377,6 +338,46 @@ Canvas、ブックマーク、ピン留め機能を活用することで、Slack Slackはテキストスニペットに設定されたタイトルをそのままファイル名としてダウンロードするよう動作する。この際拡張子が設定されていないとSlack内でそのままファイルを開くことができなくなってしまう。 ::: +## 機密情報の流出に注意する + +営業情報、個人情報、人事情報など機密情報は、「最小権限の原則」に従い、なるべく宛先を狭めるべきである。センシティブなやり取りを行う場合は、参加者を絞ったプライベートチャンネル／DMグループの活用を推奨する。 + +:::tip メッセージ通知にも気をつける +画面投影やWebミーティングでの画面共有時、意図しないメッセージ通知が見えてしまう事がある。Slackの通知設定にて次に示す設定を施すことで防ぐことが可能なので活用すると良い。 + +* 通知自体をOFFにする +* 通知はOFFにしないが、メッセージ内容は非表示にする +::: + +## ファイルの共有に注意する + +Slackのファイル共有は便利であるが、ファイルのオーナー（作成者）とチャンネルにメンバー追加できる担当者が必ずしも1:1ではない。そのため次の運用が望ましい。 + +推奨する運用: + +* Google Driveなどにファイルをアップロードする +* Google Drive側で適切な権限に絞り込む + +理由: + +* Google Drive側で権限設定が可能 +* Slack上にアップロードされたファイルが、別のチャンネルに再アップロードされて収集がつかなくなるといったケースを防ぎ、統制を図るため + +該当しないケース: + +* 社外勉強会の登壇資料など、一般に「公開済み／公開予定 」のファイルはアップロードして良い + +Google DriveのURL共有時プレビュー表示について: + +* 表紙がプレビューされるが、次の理由により問題ないという立場を取る。 + * プレビュー表示されるのは1枚目（1シート目）であり、通常は表紙ページが見られるのみ + * ファイルが存在すること自体は知られて良い（チャンネルに投稿しているため）と考えられる + * なにか問題があれば、プレビュー表示を行わない操作がSlack上で可能である + +## プライベートチャンネルの投稿に対する引用 + +プライベートチャンネルの投稿コメントを、別のチャンネルにURL引用で投稿すると、該当チャンネルの権限を有していないユーザーにも参照権限を与えてしまう。引用時にはセンシティブな内容が含まれていないか確認するよう注意する。 + # さいごに 本ガイドラインの策定にあたっては、すでにインターネットに公開されているSlack利用ガイドラインや記事等も参照させていただいた。本ガイドラインが皆様のSlack活用をより快適にする一助となれば幸いである。