こんにちは、YOSHINA分析チームエンジニア兼スクラムマスターの野本です。分析AI「YOSHINA」の開発・運用を担当しているこのチームでは、生産性を維持・向上するために日々さまざまな取り組みを行っています。その取り組みの一つに「ベロシティーの導入」があり、最近良い効果が実感できてきたのでご紹介いたします。
ベロシティー導入の機運高まる
以前のYOSHINA開発プロセスはこのようになっていました。
リリース計画作りでは次バージョンのリリース日程と、追加・改善する機能を決めます。ここで決まった機能をリリースまでに実装することになります。実装を進めていくうちに、当初の予定より実装に時間のかかる機能であることが判明したり、飛び込みでリリースに含めたい機能が出てきたりするため、最終的にリリースされる機能と必ずしもイコールではありません。
リリース計画が決まったら、スプリントという単位で計画作りと実装のプロセスを繰り返します。YOSHINA分析チームではスプリントを1週間としています。
スプリント計画作りではこのスプリントでどの機能を実装するかを決めます。実装ではスプリント計画に従って、開発チームで手分けして実装を進めていきます。スプリントが終わる時点で、スプリント計画で決めた機能の実装は一通り終わっていることが理想です。実際にはそんなことは滅多になく、何かしらの機能の実装が間に合っていないことが多いです。そういう場合は何か見えていなかった問題に直面していることが多いので、どういった課題があるのか、どうすれば解決できるのかを話し合い、次のスプリント計画作りの参考にします。
リリース予定日が近づいてきたら実装は終わりにして、YOSHINA全体として意図した挙動をしているかの動作確認フェーズに入ります。そこで見つかった致命的なバグを修正してリリースを行います。リリース予定日から遅れることはできる限り避けるべきなので、開発メンバーはリリース予定日の前々日くらいからピリピリしだします。
ご紹介したプロセスのなかで特に重要なのがリリース計画作りとスプリント計画作りです。開発しきれない量の機能をリリース計画に含めてしまうと、リリース日に遅れてしまったり、リリース予定の機能を実装しきれなかったりしてしまいます。適切に計画を立てるには、1スプリントでどれくらいの量のタスクをこなせるかを正確に予想する必要があります。
それまではベテラン開発者の勘に頼って計画作りをしていました。これではベテラン開発者が不在の時に誰かが代わりに計画作りをすることができません。また、計画に客観的な根拠がなく、ベテラン開発者が予想を見誤ってしまったらダイレクトにリリース計画に響くのでリスクが高いです。そのような問題を解決するために導入したのがベロシティーでした。
ベロシティーとは
ベロシティーとはざっくり言えば、チームが1スプリント内にこなせるタスク量です。各タスクにそのタスクがどれくらい大変かを表すポイントをつけておき、1スプリント内にこなせたタスクのポイントを合計することでベロシティーが計算できます。
ベロシティー導入後の現在の開発プロセスはこのようになります。
見積もりでは、機能ごとのポイントを開発チームで相談して決めます。ポイントは相対的な値で、過去に実装した他の機能のポイント数と比較して決めます。
振り返りでは、予想ポイント数と実際にかかったスプリント数の乖離を評価し、ベロシティーを算出します。
ベロシティー（予想） = リリース機能の予想ポイント数 / スプリント数 ベロシティー（実際） = リリース機能の実際のポイント数 / スプリント数
ここで算出したベロシティーを、さらに次のリリース計画作りで参考値として利用します。
導入までの道のり
見積もりの導入
初めて見積もりするときは比較対象がないので、ざっくり「1人が1スプリントかけてやり切れる量を3とする」と定めました。ポイントは 1 2 3 5 8 13 お手上げ から選ぶようにしました。より大きい機能は正確に見積もるのが難しいので、フィボナッチ数列を採用しています。また 13 を超えてくるような大きな機能は実は複数の機能が混在してしまっている可能性が高いので お手上げ として、機能項目の見直しを検討します。
見積もりを導入してみて得られたメリットが2つありました。
- 要件の洗い出しを早い段階でできるようになった。
- 見積もりの際に大まかな実装方針まで相談することで、開発チーム内での分担がしやすくなった。
ポイントというある程度具体的な数字を決めるために、実装に着手してから確認していた細かい要件を見積もりの段階で洗い出すことになりました。これにより、明示されていない隠れた要件がリリース直前に判明するといったことがなくなり、リリース計画作りの信憑性が増しました。
さらに、見積もりのついでに大まかな実装方針の合意を取ることで、誰でもその機能の実装に着手しやすくなりました。また、「違う方針で進めると思ってたのに〜」といった作業のコンフリクトが発生しにくくなりました。
開発期間を記録付け
見積もりの導入が軌道に乗ると、次は機能ごとに開発開始日と開発終了日を記録付けし、開発期間を算出できるようにしました。これにより予想ポイント数と実際にかかったスプリント数を比較できるようになり、今まで見えていなかった問題に気づけるようになりました。
リリース計画作りで過去のベロシティーと事前見積もりを参考にする
実は見積もり導入時点では、リリース計画作りの後に見積もりを行っていました。というのも、事前に見積もりを行えるだけの時間的余裕が開発チームになかったからです。
見積もりと開発期間が軌道に乗り、ベロシティーのようなものがなんとなく算出できるようになったことで、これらの効果が実感できたため、本腰を入れて事前見積もりをすることになりました。
事前に見積もりをすることで、過去のベロシティーと事前に見積もったポイント数から、次のリリースに含められる機能の量が客観的にわかるようになりました。これにより、リリースに含める機能の取捨選択を行いやすくなりました。
今後：ベロシティーベースで計画作り
リリース計画作りにベロシティーを導入できたのはつい最近です。今後リリースを重ねていくことでベロシティーの信憑性が増し、計画作りの確度が上がると見込んでいます。
まとめ
ベロシティー導入で得られた効果をまとめると以下のようになります。
- 見積もりによって要件の洗い出しを事前に行えるようになった！
- 予想ポイントと実際かかった期間に乖離があった部分を振り返ることで、見えていなかった問題を顕在化させることができるようになった！
- 開発者個人の勘ではなく、ベロシティーという客観的な数字を根拠として計画作りができるようになった！
また、リリース計画の確度が上がったことによって、YOSHINA 企画そのものにも以下のような波及効果がありました。
- リリース予定機能が営業側で把握できるようになった！
- 検討中のお客様に対して、リリース予定を案内できるようになった！
ベロシティーの導入は決して簡単とは言えません。YOSHINA 分析チームが見積もりを導入してから計画作りにベロシティーを活かせるようになるまで約半年かかりました。しかし、上で挙げたような効果を実感し、やってよかったと感じています。
個人的に特によかったと思うのは段階的に導入できたことです。いきなりベロシティーを導入するのではなく、見積もりの導入→開発期間の導入→ベロシティーを計画作りの参考にする、というように、できることから順番に少しずつ取り組んでいったことで、チーム全体にかかる負担を抑えつつ、メリットを実感・共有できて、ベロシティーを導入する土壌を上手く育てられたと感じています。
