チームとプロジェクトの変化を受けてスクラムイベントを見直した話

はじめに

こんにちは。認証・権限管理基盤チームでソフトウェアエンジニアをしている坂本です。

皆さんのチームでは、「昔はうまくいっていたはずの開発プロセスが、なぜか最近うまく回らない…」と感じることはありませんか？

私たちのチームも、プロジェクトの進展とメンバーの拡大に伴い、かつて機能していたスクラムイベントがフィットしなくなるという課題に直面しました。

今回は、その課題を特定し、チームで対話しながらスクラムイベントの設計を見直した経験を共有します。私たちの試行錯誤が、同じような状況にいる方々の参考になれば幸いです。

チームとプロジェクトの移行期

私達のチームでは直近半年ほどで主に以下のような大きな変化がありました。

少人数チームから拡大

私たちのチームでは、担当プロダクトの新規開発・機能追加や運用体制の強化のため、エンジニアを増員してきました。
私も6月にチームにジョインし、当初エンジニアが2〜3名だったチームは、半年ほどで現在6名体制となっています。

新規機能のリリースを意識した開発に移行

プロジェクト立ち上げ期は順調に開発を進めていました。開発を進め、仕様への解像度が高まっていった結果、ある程度システムに修正が必要であることがわかりました。

チームの変化によりスクラムイベントがフィットしなくなってきた

チームやプロジェクト状況の急激な変化により、当時のスクラムイベントが適切にワークしていないことに気づきました。
主に以下のような問題が顕在化しました。

少人数チーム時の名残によって個別にタスクのブリーフィングを実施することがあり、チーム内でコンテキストを共有できていないケースがある。
スプリントゴールに多くの目標を設定しているため、ゴールを意識した開発をしづらい状況になっている。
1スプリントの期間が長いため、プロジェクトのスコープ変更に対して軌道修正がしづらくなっている。

見直したこと

上記のような問題を解決するためにチームメンバーと相談しつつ、いくつかスクラムイベントの見直しを行いました。

タスクのブリーフィングと見積もりを定例化

これまでタスクごとに個別で実施していたタスクのブリーフィングや見積もりを、チーム全員が参加する定例ミーティングに改めました。

この場では、次のスプリントで着手候補のタスクについてPdMから背景や目的を説明し、その後チーム全員で仕様の確認や技術的な実現方法についてディスカッションします。全員の認識が揃った上で、タスクの規模感を見積もる（ポーカープランニング）ことで、以下のような効果を狙いました。

コンテキストの共有:「誰が何をやっているか分からない」状態をなくし、チーム全体でプロダクトへの理解を深める。
見積もり精度の向上: 複数人の視点で見ることで、考慮漏れを減らし、より現実的な見積もりが可能になる。
タスクの明確化: 開発に着手する前に疑問点を解消し、手戻りを防ぐ。

スプリント期間を2週間 → 1週間に

チームが拡大し、プロジェクトの不確実性が減ってきた状況を踏まえ、スプリント期間を2週間から1週間に短縮しました。

2週間スプリントでは、期間が長いがゆえに複数の大きなテーマ（ゴール）が混在しがちでした。その結果、スプリントの焦点がぼやけ、チームとしての一体感が薄れてしまうという問題がありました。

スプリントを1週間に短縮することで、より具体的で達成可能な単一のスプリントゴールを設定しやすくなります。また、短いサイクルでタスクの優先度を整理することで開発の手戻りや遅延を防止する効果を狙いました。

スクラムイベントの変更を提案した時のメンバーの反応

私自身がチームにジョインしてから期間があまり経過していなかったこともあり、スプリント期間の変更など大きな変更を提案することに対してやや不安を感じていました。しかし、メンバーは提案に対して「とりあえず試してみよう」と変化を恐れずに提案を受け入れてくれました。

また、私たちのチームでは何かを提案する際に以下のような形式でADR（Architecture Decision Record）を作成する文化があります。

- [ ] 執筆済
- [ ] 承認済
- [ ] 否認済
- [ ] 廃止済

# コンテキスト

<!--  技術的制約やビジネス要求など、解決したい課題と取り巻く現状を客観的に記述する。価値中立的で、単に事実のみを述べる。 -->

# 決定

<!-- 決定された案を記述する。肯定的かつ命令的に述べる。 -->

# 影響

<!-- 決定によって容易になることと、難しくなることを述べる。 -->

今回のスクラムイベントの変更に対してもADRを作成した（※）のですが、このフォーマットにより変更背景やProsConsが綺麗にまとまることにより、メンバーも納得感を持って提案を快く承認してくれたのではないかなと思っています。

※: 今回の提案はアーキテクチャの変更ではないのですが、アーキテクチャ以外の変更も慣例的にADRという言葉を使用しています。

チームにどんな変化が起きたか

これらの見直しを実施した結果、チームには総じてポジティブな変化が生まれました。

まず、タスクのブリーフィングと見積もりを定例化したことで、チーム全体の目線が格段に揃うようになりました。「誰が何をしているか」が明確になり、以前よりもメンバー間で助け合ったり、レビューがスムーズになったりする場面が増えました。特に、プランニングポーカーを通じてタスクの解像度を全員で上げるプロセスは、新しくジョインしたメンバーのキャッチアップを促進し、ベテランメンバーにとっては考慮漏れを防ぐ良い機会となっています。結果として、スプリント内で発生する手戻りが減少し、チームのベロシティ（開発速度）も安定し始めました。

次に、スプリント期間を1週間に短縮したことは、チームの開発リズムを大きく改善しました。毎週、具体的で達成可能なゴールを設定できるため、全員が同じ方向を向いて集中しやすくなりました。また、短いサイクルで計画と実績を振り返るため、開発タスクの急な優先度変更にも、以前より柔軟かつ迅速に対応できるようになりました。

総じて、コミュニケーションの機会が増え、チームとしての一体感が醸成されたことが大きな変化だと感じています。一方で、ネガティブな面として同期コミュニケーションを重視することになったためミーティングの時間が増加し、エンジニアの作業時間は減りました。作業時間の減少は現状コンテキストを揃えるために必要な時間と捉えています。しかし、コンテキストを揃えることに囚われミーティングの時間が増えすぎてしまうことのないように、折を見て定例ミーティングの棚卸しも実施したいと思っています。