Safie Engineers' Blog!

Safieのエンジニアが書くブログです

スクラムマスターとしての挑戦:1年間の試行錯誤と学び

この記事はSafie Engineers' Blog! Advent Calendar 17日目の記事です

はじめに

こんにちは、第1開発部でサーバーサイドエンジニアをしている伊東公平です。今回は、昨年の11月から今日まで1年以上に渡って、スクラムマスターとしてチームの改善のために試行錯誤してきた内容についてお伝えします。

課題

私がスクラムマスターとして就任した際にはすでにチームでスクラム開発を採用していました。しかし、その中での課題はまだ多くありました。その中でも私個人としては、以下のようなものに改善するメリットがあると感じていました。

課題①: スプリントゴールが不明瞭で、スプリントの途中で現時点の進捗を把握する手段が少ない。そのため、チームとしての目的意識が保ちづらい

課題②: タスクの背景理解ができていないままタスクをとり、実装することで仕様とのズレが生じ、手戻りが発生しやすくなる

課題③: 使用しているツールがバラバラで、ツール間の連携がうまく取れていないため、ツールの管理や移行に時間がかかる

取り組んだこと

上記のような課題を感じていた中で、これに対処するために大きな取り組みとして以下のようなことを1年に渡り行ってきました。この3つの取り組みに対し、それぞれの目的と効果について以降では説明していきたいと思います。

スクラムの基盤づくり

スクラムマスターとして最初に取り組んだのは、チーム内でのスクラムに対する認識やルールを整えることでした。これは先に挙げた課題①を解決するために行いました。

  • スクラムイベントの開催日時を見直し固定化

当初、スクラムイベントが開催される日時が非効率な点がいくつかありました。

例えば、スプリントの切り替わりで半日時間が空いてしまうため、スプリント間の連続性がなくなっていたというようなものです。

そのため、以下のようにスプリントの振り返りとプランニング間での連続性を持たせるようにスプリントのスケジュールを見直しました。特にスプリントの振り返りとプランニングは振り返りを行ったことを即座にプランニングで反映できるようにすることを意識しました。

  • 定量的に現在の進捗を計測

チーム内でスプリントの途中でも現在の進捗を定量的に確認できるように、以下のようなバーンダウンチャートを作成しました。これにより、進捗が遅れている場合は朝会でそれを確認できるようになり、振り返りの際にその原因をチームで会話できる体制を整えました。

上記の2点の取り組みにより、スプリントの区切りがはっきりし、進捗も明らかになり、いつまでにスプリントゴールを達成するといった意識がより強くなったと考えています。

チームの強化

次にチーム内で取り組んだのは強いチーム作りです。私の中の定義としては、「一人一人が自律し、スプリントでのタスクを消化できるような状態」を目指すために行いました。

これは課題②の解決にもなると考え行いました。

具体的には、プランニングの際に以下のようなユーザーストーリーを作成するようにしました。

ユーザーストーリーとは、エンドユーザー目線から必要な機能をタスクに分解していく手法です。青枠がサービスの機能でそれを黄色枠部分のユーザーストーリー、さらにその下のタスクまで分解する作業をチームメンバー全員で行うようにしました。

ユーザーストーリーを作成することで、タスクの背景を重点的に説明する機会が増え、チーム全員が以前より背景を理解した上でタスクの消化を行うことができるようになりました。また、タスクを作成する際の属人化を避けられるようになり、チームメンバーの誰でもタスクを作成できるという意識づけもできたと考えています。

適切なツールへの移行

最後に、スクラムイベントを行うにあたり、私のチームで使用しているツールを使用方法や現状のチームに合わせていくつか移行してきましたので、その紹介をしたいと思います。

これは、課題③でもあったように、複数ツールを使用することにより、ツール間の連携が取りづらく、タスク管理が二重になってしまっていたり、うまくそのツールを有効活用できていなかったため、この負を解決するために移行しました。

以下に改善前の使用ツールと改善後の使用ツールの一覧を載せます。

種類 改善前 改善後
プロダクトバックログ Miro GitHub Projects
スプリントバックログ Backlog GitHub Projects
振り返り Jamboard Miro

上記の移行により、最も効果が現れたのは、プロダクトバックログとスプリントバックログ

をGitHub Projectsへ移行したことでした。以下のように、同じツールを使用することで二重管理から解放され、プルリクエストとの紐付け等も行いやすくなりました。

プロダクトバックログ

スプリントバックログ

最後に

今回のブログでは、この一年間に渡ってスクラムマスターとして自分のチームをどのように変革してきたのかを紹介しました。ここでは紹介しなかった変革も沢山ありますし、失敗したものもいくつもありますが、全て挑戦して良かったと思っています。

また、今回紹介した内容が全てのチームに当てはまるわけではないので、参考にされる場合も「そんな考え方があるのかと」と思うぐらいで軽く考え、自チームにあった方法に改善して活用していただけると嬉しいです。

© Safie Inc.