Slackの運用ルール：社内ガイドラインの例と定着させるコツ

Slack（スラック）を入れて3か月ほどたつと、「結局メールで送ってくる人がいる」「大事な話がDMで進んでいて誰も経緯を知らない」「チャンネルが多すぎて読まれない」という声が出てきます。Slackが使いにくいのではなく、使い方が人によってばらばらなのが原因です。ここでは、社員20名ほどのWeb制作会社「サンプルデザイン」（プロプラン）が実際に使っている社内ガイドラインを例に、ルールに入れる項目、そのまま使える文面、決めすぎないための線の引き方、新しく入った人への案内、業務時間外の通知の決まり、定着しないパターンの直し方、見直しの仕方まで書きます。チャンネル・メンション・通知それぞれの設定の手順は個別の記事にあるので、ここでは「会社として何を決めて、どう守ってもらうか」に絞ります。

この記事の内容

1. 先に決めること
2. ルールに入れる項目の一覧
3. 社内ガイドラインの例
4. ガイドラインを置く・届ける
5. 業務時間外の通知と通知の一時停止の決まり
6. 定着させる段取り
7. 定着しないパターンと直し方
8. ルールの見直しの仕方
9. 応用
10. できないことと、その代わり
11. よく詰まるところ
12. 次にやること

先に決めること

ガイドラインの中身より先に、次の4つを決めます。ここが決まっていないと、良い文面を書いても誰も読まず、半年後に誰も直さない文書が残ります。

決めること	サンプルデザインの答え	理由
誰が決めて、誰が直すか	総務Eとディレクター Aの2人。代表は最後に目を通すだけ	総務だけだと現場の判断（案件のチャンネルの切り方）に答えられない
どこに置くか	#ask-slack のcanvas。#notice-全社 のタブからもリンク	全員がいつでも開ける場所に1つだけ置く。ファイルやメールで配らない
何行まで書くか	1画面に収まる量（見出し7つ・各3行まで）	長いルールは読まれない。細かい話は個別のcanvasに分ける
いつ見直すか	3か月ごと（1月・4月・7月・10月の第1月曜）	決めたまま放っておくと、実際の使い方とずれていく

いちばん大事なのは置き場所を1つにすることです。ガイドラインをPDFにしてメールで配ると、版が増えて、どれが最新か分からなくなります。Slackの中のcanvasに置けば、直したその日から全員が同じものを見ます。

もう1つ、ルールは「守らせるもの」ではなく「迷ったときに見るもの」と位置づけます。Slackには、書き込みがルールに沿っているかを自動で止める仕組みはほとんどありません。全員が同じ判断をしやすくするための目安として書くと、文面が命令口調にならず、読んでもらえます。

ルールに入れる項目の一覧

小さな会社のガイドラインに入れる項目と、入れなくていい項目を分けると次のとおりです。

項目	入れるか	書く中身	詳しい設定の記事
チャンネルの作り方と命名	入れる	接頭辞の一覧と、作る前に確かめること	Slackのチャンネル：作り方・命名ルール・パブリックとプライベートの使い分け
パブリックとプライベート	入れる	パブリックが基本。プライベートにする話の例	同上
スレッドとメンション	入れる	返信はスレッド、依頼は個人をメンション、@channel を使う場面	Slackのスレッドとメンション：@hereと@channelの違い、メンショングループの作り方
返事の目安	入れる	いつまでに返すか、すぐ返せないときの合図	—
DMを使わない場面	入れる	依頼・質問・報告はチャンネル	—
業務時間外の連絡	入れる	通知スケジュール、予約送信、急ぎのときの電話	Slackの通知設定：通知が来ないときの直し方と、うるさくない設定
社外の人がいるチャンネル	入れる	ext- には社内の話を書かない	Slackコネクトとは：取引先と同じチャンネルで話す設定と注意点
ファイルと決定事項の置き場所	入れる	決まったことはcanvasへ、正式な書類はGoogleドライブへ	Slackのcanvas（キャンバス）：議事録・手順書・チャンネルの案内を置く
表示名とプロフィール	入れる（1行）	「姓 名（部署）」の形	Slackの導入手順：ワークスペースの作成から社員の招待・初期設定まで
絵文字の種類と意味	3つだけ	対応済み・見ています・相談したい	Slackの絵文字とリアクション：カスタム絵文字の追加と、返事を減らす使い方
文章の書き方（敬語・挨拶）	入れない	「お疲れ様です」を省いてよい、と1行だけ	—
通知の細かい設定	入れない	職種別のおすすめは通知の記事に任せる	Slackの通知設定
罰則・違反の扱い	入れない	書かない	—

