スクラムマスターに挑戦したので大反省会をする

はじめに

Livesense Advent Calendar 9日目です。

今年に入ってから半年ほどスクラムマスターに挑戦しました。
スクラムマスターとしてうまく立ち回れなかったなあという印象なので、これを機に振り返りをしておこうかと思います。

内容としてはかなり個人的な反省となるので一般的ではないことも多々あるかもしれませんが、こんな状態になる人もいるんだなあと参考程度にみていただければと思います。

スクラムマスターになった当初の状態

年初に新しいプロジェクトが立ち上がりスクラムマスターになった当初の自分の知識レベルなどはこんな感じでした。

• このプロジェクトが始まる以前のプロジェクトでスクラム開発に取り組んだことがある
• scrum bootcampを読んだことはある
• チーム作りに興味がある

といったゆるふわな感じでスクラム開発のプロセスを知っていて、チーム作りにどう活かしていけるんだろうという興味を持った状態でした。

今だから思う反省すべきと思うこと

ゆるふわな感じでスクラムマスターという役割を引き受けてしまったため、当然うまくいかないことは多々ありました。

その中でも特に良くなかったと思うことをまとめていきたいと思います。

役割の兼任（スクラムマスター + 開発チーム)

自分の役割としてはスクラムマスターだけではなく開発チームの一員でもありました。（スクラムガイド2020年版だと開発チームではなく開発者となったようですね）

この役割の兼任はとても難しいものでした。
特に初心者スクラムマスターはやるべきではないと感じました。¹

『スクラム現場ガイド』にもスクラムマスターと開発チームの兼任は望ましくはないという記載があります。

チームメンバーとスクラムマスターを混ぜるのなら、無害にみえるが、それでも課題はあり、理想的と言えないのには変わりない。

（中略）

2つの役割を混ぜると、スクラムマスターは大きな問題をチームと同じ視点で捉えるようになってしまい、チーム全体を高みへ持ち上げるという仕事ができなくなってしまう

『スクラムマスターは大きな問題をチームと同じ視点で捉えるようになってしまい、チーム全体を高みへ持ち上げるという仕事ができなくなってしまう』の部分は実際に自分自身もこの状態になっていました。

これは個人的な話なのですが、目の前の開発に集中した方がプロジェクトが前に進む気もするし、何より開発者としての働き方の方が勝手がわかるので気がつくと開発者として働いてしまっているという状態になっていたと考えてます。

とはいえチームの状態を把握したり、開発プロセスを改善したりといった仕事も重要だという意識はあったので我に帰ったようにスクラムマスターとして振る舞おうとすることもありました。

ただスクラムマスターとして振る舞うも、その振る舞いがスクラムマスターとして振る舞っているのか、課題を解決したい一開発者としての振る舞いなのかが自分の中でわからなくなってくるという状態となっていました。

その結果、

1. チームの状態をよくしようとしてもあまり改善できない
2. スクラムマスターをこなせていないと感じる
3. 開発者として成果を出そうとする
4. 我に帰ってスクラムマスターの振る舞いをしていかないといけない気持ちになる
5. 1に戻る

という負のループに入ってしまっていました。

幸いチームメンバーに優秀な人が多く、なんとかやりやすい開発のやり方やコミュニケーションのやり方を見つけプロジェクト自体は無事リリースまで漕ぎ着けることはできたのは幸いでした。

スクラムに関する知識不足

スクラムに関する知識武装があまりできていない状態でスクラムマスターとして動き始めたので、スクラムの進め方で疑問が出た時にどこに進めば良いかの旗振りができていませんでした。

そのためプロジェクト序盤はスクラムイベントのたびに

• プロダクトバックログとスプリントバックログをどう作るのか
• プロダクトバックログアイテムの粒度はどうすればいいか
• 設計を固めるための調査などはどうすればいいか
• 見積もりのポイントはどういう基準でつけるか

などなど

スクラムイベントの中でいつの間にかスクラム議論が始まり、時間を使ってしまうということが多くありました。

時間を使ってはしまいましたが色々と議論したりすることで自分たちのやりやすい開発の進め方が徐々に見つかっていき、プロジェクト後半にはスクラムイベントやスプリントがスムーズに進むようになったのは不幸中の幸いだったと思います。

プロジェクト開始当初はスクラムの知識よりもチームの雰囲気が良い状態にする方が重要だと考えてしまっていて安易なチームビルディング²のようなことをやっていました。
今になって考えると安易なチームビルディングやっていた時間を使ってチームのスクラムの認識を揃える会などやるべきだったと反省しています。

