概要
- Jiraのオートメーション機能 は チューリング完全性 を持つことを証明
- Minskyマシン （2レジスタ計算機）を Jira上で実装 する方法を解説
- 課題リンク数・Epicのステータス で計算状態を表現
- 加算・フィボナッチ計算例 で動作を実演
- Jiraの実用的な複雑性 がプログラムと同等であることを示唆
Jiraはチューリング完全：MinskyマシンをAtlassian Automationで構築
- Jira（Atlassianのプロジェクト管理ツール） が チューリング完全 であるというエンジニアリングの通説
- これまでは曖昧な主張が多かったが、本記事では 厳密な証明 と 具体的な手順 を提示
Minskyマシンの計算モデル
- Minskyレジスタマシン は 2つの無限カウンタ と 有限の命令集合 で構成
- INC r; goto S （レジスタrをインクリメントし状態Sへ遷移）
- DEC r; if r==0 goto S else goto S' （レジスタrをデクリメントし条件分岐）
- 加算プログラム例
- DEC A; if A==0 goto 3 else goto 2
- INC B; goto 1
- HALT
- Minsky（1967年）がこのモデルの チューリング完全性 を証明
Jiraへのモデル写像
- レジスタA ：Epicにリンクされた Bug課題の数
- レジスタB ：Epicにリンクされた Task課題の数
- プログラムカウンタ ：Epic課題の ステータス
- ディスパッチテーブル ：各状態ごとの Jira Automationルール
- クロック ：自動化による遷移、または手動トリガー
- INC/DEC ：課題の 作成/削除 で実現
- 条件分岐 ： JQL条件付きルール で実装
加算マシンの実装手順
-
1. ワークフロー作成
- ステータス： BACKLOG, TODO, DEV, PROD
- どの状態からも他の状態へ遷移可能
- Epic課題 をBACKLOGステータスで作成
-
2. TODOルール（DEC A; if A=0 halt, else goto DEV）
- トリガー：EpicのステータスがTODOに変更
- Bug課題が1つ以上：Bugを1つ削除しEpicをDEVへ
- それ以外：EpicをPRODへ（HALT）
-
3. DEVルール（INC B; goto TODO）
- トリガー：EpicのステータスがDEVに変更
- 新規Task課題を作成しEpicにリンク、EpicをTODOへ遷移
-
4. レジスタ初期化
- Epicに Bug 2件（A=2）、Task 3件（B=3） をリンク
-
5. マシン起動
- EpicをTODOに遷移し、遷移チェーンが開始
- 遷移例：（2,3）TODO →（1,3）DEV →（1,4）TODO →（0,4）DEV →（0,5）TODO →（0,5）PROD
- 結果：EpicはPROD、Bug 0件、Task 5件（2+3=5の加算結果）
フィボナッチ計算の簡素化
- Jira Automation の「課題タイプ変換（CONVERT）」で Minsky操作を簡略化
- Bug→Story、Story→Taskなど即時変換
- CONVERT=DEC+INC に相当し、分岐表を大幅に縮小
- フィボナッチ計算例 （A=Bug, B=Task, C=Story）
- ステータス： TODO, QA, DEV の3状態
- TODO：TaskがあればTask→Story変換、BugをINC、TODOへ
- QA：BugがあればBug→Task変換、QAへ
- DEV：StoryがあればStory→Bug変換、DEVへ
- 初期状態：A=1, B=1, C=0
- Bの数として フィボナッチ数列 （1,1,2,3,5,8,13, …）が現れる
- HALT状態なし、Jira Cloudのチェーン上限10で停止、手動で再トリガー可能
結論
- Jiraのオートメーション言語 は 2カウンタマシン をエンコード可能
- Jira Cloudの物理的制限 はあるが、 チューリング完全性の証明 には影響しない
- Jiraの複雑な自動化 が 本質的にプログラム である理由の説明