「入れない」にした項目は、決めないのではなく、ガイドラインの本文に書かないという意味です。通知の設定は人によって正解が違うので、会社として決めるのは「急ぎの連絡はどう送るか」という送る側の決まりだけにして、受ける側の設定は職種別の例を見せるだけにしています。

社内ガイドラインの例

#ask-slack のcanvasにそのまま置いている文面です。社名とチャンネル名を自社のものに替えれば使えます。canvasの見出しは「（見出し）」と書いた行です。

（見出し）サンプルデザインのSlackの使い方（2026年10月版）
迷ったときに見る目安です。分からないことは #ask-slack に書いてください。

（見出し）1. どこに書くか
- 仕事の話はチャンネルに書く。DMは個人的な連絡と、人に聞かれたくない相談だけ
- 案件の話は #pj-（案件名）、部署の話は #team-（部署名）、質問は #ask-（窓口）
- どこに書くか迷ったら #ask-slack に書けば、誰かが案内します

（見出し）2. チャンネルを作るとき
- 名前の頭に用途を付ける：notice- / team- / pj- / ext- / ask- / log- / times-
- 案件は「pj-取引先-内容」（例 #pj-a社-サイト改修）。年や日付は入れない
- 作ったら説明欄に「何を書く場所か」と「社外の人がいるか」を書く
- パブリックで作る。人事・給与・見積もりの金額だけプライベート
- 案件が終わったら作った人がアーカイブする

（見出し）3. 返信とメンション
- 返信は必ずスレッドで。チャンネルに直接書くのは新しい話題だけ
- 依頼は相手を個人でメンションし、期限を日付と曜日で書く
- @channel は締め切りの変更・障害・全員に関わる変更だけ。夜間と休日は使わない
- @here は勤務時間中の急ぎだけ

（見出し）4. 返事の目安
- メンションされたら、その日のうちに返す
- すぐ答えられないときは :eyes: を付ける（見ています、の合図）
- 終わったら :white_check_mark: を付ける。「了解です」だけの返信は書かなくてよい

（見出し）5. 業務時間外
- 通知スケジュールは平日 9:00〜18:00 が会社の標準。時間がずれる人は自分で変える
- 夜や休日に思いついた連絡は、予約送信で翌営業日の朝に送る
- 時間外に返事は求めない。本当に急ぐときは電話する

（見出し）6. 社外の人がいる場所
- #ext- のチャンネルは取引先の人も読んでいる。社内の相談・金額・ほかの取引先の話は書かない
- ゲスト（外注さん）が入っている #pj- も同じ。説明欄に「ゲストあり」と書いてある

（見出し）7. 決まったことと書類
- スレッドで決まったことは、チャンネルのcanvas「案件の概要」の決定事項に日付と一緒に書く
- 見積書・契約書・請求書はGoogleドライブに置き、Slackにはリンクだけ貼る

持ち主：総務E・ディレクターA ／ 次の見直し：2027年1月

この文面で意識しているのは、すべての行が「何をするか」で終わっていることです。「チャンネルを適切に使い分ける」のような書き方は、読んだ人が何をすればいいか分かりません。「案件の話は #pj- に書く」と書けば、迷う余地がありません。

