従業員数約7,000名の企業に「Zapier」を導入できるか考えてみた。

普段から考えていること

KADOKAWA Connectedは「働く人々の生涯生産性を最高に高めるためのソリューションを提供する」ということに命を燃やしている。顧客の中心はKADOKAWAグループであり、利用者は約7,000名もいる。そんな彼らの生産性を爆上げしてやろうということをモチベーションにしながら、どんなことがサービス化できるかチームで日々考えている。ちなみに私たちにとってのサービス化とは、利用者の立場で価値がある事を考え抜いた上で、担当する利用者にとって価値がある最大公約数を発見することである。詳しくはKADOKAWA Connected Standardを見て欲しい。

「Zapier」の可能性を検討してみようということになった

その日、私たちEUCチーム*1はiPaaS（Integration Platform as a Service）のことを考えていた。世の中の動向として、異なる複数のシステムをAPIでつなぎ、業務効率化を実現する iPaaSの活用が目立っているが、KADOKAWAにはそれを実現する共通基盤が存在しておらず、システム毎にツール選定または開発をしているようだった。そんな非効率な状態の一部を「Zapier」で解決できないかどうか検証して、iPaaSの可能性を検討してみようということになった。そこで得られたことをブログに書いてみようと思う。

ちなみに、Zapierを選んだ理由は次の3点である。

• ユースケースなどの、参考情報がググれば豊富に見つかること
• 連携可能なサービスが豊富なこと
• 比較的安価であり検証コストを抑えられること

Zapierとは

あらめて説明するがZapierは複数の web アプリケーションを連携してワークフロー化できるサービス。具体的には、webサービスでのイベントをトリガーとしてワークフローを開始し、ワークフロー内で他のサービスに対してリクエストを送信する。GUI ベースでコーディングも不要なため、いとも簡単にワークフローを作成できる。それにより日々の定型作業のような業務を自動化することができるのだ。

例えば、以下のような自動化を実現できる。

• Gmailでのメール受信を Slack 通知する
• 特定のキーワードで Slack に投稿すると Jira のチケットを起票する
• 新しいGoogleカレンダーのイベントを自動で Jira にチケットを起票する

このように比較的にシンプルな自動化であれば、数分〜数十分程度で作成できてしまうのだからビックリである。

私たちの悩み

繰り返しになるが、Zapierはノンプログラミングでワークフローを作成できるツールなので利用者に高いITスキルを求める必要がない。プログラミングの知識をがない人でも、要領さえ掴めば数分で目的にあったワークフローを簡単に作成できるので、 インターネット上でも非エンジニア系企業での活用事例を目にすることが多い。

先に言っておくと、Zapierを自由に使えるような環境をすべてのユーザへ提供することはしないと思う。KADOKAWAも環境が用意されればイノベーターやアーリーアダプターがきっと興味を示すに違いないが、Zapierは自由度が高い分、使い方によっては機密情報を日常的に外部に漏洩してしまったり、間違ったデータを集計して報告してしまったりするようなケースがでてきてしまうだろう。またサービスを提供した後の運用・保守を務めるチームのことも心配だ。

以前こんなことがあった。とあるデータベースソフトウェアはGUIの簡単操作で、さらに様々なシステムとの連携も容易だったことから重宝された。そのため、データベースソフトウェアの知識があった担当者は、それぞれ独自にデータベースをつくり業務の中心において運用していたが、その担当者が退職するとメンテナンスができない状態となり、私たちが所属する組織のEUC関連のチームで結局引き受けることになった。追加データの登録や削除など、運用自体は大きな問題もなく各組織で行われていたデータベースだったが、クライアントOSの要件がWindows7でなければならないケースやデータのバックアップが取れていない（取れていても同じサーバのローカルに置いている）ことが増えてきた。そんな状態だったため、保守を担当するチームはリスクを考え、データ保全性の確保と信頼性の高い標準的なデータベースやプラットフォームへの移行を進めることを決めた。存在していたデータベースのいくつかは役目を終えていたため事情を説明し、廃止することができたが、いまだ運用されていたデータベースに関しては対応が難航し、関係者への説得や移行先システムの検討に時間を費やしてしまった。

同じようなことがZapierでも起きると確信している。例えば「ワークフローが動かなくなった。作成した人は退職してしまったので面倒を見て欲しい。」と言われたとする。あらかじめ「サポートはしない」といった断りをしていたとしても、困っているユーザから相談されたら無下にはできない。しかしワークフローの中身を見てみると「……なんだこの無駄に複雑なワークフローは」と仰天し、対応に想定以上の時間を費やす。こういった相談は少ないうちはまだなんとかなるが、これが無数に増えていってしまうと対応しつづけることは困難を極める。ただでさえ、効率化を考え実現したいことはユーザそれぞれで異なり、連携したいアプリやワークフローの組み方も微妙に違う。そんな三者三様のユニークな作品に対して、運用・保守を提供しつづけることはチームにとっての大きな負担になるだろう。誰でも簡単にワークフローを作成できるZapier。それを自由に使えるような環境をすべてのユーザへ提供することはないと思う理由はこんな未来が想像できるからである。

