スクラムマスターのいないスクラムチームへの挑戦
この記事は、Magic Moment Advent Calendar 2023 6 日目の記事です。
はじめに
こんにちは。株式会社 Magic Moment で VPoE をしている 清家 (@wakazooo )です。
弊社では、2022 年 9 月頃から、各チームのスクラムチーム化に取り組んできました。2023 年 12 月時点で、6 つチームがあり、うち 3 つがスクラムチームとして動いています。
私はその 3 つのチームのうちの 1 つ（外部サービスとの連携を担うチーム）で EM を担っているのですが、今年の 5 月頃より、スクラムマスターのいないスクラムチームを目指して試行錯誤してきました。本記事では、その過程と現状についてお伝えできればと思います。
なぜ、スクラムチーム化したのか
スクラムチーム化に取り組む前は、機能開発の企画起点で組成されるプロジェクトチームに所属してロードマップの実現に取り組みつつ、マイクロサービスごとに区切ったサービスチームにも所属して、運用保守をしていました。
エンジニア数名、プロダクトマネージャー、デザイナーも 1 名ずつという体制であれば問題なかったのですが、エンジニアが 10 名を超えたころから、属人化が進み、加えてオンボーディングもうまく行かないという負のループに入り始めていました。
そういった状況を打開し、チーム・個人が「自律」できる状態を目指すために取り組んだのがスクラムチーム化でした。
このあたりは、 Wantedly のインタビュー記事 で詳しく振り返っているので、是非読んでみてください。
スクラムチーム化して半年経過して、なにが起きたか
ここからは、私が EM として関与しているチームに関する話です。
スクラムチーム化に取り組み始めて半年を経過した頃、EM 兼 スクラムマスター だった私は、以下のようなことを考えていました。
EM な私：「技術的難易度の高いプロジェクトもなんとかリリースし、新しく入った人も早速コミットしている。チームの地力がついてきたな」
スクラムマスター な私：「Daily が進捗確認になってるな・・・チケットで何やってるのかは聞かないとわからないことが多いし、チーム全体のことを把握できているの、私だけなんじゃないか・・・」
つまり、チームのケイパビリティ拡大を実感しつつも、そのケイパビリティを活かした出力ができるかどうかが自分に依存してしまっている状態でした。
※ 「技術的難易度の高いプロジェクト」については、同じチームの TL である Miyake が Advent Calendar 5 日目の記事にしています！
なぜスクラムマスターのいないチームを目指したのか
2020年版のスクラムガイド のスクラムマスターの役割に、以下のような記載があります。
スクラムチームの進捗を妨げる障害物を排除するように働きかける。
「進捗を妨げる障害物を排除する」とは具体的にはどういうことでしょうか。
当時の私の見解は
チームがかかえる様々なタスクの優先順位を明確にし、各エンジニアが取り掛かるべきタスクに集中できるようにすること
でした。
しかし、この考え方は「エンジニアをタスクに埋没させ、スプリントゴールや顧客課題について考える機会を奪っている」ということに気づいたのです。
この状況から脱却するために、 スクラムマスターのいないチームへの挑戦が始まりました。
どちらかというと、スプリントを中心としたスクラムイベントに EM が介入しない状態を目指した、という方が正しいかもしれません。
スクラムマスターのいないチームを目指し、なにをしたのか
各イベントの型はある程度決まっていたので、どうやって各メンバーが考える機会を持つか、がポイントと考えました。
Daily Scrum を輪番制にする
最初に取り組んだのが、Daily Scrum を輪番制にすることでした。やることとしては以下の 2 つ。
- アジェンダ準備
- 私たちのチームの Daily Scrum では、曜日ごとにアジェンダが変わります（リリース準備やその他アナウンスなど、毎日ではないけど定期的に必要なアジェンダがあるため、曜日ごとに変えています）
- アジェンダを準備することで、Daily Scrum で何を話題としているのかがわかるようになります
- Facilitation
- 15 min というタイムボックスを守るというのは、スクラムマスターという誰かが意識すれば成立するものではありません
- タイムボックスを守る、という意識は、Facilitation をして初めて身につく感覚だと思います。
この取り組みで生じた一番大きな変化は、Daily Scrum のタイムボックスを守れるようになったことでした。
Sprint ごとにオーナーを決める
Daily Scrum をチーム全体で運用できるようになってきたタイミングで次に取り組んだのは、 Sprint のオーナー制でした。
Daily Scrum を輪番制にしても解消できないのが
- チームはゴールに向かっているのか？
- そのゴールは顧客の課題に結びついているのか？
という観点です。Daily Scrum と違い、抽象度の高いテーマを取り扱う役割のため、以下のような責務を定めました。
- Sprint を円滑にスタートし、振り返りをもって締めくくる
- Sprint Planning の準備、Facilitate
- Sprint Retrospective の準備、Facilitate
- スクラムチームが、日々ゴールに向かって進んでいるかを監視
- Velocity をチェックして、達成できないゴールがあれば、アラートを上げる
まだ取り組みを始めて 2 ヶ月程度経過（ 2 週間スプリントを 5 回実施）したタイミングではありますが、一番大きな変化は Sprint の範囲を超えたゴールや顧客課題についての議論が増えたことだと感じています。
まとめ
この記事では、Magic Moment におけるスクラムへの取り組みについて、背景とあわせてご紹介しました。
- スクラムチーム化へのきっかけは、チーム規模拡大に伴い属人化や離脱率の悪化など、課題が噴出したこと（一言で言えば、全体の空気が悪かった）
- 取り組みから半年が経過して次に直面した課題は、エンジニアがタスクに埋没してしまっていること（ゴールとか、顧客課題とかを考える機会が少ない）
- 自律したチームを目指し、スクラムマスターの役割の一部であるスクラムイベントを、チームメンバーでの持ち回りにしてみたら、いくつか良い変化を生み出せた
最後に
EM 兼 スクラムマスター というのはよくあるパターンだと思いますが、EM という性質上、スプリントだけではなくロードマップの先を見てしまい、「タスクを振る」という考え方でチームの自律性を奪ってしまいがちです。
大事なことは、チームが自律して顧客価値や課題に向き合っていること。 スクラムマスターという役割を特定の個人がもたない、というのは、自律したチームの実現に向けて選択した 1 つのやり方でした。
私達のチームがこの後どう変化していくのか。興味を持っていただける方は是非、お話しましょう！
弊社 Magic Moment では、フロントエンド・バックエンドにかかわらず全方位的にエンジニアを募集中です！ Magic Moment に少しでも興味を持っていただけたら是非エントリーください！
明日のアドベントカレンダーは 山下 さんの「コア機能のリファクタリングで取り組んだこと」です。
Discussion