テクノロジー系会社に強いSlackへの対応
Slackはアメリカ発のチャットサービスですが、とりわけテクノロジー系の会社で強い支持を集めています。様々な外部ツールとの連携が容易に実現できることが特徴で、こうしたインテグレーションに対応しているサービスもどんどんと増え、ますます便利になってきています。
会社横断的にSlackを利用しているという会社も多いのではないでしょうか。かつてはエンジニアのためのSlackというイメージでしたが、全社的に使用する例も増えてきているようです。Slack上で行えることはどんどんと増えてきているため、単なるチャットツール以上の存在になっているところも多いのではないでしょうか。
こうしたSlack利用企業を顧客に持つサービスを運営している場合、Slack通知機能をシステムに組み込むことでサービス付加価値が高まり、顧客満足度が高まる場合があります。どのような点に気をつけ実装すべきか、いくつかのポイントで整理してみましょう。
Point.1 Incoming Webhookが手軽
Slack通知で行いたい内容がもし、メッセージの投稿とファイル送信で事足りるのであれば、SlackのIncoming Webhookという機能を利用して実現するのが最も手軽でしょう。顧客側の負担もそこまで大きくなく、システム運営側にも設定の複雑さがないというメリットがあります。
通常の通知であれば、本文となるメッセージと、添付ファイルなどがある場合にファイル送信ができれば十分だと思います。こうしたユースケースでは、Incoming Webhookで十分に必要要件を満たせると思います。ファイル送信ではSlack側にファイル実体を委ねられるため、ファイル実体をシステム側で持ち続ける必要がないのがメリットになる場合もあると思います。
Point.2 処理は1秒1回が原則
SlackのAPIの利用レート制限はいくつかの段階があり、使用するAPIによって異なります。Incoming Webhookの場合は1秒に1回となっており、短時間のバースト時のみその制限を超えても良いという制限になっています。あくまでバースト時想定で常用するものではないため、基本的には1秒に1回の処理を実装すべきです。
バッチ処理で行う場合にはリクエストごとの間隔を制御しやすいため、確実に1秒休むような処理を書けば問題はでないと思います。即時処理が原則であれば、それぞれの処理が重なった場合に正確にキューイングするか、万が一利用レート制限に引っかかり「Too many requests」のエラーが起こった際のリトライ処理を実装する必要があります。内部的なサービスであれば制限にかかってもリトライすればOKぐらいの程度ですみますが、ある程度の規模以上のサービスの機能として投入する場合には、エラーが起き始めると一気に収拾がつかなくなる場合もあります。多少のスローダウンは起きたとしても、エラーが起きない処理や、エラーが起きても全体に波及しない工夫が必要になるでしょう。
Point.3 メンションも実現可能
メンションしたい相手のUserIDを設定することで、Incoming Webhookを通じたメンションも可能です。投稿内容を特に知る必要がある相手を指定できるため、人数が多い会社や部署でのSlackでは重宝される機能です。
UserIDを取得する方法さえ適切にヘルプページ等で案内することができれば、メンションするために必要な投稿書式の修正は軽微なものです。また、複数メンションも可能なので、そのように機能を拡張するのも良いでしょう。メッセージが溢れていて、メンションすることがルールになっているような組織には非常に喜ばれる機能です。
より高度な連携もAPIで可能
以上はすべて、Incoming Webhookでの利用を前提とした解説でしたが、Slackにはより高度な連携が可能なAPIが多数用意されています。「このAPIを使えばどういった新機能を追加することが可能だろうか」という視点で、SlackのAPIリストを眺めてみるのも良いかもしれません。
開発スタッフのコメント