いくらチームの雰囲気を気にしてもスクラムの進め方がわからない状態でスクラム議論がチーム内で発生すると簡単に不穏な雰囲気が生まれるという学びを得ました。

開発チームだけで先走ってしまった

スクラムマスターと開発者を兼任していたことにも繋がる部分です。

できるだけ早く動くものを作ってリリースして試したいという気持ちありました。
とりあえず必要そうな物を開発していこうという流れを作ってしまいプロダクトバックログが揃っていない状態で手を動かす方向に開発チームをミスリードしてしまいました。

プロダクトバックログアイテムが出し切れていない状態で先走ってしまったため、プロダクトオーナーとの足並みが揃わなくなってしまいお互いに何をどこまで検討しているのかが見えない状態が出来上がってしまいました。

1. 開発チームだけで仕様や機能を考える
2. プロダクトオーナーに考えた仕様や機能でよいのか伺いを立てる
3. よさそうであればPBI化してもらう

のような流れで開発を進めるようになってしまいプロダクトオーナーをお客様と見立てるようなチームになってしまっていたと考えています。

その結果、プロダクトオーナーには開発チームにどのようなコミュニケーションをとるべきか迷わせてしまいました。
開発チーム内でも仕様検討時にビジネス要件を加味した判断ができず、検討が前に進まないというような状態になってしまっていました。

プロジェクトが始まって1ヶ月ほど過ぎようとしていたところで、ようやくチームの状態とても悪いのでは？と気づきました。

そこからの対応としては

• チームメンバーと1on1をして現状をどう思うかヒアリング
• スクラムチーム全員でコミュニケーションの取り方について考えるイベントを開催

のような動きをして少しでもスクラムチームで足並みを揃えられるようにしていきました。

開発者として動いているとチーム全体の健康状態が悪いのは薄々感じつつ、目の前のことに目が向いてしまうためコミュニケーションなどのチームの健康状態のような問題を軽視してしまっていたのだと思います。

たまに我に帰ったようにスクラムマスターとしての役割を思い出すみたいな形で動いてしまっていたので足並み揃っていないことに関する対応が遅くなったのではないかと反省しています。

またスクラムマスターやるならどうするか

色々と失敗が多かったスクラムマスター活動でしたが、その分、次やるならどうするかというネタも考えることができ学びは大きな体験だったと思います。

その中で次やるならどうしたいかをいくつか紹介していきたいと思います。

スクラムマスターに専念する

自分の感覚としてはこれに尽きるのではないかなというぐらいのポイントかもしれません。

開発の手が多い方がプロジェクトの進行早くできそうだし、スクラムマスター の仕事だけだと手が余りそうだから開発者も兼任した方が効率が良さそうだと思っていた時期もありました。

ただロールを兼任をしてしまうとスクラムマスターとしての振る舞いをするための難易度が上がり、スクラムマスターとして機能しづらくなるという大きめな副作用があるということを今回の経験を通して学びました。³

『エッセンシャルスクラム』のスクラムマスターの説明に以下のような記載があります。

スポーツチームのコーチのように、スクラムマスターはチームがどのようにスクラムを使用しているかを観察し、次のレベルのパフォーマンスに到達できるようにあらゆる手を尽くす。

スクラムマスターの役割はスクラムチームを成長させることで問題を解決することではないのだと思います。

それに対して開発者は問題を解決して開発を前に進めることが役割になります。

そのため開発者 + スクラムマスターの兼任となると問題を解決すべきなのか、はたまたチームをサポートするべきなのかという迷いが生じてしまいどっちつかずな対応をしてしまうのかもしれないと思いました。（もしくはスクラムマスターの役割を忘れ、いつの間にかなっていて問題解決をしてしまう）⁴

スクラムマスターに専念することで上記のような迷いを払拭できチームを成長させることに意識を向けることができ、ロールを兼任して開発者として手を動かすこと以上の効率や成果を出せる可能性があるのではないかと考えています。

早い段階でスクラムチームにスクラム知識を身に付けてもらう

スクラムマスターとしての役目の一つとして『スクラムの価値、原則、プラクティスがみんなに正しく理解され、受け入れられるようにする』というものがあります。

自分はこの役目を疎かにしてしまったため、スクラムチームに『スクラムとは？』、『スクラムではどう考える？』などの混乱を生じさせてしまったのだと考えています。

