Slack連携の限界突破へ！iPaaS活用ガイド（第1回：現状のおさらいと課題）

s-sato

はじめに

対象読者

本記事は、Slackと他サービスとの連携に関して課題を感じている方、Slackをハブにした業務フローを検討している方を主な対象としています。

本記事の前提知識として、SlackアプリやWebhookに関する基本的な知識、何かしらのワークフローツールの基礎知識があることを想定しています。

なお、今回第1回の内容は、半分以上がSlackと他サービスとの連携についてのおさらいになっていますので、すでにSlackと他サービスとの連携についておおよそ理解されている方は、「(おさらい)」の項は読み飛ばしていただければと思います。

記事のゴール

本記事は複数回に分かれていますが、全体を通じて、読者は以下の点を達成することを目指したいと思います。

  • Slackと他サービスとの連携方法について、改めておさらいする（今回の範囲）
  • iPaaS(Integration Platform as a Service)の Zapier と Make のサービス概要を把握する
  • Zapier による実際のフロー構築のイメージをつかむ
  • Makeによる実際のフロー構築のイメージをつかむ
  • 全体を通じてのまとめ

本記事を書こうと思ったきっかけ

当社ではコミュニケーションツールとしてSlackを採用しており、多くの業務や作業のハブとなっています。また多くの企業と同様に、GoogleWorkspace、GitLab、HubSpot、Zendeskなど、各専門業務に応じた他のサービスも利用しています。
そのため、各サービスで発生するイベントやアクションを、ハブとなっているSlackを起点・経由点になるようにすれば、Slackに集中しておけば業務が回るようになるため、業務効率化の観点からなるべく連携させるようにしたいと考えています。

しかし現状としては、Slackが標準提供するWebhookなどの連携機能に不足を感じたり、他サービス側の公式Slackアプリやプラグインがサポートしている連携内容に物足りなさを感じたりすることがありました。
そのため、Slack提供機能や他サービス側の公式Slackアプリ以上の細やかなことをしようとすると、独自のSlackアプリの開発・運用が必要になり、総務や営業系の非エンジニアのメンバーにとっては途端にハードルが上がってしまいます。しかし、各専門の業務内容を一番理解しているのは、そういった非エンジニアのメンバーです。
そのため、ノーコードなiPaaS（Integration Platform as a Service）を活用することで、非エンジニアのメンバーが、エンジニアに頼ることなくSlackと他サービスを緊密に連携させて業務を効率化することができそうか？という観点でiPaaSについて検証してみようと考えたのがきっかけです。

iPaaSについて書き進めていく前に、まず前提として現状のSlackと他サービスの連携についておさらいしていきたいと思います。

他サービス→Slackへの連携（おさらい）

他サービス提供のSlackアプリ

まず最初の手段として、他サービスが開発・提供するSlackアプリを利用するという手段があります。多くのケースにおいては、この手段が他サービス→Slackへの連携の最良の方法だと思います。
ただし、あくまで他サービス側がSlackアプリを提供していれば…の話です。また私の経験上では、通知内容がものすごく限られたものだけになっていて、実際のユースケースと合わないといったこともあったりしたので、Slackアプリが提供されていたとしても過信は禁物です。

Slack提供機能による連携

Slack提供機能を利用した他サービスからSlackへの連携手段としては、以下の3つの方法があります。

1. カスタムインテグレーションの受信Webhook

昔から提供されている機能で、投稿するチャンネルを設定すれば、あとはWebhookのURLに対してJSONを送信するだけで、メッセージ投稿が可能になります。

設定が簡単なので非エンジニアのメンバーでも気軽に利用できますし、当社でも以前はよく利用していました。
ただし、JSONは以下のようにSlackが理解できる構造になっていないとダメなので、送信するサービス側がSlackのJSON仕様に対応している、もしくはJSONをカスタマイズできるようになっていないと利用できません。

{
  "text": "これは、チャンネル内のテキスト行です。
  そしてもう1つテキスト行があります。"
}

またさらに言うと、冒頭に以下のような注意書きがあるとおり、現在は非推奨な機能となっているため、その点は注意しておく必要があります。

これはレガシーカスタムインテグレーションであり、チームがSlackと連携するための時代遅れの方法です。これらの連携には新しい機能が不足しており、将来的には廃止されるか、削除される可能性があります。
これらの連携のご利用はお勧めしません。代わりに、代替手段であるSlackアプリをご確認ください。

2. ワークフロー機能のWebhookトリガー　※有料プランのみ

Slackの有料プランでのみ利用可能な機能になりますが、ワークフロー機能に受信Webhookのトリガーを設定することが可能です。受信したJSONに含まれるキーの値を変数化してワークフローの後続ステップへ渡すことができるので、送信側のJSON構造に柔軟に対応したワークフローを実行することが可能です。
例えば以下のような設定例だと、email と message キーの値を変数として、ワークフローの後続ステップで利用することができます。

有料プランの機能だけあって高機能になっていますが、実はフラット構造(1階層目のみ)のキーしか対応していないため、入れ子構造(2階層目以降)のキーは扱えないという制限があります。(以下JSONで言うと user_id や status の値は取り出せない)

{
  "email": "example@example.com",
  "message": "テキストの例",
  "user_info": {
    "user_id": 12345,
    "status": "active"
  }
}

※公式ドキュメントにもその旨の記載あり

3. Slackアプリの受信Webhook

