Jira の Automation を使ってみた
この記事は NAVITIME JAPAN Advent Calendar 2020 の 16 日目の記事です。
こんにちは、ひよこです。ナビタイムジャパンでユーザーボイスの管理・調査・分析チームで必要な機能の開発を担当しています。
ナビタイムジャパンでは課題管理に Jira を用いており、今年度はクラウド化が進められています。概要はこちらの記事をご覧ください。
ユーザーボイスの管理・調査・分析チームの役割
私たちのチームは、弊社に届いたばかりのユーザーボイスを各専門の部署が適切に扱えるように調査や管理システムの構築を行っています。
ユーザーボイスの活用については、こちらの記事をご覧ください。
ユーザーボイスの中でもルートに関するご指摘(以下、ルート指摘)は、調査の状況を Jira を用いて管理しています。
1. ユーザーからルート指摘が届く
2. ルート指摘コンバータが API を利用して Jira の課題を作成
3. ユーザーボイス調査担当者が調査
4. 必要に応じて他部署に更なる調査や対応を依頼
5. 他部署は改善や不具合の修正を行ってユーザーに届ける
Jira API の使い道
1つ目の使い道は、ルート指摘コンバータによる課題の自動作成です。これは届いたルート指摘を読み込む必要があるため Jira のクラウド移行後もフィールドの設定等を変更してそのまま利用しています。
2つ目の使い道は、ユーザーボイス調査担当者が他部署へ調査結果を添えてさらなる調査や対応を依頼する際に、依頼課題の作成を助けるツールに利用しています。依頼課題の作成は下記のステップとなります。
1. 依頼先の他部署がどの Jira プロジェクトを使用しているか選択
2. それまでの調査でわかったことを転記
3. 部署と内容によっては優先度を変更
4. その他必要なフィールドを漏れなく記載
日々たくさんの調査を行う中で、このステップを漏れなく全て手作業で行うのはどうしても負担感があるため、API を用いた依頼課題作成ツールを調査担当者に配布し、半自動化していました。
クラウド移行のタイミングでこの依頼課題作成ツールを Automation へ置き換えました。本記事では Automation について紹介いたします。
Automation とは
Automation についての公式の説明はこちらをご覧ください。
本記事で使用する用語を整理します。
ルール
Automation の設定の単位
例「コメントがあったら Slack に通知するルール」
トリガー
ルールを開始する Jira のイベント
例「コメントがあったら」「ルールを手動で起動したら」
条件
ルールの中で、課題の状態などにより分岐する条件
例「ステータスがオープンなら」
アクション
ルールの中で何らかの操作を行うもの
例「Slack に通知する」「ステータスを変更する」
トリガー・条件・アクション の組み合わせでルールが構成されます。
Automation のメリット・デメリット
メリットはやはりコードを書かなくて良いことです。Automation について学習すればエンジニアも非エンジニアも共に機能をメンテナンスしていけるので属人化を抑えられます。
デメリットは API と比べてしまうと柔軟性に欠けると感じる時があることです。ただ、このデメリットは「コードを書かなくて良い」というメリットと引き換えに起きていることであり、webhook を使うことである程度回避できるため、Jira で何か自動化したい場合はまず最初に Automation を検討する価値があると思います。
私たちのチームがなぜ Automation を使ったのか
依頼課題作成ツールの悩み
以前から使用してきた依頼課題作成ツールは調査を行い、他部署へ依頼課題を作成するにあたってはとても便利なものでした。
一方でツールの運用はチームにとって負担感がありました。
依頼先となる他部署の変更があると、設定ファイルに手を入れる → ビルド → 調査担当者に配布 という工程が必要でした。さらに一部の「設定」は当初設計された設定ファイルに入れ込むことが難しかったため、コードの中に埋め込まれてしまっていました。
そのような事情もあり、設定変更の際は必ずこのツールに触れたことのあるメンバーが対応していました。特に非エンジニアであるマネージャーは、たとえタスクに余裕があっても設定変更に手を出せないという状態になってしまっていました。
クラウド化をサポートする開発サポートチームのメンバーの一人が、私たちのチームの元メンバーで状況を知っていたため「依頼課題の作成は Automation の利用を検討してはどうか？」と提案してくれました。
クラウド版の Jira ではサーバ版と異なり拡張機能の導入なしで Automation の機能が利用可能になっており、これを用いることでコードをほとんど書かずに今までの依頼課題作成ツールと同様のことが実現できるようになりました。
Automation の利用で解決したこと
まず、コードに埋め込まれてしまっていた「設定」が、Automation の条件やアクションといった設定になりました。今までは設定ファイルとコードを確認しないと「設定」がはっきりしませんでしたが、Automation の設定を見るだけで設定の確認が済むようになりました。
次に、設定変更が Jira 上で済むことにより、ビルドや配布の手間もなくなり、さらに非エンジニアのマネージャーも含めチーム全員で設定変更の対応ができるようになりました。
※余談ですが、その非エンジニアであるマネージャーが過去に発表した資料がこちらです。チーム全員が設定変更できるというのは、エンジニア・非エンジニアの垣根を超えるべきところでは超えていくということで、この資料の内容と繋がっていると思っています。
課題から別の課題を作成する方法
ある課題を元に別の課題を作成することは Automation の「課題を作成」の機能で可能です。調査課題から依頼課題を作成するように設定を行いました。
画像の左がこのルールの全体の流れです。トリガーは最初の1つだけですが、その後の条件やアクションは自由な順番で組み合わせることが可能です。この例では条件とアクションを1セットだけにしていますが、実際は他部署の数だけ並べて設定しています。要約や説明も簡単な例にしていますが、元の課題のフィールドの内容を埋め込むことが可能です。
監査ログがあるため、Automation のルールの変更(構成の変更)や、実行がいつ成功/失敗したかを後から確認することができます。ルールに問題があった場合はエラー内容も表示されます。
作成された課題への添付ファイルのコピー
調査ではスクリーンショット等の画像が調査結果になることもあり、依頼課題の作成にはそれらの添付ファイルもコピーが必要になります。しかし Automation の機能単独では課題作成時に添付ファイルのコピーはできません(2020/12/16現在)。Automation では webhook が利用できますので、これを使って課題作成後に API で添付ファイルのコピーを行いました。
※添付ファイルのコピーは、コピーした分だけ重複して容量を使うことになってしまいます。ですので閲覧権限等に問題がなければコピーはせずに、リンクした課題を辿って添付ファイルを参照してもらうことをお勧めします。ここでは Automation の機能だけでは実現しきれないことが API を利用して実現できる例としてご紹介します。
添付ファイルのために作成した webhook
webhook は AWS Lambda + API Gateway で構築しました。webhook のリクエストには Automation のトリガーになった課題(この場合は調査用 Jira の課題)の情報が渡されます。Automation から呼び出される webhook に対して「Automation 内で新しく作成された課題のキーはこれとこれ」のような情報を渡すことはできません。
添付ファイルのコピーをしようとすると、処理の開始時点では
・コピー元はわかる
・コピー先はリンクされた課題のどれか (どれかは不明)
という状態になります。
そこで条件判定によって擬似的に新しく作成された課題を特定する処理を作りました。
1. あらかじめ課題作成時に元の課題と作成される課題をリンクする
2. webhook 内で、リクエストとして渡された作成元の課題の情報からリンクされた課題を取得する
3. リンクされた課題について内容や作成日時でフィルタリングをして、新しく作成された課題を特定する
※新しい課題の内容(要約や説明)は Automation のルールに沿って生成されているので、新しい課題ならば webhook 内でもそのルール沿った内容になっているはずであり、そうでないものは別に人の手でリンクされたものと見なす
以上のステップで、コピー先の課題の特定はできました。
Automation の「実行者」と作成された課題の報告者
添付ファイルのコピー処理を実装して意気揚々と他部署にテスト課題を作成させてもらったところ、課題はできるが添付は失敗するという状態になりました。この時課題作成を行った部署の設定では「課題の報告者は添付ファイルの追加をできるが無関係のアカウントはできない」という権限設定になっていることが原因でした。Automation は実行者を設定することができ、「Automation for Jira」か Automation を設定しているユーザ本人に設定できます。
Automation の実行者をユーザに設定した場合、別の調査担当者が Automation を起動しても実行者に設定されたユーザの権限として Automation は動作し、その中で作成される課題の報告者も設定された実行者となります。Automation の実行者と webhook 内の API を実行するアカウントを合わせることにより無事に課題作成から添付ファイルのコピーができるようになりました。
なお、記事の流れですと「実行者」という言葉が不自然に思えますが(Automation を起動する調査担当者を指すべきでは？)、Automation の設定画面や説明を見ると「手動によるトリガー」よりも「課題が作成された」「フィールドが変更された」といったトリガーを使うことを Automation は想定していそうです。後で API を利用するなど、誰かが起動した訳ではないが誰かの権限で動いて欲しい、ということを考えると「実行者」という名前の設定があるのは Automation 全体を見ると自然そうです。
Jira の API とそれを利用するためのライブラリ
今回は Python を使用しており、課題の情報の取得や添付ファイルの追加といった Jira の API のアクセスにはこちらのライブラリを使用しました。
もともとサーバ版でも API を使用しており、クラウド版への移行では API の差分が気になっていました。クラウド版でもサーバ版と同じバージョン2が使用でき、ライブラリにもサーバ版・クラウド版の違いを吸収するコードがあるようで、私たちがライブラリから利用する限りでは違いはないように見受けられました。
※Atlassian のサイトを見てもサーバ版とクラウド版の API の違いの一覧のようなものは見つけられなかったため確実ではありません。もし同じようにクラウド移行して API を使い続けられる場合はこれを鵜呑みにせずに確認された方が良さそうです。
物足りなかったこと
コードを書かなくても様々な自動化ができる Automation ですが、対話型の処理はできないようです。Automation の「実行者」の扱いの部分とも関連しますが、「チケットが作成されたら通知」のように人が意識的に介在しない処理を自動化することが多いだろうということを考えると、対話型の処理はしない前提になっているのかなと思います。
そのため Jira の利用者が課題から Automation のトリガーを手動で起動し課題の記載内容が足りなければエラーにして問題箇所を伝えるといった処理は Automation ではできないので、そこだけは仕方ないと思いつつ少々物足りないと感じました。
まとめ
Automation を利用することでコードを書かずに、Slack 通知や担当者の変更、別の課題の作成など様々な処理が自動化できます。コードを書かない分コードに起因するバグは減りますし、何よりコードを書けないメンバーもメンテナンスに関わりやすいメリットがあります。Automation 単独で足りない機能については webhook から書いたコードを呼び出すことでカバーできます。今回書いた添付ファイルの処理はやや大掛かりなものかと思いますが、条件に基づいた通知や担当者変更といった処理はコードを書かなくて済むので管理も楽ですし素早く設定可能です。
クラウド版の Jira をご利用でまだ Automation は利用したことがない方はぜひ一度触れてみてください。