期限を書くときに日付と曜日を両方入れるのは、読み違いを減らすためです。依頼の例として @デザイナーB 11/6(金)までにトップのカンプをお願いします のような1行をガイドラインの下に添えておくと、書き方がそろいます。

決めすぎないこと

ルールを作る担当になると、気づいたことを全部書き足したくなります。実際に運用していると、項目が20を超えたあたりで誰も最後まで読まなくなり、守られている項目と守られていない項目の差が開いていきます。サンプルデザインでは、次の3つの基準で書くかどうかを決めています。

• 守られないと誰かが困るか。困らないこと（挨拶の有無、絵文字の好み）は書かない
• 機能の設定で済むか。投稿できる人を絞る、デフォルトのチャンネルに自動で入れるといった、設定で済むことは文章にしない
• 1人の困りごとか、全員の困りごとか。1人だけの話は本人と話して終わりにし、ルールにしない

書かないと決めたことの例が次の表です。

よくある「書きたくなるルール」	書かない理由	代わりにやること
「お疲れ様です」を書かない	書きたい人が書いても誰も困らない	「省いてよい」とだけ伝える
絵文字は業務用の10種類だけ	守られず、確認もできない	意味を決めるのは3つだけにする
チャンネル名は英字のみ	日本語のほうが探しやすい人が多い	接頭辞だけ英字にそろえる
毎朝全員が「出勤しました」と書く	投稿が20件並び、ほかの連絡が流れる	ステータスや勤怠の仕組みで分かるようにする
times- を必ず毎日書く	書く人と書かない人がいてよい	任意にして、書く人の分だけ作る
メッセージは3行以内	長い説明が要る場面もある	長くなるならcanvasに書いてリンクを貼る、と伝える

ルールが少ないほど、ひとつひとつが守られます。最初は5つの見出しで始め、困りごとが出たときに1行ずつ足していくほうが、最初から完璧な文書を作るより定着します。

ガイドラインを置く・届ける

canvasに置いてチャンネルのタブにする

1. サイドバーで「ファイル」を開き、プラスボタンから「canvas」を選びます。
2. タイトルを「案内：Slackの使い方」にして、上の文面を書きます。見出しは / で挿入メニューを出して選べます。
3. #ask-slack を開き、会話の上部の「＋」から「canvas」を選び、作ったcanvasを検索して「挿入」します。
4. アクセス権限を確かめて「共有」します。
5. タブを右クリックして「デフォルトで canvas を表示する」を選びます。
6. #notice-全社 にも同じcanvasをタブとして追加します。

canvasは最初は招待した人しか見られない状態で作られますが、パブリックチャンネルで共有すると、そのチャンネルの全員に見えるようになります。編集できる人は、持ち主の総務EとディレクターAの2人だけにしておき、ほかの人は閲覧だけにします。誰でも直せるようにすると、気づかないうちに文面が変わり、見直しのときに何が変わったのか追えなくなります。

新しく入った人の入口を作る

入社した人やゲストで入った外注さんが最初に迷うのは、「どのチャンネルを見ればいいか」と「何を読めばいいか」です。サンプルデザインでは、新しく入った人向けの入口のcanvasを1つ作り、#notice-全社 のタブに置いています。中身は次のとおりです。

（見出し）ようこそ。最初の1週間でやること
[ ] プロフィールの表示名を「姓 名（部署）」にする
[ ] 写真を設定する
[ ] Slackの使い方（#ask-slack のcanvas）を読む
[ ] スマホにSlackを入れて、通知スケジュールを平日 9:00〜18:00 にする
[ ] 自分の部署の #team- と、担当する #pj- に入る
[ ] #ask-slack にひとこと自己紹介を書く（スレッドで誰かが返します）

（見出し）チャンネルの案内
- 全社のお知らせ：#notice-全社（読むだけ）
- 総務・経理への質問：#ask-総務（案内のcanvasあり）
- Slackの使い方の質問：#ask-slack
- 部署：#team-direction / #team-design / #team-engineer

