その中で無限に動き続けられるのはどれくらいあるの？人間が再トリガーして、途中から続けられるやつとか。

そうは思わないな。まず、JIRAはオーケストレーションじゃないし。次に、ワークフローがやるべきことは、外部情報とステータスを関連付けて、それを簡単に操作できるようにすることだよ。トリガーやルールが必要で、無限カウンターとか、2つのスタック、双方向テープみたいなものが必要だね。俺が間違ってるって証明してみてよ！

それとも、アホみたいに完全なのかな？ :)

Jiraは疎外の概念の究極の例だね。マルクスがアトラシアンについて知ってたら、『グンドリッセ』はめちゃくちゃ面白くなってたはず。

一番最悪なのは、タスク管理製品を持ってる会社がみんなJiraに向かってること。2014年のGitHubのイシューと今のを比べてみてよ：https://github.com/features/issues それに、無駄な機能をどんどん追加してるし。

これ、過小評価されてるコメントだね！

それって「JiraでDoomができる」ってことになるの？Jiraはその結果出てくる悪魔を倒すためのポンプアクションショットガンを提供してくれるの？

かなりの数の人がやってるけど、問題はJiraのインスタンスがそれぞれカスタムプロパティのフラクタルな雪の結晶みたいになってて、古い失敗したマイグレーションから新しい組織戦略まで何層にもなってることだね。APIがUIではできないことをできることも多いし、みんなUIに頼ってるから、カスタムフィールド5537とカスタムフィールド442をペアにしないと他の誰のダッシュボードにも表示されないってことに気づかずに変なところで壊れちゃう。さらに、カスタムフィールド10995は整数型のフィールドだって言ってるのに、XMLでは整数として返ってくる。でも、タスクを作成する時にはドキュメント化されてない魔法の定数文字列を使わないと、役に立たないエラーメッセージが出るんだ。ウェブUIはこれをやらないし（HTMLとリクエストではただの整数）、ドロップダウンの表示テキストと一致する文字列は80%しかない。Jiraの自動化は、今までで最悪のプログラミング体験だったよ。もっとシンプルな設定があるのは完全に信じられるし、たぶんかなり簡単なんだろうけど、ほんとにやばい。残念ながら、それでも努力する価値はある。めっちゃおすすめ。

うちの主な問題は、彼らが価格を信じられないほどつり上げてることだけだね。最近、ライセンスとユーザーの数を減らさざるを得なかった。めちゃくちゃ高かったから。

カスタムスクリプトで全部つなげてAIにJiraの面倒を見させちゃえばいいんだよ。まるでJiraの肥大化がまだ足りないかのようだね。もっとテキストを追加すると、すべてのテキストを常に自動的に処理しようとするから、さらに遅くなるよ。会社で暖房が必要なら、Jiraを使えばいい。

何年も前にJetbrainsのYouTrackに移行したんだけど、APIを使ってこんなことをやってるよ。かなり柔軟性があるんだ。AIのおかげで、さらに使いやすくなったね。

うちの会社は基本的にJiraで回ってる。ほとんどのプロセスがJiraに依存してて、特定の遷移が自動化のためにWebhookを発火させるんだ。AIにアクセスできるようになったとき、最初にやったのはJiraのMCPを作ることだった。最近はJiraに触らないようにしてるよ。ClaudeにJiraの課題を作らせたり、コメントを書かせたり、サブタスクを作ったり、課題をリンクさせたりしてる。以前は、何かを実装する方法を調べてタスクに分解するのが嫌だったんだ。細かく分ければ分けるほど、Jiraの課題をたくさん作らなきゃいけなくて。今は、全部ファイルにまとめてLLMにJiraの面倒を見てもらえるから楽になったよ。

ハッカー精神を持った企業プログラマーが、Jiraで頼まれたことのほとんどをPythonのコマンドラインスクリプトで自動化してないのが驚きだ。企業のITがトークンを2秒ごとに期限切れにするから、スクリプトが無駄になるんだよ。マジで、1時間ごとに期限切れになるトークンもあるし。

