ストーリーポイントを工数ベースで考えてはいけない理由

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/d7af57e3-0459-1631-d638-501f5a1d2ab8.png)

---

## はじめに

本記事はUzabase Advent Calendar 2023の20日目の記事です

https://qiita.com/advent-calendar/2023/uzabase

株式会社Uzabaseに入社して1か月半が経ちました@maaaashiです

https://www.uzabase.com/jp/

Uzabaseでは、アジャイル開発を採用しています

前職でもアジャイル開発をしていましたが、Uzabaseに入社してから理解が深まったことの一つに**ストーリーポイント**についての考え方があります。

本記事ではその気付き・学びについての共有をしたいと思います

## そもそもユーザーストーリーとは

ユーザーストーリーはソフトウェア開発に用いられる手法です。「誰が、何の目的で、何を実現したいか」を示し、内部メンバーなどに向けて、ソフトウェアの機能や利点を伝えることが目的です。

参考）https://products.sint.co.jp/obpm/blog/user-story

例：こういうやつです
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/a0a20216-d884-5adc-b702-73e4bd2e5191.png" width=400/>

## ストーリーポイント

ストーリーポイントとは、タスクの**難易度**・**規模**・**複雑性**を表した指標です。
ストーリーポイントを利用することで、チームの成長を測ったり、タスクの優先順位を考えたりすることができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/1bb31523-ca7e-7b75-0ff9-1487fd5614fb.png)

## 本題）ストーリーポイントを工数ベースで考えてはいけない理由

### 理由1. ベロシティが計測ができなくなる

陸上に例えつつ進めてみようと思います
（分かりやすくなっているかはわかりません。）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/f88523c7-93ef-f2da-56a8-8e2c6d6c2380.png)

試しに**時間ベース**でストーリーポイントを見積もってみましょう

---
例１）
<font color="green">**1時間**</font>走ったら<font color="green">**10km**</font>くらい走れるので、<font color="green">**10km**</font>走ったら<font color="green">**1pt**</font>とします。

しばらく経ち、徐々に体力がついてきて、1時間で<font color="red">**15km**</font>走れるようになったので、
途中で<font color="red">**15km**</font>走ったら<font color="red">**1pt**</font>に変更しました。

この後も**1時間**で走れる量を**1pt**とし、距離の変化は許容していきました。

ベロシティ計測してみたところ、毎週5pt消化で、変化のない結果になりました。

---

徐々に体力がついてきて、1ptをこなすスピードが上がったのにも関わらず、ベロシティは一定となっています。この計測結果は有用なデータといえるでしょうか？

ベロシティとは、チームがこなしたストーリーポイント数であり、開発スピードを表す指標なので、開発スピードが上がったのであれば、ベロシティはどんどん上がっていくはずです。


次に**難易度**・**規模**・**複雑性**を基準にして考えてみます

---
例２）
ひとまず、<font color="green">**10km**</font>で<font color="green">**1pt**</font>としました。
今後これを一つの指標として相対的にポイントを考えていきます
（例えば雨の日は10km走る難易度が上がるので、2ptとしたりします。）

徐々に体力が着いてきて、1日に走れる距離が<font color="red">**15km**</font>に増えました。
今まで１日で10km ⇒ 1ptでしたが、1日で15km ⇒ 1.5ptになりました。

ベロシティを計測してみたところ、体力がある週はポイント消化が多く、体調がすぐれない日はポイント消化が少なかったことがわかりました。

---

**規模**や、**難易度**というものは普遍的なものです。
それに比べて、**工数**というものはチーム成長や、プロジェクト管理方法によって変化するものです。

変化する工数をベースにしてしまうと、普遍的なデータとしてベロシティが計測できなくなってしまうでしょう。

----

### 理由2. スキル・時間感覚の差

チームメンバー間でのスキルの差も、ストーリーポイントを工数ベースで考えるべきではない理由の一つです。

たとえば、経験豊富な開発者は特定のタスクを短時間で完了できるかもしれませんが、新しいメンバーにはもっと時間がかかることがあります。同じストーリーであるのにもかかわらず、見積りを行う人のスキルによって結果が変わるのはプロジェクト管理に支障をきたす可能性があります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/3db324fc-32ff-14fb-32e9-7261ef53d78c.png)



また、時間ベースでストーリーポイントを割り当てると、チーム内での作業負荷の差異が生まれ、プロジェクトの進行に影響を与える可能性があります。


ストーリーポイントは、タスクの難易度や複雑性を表すものであり、個々のメンバーの作業速度を基準にすべきではありません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985550/8c9a7dda-7b85-55b2-9dd4-4dc972b8c944.png)


## まとめ

ストーリーポイントを工数ベースで考えると、<font color="red">**ベロシティの計測が不正確**</font>になるだけでなく、<font color="red">**スキルや、時間感覚の差による見積りの不正確さ**</font>をも引き起こすことがあります。

アジャイル開発では、ストーリーポイントをタスクの<font color="green">**難易度**</font>、<font color="green">**規模**</font>、<font color="green">**複雑性**</font>を反映する指標として用いることが重要です。

これにより、チーム全体としての進捗をより適切に把握し、プロジェクトの成功に向けて効果的に進めることができるでしょう！