（見出し）困ったら
#ask-slack に書いてください。DMでも構いません。

チェックリストはcanvasのチェックリストの要素で作ります。新しく入った人は、このcanvasを自分で複製してチェックを付けていけば、何が終わったか分かります。

部署のチャンネルに自動で入ってもらうには、ワークスペースの「デフォルトのチャンネル」に #notice-全社・#ask-総務・#ask-slack を入れておきます。デフォルトのチャンネルは新しく入るメンバーにだけ適用され、ゲストは自動では追加されません。部署のチャンネルは、部署のユーザーグループにデフォルトのチャンネルを設定しておくと、グループに入れた時点で一緒に追加されます。

チャンネルに入った人に案内を送る

ワークフロービルダーには「誰かがチャンネルに参加した時」というトリガーがあり、テンプレートにも「チャンネルの新メンバーの歓迎」が用意されています。これを #ask-slack に置き、入ってきた人に入口のcanvasのリンクを送るようにしておくと、総務が案内を送り忘れても届きます。

順番	中身
トリガー	「誰かがチャンネルに参加した時」（#ask-slack）
ステップ1	参加した人にメッセージを送る：入口のcanvasのリンクと、「分からないことはここにスレッドで書いてください」の一文

ワークフロービルダーは有料プランの機能です。作り方は「Slackのワークフロービルダー：作り方と、日報・申請・問い合わせ受付の例」に書いています。

業務時間外の通知と通知の一時停止の決まり

業務時間外の扱いは、ガイドラインの中でいちばん揉めやすいところです。送る側は「時間外に送ってもいい、見るのは明日でいい」と思っていても、受ける側は通知が鳴ると見てしまいます。サンプルデザインでは、受ける側と送る側の両方に決まりを作っています。

立場	決まり	使う機能
受ける側	通知スケジュールを平日 9:00〜18:00（会社の標準）にする。時間がずれる人は自分で変える	通知スケジュール
受ける側	会議中・集中したいときは、終わる時刻を指定して通知を一時停止する	「通知を一時停止にする」
送る側	夜・休日に思いついた連絡は、翌営業日の朝に届くよう予約する	予約送信
送る側	時間外に @channel・@here を使わない	—
送る側	本当に急ぐ（サーバー障害・当日の取引先対応）は電話。Slackは電話のあとの記録に使う	—
当番	サーバー監視の当番の週だけ、#log-サーバー監視 の通知とスケジュールを外す	ユーザーグループ @oncall-server

通知スケジュールを会社の標準にする

通知スケジュールは、通知を受け取る曜日と時間帯を決める機能です。時間外は自動で通知が一時停止され、時間内に戻ると再開されます。通知スケジュールは各自が決めます。サンプルデザインは会社の標準を平日 9:00〜18:00 とし、遅番や在宅で時間がずれる人には自分で変えてもらっています。

各自が変えるときは次の手順です。

1. 「環境設定」→「通知」を開きます。
2. 「通知スケジュール」で「毎日」「平日」「カスタム」のどれかを選びます。
3. 通知を受け取る開始時刻と終了時刻を選びます。

時間外にもメッセージは届いていて、通知が鳴らないだけです。翌朝Slackを開けば未読として残っているので、「時間外の連絡は翌朝読めばいい」とガイドラインに書けます。

通知の一時停止の決まり

会議や集中作業のときは、プロフィール写真→「通知を一時停止にする」から時間を選んで通知を止めます。運用していてよく起きるのは、会議の前に止めてそのまま戻し忘れ、午後の依頼に気づかない事故です。ガイドラインには「止めるときは『カスタム』で終わる時刻を指定する」と1行入れています。

「通知を止めている人に急ぎで連絡したい」という相談も出ます。Slackで急ぎを伝える手を重ねるより、ガイドラインで「急ぐなら電話」と決めておくほうが、止めている人の集中を守れます。

予約送信を送る側の標準にする

