Slack Bot を利用した勤怠システム導入 ( Slack + Flowxo + Firebase ) in ノースサンド

TL;DR

ノースサンドでは、勤怠のシステムとしてSlack Bot ベースとしたスクラッチ開発でのシステムを利用しています。
今回の導入に当たっての背景やメリデメ等々やプロジェクト推進、利用後に見えた世界をお伝えできればと思います。

自己紹介

ノースサンド に18年2月に入社しまして、1年ほど経ちました よーじろー が執筆しております。
前職はインフラを強みとするSIerで働いていましたが、ノースサンド社員の雰囲気と人柄、スキルに惚れて入社させていただきました。

背景

ノースサンドの以前の勤怠の仕組みはExcelによる提出でした。

それによっていくつかの課題がありました。

1. Excelの勤務表の作成負荷（全社員
これは毎月の行事でしたが、とてもヘビーでやりたくない作業でした。
そして後述の2に絡みますが、期限が短く、これまたヘビーでした。

2.勤務表の手動チェックと手直し（バックオフィス
ExcelなのでValidationが弱く業務ロジックも組み込みづらいです。
下手すると魔改造された VBA という悪魔の子が生まれます。

3.なんかダサい（よーじろー
入社して、説明を受けた時、 ダッサ って思いました。
　（既存の仕組み考えたひとごめんなさい。
え？くそダサ・・・ って思いました。
　（あ、口にはそんな出してないですよ。多分・・・

その時点から私はこれをかっこよくしなくてはならないという謎の使命感をもっていました。
そして湯船につかりながら、勝手にアーキテクチャを考えていました。

導入に向けて

導入にあたって、当初はスクラッチではなく勤怠システムのSaaSの利用を考えていました。こちらはいろいろ見た結果、ノースサンドの働き方に合うサービスがなく断念しました。
（ 業務要件を満たすことができない or カスタマイズの負荷 ）

折々あり、スクラッチでの開発となりました。
この辺から私は本格的に参加しています。

アーキテクチャ

びっくりするぐらい、ざっくりですが下記が全体イメージです。
逆に言えばこれくらいで完結するようにシンプルを意識して作っています。

フロントエンド：Slack
当初の計画ではWebのインタフェースがベースでした（だったと思います）
しかし、Webがベースだと、フロントをリッチ(優しい実装)にする手間がとても大変そうだなという印象がありました。
よりユーザビリティをあげるためには業務要件をフロントにも実装する必要があるためです。
そして、そこに絡みこむクロスプラットフォーム対応。
増える対応端末、アクセス制限、アクセス負荷、速度遅延

ということで半ば強引にSlackに倒しました。
伏線的にもSlackにしたかったんです。こちらは後述します。
ユーザ管理とかもSlackに寄せたかったのも強いです。

Bot フレームワーク：Flowxo

Bot作るよってまず出てくるのはHubotですよね。

Hubotももちろん検討しましたが、結局 Flowxo に落ち着きました。

Hubotなどはサーバが必要なため、EC2等のサーバー費用が普通に高い、そして安定稼働の監視が手間だなと感じたためです。
バックオフィスの手間を減らして、別の負荷を生み出してどうすんねんって話です。

サービスであれば、SLAをサービスに寄せることにはなりますが、管理はとても楽です。
なにより、要件がまだふわふわしてる段階であれば、コード書くよりGUIで直感的にまとめ上げていくフェーズだな、と感じました。

Flowxoは、GUIでワークフローを作るように、Botを作ることができるサービスです。

会話の作成イメージは下記です。
基本的には1本道スタイルでIF分岐とかは別コマンドってイメージでつくる形です。作っていくうちにベストプラクティスも見えてきました。

ログ管理やアナリティクスもできるので少し手間が軽減されます。

　※需要ありそうでしたら、細かな説明も別記事にしたいと思います

一応Bot導入にあたり、下記のものはすべて試しました（一部抜粋
　hubot, dialogflow, chatbot.com, bottr, botpress.io, meya.ai .... etc

なかでも meya.ai は、yamlで記載できるのでエンジニア心としてはとても揺さぶられましたが、調べたときは 料金が contact us となっていて、不明だったので、辞めました。

サーバサイド：Firebase

サーバサイドは MBaaSの代名詞とも言えるFirebaseです。
中間DB的な立ち位置でFirestoreも利用しています。

