Slack×GASで作った勤怠Botの話#1
UG Advent Calendar 2020の1日目の記事です。
どうもbarusuです。知らない方は初めまして。
今回は私が所属している会社の非公式アドベントカレンダーを勝手に作ったのでバシバシ書いていこうと思います。
2020年は仕事やらイベントやらに追われてなんもアウトプットできてなかったんで、12月くらいは頑張ろうと決意した次第。
とは言ってもまーそんな大した話じゃないので気楽に読んでください。
フィクションと思って読んでいただければ幸いです。
ということで本題。
GAS × Slack で勤怠Botを作った話 #1
2020年5月。
良くも悪くもコロナ禍による新しい生活様式が定着しはじめた頃のお話。
―――――――ちょっとさ、勤怠システム作れない?
すべては法務部長の一言から始まった…
全10話分の1話目となります。
2020/12/01:導入,初期の要望 ← 今日はココ
2020/12/02:設計
2020/12/03:構築その1 :SlackBotを作る
2020/12/04:構築その2 :GASを書く(基本メソッド編)
2020/12/05:構築その3 :GASを書く(ユーティリティ編)
2020/12/06:構築その4 :GASを書く(機能実装編:打刻処理)
2020/12/07:構築その5 :GASを書く(機能実装編:リマインド機能)
2020/12/07:構築その6 :色々書く(機能実装編:ユーザー管理機能,勤怠修正機能)
2020/12/08:構築その7 :関数とか色々(書ききれなかったやつまとめて)
2020/12/09:単体,ユーザーテスト
2020/12/10:そして伝説へ...
前置き
・都内某Web系企業
・正社員100名ちょい + 業務委託50名ちょい
・Gsuite,Slack,Salesforceなど使ってる
・部署として情シスがない(社内インフラはバックエンドエンジニアが片手間で管理してた)
登場人物
・Barusu:週4日*4hで稼働中。インフラ、セキュリティ、情シス運用、その他すべての問題の相談と解決策の提示をする
・法務部長:IT知識は勉強中、予算関連、IT導入に関する相談によく乗ってくれる
・チーフエンジニア:福岡からリモートで稼働している。
・エンジニアA:新卒3年目。寝食忘れてコーディングする変態。
・エンジニアB:新卒2年目。理系。
いきさつ ~どうしてこうなった~
喫煙所での会話から始まった(2020/05/某日)
法務部長
「あーおつかれ」
Barusu
「おつかれっすー。相変わらず忙しそうですね」
法務部長
「Barusuくんもね。リモートワーク関連の整備ありがとう。助かった」
Barusu
「いえいえー」
法務部長
「ところでさ、すげー忙しいのは重々理解してるんだけど、相談したいことがあるんだよね」
Barusu
「そこはお互い様だと思いますけどw …なんでしょ?」
法務部長
「ちょっとさー、業務委託や派遣さんの勤怠管理ができてなくって。今ってほらリモートでしょ?」
Barusu
「あー前に軽く話してたやつっすね…そこどうしましょうかね。考えなきゃですもんねー」
法務部長
「月末になってから、実は今月残業多かったので請求額が上がりますとか言われちゃうこともあってさ、これマジで困ってるのよ」
Barusu
「なるほどー確かにそれは問題ですね。でもそれって派遣元や所属会社が管理すべきものですよね?」
法務部長
「そうなんだけどね。派遣元が出してくる勤怠の表って紙な上に押印が必要なのよ。それだとあとからしか時間がわからないし、弊社としては照合できる材料がないから、それも問題だなと」
Barusu
「ははーなるほど… (要旨をなんとなく察する)
つまらん解決策になりますけど、ジョブカンとかそういう勤怠管理のSaaSを契約するのはだめなんすかね?」
法務部長
「それなら手っ取り早く解決できると俺も考えてるんだけどね。正直、現状では予算が厳しい。
月数万くらいだろうけど、コロナ関連での予算外歳出があったしかなり厳しい。
今ほら、案件なくて空いてる若手いるじゃん?そっちにお願いして内製してもらえばノウハウもたまるし。どうかな?」
Barusu
「むむむ。。結構手間とコストかかっちゃいますけどいいんですか?」
法務部長
「業務として切り出せるし、さっきも言ったけどノウハウ蓄積の一環として事業にも少なからず意味はあるからさ。
SaaS契約して終わりでも良いんだけど、なるべく若手エンジニアが「やりたそう」なことを提供したいって気持ちもあってね。
そこで、Barusuくんには監修をしてもらいたいんだよね。知恵を貸してほしい」
Barusu
「そうですか…
まぁとりあえずやるしかないっすね。馬なんで」
法務部長
「何言ってるかよくわからないけど、とりあえず△△事業部のエンジニアA,BさんとチーフエンジニアのCさんに声かけとくから要件定義のMTGしよう」
Barusu
「らじゃっす」
その後要件定義MTGできまったこと(ざっくり)
スケジュール
5月:要件定義、技術選定、基本設計
6月:構築、テスト、改修
7月:運用テスト
8月:リリース
要望
・業務委託の勤怠を把握したい
・リアルタイムで残業量を把握し、予測を立てたい
・ライセンス契約はNG(ここ交渉したけどだめだった)
要件
・インターフェースはSlackを用いること
・CSVまたはExcel,スプレッドシートで出力ができること
・位置情報を取得できること(ユーザーの事前承認必須)
・打刻忘れリマインド機能があること(土日祝日に対応すること)
・0:00またぎ(日付またぎ)の打刻は考慮しない(発生頻度が高い場合は対応」検討する)
・ユーザーの打刻修正は都度申請とすること
・管理監督者が勤怠を承認できること
・勤務時間予測を立て、しきい値を超える場合はアラートを管理者、経理、法務にメール通知する
・契約に応じた時間丸めを設定する
・中抜け時間を追加できること
・最終的に100人程度が同時に使えるようにすること
要件定義MTGでの会話 (2020/05/某日)
Barusu
「大体要件は出ましたかね。今回、私はアドバイザー的な立ち位置でお助けしますねー」
チーフエンジニア
「了解ですー!バックエンドとGsuite,Slack周りで困ったら都度相談させてください」
Barusu
「らじゃーです。では適宜SlackとBacklogでやり取りしていきましょう」
そして約2ヶ月が経過した…
7月、再び喫煙所にて
法務部長
「Barusuくんおつかれ」
Barusu
「あいっすおつかれっす」
法務部長
「あのさー」
Barusu
「んーいやな予感がしますねぇ」
法務部長
「あー。。。わかる?w」
Barusu
「まぁw長年のカンですね。
………勤怠のアレですよね?」
法務部長
「正解。事業部のほうがさ、燃えちゃってる案件の対応でかなり消耗していて。しばらくはそっちにつきっきりで勤怠の方は止まったままなんだよね」
Barusu
「あら…それは本当に大変ですね。。」
法務部長
「とはいえ、勤怠の方も進めなきゃいけないんだよね」
Barusu
「毎月発生してる作業ですしね」
法務部長
「なので本当に申し訳ないけど、Barusuくんにおn」
Barusu
「みなまで言わずとも。
まぁとりあえず作ってみましょう。これで駄目だったらSaaS入れる方向で決めてください。
一旦は事業部が途中まで作ったやつを確認してみます。使えるとこがあったら使って、完成させるか考えます。9月末には。
スケジュールは改めて出し直しですけど、モチベーションとしては8月末でユーザーテストで展開できるように頑張ってみる所存です」
法務部長「さすが」
Barusu「とにかく前に進むしかないっすね。馬なんで」
法務部長「なにそれ流行ってんの?」
次回予告
大方予想はしていたが、案の定Barusuがやることになってしまった!!色々な都合で会話内容と要件は一部伏せたり脚色しているが、SaaS契約はかなり難しい状況だ!だがしかし、途中まで作られたリソースが残っている!希望はまだあるんだ!
次回、「このリソースは使えねぇ」。デュエルスタンバイ!
続きはまた明日。ではではー。
この記事が気に入ったらサポートをしてみませんか?