Slack（スラック）の便利な使い方を探すと、機能の紹介はたくさん出てきますが、「小さな会社で実際に何を作り、どれが続いたか」はあまり書かれていません。ここでは、社員20名ほどのWeb制作会社「サンプルデザイン」（プロプラン）がSlackで実際に回しているチャンネルとワークフローを15例に絞り、何をどの機能で作り、何に効いたかを一覧にします。そのうえで、1日の流れ、代表的な5例の作り方の要点、組み合わせ方、やってみたが続かなかった例、kintoneやn8nに任せるところまで書きます。それぞれの機能の細かい手順は個別の記事にあるので、ここは「何を作るかを選ぶ」ための記事です。
この記事の内容
先に決めること
15例を全部いきなり作ると、使われないワークフローと誰も見ない通知が残ります。作り始める前に次の4つを決めます。
| 決めること | サンプルデザインの答え | 理由 |
|---|---|---|
| どこから始めるか | 困りごとが一番大きいもの1つから。月に1つずつ足す | 一度に変えると、何が効いて何が効かなかったか分からない |
| 誰が持ち主か | 作った人と総務Eの2人。ワークフローは2人ともワークフローマネージャーにする | 作った人が休んだり辞めたりしても直せる |
| 記録をどこに残すか | Slackの投稿で済むものは投稿のまま。あとで集計するものはスプレッドシートかリスト | Slackのメッセージは流れていくので、集計や台帳には向かない |
| どのプランで使うか | プロプラン | ワークフロービルダー・リスト・ゲストは有料プランの機能 |
いちばん大事なのは、困りごとから選ぶことです。「Slackでこんなこともできる」から作ると、作った人しか使いません。「日報が人によってばらばらで読めない」「問い合わせの返信が誰の担当か分からない」のように、いま困っていることを先に書き出し、それを片づける例を選びます。
フリープランではワークフロービルダーとリストが使えず、連携できるアプリも10個までです。15例のうち、フリープランで作れるのはチャンネルの使い方（例1〜5）と、Incoming Webhook・アプリ・リマインダーを使う一部だけです。プランの違いは「Slackの料金プラン：無料プランの制限とプロ・ビジネスプラスの選び方」に書いています。
小さな会社でよく作る15例
| # | 何を | どの機能で | 効くこと |
|---|---|---|---|
| 1 | 全社のお知らせ #notice-全社 | 全員チャンネル＋投稿権限で代表と総務に絞る | 大事なお知らせが雑談に埋もれない。誰もミュートしない場所が1つできる |
| 2 | 質問の窓口 #ask-総務・#ask-slack | チャンネル＋案内のcanvas＋リアクション（:eyes:・:white_check_mark:） | 個人へのDMの質問が減り、同じ質問への答えが残る |
| 3 | 案件ごとのチャンネル #pj-a社-サイト改修 | チャンネル＋「案件の概要」canvas＋タブ（資料のフォルダ） | 途中から入った人が経緯を読める。決定事項が流れない |
| 4 | 取引先との連絡 #ext-a社 | Slackコネクト | 社内と取引先が同じ場所で話せ、メールのCCが要らない |
| 5 | 個人の作業メモ #times-デザイナーB | チャンネル（任意） | 進み具合や詰まりが周りに見え、声をかけやすくなる |
| 6 | 日報 | ワークフロー（リンクから→フォーム→チャンネルに投稿）＋夕方の声かけ | 書く項目がそろい、読む側が5人分を一度に追える |
| 7 | 休暇・遅刻の連絡 | ワークフロー（フォーム→#log-休暇→スプレッドシートに1行） | 総務の転記漏れがなくなる |
| 8 | 問い合わせの受付と担当決め | メールの転送で #log-問い合わせ＋ワークフローのボタン＋リスト | 誰が返すかがその場で決まり、対応状況を一覧で追える |
| 9 | 制作の依頼 | リスト＋リストのフォーム＋期限日の要約 | DMで来ていた細かい依頼が一覧になり、抜けが減る |
| 10 | 経費・備品の申請と承認 | ワークフロー（フォーム→承認者へボタン→記録） | 口頭とメールでばらばらだった申請が1か所に集まる |
| 11 | サーバー監視の異常 | Incoming Webhook→#log-サーバー監視＋当番のユーザーグループ | 異常に気づくのが早くなり、当番だけに届く |
| 12 | GitHubのレビュー依頼 | GitHubのSlackアプリ | レビュー待ちの見落としが減る |
| 13 | 予定とステータス | Google カレンダーのアプリ | 会議中・不在がステータスで分かり、「今いいですか」が減る |
| 14 | 定例の声かけ | チャンネルリマインダー（/remind） | 毎週同じことを誰かが思い出して書かなくて済む |
| 15 | 新しく入った人の案内 | ワークフロー（「誰かがチャンネルに参加した時」）＋入口のcanvas | 案内の送り忘れがなくなる |
1〜5はチャンネルの切り方で、機能というより使い方の決めごとです。ここが固まっていないと、6以降の自動化をどのチャンネルに流すかが決まりません。サンプルデザインの順番も、最初の1か月で1〜5を固め、2か月目に6と15、3か月目に8と11、という順でした。
#notice-全社・#ask-総務・#pj-a社-サイト改修・#ext-a社・#log-問い合わせ が並び、セクションで分かれている状態サンプルデザインの1日の流れ
15例がそろうと、1日の連絡はおおよそ次のように流れます。
| 時刻 | 起きること | 例 |
|---|---|---|
| 8:30 | 代表が前日の夜に予約しておいたお知らせが #notice-全社 に出る | 1 |
| 9:00 | 通知スケジュールの時間に入り、各自の通知が鳴り始める | — |
| 9:00 | 制作の依頼リストの「期限日の要約」が #team-design に出る。今後7日間の期限が並ぶ | 9 |
| 9:15 | 朝会。ディレクターがリストのボードを画面共有しながら、今日の作業を確かめる | 9 |
| 10:00 | ホームページの問い合わせが #log-問い合わせ に流れ、スレッドに「担当する」ボタンが付く。営業Dが押す | 8 |
| 11:00 | #pj-a社-サイト改修 でデザイン案の確認。決まったことを担当が「案件の概要」canvasに転記する | 3 |
| 13:00 | #ext-a社 でA社の担当者からテキストの修正依頼。ディレクターAがスレッドで受ける | 4 |
| 14:00 | エンジニアCのプルリクエストに対するレビュー依頼がGitHubのアプリから届く | 12 |
| 15:30 | サーバー監視から応答なしの通知が #log-サーバー監視 に届き、@oncall-server で当番に知らせる | 11 |
| 16:00 | 総務Eに経費の申請が届き、ボタンで承認。記録はスプレッドシートに残る | 10 |
| 17:30 | 日報の声かけが #team-design に出て、ボタンから日報を書く | 6 |
| 18:00 | 通知スケジュールの時間が終わり、通知が止まる。翌朝の連絡は予約送信で入れておく | — |
人が自分で書き込んでいるのは、案件の相談と取引先とのやり取りくらいです。それ以外の「思い出して書く」「誰かに転記する」「通知を見に行く」は、ワークフローやリマインダー、Webhookが代わりにやっています。1日の中で、人が決めなければいけないこと（誰が問い合わせを返すか、経費を通すか）だけがボタンとして目の前に出てくる形にすると、Slackを開いたときにやることがはっきりします。
#log-問い合わせ の投稿のスレッドに、ワークフローの「担当する」ボタンと、押した営業Dの名前が並んでいるところ代表的な5例の作り方の要点
例6：日報
| 順番 | 中身 |
|---|---|
| トリガー | 「リンクから」（#team-design の会話の上部に置く） |
| ステップ1 | フォーム：今日やったこと・明日やること・困っていること（任意）・稼働した案件（選択肢） |
| ステップ2 | #team-design にメッセージ：実行した人とフォームの回答 |
要点は3つです。1つ目は、質問を4つまでにすること。項目が多い日報は、1週間で空欄が増えます。2つ目は、「稼働した案件」を選択肢にして、案件のチャンネル名と同じ書き方（「a社-サイト改修」）にそろえること。あとで検索や集計がしやすくなります。3つ目は、書き忘れの声かけを別のワークフロー（「スケジュールにもとづく」で平日17時30分）にし、その投稿のボタンの「動作」で日報のワークフローを始めることです。声かけからそのまま書けるので、書く率が上がります。
{このワークフローを使用した人} の日報
今日：{今日やったこと}
明日：{明日やること}
困っていること：{困っていること}
案件：{稼働した案件}波かっこの部分は、メッセージのステップで「変数を挿入する」から入れる変数です。日報は部署ごとのチャンネルに出し、全社で1つのチャンネルにはしません。20人分が1つのチャンネルに並ぶと、誰も読まなくなります。詳しい作り方は「Slackのワークフロービルダー：作り方と、日報・申請・問い合わせ受付の例」に書いています。
#team-design に、日報のワークフローから投稿された3人分の日報が並んでいるところ例8：問い合わせの受付と担当決め
ホームページ sample-design.example の問い合わせフォームはメールで届くので、まずGmailのフィルタで問い合わせだけをチャンネル用メールアドレスに転送し、#log-問い合わせ に流します。チャンネル用メールアドレスを #log-問い合わせ 用に取得し、転送先に入れます。受信メールの有効・無効を変える設定は、ビジネスプラス・Enterpriseだけの機能です。既定のままでメールを受けられる前提で作り、設定を変える必要が出たらビジネスプラス以上を検討します。
流れてきた投稿に、ワークフローで担当決めを足します。
| 順番 | 中身 |
|---|---|
| トリガー | 「メッセージが投稿された時」（#log-問い合わせ） |
| ステップ1 | その投稿のスレッドに、対応の手順と「担当する」ボタン |
| ステップ2 | 担当する人が、自分で「担当します」とスレッドに書く |
| ステップ3 | 問い合わせの対応リストに行を足す |
要点は、ボタンの設定（「シングルクリック」・押せる人）を決めておくこと、押せる人を「詳細設定」で営業とディレクターに限ること、担当は押した人が自分でスレッドに書く決まりにして先に書いた人にすること、そして #log-問い合わせ には人が直接書き込まない決まりにすることです。トリガーが「メッセージが投稿された時」なので、人の書き込みにも反応してしまいます。相談はスレッドで行います。メールの流し方は「SlackとGmail・メールの連携：メールをSlackに転送する・メール通知を減らす」に書いています。
例9：制作の依頼リスト
ディレクターからデザイナーへの細かな依頼（バナーの作成、画像の差し替え、修正）を、リストで追います。リストは有料プランの機能です。
| フィールド | 中身 |
|---|---|
| 名前 | 依頼の内容（例「A社 トップのメイン画像差し替え」） |
| 依頼者・担当者 | 依頼したディレクターと、作業するデザイナー |
| 案件 | 関係する #pj- のチャンネル |
| 期限日 | 取引先に出す日の前営業日 |
| 状態 | 未着手・作業中・確認待ち・完了 |
要点は、入口と通知を両方リストの自動化で作ることです。依頼する側にはリストの「フォーム」から出してもらい、毎朝「期限日の要約」を #team-design に流します。要約の期間は既定で「今後 7 日間」です。定着させるときは、最初から全員にフォームを使わせず、受ける側のデザイナーがDMで来た依頼を「リストに追加する」でその場で行にするところから始めます。受ける側が慣れてから入口をフォームにそろえるほうが、「面倒だからDMで頼む」が残りません。
プロプランのリストは、アイテムとサブタスクの合計が1,000件を超えると古いものから自動でアーカイブされます。依頼の行は完了したら月に1回アーカイブし、長く残す記録は案件の管理表に移します。詳しくは「Slackのリストでタスク管理：依頼・案件・問い合わせをSlackの中で追う」に書いています。
例11：サーバー監視の異常
サーバー監視のサービスは、異常をWebhookで送れます。Slackアプリを1つ作ってIncoming Webhookを有効にし、#log-サーバー監視 に結びつけたURLを監視サービスに登録します。送る中身はJSONで、最低限 text があれば届きます。
curl -X POST -H 'Content-type: application/json' \
--data '{"text":"<!subteam^xxxxxxxx> sample-design.example が応答しません（15:30）"}' \
https://hooks.slack.com/services/xxxxxxxx/xxxxxxxx/xxxxxxxx<!subteam^xxxxxxxx> は当番のユーザーグループ @oncall-server へのメンションです。ユーザーグループのIDを入れると、その週の当番だけに通知が届きます。全員の通知の設定を触らずに、当番の交代はグループのメンバーを入れ替えるだけで済みます。
要点は、Webhookの URL は1つのチャンネルに結びつき、URLを知っている人なら誰でも投稿できてしまうことです。URLは監視サービスとパスワード管理のツール以外に書かず、漏れたら作り直します。Incoming Webhookの送信は1秒に1件が目安で、超えると429が返ります。障害のときに大量に送る設定になっていないかも確かめます。作り方は「SlackのIncoming Webhook：外のシステムからチャンネルに通知を送る」に書いています。
例14：定例の声かけ
毎週月曜の朝に「今週の公開予定を案件の概要canvasに書いてください」と #team-direction に流す、のような決まった声かけは、チャンネルリマインダーで作ります。
/remind #team-direction "今週の公開予定を案件の概要canvasに書いてください" every Monday at 9am書き方は /remind [#チャンネル] [内容] [いつ] で、内容は引用符で囲みます。内容は日本語で書けますが、「いつ」は every Monday at 9am のように英語で書きます。繰り返しは日単位までで、1時間ごとのような指定はできません。チャンネルリマインダーは作ったあとに編集できないので、内容を変えるときはそのチャンネルで /remind list を開いて削除し、作り直します。ゲストはチャンネルリマインダーを作れません。
ボタンやフォームが要らない声かけはチャンネルリマインダー、声かけからフォームを開かせたいときはワークフロー（例6の夕方の声かけ）、と使い分けています。リマインダーの書き方は「Slackのリマインダーと予約送信：/remindの書き方・削除・あとで見る」に書いています。
#team-direction に月曜9時のチャンネルリマインダーが投稿されているところ組み合わせ方
15例は、ワークフロー・リスト・canvas・Webhookのどれか1つで作るより、2つ以上を組み合わせたほうが効きます。サンプルデザインでよく使う組み合わせは次のとおりです。
| 組み合わせ | 流れ | 使っている例 |
|---|---|---|
| メールの転送＋ワークフロー＋リスト | メールがチャンネルに流れる→ワークフローが担当を決めるボタンを出す→リストに行を足す | 8 |
| リストのフォーム＋期限日の要約 | フォームで行が増える→毎朝期限が近いものをチャンネルに流す | 9 |
| ワークフロー＋スプレッドシート | フォームの回答をチャンネルに出し、Googleスプレッドシートのコネクタで行を足す | 7・10 |
| Webhook＋ユーザーグループ | 外のシステムの通知に当番のグループをメンションする | 11 |
| チャンネル＋canvas＋ワークフロー | チャンネルの案内をcanvasに書き、参加した人にワークフローでリンクを送る | 2・15 |
| スケジュールのワークフロー＋ボタン | 決まった時刻に声かけを出し、ボタンから別のワークフローを始める | 6 |
| リストの更新＋ワークフロー | 「リスト項目が更新された時」で、状態が「確認待ち」になったら依頼者に知らせる | 9 |
組み合わせるときの決まりは1つだけで、「記録は1か所」です。問い合わせなら対応状況の記録はリスト、休暇ならスプレッドシート、案件の決定事項ならcanvas、と決めておきます。同じ情報をリストとスプレッドシートの両方に書くと、どちらが正しいか分からなくなります。
canvasとリストの使い分けは、文章で残すものはcanvas、件数があって状態が変わるものはリスト、と考えると迷いません。案件の決定事項は文章なのでcanvas、依頼は1件ずつ状態が変わるのでリストです。
#pj-a社-サイト改修 の会話の上部に、「案件の概要」canvas・資料のフォルダ・制作の依頼リストのタブが並んでいる状態やってみたが続かなかった例
作ってみたものの、1〜3か月で使われなくなった例もあります。続かなかった理由を並べると、作る前の判断の材料になります。
| やってみたこと | 続かなかった理由 | 今のやり方 |
|---|---|---|
| 毎朝、全員が「出勤しました」と書く | 20件の投稿が毎朝並び、ほかの連絡が流れた。書いても誰も読まない | 書かない。勤怠は勤怠の仕組みで、会議中・不在はカレンダーのステータスで分かる |
| 全社で1つの日報チャンネル | 20人分が並んで読めず、上長も自分の部下の分を探すのに疲れた | 部署ごとのチャンネルに出す |
| 雑談チャンネルへの書き込みを毎日1回お願いした | 義務になった時点で雑談ではなくなり、形だけの投稿が並んだ | #times- を任意にし、書きたい人だけが書く |
| 案件の一覧をSlackのリストに全部入れた | 過去の案件も含めて件数が増え、集計や請求との突き合わせができなかった | 案件の一覧は管理表に置き、リストは今動いている依頼だけにする |
問い合わせ・監視・GitHub・カレンダーの通知を全部1つの #log- に流した | 1日に何十件も流れ、全員がミュートした | 通知の種類ごとに log- を分け、担当だけが見る |
| 部署ごとに休暇の連絡のワークフローを作った | 同じワークフローが5本でき、直すときに全部直す羽目になった | 全社で1本にし、送り先を #log-休暇 1つにまとめた |
| 「ありがとう」を絵文字で数えて表彰した | 数えるための絵文字が増え、集計の手間がかかった | 表彰はやめ、リアクションは返事を減らすためだけに使う |
| 作った本人だけがマネージャーのワークフロー | 本人が休んだ日に壊れて、誰も直せなかった | ワークフローマネージャーを必ず2人以上にする |
共通する理由は、「誰の手間が減るのか」がはっきりしていなかったことです。続いている例は、どれも誰かの転記・催促・確認を減らしています。新しく作るときは「これで誰の何の手間が減るか」を一文で書けるかどうかを確かめ、書けないものは作りません。
外の仕組み（kintone・n8n）に渡すところ
Slackのワークフローとリストで足りるのは、Slackの中で完結する手順と、件数が少ない一覧までです。次のような要件が出てきたら、kintoneやn8nに渡します。
| 要件 | Slackだけでやると | 渡す先 | サンプルデザインの例 |
|---|---|---|---|
| 案件・顧客の台帳を長く残して集計する | リストは1,000件で古いものから自動でアーカイブされ、集計もできない | kintone | 案件の管理表をkintoneに移す検討中 |
| 台帳の変化をSlackに知らせる | Slackからは台帳の変化を拾えない | kintoneのWebhook→n8n→Slack | 案件のステータスが「公開待ち」になったら #team-direction に知らせる |
| 問い合わせを台帳に登録してから知らせる | ワークフローはデータベースに読み書きできない | n8n→kintone→Slack | 問い合わせをkintoneに登録し、そのリンクを #log-問い合わせ に流す |
| 金額のある承認を記録とともに回す | 分岐はビジネスプラス以上、差し戻しの履歴を残しにくい | n8nのSlackノードの承認、kintoneのプロセス管理 | 見積もりの承認を代表へのDMのボタンで押す |
| 前日の件数を毎朝まとめて送る | Slackの中に数える元のデータがない | n8nの定時実行 | 前日の問い合わせ・案件の件数を #log-システム に送る |
考え方は、台帳と判断の記録は業務システムに置き、Slackには「変わった」「判断してほしい」という知らせだけを流す、というものです。Slackのメッセージは流れていくので、あとから「先月の承認はいくつあったか」を数えるのに向きません。逆に、kintoneだけで回すと通知に誰も気づかないので、知らせの部分だけSlackに渡します。
kintoneのWebhookは1つのアプリに10個まで、ドメイン全体で1分に60回までで、CSVの読み込みや一括削除では送られません。n8nでSlackのボタンの承認を受けるには、n8nが外から届くHTTPSのURLで動いている必要があります。つなぎ方は「Slackとkintone・Salesforce・n8nの連携：業務システムの通知と承認をつなぐ」に書いています。
#team-direction に、kintoneの案件のステータスが「公開待ち」になったことをn8nから知らせる投稿が届いているところできないことと、その代わり
| できないこと | 代わりの手 |
|---|---|
| フリープランでワークフロービルダー・リストを使う | 有料プランにする。フリーのうちはチャンネルの使い方（例1〜5）とIncoming Webhook、リマインダーで始める |
| プロプランでワークフローに分岐を入れる | 分岐はビジネスプラスとEnterpriseだけ。プロではボタンを分けるか、n8nに渡す |
| ワークフローからデータベースを読み書きする | コネクタでスプレッドシートに行を足すまでにし、台帳はkintoneに置く |
| リストに1,000件を超えて残す（プロ・ビジネスプラス） | 完了した行をアーカイブし、長く残す記録は管理表やkintoneへ |
| チャンネルリマインダーを編集する | /remind list で削除して作り直す |
| 1時間ごとのリマインダー | 日単位まで。細かい間隔が要る監視はWebhookで送る側に任せる |
| Incoming Webhookで送ったメッセージを後から消す・スレッドに返す | Slackアプリのbotで chat.postMessage を使う |
| ゲストにすべてのワークフローを使ってもらう | ゲストは使う権限を与えられたワークフローだけ実行できる。外注さんが使うものは公開の設定で許可する |
よく詰まるところ
| 症状 | 原因 | 直し方 |
|---|---|---|
| 作ったワークフローが使われない | 置き場所が分からない、困りごとと結びついていない | 使うチャンネルの会話の上部に置き、誰の手間が減るかを一文で案内する |
| 日報が数日で書かれなくなる | 項目が多い、声かけがない | 質問を4つまでにし、夕方の声かけのワークフローにボタンを付ける |
| 問い合わせのワークフローが人の書き込みにも反応する | トリガーが「メッセージが投稿された時」 | #log-問い合わせ には人が直接書かない決まりにし、相談はスレッドで |
| 2人が同時に担当しようとした | 担当を決める決まりが無い | 担当は押した人がスレッドに書き、先に書いた人にする |
| 依頼リストの古い行が消えた | プロ・ビジネスプラスはアイテムとサブタスクの合計1,000件を超えると古い順に自動でアーカイブ | 完了した行を月に1回アーカイブし、件数を見ておく |
| 監視の通知が全員に鳴る | チャンネルの通知を「すべての新しい投稿」にしている人がいる、メンションが @channel | 当番のユーザーグループをメンションし、ほかの人は log- をミュートしてよいと決める |
| Webhookから送れなくなった | URLを作り直した、送り先のチャンネルをアーカイブした | 監視サービスのURLを新しいものに替える。チャンネルを復元するか新しいURLを作る |
| チャンネルリマインダーの内容を変えられない | チャンネルリマインダーは編集できない | /remind list で削除して作り直す |
| 作った人が辞めてワークフローが直せない | ワークフローマネージャーが1人だけ | オーナーか管理者が管理画面から「マネージャーとして参加する」で引き取り、2人以上にする |
| 同じ情報がリストとスプレッドシートで食い違う | 記録の場所を2つにした | 記録は1か所に決め、もう片方はリンクだけにする |
次にやること
- Slackのワークフロービルダー：作り方と、日報・申請・問い合わせ受付の例
- Slackのリストでタスク管理：依頼・案件・問い合わせをSlackの中で追う
- SlackのIncoming Webhook：外のシステムからチャンネルに通知を送る
- Slackとkintone・Salesforce・n8nの連携：業務システムの通知と承認をつなぐ