Slack×GASで作った勤怠Botの話#10

UG Advent Calendar 2020 の10日目の記事です。

どうもbarusuです。知らない方は初めまして。
昨日の続きです。
フィクションと思って読んでいただければ幸いです。

Slack×GASで作った勤怠Botの話 #10

2020年5月。
良くも悪くもコロナ禍による新しい生活様式が定着しはじめた頃のお話。

―――――――ちょっとさ、勤怠システム作れない？

すべては法務部長の一言から始まった…

全10話分の10話目、ラストです。
　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/08：構築その6 ：色々書く(機能実装編：,勤怠修正機能)
　2020/12/09：単体,ユーザーテスト
　2020/12/10：そして伝説へ...  ← 今日はココ

喫煙所にて (2020/9/某日)

Barusu
「ひひーん」

法務部長「あーBarusuくんおつかれ」

Barusu
「ういっすおつかれっす」​

法務部長
「勤怠Botなんだけどさ」

Barusu
「バグですかね」

法務部長
「そうそう。なんか、BotにDMすると2回応答するんだよね」

Barusu
「あらま」

法務部長
「まぁそんなに大したもんじゃないからこのままでも良いんだけどね」

Barusu
「ちっと見てみますねー
あーほんとだ」

Barusu
「んー同時リクエストがあるからかな？
SlackAPIの3秒後再送する仕様に引っかかってるぽいな」

Responding to Events
Your app should respond to the event request with an HTTP 2xx within three seconds. If it does not, we'll consider the event delivery attempt failed. After a failure, we'll retry three times, backing off exponentially.
Maintain a response success rate of at least 5% of events per 60 minutes to prevent automatic disabling.
Respond to events with a HTTP 200 OK as soon as you can. Avoid actually processing and reacting to events within the same process. Implement a queue to handle inbound events after they are received.
What you do with events depends on what your application or service does.
Maybe it'll trigger you to send a message using chat.postMessage. Maybe you'll update a leaderboard. Maybe you'll update a piece of data you're storing. Maybe you'll change the world or just decide to do nothing at all.

Using the Slack Events API

Barusu
「解決策は...
おっ、あるやん」

Slack Bot をサーバーレスで運用する時の、タイムアウト対策【小技】 - Qiita

Slash Command に対して 3 秒以上かかる処理をする - 1日9時間寝たい

Barusu
「うーん？？？非同期にしても変わらん...」

Barusu
「リクエストヘッダの値をみて、リトライなら廃棄するようにしとこか」

Slack Event APIで同じEventが何回も発行される問題の原因と対処 - Qiita

Barusu
「あーGASだとリクエストヘッダは取れないんか...(絶望)」

【GoogleAppsScript】doPost のリクエストパラメータでHTTPヘッダを取得することはできない - Qiita

Barusu
「ひひーん。
重要度も緊急度も低いからこれは未解決問題にしとこ」

▼問題リスト
・SlackBotからの応答が2回連続で来る

Slackにて(2020/10/某日)

法務部長
「Barusuくーん」

Barusu
「はーいBarusuです」

法務部長
「勤怠Botなんだけどさ、ユーザー展開も順調でいい感じよ。
派遣会社からの勤怠報告もこれに寄せられるようになったから、かなり助かってるよー！！」

Barusu「おー良かったです！」

法務部長
「それでさ、追加の相談なんだけど...
位置情報取れるように変更できる？」

Barusu
「ひひーん」

位置情報取得の検討

Barusu
「んーたぶん打刻時にGASのHTMLサービスを開けばJSでいけると思うんだよな」

JavaScriptで位置情報を取得する方法(Geolocation API)

Barusu
「えーそれだとそもそもインターフェースがSlackじゃなくなるよな...
まじかーこれ」

Barusu「んー、保留！」

▼問題リスト
・SlackBotからの応答が2回連続で来る
・位置情報を取得したい ← New!!

衝撃の発表(2020/10/06)

Barusu
「さて今日も情シスSlackの未読スレッドを徘徊するか...」

Barusu
「ん...？GoogleWorkspace...？？？？？？？？？？？？？？？？」

Google Workspace のご紹介 | Google Cloud Blog

GSuite→GoogleWorkspaceへ！何がどう変わる？ | 情シスHackGSuite→GoogleWorkspaceへ！何がどう変わる？

Barusu
「ぬわーーーーーーーーーーーーーーー」

衝撃の発表、その後(2020/11/某日)

Barusu
「ぶるっひひーん」

法務部長
「Barusuくーん」

Barusu
「あーい」

