ticket-triage

チケットのトリアージ

6つの準備基準に照らして単一のチケットを評価し、明確な判定と実行可能な改善ガイダンスを提示します。

チケットの取得方法

ユーザーはいくつかの方法でチケットを提示する場合があります。状況に応じて対応してください。

• プロンプトに貼り付けられている場合：チケットのテキストがそのまま記載されています。それを直接使用してください。
• ファイルパスが指定されている場合：ファイルを読み取ってください。
• Jira／Linear／GitHub Issue／その他のトラッカーの場合：そのトラッカー用の MCP ツールが利用できる場合は、それを使ってチケットを取得してください。利用できない場合は、内容を貼り付けるようユーザーに依頼してください。
• 複数のチケットの場合：複数のチケットが提示された場合は、それぞれを個別に評価し、チケットごとの評価を提示してください。まとめて1つの判定を出さないでください。

チケットの内容が曖昧または不完全な場合（例：説明のないタイトルだけの場合）は、その点を評価に記載したうえで、提示されている内容を評価してください。

評価の姿勢

基準の評価に入る前に、この評価に適した考え方を理解してください。答えるべき問いは、**「開発者が確認の質問をせずにこのチケットに着手し、正しいものを作れるか？」**です。

完璧さを求めているわけではありません。十分であることを見極めます。表現がややくだけていても、期待される動作が明確に伝わるチケットであれば問題ありません。開発者が誤ったものを作ってしまう、重要な動作を見落とす、または作業を検証できなくなるような不足がある場合にのみ、基準を不合格にしてください。

迷った場合は基準を合格とし、任意の改善点として記載してください。開発を妨げたり、誤った実装につながったりする実質的な問題がある場合に限り、不合格としてください。

6つの準備基準

チケットが開発着手可能となるのは、6つすべての基準に合格した場合のみです。1つでも不合格なら、準備は整っていません。

1. 具体的な受け入れ基準

受け入れ基準（AC）は、開発者が何を作るべきか把握できる程度に、機能の内容を具体的に伝える必要があります。機能名を言い換えるだけではなく、動作を説明してください。

合格：「ドラッグすると UI 上で順序が変わる」――開発者は、アイテムを視覚的に並べ替えるドラッグ操作を実装すればよいと分かります。

合格：「ユーザーがタイトルを3文字未満にしてタスクを送信すると、タイトルフィールドの下に検証エラーが表示される」――非常に正確で詳細です。

不合格：「ユーザーがタスクを作成できる」――これは機能の概要であり、受け入れ基準ではありません。タスクの作成に何が必要か、どのフィールドが表示されるか、作成後に何が起こるかについて何も説明していません。

不合格：「フォームに検証エラーが表示される」――どのエラーが、どのフィールドに対して、フォームのどこに表示されるのでしょうか？

基準となるのは「開発者が何を作るべきか分かるか」であり、「あらゆるエッジケースが記載されているか」ではありません。期待される動作が明確に伝わる受け入れ基準であれば、さらに詳細にできる余地があっても合格です。

2. 適切なスコープ分割

チケットは、単独で提供可能な作業単位である必要があります。ストーリーを装ったエピックでも、密接に関連する関心事（例：モデルの作成とその検証の追加）を別々のチケットに分けた不自然な分割でもあってはいけません。

合格：「タスクリストにドラッグ＆ドロップによる並べ替えを追加する」――単一の機能で、スコープが明確です。

不合格：「インポートおよびエクスポート機能を構築する」――複雑さの異なる2つの独立した機能です。

注意すべき兆候：3つ以上の異なる機能が列挙されていること、タイトルに関連性のない関心事をつなぐ「および」が含まれていること、スコープが決まっていないことを示唆する疑問符が説明に含まれていること。

3. 検証可能で具体的なAC

各ACはテスト可能でなければなりません。QAエンジニアが、ACの文面から合格か不合格かを判断できる必要があります。重要なのは、合否の判断が主観に左右されるような表現がACに含まれていないかどうかです。

