はじめに
株式会社トラストバンクでフロントエンドエンジニアをしている飯島(@iijima0226)です。
この記事は トラストバンクAdvent Calender 2024 の10日目の記事です。
今期から開発部内でアジャイル開発を取り入れることになり、スクラムでの開発を実践することになりました。
そこで、私がチームのスクラムマスターに任命されました。
今回はチームが発足してからの約9ヶ月間、スクラムマスターとしてスクラムを推進していく中でチームで出た疑問や課題を少しまとめてみようと思います。
※スクラムについての細かいイベントや手法、用語については解説しません。
長期間の開発が必要なものにスクラムは合わないんじゃない?
スクラムはスプリントごとに価値を生み出すので、スプリントごとに必ずリリースなければいけないというイメージがチーム内でありました。
しかし、スプリント毎に必ずリリースする必要はないです。
スプリントで生み出した価値をどの単位でユーザーに届けるかはPOの判断で問題ありません。
いくつかの価値をまとめてリリースしても良いですし、小出しにリリースしても大丈夫です。
ただ、気をつけなければいけない点として、リリースが遅れればその分だけユーザーに価値を提供できる時間が遅くなるということです。
開発に3ヶ月かけてリリースする場合、リリースされるまでの3ヶ月間チームはユーザーに対して何の価値も提供できていないことに注意してください。
「本当にまとめてリリースしないと価値がないのか?」は常に考える必要があります。
プロジェクトの実装にどれくらい時間がかかるか知りたいから工数を出して欲しい
スクラムでは一般的な時間単位での工数は出しません。
代わりにストーリーポイントとベロシティを活用します。
ストーリーポイント(SP)
基準のアイテムを設定し、そのアイテムよりも作業量や複雑性などが大きいか小さいかで値を設定する相対的な見積もり。
ベロシティ
ストーリポイントを直近の値で平均化したもの。
例えば1スプリント1週間でチームのベロシティは10だと仮定します。
下記の5つのアイテムがどれくらいにで終わるのかを考えてみます。
アイテム | SP |
---|---|
アイテムA | 2 |
アイテムB | 3 |
アイテムC | 1 |
アイテムD | 5 |
アイテムE | 8 |
アイテムの合計SPは19なのでおよそ2スプリントで実装することが可能です。
時間での見積もりとストーリーポイントでの見積もりの違いについて
正直なところ私はこの記事を書くまで見積もりについて勘違いをしていました。
「プロダクトに対するドメイン知識やメンバーのレベルが上がってもベロシティは増えない」と考えていました。
なぜなら「プロダクトに対するドメイン知識やメンバーのレベルが上がることで同じようなアイテムでもストーリーポイントが変わる」と考えていたからです。
具体的に例を挙げてみます。
先ほど例で挙げたアイテムBはSP3でストーリーポイントを設定しています。
ここでアイテムBと似たような改修内容のアイテムFができたとします。
この場合、今までは「アイテムBでの経験があるのでアイテムFはそれよりも早く対応でき、かつ不確実性も少ないためアイテムFにはSP2をつける」というようにしていました。
しかしこれはストーリポイントを時間に変換していることと同じで、アイテムの大きさを相対的に比較できていない状態でした。
この部分はずっと引っかかっており、チームメンバーに対してストーリーポイントと時間での見積もりの違いを聞かれた時に明確に説明できない状況が続いていました。
本来は「アイテムの大きさは変わらず消化できるストーリーポイントが増えていく」が正しい状況のようです。
この部分に関しては下記の記事が大変わかりやすかったので参考にしていただけますと幸いです。
タスクの切り方について
私のチームではPOがやりたいことをアイテムとして作成し、そのアイテムに対して必要なタスクを開発者が作っていきます。
ここでよくある間違いがやることベースでタスクを切ってしまうことです。
商品管理機能を実装する例で考えてみます。
■よくない例
- 基本設計:SP5
- 詳細設計:SP5
- 実装:SP8
- 結合試験:SP5
- QA試験:SP13
■良い例
- 管理画面上から商品を登録できるようにする:SP5
- 管理画面上から登録した商品を編集できるようにする:SP3
- 管理画面上から登録した商品を削除できるようにする:SP3
- 管理画面上から商品の公開・非公開を制御できるようにする:SP5
よくない例では開発者がやることベースでタスクが切られています。
逆に良い例ではユーザーに提供できる価値単位でタスクが切られています。
※本来はこのような単位でアイテムを切るべきですが。
スクラムではスプリント毎に価値を生み出します。
ベロシティが10のチームで上記のタスクを対応した場合、よくない例では最初のスプリントでは基本設計と詳細設計までしか終わらず実際にユーザーに提供できる価値を生み出すことができません。
一方で良い例では「商品を登録できるようにする」と「登録した商品を編集できるようにする」という価値が生み出せそうです。
スプリントレビューでは動くデモを用意してステークホルダーに商品登録・編集を実際に行なってもらいフィードバックを受けることができるしょう。
※実際には「登録した商品を削除できるようにする」「管理画面上で商品の公開・非公開を制御できるようにする」まで終わっていないとリリースできないと判断されるかもしれませんが、「長期間の開発が必要なものにスクラムは合わないんじゃない?」でも記述した通り、リリースの判断はPOが決めればよく、スプリントでは価値を生み出せている状態になります。
終わりに
今回はスクラムマスターとして活動してみて実際にチーム内で出た疑問や課題を少しまとめてみました。
ここで記載した内容以外にも本当にたくさんの疑問や課題がありその度に試行錯誤する日々です。
今はスクラムマスターとしてチーム内のことしか見えていないので、今後チーム外にも目を向けてチームとして活動しやすい環境を整えることを課題に精進していきたいと思います。
また機会があればここでは書けなかった疑問や課題を書いてみようと思います。
トラストバンクでは、一緒に働く仲間を募集中です。