アジャイル · チケット駆動型開発

チケットに何を書くか。Why・What・How を１つの例で考える。

「問い合わせフォームを改善する」を例に、目的・作業範囲・完了条件を具体化し、実装とレビューにつながるチケットを考えます。

この記事用に生成したイラストです。Pixie Works の社員・顧客や、実際のプロジェクトを写したものではありません。

Yas Naoi · Pixie Works

「問い合わせフォームを改善する」。このタイトルだけで、チームは同じ仕事を思い浮かべられるでしょうか。

見た目を整える人もいれば、入力項目を減らす人もいるかもしれません。送信後の案内を直すつもりだったのに、実装が始まってから認識の違いに気づくこともあります。

前の記事では、チケットを成果についての小さな「合意」として捉えました。今回は、架空の問い合わせフォームを例に、その合意に何を書くかを考えます。実際の顧客案件や障害の報告ではありません。

Why: なぜ必要かを、利用者の困りごとから書く

「使いやすくする」だけでは、改善の方向が定まりません。たとえば、この例では目的を次のように置きます。

問い合わせを送った利用者が、送信を受け付けたかどうか判断できるようにする。

まず目的を１つに絞ります。目的が明確であれば、実装方法を話し合うときも、その変更が必要かを判断できます。

目的に対して、今回どこまで変更するかを決めます。

日本語版と英語版の問い合わせフォームで、送信処理が成功した場合に受付完了の案内を表示する。入力エラー時には修正が必要な項目を示す。入力項目の追加、サイト全体のデザイン変更、メール配信基盤の変更は今回の対象に含めない。

対象外を書くのは、必要な改善を諦めるためではありません。今回の作業と、別のチケットで扱う作業を区別するためです。

ここでいう How は、実装手順だけでなく、どう確認すれば完了と判断できるかです。この例なら、次の３つをチームで合意します。

「受付完了の案内が出た」ことと「担当者の受信箱にメールが届いた」ことは、別々に確認する必要があります。メール到着までを今回の完了条件に含めるなら、受信確認の方法と担当者もチケットに記載します。

Jira では、この作業の担当者、優先順位、スプリントでの進行を管理します（Delivery）。Confluence には、案内文を決めた背景や要件、検討した選択肢を残します（Discovery）。

チケットには必要なページへのリンクを付け、同じ説明を何度もコピーしないようにします。実装後は PR、確認結果、必要な画面の記録をつなぎます。レビューするチームメンバーが、条件と結果を照合できることが大切です。

コーディングエージェントに依頼するときも、目的、作業範囲、完了条件を引き継ぎます。加えて、対象のファイルや既存の実装、守るべき制約を示します。

不明点があれば実装前に確認し、生成された変更と確認結果をチームメンバーがレビューします。途中で新しい要件が見つかったら、今回の範囲を変えるか、次のチケットに分けるかを判断します。

まず、次のスプリントにあるチケットを１つ選んでみてください。目的は伝わるか。今回の範囲は分かるか。完了したことを他の人も確認できるか。この３つをチームで話し合うところから始められます。

アジャイルコーチング・研修では、実際の仕事を題材に、チケット駆動型開発と AI-DLC の進め方をご提案します。