しかしその一方でZapierは業務を自動化させ、多くの効率化を実現させる可能性がきっとある。それがわかっているから、私たちは管理とユーザへの開放のバランスを模索している。Zapierは連携可能なアプリが豊富のようだが、実際にアプリと連携することで何が可能となるのだろう。安定して動くのか、制御・管理に役立つ機能はどのようなものがあるのか等はまったくわからない。それを知るために検証が必要だった。

調査・検証してみた

Zapier でできるユースケース

今回の調査・機能検証から、いくつか実現可能なユースケースを検討してみたのだが、以下のような自動化・可視化は大きな効果が期待できそうだという結論になった。

• チームや全社のGoogleカレンダーに対象メンバー全員を自動招待する
• Slack の特定チャンネルに問い合わせが投稿されたら Jira / Asana などのチケット管理ツールに自動起票する
• Slack の特定チャンネルでの問い合わせに対する一次対応までの時間を集計して Datadog で可視化する

Zapier は業務自動化のツールとして扱われることが多いようだが、他にも社内の様々な活動に対する KPI の取得・可視化にも活用できそうだ。様々な ダッシュボード系サービスとの連携も対応しており、実装も容易だ。このあたりは放っておいても鼻が利く技術者たちが見つけて、KPI 取得の仕組みを各チームで導入していくだろう。また今回は活用しなかったが、単純なサービス連携だけでなく、ワークフロー内で固有の処理を実行できる。条件分岐、文字列の加工・抽出、演算などを組み合わせて処理できる点が、Zapierがイケてるサービスだと支持される理由なんだと思う。

連携先となるサービスが、細かい条件でのトリガーを提供していないことは少々残念だったが、他サービスに連携する際に「特定の箇所だけ抽出したい」といったケースは拾うことができた。他にもエンジニアの知識が必要になるものの、webhook の送信や受信、ワークフロー間で共有可能なストレージ機能 (KVS)、Python/JavaScript によるコード実行などにも対応している。

Zapier で難しいユースケース

様々な業務の自動化を簡単に実現できる一方、Zapierには特性上実現が難しいユースケースもある。例えば以下に記したものは、一定の効果が期待できるものの、実現できなかったユースケースである。

• Slack の過去の発言を集計して可視化する
• Slack 上で ワークフローを呼び出すと自動で Atlassian のスペースを払い出す
• Slack 上で過去の発言のリンクを投稿するとその発言を削除する

つまり、Zapier はイベントドリブンでのサービス連携を想定した設計になっている。そのため過去の情報を集計するような連携機能はなく、検証したいくつかのサービス連携において複数件のリソースの同時取得はできなかった。リスト系の処理と比較的親和性の高い Googleスプレッドシートでも、一度のリクエストで20行までの検索が限度であった。他にも管理機能の自動化や委譲ができれば管理業務がスケールしやすくなると考えたが、管理者業務を自動化できるような連携機能も提供していないようだった。 

どのプランを契約するのが良さそうか

以下の点から、全社または複数のチームへの提供を想定している場合は Company プランが適当だ。

• 複数のチームを作成可能で、チーム単位での権限管理が可能なため、棚卸しがやりやすい
• ドメイン単位での利用制限が可能なため、グループ会社の他社員や業務委託のユーザによる利用も制限しやすい

Company プランは他にも SSO やユーザプロビジョニングにも対応しており、全社展開の際はこれらの機能も有効だろう。

ガバナンスを効かせるためにはある程度運用でカバーする必要がある

Zapier は使い方を間違えると社内の情報を SNS へ通知してしまうなどのセキュリティ上のリスクが存在する。ノンプログラマーでも簡単に扱えてしまうことで、その分人為的エラー（連携ミスや知識不足）による事故は起きやすいかも知れない。Zapierはこういった懸念を吹き飛ばしてくれるだけの機能が現時点では見当たらなかった。具体的には以下のような懸念点が存在する。

連携サービスの制限がブラックリスト形式のみ

Company プランでは連携対象のサービスを制限することができるが、ホワイトリスト形式ではない。連携対象サービスは 2000 以上あるため、例えば調査済みのサービスのみ許可する、というような制限の仕方は運用上難しい。

このような場合、管理者機能でワークフローで連携しているサービス一覧を定期的にチェックするなどの運用でのカバーが必要だ。

Private Folder 下のワークフローは検閲が困難

