この記事のタイトルはかなり挑発的です。
「Jira IS Turing-Complete」――要するに、「Jiraはチューリング完全だ」と言っているわけです。
チューリング完全という言葉は、ざっくり言えば「理論上、どんな計算でも表現できる能力がある」という意味です。
普通はプログラミング言語に対して使う言葉ですが、この記事はそれを JiraのAutomation に当てはめています。
正直、最初は「また大げさなネタ記事かな？」と思うかもしれません。
でも読み進めると、ちゃんと計算理論のReduction（還元）として筋を通していて、笑い話で終わらないのが面白いところです。
こういう「ふざけて見えるのに、中身は本気」の記事、かなり好きです。
記事の中心にあるのは Minsky machine です。
これは、かなり単純化された計算モデルで、必要なのは次の2つだけです。
r を1増やして、状態 S に進むr が0なら S、そうでなければ1減らして S' に進むここでの「カウンタ」は、数字を数えるだけの箱みたいなものです。
そしてMinskyは、こうした2つのカウンタがあればチューリング完全な計算ができることを示しました。
つまり、記事の狙いはこうです。
JiraのAutomationで、このMinsky machineを再現できれば、Jiraも理論上Turing-completeと言える
この組み立て方が、かなり綺麗なんです。
「Jiraがなんとなくプログラムっぽい」ではなく、理論上の既知のモデルに落とし込んで証明する。ここが重要です。
記事では、Minsky machineの要素をJiraに対応づけています。
この対応づけがうまいです。
Jiraのissue typeを「数える対象」として使う発想は、かなり発明っぽい。
Bugの数がA、Taskの数がB。
増やすときはissueを作る。減らすときは削除する。
たしかに、これならカウンタとして使えます。
そして、Epicのstatusを「今どの命令を実行しているか」というプログラムカウンタに見立てるわけです。
要するに、Epicが「今はTODO状態だから次の命令はこちら」といった具合に、実行の分岐先を持つ司令塔になる、ということです。
記事の前半で紹介されるのは、かなりシンプルな計算です。
Aに入っている値をBに足し込むという処理です。
たとえば初期状態が A=2, B=3 なら、最終的に B=5 にします。
これをJira Automationで実現するには、ざっくりこんな流れです。
Epicに次のstatusを持たせます。
そして、どの状態からどの状態にも遷移できるようにします。
ここでは「状態がプログラムの命令場所を表す」ので、かなり自由に行き来できる必要があります。
これは命令でいうと、
DEC A; if A=0 halt, else goto DEVに相当します。
実際の動きはこうです。
これは、
INC B; goto TODOに相当します。
動きはこうです。
A=2B=3EpicをTODOへ移すと、連鎖が始まります。
記事にあるトレースはこうです。
(2,3) TODO(1,3) DEV(1,4) TODO(0,4) DEV(0,5) TODO(0,5) PROD結果、Bugは0、Taskは5。
つまり 2 + 3 = 5 が実現されます。
この一連の流れ、正直かなり気持ちいいです。
「Jiraで足し算」というと冗談に聞こえるのに、実際にはちゃんと命令列として動いている。
しかも「人間がボタンを押してるだけ」ではなく、Automationの連鎖で進む。そこが妙に本格的です。
記事の後半はもっと楽しくなります。
今度は Fibonacci数列 をJiraで動かします。
Fibonacciは、ざっくり言うと
で増えていく有名な数列です。
1, 1, 2, 3, 5, 8, 13, … というあれです。
記事ではこれを
A=BugB=TaskC=Storyの3つのカウンタとして扱い、
TODO, QA, DEV の3つの状態で回します。
ここで面白いのは、Convert Issue Type という操作です。
これは issue type をその場で変える機能で、たとえば Bug → Story のような変換ができます。
記事ではこれを、実質的に DEC + INC の組み合わせとして扱っています。
つまり、ある種類のissueを減らして、別の種類を増やすわけです。
これにより、Fibonacciの更新則 (A, B) → (B, A+B) を表現できる、という話です。
個人的には、ここがいちばん「うわ、ほんとにやってる」と感じる部分でした。
Jiraって普通は「チケット管理ツール」ですよね。
それをここまで抽象化して、数の増減と状態遷移の装置として扱う発想がすごい。
しかも、単なる遊びではなく、Turing-completeの証明に必要な構成要素が揃うというのがポイントです。
「これでゲームが作れます」ではなく、「計算理論の条件を満たしています」という話なので、知的な満足感があります。
ここは大事です。
Jira Cloudには chain-depth cap という制限があり、Automationの連鎖が無限に続くわけではありません。
記事では上限が10だと触れています。
でも著者は、それでも問題ないと言います。
なぜなら、Turing-completeかどうかは「物理的に本当に無限に走るか」ではなく、理論上の計算モデルとして表現できるかが本質だからです。
人間が途中で再トリガーすれば、実行を続けられる。
Jira Data Centerでも同様の制御がある。
つまり、有限の制約があることは、理論的な証明を壊しません。
このあたりは少し数学寄りの発想ですが、説明としてはかなり筋が通っています。
「現実の製品は有限だから無理でしょ？」という反論に対して、
「いや、そもそも実コンピュータも有限だよね」という返しは、たしかにその通りです。
ここ、誤解しやすいポイントです。
この記事は「Jiraは最強の開発ツールだ！」と褒めているわけではありません。
むしろ逆で、業務ツールがいつのまにかプログラミング環境みたいになってしまうという、ちょっとした皮肉が効いています。
個人的には、ここがいちばんおもしろいところだと思います。
本来、プロジェクト管理ツールって「仕事を整理する」ためのものです。
でもAutomationや条件分岐、状態遷移、issueの生成・削除が積み重なると、気づけばプログラムそのものになる。
これはJiraに限らず、いろんな業務システムに起こりがちな現象です。
「便利にしたい」が積み重なって、最終的にすごく複雑なルールの森になる。
ああ、現場あるあるだな……と思わされます。
この記事は、Jira AutomationでMinsky machineを構成し、そこから JiraはTuring-completeだ と示す内容です。
理論計算の証明としてきれいに組まれていて、しかも実際のJira画面で動かしているのが強いです。
そして何より、こういう記事は読んでいて楽しいです。
「仕事ツールで足し算やFibonacciが動く」というだけでも面白いのに、裏ではちゃんと計算理論の話になっている。
このギャップが最高でした。
JiraのAutomationを見て「なんかプログラムみたいだな」と思ったことがある人は多いはずです。
この記事は、その感覚がただの比喩ではなく、かなり本質的なものかもしれないと教えてくれます。
そう考えると、業務ツールの設計って、意外と計算機科学の最前線と地続きなのかもしれません。