スクラムチームでロールごとのベロシティを可視化してレトロの質を上げた話
はじめに
アジャイル実践者のみなさま、今スプリントのベロシティはいかがでしょうか？？
こんにちは、コインチェック株式会社（以下、コインチェック）販売所事業部のスクラムチームでプロダクトオーナー（以下PO）を担当している大橋です。今回は、コインチェックのスクラムチームで行った具体的なベロシティ改善の取り組みについてご紹介します。
以下のような方々に役立つ内容となっていますので、興味のある方はぜひ読み進めてみてください。
スクラム開発による具体的なメリットを知りたい方
スクラムチームのベロシティを安定させたい方
スクラムチームにおけるベロシティの重要性
ベロシティとは
まずは、「ベロシティとは何か？」という基本から説明させていただきます。
ベロシティは、スクラム開発において頻繁に用いられる指標の一つです。具体的には、スクラムチームが一つのスプリント（通常は2週間などの一定期間）で完了した作業量を数値化したものです。この作業量は一般的にストーリーポイント（以下、SP）という相対見積もりによって算出された値で表されます。SPはユーザーストーリーやタスクに割り当てられます。
なお、作業量の数値化の基準がチームごとに異なるため、他のチームやプロジェクトのベロシティと直接比較をしてはいけません。
なぜベロシティが重要か
ベロシティが重要な理由は大きく2つあります。
作業量の予測
「いつ完成するのか？」といった重要な質問に答えるために、自分たちが一定期間でどの程度の作業をこなせるかを把握することができます。
チームの状態把握
チームが普段どれだけの価値を顧客に提供しているかを理解することができます。また、何か手順を変える場合、その変更が顧客に提供される価値にどのように影響するかも把握することが可能です。
参考: エッセンシャルスクラム
ベロシティは速い方がいい？
ベロシティは速ければいいというものではありません。
だからお前のチームはスクラム導入で満足して、いつまでたっても生産性が上がらないんだよ にもあるように、ベロシティを安定させ、計画通りに進められる状態になっていくことがスクラム開発を行うメリットです。
コインチェックのスクラムチームのベロシティの話
所属するスクラムチームについて
私が所属している販売所事業推進グループのスクラムチーム（以下販売所チーム）は、バックエンドエンジニア・モバイルエンジニア・デザイナー・POと様々なロールのプロフェッショナルが揃っています。販売所チームは、モバイルアプリの機能改善を行うために、2023年9月に結成されました。
チーム内にはバックエンド開発、モバイルアプリ開発、デザインと多数の作業が存在しますが、すべて同じ基準でストーリーポイントを計測し、チーム全体で1つのJIRA（タスク管理サービス）を利用しています。
ベロシティがレトロスペクティブで機能しない
とある2024年の春のスプリントにおいて、チームのベロシティが180SP程度であるのに対し、240SPがコミットメントとしてスプリントバックログに入っていることがありました。そして、実際にそのスプリントで消化したSPは180程度でした。
レトロスペクティブ（スプリントごとの振り返り）において、このベロシティとコミットメントのずれに関する課題を話し合ったのですが、自分を含め、すぐに原因がわかるメンバーはいませんでした。「なぜベロシティが重要か」で述べた通り、ベロシティはチームの状態を把握するための重要な指標です。しかし、ベロシティを計測してはいたものの、状態の検査という面ではうまく機能していなかったのです。
コインチェックではベロシティの安定性を確認する際に、過去のベロシティの標準偏差を利用しています。このスプリントの前までは、平均ベロシティ178.60SPに対して、標準偏差が16.35と、自分が経験してきたチームの中では安定しているように見えていました。そのため、ベロシティについて深く話し合う機会はありませんでした。チーム内の大きな課題として表出したのは、これが初めてでした。
プランニングでベロシティが活用されていない
この課題を改善しようと、販売所チームにおけるベロシティの利用状況を確認しました。
販売所チームでは、スプリントプランニング（次のスプリントで何をするか決める会議）をバックエンドとモバイルに分けて行っていました。作業内容が大きく異なるため、チームで話し合い、そのように決めていました。
POである私は、両方のスプリントプランニングに参加していましたが、どちらも各個人と相談しながら個人の判断でコミットメントを決めており、ベロシティをあまり参照していないことに気付きました。プランニングを分けて行っているにも関わらず、参照するベロシティは全体のものだけだったのです。
ロール毎に数値を出してみる
プランニングの正確性を上げるために、バックエンドとモバイルそれぞれの過去のベロシティを確認してみました。すると、下の画像のように、それぞれのベロシティには大きなばらつきがあることがわかりました。全体で見たときに標準偏差が小さく安定して見えていたのは、偶然どちらかのベロシティが低いときにもう片方のベロシティが高くなっていたからでした。
本来、チーム全体のベロシティを安定させるために、ロールごとの作業をサポートし合う形はスクラム開発で推奨されています。しかし、販売所チームではプランニングを別々に行っており、これは意図したものではありませんでした。
ロール毎でベロシティに向き合う
この事実をチームメンバーに共有し、次のレトロスペクティブからは全体のベロシティ・バックエンドのベロシティ・モバイルのベロシティの3つを検査するようにし始めました。このような形にしたことで、チームにおいて以下のようなプラスの変化がありました。
ベロシティが変化した原因に気づきやすくなり、レトロで具体的な話が多くなった
プランニングで個人の消化SPからロール毎のベロシティを参照するようになり、コミットメントの達成率が上がった
「可視化したことによって意識しやすくなった」とチームメンバーに評価していただけました。まだベロシティの安定を目指している段階ですが、ベロシティがしっかりと機能するようになりました。
終わりに
課題の解像度を上げる
今回は、コインチェックにおける具体的な事例がみなさまのチームにおいてどこか一部でも参考になればと思いこの記事を書かせていただきました。
コインチェックのスクラムマスター勉強会ではスクラムチームに存在する課題に対して、その課題に対してまず具体化しようということがよく話されます。「解像度を上げる」という書籍においても深さ・広さ・構造・時間のうち、
基本的には深さが足りない
ということが書かれています。
書籍で取り上げられているプロダクト作りにおける課題に限らず、組織的な問題においてもまずは課題を分解し、深く知ることが改善の近道になるかもしれません。
宣伝
そのほかにもコインチェックではアジャイル開発に関する取り組みを発信しております。是非ご覧ください！