Epic・Feature・ユーザーストーリーの違いをわかりやすく解説

ほとんどのアジャイルチームはその言葉を知っています。しかし、実際の意味について全員が合意できているチームは少数です。Epic・Feature・ユーザーストーリーの違いは、プロダクトおよびプロジェクト管理の分野で最もよく検索される質問のひとつです。チームは階層を混同し、計画できないほど曖昧なバックログか、逆に細かすぎるバックログを作りがちだからです。

階層を正しく理解することは、名前付けの練習ではありません。6か月にわたる戦略的な取り組みを、月曜日の朝に開発者が取り上げる2日間のタスクとつなぐための仕組みです。

Epic・Feature・ユーザーストーリーとは何か？

Epic・Feature・ユーザーストーリーは、アジャイル計画で使用される要件階層の3段階です。Epicは複数の Sprint にまたがる大規模な作業のまとまり、FeatureはそのEpicの中で独立した機能を表す出荷可能なスライス、ユーザーストーリーはチームが1 Sprint 以内に届けられる単一の価値単位です。

3つの階層は入れ子になっています。1つのEpicに複数のFeatureが含まれ、各Featureに複数のユーザーストーリーが含まれます。これらが合わさって、健全なProduct Backlogの骨格を形成します。

主要データ

• 要件を明確な階層に分解しているチームは、フラットなバックログを使用しているチームと比べて、スコープ変更による失敗が27%少ないと報告されています（Standish Group CHAOS Report、2023年）。
• State of Agile Reportによると、68%の組織が「バックログ構造の一貫性のなさ」を Sprint ゴール未達成の主な要因として挙げています（Digital.ai、2024年）。
• 受け入れ基準の不明確さが手戻りの主な原因であり、チームの総プロジェクト時間の平均20〜25%のコストを発生させています（PMI Pulse of the Profession、2023年）。

各階層の始まりと終わりを理解することは、計画上の摩擦と Sprint の見積もり超過を減らす最も効果的な方法です。

Epic・Feature・ユーザーストーリーの階層

以下の表は、それぞれの階層が実際にどう機能するかを整理したものです。主な区別要因は、規模だけでなく、スコープ・時間軸・オーナーシップであることに注目してください。

ズームレンズで例えるとわかりやすいです。Epicは広角ショット（目的地はわかるが、すべての曲がり角はわからない）、Featureはルートの各区間、ユーザーストーリーは個々の指示（左折、200メートル直進、ここで駐車）です。

ストーリー自体の構造についての詳細は、ユーザーストーリーと受け入れ基準のガイドを参照してください。

作業をこの階層に分解するメリット

3段階の階層はバックログを整理するだけではありません。実際の調整上の問題を解決します。

あらゆる高度でのロードマップの明確さ。 経営幹部とステークホルダーは、ストーリーの詳細に溺れることなく、Epic レベルの進捗を追跡できます。開発者はすべての四半期の戦略的文脈を知らなくても、ストーリーに集中できます。Featureはその橋渡し役を担います。

予測可能な Sprint 計画。 ストーリーが正しくサイズされていれば、チームはオーバーコミットすることなく Sprint を確実に埋めることができます。Story Pointでの見積もりは、ストーリーが実際に小さく見積もれるサイズになって初めて機能します。

依存関係の可視化。 Featureはしばしば互いに依存しており、その依存関係を Sprint の途中でストーリーレベルで発見するのではなく、Feature レベルで表面化させることで、直前のブロッカーを防ぎます。

より良いバックログリファインメント。 チームがスコープと実装を同時に議論しなくてよい場合、リファインメントセッションはより速く進みます。EpicとFeatureが「何を」を定義するので、リファインメントは「どのように」に集中できます。

この階層はスコープクリープも可視化します。新しいリクエストが既存のEpicに収まらない場合、それ独自のEpicになり、静かなバックログの肥大化ではなく、意図的な優先順位付けの会話を促します。

よくある失敗

定義を理解しているチームでも、予測可能な落とし穴に陥ります。

大きすぎるストーリー。 最もよくある失敗です。ストーリーが数日以上かかる場合や、複数の人が独立して担当する必要がある場合、それはストーリーのふりをしたFeatureです。目安：ユーザーの便益を説明する節に「そして」が含まれるストーリーは、おそらく2つのストーリーです。

