各種チェック結果をSlack通知にまとめて幸せになった件

システムの各種動作などで、

エラーなどが起きたり、

各種チェック結果を保持していたり、

それぞれのシステムで状況が異なります。

そんな中で、

社内システムの内容を確認していく中で、

このような感じで、

「Slackへの通知」

を行うことで、

色々と個人的に助かったので、

どのような経緯でやるようになったのか、

やってみてどうだったのかという個人的な意見を説明していく。

少ない人数で複数システムの面倒を見るのが大変だった

社内システムや各種外部サービスなど、

色々と使っていく中で、

最初のうち、

正確には、使っているシステムが少ないうちは、

特に少ないシステム数なので、

それぞれのシステムを確認すれば良かった。

しかし、

• 複数の社員が別のシステムを使い始めた
• 構築した社内システムが増えてきた

という状況になってきた時、

と感じることが多くなりました。

まぁ、

当たり前といえば、当たり前ですね。

システムＡのチェック結果 → システムＡを確認

システムＢのチェック結果 → システムＢを確認

システムＣのチェック結果 → システムＣを確認

という感じで、

それぞれのシステムを確認する時間が、

なかなか、大変になってくるのは、

もともと、目に見えていましたが、

実際にその状況になった時、

かなり無理ゲーであることを体感しました。

各種チェック処理なんてしたくない、けど、やるしかない

今はエンジニア不足もあるので、

多くの企業、特に社員が少なく、

エンジニアが色々と面倒を見ることが多い時、

というのは、

すごく感じることだと思う。

実際、

それぞれのシステムを、

こんな感じで、

それぞれチェックしていると、

他の改修など、

やっていきたいことができない。

個人的には、

チェック作業よりも新規開発がしたい

という考えが強いので、

それであれば、

チェック処理をまとめて、楽をするしかない

という結論に至りました。

チェック処理を楽にするために、チェック結果をSlack通知で集約

本当に、

チェック処理なんて、

面倒なので省略したいけれど、

正常稼働していることや、

各種データのチェック結果などは、

都度、確認しておく必要があるのです。

そんな環境で、

新規開発をやりたいがために、

チェック結果などを集約する事にしました。

しかし、

集約することは決めたけれど、

という感じで、

集約する方法に悩んでいました。

集約するにあたって、

• 確認結果などは、カスタムな文章で送りたい
• 確認するツールは、普段使うものが良い

という点を考えて、

普段から社内で使っている、

「Slack」のサイトへ

を集約する事にしました。

「Slackへの通知」に集約するイメージ

Slackにチェック結果を集約するイメージとしては、

もともとの、

このチェックフローのイメージから、

チェック結果を集約することで、

このように、

チェック結果をSlackに集約することで、

通知がSlackに来ることで、

わざわざ、それぞれのシステムを確認する必要がなく、

他のことに時間が割けるようになりました。

「Slackへの通知」に集約することで、チェックが楽になった

実際に上記の各種チェック結果を、

Slackに集約するようにして、

実際に運用してみた結果としては、

• チェックする時間が大幅に短縮された
• 通知するチェック結果を精査することで把握しやすくなった
• 自分以外にもチェック処理結果を共有しやすくなった

というメリットがあったので、

実際にチェック処理をSlackに集約することで、

すごく大きなメリットがあったと感じています。

そして、

個人的に最も良かったのは、

このチェック処理の確認作業で空いた時間を、

新規開発の時間に充てることができたことでした。

もし、

各種チェック処理に時間がかかっているような人がいれば、

Slackでも他のツールでも良いですが、

集約してチェック処理結果の確認を、

楽にするように取り組んでみると、

エンジニア自身が恩恵を受けるのでおすすめです。

参考：過去にLaravelでSlack通知した時のメモ

以前、

Slackへの通知に関しては、

Laravelで試して、

その時のメモを残しておいたので、

参考になれば幸いです。

LaravelからSlack通知の基本