チケットの書き方｜タスク・課題のテンプレートと良い例・悪い例

よいチケットは、「件名だけで何をするか分かる」「なぜやるか（背景）が書いてある」「どうなれば終わりか（完了条件）が書いてある」「1人が短い期間で終えられる大きさ」の4つを満たしています。 書いた本人がいなくても、別の人が読んで同じ作業ができる状態がゴールです。

確認環境：Backlog・Jira・GitHub Issues の項目名は、各社の公式ドキュメントで確かめました。GitHub の Issue テンプレート（YAML フォーム）は、Python 3.11・PyYAML 6.0.3・jsonschema 4.26.0（Linux）で、SchemaStore の「GitHub issue forms」スキーマを使って検証しました。階層の図は Mermaid 12.1.0 で描画できることを確かめています（確認日 2026年10月12日）。

チケットの種類

チケットは、種類によって書く項目が変わります。 同じ書式で全部を書こうとすると、バグに「完了条件」がなかったり、調査に「やること」が書けなかったりします。

Jira の公式ドキュメントでは、既定の作業の種類として Epic・Story・Task・Bug・Subtask が説明されています。たとえば Story は "the smallest unit of work that needs to be done"（ユーザーストーリーは、行う作業の最小の単位）、Subtask は "a piece of work that is required to complete a task"（タスクを終えるために必要な作業の一部）です。

flowchart TD
  E[エピック：経費申請を電子化する] --> S1[ストーリー：申請者として下書きを保存したい]
  E --> S2[ストーリー：承認者としてまとめて承認したい]
  E --> B1[バグ：金額にカンマを入れると保存できない]
  S1 --> T1[タスク：下書き保存の API を追加する]
  S1 --> T2[タスク：申請画面に保存ボタンを追加する]
  S1 --> T3[タスク：下書きの一覧を表示する]
  S2 --> R1[調査：一括承認の上限件数を決める]

種類別のテンプレート（コピペ用）

Backlog の「詳細」、Jira の「Description」、GitHub の Issue の本文に、そのまま貼れる Markdown です。

タスク

## 背景・目的
（なぜこの作業が必要か。関連するストーリー・チケットの番号）

## やること
- [ ] 
- [ ] 

## やらないこと
- （このチケットの範囲外。別チケットの番号）

## 完了条件
- [ ] （第三者が確かめられる条件）
- [ ] 単体テストを追加し、CI が通っている
- [ ] レビューで承認されている

## 参考
- 設計書：
- 関連チケット：

バグ

## 発生した環境
- 環境：検証環境 / 本番
- 版：v2.3.1
- ブラウザ・OS：

## 再現手順
1. 
2. 
3. 

## 期待する結果

## 実際の結果
（エラーメッセージは画面の文言をそのまま。画面のキャプチャ）

## 再現する頻度
毎回 / ときどき（10回中◯回） / 1回だけ

## 重大度・影響
- 重大度：
- 影響する利用者・業務：
- 回避策：

バグの書き方と重大度の決め方は、関連記事「バグ報告の書き方｜コピペ用テンプレートと重大度判定表」で扱っています。

ストーリー

## ストーリー
（利用者）として、（したいこと）をしたい。なぜなら（目的）だからだ。

## 受け入れ基準
- [ ] Given （前提） When （操作） Then （結果）
- [ ] 

## 対象外
- 

## メモ
- 見積もり（ストーリーポイント）：
- 分けたタスク：#

ストーリーと受け入れ基準の書き方は、関連記事「ユーザーストーリーの書き方と例30選｜受け入れ基準Given-When-Then」で扱っています。

調査（スパイク）

## 問い（調べて決めること）
（例：一括承認の上限件数を何件にするか）

## 期限・時間の上限
- 期限：
- 使う時間の上限：

## 調べること
- [ ] 
- [ ] 

## 結論（終わったら書く）
- 決めたこと：
- 理由・根拠：
- 次のチケット：#