Zapier では、実装したワークフローを Private Folder / Shared Folder のどちらかに格納することができる(Teamプラン以上) 。Private Folder に格納されたワークフローは管理者からも確認できないため、例えば組織的に許可していないサービスとの連携を行っていることを把握しづらい。Shared Folder でも他の一般ユーザへのアクセス制御は可能なため、 Private Folder を利用しないようなポリシーを設けることやポリシーに反するようなワークフローの実行を自動検知する等の仕組みを導入する必要性を感じた。

一般ユーザでもメンバー追加が可能

運用ではガバナンス上の問題から特定のユーザのみにアカウントを発行したいようなケースがある。しかし、ユーザの招待には管理権限が不要なため、定期的なチェックや自動検知などの仕組みでカバーが必要だ。

まとめ

検証を終えてZapierについて少し知ることができた。いくつか懸念はあるが社内に展開することは可能だと思う。その機能は一部の課題を解決できそうだと思ったし、それはすぐに叶えることもできそうだ。でも、私たちが求めている安心安全に使うためにはどうしても制御・管理機能が足りていない。いや、仮に足りていたとしても車の運転と同様に、ルールが整備され、利用者にマナーが定着している必要性を感じる。どちらにしても「どうぞ自由に使ってください」というのはムリだ。

Zapierの場合、足りていない部分は運用ルールをつくり、利用を支援する仕組みが必要だと思う。そしてルールやマナーが守られているかを日々モニタリングし、時には注意をすることが安心安全の支えとなるはずだ。でもこうした活動があまりにも多くなってしまうと管理者の負荷が高くなりつぶれかねない、安定した継続的運用が難しくなる。そうならない為には、部分的であっても人の手に頼った仕組みでの運用は避けないといけない。幸いZapier には外部サービス連携以外にも Zapier 自身の管理用のアプリがいくつかあった。それを使い、管理用のワークフローを作成し、統制が必要なイベントを自動検知していくなどの運用効率がポイントだと考える。もちろん利用者自身にも手放し運転は危険だという認識をしっかりと持ってもらう啓蒙活動も大切だ。

ということで、次のようなルールをつくり試験運用してみようと思う。まず、利用者（Zapierでワークフローを作成していい人）は、システム連携におけるリスクを理解しやすいエンジニア層に限定する。連携できるサービスも会社として契約しているものや申請による許可制として広がり過ぎないようにすることにした。一般ユーザに対してはエンジニアが作成した汎用的なワークフローの提供や、リクエストをもとにしたワークフローの提供によってZapier体験をしていただくつもりだ。試験運用はこのくらいが丁度いい。

その他にもいくつかルールとマナーとして決めたことを次の表にまとめてみた。

項目	試験運用中	将来的な検討
利用者（ワークフローを作成していい人）	制限する 申請による許可制 利用期間を定める	制限範囲を緩和する 　　or さらに限定を厳しくする
連携できるサービス（アプリ）	制限する 申請によって許可したもの 会社契約しているサービス（アプリ）	-
費用	無料	従量課金（使用したタスク分を利用部門に請求）
利用者の棚卸し	月に一度行う 許可していない利用者のチェック 利用期間切れの利用者の削除	-
ワークフローの棚卸し	月に一度行う 許可していないワークフローのチェック 利用していないワークフローの停止	-
アプリの棚卸し	月に一度行う 許可していないアプリのチェック	-
禁止事項	プライベートフォルダでワークフローを作成しない メンバーを追加、削除しない 許可されていないシステムとの連携をしない 許可されていないアカウント認証をしない	-

Zapierにとって、利用者や連携サービスを制限することはメリットを捨てたと言われるかもしれない。しかし、Zapierは超簡単だからこそ、それらを制限しなければルールやマナーが守られないでつくられた"野良ワークフロー"がものすごい数生まれてしまうだろう。サービスを運用する側に立たれている読者の方はわかると思うが、そうなったときの保守は地獄だ。あらためてサービスは「利用者が安心安全に使え、且つ安定した持続可能な運用であること」であるべきだと思う。

これから数か月くらいZapierの可能性を試してみる。何事もうまくいくかなんて試してみないとわからないが、うまくいくように手を加えることを繰り返してみる。「やってみて、やってダメなら変えてみる。」が私たちのモットーだ。結果はまたブログで報告するので気になる方は次回を待っててほしい。それではまた。

*1:EUC...エンドユーザーコンピューティングの略称。KADOKAWA ConnectedのEUCチームは、KADOKAWAグループの従業員に対して、業務生産性最大化とEmployee Experienceの向上を目的として、利便性とガバナンスのバランスがとれたICT基盤（PCやSmartPhoneなどのデバイス、GoogleWorkSpaceやSlackなどの各種サービス、アカウント管理など）を提供しています。また、サイバーセキュリティサービスもグループ内に提供しています。