初心者スクラムマスターが現場で学んだ3つの課題と解決策

アドベントカレンダー

スクラムマスター

前山幸太郎

2024年12月06日

この記事は「BEMA Lab Advent Calendar 2024」の6日目の記事です。

はじめに

皆さんこんにちは。
メンバーズの前山です。

今回は、僕が初めてスクラムマスターとして現場に立って感じたこと、苦しんだことと、それに対してどのようなアプローチをしたかを赤裸々にお話しようと思います。

僕がスクラムマスターを目指し始めてから約半年。
無事現場デビューを果たすことが出来ました。

とても優秀な僕は、今まで勉強した知識をチームに持ち込み、コーチングとティーチングを駆使して最高チームを作り上げました。

となる訳もなく、かなり悩み、苦しんだ１ヶ月間になりました。

勿論今でも考えることは沢山あるのですが、１ヶ月が経ち、少し道筋が見えてきたので、今回は僕のその苦悩と、やってきた事をシェアしようと思います。

※今から書くことは自分の考え、現段階での価値観なので、正解ではないですし、今後変わる可能性もあります。

苦悩1：理想と現実のギャップ！スクラムガイドとの違いに戸惑う

僕の参加させていただいたチームは、出来て半年ほど経っているチームでした。
前任のスクラムマスター（大先輩）から僕への引き継ぎという形でのスタートでした。
社内の尊敬する先輩の持っていたチームへの参加に、この先輩がやっていたチームで僕にすることあるのかなと思いつつチームに合流。
挨拶をし、しばらく観察をしていました。

あれ、プロダクトゴール無くない...?
MVPも決まってない.....?

目から鱗でした。
他にも細かいことを言えば沢山あるのですが、僕の勉強したスクラムと違うことがちょくちょく見受けられました。

僕たちの聖書、スクラムガイドには以下の記述があります。

『スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。』

やばい！！！！スクラムマスターとしての責任を果たさないと！！！！！

焦っちゃいますね。

チームの雰囲気はすごくよく、成熟していて、出来ているところはたくさんあるのに、
どうしても、出来ていないところばっかに目がいってしまい、それが焦りにつながります。

良くない良くない。

苦悩2：課題の優先順位が分からない！緊急度と重要度の判断に苦戦

例えば、チームに以下の課題があるとします。

ワーキングアグリーメントが形骸化してしまっている
プロダクトゴールがない
残業めっちゃ多い

たくさんお勉強はしたので、こういう課題があるな〜と見つけることが出来るようになったのですが、
発見した課題が
どのくらい悪影響をもたらしているか
開発の時間を削ってでも急いで取り除かないといけない課題なのか
問いかけて、時間をかけながら修正して行ってもいい課題なのか

みたいな課題との距離感が全然分らなかったです。

ここの距離感がつかめないと、全てがすごく重要かつ緊急度の高い課題に見えてきて、焦ってしまいます。
本当に良くないですね。

苦悩3：スクラムマスターという肩書のプレッシャー

チームでの自分の役割の名前はスクラムマスターです。

この記事を読んでくれているあなたに質問です。

あなたは自分で〇〇マスターと名乗ったことはありますか？

エンジニアの方なら、PHPマスター、Flutterマスター等、デザイナーの方ならUIUXマスター等、自信を持って名乗ることは出来ますか？
少なくとも、僕にはとても恐れ多いことです。

ありがたいことに、チームからスクラムやアジャイルの相談を受けることがあるのですが、その度に、あの内容はスクラムマスターとして最適な答えだったのか、もっといい解答が出来たんじゃないかと思うことが多々あります。

スクラムは不完全なフレームワークです。

スクラムマスターとして、スクラムをチームに適応していくことが出来ているのか、常に自分に問いかけています。

自信を持って”はい！”と答えられるまで、僕にはもう少し時間がかかりそうです。
そんな日が来ることを祈っています。

いつかくるであろうその日まで、スクラムマスターの名前を置いて、スクラムおじさんやアジャイルおじさんとでも読んでほしいものですね。

ここまで、新人スクラムマスターの苦悩を書かせていただきました。
（本当はあと108つくらいあるのは秘密です）
この悩みに対して、僕がやってきたことを紹介します。

やった事1：スクラムの基礎を座学で再確認

知は力なり
やっぱり先人の知恵を借りることは何よりの近道の可能性が高いです。
今までも勿論勉強はしてきたのですが、一つ一つのスクラムイベント、その思想等、より深く勉強をしました。
（定番ですが、Ryuzeeさんの記事が特に参考になりました。）

このイベントは、何のためにあるのか、どう開発に影響をもたらすのか、このイベントがないとどうなるのか、今見ているチームはこれがどのくらい出来ているか、一つ一つの事柄を自分なりに落とし込み、自分の言葉で説明できるようにしました。

また、一つのことにいくつか解釈があることに関しては、こういう考えやこういう考えはあるけど、僕はこれ派かなぁと、洗い出しと自分の好みまで把握をしました。

実際のチームの状況と、知識をしっかりと照らし合わせ、自分なりの解釈をもつ（それが全てではない）と、少しずつ焦りが取れてきたように感じます。

課題自体や、課題との距離感が少しずつ見え始めてきた気がします。（気がするだけかもしれない）

特に認識が変わったのは、”課題を解決するのは自分ではない”ということです。
自分は今まで、チームに課題があったら、スクラムマスターとして”解決に導かないといけない”と思い込んでいました。

スクラムガイドには以下の記述があります。

“スクラムチームの進捗を妨げる障害物を排除するように働きかける”

ここにはスクラムマスターは障害物を”排除する”のではなく、排除するように”働きかける”ことが求められていると書いてあります。

この認識が変わったのも、焦りが取れた大きな要因です。

やった事2：ベテランスクラムマスターとの対話で視野を広げる

前回の記事でも述べたように、自分の周りにはベテランのスクラムマスターが複数人います。
そして幸せなことに、その全員が快く相談に乗ってくれます。

チームのこと、スクラムのこと、アジャイルのこと、そもそもいい状態って何？みたいなことを沢山相談させてもらいました。
1on1がメインでしたが、たまには全員で、僕が疑問に感じたことに対して、みんなで議論することもありました。

みんなでスクラムガイドを読み、色々な観点の解釈を聞けるのは本当にありがたかったです。
一つの議題について、みんなで議論することで、また、色々なスクラムマスターの意見を聞くことで、絶対の正解なんてないんだ、正解に近いものをチームのみんなと一緒に探していけるようにすればいいんだということを改めて認識させられました。

プロダクトゴールやMVPが決まっていない状況も、チームが色々模索した結果なのだと捉え直すことができ、当時の自分はスクラムガイドに囚われすぎていたなと思いました。

また、自分が悩んでいるようなことは、僕だけではなく、みんなも同じように悩んだり、過去に困難に感じているのだと知れただけでも心が軽くなりました。