fbpx

スクラムマスターを兼任から専任に変えたら劇的な変化が起きた話

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

今回はあるチームでスクラムマスター(以下、SM)を兼任から専任に変えた時の話を共有しようと思います。
先に結果だけ言っちゃうと、めっちゃ良い感じになったよって話です(語彙力)

どうも、保育園に子供を送っていくと先生に 「半袖半ズボンで元気ですね〜」 と毎日言われているアジャイルコーチの笹です。

※絶対にスクラムマスターを専任にした方が良いという話ではありません

特に読んで欲しい方

  • これからScrumを始めようかなぁという方
  • Scrumやってるけどマンネリ化している方
  • スクラムマスターと他ロールを兼務している方、または兼務しているメンバーがチームにいる方
  • Scrumチームがもっと良くなるんじゃないかと思ってるマネージャー

話を始める前に背景説明

あるScrumチームの話です。
そのチームは3ヶ月前にメンバーの入れ替えがあり、現在のメンバーになってからまだ日が浅い状態でした。
と言っても知らないメンバーはなく、近くで仕事をしていたメンバーです。
Scrumの経験については、直前のチームでも実践していたので全く知らない人はいません。

メンバー構成

  • プロダクトオーナー:1人
  • SM 兼 開発メンバー:1人
  • 開発メンバー:5人

何が起きていたか?

分かりやすい悪そうな事象としてこんなことが起きていました。
(もちろん良い面もいっぱいあります)
- スクラムイベント中にほぼ話さない&付箋もほとんど書かない人がいるのでシーンとしている
- 以前よりベロシティが下がり、計画した機能を作れないスプリントが続いている
- スプリントレトロスペクティブはしているけど効果が出てこない
- モブプログラミングやってるけど一部メンバーが指示した通りにタイピングするだけ
- SMって何もしないので必要ないんじゃないですか?という風潮が強くなる

どうしたか?

SM不要説が強まる中、「SMと開発メンバーの兼務をやめて、試しに専任のSMにしましょう」という話をぶっ込みました。
流れに逆らう話なのでスルーされるかと思いきや、割とすんなり受け入れられました!
さっそく次のスプリントから専任SMが誕生しましたー!(パチパチ)
元々1週間スプリントをしていたので「試しに1,2週間やってみよう」という実験には慣れてたんだと思います。
(「1回やってみましょーよー、ちょっとでいいからやってみましょーよー」とちょっと多少それなりに言ったかもしれません)

どうなったか?

1週間後のスプリントレビュー&スプリントレトロスペクティブに参加した時、既に目に見える変化がありました。
2週間後には更に変化があり、下記のような状態になっていました!
- SM不要説がなくなってSMの話をみんなしっかり聞くようになった!
- スプリントレトロスペクティブで貼られる付箋の数がかなり増えて会話も増えた
- スプリントレトロスペクティブでの会話にプライベートな話題が出始めた
- モブプログラミングは2,3人ずつ2組に分かれてやることになり発言が増えた
- スプリントレビューでどんなことを学びたいのかチーム内で考え、その情報を仕入れるための準備がしっかりされていた
- スプリントレビュー中にみんなで気づいたことをメモしていた
- スプリントのバーンダウンチャートができていた
- クラス図やシーケンス図といった設計情報がめっちゃ増えてた
- ゆるかった受入確認がしっかりされるようになった
- プランニングの時間がめっちゃ長くなった
- タスクはみんながわかるような詳細なものになり作業がスムーズになった
- ベロシティが回復して、むしろ前より良くなった

考察

SMがしっかり機能したことでチームが見違えたように良くなりました。
あくまでも1つの例にすぎませんが、色んなところでありがちだと思います。
今回の件で、良い変化が生み出せたポイントは 「SMが機能した」 ところだと考えています。
兼任の時は機能しておらず、専任になったタイミングで機能してきたということです。
どうして急にSMが機能しだしたのか、3つほど理由がありそうだったので時系列でまとめてみます。  

SMが機能してきた理由① 『誰がスクラムマスターなのか明確になった』

兼任だった時と専任の時を比較してみようと思います。

〜兼任だった時代〜

SM兼開発メンバーの発言がSMとしての発言なのか開発メンバーとしての発言なのか分かりづらいです。
開発メンバーが同じ目線でのコメントを期待していた時に、SMの視点でコメントされると「もっとちゃんと意見言ってよ!」みたいになっちゃうやつです。
また、周りのメンバーが混乱するだけでなく、本人もそうそう器用に変更することはできません。
開発が遅れている時や問題に遭遇している状況では特にそうです。
目の前の開発にフォーカスしてしまい、SMとしての役割を忘れることが多いように思います。
逆に、余裕があるときに急にSMにスイッチしても周りからすると混乱するだけになってしまいます。

