スクラムマスターのみなさん。ベビーシッターになっていませんか？

なにこれ

スクラム開発において、ロールをスクラムマスターと開発チームを兼任する時の固有っぽいしくじりをして、立ち直った体験談です。
アンチパターンでも兼任している方は結構いますよね。

他の誰かが同じ轍を踏まないように。。。

スクラムマスターがベビーシッターって？

ベビーシッターってどういうこと？

特にスクラム用語ではありません。ググってもそんなに引っかかりません。
一般的には以下の定義です。

ベビーシッター（英語: babysitter）とは、母親に成り代わって乳幼児の世話をする人をいう。

https://ja.wikipedia.org/wiki/%E3%83%99%E3%83%93%E3%83%BC%E3%82%B7%E3%83%83%E3%82%BF%E3%83%BC

まあ。そのままの意味ですね。
この記事ではプロジェクトリードとタスクを巻取りまくってこなす人と変換します。

スクラムマスターとベビーシッターの違い

ここでスクラムマスターの定義をおさらいしましょう。

スクラムマスターは、スクラムチームのサーバントリーダーである（訳注：メンバーが成果を上げるために支援や奉仕をするリーダーのこと）。 スクラムマスターは、スクラムチームとやり取りをするときに役に立つこと／立たないことをスクラムチームの外部の人たちに理解してもらう。スクラムマスタ
ーは、こうしたやり取りに変化をもたらすことで、スクラムチームの作る価値を最大化する。

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

差分は以下とします。
スクラムマスターは開発チームを支援するサーバントリーダー
ベビーシッターは開発チーム内のタスクを巻き取るハイパフォーマー

スクラムマスターと開発チームを兼任する人って開発チームの中でも出力が高く、他メンバーをリード出来る様な人が行っている事が多い印象があります。

スクラムマスター、開発チームの期待役割をそれぞれ達成するために脳裏に浮かぶのは以下あたりではないでしょうか。

• チームの自己組織化
• チームの出力を最大化する
• スプリント達成

これらが良くない方向に進むとどうなるのか。
自分の場合、全く逆の方向に進んでしまいました。。。
スプリントは未達が続き、チームにネガティブな雰囲気が生まれ、一部のパフォーマンスが出る人だけでなんとかしている状態になりました。

ベビーシッターになるとどうなるの？

ベビーシッターの例

以下の様な状況が続いたらベビーシッターとなっていると思われます。いわゆるスクラム開発におけるアンチパターンと言えます。

ex1) デイリースクラムでスプリント達成のためリプランを検討するシーン

メンバー「終わってません」
チーム全員「...」
ベビーシッター「どうやって挽回させようか？」
チーム全員「...わかんないですね。」
ベビーシッター「タスク巻取り or 一緒に課題解決 or スコープ調整 or マイクロマネジメントあたりとかどう？」
チーム全員「なるほど！」

ex1が継続的に発生している場合、
チームでは想定から遅延場合のリプラン、リカバリ案を考えなくなる。
ベビーシッター具体的な対策を考え提示し続ける。そして大体は提示したタスクをベビーシッターがやることになる。

ex2) 仕様作成のシーン

メンバー「仕様できました！」
ベビーシッター「（ここは担当しないけど一応読んでおこう...考慮漏れ多すぎワロタ）」
ベビーシッター「仕様分からない箇所があるから追記しました。問題無いか確認おねがいします。」
メンバー「ありがとうございます！」

ex2の場合、
チームとしてはなんとなく前に進んでいるため特に問題として捉えない。
ベビーシッターは先回りのカバーリングが常態化していてチームにタスクを任せられなくなる。

結局どうなるの？

端的に言うとチームを組んでいるメリットが無くなります。自己組織化も進みません。それぞれの役割でどのような状態になるのかを見てみましょう。

開発チームの場合

ベビーシッターの言いなりになり、自分たちで考える習慣がなくなります。
それはスプリントの各種イベントでも発揮されてしまいます。そのため当然チームは良い方向へ育って行きません。また、個人としても成長機会をベビーシッターに奪われまくっています。
こうなっていくるとスプリントは当然の様に達成出来ず、毎回の様に終わっていないユーザーストーリーが出てきます。

ベビーシッターの場合

とにかく疲弊して、1人でやった方がうまく行くと強く思うようになります。
スプリント達成のために最初は奔走出来ても、持続可能なペースではなくなり、1人でなんとかしている気になってきます。
そしてチームに任せられなくなりタスクを抱え込むようになってしまいます。
正直1人で全部やった方が早いと考える事も出てきます。
もちろん疲弊して個人としてのパフォーマンスもガタ落ちします。

有効だった改善策

上記のような状態になってから改善に有効だった方法をいくつか紹介します。

意見、案を引き出す様な質問をする

どのイベントでも有効です。
出してもらう案は正解（良い案）である必要は無いです。出てきた意見、案に対してフィードバックを与える事で良かった点、もっと考慮すべき観点を伝えていきましょう。すると個人が自分の意見を言う様になってくるし、意見や案のレベルが上がってきます。

不要な先回りはしない

全てのプロセスで最短を目指す事を辞めました。
自分の中で要所要所でデッドラインを作って、デッドラインに触れるまではメンバーにチャレンジしてもらいます。
デッドラインに触れるタイミングで初めてタスクの巻取りを行います。
チャレンジすることで成長機会を与えます。完了しなくて巻取りになった場合でも、何が不足していたのか？を巻取り後のアウトプットを見ることで個人が振り返る事が出来ます。

自分の発言は最後にする

メンバーより先に発言する事を控える様にしました。
誰かが言ったからこれが良さそうだ。という迎合を発生させない様にするためです。

要するに

自分で考えて動いてもらう状況を提供するようにします。そして自分たちで考えたらスプリントを達成出来ると成功体験を与えましょう。

速攻性が有る策ではないので、実行しようと思った最初のスプリントプランニングだけ実行するタスクの量は減らします。私の場合、自分1人でも全部達成出来ると自身がある量に調整しました。2回目以降は特に制約無しで問題ありません。

スプリント未達続きのチームが自分で考えるようになったら、スプリント達成した！なんか良さそう！と感じてもらいましょう。
チームの雰囲気が変わったらベビーシッター卒業です。
0→100で全部やっていたことを、チームに任せても案外うまく進みます。
任せられれば疲弊した状態からも脱出できて、プロダクトのため、チームのために活動することが出来ます。

おわりに

私の場合、スクラム開発を導入して2ヶ月目くらいにこの事象に出くわしました。当時はPjM経験は有り、チームビルディング経験はほぼ無しでした。スプリントを達成しようと思うほどチームビルディングとは逆行してきましたね。。。

こんなしくじりがありますので皆さんは同じ轍踏まないで欲しいです！