Tabelog Tech Blog

食べログの開発者による技術ブログです

スクラム開発のメリット 〜食べログノートUIUXチームでスクラム開発を初経験して〜

この記事は 食べログアドベントカレンダー2022 の22日目の記事です🎅🎄

こんにちわ。サーバーサイドエンジニアの@redpineです。

食べログシステム本部 飲食店システム開発部 予約サービスチームに所属しており、食べログの予約システムを担当して3年になりました。 予約システムに関しては紹介記事が投稿されているので、ぜひご覧ください!

今年に入りチーム体制が変更になり、私はスクラム開発を行う食べログノートUIUXチームを兼任することになりました。 今までのチームではリーダーから要件定義の完了したタスクの説明を受け、設計・実装を行いリリースが完了したら次のタスクへといった開発手法を取っていました。 チームもサーバーサイドエンジニアのみで構成されていたので、他職種に依頼が必要な内容の場合は別途やり取りを進める必要がありました。
スクラム開発ではタスクの受け渡しの方法からチームメンバーの構成まで今までのチームと違っていて体制変更に不安もありましたが、半年間開発を進めるにつれて「スクラム開発っていいな」と感じる場面が増えてきました。

こちらの記事では、スクラムを経験して見えてきたメリットについて書きたいと思います。

食べログノートって?

2022年春にリリースされた予約管理台帳です。

ネット予約だけでなく、電話予約、他社ネット予約、ウォークイン予約をまとめて管理することができます。 最近では他社台帳との連携も開始され、より使いやすい台帳に向かって日々開発しています。

店舗さま向けの紹介:食べログノートとは

食べログノートUIUXチームって?

食べログノートUIUXチームは企画、エンジニア(FE, BE, APP)、デザイナーが所属している機能横断型チームです。 食べログノートのUIUXに焦点を当て、店舗さまの日々の業務での使いやすさの向上を目指しています。
スプリントの長さを1週間としたスクラムを組んで開発を行っています。

会議体

  • デイリースクラム
    毎朝15分で実施しています。 その日に取り組み予定のタスクの進捗確認、リリース確認、相談を行っています。 スプリントごとに担当を割り振ってチームメンバーが持ち回りで司会を担当しています。

  • プロダクトバックログリファインメント
    バックログからタスクの内容を整理して、実現する内容、優先度、見積もりを整理します。1時間程度で実施しています。 バックログが貯まってきたタイミングで開催していて、現在だと週に1度ぐらいの頻度になっています。
    バックログはAsanaで管理をしています。

  • スプリントプランニング
    次のスプリントで取り組むタスクの決定を行います。また、今週完了したタスクの確認、リリース日の調整も行います。 司会は来週のスプリントのデイリースクラム担当が行います。
    タスク管理はAsanaを使用しています。

  • 振り返り
    1週間のスプリント内で、よかった箇所と改善したい箇所を洗い出し来週のスプリントに向けて振り返りを行います。
    振り返り用のツールとしてMiroを使用していて、付箋を使って項目の洗い出しと分類を行なっています。

  • デモ会
    そのスプリント内の成果物をチームメンバーに共有する時間です。 自身の担当領域に関わらず、気になった箇所に関しては質問してチームのアウトプットのブラッシュアップを行います。

スクラム開発を経験して感じたメリット

スクラム開発を経験してたくさんメリットを感じることができましたが、その中でも私が特に良かったと感じたメリットを4つ紹介します。

作業の認識齟齬を減らせる

食べログノートUIUXチームで作業が完結するので、誰に聞けば良いのかが明確になってコミュニケーションが取りやすいです。 他チームに依頼となると問い合わせ先が決まっていたり、前提からの説明が必要となったりと色々気にすることがありますが、要件定義から同じチームでやりとりを進めるので、希望や条件を互いに把握できている状態からやりとりができることはよかったです。
後述するチームが相談/質問が実施しやすい環境であるということもあり、密にやりとりを進められています。 デモ会でリリース物に関して質問する場もあるので、機能に対する共通認識ができてくるのも認識齟齬が減っている要因だと思います。

認識齟齬が減ったことにより、リリース前に指摘が入り修正する機会も減り、チームの開発スピードが上がりました。
また、やりたいことに対する確認が取れている状況なので、より良くするための意見等も多く出るようになりリリース物の質の向上にも繋がっています。

チームメンバーと話す機会が増える

スクラムでは会議が多いので会話をする機会が多いので、メンバーとのやりとりするための下地が生成されやすいかと思います。
また、振り返り等で絵文字を使ってリアクションを表現している人がいて、元いたチームではあまり見ない表現で新鮮でした。 職種を跨いだチームに所属していることで、予約サービスチームとは違う雰囲気に触れられたことは良かったと感じています。
チーム外の人からも食べログノートUIUXチームは雰囲気が良いと評価されているので、他職種の混ざったスクラムチームの良さであるかなと思います。