1のカスタムインテグレーションの注意書き内で推奨されている方法です。
まず、https://api.slack.com/apps へアクセスしてSlackアプリを作成します。作成したアプリの Incoming Webhooks を有効にして、投稿するチャンネルを設定すれば、あとはWebhookのURLに対してJSONを送信するだけで、メッセージ投稿が可能になります。

現在推奨されている方法ですが、Incoming Webhooks を有効にしただけでは、結局はカスタムインテグレーションと同様で、JSONはSlackが理解できる構造になっていないとダメという問題があります。

他サービス→Slackへの連携まとめ

長々と書いてきましたが、他サービス→Slackへの連携について結論をまとめると、まず他サービス側からSlackアプリが提供されているのであれば、最初にそれを試してみるのが良いと思います。

Slackアプリが提供されていない、もしくは提供されていてもユースケースに合わなかったという場合は、受信Webhookによる連携を模索することになると思います。
ただしその場合、連携元の他サービスが、Slackにきちんと対応しているJSONを送信する、または送信するJSONをカスタマイズできるようになっている必要がありますが、Slackアプリを提供していない(使いづらい)サービスは、恐らくその辺は対応できてないと思います。

その場合は、有料プランでのみ利用可能なワークフロー機能のWebhook受信トリガーの利用を検討してみてください。ただし、フラット構造(1階層目のみ)のキーしか対応していないため、その制約によって思った通りの連携ができないシーンも出てくる可能性はあります。

Slack→他サービスへの連携（おさらい）

他サービス提供のSlackアプリ

先程と同様、最初に検討する手段としては、他サービスが開発・提供するSlackアプリを利用するという手段があります。
ただし、先程の他サービス→Slack方向の連携は 通知 が主な目的でしたが、Slack→他サービス方向の連携の目的は 何かのアクションをしたい のが主な目的になってきます。
例えばGitLabを例に取った場合、普段の作業の中で頻繁に行いそうな操作としては以下のようなものがあると思います。
　・Issueを作成したい、ラベルを付けたい、Assigneeを変えたい、コメントしたい、クローズしたい
　・マージリクエストを作成したい、マージしたい
　・特定のワークフローを実行したい
　・ユーザーを追加したい、削除したい
このようにアクションをしたい内容は多岐に渡ってきますが、当然ながら 他サービス側がSlackアプリの機能として開発・提供できる範囲は限られてきます。
実際にGitLabが提供するSlackアプリからできる操作は、基本的にIssueに関する操作がほとんどで、それ以外の操作は行えません。さらにIssueに関しても、ラベル付けやAssignee変更などの操作はサポートされていませんでした。

これはGitLab以外のサービスにおいても同様で、アクション内容は一部の限られたものだけになっていて、実際のユースケースに比べると不足していることがほとんどでした。

Slack提供機能による連携

Slack提供機能を利用したSlackから他サービスへの連携手段としては、以下の3つの方法があります。

1. カスタムインテグレーションのOutgoing Webhook

こちらも昔から提供されている機能で、チャンネル内に特定のキーワードが投稿された際に、WebhookのURLに対して定型フォーマット(非JSON)を送信する機能です。
ちょっと個性が強すぎる仕様で使いづらいように思います。(少なくとも当社内では誰も使っていませんでした)

2. ワークフロー機能のアクション　※有料プランのみ

ワークフロー機能用アプリを提供しているサービスのみが利用できます。さらにはアクション内容も限定的で、実際のユースケースに比べると不足していることがほとんどだと思います。

3. Slackアプリのイベントサブスクリプション

Slackアプリの受信Webhookと同様、https://api.slack.com/apps へアクセスしてSlackアプリを作成し、 Event Subscription を有効にして、イベントなどを設定します。
その後、アプリをボットとして常駐させることでSlackワークスペース内のイベントを監視し、イベント発生時には特定のURLに対して、イベントに関するJSONを送信します。

これは、イベントJSONを受け取ってその後の処理を行う独自のWebアプリ(Slackアプリ)を開発・運用するためのものであり、提供されている機能を利用するというスコープから外れるため、今回は対象外にしたいと思います。

Slack→他サービスへの連携まとめ

Slack→他サービスへの連携について結論をまとめると、こちらも他サービス側からSlackアプリが提供されている、もしくはワークフロー機能のアクションが提供されているのであれば、それを試してみるのが良いと思います。
ただし前述のようにアクション内容が限られているため、実際のユースケースに比べると不足していることがほとんどで、物足りなさを感じると思います。

それ以上のことをしようとすると、独自のWebアプリ(Slackアプリ)の開発・運用が必要になってくるため、途端にハードルが上がってしまいます。

まとめ

学んだことの整理

今回の記事を通じて、Slackと他サービスの連携について以下のようなことを学びました。

  • 現状のSlack連携では限界がある: Slackと他サービスを緊密に連携させようとすると、公式アプリやSlackの標準機能だけではカバーできる連携内容に不足を感じることが多く、細かなユースケースに対応できない。
  • 高度な連携には高いハードルがある: 標準機能の限界を超えて、より高度で柔軟な連携を実現するには、現状では独自のSlackアプリ開発・運用が必要となり、途端に非エンジニアや中小企業にとってのハードルが高くなる。

これらの点を踏まえ、Slackと他サービスとの緊密な連携を実現し、業務効率化を進めるための可能性として、次回は、iPaaSとは何か、さらに主要サービスのうち Zapier と Make(旧Integromat) の2つの比較をしていこうと思います。

新規CTA