こんにちは。普段はオペレーションや社内コミュニケーション基盤の整備（Ops）を担当しています。
エンジニアのみなさん、Slackでの依頼や相談で 「キュー詰まり（未読が溜まる）」 や 「意図しない挙動（誤解）」 に悩まされていませんか？
- 返事がぜんぜん返ってこない（タイムアウト）
- 読まれているのかすらわからない
- こちらの意図と違う方向に話が転がってしまう（仕様の誤解）
- 情報不足で何往復もラリーが続く（再送が増える）
私は日常的に数十件の依頼・相談をSlackで捌く中で、
「コミュニケーションの質は、"文章力" ではなく "インターフェース設計" で劇的に変わる」
と思うようになりました。
この記事では、私が社内向けにまとめてきたノウハウの中から、
相手の脳内メモリを消費せず、「読まれやすい」「返ってきやすい」Slackメッセージを実装するためのTipsを紹介します。
なぜSlackが返ってこないのか（受信側のリソース状況）
メッセージを送る前、相手の状況を想像できているでしょうか？
- 実装に集中しており、コンテキストスイッチのコストを払いたくない
- そもそもMTG続きで、Slackを確認できるのが「隙間時間の数分」しかない
その結果、相手がSlackを見る頃にはワーキングメモリが残りわずか、かつ通知キューには未読が何十件もたまっている……という状況が容易に想像できます。
この「高負荷状態」の中で、いかに自分のメッセージの優先度を上げ、処理してもらうか。これは一種のパフォーマンスチューニングの勝負です。
対策① 1行目は「ヘッダー情報」。メタデータを先に渡す
Slack通知のポップアップや一覧で見えるのは、ほぼ “1行目” だけです。
ここで「用件」「締め切り」「種類（依頼／相談／報告）」というメタデータが渡されていないと、開封すら後回しにされます。
例えば、「お疲れ様です！先程〇〇さんからこんな相談を受けまして、、、」と背景から始まっていると、忙しい人ほど処理をスキップします。
（最後に「※なる早でお願いします」と書いてあり、数時間寝かせてしまって肝を冷やす……というのは"あるある"ですが、これは期限を1行目に書いていない送信側の設計ミスです）
✔︎ 良い実装例
1行目で「相手に求めるアクション」と「期限」を宣言します。
軽いタスクであれば、所要時間を明記するのも効果的です。
- 【金曜19時まで：資料レビューをお願いします】
- 【※本日早め※ お客様とのトラブル相談：◯◯の件】
- 【※所要3分※ Salesforce設定変更のお願い】
Why?
- 通知一覧を見た瞬間に優先順位判断ができる
- 「読むべき投稿か」「あとでいい投稿か」が一発でわかる
- 読む側の認知負荷を下げられる
対策② 依頼・相談は自分の意見＋前提条件（背景）を渡す
通知を開いても、情報が足りないと「結局どうしたいの？」「これってどういうこと？」という質問が発生します。
これでボールが戻ってくると、次の返信が来るのはまた数時間後……という非同期コミュニケーション特有のラグが発生し、とても効率が悪いです。
自分の意見・前提情報をセットで渡すことで、相手は一度で処理を完了できます。
✔︎ 良い実装例
◯◯についてA案で進める方向で考えていますが、
一旦クイックさ優先でB案という説もあります。
どちらが良いか相談させてください。
■背景・判断材料
- A案：安全だが、実装に時間がかかる
- B案：工数は最小だが、リスクがある
✖ 悪い実装例
「〇〇の実装についてはどう進めましょうか？」
→ 実装方針の洗い出しから判断までを、すべて相手に丸投げしています。
特にありがちなパターン：
- 資料レビュー依頼で「確認お願いします」だけ（観点が不明）
- エラー調査依頼で「バグってます！」だけ（再現手順やログがない）
- スケジュール相談で「この日空いてますか？」だけ（用途が不明）
対策③ 情報量は最小限にリファクタリングする
「〜〜〜ということですので、ご確認の上ご判断お願いします！」と長文を送った結果、「で、〇〇についてはどうなってます？」と質問が返ってくる。
「それは中段に書いたのですが……」と思うこともありますが、これは可読性の低いコードを書いた自分が悪いです。
人間が一度に処理できる情報は限られています。
- 箇条書きは最大3つまで
- ノイズを除去する
- 判断に不要なログ（詳細な経緯）は別ドキュメント（Notionなど）に逃がす
- 「今回の処理（判断）に必要な引数は何か？」 を問い直す
相手のバッファを溢れさせない配慮が必要です。
対策④ 戻り値の型（Return Type）を単純型にする
理想は、相手が「OK」または「①でいきましょう」と、Booleanや数値だけで返せる状態です。
返事が来ないSlackは、相手に「文章作成」という重たい処理を求めているケースが大半です。
「どう思いますか？」というOpen Questionではなく、「AとBがありますが、Aで進めてよいですか？」とClosed Questionにする。
もし指定したはずの型を無視した回答が返ってくるなら、対策②（前提条件） が不十分だった可能性があります。
一緒に考えてほしい（複雑な処理が必要な）場合は、Slackで粘らずに同期処理（ハドルなどを使ったMTG）に切り替える方が早いです。
対策⑤ 単一責任の原則（SRP）を守る
これもやりがちなミスです。
@Aさん、〜〜について、〇〇のご対応お願いできますか？
@Bさん、xxxについては△△という理解でよかったでしょうか？
1つの投稿に複数のトピックや複数の宛先を混ぜると、責任の所在が曖昧になり、未処理の原因になります。「誰のボールか分からないタスク」を生まないためにも重要です。
✔︎ 原則
1投稿 = 1トピック
別の話題は別スレッドか別投稿に切り出すのが吉です。
返事が来ないときの「再試行ロジック」
Slackでは「既読」が見えないため不安になりますが、返事が来ない理由はだいたい以下のどれかです。
- 結論が1行目になく、優先度が低いと判定された
- 判断材料が足りず、処理が止まっている
- 任された処理が重く、実行できない
✔︎ 対応の型
- リトライ: 1日反応が無ければ、メンションで軽くリマインドする
- ACK: 重要な依頼はスタンプでの確認応答ルールを決めておく（例：👀＝確認中）
- 同期通信への切り替え: 3つ以上質問があるならMTGを入れる
重要なタスクは期限前に再試行できる設計にしておくと安心です。
まとめ：テキストコミュニケーションは「設計力」
Slackは「速さ」と「正確さ」が両立しないと、かえって開発スピードを落とします。
しかし、ちょっとした “API設計（文章の構成）” を意識するだけで、チーム全体の生産性は向上します。
✔︎ 送信前のコードレビュー（チェックリスト）
-
1行目はヘッダーとして機能しているか？（アクション・期限）
- 通知一覧で1行目だけ読んでも、相手が返事／アクションが可能か
-
前提条件（背景）は渡せているか？
- 追加質問なしで判断できる最小限の情報か
-
戻り値はシンプルか？
- OK / NG、A / Bなど、ひとことで返せる設計になっているか
-
単一責任になっているか？
- 1投稿 = 1トピック／1アクションになっているか
-
再試行の前提はあるか？
- ACK（👀/👍）がなかった場合にリマインドを想定できているか
毎回すべてを満たす必要はないですが、「自分の通知一覧にこれがあったら動けるか？」は常に意識できるといいなと思っています。
Slackは自分の文章力を披露する場ではなく、“相手のCPU時間をどれだけ奪わないか” という気遣い（パフォーマンスへの配慮）にかかっています。
それでも伝わらないことはある
立場上、新ツールや運用変更の周知をすることも多いのですが、
20人にメンションしてもスタンプが4〜5人しか返ってこない、ということも正直あります。
伝え方はまだまだ改善の余地があると感じています。
最後に
今回は「送信側（Client）」の設計に絞りましたが、
「受信側（Server）」にも、通知整理や非同期処理の技術が必要だと思っています。
このあたりはまた別の記事で書いてみたいと思います。
少しでもみなさんのSlackライフが快適になれば幸いです！