こんにちは、サイボウズでスクラムマスターとして働いている村田です。 2023年8月から kintone の新規機能を開発するチームに移動し、週3日（火水木）勤務で専任スクラムマスターとして活動しています。 それ以前の約1年間は、kintone のヘッダーを React 化するチームでスクラムマスターとエンジニアの役割を兼務していました。
活動紹介 blog.cybozu.io
以前所属していたチームはゴールを達成して現在は解散しています。この活動で得られた学びを Spotify で配信しているので、お時間があればこちらも聞いてみてください。
今回は前と今のチームでスクラムマスター兼務と専任両方の経験を通して得た違いを共有したいと思います。
兼務時代
スクラムマスターとエンジニアの兼務を始めた理由
エンジニアとスクラムマスターの兼務を始めたのは今から2年前です。当時の僕は開発組織のチームのあり方に疑問を抱いていました。
そんなときにフロントエンドリアーキテクチャPJ(フロリア)という新しいチーム体制でのプロジェクトが始まり、1チームに1人スクラムマスターを配置することが決まりました。自分はチームの成果を最大化するために試してみたいアイデアを沢山持っていて、これらのアイデアを実際に試すにあたってスクラムマスターは最適な役割だったため立候補しました。とはいえ、いきなりスクラムマスターになるのはキャリアの不安がありましたし、できることならエンジニアとしてキャリアを積んでいきたい気持ちも強かったため、まずは兼務でスクラムマスターを始めてみることにしました。
兼務時代のふるまい
エンジニアとスクラムマスターを兼務していました。割合はチームの状況に合わせて変えていました。スクラムマスター業が1割の週もあれば、9割の週もありました。スクラムマスターはチームに1人で代わりがいなかったため、自分の場合はスクラムマスター業を優先して、残った工数でエンジニア業に勤しむ動き方をしていました。
兼務時代は目の前の課題解決に意識が向くことが多かったです。プレイヤーとしてのアウトプットも求められるため、スクラムマスターとしてチーム内の目の前のチームの阻害要因を解決したら、即エンジニアに転身してコードを書いていました。基本的にチーム内の活動に目がいきがちで、目の前の課題がチームの外の協力を得ないと進められない状況になったときに初めてチーム外との協力関係を築いていくような立ち回りをしていました。一個人の目線で解決した方が良いと感じた課題をチームに提案して共感が得られたら解決に向けて動き始めることが多かったです。
専任時代
スクラムマスター専任を始めた理由
フロリアで活動していたチームが解散し、新たに新規機能を開発するチームでスクラムマスターとして活動することになりました。前と同じ規模のチームで兼務として似たような仕事をしても得られるものが少ないと考えたため、思い切って専任に挑戦してみました。
専任時代のふるまい
自分が所属しているチームをより俯瞰的に観察するようになりました。今までコードを書くために使っていた時間をチームの中長期的なビジョンの実現に向けた活動や、チーム外との関係性強化に向けて動くことが多くなりました。兼務時代と違って自分が直接成果物を生み出す仕事をしなくなったので、個々のチームメンバーの意見を拾う場を整えたり、世の中や社内の他のスクラムチームの事例を持ち帰ってチームに伝えたり、チームの成果を最大化するために支援に集中する応援団長的なふるまいが強化されました。常にチームの中と外の状況を見て、何を解決するのが最も効果的か考えてチームメンバーに促すことが多くなりました。
スクラムマスター専任になって良かったこと・悪かったこと
良かったこと
1. 役割が明確になった
専任として活動することで、「今、エンジニアとスクラムマスターどっちの役割で話してるんだっけ？」という混乱がなくなりました。兼務時代は「今はスクラムマスターの立場で話すんだけど…」という枕詞を使ってなるべくメンバーを混乱させないようにふるまっていました(この枕詞を使ったとしても聞いている側は混乱していたと思います)。また、一度エンジニアとして深く介入しすぎると、オーナーシップを他のメンバーに移すことが難しくなり、解決するまで自分がリードしてしまうことも何度もありました。専任になることで役割が明確になり、課題解決に向けて最期までメンバーを支援することに集中できるようになりました。自分がリードするのではなく、リードする人を育てるふるまいを意識しています。
2. 手段に拘らなくなった
兼務時代は自分が実行役も担っていたため、どうしても納得できない手段に対しては反対意見を出さざるを得ませんでした。専任になってからは手段を開発メンバーに任せるようになったため、「なぜ今、我々がその課題を解決するのか」という目的を定めることに関心を寄せるようになりました。手段は常日頃から課題に向き合っているチームメンバーの方がより良い方法を知っていますし、仮に誤った選択だったとしたとしてもスクラムマスターが効果的なふりかえりの場を用意できていれば自ずと最適解に向けて収束していくと信じているので、取り返しのつくことはすべて任せるようにしています。
スクラムマスターとして特に意識しているのは意思決定に必要な情報をチームの外から引っ張ってくることと、チームの活動が外から見えるようにすること(=スクラムの3本柱における透明性)です。場に情報を貯めて、メンバーが考えて実行する機会を増やして小さな意思決定を繰り返していけば、次第に大きなことも決められるチームに成長すると信じています。
悪かったこと
1. チームメンバーとの認識のズレが大きくなった
開発メンバーと同じ目線で物事を捉えることができなくなってしまったので、問題意識や課題感についてメンバーから共感を得て主体的に進めることが難しくなりました。自分とメンバーとの間に情報の非対称性がある状況で目的を伝えてもチームメンバーは納得してくれません。専任になってからは今まで以上に「よく観察すること」「よく話を聞いてから判断すること」が大事だと痛感するようになりました。まず対話の場を作り、お互いが持っている情報を共有し合って共通認識を作るプロセスを踏むことを意識しています。
しかし、頭では理解しているつもりでも未熟者である故に色々と物申したくなる気持ちが煮えたぎり、ある日唐突に主観100%の意見をチームにぶつけて場をしらけさせてしまうことが度々あります。言うは易し行うは難しだなと日々感じています。
チーム同士の関係性にアプローチしたいなら専任を勧めたい
最初のとっかかりとして兼務を選ぶのは良い選択だと思います。スクラムマスターの所属している小さな1チームにアプローチするだけなら兼務でも十分責務を果たせると思いました(ScrumMasterWayにおけるレベル1)。
もしチーム同士の関係性にアプローチすることを考えているなら専任をおすすめします。チーム同士の関係性にアプローチを試みたいなら、まず前提としてチームの外側で中立的な立場に立つことが求められます。チーム内の開発メンバーとしてのアウトプットが求められる状況下で、中立的な立場を維持しながら関係性にアプローチしていくのは難しいと判断しました(ScrumMasterWayにおけるレベル2 or 3)。
大事なことは1つのチームの中で組織構造のレイヤーの異なる立場の役割を兼務しないことだと考えています。自分の場合はスクラムマスターとしてのアプローチの幅を広げながら、エンジニアのキャリアを積むことを理想としていたため、現在は週3日(火水木)サイボウズでスクラムマスター専任として働き、それ以外の日は業務委託で別の会社のエンジニアとして働く働き方を選択しています*1。
*1:社内規定に従い上長からの承認を得ています。
