はじめに
こんにちは！アソビューでバックエンドエンジニア兼スクラムマスターをしている島田です！
2023年12月にコンサートや舞台公演などの希望する座席を購入できる、座席指定システムをローンチしました。
その後体制変更が行われ、今後のエンハンスを進めるにあたり本格的にスクラム開発を導入しました。
今回は、スクラム開発を導入時に出た課題感と解決した内容をお伝えできればと思います。
なお、ローンチまでの開発プロセスや体制については、プロジェクトマネージャーからプロダクトオーナーへの転身。スクラムの実践を通じて学んだ課題と魅力 を御覧ください。
チーム体制について
冒頭に体制変更が行われた旨の通り元々は30人以上開発に関わっており、機能軸(管理/ユーザ等の大きい範囲)で複数チームが構成されていました。 2023年12月に座席指定システムのローンチを迎え、2024年2月から体制変更が行われたことにより規模が徐々に縮小した結果、現在は以下のメンバー構成でスクラムを回しています。
- PdM(兼PO)
- PjM(兼SM)
- バックエンド ：4人
- フロントエンド：2人
- QA：1人
- 計：9人
現在のスクラムチーム結成時には以下の課題がありました。
- ローンチまではウォータフォールで開発していた
- これまで所属していたチームがバラバラで業務知識が偏っていた
- アソビューでのスクラム開発経験やスクラム開発自体の経験が不足していた
- コア業務知識が豊富なメンバーがほとんどいなくなった
スクラムの導入にあたって行ったこと
スクラムガイド勉強会
メンバー全員が共通の認識/知識を持った上で運営をしていくことを目的に、スクラムガイドの読み合わせを全員で行いました。
やり方としては目次毎に意見や疑問点をアウトプットし、それに対してこれまでの開発の振り返り、改善点も含めて議論をしました。
また、勉強会にはアジャイルコーチを招きチームで議論したことに対するアドバイスであったり、疑問点などをその場で認識を揃えられるようにしました。
実際にやってみたことで、各スクラムイベントでは何をどのようにやるものなのか、言葉の定義と意味について個々の認識がズレていたものが何となく…ですが揃ったと思います。
何よりも良かったのはこれからこうして行きたいよね。という共通認識ができたことです。
スプリントゼロの実施
いきなりスクラムを回すのではなく、軌道に乗るまでの助走期間としてスプリントゼロを実施しました。
期間としては2週間スプリントで回して1ヶ月間行い、経験豊富なアジャイルコーチに助言をいただきながら実施しました。
実際にスプリントを開始してみると上手く回ることはなく、各イベントでの課題が出てきたので説明します。
スプリントゼロで発生した各スクラムイベントの課題
バックログリファインメント
私達のチームではバックログの管理はPdMが行っており、ビジネス側と優先順位を決めた順に並んでいます。
バックログリファインメントの場では、次のスプリントで実施するストーリーの目的や共有を行っています。
エピック・ストーリーの粒度が不適切
新規機能開発におけるエピックの粒度が、ストーリーと同様くらいの細かい粒度になっていました。「エピックが完了 = 新規機能利用可能」という状態ではなく管理も煩雑だったのです。
また、エピック自体の粒度も大きいため1スプリントで完了できない粒度になっていました。規模の大きい開発であるため、何が完了していて何が完了していないかが分からずチームメンバーたちも混乱していました。
例) 抽選機能開発
- 抽選商品を作成できる(エピック)
- ユーザが抽選商品を購入できる(エピック)
- 抽選を実施できる(エピック)
- 抽選結果を閲覧できる(エピック)
また、エピック内に大量のタスクが登録される結果になり、プランニング時に適切に見積もれないことにも繋がっていました。
解決策として、エピックの抽象度を上げて粒度を粗くして、それに紐づく個別の要素をストーリーとして登録するようにしました。
また、1スプリントで収まるかつリリースできる(1つの機能として独立できる)ような粒度で分解して作成することで、タスク分解や見積もりもしやすくなりました。
例) 抽選機能開発
- 抽選機能開発(エピック)
- 抽選商品を作成できる(ストーリー)
- 抽選商品を閲覧できる(ストーリー)
- ユーザが抽選商品を閲覧できる(ストーリー)
- ユーザが抽選商品を購入できる(ストーリー)
- 抽選を実施できる(ストーリー)
- 抽選結果を閲覧できる(ストーリー)
仕様が不明確なため適切に見積もれない
問題として2点ありました。
- 仕様を詰めきれていなく質問が大量に出る上にその場で答えが出ずやることが曖昧でプランニングに臨めない
- リファインメントの場で初めて内容を理解するため後に確認が発生する
開発する機能に、どのような価値があり、何ができるのかというWhy・Whatの部分に重きを置いてしまいHowの部分が詰めきれていませんでした。 そのため、仕様に関する質問が大量に発生してその場では解決できずに持ち帰ることになり見積もりもできない事態となりました。 また、メンバーがリファインメントの時点で初見であることも課題感としてはあり、その場で理解したつもりになっていたとしても後から確認が発生することでコミュニケーションコストが発生していました。
解決策として、チームでリファインメントに望むための準備する時間を確保しました。 事前にチーム内で確認することにより、あらかじめ疑問点や仕様確認することを洗い出してリファインメントを実施する前に仕様をより細かくビジネス側と握っておくようにして解決することでリファインメントの場では認識齟齬がないか最終確認することができ、プランニングに臨める状態にしました。
スプリントプランニング
適切なストーリーポイントの見積もりが難しい
プランニングではストーリーから分解したサブタスクを元にプランニングポーカーを用いてストーリーポイントを付けています。
初期であることもあり、メンバー各々が得意な領域についてはタスク分解を行った時点である程度難易度や道筋が予想が可能であるためその領域が得意なメンバー間のポイントは同じくらいになるものの、それ以外のメンバーで付けたポイントと乖離がありました。
なぜそのポイントを付けたのかを話し合い、どのような事をやる必要があるのかを共有・議論することで合ってくると思っていましたが中々ポイントが合うことがありませんでした。
解決策として、以前行ったタスクをバックエンド・フロントエンド・QAでそれぞれポイントを決めて基準を設け、これに対して上か下で判断を行いポイントを付けていきました。
基準を設けることは一定効果があり、スプリントを何回か回しポイントのズレについて対話を重ねることで安定してポイントを付けることができました。
また、ポイントがズレるということは各々の業務や機能に対する理解度に差が出ていることを示しているので議論が必要であることも経験から学びました。
デイリースクラム
課題を持ち込むことでデイリーの時間が長引く
各々が抱えている課題をデイリーの場に持ち込むことで30分、長い場合では1時間ほど掛かっていました。 ここでの課題感はタスクに関わる仕様確認などの細かい確認事項がデイリーの場で行われるかつ解決まで行っていることでした。 機能自体の仕様をそもそも知らないという業務知識が不足していることも一因にありますが、同期的なコミュニケーションであるが故、後から経緯や確定事項を追うことが出来ずに日が経つと「なぜこういう仕様になっているんだっけ…」と分からなくなったり、人によって理解している内容が違ったりと、再度確認のコミュニケーションが発生してしまうという負の連鎖が起きていました。 さらにデイリーの場で確認すれば良い。という雰囲気が出てしまい日を追う毎に時間が延びていきました。
解決策として、2点行いました。
デイリースクラムの目的を再確認
スクラムガイドには以下の記載があります。
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対す る進捗を検査し、必要に応じてスプリントバックログを適応させることである。
引用元：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
あくまでスプリントゴールに対しての進捗と調整が目的であり、タスク内の詳細部分を話す場でないということを再認識しました。
課題をデイリーの場に持ち込まない
デイリーの場に課題を持ち込まないように普段のコミュニケーション内で解決できるようにしました。 こうすることにより、課題の内容が単一地点ではなく継続される透明性を担保しつつ、これまでデイリーの場まで持ってくることで発生していたリードタイムが短くなりゴール達成に向けて動けるようになりました。 もちろん、全ての課題がという訳ではなくデイリー後に個別に時間を取ったりする運用も行っています。 今では、アイスブレイクを入れても15分以内に収まるようになってきました。
スプリントレトロスペクティブ
議論が弾まない
スプリントレトロスペクティブでは、振り返りの手法としてKPTを利用しており、Keep・Problemを上げてTryは全員で議論して決めています。 各々が発表した後、気になること・なぜそう思ったのか・深掘りたいことを問いかけても中々手が上がらない…となっていました。 その後、Tryを上げるためにピックアップしたものに対して、何となく議論をして何となくTryを決めて…と表面的な問題に対して解決しようとしてあまり納得感が無い状態でした。
解決策として、ファシリテーションを工夫しました。
出たProblemに対してグルーピングをして抽象度を上げ、問題の本質はこういうことなのではないかと仮説を立ててメンバーに投げかけました。
すると、「こういう風に思っていた・これも問題なのでは・実は前から感じていた」と意見が活発になり、対話する雰囲気も出てきたことによって議論が弾むようになりました。
また、Keepではチームとして成長していることを実感できる状態になりました。
今まで潜在的に感じていたことを仮説を立て議論することで認知に繋がったと思います。
TRYの形骸化
Tryが多く上がることは良いことではあるものの全て実施することは中々難しい上、スプリント毎に増えて行くことで追跡することも困難でした。
解決策として、優先度を決めて次のスプリントで必ず実施することのみTryとして行うようにしました。
達成可能であるとチームで決めたことになるので集中できる状態になり、次のスプリントでまた優先度を決めて実施するサイクルを繰り返すことで課題を解決しました。
スプリントレビュー
成果が測れていない
ローンチから開発側でGMVや購入数について具体的な数字について測れていませんでした。チームがこれまでどんな価値提供が出来ていたかを確認できていない状態は今後のプロダクトを自分達で考えることも出来ないと同義でした。
解決策として、スプリント内のアウトカムをまとめて共有しました。
全体のGMVや購入数などだけではなく、日毎の推移も見るようにしたところ、座席指定特有の現象が起きていることに気づきました。
例えば、人気の公演であれば発売直後に一気に購入数が伸びるがその後は一定になる。であったり、サーカスのショーなどは発売直後は穏やかではあるが公演日に近づくに連れて伸びていく。
など観察することができ、これは負荷対策が必要なパターンがどういった商品なのか等を知るきっかけになりました。
成果への承認が低い
スプリントで何が達成されたかについては確認できるものの、達成されるまでの道のりは各々の活躍があってこそです。
ですが、具体的にどんなことをやったかや苦労があったのかについてはお互いに知ることは難しく成果への承認が低い状態でした。
解決策として、ドヤ会を実施しました。
ドヤ会とは、スプリント内で「ドヤ！」って言える成果や取り組みを自身で発表して周りのメンバーから称賛する取り組みです。
どんな小さなことでも互いに称賛しあうことで、自己肯定感を上げていくことが目的で1人3分程度で行います。
実施したことで、これまで見えなかった部分も知れたり、知見の共有もできるようになりました。
おわりに
スプリントゼロを終えて実際にスプリントを回すようになってからも、改善を繰り返してチームとして成長してきていると実感できています。
しかし、まだまだチームとして伸びしろがある状態です。
これから目指していくチーム像としては、いつ誰がいなくなったとしてもチームとして価値提供のスピードを鈍化させず駆け抜けられるようにしていきたいと思っています。
そのためには属人化の排除やドメイン知識、担当範囲の拡大などをやっていく必要があるので日々成長していきたいと思います。
最後に
アソビューでは「生きるに、遊びを。」をミッションに、一緒に働くメンバーを募集しています！ご興味がありましたらお気軽にご応募いただければと思います！