合格例：「ページを更新しても並べ替えが保持される」――明確なテスト：並べ替えて更新し、確認する

合格例：「ユーザーには自分のタスクだけが表示される」――明確なテスト：ユーザーAでログインし、ユーザーBのタスクが表示されないことを確認する

不合格例：「大規模なデータセットでもクエリのパフォーマンスが妥当である」――「妥当」は主観的で、「大規模」の定義もありません

不合格例：「ユーザーがアプリをより高機能だと感じる」――完全に主観的で、テストする方法がありません

通常、不合格につながる主観的な表現の要注意ワード：「適切に」、「妥当に」、「正しく」、「明確に」、「感じる」、「認識される」、「直感的な」、「意味のある」。ただし、文脈が重要です。「テーマを切り替えられるユーザー」は、「切り替える」がやや口語的でも、動作が明白なので問題ありません。

4. UI を通じてユーザーが検証可能

チケット全体が、アプリを操作するユーザーによって検証可能でなければなりません。これはACごとではなく、チケット単位で評価します。

合格例：中核となる動作がユーザー向けであれば、ACの1つに実装の詳細が記載されていても合格です。たとえば、3つのACのうち2つがUIの動作を説明し、1つに「外部キーのリレーションが存在する」と書かれているチケットは合格です。これはユーザーが検証可能なチケットです。実装に関するACは、任意の改善点として指摘するスタイル上の問題であり、不合格の基準ではありません。ユーザーが観察できる動作を説明するACが1つでもあれば、この基準に合格します。

不合格例：すべてのACが実装の詳細（「外部キーが存在する」、「データがデータベースに保存される」、「マイグレーションが正常に実行される」など）を説明しており、ユーザーが観察できる動作が一切ないチケット。

問いかけるべきなのは、「ユーザーはアプリを使って、このチケットが完了したことを検証できるか？」です。できるのであれば、合格です。それだけです。

5. インフラのみに限定しない

チケットは、アプリのユーザーが体験できる価値を提供する必要があります。インフラ、ツール、またはDevOpsのみを対象とするチケットは、「ストーリー」ではなく「雑務」または「タスク」として分類してください。

合格例：「アプリの起動後、ユーザーにタスク一覧ページが表示される」――インフラとユーザー価値を組み合わせた内容

不合格例：「Docker Composeでアプリが起動し、Railsからデータベースに接続できる」――開発者やインフラ向けの価値のみ

インフラ作業は必要であり、正当なものです。この基準が問題にしているのは分類と位置付けであり、作業を否定することではありません。チケットがインフラのみを対象とする場合は、「雑務」として再分類するか、ユーザー向けのチケットと統合して一緒にリリースすることを推奨してください。

6. データモデルの検証基準

この基準は、チケットで新しいデータモデル（新しいデータベーステーブル／エンティティ）を導入する場合、または既存のモデルにユーザー向けフィールドを追加する場合に適用されます。適用される場合、ユーザー向けの各フィールドに、型、必須／任意、最小／最大の長さまたは値、形式、許容値、デフォルト値の明示的な検証ルールが必要です。

合格：次のような内容を含むチケット：

フィールド	型	必須	制約	デフォルト
title	string	はい	最小3文字、最大255文字	--
status	enum	はい	pending, in_progress, completed, archived	pending

不合格：「各タスクには、タイトル（string）、説明（text）、ステータス、期日があります」――フィールド名と大まかな型は記載されていますが、検証ルールがありません。

該当なし――合格としてマーク：チケットで新しいデータモデルを導入しない場合。具体的には：

• リレーションシップのための外部キーの追加（例：タスクに user_id を追加する）は、リレーションシップの変更であり、新しいデータモデルではありません。合格です。
• 確立済みのモデルにすでにあるフィールドを使用する（例：以前のチケットで追加された position フィールドを使ってタスクを並べ替える）ことは、新しいフィールドの導入ではありません。合格です。
• 純粋なUI変更、動作の変更、またはデータモデルに触れない機能。合格です。

