Webエンジニアの今井です！ Rettyでは現在4つの開発チームがあるのですが、2年近く在籍したチームを半年ほど前に離れ、今は「あんこうチーム」に在籍しています。そのあんこうチームなんですが、ここ最近ベロシティがいい感じに上がってきており、プロダクトバックログから着手したアイテムをスッキリ終わらせられることが増えてきました。

何かがうまくハマっているのは間違いなさそうなので、今後もしっかりKeepしていけるように、その辺りを言語化してみようと思います！

スプリント内で「分担」することの課題感

1回のスプリントで複数のプロダクトバックログアイテムを取った時には、より優先順位の高いものから終わらせられるように動きます。スプリントゴールの置き方によって多少変わるかもしれませんが、「取ったアイテム全部を同時進行させて隙間なく分担する」ようなリソース効率を重視する進め方よりも、「優先順位の高いアイテムから着実に倒していく」ようなフロー効率的な進め方のイメージです。

とはいえ、いくらフロー効率でといっても程度はあって、一つのアイテムにガンガン人を割いたからといってその分そのアイテムのリリースが早められるわけではないです。「このアイテムの対応にこんなに人はいらないよ」となれば次に優先順位の高いアイテムに着手します。

あんこうチームには6人のエンジニアがいるのですが、ペアプロで実装に2人、付帯作業に1人いれば、それ以上人が入ってもほとんどスピードは変わらないみたいなケースもあって、結果的に半分に分かれて別のアイテムを進めることも多いです。開発が進んでくるともっと分担して、3つのアイテムが並行して進んでいることもあります。

でも、分担がいき過ぎてしまうことで、本来もっと早く出せるはずだった最優先のリリースが数日後ろになるようなこともあり、この辺りの塩梅って難しいなと思っていました。

優先順位はぶれさせずにベロシティを上げる

「もっと早く出せたはずなのに！」というスプリントはそんな課題感が特に高まるので、当然ふりかえりで「何をどうしたら良かった？」という話になります。その度にいくつかトライを積み上げていって、無意識に運用できるようになったころから、安定して全てのアイテムをDoneできるようになっていきました。その中でうまくハマったトライと、その要因を整理してみます。

不確実性をできるだけ早く潰す

不確実性を潰すと言ってますが、やりたいことは全てのアイテムをDoneするまでの解像度を上げることです。プロダクトバックログからアイテムを取った段階では、「ストーリーポイントで見ればスプリント内に収まりそう」くらいの根拠しかないので、スプリントゴールが達成できることにチームが同意（＝コミットメント）するには不十分かと思います。

なのでスプリントプランニングでアイテムをDoneするために必要なタスクを洗い出していくわけですが、あんこうチームでも良く発生していたのが「〇〇を調査する」とか「〇〇の方法を検討する」系のタスクです。

これってタスクとして切り出しているようで、実は「なんかやることはありそうだけど後で細かくみる」くらいの情報にしかなっていないので、それがどれくらいのボリュームなのかわからないままであることが多いです。

こういうタスク分解をしたアイテムのスプリントバックログは、

〇〇の実現方法を検討する
検討内容をもとに実装する
テストする
・・・

みたいなラインナップになるので、この段階では「そこまで人要らなそう」という判断をして別のアイテムに着手することになります。しかし、そのまま進めていくと「〇〇の実現方法を検討する」の結果出てきた実装タスクが思いの外多くて、「もっと早く手を打てていれば・・・」となったりします。

なので、

設計を議論しておいて構成や対応範囲を明確する
有識者に確認したりドキュメントを探して判断に必要な情報を集める
現状のソースコードを確認しないと対応内容のイメージがつかないなら先に確認する

といったことは、スプリントプランニングの中か、少なくとも本格的に実装に入る前にできる限り済ませておくことにしました。

