昨年の12月にSWEとして入社した、estie の野村です。1月末に新たなチームが発足され、そのチームで1スプリント2日でスクラムを回すという試みをしたので、感じた利点などを書いていこうと思います。
新たなプロジェクト始動
1月末にプロダクト全体の方向性を決めるためのミーティングが開かれました。今までestie proというプロダクトがユーザの要望に応じてインクリメンタルに改善されてきたため、所謂十徳ナイフになってしまう懸念があり、全体の機能を見直してより業務の改善に繋がるようなプロダクトに変えていきたいという目的がありました。
3時間超の議論の末、出たアイデアに対して「これはいける」「試す価値あり」と賛同の声が上がり、その場で5名のチームが結成され新たなプロジェクトが開始しました。他のチームも含め1週間でチーム編成を変更し、次の週にはスクラムが始まっていました。前職が比較的大きな企業だった自分にとっては衝撃的なスピード感でした。
（スクラムに参加した事業責任者視点の記事はこちら https://www.estie.jp/blog/entry/2023/04/12/150000 ）
このプロジェクトは不確実性が高いため、プロトタイプを早く作り顧客からフィードバックを得ることが求められました。確実に進めるのであれば仮説から具体的な機能の全体像を練り、デザインを作ってからようやく実装が始まりますが、今回はこれらを並行に進めることで開発スピードの向上を図りました。機能1つ1つの仕様が決まった側からデザインを作り始めて実装に移るというサイクルを繰り返し、時にはデザインを待たずにAPIだけ先に実装することもありました。
1週間のスプリントでは長すぎた
このプロジェクトでは仕様・デザイン・実装がほぼ同時進行だったため、デザインや仕様の決定・変更が頻繁に起きることが予想されました。実際に昨日正しいと思っていたことが今日違うことがわかったり、方向転換やレビューのためのコミュニケーションを細かく取る必要がありました。そこで、一般的にスプリントの長さは1~4週間ですが、それよりも短い期間にすることにしました。
また、具体的に固まっている仕様がそもそも少ない状態が続くため、無理に1週間分のタスクを見積もってもその意味は薄くなってしまいます。
1sprint1day
前述の課題を解決をするために、仕様決定→デザイン→実装→レビューのサイクルを毎日回すことにしました。定期的なミーティングは朝と夕方のそれぞれ30分で以下の通り。
朝会：レビュー・レトロスペクティブ・プランニング
| レビュー | SWEは成果物の共有、PdMやデザイナーは新たに追加したい機能の共有をし、チームメンバーと議論する |
| 前スプリントの終了 | チケットのステータスを再確認した後、前のスプリントを閉じる |
| レトロスペクティブ | 計画通りにチケットが消化できなかった場合に原因究明のために議論をする |
| プランニング | 必要なチケットが作られているか確認する。ストーリーポイントを振り、大きなタスクであればチケットを分割する。見積もりを立てやすくするために事前にチケット分割、詳細の記入が済んでいることが望ましい。 |
| 次スプリントの開始 | これまでのスプリントから完了できそうなストーリーポイントを推測し、1日分のタスクを積み込んでスプリントを開始する |
夕会：リファインメント
| 機能の詳細を詰める | 朝会で詰めきれなかった部分または新たな内容について議論を行い、バックログのタスクをより鮮明にする |
| 疑問点の解消 | 実装途中で上がった疑問などを解消する |
1sprint1dayを1週間試してみた結果、想定通りそれぞれのタスクをうまく並行して進めることができました。しかし、実装に加えてコードレビューなどを含めると1日でタスクを完了させることは難しく、これ以上タスクを意味のある単位に分割することはできなかったため、1スプリントを2日に延ばしてみることにしました。
1sprint2days
1sprint1dayで行っていた夕会を内容そのまま2日目の朝会に移して2日に延ばしてみました。
- 1日目朝会：レビュー・レトロスペクティブ・プランニング
- 2日目朝会：進捗報告・リファインメント
チームとしては2日が程よい長さでした。バックログのタスク量やデプロイプロセスによっては1週間が最適なケースもあると思います。
感じたメリット・デメリット
メリット
タスクがより具体的なものになる
2日以内にこなせるタスクには限りがあるため、程よく分割されている必要があります。詳細に目を当てないと分割は行えないため、タスクの解像度が増し必然的にそれぞれのサブタスクの具体性が増します。見積もりや目標が決めやすい
短期的な目標の方が決めやすいですし、1~2日以内にタスクをこなせるかの判断はより確実性の高いものになります。詳細に対する議論が早期に起きやすくなる
短いスプリントの前提としてタスクが細かく分割されている必要があり、実装を考えながら分割すると疑問が上がりやすく、チケットを整理する段階でデザインや仕様の議論が行われることが増えました。タスクそのものが明確で誰でも取り組むことができる
これもタスクが分割されていることによる利点で、弊チームではSWE2人とデザインエンジニア1人で実装しており、同じタスクのサブタスクを手分けして行いたい時でも常にチケットが拾いやすい状態になっていました。進捗がわかりやすくなる
スプリントに積んだタスクが終わっているかどうかがはっきりわかる、また成果報告の頻度が上がるため、進捗を管理しやすくなります。ベロシティが数値としてすぐ出るため振り返りがしやすい・モチベーションが上がる
2日毎にベロシティが数値として出てくるため、次のスプリントにすぐ活かすことが出来ます。ベロシティが下がった時にボトルネックとなる点があったか、想定していなかった困難に直面したか、開発以外のタスクが考慮されていなかったか、などの振り返りが行うことが出来ました。
一方ベロシティが上がった時には盛り上がります。プロジェクトを始める際にインセプションデッキを作りメンバーの優先順位を共有したのですが、「モチベーション」が1番という結果でした。ベロシティが数値としてすぐ出ることもモチベーションの向上、ハイパフォーマンスの発揮に貢献したのではないかと思います。
デメリット
正確なベロシティを計測しづらい
2日でギリギリ完了まで持っていけず、ベロシティとしては次のスプリントに積まれることも多々ありました。そのため数スプリントの平均を取るなどしていましたが、正確なベロシティを計りたい場合はスプリントの期間を長くした方がいいかもしれません。JIRAとの相性が悪い
JIRAではチケットを細かくサブタスクに分割してもサブタスクのみをスプリントに積むことは出来ません。また、サブタスクに振られたストーリーポイントはベロシティに換算されないため、サブタスクを使わない運用が必要になります。
まとめ
計画通り1ヶ月半でMVPを出すことができ、結果として1sprint2daysは成功でした。次のプロジェクトは、スコープがある程度決まっているため1週間のスプリントにしていますが、今回のプロジェクトで2日のスプリントでも機能するという学びがありました。今回のように仕様があまり決まっていない状態でスピードが求められる場合に、1sprint2daysはうまく機能すると思います。デメリットとしてベロシティの計測が難しくなりますが、計測する範囲を広げたり、ツールの使い方を工夫することでデメリットを抑えることができます。
また、上で述べたメリットはタスクが細分化されていることが肝であるため、1週間以上のスプリントでも同じようなタスク管理を行えば同じメリットが得られるはずです。
スプリントの期間をどのくらいにしようか悩んでいる方がいましたら是非参考にしてみてください。またestieでの開発に興味を持ってくれた方、是非一度エンジニアメンバーとお話ししましょう！