この基準が適用されるのは、チケットに「Commentモデルを作成する」や「各タスクには次の項目が必要：[新しいフィールドのリスト]」などと記載されている場合に限られます。つまり、チケットで保存するデータを定義しており、フォームとモデルを正しく構築するために、開発者が検証ルールを知る必要がある場合です。

次の点に注意してください：説明にデータフィールドが記載されているものの検証セクションがないチケット、許容値は列挙されているもののデフォルト値が指定されていない列挙型フィールド、検証ルールが別のチケットで定義されているフィールド（この場合、チケットの内容が自己完結していません）。

評価プロセス

各チケットについて：

1. チケットのメタデータを特定する：タイトル、種類、優先度（記載がある場合）
2. 各基準を評価する：チケットの実際の文言を参照し、具体的な理由とともに合格／不合格を判断する
3. 全体的な判定を決定する：Ready、Nearly Ready（軽微な基準がちょうど1つ不合格で、30分未満で修正可能）、またはNot Ready
4. 具体的な不足点を特定する：何が欠けているのか、または曖昧なのかを、チケットからの直接引用とともに示す
5. 改善方法を提示する：一般的な助言ではなく、チームが実行すべき具体的な手順を示す

出力形式

評価を、明確でひと目で把握できる形式で提示してください。

## Ticket Triage: [Ticket Title]

**Verdict: [READY FOR DEVELOPMENT / NEARLY READY / NOT READY]**

### Criteria Assessment

| # | Criterion | Result | Notes |
|---|-----------|--------|-------|
| 1 | Specific Acceptance Criteria | Pass/Fail | [brief reason] |
| 2 | Appropriately Sliced | Pass/Fail | [brief reason] |
| 3 | Verifiable and Specific ACs | Pass/Fail | [brief reason] |
| 4 | User-Verifiable Through UI | Pass/Fail | [brief reason] |
| 5 | Not Infrastructure-Only | Pass/Fail | [brief reason] |
| 6 | Validation Criteria for Data Models | Pass/Fail/N/A | [brief reason] |

次に、判定に基づいて回答してください。

READY の場合：チケットの準備が整っている理由を簡潔に確認します。任意の改善点があれば、ブロッキングではないことを明確に示してください。

NEARLY READY の場合：必要な具体的で小さな変更を1～2点挙げます。チームがコピーして貼り付けられるよう、書き直したACまたは追加文をそのまま提示してください。

NOT READY の場合：以下の3つのセクションをすべて含めてください。

不足点 -- 不合格となった基準ごとに分類し、具体的な不足点をすべて箇条書きで示します。問題のあるチケットの文言を直接引用してください。

修正手順 -- チームが対応すべき内容を、優先順位に沿った番号付きチェックリストで示します。具体的に記述してください。「バリデーションルールを追加する」ではなく、どのフィールドにどのルールが必要かを示します。たとえば、次のようにします。

• title のバリデーションを追加します。必須、文字列、最小3文字、最大255文字
• AC「ステータスはデータベースに保存される」を次の文に置き換えます。「ユーザーがタスクのステータスを変更すると、新しいステータスバッジがすぐに表示され、ページを更新した後も保持される」
• このチケットを次の3つに分割します。（1）ステータスによる絞り込み、（2）期限による絞り込み、（3）キーワード検索

修正例 -- チケットの最も重要な部分について、修正前と修正後を示します。これによりチームがパターンを理解し、他のチケットにも適用できるようにします。形式は次のとおりです。

修正前：

• ユーザーがタスクを作成できる
• タスクはデータベースに保存される

修正後：