〜専任になった時代〜

SMはいつでもSM一筋なので、他のメンバーの期待とSMの振る舞いとのギャップが少なくなりました。
SMの発言をSMの発言として受け取れるようになるため、混乱もせず、イラッとせず、受け取りやすくなります。
本人的にもある程度一貫した発言・行動ができるようになるのでやりやすくなります。
少なくとも1日の間に言動が右往左往するようなことはなくなるはずです。
複数の役割をスムーズに適切なタイミングで分かりやすく切り替えるのは、人間にはちょっと難しいんだろうなぁと思います。

SMが機能してきた理由② 『SMとして活動できる時間が増えた』

開発作業がなくなり、SMとしての役割に集中できるようになったので今までやれていなかった活動ができます。
今回の場合、率先してやっていたのが情報の可視化です。
バーンダウンチャートを作ったり、設計情報を書き出したり、ミーティングのアジェンダを決めたり…
色々なデータが見えるようになると何が上手くいっていて、どこが伸び代なのか分かりやすくなります。
実際にカイゼンを進めるのはチームメンバー全員ですが、気持ちの良いスタートがきれるようなフォローができていました。
チーム結成初期や暗礁に乗り上げているようなタイミングでは、まずはSMが引っ張ってあげるのは良いのかなと思います。
また、専任になったことで広い視野でものを見ることができるようになり、効果的な活動ができるようになったようです。
(兼任といっても、SMの役割をこなしているのは10〜20%程度で開発メインのことが多い気がします)

SMが機能してきた理由③ 『SMとメンバー間の信頼関係ができた』

兼任だった頃は、SMが何か実施してもSMの活動として認識されていませんでした。
開発メンバーも兼務しているため見分けがつかないためです。
今は専任になったことにより、SMの言動やアウトプットはSMというロールに関わるものだと認識されるようになりました。
さらに、その言動やアウトプットがカイゼンのきっかけになり、様々な良い結果に結びつくという経験ができました。
SMの活動・視点・役割・効果を理解できたことで、開発メンバーとSM間でポジティブな関係性が築くことができました。
こうなるとお互いを信頼して会話することができるようになり、より一層チームのパワーが高まっていくループができ始めます。

SMの役割には「スクラムの理論・プラクティス・ルール・価値基準を全員に理解してもらう」などがあります。
これはもちろん大事ですが、「チームに調和して役割を果たせる信頼関係が出来ていること」がそのベースにあると思います。
信頼関係が出来ていない状態で正論っぽいことを言っても、良い結果に繋がることはあまりありません。
「現場を何も分かってないのにゴチャゴチャ言ってくる邪魔なやつ」と思われることもあり、結果としてマイナスになることすらあります。
ということで、まとめると以下のステップでSMが機能する土台を作ることができたのだと思います。

  1. 誰がSMなのか明確になった
  2. SMとしての活動がしやすくなった
  3. SMとして活動をする時間が増えた
  4. 活動から変化が生まれ良い結果が出始めた
  5. SMの役割・行動・効果・必要性を体感できた
  6. SMへの信頼が生まれた

ということが発生して、SMが機能しはじめ、急激にチームが変化したのだと予想しています。

最後に

兼任スクラムマスターを専任にしたらチームがめっちゃ良くなったよ!
という話をさせてもらいました。
私の観測範囲では「開発メンバーが少ないので専任のスクラムマスターはちょっと…」「スクラムマスターって何するのか分からないので取り敢えず開発と兼任で!」と考えている人は少なくありません。
チームもプロダクトも会社の文化も違うので、兼任も専任も任命無しも一つの選択肢かなぁと思っていますが、「スクラムマスターの役割が良く分からんので兼任」というのはもったいない気がします。
理解した上で判断できるとより良い結果に結びつくのではないかと思っています。
そんなこと言ってもどうやったら理解できるんだろ…
と悩んでるそんなあなたに朗報!!
この頃出たSCRUMMASTER THE BOOKという本がオススメです(急な宣伝)。
スクラムマスターの目標や役割、スキルや成長など、知りたい情報が詰まっていると思うのでぜひ読んでみてください。
また、知識を詰め込んでもやってみないことには理解できないので、1ヶ月でも1週間でも良いのでやってみることをオススメします!
自分たちに合わなければ元に戻せば良いだけなので、気軽にトライしてみましょー!

最後の最後に

とはいえよく分からんので判断できない、もう少し具体的な話も聞きたい、とりあえず相談に乗ってほしいという方がいれば問い合わせFacebookTwitter、何でも良いので気軽に連絡くださーい!

Author

DevOpsチームのアジャイル好き。毎日宇都宮から通ってます。好きな言葉は「自由」!イベント主催するので参加してくださーい♩♪

Sasa Kentaの記事一覧

新規CTA