はじめに
こんにちは、STORES のエンジニアの takeuchi です。
私が現在所属しているチームは2024年の春に新規に編成され、現在まで新規プロダクトの開発に取り組んできました。
このチームでは、スクラム開発を採用しています。2週間スプリントごとにスプリントゴールを設定し、そのスプリントゴールの達成を目指しプロダクト開発を前進させています。
本記事では、私たちのチームのスクラム開発の概要と、スプリントを重ねながらチームで改善してきたことについて紹介します。
スクラム開発の概要
スクラムイベント
スクラム開発は、短い開発サイクル（スプリント）を通じて計画・作業・振り返りを繰り返すソフトウェア開発のフレームワークです。
私たちのチームでは2週間スプリントを採用し、スクラムガイド に記載されているイベントに従い、以下のスクラムイベントを実施しています。
- デイリースクラム: チームメンバーが毎日15分程度集まり、進捗確認や問題の共有を行います
- スプリントプランニング: 2週間スプリントのスプリントゴールの設定と、ゴール達成に必要なタスクの洗い出しを行います
- スプリントレビュー: スプリント中に完了した成果物をチームで共有し、フィードバックを得ます
- スプリントレトロスペクティブ(振り返り): チームでスプリントの振り返りを行い、継続したい点と改善点を洗い出します
スプリントの後半にはリファインメントを行います。リファインメントでは次回以降のスプリントで行う開発の優先度付けや仕様の詳細化を行います。
スプリントの最終日にイベントをまとめる
私たちのチームでは、以下の3つのイベントをスプリント最終日にまとめて実施しています。
- スプリントレビュー
- スプリントレトロスペクティブ(振り返り)
- 次回スプリントのプランニング
これらのイベントにはそれぞれ一定の時間が必要ですが、日を分けるのではなく、この日を「スクラムイベントに専念する日」として割り切っています。一日にイベントを集約させることによって、他の日でまとまった作業時間を確保するためです。
一方で、イベントが全て終わる頃にはかなり疲労感があり、この日に開発作業を進めるのは難しい場合もあります。しかし、イベントを一日に集約したことでチームにメリハリが生まれ、良いリズムで開発ができているのではと感じています。
タスク管理
タスク管理は GitHub Issue と GitHub Projects で行います。
スプリント
GitHub Projects のカスタムフィールドを Field type: iteration で作成することにより、GitHub Projects 内のアイテムをグループ化して管理することができます。
この機能を利用して、Sprint field を作成し、そのスプリントに該当する GitHub Issue を紐づけることで特定のスプリントのタスクを絞り込んで閲覧することができます。
ストーリーポイント
ストーリーポイントも GitHub Projects のカスタムフィールドを使用します。
Field type: Number でカスタムフィールドを作成し、GitHub Issue に紐づけることでストーリーポイントを GitHub Projects から確認できます。
これまでに行ってきた改善について紹介
私たちのチームでは、上記で紹介したスクラム開発のプロセスにおいてスプリントごとに振り返りを行い、問題点を洗い出して改善に取り組んできました。その中でも特に効果があったと感じた改善についてご紹介します。
プランニングのやり方を変える
スクラム開発を始めた初期段階ではプランニング時に切り出したタスクの粒度が粗く、完了条件も曖昧だったため、スプリント途中で進捗が滞ることがありました。また、DBのテーブルスキーマやAPIスキーマの設計に関する議論が長引き、その影響で重要な実装がスプリント内でスムーズにマージされず、後続のタスクが進まないという問題が発生していました。
この問題に対して、以下のように対応することを試してみました。
- DBのテーブルスキーマやAPIスキーマはプランニングの時間で同期的に決めきる
- 複雑な実装が必要なタスクは、プランニングの時間で詳細な実装部分まで踏み込み、実装のイメージを固める
2週間のスプリントに必要な全てのテーブルのスキーマやAPIのスキーマをプランニング時に同期的に決めます。テーブルスキーマやAPIスキーマの新規追加・変更のタスクの分量が多いスプリントは、プランニングに多くの時間が必要になり、なかなか大変です。
ただ、これらの作業に時間をかかる分、以下のような効果がありました。
- 重要な実装についてはあらかじめ認識が揃っているので、Pull Request 上での議論が減りマージまでの時間が短くなる
- タスクの詳細な部分まで事前に踏み込んでおくことにより、全体像が見えやすくなり漏れるタスクがなくなる
プランニングのやり方の変更後は、プランニングにかける労力と時間が当然増えましたが、変更後は変更前より後続のタスクに対してブロッカーになるタスクが減り、チームでタスクを並行して開発が進められるようになりました。
現在でもこの取り組みは継続しており、変えてみて良かったと感じています。
リファインメントでは未来の話に注力する
開発の初期段階では、進行中のスプリントに関する進捗確認や、そのスプリント中に発生した問題の対応についての議論などに時間が費やされることがありました。しかし、リファインメントで次回以降のスプリントの話ができていないことで、結果的に次回スプリントのプランニングの時間が長引き、プランニングが予定通りに終わらないことがありました。
この問題を解決するために、リファインメントの時間では次回以降のスプリントに焦点を当てることにし、現在のスプリントの進捗確認や課題の対応は必要最小限に留めるようにしました。
レビューが滞る問題への対応
スプリントが進むにつれ、新体制での開発にチームが慣れてきたことで、スプリント内で作成されるPull Requestの数が増加しました。それに伴い、一部のPRがレビューされずに滞留するという課題が発生しました。特に修正内容が複雑であったり、修正自体は簡単でも、対象の機能が複雑な場合にレビューが遅れることがありました。
各 Pull Request の description に実装についての詳細な情報を記載し、レビュアーが背景や変更内容を理解しやすくする、というのは元々チームで意識していたのですが、PRの説明をどれだけ詳細にしても、同期的に共有した方がタスク完了までにかかる時間を短縮できる場合があります。
そのため、毎日夕方に「レビュー確認の時間」を設け、その時間では以下のようなことを行いました。
- レビューが滞っているPRがないか確認する
- 実装者がレビュー依頼時に共有したいポイントを簡単に説明する
これらの取り組みによって、レビュー依頼が放置される Pull Request が減り、マージまでスムーズに進むようになりました。同期的な共有によりレビューに着手するハードルが下がったことで、チーム全体の開発フローがより円滑になったと感じています。
優先度が高いタスクにラベルをつける
開発を進める中で、スプリントの途中に後続のブロッカーとなるタスクが発生し、その影響で後続のタスクが進められない状況が生じることがありました。この問題の原因は、スプリントプランニング時に優先度の高いタスクが十分に洗い出されていないことでした。
この問題を解決するため、プランニング時に以下の対応を行うようにしました。
- 優先度の高いタスクを事前に洗い出す
- 優先度が高いタスクは担当者を決めておく
優先度の高いタスクには GitHub のラベル機能を活用し、優先度が高いタスクにラベルを付けて管理します。これにより、GitHub Projectsでタスクを確認した際に、優先度が一目で分かるようになっています。
これでプランニング時に優先度の高いタスクは洗い出すようになったのですが、優先度が整理されていても、進行中に新たなブロッカーが発生する場合がありました。
そのため、優先度の高いタスクの確認はデイリースクラムで毎日行うようにしました。 現在ではブロッカーになるタスクはデイリースクラムで必要に応じてタスクにラベルを追加し、そのラベルがついているタスクを優先して消化するようにしています。
これにより、特定のタスクがブロッカーになりスプリント全体の作業が停滞することが少なくなりました。
ADR（Architectural Decision Record）でアーキテクチャの意思決定を残す
この取り組みは、スプリント中に出てきた課題に対して改善したものではありませんが、これまでの開発を振り返って、開発初期に特にやって良かったと感じたものだったため紹介します。
私たちのチームでは新規プロダクトの開発を行なっており、初期の議論や重要な意思決定をどこかに記録として残しておかないと、後々過去の意思決定やその詳細を忘れてしまうことが想像できました。そのため、何らかの形でドキュメントを残す必要がありました。
そこで、他のチームですでに運用実績があった ADR（Architectural Decision Record） を記録することにしました。
ADRでは、意思決定に至った背景（コンテキスト）、具体的な決定内容、その決定がプロダクトに与える影響を記録することができます。これにより、意思決定の全体像が明確になり、後から振り返る際にも役立つ構造化された情報を残せます。
ADRを記録することで、過去の重要な意思決定を残すことができました。これにより、必要なタイミングで過去の記録を参照することができ、過去の決定を忘れた頃に意思決定の背景や経緯を振り返る場面でも大いに役立っています。また、チーム外のメンバーや新しく参加したメンバーにシステムの構造や設計意図を説明する際にも役立っています。
ADRは以下のようなテンプレートで運用しています。
# Decision (required) <!-- この意思決定の内容を一行で記載します。 --> ## Detail (optional) <!-- Decisionが一行で済まない場合に補足します。 --> ## Context (required) <!--- Context は、意思決定時における状況や問題、必要になった理由や動機について記述します。 これらを明記することで、意思決定の背後にある文脈を読み取れるようにします。 --> ### Related ADRs (optional) <!-- 関連の強いADRがある場合、ここでそのADRとの関係(詳細の定義、取り消しなど)を記述します。 --> ## Consequences (required) <!-- この意思決定を適用した結果、何が解決され、何が難しくなるのか、この選択に決定した理由を記述します。 - pros: - cons: --> ## Alternatives (should) <!-- 今回選ばなかったが候補として上がった選択肢についてを記述します。 - pros: - cons: -->
おわりに
スクラム開発を通じて得たこれらの知見が、他のチームやプロジェクトにも役立てば幸いです。引き続き、改善を重ねながら、より良い開発を目指していきたいと思います。
