Backlog課題（Issue）の使い分け｜抜け漏れが減る整理法

Backlogが回らない原因の多くは、課題（Issue）の粒度が揃っていないことです。

大きすぎる課題が増えると、作業中が溜まり、進捗が信用されなくなります。

逆に細かすぎても、入力が重くなって更新が止まります。

このページでは、Backlogの課題（Issue）を抜け漏れが減る形で整理する使い分けの型をまとめます。

結論：課題は「1〜3日で終わる単位」＋「完了条件」が最強

課題運用を安定させる要点は、次の2つだけです。

• 粒度：1〜3日で終わる単位に揃える
• 完了条件：どこまでやったら終わりかを一行で書く

ポイント

課題が「作業の箱」になれば運用は回ります。課題が「メモ」や「雑談」になると回らなくなります。

課題種別（Issueタイプ）の使い分け：増やさず、役割で分ける

課題種別は増やすほど整理できた気になりますが、入力が面倒になって止まります。

まずは、役割が違うものだけを分けます。

種別	役割	使う場面
タスク	通常の作業	やることの大半はここ
確認	レビュー・承認・返答待ち	止まりを見える化したいとき
不具合（任意）	問題対応	障害や不具合が頻発する場合のみ

この3つで大半は回ります。まずはここから始めるのが安全です。

粒度の揃え方：大きい課題は「成果物」で割る

課題が大きいと、いつ終わるか分からず、作業中が溜まります。

割るときは、作業工程ではなく「成果物」で割ると安定します。

割り方の例

• 資料を作る → 初稿作成／レビュー反映／最終版提出
• 記事を作る → 構成案／本文初稿／推敲・体裁調整
• 設定する → 現状確認／設定変更／動作確認・記録

成果物で割ると、完了条件も自然に書きやすくなります。

親子課題の使い方：親は「目的」、子は「実行」

課題が増えてくると、全体像が見えにくくなります。

そのときは親子で整理しますが、親子の役割を間違えると逆に重くなります。

役割	書くこと	注意点
親課題	目的／ゴール／全体の完了条件	親を細かく更新しない
子課題	1〜3日で終わる実行タスク	子に担当・期限・完了条件を置く

ポイント

親課題を「作業一覧」にしない方が軽く回ります。親は目的、子が実行です。

状態（ステータス）の使い分け：止まりを見つけるために使う

状態は、進捗を正確に見せるためではなく、止まりを見つけるために使うと運用が安定します。

おすすめの最小セット

• 未着手：着手条件が揃っている
• 作業中：今進めている（同時進行を増やしすぎない）
• 確認待ち：誰の確認で止まっているかが明確
• 完了：完了条件を満たした

「確認待ち」があるだけで、止まりが見え、催促が具体的になります。

完了条件の置き方：課題本文の先頭に一行で書く

完了条件は、長文にすると読まれません。

課題本文の先頭に、一行で置くと運用が軽くなります。

悪い例	良い例
対応する	修正案を2パターン作成し、レビュー依頼を出したら完了
調べる	選択肢3つを比較し、結論と理由を1枚にまとめたら完了
設定する	設定変更後に動作確認し、結果を課題に記録したら完了

完了条件があると、確認も差し戻しも減ります。

週次の棚卸しで、課題運用は必ず回復する

課題が溜まっても、週1回の棚卸しがあると回復できます。

課題の使い分けは、週次で整える前提で作ると続きます。

棚卸し（最小）

• 放置課題を捨てる／分ける／期限を決める
• 作業中を減らす（同時進行を増やさない）
• 完了条件が曖昧な課題を修正する

まとめ

Backlogの課題（Issue）は、1〜3日で終わる粒度と完了条件が揃うほど抜け漏れが減ります。種別は増やさず役割で分け、親は目的・子は実行、状態は止まりを見つけるために使うと、運用が軽く続きます。