こんにちは。普段はオペレーションや社内コミュニケーション基盤の整備（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ライフが快適になれば幸いです！