これをやると「スプリントプランニングにめちゃくちゃ時間かかるじゃん！」となると思いますが、ここでやっているのは本来スプリント中にやろうとしていた調査タスク、設計タスクを前倒しているだけです。スプリントプランニングを会議帯として見るとこれだけ時間をかけるのは抵抗がありますが、設計に集中するモブプロタイムだと思えば割と妥当かなと思います。複数アイテムとっているのであれば、それこそ分担して進めれば2,3時間で終わります。

ちなみに、上記のスプリントバックログの例で言うと、細かい時はこれくらいの粒度まで落としてました。

I/Fを決める
フロントの共有コンポーネント実装
UI調整
〇〇テーブルからデータ取得するロジック実装
取得データをModelに詰め替える実装
・・・

そんな感じで最初に不確実性を潰すことで、スプリント終了までの解像度が上がって、「この感じで何事もなければ全て終わらせることができそう」という判断の確度を上げることができました。

想定外のことが起きていないかの確認を頻繁に行う

「不確実性をできるだけ早く潰す」をやったからと言って、その計画通りに進むことはほどんどないので、毎日のデイリースクラムで「このまま進めていって大丈夫そう？」という確認をしています。そこで予定外のことがあればスプリント内の計画を見直して、進め方を工夫したり、場合によっては実現方法を変えてスコープ調整をしたりします。

あんこうチームでは、このデイリースクラムのようなタイミングを1日に3回ほど設けることにしてみました。複数アイテムを並行して進めたことによって自分が着手していないアイテムの状況がわからず、気づけば隣で進んでいたアイテムがスプリント内ではどうやっても軌道修正できなくなっていた、というケースに対応しようとしたトライです。

これをやると、

1人（もしくは少人数）でハマってしまってただただ時間が過ぎていた
仕様を勘違いしたまま進めてしまって手戻りになる実装をひたすら進めていた
タスクの対応範囲を正確に理解できておらず実はその後ろに眠っている大きなタスクに気づいていない

ということが検知しやすくなります。

1日に1回デイリースクラムをやるだけだと、たまたま途中のコミュニケーションを発生させずに1日が過ぎて、蓋を開けてみたら全然進んでいませんでした、とかいうことが起きうるところです。意図的に何回もコミュニケーションを挟んでおくことで、精々数時間程度のロスで済みます。

上記の他にも「全員が進行しているアイテムの状況をうっすら理解できるようになる」というメリットもあります。「朝言ってたあのタスクが終わって、予定していた次のタスクを取ったのか」だったり、「午後イチで着手したアレが懸念していた通りつまづいたんだな」だったり、自分が対応していないアイテムの状況がタイムリーに追えるわけです。これなら、自分が対応に入っていない優先順位が高いアイテムでヘルプ要請があっても、比較的スムーズに合流することができます。

こうすることで、気づいたら大きなタイムロスをしてしまう、ということを防止しつつ、何か起きたらそこまでの背景をある程度把握した状態ですぐにヘルプに入れるようになりました。

最優先のアイテムの対応にいつでも駆けつける

これは文字通り、最優先のアイテムで人手が必要になった時は、自分が進めているタスクを一旦止めてでもすぐヘルプに入ろう、というものです。

チーム内では「最優先のアイテムを対応してる人が一番偉いってことで呼びつけられたらすぐ集まろうね」みたいな会話していましたが、「最優先アイテムの対応者は遠慮せずに声かけましょう」という意味ではピッタリのニュアンスだな、と個人的に思っています。

これをやろうとした時に、先に紹介した「想定外のことが起きていないかの確認を頻繁に行う」によって「全員が進行しているアイテムの状況をうっすら理解できる」状態がいい感じに効いてきます。数時間前までの状態は大体わかってますし、うまくすれば「何かがこの後起きるかも」と予見することもできているので、それまでそのアイテムを対応していたのとあまり変わりなく合流できます。

後のふりかえりで、「これってつまりスウォーミングがいい形でできていたってことだね」という話が出ました。チームの半分はスウォーミングという言葉事態知らなかったのですが、課題感を解消しようと試行錯誤していたらそんな形になっていたみたいです。