Slackで勤怠打刻問題を解決！解決方法の違いで会社のカルチャーが作られていくよね
全従業員に何かをやってもらう、というのは実はすごく難しいです。規定にXXXというルールを書いても、それを全従業員にやってもらうようにするのは本当に大変。
かくいう私も勤怠打刻を忘れ、まとめて入力することもしばしばです。
これで困るのは管理者です。勤怠の場合は労務だったり、勤怠締めを行う上司だったりします。
今回は全従業員に毎日勤怠打刻をしてもらうという課題を解決していきます。
結論となりますが、本記事では最終的にSlackからKing of Time(勤怠システム)の勤怠打刻を行う方法を取っています。
なぜ人は毎日勤怠打刻できないのか
なぜ、打刻漏れが発生するのか？純粋に打刻を忘れる、勤怠システムにログインして打刻することが面倒ということが容易に想像できます。
この2つの原因をベースに考えると解決策は
原因1. 打刻という業務が面倒
→解決策 : 打刻をラクにする
原因2. 打刻を忘れる
→解決策 : 打刻を思い出す仕組みを取り入れる
という2つの施策が考えられます。
打刻をラクにする
まずこちらを考えていきます。通常、打刻を行うプロセスは、
1. 勤怠システムのURLを探す
2. ブラウザから接続する
3. ログインする
4. 打刻する
の4つの手順が必要です。
これをより簡単なプロセスで打刻することを考えていきます。まずは大きく自動と手動の2パターンでいくつか案出しをします。
- 自動
- PCの起動、シャットダウン、スリープ開始、解除を起点に打刻する
- 会社のPCが会社のSSID（Wi-Fi）に接続したら打刻する
- 手動
- 毎日使ってるツールからサッと打刻する
- SlackのSlash Commandから
- Google Chromeの拡張機能から
この中で自社のカルチャーに合わせて、社員が最も打刻してくれそうな案を採用します。
今回は開発するハードルの高さ（ノウハウの多さ）も考慮していったんSlackのSlash Commandからの打刻を開発し、その後、スリープを起点とした自動打刻を考えていきます。
実現方法を考える
Slackから打刻するというのはググればたくさん情報が見つかります。しかし、ここで考えないといけないのは費用対効果です。
選択肢としては以下のようなものが考えられます。
1. 自分で開発する
2. iPaaSを使う
3. 勤怠システムのオプション使う
4. そもそもシステムで解決せずに、従業員の努力してもらう
この中でどれを選択するか、がコーポレートITとしての違いがでますし、結果としてそれが会社のカルチャーとして作られていくと思います。
1番の場合は最終的にコーポレートIT部門内にシステム間連携のチームを作る方向に進んでいくと思います。このようなサーバレスでシンプルなシステムであれば片手間で運用可能ですが、それでもシステムが増えれば専任で担当をおいて、より積極的にテクノロジーで生産性を向上させる形になるでしょう。
2番の場合はより運用がより楽になるのでこちらも片手間運用可能です。ただし、iPaaSが対応しているクラウドサービスしか扱えないため、そこは注意が必要です。ほどほどに運用が楽で、ほどほどに生産性を向上させることが可能です。ただいろんなクラウドサービスに対応するためにiPaaSも複数することになったりするので、このあたりの注意が必要です。King of Timeの場合、国産のAnyflowというiPaaSで使うことができます。いわゆるZapierやIntegromatでは扱うことができません。..
3番は勤怠システムに依存します。今回はKing of Timeという勤怠システムを使っていますが、この場合、Slackでの打刻オプションは存在しません。
4番を取る企業さんが多いのかな、という印象です。どこまで従業員に寄り添うのか、どこまで規定ベースで努力をお願いするのか、どこまでテクノロジーを使ってなめらかにするのかはなかなか難しいところですが、やはりそこがカルチャーとなって形づくられるポイントかなと思っています。
今回私は1番を選択し、システムのアーキテクチャとしては、
Slack Slash Command + API Gateway + Lambda + Airtable + King of Time
という構成になりました。
Airtableは従業マスタの位置づけとなります。
技術的なあれこれ
素人プログラマーのため、よりよい書き方があれば教えて下さい
コマンド体系はいたってシンプルにしました。
/kotで出社、退社のどちらの打刻も可能
/kot breakinで休憩開始
/kot breakoutで休憩終了
King of TimeのAPIを使う際に気をつけないといけないことがあります。それはAPIの利用禁止時間が存在することです。
利用禁止時間帯
以下の時間帯（JST）はアクセストークン、打刻登録以外のAPIの利用ができません。
8:30～10:00
17:30～18:30
最初は打刻に必要なKing of Time内部のID（employeeKey）を毎回APIで取得するようにしていたのですが、上記の利用禁止時間帯になると打刻ができない現象が発生しました。
そのため、Slack IDとKing of Time内部のID（employeeKey）をAirtableに保存してそれを取得して打刻する仕組みにしています。Airtableは近い将来の従業員マスタとして利用を考えていたため、ここに保存することにしました。
運用はたいへん？
毎日なにかしら運用が必要なものはありませんので手間はかかっていません。サーバレスなのでいわゆるサーバ運用のなしです。現時点では従業員入社時にAirtableにIDを追記するというルーティンが発生しているのみ。これも自動化可能ですが、すでに私の手を離れているため、コードは書いていません。
Slash Commandが使えないときはWebから打刻するというシンプルな運用になっています。
課題に対する成果
社内のタイミングがよかったこともありましたが、結果として毎日勤怠を打刻するためのツールとして従業員の大半に使ってもらっています。
結果として企業の労務管理という課題はある程度解決できたのでは、と感じています。
この記事が気に入ったらサポートをしてみませんか？