【アジャイル体験記 #1】スプリントバックログの捉え方？ ~初学者が感じた違和感~

>この記事は、[TDCソフト株式会社 Advent Calendar 2023](https://qiita.com/advent-calendar/2023/tdc) 6日目の記事です。

## はじめに
この記事は初学者のアウトプット目的で作成しています。
そのため、内容も**初心者向け**となっております。
※筆者は**IT経歴半年ほど**のペーペーです。

# 経緯・内容
アジャイル開発でスプリントを重ねていくと以下の疑問を抱くようになりました！
<table>
  <thead>
    <tr>
      <th>目次</th> <th>バックログの担当制って必要？？</th>
    </tr>
  </thead>
</table>

本記事ではそちらに対して「スクラムガイド」を振り返り
個人的な思想を交えてまとめていきます。

https://scrumguide-ja.kdmsnr.com/

:::note info
冒頭で初学者向けとは記載しましたが
有識者の方々にも見て頂き自分にはない観点など、発見していただけると嬉しく思います。
:::

_______

## 1. スプリントバックログとプロダクトバックログ

初めに両者のスクラムガイドでの定義を見てみましょう。
>**プロダクトバックログ**
<cd><cd>
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの一覧である。これは、スクラムチームが行う作業の**唯一の情報源**である。
1スプリント内でスクラムチームが完成できるプロダクトバックログアイテムは、スプリントプランニングのときには選択の準備ができている。スクラムチームは通常、リファインメントの活動を通じて、選択に必要な透明性を獲得する。プロダクトバックログアイテムがより小さく詳細になるように、分割および定義をする活動である。これは、説明・並び順・サイズなどの詳細を追加するための継続的な活動である。多くの場合、属性は作業領域によって異なる。
作業を行う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を支援することもできる。


>**スプリントバックログ**
<cd><cd>
スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実行可能な計画（どのように）で構成される。
スプリントバックログは、**開発者による、開発者のための計画**である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで行う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
>>スクラムガイドより引用

両者ともに初学者からすると到底理解できないと思います。
実際私もそうでした！

なので、以下のように簡単に認識していただきたいです。
>プロダクトバックログ　＝　プロダクトオーナーとスクラムチームが一緒に決める作業
スプリントバックログ　＝　スクラムチーム側で決める作業

※本質から少し離れた認識になりますので、知識が追い付いてきたら再度スクラムガイドを見直してみてください！

### -Devチームでの作業分担-
スプリント内で行うバックログが決まった段階で、実際にDevチームでタスク割り振りを行っていきます。
その際に一般的には一人一つバックログを担当することが多いのではないでしょうか？
>スクラムチームの人数は10人以下が良いとされています。
（スクラムガイドより）

チーム人数とバックログの数にもよりますが上記の定義からは、担当制になってくると個人的には思っています。
___

### -疑問点-
ここまで長々と概念について記載しましたが、ここからが本題です。

上記のような状態の場合、Devチーム内で少なからず誰かが下記のように意識してしまうのではないでしょうか？？

:::note warn
スプリントゴールの達成　＜　バックログを終わらせる
:::

これは実際に筆者も作業進捗が遅れて焦ってしまうなどで、スプリント後半になるに連れて意識がそちらに集中してしまったことがあります。
筆者のように知識・経験で劣る状況や、触ったことのない改修など同じような状況に陥ってしまうケースは容易に想像できるのではないでしょうか？

こうなると、

:::note warn
バックログの担当制は広い意味で本当にアジャイルにとって良いのだろうか？
:::
と思いました。
___

### メリット・デメリット
ここで状況を把握するためにそれぞれの状況を筆者なりにまとめていきたいと思います。

初めに、良い場合です。

:::note info
・作業効率があがる
→レビュー時間確保、資料作成時間確保などチーム内の心的安全性が増加。
・作業者の裁量権である程度自由に動ける
→バックログの細部までの認識合わせや話し合いの時間を削減できる。
:::

悪い場合

:::note alert
・チームとしての立ち回りが難しい
→分担による加速もそうですが、作業内容によってはストップしてしまうものも。。作業進捗はこまめに。
:::

上記のように記載いたしましたが、これは発生しうる一例でありチームによってやり方はそれぞれで、その分良い点・悪い点が出てくると思います。

ここで伝えたいことは、
スクラムチームは個人の集まりではあるがそれぞれが独立しているわけではない。
ということです。

詳しくは次の見出しで記載します。

___

### 伝えたいこと

>スクラムチームは個人の集まりではあるがそれぞれが独立しているわけではない。

Devメンバの作業内容はそれぞれ異なります。スクラムマスターも同様です。
しかし、**目指すべき場所は同じはず**です。

↑これが筆者の違和感の原因である思想

>担当制は必要？？

:::note alert
違います。必要でも不必要でもない。
:::

そもそもアジャイル開発を行うにあたって知識・技術のばらつきはあって当然。それもアジャイルの良さである。

>本当に注視するべきはチームとしての在り方であるのではないでしょうか？

それぞれのやり方で、メリット・デメリットが存在すると思います。

>スクラムチームで活動する以上、コミュニケーションは欠かさなければ統率は生まれ自然とチームとしての立ち回りが生まれてくるのではないでしょうか？

今回の場合であれば、バックログ着手前にそれぞれの作業や内容の認識合わせを事前に行うことができれば悪い点はおそらく解消されます。

スクラムを語るうえでよく出てくる「**透明性**」について改めて考えてみると今回の疑問点が何となく解決できるのではないでしょうか？

## 最後に

今回はバックログの分担を透明性の観点から再認識してみようと思い記事を発行しました。
具体例をあげるとキリがなく、詳細にしすぎても読むのが億劫になってしまうので最低限のことを筆者なりに記載しました。

有識者の方にも。改めて自分のチームについて再認識していただけるきっかけになれば嬉しいです。

しかし、この記事の根本にはスクラムイベントの存在なしには語れません。
そちらについても次回書いていこうと思います。