＜目次＞
(１) エピック／ユーザーストーリー／フィーチャーの違いや特徴について
(１-１) エピック（Epic）とは？
(１-２) フィーチャー（Feature）とは？
(１-３) ユーザーストーリー（User Story）とは？
(１-４) タスク（Task）とは？
(１-５) （例１）Epic ⇒ Feature ⇒ User Story ⇒ Taskの分解例
(１-６) （例２）Epic ⇒ User Story ⇒ Taskの分解例
(１-７) 補足事項
(１) エピック／ユーザーストーリー／フィーチャーの違いや特徴について
「エピック（Epic）」、「ユーザーストーリー（User Story）」、「フィーチャー（Feature）」はいずれも、アジャイル開発のスクラム方式における、ワークアイテムの単位（≒要件や仕様の粒度）の単位です。
（図１１１）
本記事では、それぞれがどういった単位なのか？をご紹介します。
が、各項目の説明に入る前に、それぞれの関連性について簡単に触れておきます。（図１１１）にあるように「Epic」「Feature」「User Story」「Task」には次のような関係性があるため、以降は最上位である「Epic」から順番にご紹介していきます。
（関係性）
Epic（エピック）
*┗Features（フィーチャー）
**┗User Story（ユーザーストーリー）
***┗Task（タスク）
(１-１) エピック（Epic）とは？
スクラムの作業階層の最上位の単位で、組織が目指す大きなゴールのようなものです。
ユーザーストーリーの内、まだ詳細化されていなかったり、非常に大きな塊だったり、不明瞭な部分があったりで設計・実装に着手できないもの。Epicはより細分化して優先度をつけていきます。
（図１２１）
●Epicの基準（ふわっと）
・「事業活動」と表現するレベルの規模間か？
・単一のスプリントでは実現不可
・詳細が不明瞭な部分がある
・更に分解しないとタスクとして落とせない
●Epicの例
・銀行として、生命保険や健康保険のサービスを提供する事で、ビジネスを拡張したい
・マーケティング部門として、より多くの顧客にアプローチできるような、対話的なアプリを導入したい。
など「顧客満足度向上」や「アプリ提供」といった大きな事業活動単位のイメージです。
(１-２) フィーチャー（Feature）とは？
「Epic」を実現するために必要な「ソフトウェアの機能（≒コンポーネント＝部品）」を「Features」と呼びます。「Features」はリリース可能な単位にします。そのため、「Features」はリリースノートの単位にもなります。
（図１３１）
●Featuresの基準（ふわっと）
・リリース可能な単位になっているか？
→厳密にはユーザーストーリーマッピングの「MVP(Minimum Variable Product)」なのでFeatureとは限らない
・XXX機能と呼ぶような単位になっているか？
・機能一覧の明細程度の単位になっているか？
●Featuresの例
・アプリに「ショッピングカート機能」を追加したい
・アプリを新しいデザインのUI（画面）にする
(１-３) ユーザーストーリー（User Story）とは？
要件を示した短い文章です。エンドユーザー視点で書かれており、よくある形式では「XXXX（役割や状況）として、YYYYYがしたい（機能要件）」のような形で表現されます。
（図１４１）
●User Storyの基準（ふわっと）
・作業ボリュームの見積り（Estimate）ができるか？
・「XXXX（役割=Whoや状況）として、YYYYYがしたい（機能要件=What）」の形で表現できるか？
→もっと言うと5W1Hが明確だと尚よいです。なぜ（Why）やどのような処理で（How）等も定義する
・WBSの大区分程度の単位になっているか？
・受入条件（Acceptance Criteria）が明確になっているか？
→これは非常に大事な点です。「何をもって完了とするか？」を明確にしておく事で、テストケースも作りやすくなります。
●User Storyの例（POSTのRest APIの例）
・POSTを投げたら、該当テーブルを更新してレコードを1件追加する
・POSTパラメーターにキーを１つ指定して、該当レコードを正常に更新できる
・POSTパラメーターを複数指定して、該当レコードが正常に更新できる
・POSTリクエストで複数レコードを更新できる
→これはかなり細かい例ですが、User Storyの粒度は細かくすればする程、見積りし易くなる＆持ち越しが少なくなり管理しやすい。しかし、細かくし過ぎるとエンドユーザー観点での価値が分かり辛くなるため、この辺は臨機応変に。
(１-４) タスク（Task）とは？
ユーザーストーリーを更に分解して、作業単位に落としたものです。
（図１５１）
(１-５) （例１）Epic ⇒ Feature ⇒ User Story ⇒ Taskの分解例
実際に１つのEpicからFeature、User Story、Taskへと分解されていく例をご紹介します。
●Epic
・顧客として、効率的な買い物をしたい
↓
●Features
・顧客として、必要なものを後で思い出せるように、「リマインダーリスト」機能が欲しい
↓
●User Stories
・顧客として、必要なものを後で思い出せるように、「リマインダーリスト」にアイテムを登録できるようにしてほしい
・顧客として、リストを見ながら買い物が出来るように、「リマインダーリスト」を参照できるようにしてほしい
↓
●Tasks
・各商品のページに、「リマインダーリスト」ボタンを追加する
・「リマインダーリスト」にデータを登録するためのDBテーブルを追加する
・「リマインダーリスト」の明細を一覧表示する画面を作成する
・ホーム画面に「リマインダーリストを参照」ボタンを追加する
(１-６) （例２）Epic ⇒ User Story ⇒ Taskの分解例
●Epic（エピック）
私は膝を痛めているので、職場環境を改善して、他者に頼らずに済むようにしたい。
↓
●User Story（ユーザーストーリー）
・私は膝を痛めているで、行く場所はなるべく緩やかなスロープを付けてほしい
・私は膝を痛めているで、行く場所は椅子などの休憩スペースを充実させてほしい。
↓
●Task（タスク）
・新しいスロープを設計
・スロープの設置場所を検討
・スロープの施工の手配
(１-７) 補足
●補足：Doneの定義
・アイテムをDoneにするための条件で「リリースする為にやらねばならない」こと
・「テスト」や「レビュー」といった共通的なタスクは、「Doneの定義」の例である
・Acceptance Criteriaは「実現してほしいこと」で、そのアイテム固有の要件を満たすための達成条件を書く
●補足：Epicをクローズするタイミング
・サービスがなくなったり経営方針が変わったりするまでは、Epicは無くならないはず
●補足：非機能要件などはどうなる？
・非機能でも必ず目的があるはず。セキュリティなら例えば「ブランドイメージの維持」や「利用者の安心安全」など
