Merge pull request #1472 from future-architect/feature

Slack guidelines

Author: ma91n

source/_posts/20250402a_Slack利用ガイドラインを公開しました.md

@@ -0,0 +1,88 @@
+---
+title: "Slack利用ガイドラインを公開しました"
+date: 2025/04/02 00:00:00
+postid: a
+tag:
+  - Slack
+  - ガイドライン
+category:
+  - Culture
+thumbnail: /images/20250402a/thumbnail.png
+author: 村田靖拓
+lede: "Slack利用ガイドラインについてご紹介します。"
+---
+
+<a href="https://future-architect.github.io/arch-guidelines/documents/forSlack/slack_usage_guidelines.html"><img src="/images/20250402a/top.png" alt="" width="800" height="455"></a>
+
+# はじめに
+
+こんにちは、村田です。
+
+フューチャーでは以前より[Future Enterprise Coding Standards](/coding-standards/)のラインナップとして[Javaコーディング規約](/coding-standards/documents/forJava/)や[SQLコーディング規約](/coding-standards/documents/forSQL/)などを公開しています。
+
+また、設計ナレッジを集約させたガイドライン群として[Future Enterprise Arch Guidelines](/arch-guidelines/)も公開しており、今回はその1つとして公開した[Slack利用ガイドライン](/documents/forSlack/slack_usage_guidelines.html)についてご紹介します。
+
+# TL;DR
+
+[Slack利用ガイドライン](https://future-architect.github.io/arch-guidelines/documents/forSlack/slack_usage_guidelines.html)を公開しました。皆さんの快適なSlackライフに繋がれば幸いです。
+
+# なぜガイド作ろうと思ったのか
+
+フューチャーでは数多くのプロジェクトにてSlackを活用してコミュニケーションを行っています。ただ、それぞれのプロジェクト・チームにてSlackの使い方はマチマチで、各所で固有文化が生まれている状況でした。もちろんSlackはいろんな使い方ができるツールですし各々で最適化された使い方が浸透すること自体は良いことですが、「利便性・セキュリティなどを考慮した際に推奨される使い方」が存在することも事実です。
+
+Slackの利用ガイドラインはすでに世間でも様々公開されていますが、フューチャーでの使い方はどうなのか、改めて考えてみる良い機会になることを期待して本ガイドラインの作成に踏み切りました。
+
+# TLA(Team-level agreements)を作ろう
+
+皆さんはTeam-level agreementsをご存知でしょうか？
+Slackが立ち上げたFuture Forumという活動の中で、TLAの何たるかが定義・提唱されています。
+
+> Team-level agreements (sometimes called “Team norms,” “Team working agreements,” or “Team operating manuals”) are a set of guidelines that establish expectations for how all members of the team work with one another.
+チームレベルの合意事項（「チーム規範」、「チーム作業合意」、「チーム運営マニュアル」などと呼ばれることもある）とは、チームの全メンバーが互いにどのように協力し合うかについての期待値を定める一連のガイドラインのことです。
+>The goal is to inspire trust, create clarity, and unlock performance of teams by being more explicit up front about how the team operates.
+その目的は、チームの運営方法を事前に明確にすることで、信頼を醸成し、透明性を高め、チームのパフォーマンスを引き出すことです。
+
+[What are team-level agreements?](https://futureforum.com/2022/06/23/team-level-agreements/)より引用(和訳 by Gemini)
+
+コロナ禍を経て働き方が大きく変わっていく中で、働き方を見直しそしてアップデートしていく動きが以前よりも活発になったことは周知の事実と思いますが、ここで提唱されているTLAでは、チームごとに「全員が働きやすくなるためにはどうすればいいか」を考え、それを明文化してチームの行動指針とすることを推奨しています。
+
+私は『[Slackが見つけた 未来の働き方 いつ、どこで働いても全員が成果を出せる組織づくりのすべて](https://www.amazon.co.jp/Slack%E3%81%8C%E8%A6%8B%E3%81%A4%E3%81%91%E3%81%9F-%E6%9C%AA%E6%9D%A5%E3%81%AE%E5%83%8D%E3%81%8D%E6%96%B9-%E3%81%84%E3%81%A4%E3%80%81%E3%81%A9%E3%81%93%E3%81%A7%E5%83%8D%E3%81%84%E3%81%A6%E3%82%82%E5%85%A8%E5%93%A1%E3%81%8C%E6%88%90%E6%9E%9C%E3%82%92%E5%87%BA%E3%81%9B%E3%82%8B%E7%B5%84%E7%B9%94%E3%81%A5%E3%81%8F%E3%82%8A%E3%81%AE%E3%81%99%E3%81%B9%E3%81%A6-%E3%83%96%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%BB%E3%82%A8%E3%83%AA%E3%82%AA%E3%83%83%E3%83%88/dp/4798177431)』という書籍を拝読しましたが、この本の中でも、チームのステージ（立ち上げ期、安定期、など）に合わせて会議のあり方や出社とリモートの組み合わせ方などについて適宜議論することの重要性を説いています。
+
+Slackの利用方法についてもこのTLAの考え方が非常にマッチしています。
+
+# スレッド内での返信・通知、どう考えてますか？
+
+例えばこんなケースを考えてみたいと思います。
+
+とあるアプリケーションの開発にてあなたは開発を担っています。仕様責任者やレビュアーなど関係者とのやり取りはSlackにて行っており、実装方針についてスレッド内にて数度のやり取りの上、決定した方針が仕様責任者からあなた宛のメンション付きで投稿されました。
+
+あなたはこの際どのように返事をしますか？
+
+①相手宛のメンションを付けて「分かりました」と返事
+②メンションは付けず「分かりました」と返事
+③仕様責任者のメッセージにリアクションをつける（「了解しました」のような文字スタンプを想定）
+
+...たぶん色んな派閥の人がいるんじゃないかなと思います。
+
+①派「分かったってことを確実に伝えなきゃ。メンション付けないと相手が気が付かないじゃん。」
+②派「相手に行動を促すわけではないし、メンションは付けなくていいかな。」
+③派「不要なメッセージ投稿はスレを汚すだけ。リアクションだけで十分でしょ。」
+
+それぞれの主張、いずれも「言ってること自体は理解できる」って感じなのではないでしょうか。
+
+今回公開したガイドラインでは以下のように記載しており、ベーススタンスは②です。
+
+>過剰なメンションの抑制
+原則、レビュー依頼や確認依頼など、行動してほしい時にメンションを付けるものとする。「@mirai ありがとうございます！」 「@mirai 承知しました！」等の挨拶にメンションを付けると、通知が来てノイズになるため非推奨とする。メンションを付けず「ありがとうございます！」とすると良い。
+
+しかし実際私の周りには③派の人も結構おり、チャンネルによっては③前提でSlackコミュニケーションを取っています。
+
+小さな話と感じるかもしれませんが、ちょっとしたコミュニケーションのストレスはチリツモで大きくなっていってしまいます。例えばこういった内容をTLAとしてチームごとにすり合わせできると、チームでのコミュニケーションが円滑になっていくはずです。
+
+そしてその際の叩き台として、今回作成したSlack利用ガイドラインを活用いただけると幸いです。やはりTLAを議論する際に困るのは「何を議論すべきか」の部分です。なのでまずはチームメンバー同士でSlack利用ガイドラインを一読いただき、「ここは賛成」「ここは少し別の考えを持ったんだけど皆さんはどうでしょうか...」などお互いの考えを持ち寄ってチームにとって最適な形を議論するきっかけになればいいなと思っています。
+
+# さいごに
+
+フューチャーはSlackとGoogle Workspace(GWS)とを両方活用しながら日々のコミュニケーションを行っています。Slackは元々チャットツールとしてフロー情報を取り扱うイメージが強く、ストック情報の取り扱いは基本的にGWSを使っていたのですが、Canvasなどストック情報の取り扱いにも長けた新規機能の登場によりその境界がまた変わってきてるなと感じております。
+
+「Slackにてどこまでストック情報を取り扱うか」については私もまだまだ研究中であり、ベストプラクティスには至れていないなと感じる今日このごろ。まずは本ガイドラインの公開を第一歩として、更にSlackの有効活用検討を進めていきたいと思います。