こちらは、コスト的にめっちゃ安かったのもありますが一番はFirebaseを使いたかったという点につきます。

FaaSならなんでもよかったのですが、知ってるの(Lambda + API Gateway)やっても業務感でて楽しくないじゃないですか。。ですよね？

実際、ログの管理もめっちゃ楽ですし、アプリのエラーインシデントもとても簡単に拾え、最高でした。

また、APIのエンドポイントがFunctionと同じレイヤーでコードでかけるので、MVCフレームワークのルーティングレイヤーを書くようにエンドポイントが実装できたのがとても開発しやすかったです。

この点はAWSのLambda + API Gatewayとは段違いに良いなと感じました。

実装スケジュールと体制

仕事を受け取ったときには
様々な背景があり、業務要件のリストとDB直接みて想いを察しろ。という感じでした。

ただまぁそこまで複雑な構想ではなかったので、ソレで十分でした。

もうアーキテクチャは自宅の湯船で描けていたので、後は細かなサービス選定のみです。

ノースサンドは 2月から期が変わるためそこにリリースのマイルストンを置き、テストユーザでの運用ベースでのテストのバッファを取り、
基本的には 18年 10月 ~ 12月の3ヶ月間 がメインで開発していました。
1月はバグフィックスがメインです。

カナリアリリース的な発想です。

プロジェクトを進めていた 3〜4名ほどで軽くポンチ絵を手書きをしてプロジェクトを始めました。

ポンチ絵の様子

プロジェクトとしては、複数名のメンバで構成されていましたが、
実際に今回記載の領域において、コードをかいて、仕組みをつくって、
手を動かしていたメンバーは 私一人です。
立派なドキュメントも一人で作ってます（割とマメな性格です

なぜなら下記のやりとりがあったためです。

あれ、誰かいたほうがいいよね？ 何人居る？ （優しい人

この程度なら俺一人で十分ですね。中途半端なスキルなら居ない方がいいです。　（自分

こう啖呵を切って後に引けなくなった私は割とがんばりました。
どっちかというと、楽しかったです。

2週間でモックのAPIをつかってBot 利用時のイメージがほぼできたので、
同時期からコードを書き始め、1.5ヶ月ほど集中してコードを書いてました。

ざっくり下記のイメージだった気がしてます
10月頭
　モック作る
10月末
　モックでのドッグフーディング
10月中 ~ 11月末
　集中して作る
12月頭
　実際のアーキテクチャでのドッグフーディング
12月末
　細かい微調整と、HRシステムへの連携

 ※コードのコミットログと、議事メモ見ながらおぼろげに、、、

実装は一人でやりましたが、
実際には推し進めるに当たって実は一人ではないです。

細かな質問も一瞬で返してくれて一緒に考えてくれて、整理を手伝ってくれた経理の長
 くそお世話になりました。

システム的にやりたくないけど、会社の制度の方をサクッと変えてしまうし、サクッと重めのことを決めてしまう役員
システムとのバランスの見極めがうまい人だなと感心しました。
（負債となる判断のポイントが秀逸）

暖かい目で一緒に完成度を高めてくれたプロジェクトメンバ
めっちゃ暖かかった。

何より現場調整を一緒にやってくれた現場メンバ
彼らがいなかったら多分時間を作れてなかった。

ご協力いただいたテストユーザの方々
とても優しめで助かりました。

何よりも、システムを使ってもらってる人全員
使う方も変化による理解と対応が必要ですがご協力いただきました。

上記のたくさんの仲間達に救われ実装できたと思っています。
その節はありがとうございました。

土下座する準備はいつでもできてましたが、まだ発動しなくて済みそうです。

勤怠Bot導入によって見えてきた世界

費用感
基本的にはランニングコストのみです。
詳細は控えますが、勤怠SaaSサービスの 1/10 程度のコストで実装できています。社員が増えれば、どんどんお得になります。（負荷を考慮しても）

ここはクラウドネイティブな時代なので結構こだわりました。
システム設計もコストを強く意識して設計している部分が多々あります。

バックオフィスの負荷削減
管理者操作も実装しているため、集計系なども実装しています。
まだ、たたき上げている部分もあるため完全に業務が無くなっているわけではないですが、楽になっているんじゃないですかね。多分。
ですよね？

