より良いチケットが、エージェントによるより良いコード生成を支援する

AIエージェントを活用してエンタープライズ向け製品を構築した経験の振り返りと、私たちの働き方についてデータが物語ること。

観察から見えたこと

ここ数か月、私たちは従業員の報酬計画・管理・コミュニケーションを支援する、全社規模かつ本番運用レベルのアプリケーションを急ピッチで構築してきました。私は、自分たちが作ったものを従来型の手法で作られたプロダクトと比較して、この新しい働き方から得られる知見を引き出そうと試みました。

私たちは1つの目標を掲げて取り組みを始めました。それは、小さなチームがどれだけ速く本番運用レベルのプロダクトをリリースできるのか、自分たちの限界に挑んでみることです。そのため、通常のスプリントセレモニーや従来型のフレームワークは省き、ひたすら開発に専念しました。

始める前の私たちには、ざっくりとした仮説がありました。エージェントと協働すれば、より速く成果を出せるだろう、そしておそらく、エージェントを軌道に乗せておくために、いつもより少しチケットを多めに書くことになるだろう、というものです。そこまでは想定内でした。

想定外だったのは、その規模でした。従来型の手法で同程度の期間に提供された、規模の近いプロダクトと比較して結果を測定したところ、エンジニア1人あたりの成果は、正味のコード行数、循環的複雑度、データベーススキーマの規模、外部連携のいずれの指標でも、およそ5倍に達していました。2つのビルドは規模の面ではほぼ同等です。さらに、5人のチームが、そのチームと比べて1人あたり5倍近くのJiraチケットを書いていました。

さらに大きな驚きは、品質でした。出典を伏せた状態での評価では、私たちのチケットは記述品質で5点満点中平均4.47点を記録し、従来型の手法で書かれたチケットの2.72点を上回りました。また、「エージェントレディ」と判定されたチケットの割合は83%に達し、従来型のわずか6%と対照的でした。

直感に反するようですが、エージェントによって開発スピードが上がったことで、適切にスコープが定められたチケットの価値は、下がるどころかむしろ高まりました。理由は3つあります。

「どうやって」の部分こそ、人から最もよく尋ねられるところなので、自分たちのリズムをつかんだあとに実際どんな形になったのかをご紹介します。うまくいったパターンは、人間の労力を工程の上流に前倒しし、まず深く理解することに注力するというものでした。そうしておけば、エージェントが動き出す時点では、チケットはそのまま実行できる仕様書になっているのです。

できます。私は、出典を伏せたチケットのサンプルを、記述品質の5つの観点(明確さ、スコープ、受け入れ基準、コンテキスト、実行可能性)で採点するLLMジャッジを構築し、私たちのAIネイティブなチケットを、従来型の手法で書かれたチケットと比較しました。

サンプル:300件のチケット(プロダクトごとに150件)を、実際に出荷されたコミットから参照されていたチケット群からシード付きランダムで抽出しました。この差は統計的に圧倒的です(Welchのt値が約17.5、p<0.001)。これは、両側150件ずつのチケットで、この差が標本抽出のたまたまの偏りである確率が1,000分の1未満であることを意味します。

差が最も大きく開いたのは、まさにエージェントにとって最も重要な部分、すなわち受け入れ基準とコンテキストという、エージェントが自律的に実行するために必要な2つの要素でした。私たちのチケットは、実行可能な仕様書のように読めます(明示的な受け入れ基準、スコープに含まれる領域、スコープ外に関する注記、依存関係のリンク)。一方、従来型のチケットは、たいてい1行の要約とリンク1本だけでした。

一つ、本当に足りていないものがありました。エージェントは、別の作業をしている最中に、実在する問題、すなわち潜在的なバグ、その場しのぎの対応、技術的負債などをたびたび浮かび上がらせます。しかし、それらをその瞬間に手間なく記録する手段がないため、こうした発見はセッションが終わると消え去ってしまいます。

その結果、一種の健忘症のような状態が生まれます。同じ問題が何度も何度も再発見され、私たちは毎回それらを見つけ出すコストを払いながら、そのコストを一向に返済できずにいるのです。

朗報は、私たちがすでにその解決に向けて動き出していることです。エージェントの活動をあらゆるチケット上で一級市民として扱えるようにし、エージェントが技術的負債を見つけたその瞬間に、セッション終了とともに失うことなく記録できるようにするのです。

私が最も強く感じるのは、これらのどれ一つとして義務づけられたものではなかった、ということです。私たちは、Jiraについて何かを証明しようとして始めたわけではありません。可能な限り速く動こうとするその真っ只中で、ごく自然にJiraへ手を伸ばし、そしてJiraはその居場所に値し続けたのです。エージェントの作業範囲を定める必要があるとき、チーム全体で連携する必要があるとき、あるいは作業をきれいに引き継ぐ必要があるとき、そのたびに、優れたチケットこそが物事を機能させてくれる道具でした。それは静かに、私たちがAIネイティブなワークフローで動くうえでの屋台骨となっていったのです。

信頼という側面もあります。企業はすでに、最も機密性の高い計画データや知識データをアトラシアンに預けて信頼を寄せています。エージェントが生み出す成果物、エージェントが使うコンテキスト、下す判断、加えられる修正、そしてトークンコストを、その同じ信頼できる場所に保持しておくことには意味があります。なぜなら、その記録を外部のAIツールにばらまくのではなく、自分たちの手で保有したいはずだからです。

AIが進化し続け、まるでどんな願いでも叶えてくれるかのように見える世界では、大切なのは願いの立て方です。私たちがあえて明示することを選んだ細部こそが、何が作られるかを形づくります。そして、エージェントに埋めさせるまま残したあらゆる前提は、後になって払うことになるコストなのです。そして、そうした願いをうまく立てる場所、すなわち意図を明確に捉えてエージェントに手渡す場所として私たちが見出したのが、Jiraチケットでした。