チームメンバーとのコミュニケーションの障壁が下がっているので、小さな相談や確認の頻度が高くなり認識齟齬軽減にも良い影響があります。 特に職種を跨いだやりとりのスピードが今までと段違いで進められるようになり、その辺りのリードタイムは短縮されてスムーズな開発を進められています。

チームの状況が見えやすい

プロダクトバックログにやるべきタスクがまとまっており、どういうタスクがあるのかが全体像が把握できる状態になりました。 自身のタスクがどういう優先度で作業することになっているのか、関係者は誰かも把握した上でタスクに取り組むことができるので、開発作業を進めやすかったです。
以前のリーダーからタスクを説明されて終われば新しいタスクという形であると、どうしても何のためのタスクなのか、次がどうなっているかが見えにくく行動しにくいことがありました。 全体像が見えていると今の作業内容で良いかどうの視点で判断ができるので、仕事を進める上での行動の起こしやすさに直結していると思います。 私は以前に比べ要件や実装内容に関して改善相談などを積極的に行おうというマインドになりました。

チーム改善が早い

週ごとにスプリントの振り返りを行っているので改善案を考える頻度が今までに比べて高いです。 短い間隔での振り返りなので、記憶も新しい状態で濃い振り返りができました。
また、毎週振り返りがあることで先週の改善策が実施できているかも確認できるので、放ったらかしにならない状態になっているのも良かったです。 振り返りでは絵文字を使ったリアクション等もあり、褒めの場としても機能しており、チームコミュニケーションの円滑化にも繋がっていると思います。 そういった状況下であるので、チーム全体がよくしていこうという動きが見えることでさらにチーム改善が促進されている気もします。

見えてきた工夫が必要な箇所

たくさんメリットを感じることができたスクラム開発ですが、運用してみて工夫が必要な箇所も見えてきました。 チームによって工夫が必要な箇所は様々であると思いますが、チームでスクラム開発を回すために工夫した箇所について紹介します。

会議に時間がとられがち

発足当初はリファインメントなどスクラム開発を始動するための会議の頻度が多かったため、会議に時間を割かれ実装の時間がとりにくいという状況でした。 解決策としては一時期だけリファインメントをガッツリと行い、着手できるタスクを用意し定期的なリファインメントの頻度を落としました。
緊急で着手したいタスクが出た場合など、タスク優先度によっては追加でリファインメントを実施するなど柔軟に対応しています。 今では会議に時間が取られすぎることがなく、実装の時間が取りやすい状況になりました。
定期的な会議でスプリント内の作業が埋まらないように、実装と会議のバランスの調整は必要だと思います。

大規模タスクの管理

プロジェクトのような実装工数が大きいタスクをチームで担当することがありましたが、他のタスク同様にスプリントに落とし込んで作業を進めるとタスク全体の状況が分かりにくいといった状況になってしまいました。
スプリントにタスクを割り振ることは、誰が何を担当しているかを明確にするという観点では良かったのですが、プロジェクト管理の観点では全体像が見えにくいという欠点があります。 対応としては、プロジェクト管理用のAsanaを作成し、プロジェクトの状況管理とスプリントごとのタスク管理を分けました。
スプリント内で管理できるタスクばかりではないため、プロジェクトのような工数の大きいタスクなどは管理方法を検討する余地がありそうです。

まとめ

スクラム開発は色々と守るべき内容が多く、やっていけるか当時は不安でしたが続けていくことで重要な箇所に気づくこともできました。

まとめると、スクラム開発を経験して以下4つのメリットを実感できました。

  • 作業の認識齟齬が減る
  • チームメンバーと話す機会が増える
  • チームの状況が見えているので、動きやすくなる
  • チーム改善が早い

特にお互いの状況が把握でき、コミュニケーションが取りやすい環境というのは仕事がやりやすく、それによって開発スピードが上がり、より良いアウトプットに繋がっていると思います。
スクラム開発には価値基準がいくつかありますが、個人的にはこの部分が重要ではないかと考えています。

一方でスクラム開発を進めるにあたり、以下のような工夫が必要な内容も見つかりました。

  • 会議に時間が取られがち
  • 大規模タスクの管理

スクラム開発は多くのメリットを感じることができましたが、必ずしもチームに合っているかは分かりません。 チームの状況やタスクの状況によってスクラム開発の進め方を工夫することで、チームにあったスクラム開発の形が見つかりより良いスクラムチームとなっていくと思います。

今回の記事の内容が何かの参考になれば幸いです。

おわりに

食べログノートUIUXチームで食べログノートを開発いただける方を募集しています。

気になった方は是非チェックしてみてください!

明日は @hagevvashi の「社内に閉じこもっていたエンジニアが社外エンジニアコミュニティに参加するためにやったこと」です。お楽しみに!