歴代のスクラムマスターがやってきた取り組みを解剖してみる

この記事は SmartHR Advent Calendar 2022 の22日目のエントリーです。

こんにちは。プロダクトエンジニア兼アジャイル推進室メンバーのshooenです。今回はアジャイル推進室メンバーとして、社内の「交代制スクラムマスター」という取り組みで歴代のスクラムマスターたちがどういうことに取り組んできたのか見ていきたいと思います。

交代制スクラムマスターとは

そもそも「交代制スクラムマスター」ってなんやねんという話ですが、ざっくり説明するとスクラムマスターのようにチームや組織を見れる・アクションを起こせる人を増やすために、スクラムマスターの役割を敢えて交代制で回す取り組みです。

詳しくは「組織のさらなるカイゼンを。SmartHRの「交代制スクラムマスター」制度のお話 - SmartHR Tech Blog」をご覧ください。

歴代のスクラムマスターはどんな取り組みをおこなってきたか

交代制スクラムマスターの取り組みが始まってから1年半以上が経ち、のべ約40名がスクラムマスターを務め、さまざまな取り組みをおこなってきました。ここでは歴代のスクラムマスターたちが取り組んできたことを独断と偏見でカテゴライズし、どういった活動がおこなわれてきたかを分析していきたいと思います。

取り組みをカテゴライズ

独断と偏見で以下のようにカテゴライズしました。

他チームのスクラムイベント見学
自チームの現状把握
開発プロセス把握・改善
スクラムイベントの改善
プロダクトバックログの改善
チームビルド
クロスファンクション化
ファシリテーション関連
完成の定義関連
モブプロ見学・改善
ビジネスサイドへの越境
etc.

カテゴリだけでも多岐にわたっていますね。中でも特によく取り組まれていたものについて詳しく見ていきましょう。

他チームのスクラムイベント見学

他チーム・FBの付箋

一番多かったのが「他チームのスクラムイベント見学」でした。特にスクラムマスターをやり始めた頃に、他チームのスクラムイベントを覗いて他チームの良いところを学びつつ自チームのGoodな点やMoreな点を客観的な視点で把握するムーブが多いです。

スクラムマスターのやり始めでなくとも、自チームで何らかのスクラムイベントがうまく機能していないときに、うまくやってそうなチームのスクラムイベントを見学しに行くケースもありました。

同期的に見学する場合もあれば、最近はほぼすべてのチームがオンラインですのでイベントを録画してもらって非同期で見ることもあります。

見学した際は学んだことを自チームに持ち帰るだけでなく、見学させてもらったチームへFBするケースが多く、受け入れ側のチームにとっても学び・発見がある取り組みとなっています。

自チームの現状把握

チームの現状把握に関する付箋

次いで「自チームの現状を把握する」動きが多く見られました。スクラムマスターチェックリストやryuzeeさんのスクラムチーム用セルフチェックリスト、SCRUMMASTER THE BOOKにある「エクササイズ：自己組織化したチーム」などを使ってチームの現状を把握するケースが多いです。こうしたチェックリストやエクササイズをやると逆説的ではありますが「こういう点を意識すると良いんだな」ということがわかり、改善をおこなっていく上で目指す方向性をチームで揃えやすいという面もあります。

他には、開発者としてではなくスクラムマスターとして自チームのスクラムイベントを一度俯瞰してみる・観察してみるといったこともおこなわれていました。スクラムマスターを担う方はいずれも各々の職能（エンジニア・QA・デザイナー・etc.）を専門とした開発者としてスクラムチームに所属していますが、開発者としてではなくスクラムマスターとして、いつもと違う視点でチームを観察することで新たな気づきを得ることができます。

まずはチームのGoodな点、Moreな点を把握して改善すべきポイントを特定し、そこから改善活動に繋げていく流れができているようですね。

開発プロセス把握・改善

開発プロセス把握・改善に関する付箋

顧客へ届ける価値を最大化するために「開発プロセスに潜むボトルネックや無駄を特定・改善していく」ムーブも多いです。中でも目立つのが「バリューストリームマップ」を作成しチーム全員でプロセスを見直す取り組みです。バリューストリームマップを使った取り組み例は「フィーチャーチームについてまとめてみた - SmartHR Tech Blog」をご覧ください。

他にはフロー効率についてチームで理解を深めたり、フィーチャー開発を始める際に解決したい課題の解像度を上げるために簡易的なカスタマージャーニーマップを作り、開発の優先度を「骨（ユーザーの課題を解決するために必ず必要）・肉（なくてもいいけどあると便利）」という基準で整理していく通称「骨肉フレームワーク」を取り入れるなどしていたチームもありました。

スクラムイベントの改善

最後はスクラムイベントを見直す動きです。やはりスクラムイベントがうまく機能していないケースは多いです。中でも「スプリントレトロスペクティブ」と「スプリントプランニング」に関する改善活動が多く見られました。

スプリントレトロスペクティブに関する取り組み

レトロスペクティブ改善に関する付箋

前提として、多くの開発チームではKPTベースでスプリントを振り返っています。よくある課題は「Problemがなかなか出ない」「Problemに対するTryがなかなか決まらず時間内に終わらない」などですね。

「Problemがなかなか出ない」課題に対してはKPTにFuan（Problemとまでは行かないけど気になったこと）を追加して気になりポイントを挙げる心理的ハードルを下げたり、「時間内に終わらない」課題に対してはProblemに対する優先度を付けて高いものだけ話す、課題解決フレームワークを使ってみるなどの取り組みが見られました。

他には「レトロのレトロ」といった、レトロそのものを振り返り課題を洗い出す会をやっているチームもありました。メタな視点でスクラムイベントを振り返るとスクラムイベント自体に感じているモヤモヤが吐き出されて気づきも多いようです。

スプリントプランニングに関する取り組み

プランニング改善に関する付箋

スプリントプランニングに関して特に多かったのは「タイムボックス＆タスクの見積もり時間の導入」です。プロダクトバックログアイテムをバックログからスプリントバックログに上げる際はベロシティを参考にしていますが、チームによっては「ベロシティが安定していない」「バーンダウンできなかったときにどのアイテムで想定より時間を要したかが不明瞭」「そもそもチームメンバーの可処分時間（タイムボックス）で処理しきれる量だったか怪しい」などのケースがよくあります。

それらを解消するために「今回のスプリントにおけるチームメンバーのタイムボックス」を最初に算出し、かつスプリントバックログアイテムにもおおよその見積もり時間を入れることで、少なくともタイムボックスを上回る量のアイテムが入らないようにしていくムーブが多く見られました。

実際にメンバーのタイムボックスを算出すると「タスクに費やせる時間てこんなに少なかったの！？」となる方が多いです。