私のチームでは、Slack通知をアプリレイヤーで発生したエラーの検知や、バッチ処理の実行結果を報告する目的で利用しています。
Slack通知は、受信側がその内容を必要とするタイミングで適切に届けることで価値を発揮します。しかし、不要な情報が日常的に混在すると、受信側の注意力が分散し、重要な情報への認知を妨げる結果となります。そのため、通知は常に必要なものだけになっていることが理想的です。
しかし、実際の開発・運用現場では、時間の経過とともに念のために追加した通知が蓄積し、情報の形骸化が進む傾向にあります。私のチームでも同様で、極端な例ですが、1日の通知のうち約8割が、実際には対応や確認を必要としない通知になっているチャンネルがありました。全てのチャンネルがそうであったわけでは無いですが、このような状態ではセキュリティに関する警告や致命的なシステムエラーなどの重要度の高い通知が埋もれ、見落とされる危険性が高まっていました。
方針
通知の量を適切に管理するため、情報の性質に応じた出力先の再定義を行いました。全ての情報を一律にSlackへ流すのではなく、以下の基準に基づき情報を分離しました。
Slackに出力する情報
- 即時対応が必要な情報システム異常やエラーなど、速やかな確認とアクションが必要なもの
- ビジネス判断に必要な情報: 非エンジニアを含む関係者が、ビジネス上の判断や運用の進捗管理を行うために必要とする情報
CloudWatch Logsに出力する情報
- バッチ処理の正常終了ログ、詳細なデバッグログ、事後調査用のログなど。即時の通知は不要だが、履歴として参照できるようにしておくべき情報
この基準に沿って、既存の全通知を対象に「誰が、どのタイミングで、何のために参照するのか」を再評価する棚卸しを実施しました。
実施内容
今回の対応では、アプリケーションのソースコードから不要なSlack APIの呼び出し処理を直接削除するとともに、Slack側のチャンネル構成についても見直しを行いました。
具体的な実施内容は以下の通りです。
- 不要な通知となっていたバッチ処理の完了通知や、正常系のログ出力をコードから削除
- 削除対象となった情報は、必要に応じてCloudWatch Logsへ出力されるようロジックを調整し、トレーサビリティを確保
- 通知の役割が重複しているもの、あるいは用途が不明確になっていたSlackチャンネルを統合・削除し、情報の集約先を整理
不要なロジックを削除し、コードベースと通知環境の両面を健全な状態に戻すことを重視しました。「とりあえず残しておこう」という理由で実装されていた通知を削除する際、詳細なログがCloudWatch Logsに保持されていることが、心理的な安全策となりました。
実施結果
不要な通知処理を削除した結果、対応が必要な通知のみに絞られたことで、チーム全体のアラートに対する感度が向上し、異常発生時の初動が迅速化されるという効果が得られました。また、ソースコードの可読性が向上し、開発者の認知負荷が軽減されました。システムの健全性を維持するためには、実態に合わせて不要な処理を削ぎ落とす工程が不可欠であることを再認識しました。エンジニアリングにおいて、機能を追加することだけでなく、不要になったコードを適切に削除することも同等に重要だと改めて思いました。
今後の展望
通知が増殖する背景には、構造的な問題があると考えています。開発時において、安易にSlack通知に組み込むことは、実装コストが低く、心理的な安心感も得やすいため、つい選んでしまいがちな傾向があります。しかし、こうした選択が積み重なることで、結果的に通知の肥大化を招いていました。この問題を解決するため、今後はガイドラインの整備やAIによる自動選別などの導入を検討し、仕組みによって通知の要否を管理できる体制を整えたいと考えています。そうした中で情報の形骸化を防ぐ仕組みの構築を進め、チームが本来注力すべき業務に集中できる基盤を整えていきたいです。