アジャイルの作業単位(バックログ / エピック / フィーチャー / ストーリー / タスク)

全体像#

大きい順に並べると次の階層になる。バックログだけはそれらを入れておく箱で、単位ではない。

単位	ひとことで	期間の目安	誰の言葉で書くか
エピック	大きなテーマ・目的	数スプリント〜数か月	ビジネス
フィーチャー	利用者に届く機能のまとまり	1〜数スプリント	プロダクト
ストーリー	利用者にとっての価値 1 つ	1 スプリント以内	利用者
タスク	ストーリーを実現する作業	数時間〜1 日	開発者

用語の粒度はチームやツール(Jira、Azure DevOps など)で揺れる。フィーチャーを置かずにエピック → ストーリーの 2 段で運用するチームも多い。

バックログ#

やりたいこと・やるべきことを優先順位つきで並べたリスト。

プロダクトバックログ: プロダクト全体の「次にやる候補」。プロダクトオーナーが優先順位を決める。
スプリントバックログ: そのスプリントでやると決めたストーリーと、それを分解したタスク。開発チームが持つ。

上ほど詳細で見積もり済み、下ほど粗くてよい。全部を最初から細かく書かないのがポイント。

エピック#

1 スプリントでは終わらない大きな塊。「会員機能を作る」「決済を刷新する」くらいの粒度で、そのままでは着手できないので、フィーチャーやストーリーに割ってから扱う。

フィーチャー#

利用者から見て意味のある機能のまとまり。「ログインできる」「パスワードを再設定できる」など。エピックとストーリーの中間で、リリース計画やロードマップの単位として使われることが多い。

ストーリー(ユーザーストーリー)#

利用者にとっての価値を 1 つだけ書いたもの。よく使われる型は次のとおり。

〈利用者〉として、〈やりたいこと〉をしたい。なぜなら〈理由・価値〉だから。

例: 「会員として、パスワードを忘れてもメールで再設定したい。サポートに問い合わせずにログインし直せるから。」

良いストーリーの目安は INVEST(Independent / Negotiable / Valuable / Estimable / Small / Testable)。ストーリーには受け入れ条件(Acceptance Criteria)を書いておき、完了はそれで判断する。見積もりはストーリーポイントで行うのが一般的。

タスク#

ストーリーを実現するための具体的な作業。「再設定 API を作る」「メールテンプレートを書く」「E2E テストを追加する」など。開発者の言葉で書き、時間で見積もってよい。利用者価値は持たないので、タスク単体ではリリースしない。

関係を一行で#

バックログ(箱)に、エピック ⊃ フィーチャー ⊃ ストーリー ⊃ タスクが入っている。スプリントで約束するのはストーリー単位、日々の作業管理はタスク単位。

更新履歴#

2026-10-07: 初版
2026-10-09: 関連に LeSS とエレベーターピッチを追加