概念実証：なぜJira is Turing-Completeなのか

長年、エンジニアリングの伝承では、Jiraはチューリング完全であると言われてきました。多くの人々がその複雑な自動化機能の証拠として漠然と言及してきましたが、それを証明するための形式的な帰着（reduction）を提供した者はほとんどいませんでした。最近の技術的なディープダイブにおいて、Nicolas Seriot氏は、Atlassianのプロジェクト追跡ツールが、Minsky register machineを実装することによって、実際に汎用コンピュータとして機能し得ることを示し、伝承を超えた証明を行いました。

この発見は、単なる理論的な好奇心にとどまりません。複雑なJiraの自動化が、なぜプログラミングのように感じられるのかを説明しています。なぜなら、形式的な意味において、それはプログラミングそのものだからです。

計算モデル：Minsky Machine

チューリング完全性を証明するために、Seriot氏はMinsky register machineを利用しています。このモデルはチューリングマシンと計算的に等価ですが、ビジネスツールへのマッピングは大幅に簡素化されます。Minsky machineは、2つの無制限のカウンタ（レジスタ）と、ラベル付けされた有限の命令セットのみを必要とします：

Increment (INC r; goto S): レジスタ r の値を増やし、状態 S へ移動する。
Decrement/Branch (DEC r; if r == 0 goto S else goto S'): レジスタ r の値を減らす。もしレジスタがすでに0であれば、状態 S へ移動し、そうでなければ、状態 S' へ移動する。

Jiraの自動化言語内でこのモデルを提示することで、帰着は完了し、Jiraはチューリング完全であることが証明されました。

MinskyをJiraにマッピングする

Seriot氏の証明は、Minsky machineの抽象的な構成要素を、特定のJiraエンティティにマッピングしています：

Minsky Machine Component	Jira Implementation
Register A	Bug タイプのリンクされた課題の数
Register B	Task タイプのリンクされた課題の数
Program Counter	単一の Epic 課題のステータス
Dispatch Table	Jira Automation rules (各命令状態につき1つ)
Clock	自動化によってトリガーされる遷移、または外部からの再トリガー

このアーキテクチャでは、Epicのステータスが現在の命令をエンコードしています。自動化ルールは、リンクされた課題の数を検査し、次のステータス遷移を決定します。INC および DEC 操作は、リンクされた課題の作成または削除によって実行され、条件付き分岐はJQL-conditioned rules を通じて処理されます。

ケーススタディ：加算の実装

理論を実証するために、1つのEpic、5つのリンクされた課題、および各状態につき1つの自動化ルールを使用して、最小限の加算マシンが構築されました。ワークフローは、以下のステータスで構成されます：BACKLOG $\rightarrow$ TODO $\rightarrow$ DEV $\rightarrow$ PROD。

Rule for TODO (DEC A; if A=0 halt, else goto DEV): リンクされた Bug が存在する場合、それを削除し、Epicを DEV に遷移させます。Bug が存在しない場合、PROD に遷移させます（停止）。
Rule for DEV (INC B; goto TODO): 新しい Task を作成し、それを Epic にリンクし、Epicを TODO に戻します。

2つの Bug (A=2) と3つの Task (B=3) で初期化されたとき、マシンは一連の遷移を実行します。Epicは最終的に 0個の Bug と 5個の Task がリンクされた状態で PROD に到達し、実質的に $2 + 3 = 5$ を計算します。

スケーリング：フィボナッチ数列と「Convert」ショートカット

基本的な帰着は論点を証明していますが、Seriot氏は、Jiraの Convert Issue Type 機能を利用することで、より効率的な実装が可能であると指摘しています。Bug を Story や Task に即座に変更することで、煩雑な DEC + INC のサイクルを避けることができます。

3つのレジスタ（Bug, Task, Story）と3つの状態（TODO, QA, DEV）を使用することで、フィボナッチ数列生成器を実装できます。このマシンは、Task の数において、1, 1, 2, 3, 5, 8, 13... という数列を無限に生成し続けます。Jira Cloudはチェーンの深さの制限（通常は10個のトリガー）を課しているため、「クロック」には、計算を継続するためにEpicを時折手動で再トリガーする人間のオペレーターが必要です。

コミュニティの視点：「Turing Tarpit"

Jiraがチューリング完全であるという事実は、開発者コミュニesteño la comunidad de desarrolladores ha provocado una mezcla de diversión y horror.

"That explains why it's impossible to tell whether any given Jira operation is going to halt or not." — @lmm

他の観察者は、チューリング完全性は現代のソフトウェアにとって低いハードルですが、Jiraでのプログラミングの「経験」は、非常に設計の不十分なプロセッサ向けのアセンブリ言語を書いているようなものだと指摘しています。

"What's surprising is how awful their automation flow tools are to work with. Feels like programming in assembly to accomplish what you want." — @fercircularbuf

また、この証明は、避けられない結末への第一歩であるというジョークも絶え間なく語られています。すなわち、誰かが DOOM をJiraインスタンス内で動作させるために移植することです。

結論

課題の数をレジスタとして扱い、ステータス遷移を状態変化として扱うことで、Jiraはチケット追跡ツールとしての役割を超え、汎用コンピュータへと変貌します。Jiraでソフトウェアを書くことの実際的な有用性はほぼゼロですが、この証明は、エンタープライズ・ソフトウェアの複雑性が、しばしば普遍性へと進化していくことを思い出させてくれます。それは、通常、最も予期せぬ、かつ不便な場所において行われます。