SaaSをつなぐSaaS「Zapier」と、SaaS APIエコシステム

どうも、エンジニアのgamiです。

僕の仕事の1つに、プロダクトに対する問い合わせの調査フローを改善するというものがあります。

僕はいまSaaSプロダクトを提供している会社にいて、社内外から日々多くの問い合わせが飛んできます。問い合わせしてくる人は、たとえば「この機能が思ったように動かない」という問題を抱えています。その問題の原因は、バグ、不親切な仕様、ドキュメント不足、利用者の知識不足、など様々です。こうした原因の切り分けをし、必要に応じて適切なチームにエスカレーションするのが、僕の仕事の1つです。

先日、このエスカレーションにおける通知フローをZapierを使って自動化しました。具体的には、GitHubでissueにラベルを付けたら、関連する開発チームにSlackでメンションが飛ぶといったフローです。

Zapierは僕の大好きなサービスの1つで、各種SaaSの機能をつなぐような自動化をまさにNoCodeで実現できます。今回は、僕が実際に体験した自動化を紹介しながら、ZapierのようなiPaaSと呼ばれるサービスとSaaSのAPI エコシステムについて考えます。

業務はSaaSを横断する

ご存知のように、近年の業務アプリケーション業界はSaaSプロダクトが席巻しつつあります。僕も仕事ではSlackでコミュニケーションを取り、GitHubでタスク管理し、esaやNotionにドキュメントを書いています。

DXの文脈の中で、SaaSシフトの重要性も叫ばれています。一方で、SaaSプロダクトを個別に導入しただけでは業務のアジリティは頭打ちしてしまいます。なぜなら、業務は複数のSaaSを横断して行われるからです。

たとえば僕が今回取り組んだ問い合わせのエスカレーションでも、タスク管理やissueベースのコミュニケーションはGitHubで、通知や日々のコミュニケーションはSlackで、開発チームの機能担当表の管理はGoogleスプレッドシートで行われています。素直に業務を実行するなら、次のようなフローになります。

1. GitHubのissue上で問い合わせ内容が僕にメンションされる
2. 僕はGitHubの通知からそれに気付き、原因を切り分ける
3. 対象の機能に対応する開発チームをGoogleスプレッドシートの担当表から探す
4. 担当の開発チームが属するSlackのグループメンションを使ってエスカレする
5. 開発チームのメンバーはGitHubのissueを見てより詳しい調査やコード修正などを行う

このように、複数のSaaSを横断して業務が進みます。こうした業務を効率化するには、複数のSaaSをつなぐような自動化が必要になります。

たとえば通知の自動化。複数のSaaSを業務で使っているとしても、それら全ての管理画面を定期的に巡回するのは大変です。SlackとGmailとGitHubとNotionの全てを1時間毎に見て回っていたら、日が暮れてしまいます。たとえばSlackやGmailで全ての通知を受け取れるようにすれば、それらの画面を入り口として別のSaaSにおける重要な情報にもすぐに気付くことができます。

Zapierはこれをどう自動化したか？

今回実現したい自動化フローは、次のようなものでした。

1. エスカレしたいGitHubのissueに機能別のラベルを付ける
2. その機能を担当する開発チームをGoogleスプレッドシートの担当表から特定する
3. その開発チームにGitHub issue URLを含めてSlackでメンションする

こうした3つのSaaSをつなぐような自動化は、どのように実現すべきでしょうか？

多くの優れたSaaSプロダクトがそうであるように、GitHubもSlackもGoogleスプレッドシートも、WebhookやAPIなど外部連携のための汎用的な仕組みを持っています。たとえばGCPにサーバーを立てて、GitHubのWebhookを受け取り、SlackやGoogleスプレッドシートのAPIを叩くようなコードをデプロイすることで、上記の自動化を実現することもできるでしょう。

しかし、それはあまりにも面倒くさい作業です。「Googleフォームの入稿を自動化した話」にも書いたように、エンジニアだって楽がしたい。管理するサーバーやプログラムを増やすことは、できれば避けたいところです。

そこで、Zapierの出番です。

Zapierでは、1つの自動化ルールのことをZapと呼びます。Zapには、トリガーとアクションを設定します。あるSaaS上で発生した出来事をトリガーに別のSaaSを操作（アクション）するといったSaaS横断の自動化を、簡単に実現できます。

たとえばGitHubで新しいissueが作られたことをトリガーにしたければ、Zap上でGitHubコネクタを選んで設定するだけで実現できます。