ハッカー精神を持った企業のプログラマーが、Jiraで求められることのほとんどをPythonのコマンドラインスクリプトとかで自動化してないのに驚いてる。俺が働いてたJIRAを使ってた多くの組織では、こういうことをするための資格を与えてくれなかった。

ここにはすごくナイーブな点が見えるね：* 「企業ハッカー」ってあんまり一般的じゃない。企業の世界では、ほとんどのプログラマーは言われたことをやるだけで、それ以上はしない。イニシアチブを取ると罰せられる。* APIラッパーは実際には良くない。API自体もかなり貧弱だし。JIRAは恣意的に物事を変える伝統があって、特に機能を削除したり、役立つ機能を隠したりする。よく設計されたり実行された製品じゃない。* AIはまだ成熟してなくて、バグトラッカーに求められることには役立たない。ほとんどの企業にとって、こういうやり方は高すぎる。* QAは通常、後回しにされる。予算削減や手抜きの話になると、そこは左も右も真ん中も関係なくなる。ほとんどの企業はQAを負担と見なしていて、価値を生んでるとは思ってない。顧客にQAがあるって言うために、ただそれを装ってるだけ。QAに意味のあることをさせるためには、優秀なエンジニアを雇ったり、開発時間を割いたり、計算リソースを割り当てたりしなきゃいけないけど…それは大変だよね！俺が見たQAのほとんどは、特に国際的な大企業では、見せかけのためだけで、同じほとんど役に立たない手動プロセスを踏んでるだけだった。QAをもっと効率的にするアイデアがいくつかあったけど、実際に成功する製品になる可能性があるか試してみた結果、誰もQAを改善したがってないって気づいた。もし製品が「認証」（製品をテストしたと主張する能力）を安くできれば、実現可能かもしれないけど…これは俺が行きたかった方向でもないし、バグトラッカーをこの方向で改善するのも本当に難しい。---- * 探索的テストっていうのは、ある種の「ファジング」なんだけど、もっと構造化されたもの。ファジングは通常、入力に適用されて、テスト中のプログラムを通るすべての可能な方法を探ろうとする。探索的テストは、組み合わせて長いテストを作ることができるモジュールで構成されるテストなんだ。これによって、プログラムの難しい「コーナー」ケースに到達する問題や、入力に直接（または全く）依存しないコードパスに到達する問題を解決する。

そういうことはやってるけど、あまり話さないようにしてるんだ。「そんなことするな」って言われるのが嫌だから。実際、書きたくても書けないことがたくさんあって、そういうイタズラみたいなことをやってるんだ。自動スワイプとか、レストランの予約を競争したり、友達が家を買えるようにスクレイパーを作ったり、UXがクソなサイトの内部APIに接続したりね。利用規約をたくさん破ってるけど、まあ、楽になるからいいや。これがなかったら今の妻とも出会えなかったと思うし。自分はTinderの成功例かもしれないけど、自動スワイプで利用規約は破ったよ :’) でも、バンされたわけじゃない。特別なことはしてないから、検出もイマイチなんだよね。このコメントを見て複雑な気持ちになったなら、だからこそこういうことを詳しく書かないんだ。最近はLLMがこういうことを解決してくれるし、こういうのを振動コードするのはすごく面白い。今、どの内部APIを使ってるかは言わないけど、進捗を見える化するEdTechプラットフォームでの進捗を楽しんでるから、あまり進捗を見せないのが好きなんだ。Jiraに戻るけど、自分に合った代替UIを振動コードしたし、Googleカレンダーやオフィスにいる時を知るための他のツールとも統合したよ。