法務部長
「こないだ提案してくれたGSuiteのプラン変更なんだけどさ...
ちょっと高いよね...？」

Barusu
「そうですね...頭痛いですね」

法務部長
「役員会でも高いよねーって話になってさ。
～中略～
ウチってさ、Office365も契約してるでしょ？MS365に寄せる方向ってないかな？」

Barusu
「ありっちゃありですよ。今のウチの課題がいくつかまとめて解決できるでしょうし、ワンチャンありです」

法務部長
「MS365に切り替えるときのコストと、段取りを軽く組んでみることできる？」

Barusu
「あーまぁ、そう言われると思って資料作ってました。
まだ粒度荒いですけどこれっす」

法務部長
「さすがというかなんというか...」

Barusu
「あっ、そうだ。勤怠Botも一部組み替える必要がありますね。
バックエンドをスプレッドシートにしてるので、これをちゃんとしたRDBに組み替えなければです」

法務部長
「あーそうなんだ。せっかく作ってもらったのにね。
で、どれくらいかかりそう？」

Barusu
「えーとですね...
その質問には回答せず、別の提案なんですけど」

Barusu
「やっぱ、SaaS契約しません？」

法務部長
「...前向きに検討しとこうｶﾅー」

Barusu
「...ﾃﾞｽﾖﾈー」

法務部長
「まだMSに切り替えるって決まったわけじゃないから、一旦勤怠Botの追加要望は置いといていいや」

Barusu
「らじゃーっす。まぁ手が空いたときに追加要望の件は検討しておきます」

法務部長
「ではそれで。じゃーとりあえず、勤怠Botは継続して使っていくね」

Barusu
「はいー」

Slack × GAS で作った勤怠Botのその後

依頼者の声

法務部長
「短い納期でサクッと作ってくれて助かった。
まだ課題はあるが、勤怠状況が見えるようになり、残業の抑止や稼働増による請求発生の予防にもなっていて本当に助かる」

バックオフィスの反応

業務委託管理担当
「所属会社ごとにフォーマットが違う勤務表を紙で提出され、数字の確認も目視と日報メールとの照合でやっていたので、とても手間がかかっていた。
この作業がなくなるだけで相当ありがたい」

ユーザーの反応

※Slackでエゴサしました

＊「これを毎日ちゃんといれるのはきつい」(デザイナー)
＊「スラッシュコマンドでやりたい...」(エンジニア)
＊「修正がいちいちフォームなのはつらい」(営業)
＊「なんでBarusuさんが作ったんだろう...」(エンジニア)
＊「IEYASUでよくね？」(エンジニア)
＊「頑張ったなぁ...」(事務担当)
＊「おはよう、おつかれで反応してくれるのはわかりやすくて助かるー」(営業)

総括

Good!!👍

+ なんだかんだで完成できた
+ GASの理解が深まった(気がする)
+ ランニングコスト0
+ ユーザー、バックオフィスともにそこそこ評価良い
+ バックエンドをスプレッドシートにしたおかげで、非エンジニアでも多少保守ができる(教育すれば引き継げるレベル)

Bad...👎

- 中長期を見据えて、最初からSaaSで契約しておくべきだった
- バックエンドをスプレッドシートにしたせいで、GoogleWorkspaceからのスイッチングコストが増した
- ランニングのライセンス費用はかからないが、工数はかかる

最後に

ここまでお付き合いいただきありがとうございました。

"Slack×GASで作った勤怠Botの話"シリーズ、全10話はこれにて完結となります。
ソースコード込でだいたい5万字くらいは書いたかもしれませんね。

お話としては一応完結しましたが、実際の勤怠Botはまだ問題点を多く抱えております。
作中で書いたもの以外にも細々とした改修点があったり、割と煩雑になってしまっているソースもあったり、棚上げにしたままの問題点もいくつかあります。

これから少しずつ改修をして、最終的にはSaaSに乗り換えるべきなのでしょうね。
すぐにでも切り替えた方が良いんじゃないかとか考えてもいますが、政治的力学もあるので一概には判断ができなかったりします。

今回このお話を書いた背景としては
解決に至ったかわからない、別の問題を作ってしまったかもしれないモヤモヤを整理したかったからであります。
流石に全容を明かすことはできませんでしたが、こうして記事を書いていると思考がまとまるようでして。
いくつか解決策を思いついたので検討してみようと思います。
うまくいったらいつかまた、こうしてシリーズモノとしてご紹介できれば良いなーと。

うまくいかなかったら...？

そうですね。
やらかしネタとして、どっかのLTで盛大に笑いを取りにいこうかな。

では、いつかまた。

そして伝説へ...