閉じないEpic。 無期限に開いたままのEpicはゴミ捨て場になります。計画単位としての意味を失います。Epicには明確なDefinition of Doneが必要です。つまり、戦略的な機能をまとめて提供する出荷済みFeatureのセットです。

受け入れ基準の欠如。 受け入れ基準のないユーザーストーリーは、コミットメントではなく願望です。チームはテストできず、プロダクトはサインオフできません。すべてのストーリーには、価値が届けられたことを確認できる基準が少なくとも1つ必要です。

テーマと混同されるFeature。 テーマはEpicを戦略エリア（「顧客維持」など）でグループ化するラベルです。Featureは出荷可能なものです。ユーザーにFeatureをリリースできます。テーマはリリースできません。この区別を明確に保つことで、Featureが時間とともにテーマに膨らむのを防ぎます。

Feature レベルをスキップする。 チームによってはEpicを書いて直接ストーリーに分解することがあります。非常に小さなスケールでは機能しますが、四半期計画や依存関係の追跡のための中間構造がない、数百の未グループ化されたストーリーのバックログを作り出します。

EpicをFeatureとストーリーに分解する方法

分解プロセスは再現可能です。B2B SaaS 製品のチェックアウトフロー Epic を例に解説します。

ステップ1：Epicをビジネス成果として記述する

Epicをフィーチャーリストではなく、ゴールとして記述します。良い例：「購入者が営業に連絡せずに購入を完了できるようにする」。悪い例：「チェックアウト画面を構築する」。

ステップ2：主要な機能スライス（Feature）を特定する

「このEpicにはどのような独立した出荷可能な機能が必要か？」と問います。各回答がFeature候補です。チェックアウト Epic の場合：

• ゲストチェックアウト（ログイン不要）
• 保存済み支払い方法
• 注文サマリーと確認
• プロモーションコード入力
• 税金と送料の計算

これらのそれぞれは独立して出荷でき、ユーザーに価値を提供できます。

ステップ3：各FeatureのユーザーストーリーをF書く

「ゲストチェックアウト」のストーリーの例：

• 「ゲストとして、注文確認を受け取るためにメールアドレスを入力できる。」
• 「ゲストとして、アカウントを作成せずに請求先住所を入力できる。」
• 「ゲストとして、注文する前にカートを確認できる。」

Sprint に移す前に、各ストーリーに INVEST 基準を適用します（後述のベストプラクティスを参照）。

ステップ4：すべてのストーリーに受け入れ基準を追加する

各ストーリーには少なくとも1つのテスト可能な基準が必要です。メールアドレス入力ストーリーの例：「有効なメール形式の場合、ユーザーがフィールドを送信すると、システムがそれを保存して確認メッセージを表示する。」

ステップ5：依存関係と価値によってFeatureを順序付ける

すべてのFeatureが同等ではありません。ゲストチェックアウトはプロモーションコードの前提条件であり、プロモーションコードは価格ロジックに依存します。Sprint の順序を確定する前に、Feature レベルで依存関係チェーンをマッピングします。

この5ステップのプロセスはあらゆるドメインに適用できます。チェックアウトの例をオンボーディングフロー、レポートモジュール、またはマーケティングオートメーションシーケンスに置き換えても、ロジックは成立します。

チーム別の例

機能によって同じ階層を使いますが、内容は大きく異なります。

チームに関わらず、すべてのユーザーストーリーは同じ形式に従っています。ユーザーが誰か、何をする必要があるか、そしてなぜか。「なぜ」の節が、タスクを実際の受け入れ基準が付いたストーリーに変えるものです。

ベストプラクティス

ストーリーには INVEST 基準を使用する。 適切に形成されたユーザーストーリーは、Independent（別のストーリーを必要とせずに作業可能）、Negotiable（スコープが固定されていない）、Valuable（実際のユーザーに何かを提供する）、Estimable（チームがサイズを見積もれる）、Small（Sprint に収まる）、Testable（受け入れ基準がある）です。確信が持てないストーリーは Sprint 前にこのチェックリストを通してください。