調査のチケットは、「時間の上限」と「結論の欄」が大事です。 上限がないと調べ続けてしまい、結論の欄がないと、調べたことがチケットのコメントに散らばります。

件名の付け方

件名は、一覧の画面で「どれが自分の作業か」「何が終わっていないか」を見分けるためのものです。 一覧では件名しか見えないことが多いので、件名だけで中身が分かるように書きます。

完了条件の書き方

完了条件は、「作業した人以外が、同じ判断で『終わった』と言える」ように書きます。 「対応する」「確認する」だけでは、どこまでやれば終わりかが人によって変わります。

チーム全体で毎回求める条件（レビュー済み、テストが通る、ドキュメントを更新）は、チケットごとに書かずに「完成の定義（DoD）」として1か所にまとめると、チケットには固有の条件だけを書けます。関連記事「完成の定義（DoD）の例とチェックリスト｜受け入れ基準との違い」で扱っています。

粒度の目安

チケット1枚は、「1人が」「短い期間で」「1回のレビューで見られる量」で終えられる大きさにします。 スクラムガイド（2020年版）では、スプリントの計画で、プロダクトバックログの項目を "smaller work items of one day or less"（1日以下の小さな作業）に分けることが多いと書かれています。また、1スプリントの中で終えられる項目が、スプリントの計画で選べる状態とされています。

逆に、細かすぎるチケット（「変数名を変える」など）が増えると、チケットを更新する手間のほうが大きくなります。 その場合は、1つのタスクのチェックリストにまとめます。作業の分け方の考え方は、関連記事「WBSの作り方｜システム開発の実例表と分解を止める判断基準」で扱っています。

良い例・悪い例の対比

タスクの例

悪い例

件名：下書き
本文：下書き機能お願いします。

良い例

件名：[経費申請] 下書き保存の API を追加する

## 背景・目的
#120「申請者として下書きを保存したい」のサーバー側の作業。

## やること
- [ ] POST /api/expenses/drafts を追加（入力チェックは申請と同じルールのうち、必須チェックだけ外す）
- [ ] 下書きの保存期間（90日）を過ぎたものを消すバッチの設定を追加

## やらないこと
- 画面の変更（#122 で行う）

## 完了条件
- [ ] 必須項目が空でも保存でき、GET で同じ内容が返る
- [ ] 他人の下書きは取得できない（403 が返る）
- [ ] 単体テストを追加し、CI が通っている

「90日」は例の値です。

バグの例

「期待する結果」が書かれていないバグは、仕様どおりの動きなのか、不具合なのかを判断できません。 上の例では、「カンマ付きの金額を受け付けるか」が仕様で決まっているかを、まず確かめることになります。

よくある悪い書き方の一覧

Backlog・Jira・GitHub Issues の項目名の対応

ツールが変わっても、書く中身は同じです。 項目名だけが違います。表は、各社の公式ドキュメント（Backlog は課題の追加 API、Jira は Issue／work item の項目の説明、GitHub は Issue の説明と Issue フォームの構文）で確かめた名前です。

• Backlog の課題の追加 API では、件名・種別・優先度が必須（プロジェクトの指定も必須）で、詳細・担当者・期限日などは任意です。
• Jira の Cloud 版のドキュメントでは、「Issue」は「work item」と呼ばれるようになっています。項目名は、管理者の設定で変えられることがあります。
• GitHub Docs の Issue の説明では、Issue に付けられる情報として、担当者・Issue type・ラベル・マイルストーン・sub-issue（子の Issue）・依存関係（blocking）・Projects が挙げられています。

課題をスプレッドシートで管理する場合の項目は、関連記事「課題管理表のテンプレートと書き方 項目一覧・記入例・Excel数式」で扱っています。

GitHub の Issue テンプレート（YAML フォーム）の雛形

.github/ISSUE_TEMPLATE/ に YAML のファイルを置くと、Issue を作る画面が入力フォームになります。 GitHub Docs では、name・description・body が必須のキーで、ファイルは既定のブランチにコミットしたときに使えるようになると説明されています。