改めてスクラムマスターをやるのであればプロジェクト序盤の手を動かす前からスクラムについての学習を行うイベントを定期的に開催していく必要があると考えています。

やることとしては

• チームで共通のスクラムに関する書籍やスクラムガイドを輪読
• 内容について議論
• 自分たちのスクラムチームならどうするかの方針を固めていく

のような活動ができると良いのかなと思います。

そうすることでスクラム開発に関しての混乱を減少させ、プロジェクトの進め方の共通認識を作っていくことができると思います。

またスクラムマスターになりたてでスクラム知識が薄いと自覚できるのであれば、外部でも内部でもスクラムに詳しい方に頼っていくべきだと感じました。

自分でイメージできていないことをあやふやに伝えてしまうとチームを混乱させてしまうばかりではなく、スクラムマスターとしての信頼も失われていきます。

わからないことはわからないと認め、適切な人に力を借りるというのも重要な仕事です。（よく考えたらスクラムマスターに限らず社会人としての話でもありますね...)

そして何よりスクラムマスターになるということが分かった時点でスクラム知識を身につける学習をきちんと行おうねということですね...(反省)

プロダクトバックログを取り揃える

プロジェクト始まってふんわり作るもののイメージはありつつ、何から始めればいいか、何が整理されていないのかがチームの共通認識として作れていなかったのが反省でした。

なのでもし次スクラムをやるならプロダクトバックログを荒い粒度でもいいのでプロジェクトで目指すところまで出し切ります。

プロダクトバックログが揃っていない状態で開発だけすすめてしまうと自分たちはどこまで進んだのか、後どれくらい進まなければいけないのかの見通しが立たなくなってしまうと感じました。

プロジェクト終了までにどのようなプロダクトバックログアイテムが必要か見当がつかない場合もあるかと思います。

その場合はインセプションデッキを作るなどして、プロジェクトの目指すべき方向をチーム全員で把握して、その方向を目指すために何が必要かを洗い出していくべきだと思います。

その上で達成するための最小限を考え抜いて、その最小限を作るために必要なことを洗い出していくことで必要なプロダクトバックログアイテムが出てくるのではないかなと考えています。

そこまで作ることができればチームとして何をやるべきかが明確になってきて、それを達成するための動きができるのではないかと思います。

反省まとめ

他にも反省したいことはやまほどあるのですが、言語化しておきたい部分は書き連ねたと思います。

あらためて書いた内容を眺めて思うところとしてはスクラムマスターとして以下の状態ができるようにチームを支援することが重要なのかなと思いました。

• プロジェクトを進めていくために目指す共通の目標をチームで捉えること
• チーム内での密なコミュニケーションを取れるようにすること

結局コミュニケーションでチーム内で遠慮なく目的に向かうために必要な意見を言い合える状態を作っていくことがチームとして重要なのではないかなと感じました。

---

うまく行かなかった話をつらつらとしてしまっているので、スクラム微妙なのか？という印象を持たれてしまう方もいるかもしれません。

ただそんなことはなくて、この話はうまくスクラムをできなかったという話です。

スプリントをまわして一定のタイミングでスクラムイベントを実施することで開発のリズムを作ることができましたし、振り返りを行って開発の改善ポイントを見つけて改善していくことでスプリントの正確さが上がってきたりもしました。

実際スクラム開発を進めたことでプロジェクトを完遂することもできています。

もしもっとうまくスクラムを回せていたら、もっと成果を出せるチームになれていたのではないか感じたので、スクラム開発のポテンシャルはかなり高いなと思いました。

完全にただの個人の反省となってしまいましたが、こんな事例もあるんだなあと参考にしていただければですm(_ _)m

---

1. スクラムマスターの振る舞いがわからない状態で兼任してしまうと、開発者としての振る舞いもスクラムマスターの役割だと勘違いしてしまいそうだと感じました ↩

2. 自分の弱みを共有とか一緒にゲームするとかクソぬるいことやっていました...心理的安全性とぬるま湯を履き違えていました... ↩

3. 少なくとも自分のようなスクラムマスター初心者はというニュアンスです。役割を切り替えるのがうまかったり、スクラムマスターとしての経験が豊富な方であれば勘所を掴んでいてうまく立ち回れるのではないかと考えています。 ↩

4. スクラムマスターと開発者を兼任しなければいけない状況であれば、問題が発生した際はスクラムマスターとしての立場をとることをチームと合意を取っておくとやりやすさが出る可能性はある気がしています ↩