本規約は、世の中のシステム開発プロジェクトのために無償で提供致します。
ただし、掲載内容および利用に際して発生した問題、それに伴う損害については、フューチャー株式会社は一切の責務を負わないものとします。
また、掲載している情報は予告なく変更することがございますので、あらかじめご了承下さい。
リモートワーク／ハイブリッドワーク前提の業務において、チャットなどの非同期コミュニケーションを円滑に進めることは、業務効率を向上させるだけではなく、従業員全員の満足度を向上させ、より良い職場づくりに繋げることができる。
また、ユーザーの様々な要望に応えるため、現代のチャットサービスは豊富な機能が提供されている。しかし、各ユーザーの考え方／利用者の感覚が千差万別であるため、ある人によって問題ないとされる行動が、別の人にとっては良くない受け取り方をされることも多い。例えば次のような対立が考えられる。
これら運用方法は利用者の所属する部署やチームごとに自然と決めていくことが多いが、複数のチャンネルで異なった運用方針である場合に混乱をきたすことがしばしばである。また、トレードオフを理解せずに、メールのコミュニケーションモデルを引きずった方針を取ってしまうこともある。異なる文化圏のチームから移籍した時に、ハレーションが起きるケースも多い。
本ガイドラインはSlackを対象に利用方針についてのベースとなる規約を設け、Slackを用いてより良いコミュニケーションを促進することを目的とする。
::: warning 有志で作成したドキュメントである
:::
チーム、プロジェクトでの利用の場合は
リクエスト制（By Request） もしくは招待性（
Invite Only）の設定を推奨する。
通常ワークスペースにメンバーを追加した際には #general
へ自動参加するが、他にもメンバー全員に参加して欲しいチャンネルがある場合にはデフォルトチャンネルを追加する。
::: tip 💡ユーザグループに対してもデフォルトチャンネルを設定できるため、用途に応じて使い分けると良い。 :::
ワークスペースごとにガイドラインを設定することを推奨する。後述の表示名設定や、その他チームコミュニケーションにおけるルールを設定する。表示名のガイドラインを設定する権限があるのは、ワークスペースのオーナーだけなので注意する。
ワークスペース内に複数のチームが混在する場合、それぞれのチームごとに管理者権限保持者を設定すること。
理由:
デフォルトのアイコン利用は極力避け、アカウント登録時に各自のアイコン画像を積極的に登録する
理由:
また、GitHub/GitLab、Google Workspace、その他利用サービスも同様のアイコンを利用することで、個人を識別しやすくなる。
表示名（Display name） もしくは氏名（Full name） にて、ローマ字及び漢字（無ければカタカナ）でのフルネームを登録すること。表示名はチームごとに記載文化や書き方が異なるケースが多いので、本ガイドラインでは氏名に記載することを推奨する。例えば「未来 太郎」の場合、「Taro Mirai (未来 太郎)」という記載を推奨する。
理由:
ユーザーグループの利用を推奨する。ゲストユーザーは追加できないため、もしチャンネルに該当するメンバーが在籍する場合は、その旨をメンバー全員が理解しコミュニケーションから除外してしまわないように注意すること。
::: tip 💡ユーザーグループを作成できない状態の回避策 ユーザーグループを作成できない状態（メンバーがワークスペース間にまたがっている場合等）の時、メンション先の対象者全員が個別に自分のSlack設定>Notification>My Keywordsに「＠○○チーム」と予約語を登録することで、擬似的にグループメンションが可能である :::
Slack
コネクト等でチャンネル内に社外のメンバーが含まれる場合には、チャンネル名の先頭に
---ext をつける
理由:
敬称は省略して、 @mano メッセージ内容
といった形式でコメントすること。もし、どうしても敬称を付けて欲しい場合、表示名をさん付けにするハックも存在するため、受信者側で調整する。
理由:
積極的に活用することを推奨する。テキストコミュニケーションは、画像や音声が伝わらない分、冷たく捉えられがちである。特にリーダーなど上位のポジションにいる場合は、メンバーに威圧的に捉えられないように配慮するのが好ましい。
「では、Aの方針でよろしくお願いします！」「では、Aの方針でよろしくお願いします:ganbatte:」 など付けることで、不機嫌でないことがわかり、心理的安全性が保たれる。
積極的にカスタム絵文字を追加することを推奨する。チーム内でしか通用しない（例えば内輪ネタのような）カスタム絵文字であっても気軽に追加して良い。
理由:
非同期のコミュニケーションにおいて発信者が気になる点として、「投稿内容を見てくれたのかどうか」がある。特に確認依頼については見ていればOKで、回答は急がないケースは想像以上に多い。
こういった場面では、::後で確認します::
といった絵文字リアクションを付けることで解決するため、積極的に活用する。
また、参加者が多いチャンネルでの発信は勇気がいることなので、コミュニケーションを活性化させるためにも絵文字リアクションを積極的に行い推奨／礼賛することが望ましい。
::: warning ⚠️「〇〇してほしい」「〇〇について教えてほしい」（相談セクション）への対応は絵文字リアクションだけで済まさない 「投稿内容を見てくれたのかどうか」ではなく、「投稿内容を理解して次のアクションをとってくれるのか」を知りたい場面も多い。 そのような場面では、絵文字リアクションのみで済まさず、対応可否をコメントでフィードバックする必要がある。 :::
基本的には、DMよりチャンネルでのやり取りを推奨する。チャンネルであっても、より参加人数が多い（よりオープンな）チャンネルでのやり取りを推奨する。
理由：
DMの利用を推奨するケース:
timesとは、分報や作業スレッドとも呼ばれ、今取り組んでいることや困っていることを投稿することを指す。
本規約の推奨は次のとおり:
理由:
::: warning ⚠️timesスレッドの注意 times内とはいえ、他の人が不快になるような発言や不適切な利用は避ける（チームメンバーが閲覧可能であることを忘れない） :::
::: tip timesスレッドでのやり取りにこだわりすぎない
:::
::: tip スレッドのフォローは適当なタイミングで外す（外してもらう） timesスレッドでメンションされると、その後にもスレッド内の投稿がメンション先のユーザーに通知が飛び続けてしまうのではないか？という懸念がある。
:::
チャンネルのメッセージ（スレッド先頭の投稿）では、話題を端的に表現する。ただし、返信スレッドの中を確認しないと内容が分からないようなメッセージ（タイトル）は非推奨とする。
| メッセージ（スレッド先頭の投稿） | |
|---|---|
| ✅推奨例 | @mirai チケット #4191 foo bar failed のビルドエラーの解消についての相談です。スタックトレースはスレッド内に記載します |
| ❌非推奨例 | レビュー依頼 |
なお、メンションはメッセージ（スレッド先頭）に付けるか、返信スレッド内に付けるかは任意とする。
参考:
Slackは本来、フロー情報向けのツールである。しかしこれをWikiなどのストック情報向けツールに転記する労力は高く、運用が形骸化しがちである。そのため、例えばあるスレッドで設計方針について議論したのであれば、そのスレッドのURLをコピーして、作業チケットやWikiなどに記載し、トレース可能にするような運用にするチームも良く聞く。本規約もスレッドURLの活用を推奨する。
なお、決定事項の経緯や議論内容を数年経過したのちに確認することもしばしば発生する。そのため議論があればスレッドを利用し、かつ同一スレッドで複数のテーマを混ぜないことが望ましい。関連議論がいくつかのスレッドに分かれる場合、相互に関連スレッドのURLを投稿しておくと良い。
::: tip 💡Slackにおける情報ストック機能
Canvas、ブックマーク、ピン留め機能を活用することで、Slack内にてストック情報を取り扱うことも可能である。PJで利用している課題管理サービスのURLを共有したい場合にはブックマーク、PJメンバーに都度参照して欲しい特定のメッセージがある場合にはピン留め、情報量が多く章立てて整理をしたい場合にはCanvas、などといった形でユースケースに合わせて使い分ける。
:::
Also send to channel を利用することで、スレッド内の投稿をチャンネルのタイムライン側に重複投稿ができる。
本規約の推奨は以下の通り:
@channel緊急時を除き、原則利用を禁止する。
理由:
@channel
はSlackを見ていないユーザにも通知が飛ぶため、休暇中のメンバー等にも影響がある。受取側で制御すべきという考えもあるが、システム障害対応など優先度の高い問い合わせのために、あえてOFFにしていないメンバーも存在することを考えると、なるべく利用を避けた方が無難である利用して良い場合:
@channel
を使っても良い@hereメールのCCに似た意図で @here
を使うことは禁止とする。
推奨ケース
@真野 @村田 ○○の件ですが\~NG（メールのCC的な形で @here を追加）
@真野 @村田 @here ○○の件ですが理由:
@here
を付けずに、チャンネルの未読通知で後で見ることができるため@here
の緊急性やアクションを求める意味合いが弱まり、真に必要なときに読み飛ばされてしまう可能性が上がるため（「狼少年」現象）利用して良い場合:
原則、レビュー依頼や確認依頼など、行動してほしい時にメンションを付けるものとする。「@mirai ありがとうございます！」「@mirai 承知しました！」等の挨拶にメンションを付けると、通知が来てノイズになるため非推奨とする。メンションを付けず「ありがとうございます！」とすると良い。
::: tip
💡情報提供依頼系など善意やり取りはきちんとフィードバックする
情報提供依頼はSlackと親和性が良いタスクである。この際、情報提供の依頼者は、回答してもらった人に対して、:+1:
絵文字だけのリアクションを取る場合があるが、フィードバック付きでコメントを返すことが望ましい。情報提供者としても、その情報が役立ったのか、またそうでないかの関心は強いためである。
もし、フィードバックが難しい場合や、スレッド投稿数をなるべく減らしたいなどの意図がある場合は、複数のリアクションを返し感謝の意を強調すると良い。
👍️🎉☺[神] のようなイメージである。
:::
単なる周知目的ではなく行動を促したい相手に絞ること。お見合いになってボールが浮いてしまう可能性がある。「@mirai @mano @murata @ozawa @tanimura AWSの設定で確認したいのですが～」などと広すぎる場合は、宛先メンバーは自分よりもっと詳しい人がいるかも知れないので、回答すべきかどうか逡巡してしまう。できれば1、2名に宛先を絞り、宛先メンバーから別の有識者メンバーにディスパッチしてもらう運用を考えると良い。
特にリーダーからメンバーに対して、深夜（22:00-6:00など）や休日など業務時間外の投稿は原則禁止とし、予約投稿を推奨する。
理由:
::: tip 💡受け取り側で制御する方針
システム障害時などの緊急時は電話連絡とし、メンションに対する即対応を求めない取り決めを行うのであれば、受け取り側で通知時間を設定し、送る側は送信時間に気を遣わない運用も可とする。ただし、時間外に通知を受け翌営業日に対応しようと考えたが翌営業日には忘れているような場合、受け取り側で通知を受けた時点でリマインダーを仕込んだり、アクティビティ
> @メンション
を定期的に確認するような工夫をする。 :::
表示名に不在情報を記載（例：@sato_11/8休）しておくことを推奨する。受信側が不在時に緊急性の低い通知を防げたり、送信側が即レスを期待しなくて済む。不在情報がGoogleカレンダーなど別のスケジュールアプリで管理されていたとしても、Slackでの依頼時に気付けるため。
::: tip 💡ステータス機能で「休暇中🏝️」にすればよいのではないか
ステータス機能でもチームメンバーに不在であるという状態を表明できる。しかし、次の観点で表示名での表明を推奨する。
:::
箇条書き、太字、引用などの装飾は、積極的に活用する。文章を構造化することで、読み手にとっての負荷が軽減されるため。Slackの書式以外にも、【すみかっこ】等の記号を使うことでセクションを表現することも同時に推奨する。
有識者にスタックトレースなどのエラー内容を画像添付して問い合わせることは原則として非推奨とし、テキストで共有することを推奨する。また、共有内容が長文の場合にはテキストスニペット使用が好ましい。
理由:
次の場合は、スクリーンショットなどの画像で共有しても良い。
::: tip
💡テキストスニペット利用時は、タイトル（ファイル名）に拡張子をつける
Slackはテキストスニペットに設定されたタイトルをそのままファイル名としてダウンロードするよう動作する。この際拡張子が設定されていないとSlack内でそのままファイルを開くことができなくなってしまう。
:::
営業情報、個人情報、人事情報など機密情報は、「最小権限の原則」に従い、なるべく宛先を狭めるべきである。センシティブなやり取りを行う場合は、参加者を絞ったプライベートチャンネル／DMグループの活用を推奨する。
:::tip 💡メッセージ通知にも気をつける
画面投影やWebミーティングでの画面共有時、意図しないメッセージ通知が見えてしまう事がある。Slackの通知設定にて次に示す設定を施すことで防ぐことが可能なので活用すると良い。
Slackのファイル共有は便利であるが、ファイルのオーナー（作成者）とチャンネルにメンバー追加できる担当者が必ずしも1:1ではない。そのため次の運用が望ましい。
推奨する運用:
理由:
該当しないケース:
Google DriveのURL共有時プレビュー表示について:
プライベートチャンネルの投稿コメントを、別のチャンネルにURL引用で投稿すると、該当チャンネルの権限を有していないユーザーにも参照権限を与えてしまう。引用時にはセンシティブな内容が含まれていないか確認するよう注意する。
本ガイドラインの策定にあたっては、すでにインターネットに公開されているSlack利用ガイドラインや記事等も参照させていただいた。本ガイドラインが皆様のSlack活用をより快適にする一助となれば幸いである。
参考：