.github/
└── ISSUE_TEMPLATE/
    ├── task.yml      タスク
    ├── bug.yml       バグ報告
    └── config.yml    テンプレートを選ぶ画面の設定

task.yml

name: タスク
description: 作業を1つ登録します（1人が1日程度で終えられる大きさに分けます）
title: "[タスク] "
labels: ["task"]
body:
  - type: markdown
    attributes:
      value: |
        件名は「[画面・機能] 何を どうする」の形で書きます。例：[経費申請] 下書き保存のAPIを追加する
  - type: textarea
    id: background
    attributes:
      label: 背景・目的
      description: なぜこの作業が必要か。関連するチケットやストーリーの番号も書きます。
      placeholder: "#123 のストーリー（下書き保存）を実現するため"
    validations:
      required: true
  - type: textarea
    id: scope
    attributes:
      label: やること
      value: |
        - [ ] 
        - [ ] 
    validations:
      required: true
  - type: textarea
    id: out-of-scope
    attributes:
      label: やらないこと
      placeholder: "画面側の変更は #125 で行う"
  - type: textarea
    id: done
    attributes:
      label: 完了条件
      description: 第三者が「終わった」と判断できる形で書きます。
      value: |
        - [ ] 
        - [ ] レビューで承認されている
    validations:
      required: true
  - type: dropdown
    id: priority
    attributes:
      label: 優先度
      options:
        - 高
        - 中
        - 低
      default: 1
    validations:
      required: true
  - type: input
    id: estimate
    attributes:
      label: 見積もり（時間）
      placeholder: "6"

bug.yml

name: バグ報告
description: 不具合を報告します
title: "[バグ] "
labels: ["bug"]
body:
  - type: input
    id: environment
    attributes:
      label: 発生した環境
      placeholder: "検証環境 / v2.3.1 / Chrome 141 / Windows 11"
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: 再現手順
      value: |
        1. 
        2. 
        3. 
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: 期待する結果
    validations:
      required: true
  - type: textarea
    id: actual
    attributes:
      label: 実際の結果
      description: エラーメッセージは、画面の文言をそのまま貼ります。
    validations:
      required: true
  - type: dropdown
    id: frequency
    attributes:
      label: 再現する頻度
      options:
        - 毎回
        - ときどき
        - 1回だけ
    validations:
      required: true
  - type: dropdown
    id: severity
    attributes:
      label: 重大度
      options:
        - 致命的（業務が止まる）
        - 高（回避策がない）
        - 中（回避策がある）
        - 低（表示の崩れなど）
    validations:
      required: true
  - type: textarea
    id: logs
    attributes:
      label: ログ
      render: shell
  - type: checkboxes
    id: checks
    attributes:
      label: 登録前の確認
      options:
        - label: 同じ内容のチケットがないことを検索した
          required: true

config.yml

blank_issues_enabled: false
contact_links:
  - name: 使い方の質問
    url: https://example.com/faq
    about: 操作の質問は、こちらのFAQを先に見てください

GitHub Docs では、blank_issues_enabled: false にすると、Read・Triage の権限の人にはテンプレートだけが表示され、Write 以上の権限の人には引き続き空の Issue の選択肢が表示されると説明されています。url は自分のチームのページに書き換えます。

スキーマで検証した結果

task.yml と bug.yml は、SchemaStore の「GitHub issue forms」の JSON スキーマで検証し、どちらもエラーはありませんでした。 SchemaStore はエディタの補完などに使われる、コミュニティが管理するスキーマ集です（GitHub の公式のものではありません）。わざと誤りを入れると、次のエラーになりました。

スキーマでは見つからない落とし穴もありました。 最初、placeholder: 画面側の変更は #125 で行う と引用符なしで書いたところ、YAML では「空白のあとの # から後ろ」がコメントになるため、読み込んだ値は「画面側の変更は」だけになりました。# を含む値は、引用符で囲みます。 GitHub Docs でも、markdown 要素の見出しの # について、文字列を引用符で囲むよう注意書きがあります。

