この記事は「ウィルゲート Advent Calendar 2022」の 3 日目の記事です！
はじめに
こんにちは。
株式会社ウィルゲートの夏目です。
所属は開発ではないのですが、今回参加させてもらいました！
現在はセールステック事業部のサポートチームを本所属として、他に2部署兼任しています。
営業活動以外の「なんとかしたいこと」をなんとかする役割が多いという業務の性質（？）上、最近GASで何かを作ることが多くなりました。
今回は、その中でもBacklogのAPIを使って作った自動通知のことを取り上げ、施策の効果とともに考察していこうと思います。
Backlogの期限切れ通知を作りました
こちらのページを参考に、期限切れ通知を作成しました。（ありがとうございます）
参考ページ
❶メイン処理
https://inet-engineer.hatenablog.com/entry/2018/12/26/092016
※サンプルコードで載せて頂いているところの「return message;」をfor文の外に出して使いました。
❷休日は通知飛ばさない
https://dev.classmethod.jp/articles/202001-workday-only-gas/
❸本家BacklogAPI（課題取得）
https://developer.nulab.com/ja/docs/backlog/api/2/get-issue-list/#
【前提】
- Backlogに期限付きのチケットがある
- コミュニケーションツールはslack
GASでトリガを設定し、任意の頻度で該当するチケットを通知しています。
↓↓↓↓↓実際の通知↓↓↓↓↓
こちら本所属の部署用に作ったのですが、他にもBacklogを使っているチームがあり、要望があったため横展開しました。 （ブログを書いている間に、もう一つ横展開しました（笑）
それぞれの運用状況
各チームをABCと称し紹介します。
[業務に取り込んでいい感じ]Aチーム
通知：朝夕
夕会で通知をチェック
Backlogの導入とほぼ同時に導入
→期限切れは大体防げていて、切れていても夕会でチェック
[強靭プレイで回っている]Bチーム
通知：週一
各自Slack上で報告
人の運用を通知に切り替えた
→Slackの自動通知を見て各自対応し、スタンプで報告する運用で回っている
[改善が必要そう]Cチーム
通知：昼
各自に更新をゆだねている
Backlogの導入とほぼ同時に導入
→期限切れが多く出てしまっており、管理ができている状態ではない
同じ通知の機構を使っていますが、それぞれ業務への取り込まれ方や状況がかなり異なることがわかります。
考察
各チームの導入後の動きから、いくつか考察を…。
- 【Aチーム】システム＋人の動きをセットで設計
→性悪説に則り、個々人がチェックしない前提で夕会にチェックを取り入れることで、チケットの更新を忘れない体制ができる。
若干の時間はかかるが、定例会のついでに取り入れれば無理ないイメージ。
- 【Bチーム】人がやっていた業務の自動化は固い
→すでに人が手動で行っているものを自動化するのであれば、プラスでフローを考える必要はない。
ただ、個人的にBチームがこの運用（通知のみ）で回ってるのはすごいと思う。
- 【Cチーム】期限切れの通知で一番防ぎたい「チケットの期限切れの放置」は、一度はじまると止まらなくなる。
→多すぎる通知は見られなくなるため、仕切り直しが必要。チケットの更新自体への意欲が起きない場合、チケットの粒度を変えたり更新フローを整える必要がある。
タスクの見える化＝Backlog導入が主目的だったので、期限切れ通知はそもそも必要か見直すとよいかも。
まとめ
ご紹介した通り、同じ機構であってもチームによって運用の仕方や効果がバラバラでした。同じ社内であってもこのような状態ですので、企業が変わればさらに変わるのでは？と思っています。
本記事をまとめていて改めて、どんな施策も「人」とうまくかみ合わせることが必要だなと強く感じました。
GASは
- ググったら情報がたくさん出てくる
- 特別な環境設定が不要
といった利点があると思うので、小回りを利かせたい社内ツールの作り始めとしてはちょうどよいと思っています。
比較的気軽に作成・改変できるので、使う人たちで都度話しあったりできるといいと思います～！！
非エンジニアの方もとっつきやすいと思うので、ぜひ！！
師走は本当に時が走り去っていきますね…！「ウィルゲート Advent Calendar 2022」も走っていきますよ…！！！
明日はことみんの「Goとスクレイピングに同時に入門する」です！乞うご期待！！