水平ではなく垂直にスライスする。 水平スライスは技術スタックの1層を提供します（例：「チェックアウトのデータベーススキーマを構築する」）。垂直スライスはすべての層を貫いてユーザーが見える価値を提供します（例：「ゲストが注文確認を見ることができる」）。垂直スライスにより、フィードバックが早く、リリースが早まります。

Feature レベルで WIP 制限を設定する。 Featureを単なる組織バケットではなく、仕掛品として扱うことで、チームが並行して多くのFeatureを開始しすぎるのを防ぎます。Scrum フレームワークは同時並行作業を制限してフローを改善することを推奨しています。

Epicは四半期ごと、Featureは Sprint ごと、ストーリーは毎日レビューする。 計画のリズムはスコープと一致する必要があります。Epicは四半期ロードマップレビューに属します。Featureは Sprint 計画に属します。ストーリーは Daily Stand-up に属します。これらのリズムを混在させることは、計画上のオーバーヘッドのよくある原因です。

Epicをアジャイル手法のゴールに結びつける。 すべての Epic はビジネス目標（OKR またはQuarterlyゴール）に紐付けられるべきです。Epicがゴールに結びつけられない場合、アクティブなロードマップではなくバックログの候補です。

複数のプロダクトラインにまたがってあるいは大規模で作業するチームには、Scaled Agile Framework (SAFe) がEpicの上に2つのレベル（capabilities と portfolio epics）を追加します。また、Scrum のプラクティスがアジャイルの原則にどのように適用されるかという一般的な質問を解消するには、アジャイルと Scrum の比較を参照してください。

よくある質問

Feature とテーマは同じですか？

いいえ。テーマはロードマップのコミュニケーションのために関連するEpicをグループ化するラベルです（例：「信頼性」や「成長」）。デリバリーのコミットメントは付いていません。Featureは1つのEpic内の出荷可能な機能です。テーマはEpicを整理し、Featureはそれを分解します。

1つのEpicにユーザーストーリーはいくつ含まれるべきですか？

決まった数はありませんが、実用的な範囲は Epic 内のすべての Feature にわたって10〜30のストーリーです。10未満の場合、Epic は実際にはFeatureかもしれません。50を超える場合、Epic が広すぎて、それぞれのゴールを持つ2つの別々のEpicに分割すべきかもしれません。

EpicにはStory Pointがありますか？

従来の意味ではありません。Story Pointは個々のユーザーストーリーの相対的な複雑さを見積もるために使用され、不確実性が有用な程度に小さい場所です。Epicはより大きな単位で見積もられます。Tシャツサイズ（S/M/L/XL）または大まかな Sprint 数。Epic レベルで Story Point を使用すると、偽りの精度が生じます。

Featureはいつ2つに分割すべきですか？

分割すべき状況：Featureが2つの異なるユーザージャーニーをカバーしている場合、一方が独立して出荷できて価値を提供できる場合、あるいは一方のデリバリー期間がもう一方より大幅に長い場合。Featureの説明を書いていて「そして」を使って2つの異なる機能をつなげているなら、それは分割のサインです。

ユーザーストーリーはEpicの外に存在できますか？

はい、技術的には。「テクニカルデbt」「スパイク」などの非Feature作業アイテムは、親のEpicなしにストーリーとして書かれることがよくあります。しかし、顧客向けまたはプロダクトレベルの作業については、親のFeatureまたはEpicのない孤立したストーリーは、可視性のコンテキストを持たない孤立したバックログアイテムになります。可能な限り親に紐付けておきましょう。

関連記事

• ユーザーストーリー
• Product Backlog
• バックログリファインメント
• Story Points
• 受け入れ基準
• Definition of Done
• アジャイル手法とは
• アジャイルと Scrum
• Scaled Agile Framework (SAFe)

階層を正しく理解することは、毎 Sprint 成果をもたらす投資です。EpicとFeatureとストーリーの違いについて合意したチームは、計画でスコープを再議論することをやめ、一貫して出荷できるようになります。1つのEpicから始め、上記の5ステップのプロセスで分解し、それ以降のすべての計画会話でのチームの共通の参照として活用してください。