はじめに

この記事ではMicrosoft Teamsを 実際に使って便利だった機能 と、Slack と比べて正直キツいと感じた部分 を記載する。あくまで使い始めの超基本的な内容。

目次

チャンネル設計 ― ここを最初にサボると地獄
スレッド返信 ― 使い方を統一しないと崩壊する
タブ機能 ― チームの情報を一か所に集める
会議機能 ― これだけは正直 Zoom より使いやすかった
Power Automate 連携 ― 通知の自動化で神になれる
正直イマイチだった機能・場面
結局 Slack と何が違うのか

1. チャンネル設計

やってみたこと

Teams を使い始めて最初にやらかしたのが、チャンネル設計を作ったこと。
3ヶ月後には「チームAの連絡」「チームAの雑談」「チームA_old」「チームA_2024」が乱立した。

反省して設計し直した構成がこれ。

設計のポイント：

一般 チャンネルは削除も非表示もできないので、ここをお知らせ専用にする
Bot 通知専用チャンネルを最初から作る（開発チャンネルに流すと会話が埋まる）
障害チャンネルを独立させる（ステータス確認がしやすくなる）

正直な感想

良かった点：

チャンネルに 「タブ」を追加できるので、関連ドキュメントや Wiki を紐づけておける（後述）
プライベートチャンネルで特定メンバーのみの空間を作れる

ハマりポイント：

チャンネルの並び順をユーザーが自由に変えられない（アルファベット順固定）
一度作ったチャンネルは削除しにくく、ゾンビチャンネルが量産されがち
Teams の「チーム」と「チャンネル」の概念が、一般的な「チャンネル」とズレていて、社内説明に毎回苦労する

2. スレッド返信

やってみたこと

Teams の投稿には「返信」と「新しい投稿」の2種類がある。
これを最初にチームで統一しておかないと、会話が縦横無尽に散らばる。

チームで決めたルール：

✅ 同じトピックの続きは「返信」で
✅ 新しい話題は「新しい投稿」で
✅ 誰かへの反応は必ずスレッド内でリアクションか返信
❌ 「了解です！」を新しい投稿にしない

正直な感想

良かった点：

スレッドがちゃんと使われると、話題ごとに会話がまとまって振り返りやすい
後からチャンネルに参加したメンバーも経緯を追いやすい

ハマりポイント：

Slack のスレッドと UI が異なるので、Slack 経験者が混乱しがち
返信が来てもスレッドが折りたたまれていると気づかないことがある
ルールを徹底するのが難しく、結局は文化づくりの問題になる

3. タブ機能

やってみたこと

チャンネルの上部にある「+」でタブを追加し、チーム情報を一か所に集約した。

追加できる主なタブ：

タブ	用途
SharePoint / ファイル	ドキュメント管理（デフォルト）
OneNote	共有ノート
Planner	タスク管理（Microsoft 謹製）
Azure DevOps	チケット・スプリント管理
Website	任意の URL を埋め込む
PowerBI	レポートをそのまま表示

正直な感想

良かった点：

Grafana や Confluence を埋め込めるので、チャンネルを開けば必要な情報が揃う 状態を作れた
Microsoft 製品同士（Azure DevOps・Planner・SharePoint）との連携は本当にシームレス

ハマりポイント：

タブが増えすぎると逆に探しにくくなる（5〜6個が限界）
サードパーティ製タブは認証が面倒なケースがある（SSO が通らないなど）
Notion はタブ機能に相当するものがなく、この点は Teams が明確に勝っている

4. 会議機能

やってみたこと

これは正直、Zoom や Meet より使いやすかったと感じた数少ない機能。

特に便利だったもの：

自動文字起こし（トランスクリプト）：会議後にそのまま議事録のベースになる
ブレイクアウトルーム：グループワークに使える（Zoom より設定が楽）
Together Mode：雑談に使うと意外と盛り上がる
Outlook カレンダー連携：招待〜参加がシームレス

正直な感想

良かった点：

録画が SharePoint に自動保存され、後から見返しやすい
参加 URL を発行しなくてもチャンネルから直接会議に入れる
文字起こし精度は日本語でも実用レベルになってきた

ハマりポイント：

大規模会議（50人超）になると動作が重くなることがある
外部の人を招待する場合、ゲストアカウント周りの設定が煩雑
ブレイクアウトルームへの割り当てが手動だと地味につらい（100人規模はきつい）

