Jira Expressions：JQLの限界を突破し、ワークフローを「自律進化」させるコード術
Jiraの自動化（Automation for Jira）を「GUIのポチポチ作業」だと思っているなら、君はまだJiraの真のパワーの1％も引き出せていない。
JQL（Jira Query Language）は強力だ。だが、それはあくまで「静的な検索」に過ぎない。我々エンジニアが求めるのは、「課題のコンテキストを動的に解釈し、その瞬間の正解を導き出す自律的なロジック」だ。
そこで登場するのが、Jira内部で叩くことができる最強のDSL、「Jira Expressions」だ。今日は、JQLでは絶望的に無理な複雑な条件分岐を、Automationルールにどうねじ込むか。その深淵へ案内しよう。
—
1. Jira Expressionsが「神」である理由
JQLがSQLのサブセットだとすれば、Jira Expressionsは「Jiraの内部データ構造（DOMに近い）を直接操作する動的言語」だ。
- JQLの限界: `status = Done`（ステータスがDoneであることしか分からない）
- Expressionsの真髄: `issue.subtasks.all(s => s.status.name == ‘Done’)`（子課題すべてが完了しているかという「階層的依存関係」を判定できる）
APIを外部サーバーで叩く必要はない。すべてはJiraのイベントループ内で解決する。これにより、外部連携のオーバーヘッドをゼロにし、ミリ秒単位のレスポンスでワークフローを制御できる。
—
2. 実践：親課題のステータスを「子課題の全完了」で自動遷移させる
多くのチームが「子課題が終わったら親を閉じたい」と願うが、標準機能では力不足だ。Jira Expressionsを使えば、スマートな判定が一行で書ける。
Automationの条件判定（Advanced Compare Condition）で以下を設定せよ：
// 親課題の全サブタスクが「完了」または「クローズ」ステータスにあるか判定
issue.subtasks.all(s => [‘Done’, ‘Closed’].contains(s.status.name))
- 解説: `all()` メソッドは、サブタスクのリストを走査し、条件を満たさないものが一つでもあれば即座に `false` を返す。高効率かつクリーンだ。
—
3. 高度なバリデーション：所属グループによる動的アクセス制御
特定の権限グループに属するユーザーだけが、特定のステータスへ移行できる「動的なバリデーション」が必要なケースは多い。
Automationの「Issue Fields Condition」にて利用：
// ユーザーが「dev-ops-admins」グループに属しているか、あるいは作成者本人であるか
user.groups.contains(‘dev-ops-admins’) || issue.reporter.accountId == user.accountId
- アーキテクチャの視点: この判定はクライアントサイドではなくサーバーサイドのコンテキストで行われるため、UIを改ざんしても突破できない。堅牢なガバナンスを実現する必須テクニックだ。
—
4. パフォーマンスを極める：最適化ハック
Jira Expressionsは強力だが、`issue.comments` のような巨大なプロパティを安易に全件走査（`map`や`filter`）すると、APIの実行時間に悪影響を与え、スロットリングのリスクが高まる。
パフォーマンス最適化の鉄則：
1. Lazy Evaluationの意識: `all()` や `exists()` を使い、条件に合致した瞬間に評価を終了させること。
2. 不要なフィールド参照の回避: `issue.fields` を多用せず、必要なプロパティだけを絞り込む。
3. 計算の局所化: 複雑な計算が必要な場合は、Automationの「Lookup Issues」で対象を事前に絞り込み、Expressionsで判定するのはその「結果」に対してのみ行うこと。
—
5. 伝説的アーキテクトからの助言：なぜコードで制御すべきなのか
GUIによる設定は、最初は楽だ。だが、複雑化するにつれ、それは「スパゲッティ・ワークフロー」という負債を生む。
- 可読性: GUIの条件設定ツリーを読み解くより、数行のExpressionsを読む方が圧倒的に早い。
- 再現性: 複雑な条件は、JSON形式でエクスポートし、Gitでバージョン管理できる。これが「Infrastructure as Code (IaC)」のJira版だ。
最後に
Jira Expressionsを使いこなすということは、Jiraという巨大なブラックボックスを、君の意のままに操るOSにするということだ。
「これ、Jiraの標準機能じゃ無理ですよね？」というPMの相談に対し、「いや、Expressionsで書ける」と即答できるか。それが、君が現場で真のアーキテクトとして信頼されるための第一歩だ。
さあ、GUIから卒業し、Jiraを「設計」しろ。そこにしか、開発チームのベロシティを極限まで高める未来はない。
—
筆者：Jiraの内部構造を解析し尽くしたアジャイル・アーキテクトより