Tably社内で開発し活用しているアプリ/サービス
こんにちは。Tably よういちろうです。
2020年1月1日にTablyに入社して、早くも1年以上が経過しています。この間、結構多くの方々から「Tablyで一体何をしているんですか？」という質問を受けてきました。その答えは、
「自分たちに役に立つツールやサービスを開発してます」
と答えてきましたが、あまり具体的にどんなものを作ってきたのか、お伝えする機会があまりなかったというのが正直なところです。
そこで、このエントリでは、今までどんなものを作ってきたのか、紹介してみましょう。大小問わず、作って活用しているものは全て紹介したいと思います。
勤怠管理Slack BOT
まず真っ先に開発したのが、日々の勤怠を記録するためのSlack BOTです
勤怠は毎日記録することになるので、本当に手軽さが大事です。何かアプリを起動したり、ウェブアプリを開いたりするのですら手間です。そこで、毎日使うであろうSlackにBOTを仕込んで勤怠を記録できれば良さそうだ、ということで、ゼロから作ることにしました。
とにかくまずは勤怠の記録をできるようにして、その後は徐々に機能を追加していきました。今では、勤怠管理は全てこのSlack BOTにて行われています。
勤怠の記録は、Slack BOTの「/attendance」スラッシュコマンドで行います。
上記のボタンを押して勤務開始と終了を記録しても良いですし、「/attendance in」「/attendance out」でも記録することができます。また、「確認・修正」ボタンを押すとポップアップが表示され、ここでも勤怠の記録ができ、また過去分の確認や修正ができるようになっています。
また、休暇を取得する場合も、このポップアップからできるようになっています。
もちろん、Slackのスマホアプリ版からも操作可能です。
「そう言えばさっき、API っていうボタンがあったな」と思った方は、さすがです。Slackアプリを起動することすら面倒だ！という状況のときのために、API にて勤務開始と終了の記録を行うことができるようにしています。
僕はGoogleアシスタントとIFTTTを組み合わせて上記のURLを登録することで、「おっけーグーグル、仕事を始める」とNest Hubなどに話しかけることで記録することができるようにしています。その他にも、Siriショートカットでも同じことができます。
Slack BOTには「App Home」という機能があって、BOTが「画面」を持つことができます。この勤怠BOTも、App Homeに対応しています。
休暇の残日数をこの画面で確認できるので、便利です。
社員の勤怠管理は、社員の健康管理に直結する非常に大事な事項です。例えば、36協定を遵守しなければなりません。Slack BOTは、社員の勤務時間について、働きすぎないように「助言」をしてくれます。
例えば、一日あたり8時間を超えた場合は、以下のように話しかけてくれます。
もちろん、深夜時間帯や月間、年間での勤務時間に関する指摘も的確に助言が飛んでくるようになっています。
社員向けの機能としては以上になります。しかし、これだけでは勤怠管理とは言えません。労務担当者はもっと仕事があります。このSlack BOTは、もちろん労務担当者向けの機能も提供しています。
労務担当者のアカウントでApp Homeを開くと、下の方に管理向けのボタンが表示されます。
社員が取得可能な休暇にはいろいろな種類があります。もちろん、企業独自の休暇種別もあることでしょう。労務担当者は「休暇種別登録」ボタンを押して、休暇種別を登録していくことができます。休暇ごとに、勤務時間に加算するかどうかも指定することができます。
「休暇付与」ボタンを押すことで、社員に休暇を付与することができます。
もちろん、付与する休暇の取得可能期限も設定可能です。
過去の勤怠の記録が書き換わってしまうわけにはいきませんので、年月を指定して勤怠を確定させることが可能です。確定済みの年月の勤怠記録に対して、社員は修正などを行うことができなくなります。
Slack上で操作できる機能は以上となりますが、データベースに情報が格納されているだけでなく、Google Sheetsとして集計されたレポートが毎日更新されています。
例えば、以下は月ごとの勤務時間の実績です。また、労務士に提出することになる全社員の月ごとの勤務時間集計結果のシートもあります。
また、年次有給休暇の付与と取得実績も、シートで出力されています。
最初は「勤怠管理なんて開始と終了を記録してあとで集計すればいいんでしょ楽勝じゃん」と思っていたのですが、勤務時間の計算ロジックはなかなか複雑であり、決めごとも多いです（日をまたいで勤務したときの扱いとか）。テストコードをがっつりと書いて実装を進め、年初めに入社から1年経過、つまりすでにグルッと1周していて問題なく使えていますので、稼働実績としても問題なく勤怠管理ができている、と言い切ってよいかと思います。
Tably固有の事項をできるだけハードコードせずに実装したので、おそらく他社でもそのまま使えるだろうな、とは思いつつ、十分かつ使いやすい勤怠管理システムを自分たちが特に不満を持つことなく当たり前に使い続けている現状は、嬉しい成果かと思っています。
ちなみに、この勤怠Slack BOTは、バックエンドで以下の技術を使っています。
Google AppEngine (NodeJS), Cloud Datastore, Google Sheets API v4, TypeScript, Slack API
毎月のランニングコストは、1年間運用した結果、不具合で数百円使ってしまった月がありましたが、その後は毎月1円未満で推移しています。
Google Cloud Platform課金レポートSlack BOT
勤怠Slack BOTは、Google Cloud Platformの各種サービスを使って実装されています。限りなく課金額をゼロに近づけるべく自分の技術力を注いでいますが、毎日クラウドの利用がどの程度だったのか、つまり課金額がどこにどの程度発生しているのかは、とても気になることです。
毎月の請求レポートを見てからでは遅く、でも自分の設計が常に完璧であるわけがない。となると、「できるだけ早くミスに気がつく」ための仕組みが必要となります。
そのために、Google Cloud Platformの利用状況と課金状況を毎日レポートしてくれる仕組みが欲しくなりました。そこで、レポートをSlackで毎日教えてくれるBOTを開発しました。
経験上、ごく一部の利用機能において「他よりも飛び抜けて課金額が跳ね上がる」という傾向があると考えているので、利用量と課金額の上位10個を観測していれば「ああ、これか」と原因がすぐにわかります。プロジェクトごとのランキングと、細かな利用機能の上位10個のランキングを毎日レポートさせていて、自分の設計の間違いや改善の材料にしています。
ここで白状します。事前にこの課金レポートの仕組みを導入したという格好の良い話ではなく、実際に課金額を跳ね上げらせてしまったことへの反省として、この仕組みを導入しました。以前は1円もいかない勤怠Slack BOTの課金額が、ある日突然200円以上に跳ね上がっていました。しかも、それが3日間続いた後に、たまたまGCP Consoleを見て気がついたのです。「え、1日あたりたったの200円でしょ？」と考えてしまうのは正しくなく、ここで重要なことは相対的に「課金額が200倍になった」ことです。1万円が200万円です。正当な理由がなければ、こんな事態は許容されるわけがありません。
このSlack BOTにより、課金額を毎日チェックすることができるようになりましたし、何よりも課金額に対して意識が変わり、設計時によりコストについて考えるようになりました。
ちなみに、この課金額レポートSlack BOTは、バックエンドで以下の技術を使っています。
GCP Billing Export, BigQuery, Cloud Scheduler, Cloud Pub/Sub, Cloud Functions, Slack API
Zoomミーティング作成およびURL発行Slack BOT
弊社では特に理由がなければZoomを使っているのですが、「すぐに話したい」というときに限って何も準備していない状況であり、Zoomの画面を開いてミーティングを作成して・・・という操作がとても面倒に感じてしまいます。しかも、ミーティングの作成、URLを相手に伝える、といったことは「毎回ほとんど同じ操作」です。これは人間がやることではありません。
そこで、「またか！」という声が来そうですが、Slack BOTを作りました。その名も「Zoom Please」です。
“/zoomplease” というスラッシュコマンドを使って、Zoomのミーティングを自動的に作成して参加URLをすぐに得ることができます。
最初に、”/zoomplease connect” と発言すると、以下のようなメッセージが返ってきます。
この青い文字をクリックすると、Zoomの認可画面が出てきます。
これにより、SlackユーザアカウントとZoomユーザアカウントが紐づけされます。あとは、”/zoomplease meeting” と話しかけることで、Slack BOTが以下のように返事をしてきます。
話したい相手がいるSlackチャンネルで “/zoomplease meeting” と発言することで、相手もこのリンクからZoomミーティングにすぐに入ることができます。ミーティングを開催する側も、参加する側も、とても手軽です。
これを作ってからもうすぐ1年になりますが、社内では当たり前の機能となっています。
メールの自動処理「Email Flow」
次に手がけたものは、日々送られてくるメールを効率よく捌くための仕組みづくりでした。
現在は社内で「Email Flow」という名前で呼ばれている仕組みですが、最初は「Financial Email」という名前をつけていて、メールで送られてくる請求書の添付ファイルを自動的にGoogleドライブの所定のフォルダにアップロードする仕組みでした。
これをさらに汎用的にしてルールベースで様々な処理を行えるようにしたものが、Email Flowという仕組みになります。これは、以下のnoteですでに皆さんに紹介させていただきました。
PPAP対策も施されていて、手作業でパスワード付きzipファイルを解凍しなければならない手間は、すでにTably社内では必要ありません。
ほとんどメンテナンスすることなく、Email Flowは着々とメールを処理してくれています。この仕組みが止まってしまった後は、Tablyの業務は滞ってしまうのでは、と思うくらいの働きをしてくれていると自負しています。
上記の記事にて「ワークフローを組み上げる作業が難しい」と課題を上げていましたが、その後にワークフローをテキストファイル（JSON形式）で出力し、修正後にアップロードして新規のワークフローとして登録する、という簡単なツールを作ったことにより、手間の軽減を実現しています。本当はGUIアプリ化したいところですが、いまのところそこまでワークフローを追加したり修正したりする機会がないので、着手していません。
Email Flowについては、メール受信をきっかけとする完全なイベントドリブンでの処理であり、ランニングコストは毎月2,3円で収まっています。
Googleカレンダーを便利にするSlack BOT
弊社では多くの方々と打ち合わせをさせていただいていることもあり、その予定調整は結構な難易度となっています。例えば、以下のような内容を相手に送る機会は、誰しもが経験していることかと思います。
3/30(火) 15:00-16:30 お打ち合わせ（仮）
4/15(木) 13:00-14:30 お打ち合わせ（仮）
4/16(金) 13:00-14:30 お打ち合わせ（仮）
この候補日の一覧を書くだけでも、結構手間です。Googleカレンダーからキーワード検索をして、一気にこのテキストをコピペしたいと思いませんか？
これを実現してくれるSlack BOTを作りました。社内では「Calendar Tools」という名前のBOTです。”/calendartools” というスラッシュコマンドで呼び出すことができます。
Slack 内で “/calendar search” と話しかけることで、検索画面が出てきます。
検索結果は、テキストメッセージとして返信されます。
あとはこれをコピペしてメールに貼るなどして先方に伝えることで、予定調整を行うことができます。
さて、予定調整を終えた後に、仮で抑えていた予定は必要なくなったので、一気に消すことになると思います。これはこれでGoogleカレンダーのUIから消すのは面倒です。そこで、Calendar Tools では、検索した結果から、予定の名称を一気に変更したり、複数の予定を一気に消したりすることができます。
「予定調整しなくちゃ、でも面倒だな」と思ってしまう要因として、こういったちょっとした作業の積み重ねがモチベーションを下げていると思います。こういったちょっとしたことを簡単にしてあげることが大事です。
Calendar Tools は、以下の技術で開発されました。
TypeScript, Google AppEngine NodeJS, Slack API, Google Calendar API
Moderator
最後は、主にオンラインイベントにて弊社で活用しているウェブサービスを紹介したいと思います。名前は「Moderator」です。
どこかの会場に集まって行うオフラインイベントでは、登壇者は参加者の顔を見ることができます。「なにか質問はありますか？」と聞けば、その場で参加者は手を上げて質問ができます。さらに、登壇者は参加者の顔を見て「あれ、話が難しかったかな」などと手応えを感じ取ることができますが、オンラインイベントではそういうわけにもいきません。
そこで、オンラインイベントでも参加者が気軽に質問ができるように、そして登壇者が手軽に参加者の状況を把握することができるように、という仕組みを考え、形にしたサービスが、Moderatorになります。
Modertorを使ったオンラインイベントに参加したときのことを紹介してみます。イベントの参加者は、イベントの主催者から「この URL にアクセスしてみてください、もしくは、この QR Code にアクセスしてみてください」と促されます。PCやスマートフォンのウェブブラウザにて、Moderator でイベントのページが開きます。ニックネームを設定しながら、イベントの中継を見ます。
その後、イベントが進み、登壇者が参加者から質問を受け付け始めました。すると、Moderator の画面は自動的に切り替わっていて、参加者が質問を投稿できるようになっています。「これは自分も聞いてみたい！」といった質問には、ハートマークを押して +1 することが可能です。
イベント内で登壇者が一通り質問に回答していきます。その際には、質問を大きく表示することで、参加者はいまどの質問に対して登壇者が話しているか、はっきりとわかります。
登壇者が「今日のイベントはこれで終わりですが、最後にアンケートに答えてください」と参加者にお願いをしました。手元のスマートフォンを見ると、自動的にアンケートの回答ページに切り替わっています。
アンケートの質問は選択式です。選択していくだけで回答していくことができます。もしかしたら、最後に登壇者がアンケートの結果をグラフで公開するかもしれません。その際にも、参加者の画面に自動的に反映されます。
登壇者は、Moderator の管理画面にて、参加者から来た質問を見ていき、回答した質問に印をつけていくことができます。
イベントとの始まりから終わりまで、いくつか異なる話題でイベントが構成されることが一般的です。そして話題が変わるタイミングで質疑応答やアンケートなどを行うことになるでしょう。Moderatorでは、一つのイベントの中に複数のセクションを作成し、質疑応答のテーマやアンケートの内容をセクションそれぞれで作成していくことができます。セクションを切り替えていくことで、参加者に提示される画面も自動的に変わっていく仕組みです。
予め登壇者はイベントの予定に沿ってセクションを作成しておき、質問の受付やアンケートの回答のタイミングを考えておくと、Moderatorをスムーズに使いこなすことが可能となります。
Moderatorに投稿された質問をSlackに流していく機能も備わっています。後日振り返りに利用したり、社内イベントであれば質問への回答をSlack上で行うことでイベントの続きをSlack内で行うこともできるでしょう。
Moderator は、弊社が主催するオンラインイベントや、研修事業などで利用しています。今まで数千人規模のオンラインイベントでも運用実績があり、大量の質問の投稿や +1 の投稿などを余裕で捌きました。現在も Moderator は日々開発を続けています。
Moderator は以下の技術で開発しています。
React, TypeScript, Firebase (Authentication, Firestore, Functions, Cloud Pub/Sub, Slack API, Google Sheets API v4
イベントの規模（特に参加者数）に依存して、Moderatorのランニングコストは増減します。昨年の実績では、参加者が1000人を超えるオンラインイベントが2回実施され、そのどちらも200円以内で収まり、全てのイベント実施の合計額も600円ほどでした。
まとめ
以上が Tably に入社してから1年間で開発してきたソフトウェアとなります。どれも、今では弊社の活動にはなくてはならないものとなっています。Moderator は、今後みなさんが実際に目にする機会もあるかなと思います。また、Google Cloud Platformの課金額の合計では、昨年1年間で1,300円以内に収めることができ、予想を大幅に下回る金額で着地させることができました。
今後もこのような開発を積極的に行っていきたいと考えています。まずは自分たちがユーザとなり、自分たちで価値をしっかりと感じることができるようにすること、そしてそれらが直接的にも、間接的にも、世の中のさらなる発展に寄与できれば良いな、と願っています。