10年選手のエンジニア、スクラムマスター研修で衝撃を受け、メンバーに信託する話。あるいはオクラとボーイスカウトルールの話
初めまして。
コミューン株式会社のyama_sitterです。
2021/11に実施されたスクラムマスター研修を経て、晴れて「認定スクラムマスター」になることができました。
今回はその研修で得た大いなる学び、またその学びを生かしてメンバーを信頼したことと、その結果について書きたいと思います。
自己紹介
「企業とユーザーが融け合う社会を実現する」会社、コミューン株式会社の開発部でWebエンジニア（現：スクラムマスター）をしています。
"死なないで済むスキルが欲しいからエンジニアを目指す" という志の低いところから私のエンジニア人生が始まりましたが、気付けばエンジニアになって10年弱も経過していました。
今はReact（Next.js）、Nodeをメインに触っていますが、これからはスクラムマスターとしての活動がメインになると考えています。
ちなみに私の務めるコミューン株式会社ですが、↓の会社説明資料を見てもらうと理解しやすいかと思います。
スクラムマスター研修とは
Scrum Allianceの認定スクラムマスターになるために必要な研修です。
日本だとodd-e様などが研修を実施しています。
研修を受けないと認定スクラムマスターになるための試験を受けることができません。
また研修費用が30万以上と高いので、受けるには結構な覚悟が要ります。
「今後私はこれでやっていく」という強い気持ちが必要です。
ちなみに私の場合は、研修費用を会社が出してくれました。
マジでありがとうございます…。
研修を受けた背景
これは凄くシンプルで、チーム一体となり、良い開発・楽しい開発をしたかったからです。
リモート + タスクが調整されてエンジニアに降ってくるという状況のため、一部のPJを除けばチーム感は殆どありませんでした。
そういった状況を少しでも変えるべく様々なロールの方と議論していたところ、気付けば「じゃああなたがスクラムマスターやってみたら」という話になり、マジかよ…と思いつつも「だったら本気でやってみよう」と思い立ち、研修を受けることになった次第です。
研修で得た大いなる学び
研修初日に戻れるならば、半端に知識だけあって余裕綽々で臨んだ私に対して「学ぶスタンスを変えなさい」と言ってあげたいです。
結論から言うと、研修では "スクラムマスターとはかくあるべき" という考え方を学び、そして本当の意味で理解することができました。
1. 御用聞きに徹するのではなく、メンバー自身が「解決できる」と信じる
講師の方から、「スプリント途中で、サービスに必要なバナーを他部門の人が用意できていなかった時に、スクラムマスターとしてどうする？」と聞かれました。
この時研修参加者の方から挙がったのは「他部門の人に伺う」「スコープを調整する」というもので、私も全く同じように考えていました。
ただ、講師の方の意見は違いました。以下は講師の方の発言です。
※ 以降、講師の方の発言はうろ覚えですのでご了承ください
「開発チームのメンバーに "もし他部門の人が一斉に辞めたらどうする？" と質問しました」
「帰ってきた回答は "PhotoShopのライセンスを持っているので、それで何とかします" でした」
「そうしたら僕は聞きます。 "じゃあ、何で今、それをやってみないの？" 」
私には目からウロコでした。「これこそコーチングのあり方だ…！」と強く感じたのを覚えています。
この瞬間まで「スクラムマスターは良きコーチである」と頭では分かっていながらも、どこかで「ゴール達成のために秘書のように動いたりマネジメントを実施する = スクラムマスター」と思い込んでいたのを感じました。
勿論、スプリントゴール達成・プロダクトの価値向上のために、スクラムマスターが動き回ることはおかしくありません。
ただ本当に重要なのは、御用聞きにならず、チームが自分たちで解決できると信じ、課題を解決できるよう導くことだと、この時初めて理解できたのでした。
"push" ではなく "pull（コミットメント）”
スプリントプランニングの事前準備は何か、という問いに対して、私は "ベロシティ" と答えました。
ただここでも、講師の方の意見は異なりました。
「僕だったらベロシティは使わないかな」
「仮に前回のベロシティが100ptだった時に、それを前提に話をしたら "今回も100pt積んでね" という "push" 型のコミュニケーションになってしまう」
「開発チームが自分たちでバックログからアイテムを "pull" し、コミットメントすることが重要なんだ」
「ベロシティ必要だろ（ﾄﾞﾔｧ）」となっていた私は、ここでも衝撃を受けます。
御用聞きの件と同じく、 "コミットメントが重要" ということを知ってはいましたが、真の意味では理解できていなかったことを痛感させられました。
仮にpush型のコミュニケーションを取っていたら、それは "メンバーを信じていない" のと同じになっていたと思います。
ベロシティを目安に考えることは悪いことではありません。
ただ大事にすべきは開発チームの自信とコミットメント（pull型のコミュニケーション）であり、何かを強要（push型のコミュニケーション）するものではない、ということです。
メンバーを信頼し、任せる
Less（大規模スクラム）の話になった時に、私から講師の方に質問しました。「イベントに参加するチームの代表を決めるにはどうしたらいいですか？」
この質問に対し、講師の方からもらった解答を以下に載せます。
「メンバー自身に決めてもらえばいいんだよ」
「困った時はメンバーに聞くといい」
「信頼するべきはメンバーの意見だからね」
凄い…。
私はここでも「スキルや経験を考慮し、ある程度道を示してあげる必要があるのでは」などと勝手に考えていたのです。
今思えば何様という話なのですが、「スクラムを理解してちゃんと回さなきゃ…！」とか「メンバーにしっかり決めて教えてあげないと…」という思いが、私をこのスタンスにさせていたのだと思います。
新卒1年目のメンバーで構成されているといった状況でない限り、開発チームは自分たちで考え、良い方向に向かうよう意思決定してくれるはずです。
メンバーを信頼し、任せることは、スクラムマスターの最初の1歩であり、また最初の鬼門ではないかと感じました。
研修の学びを還元し、メンバーを信託する
学びを取り入れてまず実施したのはチーム作りのワークです。
とはいえ私がやったことは、
1. 付箋に名前と得意・不得意・挑戦したいことを書いてもらう
2. スキル/経験の4象限にプロットしてもらう
3. あとは「この情報からバランス良くチームを作ってね」と伝える
の3つだけです。
それ以降はほぼ開発メンバーのみで進行してくれました。
設計からワーク実施まで含め、とにかく任せること意識を置き、それを徹底したと思います。
結果、バランスの取れた2チームが完成することに…！
それぞれチーム名も決めてもらったのですが、かなり個性が出る結果になりました。（本人たちが決めたので私は何も言いませんw）
1. ボーイスカウトルールチーム（弊社CTOのポエムから抜粋）
2. オクラチーム（メンバーの一人がオクラが好き過ぎる結果）
信じて任せたことで、きちんとバランスの取れたチームができたのです。
表には出しませんでしたが、内心めちゃくちゃ喜んでしまいました。
この小さな体験は、今後スクラムマスターとしてやっていく上での小さな自信になったと思います。
学びを得た私がこれから目指していくもの
・お互いに信頼できる
・楽しく仕事ができる
そんなチームが私の目指す形です。
ボーイスカウトルールチームもオクラチームもまだまだ形成期なので、今後は1on1やドラッカー風エクササイズなどのコミュニケーション施策を用い、よりお互いに信頼しあえるチームにしていきたいと思っています！
まとめ
スクラムには答えがありません。
今回私が得た学びは一例ですし、講師や参加者の方次第では、研修で得るものが変わってくるでしょう。
それでもスクラムマスターとして成長したい、いいチームを作りたいと考えているのであれば是非、スクラムマスター研修を受けてみてもらいたいです。
"信じて任せる" ことが苦手な人でも、できるようになる最初の一歩を踏めるはずです。
最後に
私が働いているコミューン株式会社ではエンジニアを募集しています。
「認定スクラムマスターと一緒にスタートアップでスクラムを回したい！」という方がいましたら、是非ご連絡ください！
一緒にいいチーム、いいプロダクトを作りましょう。
この記事が気に入ったらサポートをしてみませんか？