スクラム失敗談 | スクラムマスターがチーム改善をリードしてしまう

Androidエンジニア 兼 スクラムマスターのNichiです。

スクラムマスターの拝命を受けて9ヶ月ほどたち、約18スプリント(2週間スプリント)が経過して、最近ようやく、スクラムマスターとして自分がどう振る舞うのが良いのかが少しずつ見えてきました。

そこで、今になってようやく気づいた、スクラムマスターとしての失敗談を不定期で更新しております。

なお、過去の2記事は↓↓

自分がスクラムマスターになった背景

さて、今回の記事の本題に入る前に、皆さんは、どういった過程でスクラムマスターになったでしょうか？

私の場合は、まず自分の性格の話をすると、「こうすればもっと良くなるのに」ということに敏感な方で、改善案をどんどん提案・実行し、かつ真面目でマメというのもあり、昔から何かとグループリーダーに選ばれることが多かったです。つまり、プロジェクトを前に進めていくのが割と得意です。また陽気な性格で、自分自身もチームメンバーも楽しく仕事ができるようにギャグを交えながら場を和ませたり(実際には盛大にスベりまくってシラけさせたり)するのも得意で、嬉しいことに愛されキャラと呼んでもらえることもあります。加えて、言われたことをただこなすのではなく、ユーザーにとってワクワクするものを自分の提案も交えながら作りたいというモチベーションが高く、「何の為にこれを作るのか？」という背景や、「ほんとにこれでユーザーは嬉しいのか？」ということを意識しながら、ユーザーにとって価値ある施策なのかどうかを自分なりに考え、POや企画の方々に質問・提案をすることも得意、というか無意識でしています。

このように、企画に対しても、それをリリースするまでのプロセスに関しても、ユーザーがワクワクするのか？という観点で、周囲を巻き込みながら積極的に意見を提案・実行し、チームを前に推し進めることが自然とできる、という点を買われてスクラムマスターを任せてもらったのではないか、と推測しています。(全然違ってたらごめんなさい、あとで上司に確認してみますw)

気づけば自分の意見がめっちゃ多い

そんなこんなでスクラムマスター兼Androidエンジニアとしてモバイルアプリのプロダクトのスクラムチームで働き、いろんな壁にぶち当たりまくるのですが、最近特に危機感を覚えているのが、「チームメンバーから提案が少なく、自分が喋る時間が多くない？」ということです。これは別に最近になって露見したことではなく、自分がスクラムマスターとなってからずっと感じていたことで、時には「何でみんなもっと意見してくれないんだろ、改善したい気持ちないのかな？」と思ってしまうこともありました。「自分だったらここすごい気になるしもっと改善したいと思うのに、みんなは何も思ってないの？」と心の中で叫んだり。

例えばPBR(プロダクトバックログリファインメント)の時に、企画背景や実現方法などについて、POに対するチームメンバーからの質問が少なくて、気づけば自分ばかりが質問している。レトロスペクティブでは、良かったことや悪かったことの感想はたくさんあっても、どうしたらもっと改善できるかという提案・議論が少なく、ありきたりな結論になる。

他にも、POと開発者とのコミュニケーションのハブに自分がなってしまったり、何かと自分が意思決定をすることが多い。

なんか自分ばっか話しているし、相対的に他のメンバーからの意見が少なく見える。

それ、スクラムマスターとして振る舞えていない

結局これは、他のメンバーに何か原因があるわけでは決してなく、スクラムマスターである自分が、スクラムマスターとして振る舞えていないんですよね。チームの自己組織化・自己管理化を促進するはずのスクラムマスターが、自らそれを阻んでしまっている。

なぜそうなってしまったかというと、私の性格上、自分で決めて自分でどんどん推し進めていくのが得意で、逆にいうと、他者に判断や推進を任せるというのを、しっかり意識してないとできない、お節介焼きタイプだからだと思っています。あとは、自分は割とどんな環境でもガンガン意見を言えるタイプなので、意見が少ない人の気持ちを理解できていない。

なので、本来であれば、チームメンバー一人一人に対して、「自分たちで判断し改善していく」ことを何度も伝え、実際にそう振舞ってもらうことを手助けし、POや開発者の責務に関する範囲(つまり、プロダクトバックログアイテムの優先度やそのデリバリーに関すること全般)ではスクラムマスターは自らの提案や指示、意思決定を極力控える。スクラムのコンセプトや各種スクラムイベントの意義と各メンバーの役割を伝え、スクラムの知見を元にした参考程度のヒントを出すに止める。自分の意見をグッとこらえ、チームメンバー全員が同じ量の発言・提案をできるようにファシリテートする。「意見少ないな」ではなく、質問をして意見を引き出す。意見を出しにくい背景をヒアリングする。

繰り返しになりますが、私のようなタイプの人間は、自然に振舞っていると、ついつい自分の意見を主張し、自分で仕事を巻き取り、自分で判断して一人で物事を進めてしまい、スクラムマスターとしてはアンチパターンを踏んでしまうので、注意が必要です。

開発者との兼務は特に注意

特に開発者と兼務している場合、スクラムマスターである自分がデリバリーのプロセスに直接関わっているため、デリバリーの過程でも他の開発者の主体性を削いでしまう可能性があります。「デリバリーは開発者のみなさんの責務です、自分たちで計画しその責任を果たせるようにしっかり議論してください」と、第三者的な一定の距離を置きづらい。

チーム改善を実施するのはスクラムマスターではなくPOと開発者

長々と書いてしまいましたが、私のような、物事を推進するのが得意なタイプは、意識的にスクラムマスターとして振る舞うようにしないと、気づけば自分でチームメンバーの自己組織化・自己管理化を妨げてしまいます。

チーム改善を実施し、持続的にユーザーに価値を届ける主体はPOと開発者で、スクラムマスターはそれを実現できるような支援に徹します。いろんなことを言いたいし実行したくてウズウズするでしょうが、スクラムマスターとしての自分の責務を全うしましょう。

その他のTIPS

最後に、「チームメンバーの意見が少ない」と感じた時に、私のチームメンバーからヒアリングして出てきた意見をいくつか共有しておきます。

- 議論をできる信頼関係が構築されていない (自分の提案はナンセンスなんじゃないか、否定されるのではないか、という恐怖)
=> レンシオーニの五つの機能不全ピラミッドの根底にある、「信頼関係の構築」と「衝突への恐怖」を解消する

- 各種スクラムイベントの意義と、その中で各自に期待される行動が伝わっていなく、どう意見すれば良いか分からない
=> スクラムについてのティーチング、メンタリング

- みんなに問いかけた時に、数秒沈黙になっただけで気まずくなって自分で話出してしまう
=> 瞬発力より熟考タイプもいるので、沈黙に少し耐えて待ってみる

- リモートなので同時に発言することが難しく、タイミングを待っている間に話が次に進んでしまう
=> こちらから話を振るだけでなく、チャットでのコメントや同時編集のドキュメントへの記載も歓迎する

- アジェンダが事前共有されてなくて事前に質問を考える時間がない
=> PBRなど、事前に企画内容などをシェアしてもらい、質問欄などを設けて事前に考えてもらう

あとは、自分がスクラムマスターとして悩んでいる内容をチームに共有してみるのも良いと思います。