うん、前に働いてたところで、彼らのAPIを使って時間を節約するためのいくつかの小さなシェルスクリプトを作ったことがあるよ。各チケットに人間の説明を追加するカスタムテキストフィールドを作ったり、リリースが出た時に自動でタイムスタンプを入れるようにしたりね（デプロイスクリプト）。1回の作業として1つのチケットをリリースしてた（1日にたくさんのチケットを扱ってた）。これにカスタムフィルターを組み合わせることで、Jiraが各ボードや会社全体の人間が読める変更ログを提供してくれたんだ。このメッセージはビジネスにSlackで送られて、みんなが何がライブになってるかを把握できるようになってた。リリースのすべてを検索できる監査ログにもなってて、コード変更に結びついてた。デプロイプロセスもJiraのチケットを移行させるから、開発者はチケットをメインにマージする以上のことをする必要がなかったんだ。ルーチン作業のためのチケットを自動で作成する小さなスクリプトがたくさんあって、何年も超安定してたと思う。今も動いてるんじゃないかな。カスタムフィールドの命名規則はダサかったけど、チームがJiraの設定を管理してれば、みんなが同じページにいるのはそんなに難しくなかった。最初はJiraが嫌いだったし、何年も前は問題が多かったけど、今は設定さえすればそんなに悪くないよ。自分の会社に選ぶことはないけど、開発者として、管理者として、エンドユーザーとして使って、内部ツールを開発してきたから、設定して動かし始めればほとんど邪魔にならないね。

あのバージョンのJIRAは、簡単にひどく設定できちゃうからね。それがJIRAの主な問題なんだ。実際にまともに設定する力は、面倒くさがったり、時間がなかったり、毎日使ってない人たちに独占されてる。まあ、問題の一つだけどね。それに、信じられないくらい遅いし、課題が他の課題の親になれないみたいな変な制限もある。

俺の本業ではJiraとかのツールを使わなくなったから、純粋な好奇心から聞くんだけど、プロジェクトチーム全体（オタクだけじゃなくて）でのより良い代替案についての合意はどうなってるの？

編集モードにダブルクリックする件について：そうそう、めっちゃ同意！超イライラするよね。基本的なテキストのことすら間違えるし！でも、プロジェクトマネージャーが言ってたことがあるんだ…彼らはそれが好きなんだって。全単語を選択するのにダブルクリックドラッグなんて使わないから…うーん、コンピュータを上手に使える人が、ほとんど使えない人の便利さに引きずられてる感じ。

面接の時、俺は「JIRA、ああ、まだ使ってるの？」って言ったんだ。使えるよ、って。ちょっと待って、何か見逃した？タイムホールに落ちたのかな？なんでJiraの話をしてるのがVisicalcみたいになってるの？今はIT企業で働いてないから、過去2年間に何か大きなことを見逃したのかも…

ほら、ツールのせいじゃないんだ。正しくツールを設定できる人がこの地球上にはいないんだよ…人間の無能さのせいでツールを責めることはできないよね。じゃあ、誰のために作られてるのかって？それは全く別の質問で、今はその話はしないことにしよう。

そうそう、その遅さがいつも気になるんだ。要するに、チケットシステムって単なるチケットのデータベースとチケットと状態の関係の集まりに過ぎないのにね。確かに、たくさんの相互接続されたチケットやカスタムフィールド、プラグインがあれば、爆発的に複雑になるけど。シンプルなテキストデータと添付ファイルだけで動くものが、どうしてこんなに遅くなるのか全く理解できないよ。

チケットが洗練されるためにはユーザーの割り当てが必要なの？それは作業をする人が誰に割り当てられるかによるべきで、洗練の一部ではないと思う。

これって本当だよね。Trelloはシンプルさを制約にしてるから、ユーザーが大きな混乱を起こすことはない。でも、やっぱり混乱は起こせるし、真実のソースとしては、ちゃんと物を動かすのは人間だから、あんまり良くはならない。すべてのプロジェクト追跡アプリは、根本的な問題の原因は同じ：ユーザーなんだ。

Atlassianもこれを知ってると思うよ。Jiraで基本的なカンバンボードをセットアップすると、ほぼTrelloのボードになるんだ。デフォルトのオプションの一つとして提供されてるし、こんなシンプルな選択肢があるとはちょっと驚いたよ。もちろん、複雑さはあって、余分なカラムを追加したくなった瞬間、深い穴にハマっちゃうけどね。

たぶんそうだね。でも、Trelloは最近大規模な数日間の障害があって、コメントしたりカードを動かしたりできなかったから、今の時点で誰かに勧めるのは難しいな。