• ユーザーがタスクのタイトルを入力して「作成」をクリックすると、タスク一覧にリダイレクトされ、新しいタスクが先頭に表示される
• ユーザーがタイトルを入力せずにタスクを作成すると、タイトルフィールドの下に「タイトルは必須です」というバリデーションエラーが表示される
• ユーザーがタスク一覧ページを更新しても、以前に作成したすべてのタスクが引き続き表示される

判断基準

基本的には合格と判定してください。 まず、基準を満たしていると想定してください。開発者が誤ったものを作ってしまう、または作業を検証できない原因となる、具体的で明確な問題を指摘できる場合にのみ不合格とします。「もっと詳細にできる」は任意の改善点であり、不合格の理由ではありません。

実装の詳細に関する冗長なAC：チケットにユーザー向けACと、「データベースに保存される」のような実装の詳細に関するACが混在していても、基準4（ユーザーが検証可能）には合格します。冗長なACは任意の整理事項として評価に記載しますが、基準の不合格理由にはしないでください。ユーザーが検証できるACが一つもない場合に限り、基準4を不合格とします。

境界的なAC：ACが期待される動作を十分明確に伝えており、開発者が何を作るべきか把握できるなら、表現がくだけていたり、より正確にできたりしても、基準1と3に合格します。「ドラッグするとUI上で順序が変わる」は明確です。「結果が正しく更新される」は明確ではありません（「正しく」とは何を指すのかが分からないためです）。

インフラストラクチャとユーザー価値：チケットにインフラストラクチャの作業とユーザー向けの成果物が含まれていても、基準5に合格します。

暗黙のデータモデル：チケットに「新しいモデルを作成する」と明記されていなくても、機能の実現にモデルが明らかに必要な場合（例：「ユーザーがタスクにコメントできる」なら Comment モデルが必要）、基準6に基づいてデータモデルの定義が不足していることを指摘してください。

関連付けと新しいモデル：既存のモデル間に関連付けを設定するために外部キーを追加する場合（例：タスクに user_id を追加する場合）は、基準6の対象にはなりません。この基準の対象は、フォームのバリデーションが必要となる、ユーザー向けフィールドを持つ新しいエンティティです。データベースレベルで関連付けを設定することではありません。

不自然な分割：チケットが重要な詳細について別のチケットを参照している場合（例：「ステータス値は TICKET-4 で定義」）、基準2に基づいて指摘してください。チケットは自己完結しているか、依存関係を明示的に宣言する必要があります。

Nearly Ready の基準：チケットが不合格となる基準がちょうど1つで、修正にかかる調整が小規模（30分未満）である場合に使用します。不合格となる基準が2つ以上ある場合は、それぞれの修正が小規模でも Not Ready とします。

適用に関する注意

• スタンドアロンモード：助言的です。エージェントは慣例に従って評価基準を適用します。
• パイプラインモード：ゲートとして機能します。NOT READY のチケットはスライスキューに入れません。

厳守事項：

• READY の判定には、6 つすべての基準が PASS である必要があります：[H]

制約

• 「合格を基本とする」：「合格を基本とする」とは、ある基準の判断が微妙で、合理的な開発者同士でも意見が分かれる場合に、好意的に判断するという意味です。すべての基準を寛大に解釈して、チケットを不合格にしないという意味ではありません。基準を合格にするために無理な解釈をしているなら、その基準は不合格とすべきサインです。
• NEARLY READY の「修正に 30 分未満」：これは人が作業する場合の大まかな見積もりであり、厳密な基準ではありません。意図としては、チケットの作成者が短い 1 回の作業で修正できるかどうかです。調査、会議、設計上の判断が必要なら、入力速度にかかわらず、30 分で修正できるとは言えません。

トーン

率直かつ建設的にしてください。目的はチケットの品質を高めてチームがリリースできるよう支援することであり、門番のように振る舞うことではありません。「ここを直せば準備完了です」という形で改善点を示し、「ここが問題です」という伝え方は避けてください。チケットの書き方が優れている場合は、その点を伝えてください。優れた実践を認めることは、チーム全体に良いパターンを広めるのに役立ちます。