5. Power Automate 連携

やってみたこと

「GitHub で PR がマージされたら Teams に通知する」をノーコードで実現した。

設定の流れ（GitHub → Teams の例）：

Power Automate で「HTTP 要求を受け取ったとき」トリガーを作成
Webhook URL を取得して GitHub の Webhook に登録
アクションで「Teams にメッセージを投稿する」を選択
メッセージ本文を PR タイトル・URL・マージ者名で組み立てる

正直な感想

良かった点：

Microsoft 365 エコシステム内の連携は本当に強い（Azure・Outlook・SharePoint・Excel との自動化）
ノーコードで複雑なフローが作れる

ハマりポイント：

Slack の Incoming Webhook と比べると設定が重い。Slack なら5分でできることが Teams だと30分かかることがある
Power Automate の無料枠は実行回数に制限があり、大量の通知フローを作るとすぐに上限に当たる
エラーが起きたときのデバッグが分かりにくい（ログが見づらい）
Zapier や Make（旧 Integromat）を使ったほうが柔軟なケースも多い

6. 正直イマイチだった機能・場面

❌ 検索が壊滅的に弱い

Slack は検索が優秀で、キーワード・投稿者・チャンネル・日付で絞り込めて精度も高い。
Teams の検索は 精度が低く、絞り込みオプションも少ない。「あのメッセージ絶対あったのに出てこない」が日常茶飯事。

❌ UI/UX が重くて直感的でない

これは体感として本当に辛い。特にチャンネルやスペースを多数抱えている組織だと、切り替えのたびにストレスが積み重なる。
Electron 製アプリ特有の問題でもあり、メモリ消費も多い（8GB RAM の端末だと顕著）。

❌ 通知設計が複雑すぎる

Slack は「このチャンネルはメンションのみ通知」「このチャンネルは全投稿通知」がシンプルに設定できる。
Teams は通知設定の階層が深く、どこで何を設定したか分からなくなる。

通知の設定場所が多すぎる問題：

・Teams アプリの設定
・チャンネルごとの設定
・投稿ごとの通知設定
・Outlook の通知と混在
・モバイルとデスクトップで設定が別

→ 「通知来すぎ」か「通知来なさすぎ」の二択になりがち

❌ Slack のアプリエコシステムには遠く及ばない

Slack には豊富なサードパーティ連携（GitHub・Jira・PagerDuty・DataDog など）がある。
Teams にも同様のアプリはあるが、設定の複雑さ・安定性・柔軟性で Slack に負けていることが多い。

連携	Slack	Teams
GitHub	◎ シンプル	△ 設定が重い
Jira	◎	△ 動作が不安定なことも
PagerDuty	◎	△
DataDog	◎	△
Microsoft 製品	△	◎◎ 圧倒的

❌ 「いいね」だけでは反応が単調

Slack は絵文字リアクションが豊富で、スタンプ文化がコミュニケーションを豊かにする。
Teams は「いいね・ハート・笑い・驚き・悲しい・怒り」の6種類のみ（カスタム絵文字は 2023 年以降追加されつつあるが）。
地味にチームの雰囲気に影響する。

7. 結局 Slack と何が違うのか

2つのツールの本質的な違いはここだと思っている。

どちらを選ぶべきか

正直な結論：
Teams は 「Microsoft 365 の一部として使う」前提で設計されており、その文脈では非常に強い。
しかし「チャットツール単体」として Slack と比較すると、UX・検索・エコシステムで負けている場面が多い。
エンジニアが自由に選べる環境なら Slack を選ぶが、会社がすでに M365 を使っているなら Teams を使い倒すほうが合理的。

まとめ

評価軸	Teams	Slack
検索	△	◎
動作の軽さ	△	◎
会議・録画	◎	△
Microsoft 製品連携	◎◎	△
サードパーティ連携	△	◎
通知設計	△（複雑）	◎
コスト（M365あり）	◎◎	△
開発者体験	△	◎

Teams を使うなら、「チャットツール」ではなく「Microsoft エコシステムのハブ」として設計するのが正解。
チャットだけを期待して導入すると、Slack からの移行組が全員不満を持つことになる。

この記事の内容は個人・チームでの実体験に基づいています。Microsoft のアップデートにより仕様が変わっている場合があります。