タスクの作業時間記録の重要性

タスクの作業時間を記録することは、プロジェクト管理やチームの生産性向上において非常に重要です。

• 今日自分が何の作業をどのくらいの時間かけて作業したのかを振り返ることができます。
• あるタスクに対してどのくらいの時間をかけたのかを把握することで、タスクの見積もりやリソース配分を改善できます。
• プロジェクトや担当者ごとの作業時間を集計することで、チームのパフォーマンスを分析できます。
• 月次で作業時間を集計し、クライアントへの状況報告に利用できます。

Tagbangers では Atlassian の Jira でタスクを管理しており、個々の作業時間を記録するためのアドオンとして Tempo を利用しています。

Tempo は UI 上で日毎の作業記録と過去の作業内容を確認できますが、それらは各個人の手元でしか確認できません。 また、作業時間の記録は手動で行う必要があり、日々の業務の中で忘れがちになってしまいます。

そこで、1 日の終わりに日報としてチャットに投稿することで、作業時間の記録を促進しチーム全体での共有を図ることができます。

日報を手動で作成するのは面倒なため、これまで Tagbangers では自動で日報を作成する Bot が開発されてきました。

第一章 - HipChat 時代の日報 Bot

Atlassian ではかつて HipChat というチャットサービスを提供していました。

この頃から Tagbangers では HipChat 上で日報 Bot が存在していました。

私がインターンとして Tagbangers に参加した 2018 年のギリギリのタイミングで HipChat 上で元気に稼働していた日報 Bot は、Hubot というフレームワークを使って実装されていました。

1 日の終わりに @hubot bye とタイプするとゆるいリアクションと共に ヒューボット くんが作業ログを投稿してくれました。

Tempo は API を提供しており、Hubot のスクリプトから API を叩くことで作業時間の記録を取得し、日報を生成していました。

その API を使い、月次でクライアントに提出する保守報告書を自動生成してくれるアプリケーションも存在していました。

そして 2018 年に HipChat が Slack に買収され、ヒューボットくんと共に消え去ってしまいました...

第二章 - Slack 復活した Bot

Slack に移行してから暫くは、日報と Tempo への作業時間の記録は別々に手動で行われていました。

Tempo の手動の記録は忘れがちになることが多く、モチベーションも下がりがちでした。

そこで、かつて存在した Hubot の日報 Bot を Slack 上に蘇らせようと模索しました。

そして 2022 年、Hubot は Slack 上に蘇りました。

新しい Hubot の概要

この Hubot は名前だけで、実際は Slack Bolt という Slack のアプリ開発フレームワークを使って実装されています。

デプロイ先は AWS Lambda 上で動作し、Slack のショートカット /bye をトリガーに Tempo の API と Jira の API を叩いて、Slack に日報コメントを投稿します。

なぜ二つの API を叩く必要があるのかというと、Tempo の API は

• 作業時間
• コメント
• Jira の ID

しか返さないため、チケットの情報が含まれていないためです。

そのため

1. Tempo の API から当日の作業時間を取得
2. 取得した作業時間ごとに Jira の API からチケットの情報を取得
3. 取得したチケットの情報と作業時間を組み合わせて日報のメッセージを組み立て
4. Slack の API を使って日報を投稿

というフローで実装しました。

作業時間集計機能の追加

さらに月次の保守報告書を作るために、特定のクライアントに紐づくチケットの作業時間を集計して csv ファイルにして投稿する機能も実装しました。

こちらも同様にショートカット /report をトリガーに実行されます。

以前のように報告書そのものは作成できませんが、csv をコピペすることで報告書のテーブルの作成が容易になり、作業時間の短縮につながりました。

その後

かつての Hubot を思い出させるような /bye ゆるい挨拶と共に Slack 上で日報を投稿してくれる Bot が復活しました。

これにより日報を行うために Tempo の作業時間を記録しなければ、というモチベーションにつながり、チーム全体での作業時間の記録の促進と活用が進みました。

第三章 - 潜在的課題を解決した次世代の Bot

Slack Bolt で作成した Hubot にはいくつか問題点がありました。

デプロイ先を用意する必要がある

デプロイ先として AWS Lambda を用意する必要があり、当然メンテナンスも個人で行う必要があります。

API トークンの管理と権限の問題

これが一番の問題でした。

Jira (Atlassian) と Tempo の API トークンは個人で発行する必要があり、

• 期限が切れたら再発行する必要がある
• トークンを作った人が権限のない Jira プロジェクトや Tempo にアクセスしようとするとエラーになる
• API トークンが漏洩するリスクがある

投稿後に作業時間のつけ忘れに気づくことがある

たまに起きることですが、その後再投稿をすると日報が重複してしまいます。

確認モーダルの作成や削除などの機能を作ることは可能ではありますが、そのためにはフローの実装や投稿した ID の保持などを行う必要があり、実装の難度が高いため妥協していました。

Slack Platform を用いた Bot の開発

その頃 Slack では Slack Platform という次世代プラットフォームが利用できるようになりました。

このプラットフォームは、Slack 上のアプリ開発をより容易にするため様々な工夫がされています。

まず注目したのはデプロイ先を自前で用意する必要がなくなったことです。

Slack API を用いて開発・デプロイを行うことで、Slack のサーバー上で Bot が動作するようになりました。

そして開発していて一番驚いたのは、OAuth 2.0 の認証フローが組み込まれていることです。

これにより、固定の API トークンによる認証ではなく、ユーザーごとに認証を行うことができ、そのユーザの権限で API を叩くことができるようになりました。

潜在的課題だった 2 点が解決されることと、次世代プラットフォームに興味を持ったことから、Slack Platform を用いた Bot の開発を行いました。

そして、出来上がった Bot は Perry という名前で実運用を始めようとしています。

なぜ Perry かというと、Tagbangers は横浜にオフィスを構えており、横浜と言えばペリーだからです。（個人的発想）

Perry の概要

Perry はこれまでの Hubot の機能を引き継ぎつつ、Slack Platform 機能を活用して以下のような機能を実装しています。

最初に OAuth 2.0 の認証をユーザに促す

この機能は Slack Platform で実装されており、クライアントの定義をするだけで認証フローが組み込まれました。

Jira	Tempo

日付選択と投稿内容の確認のフローの追加

Slack には Workflow Builder という機能があり、Slack アプリ上からフローを定義して簡易的なアプリを作成することができます。

同じように Slack Platform でも Workflow の機能があり、フローごとにモーダルの遷移を定義することができます。

これを活用して

1. 日付を選択
2. 選択した日付の日報の確認
3. 日報を投稿

という流れを実装することができました。

日付選択	日報の確認	日報の投稿

これにより、よりセキュアでより柔軟な日報の投稿が可能になりました。

Perry のこれから

Perry はまだ開発途中であり、Hubot にあった作業時間集計機能なども移行する予定です。

Slack Platform では Datastores の機能があり、これを用いて投稿の編集・削除や、週次のサマリーの投稿なども実現することが可能になります。

次世代プラットフォームで Perry はさらなる進化を遂げるでしょう。

まとめ

Tagbangers では、Tempo を使ってタスクの作業時間を記録し、Bot を用いて日報を投稿する文化が根付いています。

Slack で日報が投稿されると「この人は仕事が終わったんだな」「この人はこんな作業をしたのか」といったことがわかり、仕事帰りに日報を出して「さあ、帰るか！」という文化が根付いています。

最後に、Hubot と Perry はオープンソースで公開しています。興味のある方はぜひご覧ください。

• Hubot Bolt App：https://github.com/cocor-au-lait/hubot-bolt-app
• Perry：https://github.com/cocor-au-lait/perry