夜や休日に連絡を思いついたら、その場で送らずに翌営業日の朝に届くよう予約します。メッセージの入力欄の送信ボタン横のメニューから日時を指定すると、予約できます。

代表や管理職が夜にメッセージを送ると、部下は「返さないといけない」と感じます。サンプルデザインでは、代表が最初に予約送信を使い始めてから、時間外の投稿が目に見えて減りました。ルールは上の立場の人が守っているのを見て、はじめて守られます。予約送信の詳しい使い方は「Slackのリマインダーと予約送信：/remindの書き方・削除・あとで見る」に書いています。

定着させる段取り

ガイドラインは、作って #notice-全社 に流しただけでは読まれません。サンプルデザインでは、次の順で1か月かけて定着させました。

1. 1週目：説明会（30分）で、ガイドラインのcanvasを全員の画面で開いてもらい、#ask-slack でスレッドの返信とリアクションを一度ずつ練習する。
2. 1〜2週目：ディレクターが、スレッドで返していない返信やDMでの依頼を見つけたら、その場で一言返す（「スレッドでお願いします」「#pj-a社-サイト改修 に書いてもらえますか」）。責める言い方はしない。
3. 2週目：代表が業務の指示をチャンネルで出し、夜の連絡は予約送信にする。
4. 3週目：#ask-slack に出た質問と答えを、総務Eがガイドラインのcanvasの「よくある質問」に足す。
5. 4週目：総務Eとディレクター Aで、守られていない項目を3つ挙げ、文面を直すか、項目ごと消すかを決める。

2のその場の一言が、いちばん効きます。ガイドラインを何度流すより、実際の書き込みに一言返すほうが伝わります。2週間ほど続けると、ほとんどの人がスレッドで返すようになり、DMで来る依頼も減ります。

定着しないパターンと直し方

ガイドラインを作っても、次のような状態になることがあります。原因はほとんどの場合、ルールの文面ではなく、ルールより楽な抜け道が残っていることです。

パターン	起きていること	原因	直し方
メールに戻る	社内の連絡がメールで届く	メールで送っても受け取ってもらえる。代表や上長がメールで送っている	メールで来た社内の連絡はSlackに書き直してもらう。上の立場の人から先にSlackに寄せる
DMだらけ	依頼がDMで回り、担当が休むと誰も経緯を追えない	チャンネルに書くと大勢に見られて恥ずかしい、どこに書くか分からない	DMで来た依頼はチャンネルで受け直す。チャンネルの説明欄を整え、書く場所に迷わないようにする
読まれない	お知らせを出しても「知らなかった」が出る	チャンネルが多すぎて、全部をミュートしている	全員が必ず見るのは #notice-全社 だけにし、そこは誰もミュートしない。確認が要るお知らせは「読んだら :white_check_mark:」と書く
@channel だらけ	毎日 @channel が飛び、通知を切る人が出る	確実に読んでほしい気持ちで付けている	使ってよい場面をガイドラインに書く。プロプランではチャンネルごとに制限できないので、使われたときに一言返す
スレッドを使わない	チャンネルに返信が並び、話が混ざる	スレッドの使い方を知らない、通知が来ないと思っている	説明会で練習する。スレッドで返さない返信には、スレッドで「スレッドでお願いします」と返す
チャンネルが増えすぎる	似た名前のチャンネルが並ぶ	作る前に確かめる手順がない	作る前の3つの確認（既存で足りないか・2週間以上続くか・終わり方が決まっているか）をガイドラインに入れ、半年ごとに棚卸しする
返事がない	依頼しても返事が来ず、催促が増える	誰に頼んだか、いつまでかが書かれていない	依頼は個人をメンションして期限を書く。すぐ返せないときの :eyes: を決める
既読が分からず不安	「読んだかどうか分からない」と言われる	読んだ合図を決めていない	確認が要る連絡だけ「読んだらリアクションを付けてください」と書く
ルールが古いまま	書いてあることと実際の使い方が違う	見直しの日が決まっていない、持ち主がいない	canvasの最後に持ち主と次の見直しの月を書き、カレンダーに入れる

