Jiraの自動化ルール実務ガイド:トリガー・条件・アクションでステータス遷移・通知・アサインを自動化する設計手順

ボード・ワークフロー・JQLの先にある、運用工数の自動化

「Jiraのボード運用実務ガイド」でスクラムボードとカンバンボードの使い分けを設計し、「Jiraのワークフロー・課題タイプ設計」でステータスと遷移を固め、「JQL実務ガイド」で検索とフィルタを使いこなせるようになると、次に出てくる課題は「このステータス遷移やアサインの変更を、毎回手作業で行い続けるのか」である。ステータスが変わるたびに担当者へ通知を書く、レビュー待ちに入った作業項目を手動でアサインし直す、といった作業は、件数が増えるほど抜け漏れの原因になる。

Jiraはこの手作業を、トリガー・条件・アクションの組み合わせで置き換える自動化ルール(Jira Automation)を標準機能として備えている。この記事は、Atlassian公式ドキュメントの仕様から、自動化ルールの構成要素と設計手順、使用量制限、実行を記録する監査ログまでを整理する。累積フロー図やベロシティチャートで進捗を数字として読む方法は「Jiraのレポート機能実務ガイド」が扱っており、本記事はその手前にある「運用そのものを自動化ルールに任せる」段階を扱う。ツールそのものの選定は「プロジェクト管理ツール比較」を参照してほしい。

この記事の編集基準

本記事にアフィリエイトリンク・紹介料・掲載料は一切ない。仕様はAtlassian公式サポートドキュメントを出典としている。

自動化ルールの基本構造:トリガー・条件・アクション

Atlassian公式ドキュメントは、自動化フローを「トリガー」「条件」「アクション」という3つの部品の組み合わせとして説明している。トリガーはフローを開始させる契機であり、1つのフローに必ず1つ必要になる。条件は、トリガーの後に任意で追加できる部品で、設定した基準に合致した作業項目だけに実行範囲を絞り込む。アクションは実際の処理を行う最終段階であり、フローを完成させるには少なくとも1つが要る。

フローを構成する各部品(トリガー・条件・分岐・アクション)はステップと呼ばれ、公式ドキュメントは「フローが有効化されると、ステップは表示されている順番に上から下へ実行される」と説明している。後続のステップが前のステップで作られた情報(スマート値など)を必要とする場合は、その情報を作るステップより後ろに置く必要がある。フローの作成方法にはテンプレートを使う方法とゼロから組み立てる方法があり、いずれも保存したうえで有効化して初めて動き出す。

ルールを作成・管理できる権限は、対象がスペース単位かサイト全体かで変わる。Company-managed spaceでは「Administer spaces」と「Browse spaces」権限を持つユーザーが、Team-managed spaceでは「Administrator」アクセス権を持つユーザーが、それぞれ自分のスペース内のフローを作成・管理できる。「Administer Jira」というグローバル権限を持つユーザーは、単一スペースから複数スペース、Jira全体まで、範囲を問わずフローを作成・管理できる。

トリガー:何をきっかけに動かすか

Atlassian公式ドキュメントが一覧するトリガーは、DevOps連携やJira Service Management向けを含めると50種類を超える。このうち、PM・PMOが運用工数の削減で使う頻度が高いものは次のとおりである。

条件:トリガーを絞り込む

条件は、トリガーが発火した作業項目のうち、実際にアクションを実行してよい対象だけに絞り込むための部品である。

アクション:実際に何をするか

条件を満たした作業項目に対して、実際の処理を行うのがアクションである。ステータス遷移・アサイン・通知は、いずれも公式が用意する標準アクションで実現できる。

設計手順:ステータス遷移・通知・アサインを自動化する

ここまでの部品を、実際にルールを組み立てる順序として並べ直す。

使用量制限を超えない設計にする:月間ステップ割り当て

自動化の使用量は「ステップ」という単位で計測される。Atlassian公式ドキュメントは、ステップを「トリガー・条件・アクション・分岐・ループを含む、自動化フローの実行された部分1つ」と定義している。ステップは組織単位でプールされ、Jira・Confluenceなど複数のAtlassian製品をまたいで合算される。

個々のルールにも上限がある

月間の総量とは別に、1本のルールにも上限がある。Atlassian公式ドキュメントによると、通常のフローは条件・分岐・アクションの合計が65ステップを超えて構成できず、アドバンストフローではこの上限が500ステップまで広がる。この上限があるため、1つの工程に絞ってルールを設計する(STEP1)方針は、上限に抵触しにくくする設計そのものにもなる。

フローが短時間に自分自身または他のフローを連鎖的にトリガーする回数には、ループ検出の上限として10回が設定されており、これを超えると実行が停止する。同時に実行できるフローの数(同時実行数)はプランによって異なり、Freeは5、Standardは10、Premiumは20、Enterpriseは30である。複数のAtlassian製品を利用している場合は、その中で最も高いプランの上限が適用される。

運用開始後は監査ログで実行結果を確認する

自動化ルールは、有効化して終わりではない。Atlassian公式ドキュメントによると、監査ログには実行日時、実行ごとに割り振られる識別番号、フロー名、実行結果(ステータス)、実行にかかった総所要時間が記録される。各ログは展開すると、フロー内の各ステップの詳細と、ステップごとの所要時間まで確認できる。

監査ログの保持期間は過去90日間であり、それより古い記録は自動的に削除され復元できない。管理者は個々のフローの監査ログのほか、スペースまたはサイト全体の直近の実行状況をまとめた表からも実行結果を確認できる。有効化したルールが意図どおりに動いているか、想定より頻繁に実行されていないかは、この監査ログを定期的に開いて確認する運用が必要になる。

まとめ:ボードとワークフローの設計があってこそ自動化ルールが機能する

自動化ルールは、「Jiraのワークフロー・課題タイプ設計」で固めたステータスと遷移、「JQL実務ガイド」で使いこなした検索条件があってはじめて、狙った作業項目だけを正確に動かせる。ステータスや課題タイプの設計があいまいなままトリガーと条件を組んでも、対象がずれて誤った通知やアサインを生む原因になる。

運用工数を削減する自動化ルールと、「Jiraのレポート機能実務ガイド」で扱った累積フロー図・ベロシティチャート・コントロールチャートは、どちらもボードとワークフローの設計の上に成り立つ。手作業を自動化ルールに任せたら、その結果が数字にどう表れているかをレポートで確認する、という一連の運用に位置づけて使うとよい。