こんにちは！
ツクリンクでアソシエイトエンジニアリングマネージャーをしている八尾(@Tomoki____Y)です。
私は普段、各プロジェクトが円滑に進むようサポートすると共に、エンジニアがより開発に集中し、顧客と向き合える環境づくりに取り組んでいます。
私がメインで関わっている Growth チームの紹介がツクリンクアドベントカレンダー 2025で行われますので、是非見ていただけますと嬉しいです！
はじめに
突然ですが、皆様のチームのアラート通知チャンネルは健康でしょうか？
通知が鳴っても「あー、またいつものやつね」とスルーされることが常態化していないでしょうか。
もし、このような「不健康な通知」を放置していると、チームには深刻な悪影響が生じます。
-
開発者体験の低下
- 意味のない通知による頻繁な割り込みが、エンジニアの集中力を寸断してしまう。
-
チームの疲弊
- 「対応不要なエラー」を見せられ続けることによる徒労感や、認知負荷の蓄積。
-
アラート全体の形骸化
- 「いつものやつね」というバイアスがかかり、本当に重要な障害通知まで埋もれてしまう。
先日、一部そのようになっていた通知設定を見直し、不要なアラートを削除・整理する作業を実施しました。
この記事では、その作業を通じて改めて痛感した、アラートを形骸化させないために重要だと感じた設計ポイントをご紹介します。
なお、これらのポイントはまだチームとして完全にルール化・運用できているわけではなく、今後実践していきたいと考えている内容になります。
1. 対処可能・対応必要なものだけを通知する
これは私自身も振り返るとやってしまいがちだったのですが、「その通知を受け取ったエンジニアが、何らかのアクション（調査、修正、周知など）を取る必要があるか？」を基準にしておくことが重要です。
なぜ重要か
「何かが起きた」という情報をすべて通知してしまうと、緊急対応が必要な障害通知が、日常的な「対応不要なエラーログ」に埋もれてしまいます。
ここで言う「対応不要」とは、単にシステム内部のエラーかどうかだけでなく、「今すぐ人間が介入して状況を変える（あるいは判断する）必要があるか」という観点です。
設計の指針
ログで十分ではないか？
- 単発の入力ミスや、想定内の拒否（バリデーションエラー）など、エンジニアがその場で見ても「そうですか（正常な動作です）」としか言えないものは、通知すべきではありません。これらは通知までは行わず、ログ出力程度に留めるべきです。
人が動く必要があるか？
- システム障害でなくとも、「外部サービスが落ちているのでユーザー告知が必要」「不正利用の疑いで調査が必要」といった場合は、立派な「対処可能/対応必要」な通知です。
通知の信頼性を保つ
「念のため知っておきたい」という情報をアラートチャンネルに通知することは、開発者の認知資源を削ります。「通知が鳴った＝何らかの判断や行動が求められている」という信頼感を設計レベルで保証することが、健全な開発者体験につながります。
2. 通知の「チャンネル戦略」を設計する
アラート設計において、意外と見落とされがちなのが「どこに通知するか」という視点です。
なぜ重要か
「エラー通知はとりあえず #alert チャンネルへ」と、全ての情報を一箇所に集約してはいないでしょうか？
緊急度の高いシステム障害も、日次のバッチ処理の結果も、重要度の低い警告もすべて同じ場所に流し込むと、チャンネル内の情報の重要度が希釈されます。結果として、エンジニアは常に流れるタイムラインから「自分に関係ある重要な情報」を目視でフィルタリングすることになり、認知負荷が高まります。
設計の指針
情報の「緊急度」と「ターゲット」に応じて、通知先を明確に分離することが重要です。
例えば、以下のような分離が考えられます。
緊急度による分離
-
#alert-critical: 即時対応が必要な障害（サイトダウン等）。全員が通知をオンにする場所。 -
#alert-warning: 翌営業日などに確認すればよい警告。 -
#log-xxx: 記録用。何かあった時に検索するための場所（通知 OFF 推奨）。
役割による分離
- 全エンジニアが見るべきか？ 特定のドメイン担当者だけが見ればよいか？
- CS チームへの連携が必要な情報は、エンジニアのチャンネルではなく CS 連携チャンネルへ流す。
チャンネル戦略の効果
情報は「混ぜる」とノイズになりますが、「分ける」ことで重要な通知を守ることができます。
「このチャンネルの通知は絶対に今見るべきものだ」とエンジニアが確信できる状態を作ること。それが重要な通知の形骸化を防ぎ、チームの集中力を守るための「チャンネル戦略」です。
3. 通知メッセージは「状況報告」ではなく「行動指示」にする
通知メッセージの内容を設計する際、単に「何が起きたか」を伝えるだけになっていないでしょうか？アラートの目的は、受信者に現状を伝えることではなく、受信者を動かして状況を解決することです。
なぜ重要か
「バッチ処理が失敗しました」「CPU 使用率が高いです」といった「状況報告」だけのメッセージでは、受け取ったエンジニアは以下のような判断をその都度脳内で行わなければなりません。
- 「で、これはどれくらいヤバいのか？（緊急度）」
- 「放置していいのか、すぐ対応すべきなのか？（要否）」
- 「まず何を見ればいいのか？（初動）」
特に深夜や休日、あるいは障害発生時の混乱した状況下で、この「判断コスト」を強いることは、初動の遅れや対応ミス（オペレーションミス）を招く原因になります。
設計の指針
メッセージには「事実」に加えて、必ず「推奨されるアクション」を含めることが重要です。
Bad（事実のみ）:
[Alert] Jobが失敗しました (Job ID: 12345)
これでは、再実行すべきなのか、無視していいのか分かりません。
Good（事実＋行動指示）:
理想的には、以下のような形式が望ましいです。
[Warning] 請求作成バッチが失敗しました。
影響: 明日の請求処理に遅延が発生する可能性があります。
アクション: 管理画面から Job ID:12345 の再実行ボタンを押してください。
失敗が続く場合は SRE チームへエスカレーションしてください。
手順書: [Runbook へのリンク]
心理的負担を軽減する
緊急時に最もメンバーを消耗させるのは「どうすればいいか分からない」という不安です。
メッセージの中に明確な Next Action や 手順書 へのリンクを含めること。「通知を見れば、次にやるべきことが書いてある」という状態を作ることが、メンバーの心理的負担を下げ、迷いのない迅速なリカバリーを可能にします。
4. 定期的に「通知の断捨離」を行う文化を作る
最後に、組織文化の話です。アラート設定はリリースした瞬間から古くなり始めます。
なぜ重要か
システムの改修やビジネスルールの変化により、当時は必要だった通知も「今は不要（ただのノイズ）」になることがよくあります。
「スルーされた通知」が放置されている状態は、窓割れ理論のように、他の重要な通知への注意力を散漫にさせます。
運用の指針
今後、チームで実践していきたい運用方針として、以下のようなことを考えています。
無視された通知を検知する
- 誰も反応しなかった通知や、「これは無視していいやつ」と会話される通知を見逃さないようにする。
定期的な棚卸し
- 四半期に一度など、コードのリファクタリングと同じようにアラート設定を見直す時間を設ける。
目指したい文化
「アラートを無視したメンバー」を責めるのではなく、「無視されるようなアラートを放置しているプロセス」を疑う文化を作っていきたいと考えています。
アラート設定を「断捨離」し続けること。それが「集中できる開発環境」を作る 1 つの方法だと考えています。
まとめ
アラート設計を深く考えずに実施してしまうと、通知自体の形骸化を招いてしまいます。
この記事では、アラート整理を通じて痛感した、アラート通知を形骸化させないために重要だと感じた 4 つの設計ポイントをご紹介しました。
- 対処可能・対応必要なものだけを通知する - 通知の信頼性を保つ
- 通知の「チャンネル戦略」を設計する - 重要な通知を守る
- 通知メッセージは「状況報告」ではなく「行動指示」にする - 心理的負担を軽減する
- 定期的に「通知の断捨離」を行う文化を作る - メンバーを責めず、プロセスを疑う
「不安だからとりあえず全部通知しておく」。その気持ちは、私自身も痛いほどよくわかります。しかし、その「念のため」の通知が積もり積もって、チームの集中力を奪い、疲弊させているとしたら本末転倒です。
勇気を持って不要な通知を捨て、本当に必要な通知だけを残すこと。それが「メンバーが開発に集中できる環境を作る」ことにつながります。
今回ご紹介したポイントは、まだ完全にはチームで実践できていませんが、今後少しずつ取り組んでいきたいと考えています。もし皆さんのチームでも「いつものやつね」と無視される通知があれば、まずは 1 つ削除してみることから始めてみてください。小さな一歩が、チーム全体の開発者体験を大きく改善するきっかけになるかもしれません。
この記事が、皆さんのチームのアラート設計を見直すきっかけになれば幸いです！
Discussion