表のうち、最初の3つ（メールに戻る・DMだらけ・読まれない）は、ほぼどの会社でも一度は起きます。どれも「ルールを守らない人が悪い」と考えると直りません。メールで送るほうが楽、DMのほうが気楽、全部見るのは疲れる、という理由があるので、その理由を消す方向で直します。

ルールの見直しの仕方

3か月ごとに見るもの

見直しは3か月ごと、総務EとディレクターAの30分の打ち合わせでやります。見るものは次の4つです。

見るもの	見方	判断
会話が行われている場所	オーナーが「管理者」→「ワークスペースアナリティクス」→「概要」タブで、「会話が行われている場所」を見る	DMに流れている話が増えていそうなら、どの部署かを現場に聞く
#ask-slack の質問	3か月分の質問を読み返す	同じ質問が2回以上出ていたら、ガイドラインかcanvasに答えを足す
守られていない項目	2人がそれぞれ3つずつ挙げる	文面を直すか、項目ごと消す
増えたチャンネル	チャンネルの一覧で、説明のないもの・90日動いていないもの	説明を入れてもらうか、アーカイブする

アナリティクスは、オーナーと管理者が見られます（既定ではゲスト以外のメンバーも閲覧できます）。ただ、数字が増えた減ったより、どの部署が書き込みに出てこないか、どの話がDMに流れているかを見るほうが、直す手がかりになります。

社員の声を集める

見直しの前に、#ask-slack で「Slackの使い方で困っていること」を1週間だけ募集します。ワークフロービルダーのフォームで匿名ではなく名前つきで集め、回答はチャンネルには出さずにスプレッドシートに残します。実際に運用していると、「ext- のチャンネルで取引先の人がメンションを付けずに書くので気づかない」「log- の通知が多すぎる」のように、ルールではなく設定で直せる話が半分ほど出てきます。設定で直せるものは、ルールに書かずに設定を直します。

変えたら知らせる

ガイドラインを直したら、#notice-全社 に「Slackの使い方を更新しました。変わったのは次の2点です」と、変わった点だけを書いて流します。全文を流し直すと、何が変わったか誰も分かりません。canvasの最後の行にある「次の見直し」の月も、このとき書き換えます。

応用

取引先やゲスト向けの短いルール

Slackコネクトでつながっている取引先や、ゲストで入っている外注さんには、社内のガイドラインをそのまま見せません。社内の事情（DMを使わない場面や業務時間）を押しつけることになるからです。#ext-a社 の説明欄とcanvasに、次の3行だけを書いています。

・このチャンネルはA社様とサンプルデザインの連絡用です
・返信はスレッドでいただけると助かります（スレッドの使い方は下の画像のとおり）
・平日 9:00〜18:00 に確認しています。お急ぎの場合はお電話ください

社内向けには、ガイドラインの「6. 社外の人がいる場所」で、社内の相談や金額を ext- に書かないことを決めています。取引先とのつなぎ方は「Slackコネクトとは：取引先と同じチャンネルで話す設定と注意点」に書いています。

長いスレッドはAIの要約で追いつく

2026年10月時点の料金ページでは、フリー・プロ・ビジネスプラスの「基本的な AI 機能」に、AIによる会話の要約と毎日のまとめが入っています。休み明けや途中から案件に入ったときに、長いスレッドやチャンネルを要約して追いつけます。ガイドラインに「休み明けは要約で追いついてから質問する」と書いておくと、「何があったか教えて」というDMが減ります。ただし要約は判断の材料で、決まったことの記録ではありません。決定事項は従来どおりcanvasに書きます。AI機能の範囲は「Slack AIとは：要約・検索の回答・ハドルの議事録と料金」に書いています。

設定で済むことは設定でやる

ルールの文章より、設定のほうが確実に効きます。ガイドラインを書く前に、次の設定を済ませておくと、書く項目が減ります。

