Pixie Works
アジャイル · チケット駆動型開発
チケットを仕事の共通言語にする。
人がコードを書く場合も、コーディングエージェントを使う場合も。明確なチケットで計画、実装、レビューをつなぎます。
この記事用に生成したイラストです。Pixie Works の社員・顧客や、実際のプロジェクトを写したものではありません。
チケットを作ったのに、実装が始まると「何をもって完了？」という話に戻る。
作業名は付いていても、チームで仕事の意味を共有できていないときに起こりがちです。私がチケット駆動型開発でまず大切にするのは、実装前に目的を見える形にすること。チケットはボード上で動かす項目だけではなく、成果についての小さな「合意」です。
目的、作業範囲、完了条件を書く
意味のあるチケットは、「なぜ必要か（Why）」「何を含むか（What）」「どうなれば完了か（How）」に答えます。長い仕様書である必要はありませんが、別の人が実装し、レビューできるくらい具体的にします。
例えば「問い合わせフォームを改善する」だけでは、人によって想像する内容が違います。「正常な送信後に確認を表示し、メール配送の成否を記録し、日本語と英語の画面で確認する」なら検証できます。詳しい要件や判断の背景は、チケットから参照できる場所に残せば十分です。
計画と完了の証跡をつなぐ
Jira ではバックログ、優先順位、スプリントの作業を管理します（Delivery）。Confluence には要件、設計上の判断、その理由を残します（Discovery）。スクラムの計画、進捗確認、レビュー、ふりかえりでは、これらの記録を使います。チケットは、実際の変更と動作確認の結果をそこへ結び付けます。
レビューで見落としが見つかったら、チケットを更新するか次のチケットにします。会話に参加した数人しか知らない情報をチームの仕事として戻し、共有するためです。
コーディングエージェントにも同じ明確さを
コーディングエージェントは実装を助けますが、曖昧な依頼を渡しただけで目的が明確になるわけではありません。チケットの目的、境界、完了条件を具体的な指示に変え、実装と必要なテストを依頼します。そして人が変更内容、テスト結果、残る不確実性を確認してから受け入れます。
これは、私たちがご提案する AI-DLC の出発点です。成果に責任を持つのはチームのまま、エージェントにはレビュー可能な仕事を任せる。学んだことは次のチケットに反映します。
まずは実際のチケットを１つ
これから着手する仕事を１つ選び、目的を１つだけ書いてみてください。作業範囲を定め、確認できる完了条件を２、３個挙げ、背景となる判断へリンクします。レビュー時に結果と条件を比べ、分かったことを記録します。一度にすべてのプロセスを変える必要はありません。
計画の最初の会話からチームメンバーによる最終確認まで、チケットをチームと AI の共通言語にしていきます。