😺

初心者SMによるSM活動ふりかえり

2024/02/04に公開

始めに

私は某会社でスクラムの開発者3年を経て、スクラムマスター9ヶ月目です。
この記事は開発者時代と同じチームにおいて、スクラムマスターを実施した際(2023/5-2023/12)のふりかえりを備忘録として書きました。

失敗した言動

スクラムマスターである私の言動によって開発者の能力発揮をできなくしてしまった感覚があります。
具体的には以下のような言動です。

  • ある開発者Aが不快感を感じていた別の開発者Bの言動に対して、不快感を感じていた開発者Aに我慢をするように求める
  • 開発者の自由にやってくださいという旨の発言をしつつ、方針について否定的なコメントをする
  • ファシリテーションを開発者に任せ続ける

1つ目の言動の要因は、自分が開発者Bの立場になって考えると、その言動の理由に共感してしまったことでした。共感すること自体は良いと思いますが、その上でその言動によって悪影響があるのであれば、是正を求める等問題への対処法について考えた方が良かったと考えています。

2つ目の言動による影響としては、私はチームの一員として懸念を感じる点をコメントしているだけのつもりでしたが、開発者から見ると言動に制限がかけられている、何かと試したいのに試せないと思われていたように感じられていたことです。開発者の行動に制限をかけないように、実施前に否定的なコメントをするのではなく、結果を見て行動する割合を多くした方が良かったと思っています。
この言動の要因としては、プロジェクトの不確実性の高さと私のリスクマネジメント能力不足から生まれる不安感から出たものだと考えています。

3つ目の言動については、私から見てファシリテーションスキルが高くなく、かつファシリテーションスキルを伸ばしたいと思っていない開発者に対して、ファシリテーションを任せたことで、チーム全体が有効に動けなくなってしまったことです。
開発者全体にファシリテーションスキルを培わせることで、長期的なスパンでのチームの成長を促したいと思っていましたが、結果的にはそのタイミングが良くなかったと考えています。
そのファシリテーターである開発者の介入を待ってから私が介入しようとするため、タイミングが遅れてしまいましたし、その遅れたタイミングで有効に介入できるほど私のファシリテーションスキルも高くありませんでした。

実際にこれらの言動をやめていくと徐々に開発者のOutput量が増えたり、スプリントゴールの達成ができるようになっていきました。

今でもどうしたら良かったのかわからないこと

効果的なプロダクトゴールとスプリントゴールの立て方について

Vertical Sliceで考えたほうが良いことや、交渉可能なレベルのゴールを立てたほうが良いことは知っているものの、POに「具体的にどういうゴールだったら良いの」と聞かれても答えられませんでした。
私はプロダクトオーナーの業務やスキルについて、より理解が必要だと考えています。

開発者のやりたいことと現状の業務でやらなければいけないことが一致していない時にどのように動くか

このことによって具体的に困っていたことは、開発者のモチベーション低下でした。
開発者のやりたいことをできる範囲で実現できないかとチームリーダーや上司に提案して、その提案事項の実施許可をもらったものの、開発者はその提案内容だけでは納得できないということが発生していました。
事前に開発者にその提案内容を見てもらうなどすると、開発者の期待により寄り添えたかもしれませんが、それだけでは根本的な解決ができてなかったように思います。
より上手く開発者のやりたいことと現状の業務でできることをすり合わせるにはどうしたら良いのかは不明でしたが、ピープルマネジメントのスキルの向上によって、解決策が見つかるのかもしれないです。

上手くいった言動

開発者がどう進めたら良いかわからないタスクをリードする

開発者の中でどう進めたら良いかわからないタスクを実施しなければならなくなった際に、タスクの進捗がほぼ出なくなるという事象がよく発生していました。
その事象に対してどう進めたら良いかわからないタスクを小さく切ることや、まず手をつけられるところを探すことを推進しました。
最初は開発者の帽子を被ってタスクを一緒に実施することしか出来なかったですが、徐々に自分がファシリテーションして推進していく言動を学ぶことで、開発者中心となってタスクを進めていけるようになっていきました。

POが参加している会議の情報のキャッチアップ

POがそのチーム以外の業務も実施する必要があり、非常に忙しい状況だった上、そのPOはPO業務を初めて実施していたことから、ゴールの設定やタスクの実施目的などPOとしてやりたいことを実施することが難しい状況でした。
また私もPOの経験やスキルへの理解がなく、POへのスキル的な支援が難しい状況にありました。
そのため、私が自らPOとしての動き方をキャッチアップしながら、会議体への参加や議事録の確認などによって周囲の情報をキャッチアップすることで、POとしてやりたいことをPOとできる限り同じ情報を持ちながら支援できるようになりました。
完全な解決になったかと言われるかまだまだでしたが、スキルが少ない中での行動としては上手くいったと考えています。

開発者と月一で1on1

上記のように、開発者のやりたいことと現状の業務でやらなければいけないことが一致していない状況において、開発者の思いを深掘りしたかったですが、普段の会話だけだとどうしても把握することが難しい状況でした。
そのため、月一で1on1をして開発者の思いを知って、その上でどのようなことが可能かをすり合わせようとしました。
それらの集計結果は上司やPOへの交渉材料にもなりましたし、副次的に開発者が一人で思い悩むだけでなく吐き出す場になったので良かったのではないかと思っています。

最後に

あまりにも上手くいかないことがありすぎて書き始めましたが、書くたびに自分自身の言動をふりかえりながらアップデートしていけたので、すごく良い取り組みでした。
現在新たなチームでのSM業務を実施しているので、その業務から離れたらまたふりかえりたいと思ってます。

Discussion