compare
Jiraのチケット作成で迷わない書き方｜受け取る人が動ける粒度
Jiraのチケット作成で手が止まるとき、詰まっている場所は画面の操作ではありません。どこまでを1枚にするのか、タイトルに何を書くのか、どこまで書けば受け取った人が着手できるのか。この3つが決まっていないから、作成の画面を開いたところで指が止まります。
先に結論を書きます。チケット作成で決めるべきものは2つだけです。1つは1枚の大きさ、つまり粒度。もう1つは完了の条件、つまり何が出来上がったら閉じてよいのかという線です。この2つが決まっていれば、残りの欄は埋まります。逆に、この2つを決めずに欄を全部埋めても、受け取った人は「で、何をすればいいのか」を聞き返してきます。
この記事では、チケットを作る作業そのものが重くなっている背景から始めて、動けないチケットに共通する欠け、タイトルの書き方、1枚の大きさの決め方、本文に並べる欄、作る手順、親子とサブタスクの境目、作成の手間を削る方法、そして無料の範囲でどこまで試せるかまでを順に扱います。
チケットを作る作業そのものが重くなっている背景
課題管理の道具が広く行き渡ったことで、以前なら口頭やチャットで済んでいた依頼が、いまはすべてチケットとして残るようになりました。残るのはよいことですが、副作用が2つ出ています。
1つ目は、作成の件数が増えたことです。1日に何枚も作るようになると、1枚あたりに掛けられる時間は数分しかありません。数分で書けるものは、たいてい「ログイン画面の件、お願いします」のような1行です。受け取った側はその1行では動けないので、確認のやり取りが始まります。作成が速くなったぶん、着手までの時間が伸びる。これが起きています。
2つ目は、入力できる欄が増えたことです。課題の種類、優先度、コンポーネント、担当者、報告者、期限、見積、スプリント、ラベル、エピック。欄が多いほど丁寧に管理できるように見えますが、実際には逆で、埋める人が減ります。必須にすれば埋まりますが、埋まるだけで中身は適当になります。優先度の欄が全部「中」になっているプロジェクトは、どこの現場にもあります。
Jiraの料金ページでは、無料のプランが最大10ユーザーまで永久に無料で、課題数とプロジェクト数に上限がなく、バックログ・リスト・ボード・タイムライン・カレンダー・要約の各ビューとレポートが含まれると案内されています。自動化はサブスクリプションあたり月150ステップ、ストレージは2GBです。有料のStandardは1ユーザーあたり月額1,085円、Premiumは月額1,987円と表示されています（2026年9月27日時点、月払いの表示。年間請求にすると最大17%割引と案内されています）。
つまり、5人から数十人のチームがチケット作成で困っているとき、その原因は料金プランでも機能の不足でもありません。作る側と受け取る側の間で、書き方の取り決めが無いことです。ここを取り決めれば、いまの道具のままで解決する部分が半分以上あります。
受け取る人が動けないチケットに共通する4つの欠け
読んだ人が着手できないチケットを並べてみると、欠けている情報は4種類に収まります。
1つ目は、どうなれば終わりなのかが書かれていないことです。「検索が遅いので改善してほしい」というチケットは、何秒になれば終わりなのかが書かれていません。受け取った人は自分で線を決めるしかなく、報告したあとで「まだ遅い」と差し戻されます。作った側は速さの目標を持っていたのに、書かなかっただけです。
2つ目は、誰のために必要なのかが書かれていないことです。依頼の背景が無いチケットは、優先順位を判断できません。受け取った人が他に5枚抱えていたとして、どれを先にやるかは背景で決まります。背景が無ければ、着手の順番は「目に付いた順」になります。
3つ目は、いまどうなっているのかが書かれていないことです。不具合の報告で多いのが、期待した結果だけが書かれているものです。「保存できるようにしてほしい」とだけ書かれていて、いま何が起きているのか、エラーの文言が出るのか、黙って失敗するのかが分かりません。再現の手順を探す時間が、修正そのものより長くなります。
4つ目は、どこの話なのかが書かれていないことです。画面の名前、機能の名前、URL、対象の環境。この4つのどれかが欠けると、受け取った人は探し始めます。同じ名前の画面が2つある製品では、探すだけで30分溶けます。
この4つを裏返すと、チケットに必要な情報が出ます。完了の条件、背景、現状、対象の場所です。優先度やラベルは運用の都合で追加する欄で、着手には要りません。順番を逆にして、運用の欄から埋め始めるチームは、この4つが抜けたまま作成を終えてしまいます。
種類を3つに絞ると、書く内容が決まる
課題の種類を細かく分けているチームは多いのですが、書き方の取り決めという観点では3つで足ります。不具合、要望、調査です。この3つは、必要な情報が根本的に違います。
不具合は、あるべき状態が既に決まっているものです。だから完了の条件を書く必要がありません。代わりに必要なのは、再現の手順と、いま起きている症状です。この2つが揃っていれば、受け取った人は直せます。逆に、不具合のチケットに設計の相談を書き込むと、話が2つ混ざって着手できなくなります。
要望は、あるべき状態がまだ決まっていないものです。だから完了の条件が最も重要になります。ここを書かずに要望を出すと、受け取った人が想像で作り、あとで作り直しになります。要望のチケットで手を抜いてよい欄は再現の手順で、抜いてはいけない欄は完了の条件です。
調査は、答えが出るまで何が必要か分からないものです。完了の条件は「何が分かったら終わりか」という形で書きます。「なぜ遅いのかを特定して、原因を1行で報告する」。ここを決めないと、調査は無限に続きます。調査のチケットには期限ではなく、掛けてよい時間の上限を書くのが実務的です。半日調べて分からなかったら、分からなかったという報告で閉じる。この取り決めがあるだけで、調査が塩漬けになりません。
種類を細かく分けたくなる気持ちは分かりますが、種類が10個あると、作る人は選ぶだけで迷います。迷った結果、全部が同じ種類になります。3つに絞って、それぞれの書き方を決めるほうが、実際には細かく管理できます。
タイトルは「対象と、どうするか」で書く
タイトルは一覧で読まれます。一覧に並んだときに何の話か分かるかどうかが、唯一の基準です。
書き方の型は1つで足ります。「どこの」「何を」「どうするか」を並べます。「請求書の一覧で、締切の並べ替えが効かないのを直す」「メンバー招待のメールに、送信元の名前を入れる」。この形で書くと、対象と動作が両方入ります。
逆に、一覧で役に立たないタイトルには特徴があります。名詞だけで終わっているもの、たとえば「検索の改善」「表示崩れ」。何を指しているのか分からないので、開かないと判断できません。一覧を100枚スクロールする人にとって、開かないと分からないタイトルは存在しないのと同じです。
もう1つ避けたいのが、タイトルに背景を詰め込むことです。「先週の打ち合わせで決まった、来月のキャンペーンに間に合わせるための請求書一覧の並べ替え対応」。長いタイトルは一覧で途中が切れて、いちばん大事な「並べ替え」が見えなくなります。背景は本文の欄に書きます。
記号の使い方も取り決めておくと、一覧が読みやすくなります。ただし、角括弧で分類を頭に付ける書き方は、分類の欄がある道具では二重管理になります。コンポーネントやラベルで表現できるものをタイトルに書くと、片方だけ直したときに食い違います。タイトルに書くのは、欄では表現できないことだけにします。
数字を入れられるなら入れます。「一覧の表示を1秒以内にする」は、完了の条件がタイトルに入った状態です。一覧を眺めるだけで、終わったかどうかの判定基準が分かります。ただし、数字を入れられない種類のチケットに無理に入れる必要はありません。
1枚の大きさを決めるのが最初の仕事
粒度は、チケット運用のほぼ全部を決めます。ここが揃っていないプロジェクトでは、進捗の報告が成立しません。
目安としては、1枚が半日から3日で終わる大きさに揃えると、5人から数十人のチームで扱いやすくなります。この範囲にする理由は、報告の頻度と噛み合うからです。毎日の短い確認で運用するなら、3日を超えるチケットは3日連続で「作業中」という報告になります。遅れているのか順調なのか、報告からは読み取れません。
大きすぎる1枚の見分け方は簡単です。進捗を聞かれたときに割合で答えるしかないチケットは、大きすぎます。「70%です」という報告は、残り30%が半日なのか1週間なのかを伝えていません。終わったか終わっていないかで答えられる大きさまで割ると、報告が見込みの数字ではなくなります。
小さすぎる1枚の見分け方も明確です。担当者以外の誰も関心を持たないものは、チケットにする必要がありません。その人の手元のメモで済みます。チケットにするのは、誰かの作業の前提になっているもの、または遅れたら他の人に影響が出るものです。この基準で切ると、件数はかなり減ります。
割り方には順番があります。まず成果物で割り、次に作業で割ります。「テストをする」という作業で割ると完了の判定が曖昧になりますが、「結合テストの結果一覧」という成果物で割れば、出来上がったかどうかで判定できます。作業の動詞で割ったチケットは、どこまでやれば終わりなのかが人によって違います。
なお、粒度を揃える作業は、作成の時点でしかできません。作ってしまったあとに大きすぎると気づいても、分割は面倒で、たいてい放置されます。作成の画面を開いた時点で、この1枚が3日で終わるかを自問する習慣を付けるほうが安く済みます。
本文に並べる5つの欄
本文の書式を決めておくと、書く時間が短くなります。白紙に向かうより、見出しが並んでいるほうが手が動きます。
第1の欄は、背景です。なぜこれが必要なのかを2行で書きます。「お客様から3件問い合わせが来ている」「来月の請求に間に合わせる必要がある」。ここが優先順位の判断材料になります。
第2の欄は、現状です。いま何が起きているかを書きます。不具合なら再現の手順を番号で並べ、エラーの文言はそのまま貼ります。要望なら、いまはどうやって回避しているかを書きます。回避の方法が分かると、受け取った人は緊急度を判断できます。
第3の欄は、期待する状態です。どうなってほしいのかを書きます。ここで注意したいのは、実現の方法を書かないことです。「ボタンを画面の右上に増やしてほしい」と書くと、方法が固定されます。「一覧から直接、締切を変えられるようにしたい」と書けば、受け取った人がより良い方法を選べます。
第4の欄は、完了の条件です。何が確認できたら閉じてよいのかを、箇条書きで並べます。 ・一覧の並べ替えが締切の昇順と降順で切り替わる ・並べ替えた状態で画面を移動しても、戻ったときに維持されている ・件数が1,000件のときも1秒以内に並び替わる この欄があると、差し戻しが激減します。作った側と受け取った側で、終わりの線が共有されるからです。
第5の欄は、対象の場所です。画面の名前、URL、対象の環境、関係する仕様書の在りか。探す時間をここで消します。
この5つ以外は、書かなくても着手できます。工数の見積、影響範囲の調査結果、代替案の比較は、着手した人が調べて追記するものです。作成の時点で全部揃えようとすると、作成が止まります。
作る手順を6つのステップに分ける
順番を守るだけで、書き直しが減ります。
第1のステップは、それが1枚かどうかを確かめることです。依頼の中に「そして」が入っていたら、2枚に分かれる可能性があります。「請求書の一覧を並べ替えられるようにして、そのついでに印刷も直したい」は2枚です。
第2のステップは、完了の条件を先に書くことです。順番が逆になりやすい箇所ですが、ここを先に書くと1枚の大きさが決まります。完了の条件が5個以上並んだら、そのチケットは大きすぎます。
第3のステップで、タイトルを書きます。完了の条件を書いたあとなので、何をどうするのかが自分の中で固まっています。先にタイトルから書くと、抽象的な言葉になりがちです。
第4のステップで、背景と現状を書きます。ここは事実を並べるだけなので、迷いません。
第5のステップで、欄を埋めます。種類、担当者、期限、関係するもの。担当者を決められないときは、空のままにしておくほうがよいです。とりあえず誰かに割り当てると、その人は自分の仕事だと思わないまま通知を受け取り続けます。
第6のステップで、関連するものと結び付けます。前のチケットの続きなら、その関係を残します。この作業を飛ばすと、半年後に「なぜこの仕様にしたのか」を追えなくなります。
この6つのうち、省略されがちなのは第2と第6です。第2を省くと差し戻しが増え、第6を省くと経緯が消えます。どちらも、省いた時点では困りません。困るのは1か月後です。
親子とサブタスクを使い分ける境目
大きな仕事を分けるとき、どこまで階層にするかで悩みます。基準は1つで、他人に影響するかどうかです。
他人に影響する分割は、階層にします。設計を終えないと実装に入れない、実装を終えないとテストに入れない。この前後関係があるなら、それぞれを独立した1枚にして、関係を結びます。前の1枚が遅れたときに、後ろの1枚も動くべきだと分かる形にしておきます。
他人に影響しない分割は、1枚の中のチェックリストにします。担当者が作業を進めるために自分で分けた手順は、他の人が見る必要がありません。チェックリストにしておけば、進み具合は1枚の表から見えます。件数を増やさずに、細かさを保てます。
階層を深くしすぎると、一覧で全体が見えなくなります。3階層を超えると、どの階層を見ているのか分からなくなり、開いたり閉じたりの操作が増えます。第3階層までで収まらない大きさなら、それは1つのプロジェクトとして分けるべき規模です。
もう1つ、階層を作るときに決めておきたいのが、期限の持ち方です。上の階層と下の階層の両方に期限を入れると、必ず食い違います。下の階層の最も遅い期限が、上の階層の期限になる形にしておくと、二重管理になりません。上に手で入れた期限は、下が動いても追従しないので、いつのまにか嘘になります。
作る手間そのものを削る
書き方が決まっても、毎回同じことを手で打つのは無駄です。削る方法は3つあります。
1つ目が、テンプレートです。不具合の報告、機能の要望、調査の依頼。種類ごとに本文の見出しを用意しておけば、書く人は埋めるだけになります。テンプレートの効果は文章の質より、抜けが減ることに出ます。
2つ目が、繰り返しの登録です。毎月同じ手順で発生する作業は、毎回手で作る必要がありません。前月の1枚を複製して日付だけ直す運用でも、十分に手間は減ります。
3つ目が、画面を開かずに作ることです。コマンドから作る仕組みが用意されている道具では、手元の作業を中断せずに1枚を登録できます。
こうした悩みは jira-cli を導入することで解決できました。ターミナルからチケットを作成でき、Claude CodeやChatGPTを使うことで、チケット作成をほぼAIで自動化することが可能できました。 出典: qiita.com
ただし、作成を自動化するときに気を付けたい点が1つあります。作るのが速くなると、件数が増えます。件数が増えて、読まれない1枚が積み上がると、一覧そのものが信用されなくなります。自動化を入れるなら、同時に「閉じる」側の運用も決めてください。3か月動いていないものは閉じる、というだけの決まりで十分です。
自動化の回数に上限があるプランを使っている場合は、その上限も確認しておいてください。Jiraの料金ページでは、無料のプランの自動化がサブスクリプションあたり月150ステップ、Standardが1ユーザーあたり月400ステップと案内されています（2026年9月27日時点）。人数が増えると、上限の数え方が変わる点は判断の材料になります。
閉じる取り決めが無いと、作成の質は下がる
作成の話をするときに抜け落ちるのが、閉じる側の取り決めです。ここが無いプロジェクトでは、一覧が数百枚に膨らみ、誰も最後まで見なくなります。見られない場所に作られるチケットは、丁寧に書く動機が湧きません。つまり、閉じる運用は作成の質に直結します。
取り決めは3つで足ります。1つ目は、完了の条件を満たしたら作った人が閉じることです。直した人が閉じる運用にすると、本当に直ったかの確認が飛びます。2つ目は、3か月動いていないものを一度まとめて見直すことです。やらないと決めたものは、やらないという状態にして閉じます。「いつかやる」の欄に移すのは、閉じるのと同じ効果があります。3つ目は、重複を見つけたら片方を閉じて、もう片方に情報を寄せることです。同じ話が2枚に分かれていると、片方だけ直って終わります。
この見直しに掛かる時間は、5人のチームで月に30分程度です。30分を惜しんで一覧が膨らむと、必要な1枚を探す時間が毎日数分ずつ増えます。1か月で元が取れる作業です。見直す日を月の初めに固定して、担当を持ち回りにしておくと続きます。誰かの気づきに任せると、忙しい月から順に飛びます。
無料の範囲でどこまで試せるか
書き方の取り決めを作ったあと、道具を替えるかどうかを考える段階に入ることがあります。そのとき最初に見るのは、無料の範囲に何が含まれるかです。判断したい機能が有料プランからしか使えない道具では、判断のために課金することになり、順序が逆になります。
公開されている料金ページを並べると、無料の範囲は道具ごとに大きく違います。Jiraは最大10ユーザーまで無料で、ボードもタイムラインもレポートも含まれます。Trelloは1ワークスペースにつき10ボード・10人までが無料で、カレンダーとタイムラインは有料のPremiumからです。Asanaは2人まで、monday.comは2人・ボード3つまでで、どちらも工程表の表示は有料プランからになります。Backlogは10人・1プロジェクトまでが無料で、ガントチャートは含まれません。
人数で切る道具と、機能で切る道具があるということです。5人のチームがガントチャートを試したいだけなら、人数の上限に余裕がある道具を選んでも、肝心の工程表が有料なら試せません。逆に、機能が全部使える道具でも、人数の上限が2人ならチームで試せません。自分が確かめたいことが無料の範囲に入っているかを、先に見てください。
そして、料金の比較で見落としやすいのが税の扱いと請求の単位です。1人あたりの月額で書かれている道具と、組織あたりの定額で書かれている道具を、同じ表に並べると判断を誤ります。30人で使うなら、1人あたり月額500円（税抜）の道具は月額15,000円、組織あたり月額16,000円（税抜）の道具とほぼ同じになります。人数が50人を超えると、定額のほうが安くなります。自分の人数を当てはめてから比べてください。
道具の違いを分解して考える
チケット作成の詰まりは、書き方の取り決めで7割が解決します。残る3割は、道具の作りに由来します。分けて考えると、次に何を変えるかが決まります。
道具の作りに由来する部分は3つです。1枚を別の見え方でも見られるか、前後関係が自動で動くか、話した内容が1枚に残るか。この3つを比べるための材料を挙げておきます。
1枚のカードを、一覧としても、横棒の工程表としても、カレンダーとしても見られる作りのものがあります。どの見え方で何が分かるのかはできることのページに8種類のボードとして整理されていて、チケットの一覧と工程表を別の場所で管理する場合との違いを確かめる材料になります。同じカードを直せば全部の見え方が変わるので、工程表を引き直す作業そのものが消えます。カードの中にチェックリストを作れる点も、階層を増やさずに細かさを保つ話と噛み合います。
会話が1枚に残るかどうかも、確認のやり取りの量に効きます。同じページには、ワークスペースごとのチャットとカードへのコメントが並べて説明されています。依頼の背景がチャットに散らばると、チケットには結論だけが残り、なぜそうしたのかが追えなくなります。
料金の考え方も判断の材料になります。機能で絞らず、区切るのは人数とボードの数だけという方針を採っている料金のページでは、ガントチャートもカスタムフィールドも無料のプランに含まれると明示されています。チケットに独自の欄を追加できるかどうかが有料の条件になっている道具もあるので、ここは比べる価値があります。
候補を横に並べたい場合は比較の一覧のページに、主要なプロジェクト管理ツールの無料枠と、工程表がどのプランから使えるかが表で整理されています。いま Trello を使っていて工程表だけが足りない状況ならTrelloとの比較のページに、無料枠のボード数の数え方と、タイムラインが有料からになる点が並べて書かれています。Atlassianの製品をまとめて使っている利点も、同じページで認めた形で挙げられています。
30人以上で使っているチームはBacklogとの比較のページが参考になります。組織単位の定額制と1人あたり課金の分かれ目、ガントチャートが含まれるプランの条件、2027年1月に予定されているプラン改定までが並べて書かれているので、自分の人数を当てはめて読めます。仕様書や議事録も同じ場所にまとめたい場合はNotionとの比較のページに、設計の自由度と最初から揃っていることの違いが整理されています。
移す場合の条件はTrelloからの移行のページに、何が移って何が移らないのかが項目ごとに示されています。自動で取り込めるのは Trello からだけで、他の道具からは手作業になる点も、同じページに書かれています。無料の範囲でどこまで確かめられるかはよくある質問のページにも整理されています。
最後に順番だけ繰り返します。完了の条件を先に書く、1枚を3日で終わる大きさに揃える、タイトルに対象と動作を入れる、そのあとで欄を埋める。道具を替える判断は、この4つを試したあとです。書き方が決まっていないチームが道具を替えると、同じ問題が新しい画面で再現します。
Q1. チケットのタイトルには何を書けばよいですか？
どこの何をどうするかを並べます。「請求書の一覧で、締切の並べ替えが効かないのを直す」のように、対象と動作を両方入れてください。名詞だけで終わるタイトルは、一覧で開かないと判断できないので機能しません。背景は本文の欄に書き、分類の欄で表現できるものをタイトルに重ねて書かないでください。二重管理になります。
Q2. 1枚のチケットはどのくらいの大きさにすればよいですか？
半日から3日で終わる大きさが目安です。判定の仕方は、進捗を聞かれたときに割合で答えるしかないものは大きすぎる、というものです。終わったか終わっていないかで答えられる大きさまで割ってください。逆に、担当者以外の誰も関心を持たないものは、チケットにせず1枚の中のチェックリストに入れます。
Q3. サブタスクと別のチケットは、どう使い分けますか？
他人に影響するかどうかで分けます。設計が終わらないと実装に入れないような前後関係があるなら、独立した1枚にして関係を結びます。担当者が自分の都合で分けた手順は、1枚の中のチェックリストにしてください。階層は3段までにとどめ、上と下の両方に期限を入れないようにします。必ず食い違います。
Q4. 無料のプランだけでチケット管理を回せますか？
人数と、確かめたい機能の両方を見てください。Jiraの料金ページでは無料のプランが最大10ユーザーまでで、ボードもタイムラインもレポートも含まれると案内されています（2026年9月27日時点）。一方で、無料では工程表が使えない道具もあります。判断したい機能が有料プランからしか使えないなら、そこは比べる前に確認しておくべき点です。