Slackコネクタをアクションに登録すると、Slack通知のメッセージ内容をフォームから編集できます。たとえばGitHub issueのURLなど、前段のGitHubトリガーに関連する情報も動的に差し込むこともできます。

このように、Zapierに登録されたSaaSプロダクトであれば、GUI上の設定だけで簡単に連携できます。各種SaaSの詳しい外部連携仕様を知らなくてもこうした自動化ができるのは、本当に画期的なことです。

ちなみに、今回僕が実現したかった「GitHub issueに特定のラベルが付与されたら関連チームにSlackに通知する」という自動化は、トリガーとアクション3つをつなげたちょっとだけ複雑な設定が必要でした。

1. [トリガー] GitHubからissue関連のWebhookを受け取る
2. [アクション] 「あるprefixが付いたラベルが付与された」ときだけアクションが起動するようにフィルターする
3. [アクション] ラベル名でGoogleスプレッドシートの担当表を検索し、担当チームに対応するSlackメンションを取得する
4. [アクション] 取得したSlackメンションを差し込んでSlackに通知する

ちなみに現在Zapierでは無料プランも提供されていて、すぐに触ってみることができます。気になる方はどうぞ。

iPaaSの流行とSaaSエコシステム

さて、APIを通じたシステム連携やエコシステムについてはこれまでにもnoteに書いてきました。

コンピュータの方が得意な定型業務は、こうした世界中のシステム同士のAPIを介した双方向の「会話」によって、24時間休むことなく実行されているのです。

サービスがAPIを介して相互に連携し価値を高め合っているような状態のことを、APIエコシステムと呼ぶことがあります。マネーフォワードと金融サービスとの連携は、まさにAPIエコシステムを考える格好の題材と言えます。

特にSaaSの世界では外部システムから機能を利用するためのAPIセットを整備することが一般的になりつつあります。日々の業務はSaaSを横断し、SaaSを横断した自動化が当然のようにユーザーから要求されるからです。

こうしたSaaS APIエコシステムは、Zapierのようなプロダクトの登場によってさらに盛り上がりを増しています。ちなみにZapier的なプロダクトは、iPaaS (integration Platform as a Service) と総称されることがあります。クラウドサービス間連携を実現するためのプラットフォームが、それ自体クラウドサービスとして利用できるようになっているわけです。代表的なiPaaSは、次の通りです。

・IFTTT
・Zapier
・Workato
・Power Automate (Microsoft)

こうしたiPaaSは、「どれだけ多くのサービスと連携できるか」を競い合っています。たとえばWorkatoのIntegrationsページを見ると、500以上の連携先サービスが掲載されています。

こうしたiPaaSの連携先を眺めていると、そのほとんどがSaaSであることに気付きます。これにはどのような意味があるでしょうか？

まず、SaaSプロダクトを提供する会社にとっては、APIを整備しiPaaSの連携先に掲載してもらうことが重要な戦略の1つになります。顧客企業の業務がiPaaSによるSaaS間連携を前提に構築されるようになると、このAPIエコシステムにのっていないSaaSプロダクトは検討から外されるようになります。こうした力学によって世界中のSaaSは自らAPIを公開し、iPaaSはそれらをつなぎ、ユーザーの便益は増していきます。

次に、システムを利用する企業にとってはどうでしょう？まだSaaSシフトが進んでいない企業は、自社の独自システムを相互に連携する度に独自の開発を強いられます。なぜなら標準的なSaaSと違って独自開発のオンプレシステムは、iPaaSの連携先リストには載っていないからです。もちろん、iPaaS側の汎用的なコネクタによって、生のHTTPリクエストを独自システムと交換できることも多いです。しかし、抽象化されていない分だけ連携設定のハードルは上がるでしょう。SaaSシフトが進んでいる企業と進んでいない企業では、業務の効率化にかかるこうしたコストに差が出てきます。iPaaSが加速するSaaS APIエコシステムの発達は、利用企業のSaaSシフトを進める外圧へとつながります。

というわけで今回は、Zapierの機能からSaaSのエコシステムについて考えてみました。自動化の文脈ではRPAという言葉もよく聞きますが、あくまでSaaSシフト以前の過渡期の技術であるというのが僕の印象です。SaaS APIエコシステムが支配的になった世界では、とりあえず標準的なSaaSに乗っかることが組織のアジリティを上げる最も簡単な手段となるのです。