こんにちは！情報システム部の久保です。
アジアクエストでは、2023年1月からワークフローシステムのkickflowを導入しました。
この記事では、kickflowの紹介と、導入してみた感想、苦労した点などをまとめていきます。
筆者は、アジアクエストの情報システム部で各種SaaSやセキュリティ製品の導入や運用を担当しています。
これまでに導入に携わってきたものの例としては、SmartHR、Okta、AWS Client VPNなどがあります。
AWS Lambda / GAS / iPaaSなどを使ってツールの開発も行っています。 こんなのも作りました。
Slack + GAS + Google Driveで脱PPAPツールを作ってみた
kickflowについても、ワークフローシステムの製品選定から導入までをメイン担当者として行いました。
様々な企業の情シス・コーポレートエンジニアの方が集まる『情シスSlack』というコミュニティがあります。
※『情シスSlack』はこちら
私も情シスSlackに参加させていただいているのですが、Slackワークスペースの中で日々様々な質問・相談・情報共有などが行われています。
そんな『情シスSlack』の中で、「kickflowってどんな感じ？」という趣旨の投稿を以前からたまに見かけていました。ワークフローシステムの中では世の情シスの方たちがかなり気になっている製品なんだと知り、自分自身も導入前は気になっていたこともあり、導入した身として一度しっかりとまとめて世に発信しておこうと思ったことがきっかけです。
また、気になっている人がいる割に、kickflowの具体的な機能の内容にまで踏み込んで書かれているブログがあまりないなと感じたことも理由の1つです。
kickflowの簡単な紹介です。
クラウドで提供されている稟議ワークフローシステムです。
公式HPにも書いている通り、設定の柔軟性やシステム連携のしやすさを強みとしている製品です。
スタンダードプランとエンタープライズプランの2種類があります。
以前はスモールプランというさらに下位のプランがありましたが、現在はHPからはなくなっているようです。
アジアクエストではスタンダードプランを契約しており、本記事の内容も特に断りのない限りはスタンダードプランを前提としています。
具体的な内容に入る前に、kickflowで使われる代表的な用語について簡単に説明しておきます。
ワークフロー：申請のテンプレートのようなもの。申請する際の入力項目やどの承認経路を使用するかを定義する。
経路：承認経路のこと。kickflowではワークフローと経路が分離されており、1つの経路を複数のワークフローで使いまわすことも可能。
チケット：申請書のような意味合い。ワークフローから作成される1つ1つの申請を指す。
フォルダ：ワークフローや経路などをまとめておく箱のようなもの。
kickflowの機能については、HPにある機能一覧を見ると大まかなイメージが掴めると思います。
概要についてはそちらに任せ、この記事では個人的に良いと思っている機能について利用者目線でいくつか紹介していきます。
「いきなりこれかよ」という感じですが、個人的にkickflowの大きな特徴はここだと感じています。
API仕様書を見て分かる通り、提供されているAPIがかなり充実しています。
GUIでできるアクションのほとんどはAPIでもできる印象です。
逆にAPIではできないことの代表例としては、ワークフローや承認経路の作成などでしょうか。ただし、これらをAPIで自動作成したいというケースはあまりないような気がします。
他のワークフローシステムだと、そもそもAPIが公開されていなかったり、参照系のアクションしかできないような製品が多く、FaaS / iPaaS等を使用したシステム連携をしたい場合、かなり苦しいのではないかと思います。
管理者ロールを細かく切れる点もkickflowの良さだと感じています。
kickflowでは、特定の対象の管理権限だけを持つような管理者ロールを自分で作ることができます。
例えば、監査担当者にはチケットの閲覧権限と監査ログの管理権限だけを持たせる、といった具合です。
また、ワークフローやチケットの中でも特定のものだけを管理する権限を与えることもできます。例えば、部署の担当者ごとに管理者ロールを作成してその部署に関連するチケットだけを閲覧させる、といったことも可能です。
事前定義された数種類のロールしか使用できないサービスもある中で、このように柔軟に権限を設定できるのは統制面で大きなメリットがあると思います。
特定の条件に基づいて承認経路を変更したり、特定の条件に該当したら申請を拒否するようなことができます。
例えば、下記のようなことができます。
画面イメージ
上記の画面イメージの例は非常にシンプルな条件設定ですが、下記のようなこともできます。
代理申請・代理承認どちらも可能ですが、アジアクエストでは主に代理承認を活用しています。
承認者の休暇中に承認が滞らないように、代理で別の人が承認できるようにしたいというニーズはどの企業でもありそうです。
画面イメージ
代理期間の設定をすることで期間限定にできたり、対象のワークフローを限定することで代理承認権限を一部ワークフローに限定できます。
特に代理期間の設定は、承認者が休暇から戻ったときの設定の戻し忘れを防ぐという意味でも非常に重宝しています。
細かい機能も1つ紹介しておきます。
作業中モードは、チケットの申請や承認を一時的にブロックできる機能です。
ちょっとした機能ですが、管理者にとってはありがたいです。メンテナンスが必要になったときや、大規模な組織変更時に一時的に申請させたくない場合などに使えます。
作業中モードを有効化すると、ユーザー側から見ると、一時的に申請や承認がブロックされる旨が表示されます。実際に申請や承認をすることもできません。
1つ1つ書くと長くなってしまうので割愛しますが、その他にも多くの優れた機能があります。
他にどのような機能があるかについては、公式HP等をご参照ください。
また、クラウドネイティブさんのこちらの記事もおすすめです。
ここからが表題の導入体験記です。
アジアクエストでは、kickflow導入前も別のSaaSのワークフローシステムを使用していました。
しかし、APIが公開されていない、管理者の権限設定粒度が粗い、Slackから承認ができないなどの問題があり、ワークフローシステムを更改しようということになりました。
3製品程度に絞り込んだ後に選定を行い、kickflowに決定しました。
kickflowを選んだ理由は色々ありますが、アジアクエスト的には以下の4つが大きかったです。
導入作業の中でkickflowに対して良かったと感じたことを紹介します。
kickflowの機能に関しては先述しているので、ここで紹介するのは機能以外のお話です。
営業の方が1人ついてくれて、Slackベースでサポートしていただけました。アジアクエストで導入したときには機会がありませんでしたが、必要な時にはZoomでのサポートもしていただけるとのことでした。
「他社製品との比較表ください！」「導入稟議のための材料ください！」など、かなりわがままな頼り方をしてしまいましたが、いずれも親切に対応してくれました。
具体的な機能に関して質問がある場合はサポート窓口にリクエストを投げる形ですが、そちらもレスポンスが非常に速いです。質問の内容にもよりますが、ほとんどのリクエストはその日のうちに回答をいただけました。
検証・導入作業を進めていく中で「こういう機能があったらいいのにな」と思うことはよくあると思います。
私も感じたことは頻繁にフィードバックしていたのですが、いくつかは既に実現していただけました。
一例としては下記があります。
そもそも新機能の追加やアップデートが頻繁に行われており、その中で自分たちの要望も叶えられることがある、という感じでした。
機能アップデートページを見てもアップデートのペースが分かると思います。 多くの企業から要望が上がっている機能から順に実装されていくとは思いますが、導入後も改善が期待できる製品だと感じます。
導入にあたって苦労した点もありました。
かなり具体的な話をするのでkickflowを触ったことがない方からするとよく分からないところもあるかもしれませんが、雰囲気で読んでいただけると幸いです。
kickflowでは、組織図を作成し、組織図内のチーム（部署）を経路内のステップの承認者として指定することができます。また、チームとは関係なく個別に承認者を指定することもでき、この方法で複数人を1つのステップに入れることも可能です。
経路を設計する中で、複数部署から1人ずつを同じ承認ステップに入れたいケースがあり、組織図と承認経路に入れたいチームが一致しないということがありました。
この場合、ユーザーを個別に指定してもよいのですが、多くの経路でそれをしてしまうと、経路に入れるメンバーに変更があった場合に全ての経路で修正が必要となり、余分なメンテナンスコストがかかってしまいます。
このような背景があってどのように設定するか迷いました。最終的には正規の組織図とは別に承認用のチームを作り、組織図上は兼務している形にすることで対応しました。
kickflowのフォルダは下記のような用途があります。
①申請者がチケットを作成するとき、フォルダを指定してワークフローの絞り込みを行う
②「このフォルダ内のワークフローはこのチームのみ申請可能」のように、フォルダ内のワークフローから申請できる人を特定のチームに限定する
③管理者ロールで管理できる対象のワークフローやチケットを特定のフォルダ内だけに限定する
フォルダ体系の設計をする中で、「上記の用途のいずれかを優先すると、他の要件が満たせない」というような状況になってしまいました。
最終的には①と③を重視し、②は諦めました。
②に関しては前述の「承認経路の自動分岐・申請拒否」機能で、特定のチーム以外から申請された場合に拒否する機能で代用しました。
スタンダードプランでできること・できないことは料金プランを見て分かっていたつもりでしたが、思わぬ制限があったりしました。
一例を上げると、スタンダードプランでは管理者ロールは10個までしか作成することができません。
「システム運用担当」「監査担当」「経理担当」など、細かく管理者の役割を定義していき、それぞれに最小権限を与えるということが理想でしたが、一部は妥協してまとめるなどしました。 （それでも他製品と比較すると十分な粒度の細かさで役割定義は出来ると思います）
また余談ですが、スタンダードプランではSAMLが使えないのも痛いですね。
最上位プランでないとSAMLが使えないSaaSはよくあるので仕方ないですが、スタンダードプランでもSAMLが使えるようになると個人的にはもっとkickflowのことが好きになる気がします。
苦労した点は色々ありましたが、特別大きなトラブルもなく導入を完了することができました。
製品選定を開始したのが2022年7月頃なので、導入に向けて動き出してから本番稼働までの期間はおよそ半年でした。
導入期間は組織の規模や状況にもよりますが、1つの目安としていただければと思います。
※ちなみにアジアクエストは社員300人程度の規模の企業です。
kickflow自体の使いやすさやサポートしてくださったkickflow社員さんの親切さもあり、導入担当者としての満足度は非常に高かったです。
社員からも、Slackから承認できることや承認が早く完了することで便利になったという声が聞かれました。
個人的には素晴らしいワークフローシステムだと感じたので、導入を検討している方にはまずは一度トライアルを申し込んで触ってみてほしいなと思います。
「他の業務にも追われており、十分に検証の時間を割けないままトライアル期間が終わってしまうのではないか？」という懸念をお持ちの方もいるかもしれませんが、トライアル期間の長さも柔軟に対応してくれる可能性があるので、一度相談してみることをおすすめします。
特に下記のような企業にはおすすめできます。
逆に、あまりおすすめできないと感じるのは下記のような企業です。
kickflowが気になっている方に、雰囲気だけでも伝われば幸いです。 ここまでお読みいただきありがとうございました！