
スクラムマスターを1ヶ月やってみてのふりかえり
こんにちは。フロントエンドエンジニア兼社内広報のとよしーです。
11月下旬まで、主にフロントエンドの開発をチームでやってきましたが、プロジェクト内で再びスクラムマスターの必要性が問われ始めてきました。
私としては以前からスクラムマスターという役割に興味があり書籍などでインプットもしていたため、スクラムマスターにチャレンジすることになりました。
今回の記事では、スクラムマスターにチャレンジしてから1ヶ月経ったので、ふりかえってみようと思います。
● 背景
そもそもスクラムマスターの必要性が問われ始めたきっかけを説明します。
私たちのプロジェクトは、3ヶ月に1回プロジェクトメンバー全員が集まって「インセプションデッキ」を次の期に合ったものに更新します。
その中でチーム間の相関図を図示するワークショップがありました。そこで見えてきたのは、スクラムチーム内の開発者とPdMの間や、他のチームとの間でコミュニケーションがうまくいっていないことでした。
また別の背景として、開発者のチームに新規メンバーが参入してきたこともあり、いままで安定的に進めてきたチーム編成に変化があったこともあります。
そのような背景で、再びスクラムマスターが必要なのではないか?という声があがったわけです。
ちなみに「再び」というのは、1年前に@junichi_m氏にスクラムマスターをやっていただき、その結果、チームが成熟したため、スクラムマスターの役割から離れた経緯があります。
● スクラムマスターをやってみてのふりかえり
前提条件
Devチーム:開発者5名 / スクラムマスター1名
PdMチーム:3名
スプリント:2週間
・チーム間連携を促すこと
私たちのプロジェクトはPOのことをPdMと呼んでいます。また、PdMが3人いるため、チームとして動いております。したがって、開発者がいるDevチームの中にPdMは事実上存在していないので、PdMともチーム間連携を取っている形になっております。
私がスクラムマスターとして入りたてのころは、DevチームとPdMチームが期待していることに関してうまくコミュニケーションを取れておらず、PdMに対する不信感がチーム内で高まっておりました。
そこで、チーム間でうまくコミュニケーションをとれるようにするために、PdMと開発者がお互いの期待値や認識を合わせる場をセッティングし、私はファシリテートしました。
(正直、めっちゃピリピリしていて一触即発なんじゃないかと私自身、勝手に不安になり胃をちょっと痛めていましたが、比較的穏やかに会は進みました)
結果、開発者が求めているチーム像の認識合わせや、PdMは1スプリント内の機能のリリース数を重視しているわけではないことがお互いにすり合わせることができました。
ただ、1度この場を開催してPdMとのチーム間連携のすべての問題が解決するわけではなかったので、引き続き隔週で話し合う場を設定することにしました。
チーム間連携についてふりかえった結果、今後も気をつけたい点が挙がってきました。
それはスクラムマスターがただの仲介屋にならないことです。
DevチームとPdMを仲介することが目的なのではなく、DevチームもPdMも含めたスクラムチームとしてパフォーマンスをあげられるチームにすることが目的なので、今後もこの点を見失わないようにしていきます。
・ふりかえりを機能させること
現在のスクラムチームは「ふりかえり」を週1回のペースで開催しています。
スクラムマスターとして入りたてのころは、チームのふりかえりが日々気になっているトピックをみんなで話し合う会になっていました。
トピックの中には「ふりかえり」っぽいものもありましたが、ふりかえりで「検査」と「適応」ができていなかったため、まずはふりかえりを機能させることに注力しました。
まずは、その時のチームの状況に合ったふりかえりのフレームワークを実施してみました。
具体例をあげると、
前スプリントがうまく立ち回らなかったときは、根本原因を究明する
「5つのなぜ」
で深掘りをしたり、
チームメンバーのタスク状況の可視化を押し進めるために、
「タイムライン」
を行ったり、
開発を進めるうえで、良い点・妨げている点を可視化するために
「熱気球」
のワークショップを行いました。
ふりかえりを行っていくうちに、チーム内のプロセスに関する課題を見つけられるようになってきました。例えば、以前は、タスクのゴールが不鮮明なまま作業を進め、時間を多くかけていた傾向がありましたが、ふりかえりの結果、タスクの完了条件が曖昧のまま進めていたことが分かったので、完了条件の認識をチームで合わせるようになったのはひとつ変わった点です。
ただ、いまだにふりかえりをやる上で難しいことは次に向けたActionの決め方です。
いままではActionが抽象的でゴールが見えないものだったり、
「MTGをセッティングする」のようにタスク的なActionが多かったです。
よくActionは「SMARTゴール」で考えようと言われますが、私自身もSMARTゴールを意識して、チームと一緒にActionを考えました。
現時点での私自身のふりかえりとしては、まだActionの決めたあとのゴールに抽象的な部分があると感じています。
ふりかえりで得た気付きを継続的にチームに適応させていくために、ふりかえりをただの楽しいワークショップで終わらせずに、具体的なActionを決めて、着実にそれらをチームに適応していくことが今後の改善点です。
・リーダー / フォロワーの関係にならないように気をつけたこと
スクラムマスターの人物像として、スクラムガイド2020には
スクラムチームと、より大きな組織に奉仕する真のリーダーである。
と記載されておりました。
真のリーダーってなによ...と思いましたが、この「リーダー」に関して、
スクラムマスターとしてどのようなリーダー像が求められるのか?
という疑問をスタート地点として考えていきました。
私自身、いわゆる「リーダー」というのは、みんなをヨイショヨイショと率いて、チームメンバーに的確な指示を出すといったイメージがつい最近までありました。
しかし、そのやり方だけではスクラムガイドに書いてある自己管理型のチームになれるのか疑問が残りました。
モチベーションを持ちつつチームメンバー自身で考え、チームとしてのパワーを最大限活かすのであれば、
「おれについてこい!」
のような「リーダー / フォロワー」の関係性は望ましくないと考えました。
そこで私が目指したリーダーとチームとの関係性は「リーダー / リーダー」です。
チームメンバーそれぞれが自己管理できるように、スクラムマスターとしては必要以上に口出ししない方向性でこの1ヶ月は進めていました。チームメンバー自身が考えて動けるような環境を意識して作ろうとしていますが、やはり時々「こうしたほうがいいと思う」といった言い回しに私自身がなっている時がありました。
特に、スクラムをやっていた時の私の経験則を押し付けそうになってしまいました。現在は、私がスクラムをやっていた時のチーム編成や環境は違うので、一概に私の経験則が今のチームメンバーに役に立つとも言い切れません。
まだまだ私自身としては反省点がありますが、引き続きチームの状況を観察しつつ、チームメンバー全員が自己管理できるリーダーのような立ち振る舞いができる環境を作れるように尽力していきます。
● まとめ
以上、1ヶ月スクラムマスターを担当してみてのふりかえりでした。
正直なところ、チームメンバーそれぞれの個人としてのパフォーマンスは素晴らしいのですが、スクラムチームとしてのパフォーマンスはまだ出し切れていないように見えています。
チームメンバーの単なる「足し算」としてのパフォーマンスではなく、「掛け算」として相乗効果を生むようなチームにしていくには、どうしていけばいいかと日々頭を悩ましています。
一朝一夕でチームが信じられないほど成長することはないと思っていますが、まずはチームがどこに向かっていくのかという指針を設定することが大事なのではないかと考えています。
来年はチームメンバーの主語が「私」ではなく「私たち」で考えられ、パフォーマンスを出せるようなチームに成長できるようにしていくことが目標です。
読んでいただきありがとうございました。