Jiraはチューリング完全
(seriot.ch)- Jira Automation は、2つの無限カウンタと有限の命令状態を持つ Minsky マシンを表現でき、Jira のチューリング完全性を示せる
- Epic の状態は プログラムカウンタ、リンクされた Bug と Task の数は2つのレジスタとなり、Automation ルールが命令ごとのディスパッチテーブルになる
INCとDECはリンクされた課題の作成・削除で実装され、条件分岐は JQL 条件ルール でリンク課題数を調べて決定される- 加算の例では
A=2、B=3から Bug を減らし Task を増やし、実際の*.atlassian.net実行で Task 5個 と停止状態に到達する - Fibonacci の例では課題タイプ変換でループを減らし、Jira Cloud の チェーン深度制限 10 に達したら手動再トリガーで継続できる
Jira 自動化で作る Minsky マシン
- Jira Automation は、2つの無限カウンタと有限の命令状態を持つ Minsky register machine を表現できるため、Jira のチューリング完全性を示す還元が可能
- Minsky が1967年に証明したモデルは、
INC r; goto Sとif r == 0 goto S else (DEC r; goto S')だけで構成される - Jira の構成要素は Minsky マシンの各要素に対応する
- Register A: リンクされた Bug 課題の数
- Register B: リンクされた Task 課題の数
- Program Counter: 単一の Epic 課題の状態
- Dispatch Table: 命令状態ごとの Jira Automation ルール
- Clock: 自動化がトリガーする遷移、またはチェーン制限後の外部再トリガー
- Epic の状態が現在の命令をエンコードし、Automation rules がリンク課題数を確認して次の状態へ遷移する
INCとDECは該当タイプのリンク課題の作成と削除で実装され、条件分岐は JQL 条件ルール で処理される
実行例と制限
- 加算プログラム は、
Aを減らしながらBを増やす Minsky プログラムで構成される1. if A == 0 goto 3 else (DEC A; goto 2) 2. INC B; goto 1 3. HALT - 最小実装は、1つの Epic、リンク課題5個、命令状態ごとに1つずつの Automation ルールで構成される
-
ワークフローとルール
- Jira Workflow に初期状態
BACKLOG、続いてTODO、DEV、PRODを作成し、すべての状態間で相互に遷移できるよう設定する BACKLOG状態の Epic を1つ作成するTODOルールはDEC A; if A=0 halt, else goto DEVを実装する- Epic の状態が
TODOに変わるとトリガーされる - リンクされた Bug が1つ以上あれば Bug を1つ削除し、Epic を
DEVに遷移させる - Bug がなければ Epic を
PRODに遷移させて停止する
- Epic の状態が
DEVルールはINC B; goto TODOを実装する- Epic の状態が
DEVに変わるとトリガーされる - 新しい Task を作成して Epic にリンクする
- Epic を
TODOに遷移させる
- Epic の状態が
- どちらのルールでも "Allow rule to trigger other rules" を有効にする
- Jira Workflow に初期状態
-
初期値と結果
- Epic に Bug 2個と Task 3個をリンクして
A=2、B=3として初期化する - Epic を
TODOに遷移させると、次の流れで連鎖実行される(2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD - 実際の
*.atlassian.netインスタンスで実行され、最終的に Epic はPRODに到達し、Bug 0個と Task 5個がリンクされる - この実行は Jira 自動化で
2 + 3 = 5を計算した結果になる
- Epic に Bug 2個と Task 3個をリンクして
-
Fibonacci 構成
- Convert Issue Type は、Bug → Story、Story → Task のように課題タイプを即座に変更できる
CONVERTはDEC + INCで表現でき、計算能力自体を拡張はしないが、移動ループのディスパッチテーブルを減らして、より複雑なプログラムを扱いやすくする- Fibonacci は
(A, B) → (B, A+B)として表現され、3つのレジスタA=Bug、B=Task、C=Storyと3つの状態TODO、QA、DEVで構成されるTODO: if any linked Task exists: CONVERT Task → Story INC Bug transition to TODO else: transition to QA QA: if any linked Bug exists: CONVERT Bug → Task transition to QA else: transition to DEV DEV: if any linked Story exists: CONVERT Story → Bug transition to DEV else: transition to TODO - 初期状態は
A=1、B=1、C=0で、Task の数であるBに1, 1, 2, 3, 5, 8, 13, ...の数列が現れる - 加算マシンと異なり、Fibonacci マシンには停止状態がなく、Jira Cloud のチェーン深度制限 10 に達するまで実行される
- 制限に達したら、運用者が Epic を再トリガーして継続でき、1回の状態編集で連鎖実行を再開できる
- Jira Data Center は
automation.rule.execution.timeoutと関連設定を構成可能なプロパティとして公開している - 無限の課題生成とルール実行を仮定すれば、Jira 自動化言語は2カウンタマシンをエンコードでき、物理コンピュータも有限であるという通常の基準では、Jira Cloud の有限クォータはこの構成への反証にならない
1件のコメント
Hacker Newsの意見
Jiraは完全にひどいので、別のどんな形のひどさにも変化しうる潜在力を持っている
MarxがAtlassianを知っていたら、Grundrisseはものすごく燃え上がっていただろう
2014年のGitHub Issuesと今の姿を見比べればいい: https://github.com/features/issues
しかも延々と、延々と、重複機能を追加し続けている
Jiraは人気があり、好みの言語向けのAPIラッパーもよく揃っている
ハッカー気質のある企業開発者たちが、PythonのコマンドラインスクリプトのようなものでJiraにやらされる作業の大半を自動化していないのが不思議なくらいだ
Jiraを押し付ける人たちより自分のほうが一桁以上楽に使えるようにしてしまえば力関係がひっくり返り、Jiraは自分を守るために押し付ける道具になる
ときどきほとんど悪意を持ってJiraを使ってみたが、責任回避には素晴らしい
問題が起きたら「これは私が書いた何百件ものJira更新に全部明確に書いてありましたよね、読んでいましたよね？」と言えばいい
今はAIもあるのだから、カスタムスクリプトで全部まとめてAIにJiraの雑務をやらせればいい
APIでできることがUIでは許可されていない場合も多く、しかもみんなUI基準で動くので、変に壊れた隅へ迷い込みやすい
たとえばcustom_field_5537がcustom_field_442と対になっていないと他人のダッシュボードに表示されない、ということに気づかないかもしれない
またcustom_field_10995は整数フィールドだと主張し、XMLでも整数として返すのに、チケット作成時には文書化されていない魔法の定数文字列を使わなければならず、更新時にはそうでもない、という具合だ
Web UIはそうしておらず、HTMLとリクエストにはただの整数が入っていて、その文字列の80%だけがドロップダウンの表示テキストと一致する
Jira自動化は私が経験した最悪のプログラミング体験だった
もっと単純な設定が存在し、かなり簡単な場合もあるのは確かだが、それでもひどすぎる
悲しいことに、それでも注いだ労力に完全に見合う。強く勧める
各チケットに人が読める説明用のカスタムテキストフィールドを追加し、リリースがデプロイされるとデプロイスクリプトがタイムスタンプを自動で埋めていた
私たちは作業単位ごとにチケットを1件ずつリリースし、1日に何件も処理していた
カスタムフィルターと組み合わせることで、Jiraは各ボードと会社全体について人が読める変更ログを提供し、これらのメッセージがSlackでビジネス側に送られて、何がデプロイされたのかを全員が把握できた
それはコード変更に結びつく検索可能なリリース監査ログでもあった
デプロイ処理がJiraチケットの状態も遷移させるので、開発者はチケットをmainにマージするだけで、デプロイされ、Jiraでも完了になった
定型作業用のチケットを自動生成する小さなスクリプトもたくさんあった
何年も非常に堅牢で、今でも動いている可能性が高い
カスタムフィールドの命名規則はいまひとつだったが、チームがJira設定を管理しているなら全員が同じ基準を保つのは難しくなかった
最初はJiraが好きではなく、昔は問題も多かったが、最近は設定さえうまくやればそこまで悪くない
自分の会社なら選ばないが、開発者でもあり管理者でもあり最終利用者でもあり社内ツール開発者でもあった立場からすると、構成されて動き始めればたいてい邪魔にはならない
テキストをさらに追加すれば、Jiraはsomehowその大量のテキストの上で常にすべてを自動実行することになり、もっと遅くなるだろう
会社に暖房が必要ならJiraを使えばいい
かなり柔軟で、AIのおかげでさらに可能性が広がった
ほとんどのプロセスがJiraに依存しており、特定の遷移が自動化用のWebhookを実行する
AIへのアクセス権を得て最初にやったことの一つがJira MCPを作ることだった
今ではJiraをほとんど直接触らないようにしていて、ClaudeにJiraの課題作成、コメント記入、サブタスク作成、課題の関連付けなどをやらせている
以前は実装方法を調べてタスクに分解しなければならないたびに怖かった
細かく分けるほど、それぞれの作業を入れるJira課題をさらに多く作らなければならなかったからだ
今では全部をファイルに整理して、大規模言語モデルにJiraの雑務を任せればいい
以前働いていた会社に戻ったら、まだJIRAを使っていた。
面接では当然「JIRAですか、まだそれ使ってるんですか？ 使えますよ」と答えた。
実際使えはするが、最新のJIRAを見て本当に衝撃を受けた。
細かい不便が千個くらいあって、最悪の一つはテキストをダブルクリックして選択しようとすると、いきなりフィールドが編集モードに入ることだ。
私が覚えているのは JIRA Server 4.0 で、ここで当時を振り返れる: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
十分に拡大すると、各イシューにはタイトル、種類、修正バージョン、影響バージョンなどがあり、そのままコメントへつながる構造になっていた。とてもシンプルだった。
ものすごくイライラする。基本的なテキスト操作すらおかしい。
なのに、それを気に入っているプロジェクトマネージャーがいると言っていた。
単語全体を選ぶためのダブルクリックドラッグを使わないからだそうだ。
いつものことだが、コンピュータをやっと使える程度の人たちの都合のせいで、より熟練したユーザーが引きずり下ろされる。
何か見落としているのか、時間の穴に落ちたのかと思う。
なぜ Jira をVisicalcみたいに語るのかわからない。
今はIT企業で働いていないので、この2年の間に何か大変動を見逃したのかもしれない。
4.x から 6.x に移るときにも、あるいは OFBiz のガタガタした箱や、見た目だけ合わせたまったく別の製品群のように、細かな不便も一緒についてきた。
そのエンジニアたちはとっくに去り、1株280ドルも一緒に持っていった。
JIRA の根本的な問題は、まともに設定する権限が常にごく少数にしかなく、その人たちが面倒くさがるか、時間がないか、毎日使わないので気にしないことにある。
もちろん問題はそれだけではない。
想像しがたいほど遅いし、イシューが別のイシューの親になれないといった妙な制限もある。
JIRA は遅すぎるし、管理者たちはまともな設定方法を知らないように見えた。
使っただけでトラウマがある。
この惑星には、そのツールを正しく設定できる人間が一人もいないだけだ。
人間の無能を理由にツールに責任を負わせることはできないだろう。
では誰のために作られたのか、というのはまったく別の問題で、今は議論しないほうがいい。
本質的にチケットシステムとは、チケットとチケットの関係や状態を保持するデータベース以上のものではない。
もちろん、関連チケットやカスタムフィールド、プラグインが多ければ複雑さが爆発することはあり得る。
それでも、単純なテキストデータと添付ファイルを扱う代物が、どうしてあれほど耐えがたいほど遅くなり得るのか理解できない。
ついに Jira でDoomができるようになった。
https://mattrickard.com/accidentally-turing-complete
つまり、ある Jira のタスクが停止するかどうか判定できない理由が説明されている。
Jira は、その結果として生まれる悪魔どもを始末するためのポンプアクションショットガンも提供してくれるのか？
代わりにAzure Boardsを使ってみれば、JIRA を好きになるはずだ。
Microsoft がもっと悪くできないソフトウェアはこの世にないからだ。
Outlook に対する軽蔑をきちんと表せる言葉を見つけるのは難しく、「嫌い」では話が始まらない。
メールを受け取って送るという最も基本的な作業すらまともにこなせない。
スマホにメール通知が来てアプリを開いても何もなく、下に引っ張って更新しても何も起きない。
たいてい 1〜15 分後になってやっと表示される。
Outlook でやることは何もかもがひどく煩雑だ。
昔、Office 2003 の時代にも Outlook を使っていたが、ここまでひどかった記憶はない。どうしてここまで退化したのかわからない。
Teams については語り始めたくもない。あのプログラムが何の問題を解こうとしているのかもよくわからない。
共有ファイルは OneDrive にあるのに Teams にもあり、なぜか Outlook にもある。
コンピュータのバックアップファイル、CloneZilla イメージ約 30GB を OneDrive/Teams/Outlook に移さなければならなかったが、永遠にかかり、Win11 の入った 6 コア Ryzen ノートPCのファンがその間ずっと狂ったように回っていた。
どうして？ なぜ？
すべてのワークフローおよびオーケストレーションエンジンはチューリング完全だ。
そもそもの目的が実行フローを自動化することだからだ。
あるいは、人間が再トリガーして中断した地点から再開できるのか？
第一に、JIRA はオーケストレーションではない。
第二に、ワークフローの仕事とは、ある種の状態を外部情報に結びつけ、それらを簡単に操作できるようにすることだ。
チューリング完全であるには、トリガーとルール、無限カウンタのようなもの、2つのスタック、双方向テープのようなものが必要だ。
違うというなら証明してみてくれ。
Jira の自動化は気に入っている。
Jira を使う新しいチームに入ると、サブタスクのストーリーポイントを自動集計して親タスクのストーリーポイントを埋めたり、十分に精緻化された属性がなければチケットを自動でバックログに戻したりする自動化を設定する。
たとえば担当者、ストーリーポイント、優先度、説明などが欠けている場合だ。
1スプリントも過ぎればチームボードはずっと整理される。
なぜこれがデフォルトでないのかはわからないが、自動化で簡単に直せる。
担当者はその作業を引き受けた人に割り当てられればいいのであって、精緻化段階の一部であるべきではない。