import json, yaml, jsonschema   # PyYAML 6.0.3 / jsonschema 4.26.0

schema = json.load(open("github-issue-forms.json"))   # SchemaStore のスキーマ
for f in ["task.yml", "bug.yml"]:
    data = yaml.safe_load(open(f".github/ISSUE_TEMPLATE/{f}", encoding="utf-8"))
    jsonschema.validate(data, schema)                  # 誤りがあれば例外になる
    print(f, "OK", len(data["body"]), "要素")

task.yml OK 7 要素
bug.yml OK 8 要素

validations の required: true は、GitHub Docs ではパブリックリポジトリでのみ働くと書かれています。 プライベートリポジトリでは、必須にした欄が空でも Issue を作れる点に気をつけます。Issue をコマンドラインから作る方法は、関連記事「GitHub CLI（gh）の使い方｜逆引きコマンド一覧とjqレシピ」で扱っています。

よくある質問

Q. チケットと課題とタスクは、何が違いますか。 A. ツールによって呼び方が違うだけで、指しているものはほぼ同じです。Backlog では「課題」、Jira では「work item（以前は Issue）」、GitHub では「Issue」と呼びます。この記事では、それらをまとめて「チケット」と呼んでいます。

Q. 完了条件と受け入れ基準は同じですか。 A. ストーリーのチケットでは、受け入れ基準が完了条件の中心になります。タスクのチケットでは、「API が追加され、テストが通っている」のような作業の完了条件を書きます。両方に共通する条件は、完成の定義（DoD）にまとめます。

Q. 生成AIの開発エージェントに渡すチケットは、何を足せばよいですか。 A. 人に渡すときより、やらないことと完了条件の確かめ方（どのテストを流せばよいか）を詳しく書くと、作業の範囲がぶれにくくなります。関連記事「AIエージェントのタスク分解｜指示書テンプレートと粒度の判断表」で扱っています。

Q. チケットが多すぎて、どれからやればよいか分かりません。 A. 優先度の欄を使い、並べ替えの基準をチームで決めます。決め方は、関連記事「優先順位の付け方｜緊急度×重要度マトリクスの例と点数表」で扱っています。チケットの流れを見えるようにするには、関連記事「カンバン方式のやり方 列の例とWIP制限の決め方・計算例」が参考になります。

まとめ

• よいチケットは 件名で中身が分かり、背景と完了条件があり、1人が短い期間で終えられる
• 種類で書く項目が変わる。タスクは完了条件、バグは再現手順と期待する結果、ストーリーは受け入れ基準、調査は問いと時間の上限
• 件名は 「[対象] 何を どうする」。完了条件は 結果の状態・値・確かめ方で書く
• 粒度は、スクラムガイドの 「1日以下の作業」 を目安に、担当・レビューの量で分ける
• GitHub の Issue フォームは name・description・body が必須。# を含む値は 引用符で囲む

参考・出典

確認日はいずれも 2026年10月12日です。

• Backlog API「課題の追加」：https://developer.nulab.com/ja/docs/backlog/api/2/add-issue
• Atlassian「What are work types?」（Jira Cloud）：https://support.atlassian.com/jira-cloud-administration/docs/what-are-issue-types/
• Atlassian「What is an Issue」（Jira の項目の説明）：https://confluence.atlassian.com/display/JIRA062/What+is+an+Issue
• GitHub Docs「About issues」：https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues
• GitHub Docs「Syntax for issue forms」：https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms
• GitHub Docs「Syntax for GitHub's form schema」：https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-githubs-form-schema
• GitHub Docs「Configuring issue templates for your repository」：https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository
• SchemaStore「github-issue-forms.json」：https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/github-issue-forms.json
• The Scrum Guide（2020）：https://scrumguides.org/scrum-guide.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。