ルールにしたいこと	代わりの設定
#notice-全社 は読むだけ	全員チャンネルの「投稿権限」で、投稿できる人を代表と総務に絞る
新しく入った人を決まったチャンネルに入れる	デフォルトのチャンネルと、ユーザーグループのデフォルトのチャンネル
アプリを勝手に入れない	「承認済みアプリを必須とする」をオンにする
時間外に通知しない	通知スケジュールを各自で決める

管理者が最初に見直す設定は「Slackの管理者と権限：オーナー・管理者の役割と最初に見直す設定」に書いています。

できないことと、その代わり

できないこと	代わりの手
ルールに反する書き込みを自動で止める	設定で済むものは設定でやり、残りはその場の一言で直す
プロプランで、全員チャンネル以外のチャンネルの投稿や @channel を使える人を絞る	使ってよい場面をガイドラインに書く。チャンネルごとに絞るならビジネスプラス
通知スケジュールで送る側の送信を止める（通知スケジュールは受ける側の設定）	送る側は予約送信を使う、とガイドラインに書く
ガイドラインを社外の人にそのまま守ってもらう	社外向けには3行の短い案内を別に作る
ガイドラインのcanvasで、誰が読んだかを確かめる	説明会で全員の画面で開いてもらう。大きく変えたときは #notice-全社 で「読んだら :white_check_mark:」と書く
規程として正式な文書にする（就業規則に入れる等）	正式な規程はGoogleドキュメントで管理し、Slackのガイドラインは運用の目安として分ける

Slackのガイドラインは、就業規則や情報セキュリティの規程とは分けて考えます。規程は版の管理と、Slackを使わない人（社労士など）との共有が要るので、Googleドキュメントに置きます。ガイドラインには「情報の扱いは情報セキュリティ規程に従う」と1行書いて、規程へのリンクを貼るだけにしています。

よく詰まるところ

症状	原因	直し方
ガイドラインを流したのに誰も守らない	#notice-全社 に1回流しただけで、置き場所がない	canvasに置いて #ask-slack のタブにし、説明会で一度開いてもらう
ガイドラインが長すぎて読まれない	気づいたことを全部書き足した	見出し7つ・各3行までに削り、細かい話は個別のcanvasに分ける
誰かがガイドラインの文面を書き換えていた	canvasの編集権限を全員に付けている	編集は持ち主の2人だけにし、ほかの人は閲覧だけにする
新しく入った人がガイドラインに気づかない	タブに置いただけで、最初に開かない	タブを「デフォルトで canvas を表示する」にし、参加した人に案内を送るワークフローを置く
ゲストがデフォルトのチャンネルに入っていない	デフォルトのチャンネルはゲストには自動で適用されない	ゲストは招待のときに入るチャンネルを指定する
時間外にも通知が鳴ると言われる	通知スケジュールを各自が変えた、またはスマホ本体の設定	「環境設定」→「通知」の「通知スケジュール」を一緒に確かめる
午後ずっと通知が来なかった	通知の一時停止の戻し忘れ	止めるときは「カスタム」で終わる時刻を指定する、とガイドラインに入れる
@channel が減らない	プロプランではチャンネルごとに使える人を絞れない	使われたときにスレッドで一言返す。続くならビジネスプラスの投稿権限を検討する
代表がDMで指示を出し続ける	上の立場の人がルールの外にいる	代表に最初にチャンネルと予約送信を使ってもらう。代表宛てのDMの依頼は秘書役がチャンネルに転記する
見直しが一度も行われない	持ち主と日付が決まっていない	canvasの最後に持ち主と次の見直しの月を書き、カレンダーに予定を入れる

次にやること

• Slackのチャンネル：作り方・命名ルール・パブリックとプライベートの使い分け
• Slackのスレッドとメンション：@hereと@channelの違い、メンショングループの作り方
• Slackの通知設定：通知が来ないときの直し方と、うるさくない設定
• Slackの活用事例：小さな会社でよく作るチャンネルとワークフロー15例