こんにちは。フィードフォースの EC Booster チームで開発(主にプロダクトオーナー)をしている @sukechannnn です。元々ずっとバックエンドエンジニアでしたが、最近プロダクトオーナーをやるようになりました(理由はのちほど!)。
昨年のアドベントカレンダーで 半年モブプロしたらチームが大きく成長した話 というブログを書いたのですが、2021年3月から モブプロを取り入れたスクラム開発 をしています。それに伴って、"モブプロ" と "個人タスク⇢レビュー" の両軸で開発するようになりました(先日リリースしたカイゼンカード はスクラムで開発しました)。
今は良い感じに回っていますが、そうなるまでに色々と試行錯誤したので、そこで得た学びをお伝えできればと思います。全員リモートワークで開発するなら、モブプロを取り入れたスクラムはおすすめです!
モブプロの良さと難しさ
モブプロ中心の開発を初めた当初は、以下の利点を感じていました。
- ドメイン知識の共有がしやすい
- コンテキストの共有がしやすい("何をどう作るか" という議論もしやすい)
- レビューが要らない
- リモートワークでもさみしくない(だいじ)
しばらくモブプロを続ける中で、開発メンバー全員がドメイン知識やフロント〜バックエンド全体の技術的な知識を共有している状態になりました。なので、なにか悩みがあってモブプロで共有すると「わかる〜」となるし、何より単純に仲良くなったと思います(ヨシッ!!)。
一方で、だんだんと モブプロだけ の開発が窮屈になってきました。
- 知識の共有が進んできて "全員でやらなくても良くない?" というタスクが増えてきた
- 個人でじっくり考えた方が良いタスクもあるのが分かった(新しい技術の調査、設計の見直しなど)
これはチームが成長したことで出てきた嬉しい悩みなのですが、とはいえ完全にモブプロを辞めるのも上述したメリットを失いそうで怖い...。チーム全員で「今後どう開発していこう?」というのを話し合い、モブプロを取り入れたスクラム開発 を試してみることにしました。
そうだ、スクラムしよう!
スクラム開発をしようと思ったのは、ストーリーポイント*1で見積もって ベロシティ*2を測りたい という別の目的もありました。
モブプロで開発していると新機能のメイン開発は着実に進んでいくのですが、それ以外の細かいタスク(主に保守系)が見積もりづらい状況で、空いた時間にやるという形になってしまっていました(それ用に時間は設けていましたが)。
モブプロ以外の個人タスクを計画的にやりたい、見積もりもしっかりやりたい、ということで、スクラムを導入することで、モブプロと個人開発のいいとこ取り をしようと考えました。
- 新機能開発などのコンテキストの共有が重要なタスクは引き続きモブプロでやる
- ストーリーポイントで見積もる
- それ以外は個人タスクとして各自で進められるように、プランニングでしっかり整理する
- 個人タスクもストーリーポイントで見積もる
- 全てのタスクをストーリーポイントで見積もるのでベロシティが測れるようになる
- 振り返りで見積もりの精度を上げられる
めっちゃ良さそう...そう思っていざやってみたところ、1つ大きな壁にぶち当たってしまいました。
プランニングが終わらない問題
エッセンシャルスクラムにもある通り、1週間のプランニングに2時間以上かけるべきではありません。僕らは「1スプリント=1週間」で回しているため、2時間の予定で始めたプランニングですが、これが終わらない...。最初から何回かは4時間以上かかり、全員ヘトヘトになってしまいました。
モブプロはプランニングが簡単です。全員やることが同じなので、基本的にタスクが直列で繋がっていきます。そのため「今スプリントはここから⇢ここまで」という感じで Sprint Backlog 的なものを決めることができました。
しかし、スクラムの見積もりはもっと横断的なものです。単純に、今取り組んでいるものだけ見れば良いのではなく、これから取り組むものをたくさんある issue から選ぶ必要があります。そう、この たくさんある issue の中から今スプリントにやるタスクを選ぶこと に時間がかかってしまうのです。
以前にもスクラム開発を試したことがあるのですが、その時もこれが原因でプランニングがとても大変でした。気にするトピックが多すぎてだんだん何について議論してるか分からなくなり、空中戦になってしまうんですよね...。
その原因は、主に以下の2つでした。
プロダクトオーナー不在の問題は、元々それっぽいことをしていた僕が、改めてプロダクトオーナーやりますと手を上げ、バックログ管理の責任を持つことになりました。
それでも、バックログリファインメントが上手く行かない問題は残っていました。リファインメントの概念は理解していて、しっかり時間も取っていたのに、いざプランニングをすると色々な issue を見すぎて伸びてしまう...。過去に何度も直面したこの問題に、改めて取り組むことにしました。
原因は「issue が散らかっていること」だった
僕たちが開発している EC Booster は、ショッピング広告の自動運用やデータフィードの更新など、様々なジョブが裏で動いています。そのため、運用作業が日々発生し、運用の中で見つかる例外ケースやバグの修正が多々あります。 また、フロントエンドとバックエンドを全員が開発するため、1つのリポジトリで管理していることもあり、色々な種類の issue が1つのレーンに入り乱れてしまっていました。
そのため、優先順位を付けるのも難しく、また「次スプリントで何をどこまでやるか?」を判断するのが難しくなってしまっていました。
プロダクトバックログを整理しなければ、というのは分かっているのですが、スクラムに関する本やブログには整理の方法は書いてありません。どうやって整理したら分かりやすくなるかな...と考えていたところ、同僚が共有してくれた以下の記事が参考になりました。
エンジニア歴17年の俺が、事業系の開発タスクをバンバン投げてくる非エンジニアに、保守の必要性を死ぬほど分かりやすく説明する。
この記事の中で「issueには "種類" がある」と言っていて、issue の種類別に整理された図が載っていました。これだ...!
issue をグルーピング、優先順位はそれぞれで
上記の記事を参考に、issue を 新機能開発、バグ修正/運用改善、ライブラリーアップデート に分けて、それぞれのレーンで優先順位を付けるようにしました。
issue の種類が同じなので、優先順位を付けるのは簡単です。さらに、スプリントバックログに入れるタスクを 新機能開発:運用系 = 6:4 の割合にする、という決めを作りました。さらに、何回かスプリントを回してベロシティも見えてきました。
ここまで情報が揃うと 次のスプリントで何をやるか決める基準 ができてきます。
そもそもの「次のプランニングでどの issue について話すか?」というのも、それぞれのレーンで優先順位が高い issue を6:4のバランスとベロシティを参考に選べるようになりました。プランニングの前にプロダクトオーナーが(開発チームと協力しながら)当たりを付けておくことで、プランニングで話すトピックを事前に共有できるようになり、開発メンバーそれぞれが事前に頭を整理しておくこともできるようになりました。
これにより、プランニングがかなりスムーズに進むようになったので、いよいよスクラムが回り始めました。新機能開発はモブプロの同期的な開発で、それ以外のタスクは個人タスク⇢レビューという非同期な開発で進められるようになり、デリバリーの最大化を目指しつつ、個人の稼働率も上げられるようになりました。
まとめ
issue をグルーピングしそれぞれで優先順位を付けたことで、プランニングが時間内に収まるようになっただけでなく、プランニングで話すトピックを絞ったことでより深い議論をすることができるようになりました。今は「モブプロを取り入れたスクラム」がとても良い感じに回っています!
↓ EC Booster チームでの「スプリントの回し方」資料を公開しているので、気になった方はぜひ見てみてください!(もっとこうしたら良いよ!という助言などあれば頂けると嬉しいです!)
こんな感じ開発している EC Booster ですが、ただ今 バックエンド(Ruby, Rails)が得意なエンジニアを猛烈に必要としています!!!
もしちょっっっとでも興味があれば、 僕とお話しましょう! 以下から気軽に応募してください! https://open.talentio.com/1/c/feedforce/requisitions/detail/19785
最後まで読んでいただき、ありがとうございました!