JiraとBitbucketは、どちらも最初の会社であるHalcyonで出会ったものだった。チームはJira上のカンバンボードで動いており、リポジトリはBitbucketが担当していた。ただ、私はそのボードの上で働いていただけで、それを組み立てた側ではなかった。ワークフローも、パーミッションも、自動化ルールも、私が加わるずっと前に誰かがすでに設定していたものだ。私はただその中で作業していた。
Bitbucketは大学時代にも私についてきた。数年後の卒業制作で、チームはリポジトリ管理にBitbucketを使っていたが、メンバー数の上限にぶつかってしまった。Bitbucketは追加できる人数に制限があり、その上限に達した時点で選択肢はほとんど残っていなかった。私たちはすべてGitHubに移し、それ以来ずっとそこに留まっている。
それ以来、日々使うツールは完全に変わった。今働いているCodyでは、チームはAsanaを使っているが、アジャイルチームがよく語るような使い方ではない。ストーリーポイントも、見積もりの儀式もない。あるのはただタイムラインだけで、ある機能にどれくらいの時間がかかると見込まれているかと、誰が何を担当していて、それが終わっているかどうかを追跡するだけだ。Linearとn8nが日々実際に触れているもののそれ以外を占めており、JetBrains系のものにはTeamCityを使っている。
だから最近、ほとんど好奇心だけでJiraを再び開いた時、そこは2022年か2023年頃からずっと触れられずにいた。そして見つけたのは、自分が見ていない間にすっかり成長していたものだった。
自動化の部分は簡単に理解できた。チケット作成時に誰かへ自動的に割り当てる、ワークフローの遷移で発火するルールを設定する、どれも見慣れないものには感じなかった。Atlassianのブランディングの裏側にあるのは、n8nやZapierで毎日使っているのと同じ「Xが起きたらYをする」というロジックだったからだ。Jiraには自動化設定の奥にIncoming Webhookトリガーというものまであり、どこからでも(Stripeも含めて)POSTを受け取り、そのペイロードを{{webhookData}}というスマート値で読み取ることができる。StripeのWebhookをn8nに組み込んでDiscordやTelegramに流す方法をすでに知っているなら、その時点でJira Automationの9割はもう理解できている。ただ送り先のノードの名前が違うだけだ。
ストーリーポイントについては、実際に立ち止まって考えさせられた。用語自体は何年も前から漠然と知っていたが、自分の経験の中ではそもそもそういう仕組みが必要になったことがなかった。調べてみると、プロジェクト単位の設定ではまったくなく、個々のissueに紐づく一つのフィールドで、作業が始まる前のバックログリファインメントやスプリントプランニングの段階で記入するものだった。時間ではなく相対的な作業量と不確実性を表すものであり、だからこそ多くのチームは線形ではなく、1、2、3、5、8、13といったフィボナッチ的な数字を選ぶ。
そこからさらに難しい問いが生まれた。あるものが本当に完了したと、どうやって知るのか。Jiraはこの問いに答えてはくれない。カードをDoneにドラッグしても、ステータスのフィールドが切り替わるだけで、何かが検証されるわけではない。その検証に意味を持たせたいなら、Doneの手前にレビューやQAの列を追加して作業者本人以外がそこに移動させるようにするか、条件が満たされない限り遷移をブロックするワークフローバリデーターを設定するしかない。もし誰かが完了していないものをDoneにしてしまっても、特別な取り消し機能はなく、他のステータス変更と同じようにIn Progressへ戻すだけでいい。
完全に思い違いをしていたのがGroupsとTeamsだった。Groupsが権限の提供を担っているので、GroupsがTeamsより上位にある階層構造だと思い込んでいた。それなりに筋が通っているように感じていたが、間違いだった。両者はまったく入れ子になっていない、並列に存在するまったく別のシステムだ。Groupsは管理者によって管理され、パーミッションスキームやセキュリティレベル、通知スキームといった実際のアクセス権を制御する。Teamsは誰でも自由に作成でき、主に部門を横断した協力関係を可視化するために存在する。Teamsは今のところパーミッションにはまったく関与しないし、Groupをそのまま「Teamの中に」組み込むこともできない。
なぜそこを間違えたのか、振り返ってみると、それはJiraが分かりにくいという話ではない気がする。私がこれらのツールを実際に使ってきた場面は、Halcyonで誰かがすでに組み立てたシステムの中の一メンバーとしてか、あるいは完全に一人だけの、どちらかしかなかった。個人的なプロジェクトで一人で触っている時、パーミッションスキームの向こう側に、自分のメンタルモデルが間違っていた時にそれに気づいてくれる二人目の人間はいなかった。GroupsやTeams、パーミッションスキームについてどれだけ読んでも、実際に何かがおかしくなればすぐに気づく本物のチームメイトのためにアクセス権を設定したことがない限り、その知識はずっと理論のままだ。それが、技術的には「使ったことがある」はずのツールなのに、他人が関わって初めて重要になる部分でずっと自信が持てなかった、本当の理由なのだと思う。