BacklogとChatworkを連携させてみた
やったこと
弊社はタスク管理をbacklogで行っているのだがエンジニアの手持ちのタスクがなくなったらその旨をチャットワークに通知できるようにした。
なぜやったのか
営業部の方々からエンジニアが手持ちのタスクがなくなったらすぐ知りたいという要望があったのだが、タスク管理ツールとして使っているbacklogにそのような機能がなかった。
幸いbacklogはapiも公開されているのでその中にあるだろうと思い、自分たちでやるか！という判断に至った。
苦戦したこと
-
どうやってapiを叩く処理を呼び出せば良いのか分からなかった。
僕たちエンジニアがタスクのステータスを完了に変更させた時目的の処理を行えば良いだろうと漠然と考えていたが、そもそもどうやってそのタスクについての処理を行ったことを検知すれば良いのか分らなかった。
これについては「backlog リクエスト 飛ばし方」といった感じで調べたらwebhookという存在を知った。
詳しく調べたところこれは予め登録したURLにPOSTリクエストを送れるといった機能だと知ったので、これを使えばapiを叩く処理を呼び出せるだろうと判断した。 -
どこでapiを叩く処理を書けば良いか分らなかった。
postリクエストは受け取れるようになった。
しかしそれをどこで受け取り次の処理を行えば良いか分らなかった。
自社プロダクト内で？？とも一瞬考えたが、流石に違うかと考え直した。
新しくサーバーを建てるしかないのかと調べたところgasにたどり着いた。
以下の理由でgasを採用した。
・ 無料。あくまで社内ツールでお金はあまりかけられなかったので、これはとても有り難かった。
・ 簡単にデプロイが出来る。一日でも早く完成させたかったので手軽にデプロイできるのもポイントが高い。
・ ほぼjavascript
ここまで出来ればあとは楽勝だと思っていた。 -
要件を満たせるエンドポイントが存在していなかった。
最後の壁である。
これは完全に僕の調べ不足なのだが要件を満たせるエンドポイントがなんと存在していなかったのだ！！
予想外だったが今更ツールそのものを変えることは出来なかったので既存のエンドポイントを組み合わせるしかないなと思った。
これについてはタスクを完了させたユーザーの他のタスクを全て取得し、それらのステータスから手持ちのタスクがあるかどうかを判断すればいけるのではと判断した。
幸いにもユーザーのタスクを全て取得し、各タスクの詳細を確認するエンドポイントはそれぞれ存在していたのでこの方向で実装することにした。 -
ロジックとチャットツールへの通知を分離した。
弊社は現在チャットワークを使っているが将来的に他のツールへ移行する可能性もあるので分離することでチャットツールの切り替えを容易にした。
まとめ
外部apiを用いてツールを開発するのは初めてだったのでいくつか苦戦する箇所は出てきたのだが、問題をうまく細分化、言語化して調べたおかげで沼にハマることもなく実装を進める事が出来たと思う。
昔と比べて問題を解決する際に上手に細分化できるようになったと感じる。
例えばAというゴールがあったとすると昔だったらきっと「A やり方」などと調べるだろう。
しかし今だったらAにたどり着くにはBする必要がある、そのためにはC,D..といったように切り分けその都度調べる。
エンジニアにとってググり力は必須のスキルなのでそれが上達したのは大きい。
余談
満を持してリリースしたが、最近やる事が山積みでどのエンジニアも手持ちのタスクがなくなるといった事がないので、このツールは日の目を見ずにいる😶
Discussion