部署横断の入社準備を、kickflowを使って統制した話

入社準備って大変ですよね。
ミスった時の業務インパクトも中々に大きく、どうにか避けたいところ。
ただ、「人事・労務・総務・情シス」と部署／役割間での連携があって、それぞれのゴール（責任範囲）が異なるため、漏れが発生しやすい。
弊社でもミスや漏れが多発したので、対策としてkickflowというサービスを利用して、入社準備をワークフロー化しました。
こんな方法もあるよ、と頭の片隅でも置いて頂けますと幸いです。

何をどうした

Before

・人事が独自のマスターデータを持っており、スプレッドシートへの転記が遅れがち（全情報が揃ってから書くから。気持ちは分かる）
・スプレッドシートが壊れるし、全部署で共用するからよくデグレる。
・必要情報だけ書き込むルールを作っても、風化して問題がループする

After

・氏名＆部署が確定した時点で人事が稟議を起票するので、トリガーが早い
・スプレッドシートへの書き込みは、Webhook＆GAS。（更新頻度が最低限に）
・内定→稟議起票という仕組み化のため、人が変わっても風化しにくい
　※サービス側で必要なデータ登録を強制するため、記載漏れも無い

解消した問題点と発生したメリット

■解消した問題
１：メール＆Slack通知により、対応漏れが無くなった。

以前は入社準備というチャンネルに人事が通知　→　各自でスプレッドシートを確認。という流れだったため、
自分でタスク管理＋リマインダーを設定する必要があった。
kickflowはメール＆Slack連携通知が標準で付いてくるので、通知が毎日届き作業忘れの防止に貢献。
↓トリガー毎の細かい設定が可能

２：人事からの連絡が爆速に　＝　余裕を持って対応できる。

そうなんです。氏名と所属部署さえ分かっていれば、それ以外は後からでも何とでもなるんです（ただし、当社比です）

３：スプレッドシートのデグレーション抑制

他部署と共有するシートに、手作業で書き込む事の怖さよ。
言った言わない
更新漏れ、更新ミス
壊れたんでバージョン戻しました　
からの
戻しすぎ問題
入社シートの増殖バグ（人災）発生。一体どれがマスタシートなんだ・・・
もう書ける事いっぱい。事件はスプシで起きている。

それがですよ。
kickflow上で各部署の入力データをWebhookでマスターシートに転記。
それを各部のシートに参照関数で持っていけば・・・ほら護身完成。
共通データはBOTに転記させて、各チームの個別データを
部署毎の別シートで運用すれば、お互いの聖域は守られます。

おまけ

今回利用したkickflowは、レゴブロックの様に自在にワークフローを作れる面白いサービス（個人の所感ですが）。
そこで、今回の改善にどう役立ったのか、一部ですが記載しておきます。

１：並列承認が出来る
以前利用していたWFサービスでは、平社員同士がお互いに承認する事が出来なかった。
例：自分より役職が上の、上長以上でないと承認者に指定出来なかった。
ところがkickflowだと承認フローを自由に設計可能なので、
平社員同士の承認経路などもOK。つまり
「職務権限規程」に該当しないワークフローが作れる。これは良い。

２：API連携が豊富
WebHookやRESTAPI完備。
”解消した問題”の”３”で記載した処理ですが、稟議完了後は以下の処理でGoogleアカウントの発行まで行っています
稟議完了　→　kickflowのWebhook　→　スプレッドシートへ転記　→　編集をトリガーとしてGAS発火　→　必要項目を人事シートへ転記＆GoogleAPIを利用してGoogleアカウント作成

RESTAPIは今回使っていませんが、何と稟議（kickflowではチケットという）を起票するAPIも完備されているので、kickflowを一度もログインする事なくワークフローを完了させる事も可能だったりします。
環境や組み合わせるSaasサービスを考えれば、より楽な運用方法が見つかるかもしれません。

kickflowを利用した別の改善を実現したら、またNoteに書こうと思います。

以上です。

ここまでお読み頂きありがとうございました。