全社員の負荷削減
多少は楽になったのではないかと。
個人的には毎月30mほど時間をかけていた作業が、ほぼ無くなりました。
それに加えてIFTTT 連携で GPSベースでの 自動入力も導入しているのでもっと楽です。1日 15秒程度しか時間を使ってないです。
（Siriのコマンド作ったけど結局使ってない。。。）

現在ノースサンドには 100名弱がいるので、毎月 50時間分 の工数削減にはなるのではないかと。その半分だとしても 25時間。
25時間 × 時給 × 12ヶ月 = まぁまぁな金額。

ROI的にもわりといいんじゃねーかな。

ノースサンドのかっこよさ
かっこよさ爆上げ。いや、知らんけど。

私はそう思っています。

Bot導入の裏目的

Slackの部分で、伏線を張っていた件ですが。
私個人の思いとしてはSlackを普通にしたかったってのが強いです。
ツール（IT）が導入され、実際に利用されるためには下記の2パターンしかないと考えています。

1. 圧倒的な利便性がある
2. 利用しないと業務を遂行できない

今回は、2が強いです、ただ1も諦めたくなかった。
そのために楽になる仕組みは結構導入したつもりです。このパイプラインに乗れている方はとても楽だと感じていただけてると思っています。たぶん。

ですが、その他のBot導入の個人的な意見もあります。

ChatOpsやりたかった
時代の潮流じゃないすか。やって勘所はつかんでおきたい。
実際には Intercomを代表するようなシステムとの連携が必要ですが、まぁはい。とりあえずさわりでもやりたかった。

Webは作りたくなかった
Webでの実装は一番ベターでアーキテクチャもわかりやすく、学習コストも一番低いです。
ただ、学習コストが低いというのは同時に成長が少ないともとれます。
せっかくの社内プロジェクトで自分で自由に動かせて失敗しても許容される状況で無難な選択はしたくなかったです。

開発の時間を最大限に自分の成長にも活かしたかったです。
フロントにReact使えば、、SPAでつくれば、、等々それでも成長の余地はあったと思いますが、そういった1部分のスケールのレベルでの挑戦はあまり心が躍らなかったです。

Slackをノースサンドの共通言語にしたかった
個人的な所感ですが、最近のツールは使わないと良さが全面に伝わらない部分が多々あると思います。
機能は一緒だけど、UI/UXで勝負しているツール等々。

Slackは文字でサマリにするとただのチャットツールです。そんなの市場には死ぬほどあってしかも超大企業が商材として構えてます。

メールで良いじゃん勢も多数います。

しかし、Slack を利用することに価値が多く、ある。
それを何かしらで体現したかったのです。
  ※ Slack に対する想いは別で書くかもなのでここでは深掘りません。

導入以前は、Slackは公式と言える状態でなく、利用者もまばらでした。
MS Teams勢なども居たと記憶しております。
とりあえず、社員名を入れると、チャットがつながる状況を作りだしたかったのです。
今回の勤怠システム導入によって、全社員登録することでやっと #general が機能してきたなーーという所感です。
これによって、勝手に社内のコラボレーションが増えて充実度が増してるなという勝手な印象なのですが、どうですかね。
どうなんでしょう。

ちょっと簡単に推し量る術がわかりません。

とりあえず、既成事実的に浸透したので良しとします。

今後の展望

まだまだ、バックオフィス系の手間を減らす余地はあるので、そこの継続的エンハンスメントが必要です。（一応じり貧で対応してますが、、、

また、もう今のフェーズでは、FlowxoじゃなくてFirebaseに全寄せしても問題ないほどに要件が固まったので、その実装をすることでサービス依存度を下げてコストを圧縮したい計画もあります。

後は利便性をあげるユーザ向けの機能もヒアリングして実装していきたい気持ちもあります。

そして、一緒に開発してくれるメンバもでてきたのでナレッジトランスファーも実施しています。（ほぼ完了してるけど

まとめ

そんな感じで、個人と会社の利害がすべて一致した形でのプロジェクトだったのでとても楽しかったです。
また他の見つけてどんどんやりたい所存です。

ですが、一人ではやっぱ天井はあるので、、、

We are hiring!!

こーゆー取り組みを自発的に提案して作りたい仲間も募集しています。
http://bit.ly/2M3k5Xr

Twitter もみてね。最近わりとちゃんとやってます。
https://twitter.com/NorthSandHQ

ではまた。