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

Barusu

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

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

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

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

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

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

全10話分の2話目となります。
　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：そして伝説へ...

制作物を確認してみる(2020/07/03)

Barusu
「んーとりあえず、作成途中のやつを見てみるか。
　Backlog読む限り、あんまり進捗よくないっぽいけど。。。
　エンジニアAくんにリソースの保管場所聞いてみよう」

エンジニアA
「すみません…ここのGithubにリソース置いてあるので、これ見て引き継ぎしてくだされば助かります」

Barusu
「おっすおっすさんきゅー」

引き継いだPJの状況を見てみた。

Barusu
「まぁ予想してたけど基本設計書とかドキュメンテーションはほぼ0か。
なるほど、Vue.js + GAS + GoogleDriveの構成ね。」

Barusu
「SlackBot + データ集計 はできているか…最低限は。
　が、バックエンドでのデータ処理がほぼ未定義だな。
　GoogleドライブにJson保持する形式、そこから先は何もなしか…
　ユーザーIDを保持する機構も考慮されてないな。
　月またぎでのJson保持とユーザー別勤怠データの集計も設計されてないっぽい。
　この設計だとせいぜい15人くらいまでか…」

Barusu
「んー」

Barusu
「このリソースは使えねぇ」

制約事項を整理する(2020/07/06)

Barusu
「一旦要件を整理しよう」

要望
　・業務委託の勤怠を把握したい
　・リアルタイムで残業量を把握し、予測を立てたい
　・ライセンス契約はNG(ここ交渉したけどだめだった)
要件
　・インターフェースはSlackを用いること
　・CSVまたはExcel,スプレッドシートで出力ができること
　・位置情報を取得できること(ユーザーの事前承認必須)
　・打刻忘れリマインド機能があること(土日祝日に対応すること)
　・0:00またぎ(日付またぎ)の打刻は考慮しない(発生頻度が高い場合は対応」検討する)
　・ユーザーの打刻修正は都度申請とすること
　・管理監督者が勤怠を承認できること
　・勤務時間予測を立て、しきい値を超える場合はアラートを管理者、経理、法務にメール通知する
　・契約に応じた時間丸めを設定する
　・中抜け時間を追加できること
　・最終的に100人程度が同時に使えるようにすること

Barusu
「後ろ側はGoogleスプレッドシートでいいな。全部GASでやると重くなるし。
　てか、これMiyamotosan でよくね？」

▼Miyamotosanとは
Google Apps Scriptで書かれた、Slack上で動く勤怠管理Bot。
Slackで下記の様につぶやくと、みやもとさんがGoogle Spreadsheetに勤怠を記録してくれます。

画像1

https://github.com/masuidrive/miyamoto

検討：Miyamotosanではだめなのか(2020/07/07)

結論：だめだった。

▼理由
・中抜けの登録、承認機能がないので追加開発が必要。
・ユーザーが打刻修正、時間指定打刻できてしまうのもNGとのこと。
・ES6非対応で処理が重い上、記述が複雑で追加開発のコストがきつい。

流石にこれを書き換えるほどのスキルは俺にはなかった。​

覚悟完了(2020/07/07)

Barusu
「0から作るしかない…
　とりあえず法務部長に状況共有するか」

Barusu
「かくかくしかじか」
法務部長
「了解。じゃまず作ってみて、その後考えよう。
　弊社にとって学習機会になるだろうから、Barusuくんの裁量で、できる限りでいいからやってみて良いよ。終わらなくても良いや」

Barusu
「そんなん言われたらやる気出ますやん」

基本設計とI/Oを考える(2020/07/07)

Barusu
「とりあえずInとOutで必要な情報を考えよう」

出勤打刻
    In
        ユーザーのチャット(おはよう、グッドモーニングなど)
    Out
        Bot：「打刻完了」or 「打刻できません」

中抜け時間登録
    In
        ユーザーのチャット(休憩、中抜けなど)
    Out
        Bot：「登録しました」or 「登録できません」
退勤
    In
        ユーザーのチャット(おつ、お疲れさまでしたなど)
    Out
        Bot：「打刻完了」or「打刻できません」
リマインド機能
    In
        トリガー：GAS、条件：スプレッドシートの値
    Out
        Bot：対象ユーザーへDM(打刻忘れてない？など)

Barusu
「図にするとこんな感じか」

画像2

① ユーザー：Slack BotにDM
② Slack Event API：GAS発火
③ GAS：スプレッドシートに転記
④ GAS：スプレッドシートから値を取り出す
⑤ GAS：SlackAPI実行
⑥ Slack Bot：ユーザーにDM

Barusu
「さて。じゃあ実装していくか…
　とりあえずSlack Bot追加しよーっと」

次回予告

まさか0から作り直しになるとは思っていなかったBarusu！
しかしこんなことは日常茶飯事だ！
次回以降はそこそこちゃんと技術的な内容になっていきます！
書ける範囲を確認しつつ、ちゃんとまとめていくので次回もよろしくです！

次回、「Re:ゼロから始めるSlackBot構築」。デュエルスタンバイ！


この記事が気に入ったらサポートをしてみませんか？