アジャイル開発（スクラム開発）で要件はどこに書く？

# アジャイル開発におけるユーザーストーリーは価値を表現する
私が経験した、アジャイル開発のチームでは、Epic/Feature/UserStory/Taskの4つのカテゴリのチケットを使って開発を進めていました。その中でも、ユーザーストーリーは、開発者がユーザーの視点で価値を表現するためのものでした。

しかし、アジャイル開発（実際にはスクラム開発）を進める過程で次の現象が見られました。
- ユーザーストーリーの一覧が要件の一覧になっている
- ユーザーストーリーの一覧が機能の一覧になっている
- ユーザーストーリーの一覧がタスクの一覧になっている

この書き方はうまく機能するのでしょうか？答えはNoだと思います。私は要件はEpic/Feature/UserStory/Taskのどこにでも書くことができると考えています。それぞれのチケットには異なる役割があり、誰に見てもらいたい要件かによって書く場所が変わるのが望ましいです。

また、機能やタスクは、その名の通り、それぞれFeatureやTaskに記載することが望ましいと考えています。

※この投稿は私の主観を多く含みます。ご了承ください。アジャイル開発（スクラム開発）の運営は、組織やチームによって異なるため、どのやり方が正しいとは言えません。

# ユーザーストーリーってなんだっけ

スクラム開発におけるユーザーストーリーは、製品の機能や要件をユーザーの視点で記述した短い文書です。ユーザーストーリーは、チームがユーザーのニーズを理解し、そのニーズを満たすために何を作るべきかを明確にするのに役立ちます。

ユーザーストーリーは通常、以下の形式で書かれます：
```
As a [ユーザーの種類], I want to [機能] so that [目的・理由].
```

## ユーザーストーリーの具体的な事例

### 事例 1: シンプルなタスク管理アプリ

**ユーザーストーリー:**
```
As a user, I want to add new tasks to my task list so that I can keep track of what I need to do.
```

**解説:**
- **ユーザーの種類:** user
- **機能:** add new tasks to my task list
- **目的・理由:** keep track of what I need to do

このユーザーストーリーは、ユーザーがタスク管理アプリに新しいタスクを追加できる機能を示しています。

### 事例 2: オンラインショッピングサイト

**ユーザーストーリー:**
```
As a customer, I want to search for products by keyword so that I can find items I'm interested in purchasing.
```

**解説:**
- **ユーザーの種類:** customer
- **機能:** search for products by keyword
- **目的・理由:** find items I'm interested in purchasing

このユーザーストーリーは、ユーザーがオンラインショッピングサイトでキーワードを使って商品を検索できる機能を示しています。

### 事例 3: ソーシャルメディアアプリ

**ユーザーストーリー:**
```
As a user, I want to receive notifications when someone likes my post so that I can stay engaged with my content.
```

**解説:**
- **ユーザーの種類:** user
- **機能:** receive notifications when someone likes my post
- **目的・理由:** stay engaged with my content

このユーザーストーリーは、ユーザーが自分の投稿に対して「いいね」がついたときに通知を受け取れる機能を示しています。

## ユーザーストーリーの重要性

1. **ユーザー視点の理解:** ユーザーストーリーは、開発チームがユーザーの視点から要件を理解するのを助けます。
2. **コミュニケーション:** ユーザーストーリーは、開発チームとステークホルダー（関係者）とのコミュニケーションを促進します。
3. **優先順位付け:** ユーザーストーリーを使うことで、どの機能が最も重要かを優先順位付けしやすくなります。
4. **小さな単位での開発:** ユーザーストーリーは、機能を小さな単位に分割することで、段階的に開発とリリースを行うのに役立ちます。

ユーザーストーリーは、スクラム開発の中心的な要素であり、ユーザーのニーズを満たすための効果的なツールです。

# 要件はどこに書くべきか

要件はEpic、Feature、User Story、Taskのどこにでも書くことができます。それぞれのチケットには異なる役割があり、誰に見てもらいたい要件かによって書く場所が変わるのが望ましいです。

## EpicとFeature

EpicやFeatureは通常、ステークホルダー（上長、営業、その他の関係者）の目に触れることが多いです。そのため、わかりやすく、納得しやすい言葉や粒度で記載されることが重要です。EpicやFeatureに要件を書いておくことで、ステークホルダーに対して開発の進捗や方向性を明示できます。

### 例:
```
As a project manager, I want to see a detailed project timeline in the dashboard so that I can easily track the progress and make informed decisions.
```

## User Story

User Storyは、開発者がユーザーの視点から価値を表現するためのものです。User Storyに要件を書いておくことで、開発者は何を実現すべきか、なぜそれを実現すべきか、実現した結果どんな作用や副作用があるかを理解できます。このため、User Storyはできるだけ簡潔に、かつユーザーの視点で価値を表現するように書くべきです。

### 例:
```
As a user, I want to receive notifications when someone comments on my post so that I can stay engaged in the conversation.
```

## Task

Taskにも要件は必要です。各Taskには、その作業を進める上での注意事項や具体的な指示が含まれます。例えば、「〇〇機能と××機能との整合性を取る」や、「過去のスプリントレビューでの〇〇さんの××という指摘を解決する」などです。

### 例:
```
As a developer, I need to ensure the new login feature is compatible with our existing authentication system, following the guidelines provided in the previous Sprint review.
```

各チケットの役割とその記載内容を明確にすることで、プロジェクト全体の透明性と理解が向上し、スムーズな開発が進行します。

# 機能はどこに書くべきか

ずばり、Featureです。Featureは極力簡潔に、かつ、ユーザーストーリーの一覧を見ただけで、どのような機能があるのかがわかるように書くべきです。これは、機能の一覧化や進捗管理が上長から求められることが多いためです。

私の経験上、上長はアジャイル開発への理解の深さに関わらず、「〇〇機能ってどうなったんだっけ？」と気軽に聞いてくることがありました。その時に、Featureの一覧を見せることで、上長に安心感を与えることができます。また、Featureに紐づくUser StoryやTaskの一覧を使って状況を示すことが可能であり、上長の安心材料になります。さらに、User StoryやTaskが明確でないFeatureは、当分先のスプリントで実現することも同時に示すことができます。

### 例:
```
As a product manager, I want to list all new features in a concise manner so that stakeholders can easily track the progress and understand what functionalities are being developed.
```

# タスクはどこに書くべきか

こちらも自明ですね。User Storyの下です。すべてのタスクが何らかのUser Storyに紐づいているはずです。タスクの一覧は、User Storyの実現に向けての具体的な作業を示すものです。タスクの一覧を見ることで、User Storyの実現に向けての進捗がわかります。また、タスクの一覧を見ることで、User Storyの実現に向けての具体的な作業が明確になります。

これにより、開発者は自分が何をすべきかを明確に理解することができます。

### 例:
```
As a developer, I want to list all tasks under their respective User Stories so that I can track the progress of each story and understand what specific actions need to be taken.
```

タスクをUser Storyの下に明確に記載することで、チーム全体が現在の進捗を理解しやすくなり、各メンバーが具体的な作業に集中できるようになります。