成果を出し続ける開発チームを作るために
自己紹介
こんばんは。
多分公開するのが夜になるので夜の挨拶から始めてみました。
Rettyでマネージャーをやっております、李と申します。
今回話す内容
この記事はEM Advent Calendar 2021の16日目の記事として作成しました。
今年の夏に、もともとマネージャーをやっていたチームとは別のチームのマネージャーを兼務することになりました。
新マネージャーとして入るときにやったことと、それによって何が変わったかをこの場を借りて共有し、今後皆さんが新しいチームを担当することになった際に少し役に立つことができれば幸いです。
配属前にしたこと
配属の目的を明確に認識した
今回のマネージャー配属は明確な目的がありました。
社としてチームに期待しているほどの成果（デリバリー）が達成できておらず、週単位のスプリントのゴールも未達成が続いたので、成果を出し続けるチームにすることが目的でした。
今考えると、すべてのマネジメントの目的とやることはそれなのでは？と思いますし、この配属を通じてそれを改めて確認できたのだと思います。
改めて強くその目的を意識することで、まず実感出来る成果改善に取り組むことが出来たと思います。
メンバーヒアリングを行った
マネージャーが変わるということを事前に伝えて、急な変更と感じないようにグラデーション付けを行いました。
今後マネージャーになるので、それまでお互いのことを知るため、そしてチームに関して思ってることをぶつける1on1を数回実施することにしました。
その数回の1on1で、お互いのざっくりした性格や重要だと思う価値、キャリア志向、個人・チームの課題だと思っていることなどを吸い上げることが出来ました。
配属後にしたこと
なぜマネージャーとして来たのか目的を明確に伝えた
会社として今このチームがどういう評価を受けているのかを明確に伝える必要がありました。話す立場としては結構キツいですが、ここでチームに期待しているレベル感を間違えて伝えてしまってはいけないと思い、部門長からの期待と私からの期待を明確に伝えました。
詳細は控えますが、「成果が出てないわけではないが、このメンバーならもっと出来ると思っている」というエモい系と「スプリントゴールの達成が出来てない期間がこれぐらいある。その原因があるはずでそれを解消していく」明確な改善ポイントを示す話をしました。
マネージャーとして出来ることと出来ないことを明確に伝えた
私のスキルセットとはかなり離れている開発チームだったため、予め自分に出来ることと出来ないことを伝えました。
多方面で調整して進める必要があるものを調整して進める
長丁場でゆっくり少しずつ進めていくべき技術課題の推進
チームの中にいない外から見ての疑問の投げかけ
スプリントゴール達成を妨げる差し込みのブロック
などの物事の推進・快適に開発するためのサポートは任せてと話し、
実際開発の技術的リード
技術課題のリストアップや解決方針検討
レビュー
などの技術的部分はメンバーを信じて任せると伝えました。
これによって、お互いに期待することと役割を共有できたので、メンバーは技術的判断は自らしていきながら、進めにくい部分ではマネージャーを頼るようになりました。
チーム合宿を行った
チームの課題を自ら発見して納得し改善していけるように、1日漬け込みで合宿を実施しました。（普段の業務から離れて、あるテーマに関してとことん思考・議論するのをRettyでは合宿と呼んでいます。）
合宿の目的は以下のように設定しました。
変化が始まるんだと思ってほしい
ふわっとしているものでもいいので皆が共通して目指すものを持つ
現状を振り返り、今後やることをチーム自ら考える機会にする
課題は多いけど糸口的に一つの絶対達成するアクションを設けたい
また、担当PdMも巻き込んで参加してもらい、エンジニアリングだけの方向性にならないようにしました。
合宿の詳細は省きますが、結果として
チームとしてプロダクトに対するビジョンを設定した
ビジョン達成のためのチームの理想のあり方を議論し、実現するアクションを考えた
その中でまず必達するべきアクションを1、2個に絞ってまずそれを実行することにした
ということが出来ました。
見えないタスクを見える化した
見えないタスクが多すぎるので、期待しているほどのパフォーマンス発揮が出来ないことが合宿で分かったので、見えないタスクを見える化していくことからやると決めました。
持っているプロダクトが複数あり、施策開発も運用も一つのチームでほぼ賄っていたので、施策開発はバックログ上で管理されているけど運用・改善などは見えないタスクとしてチームのリソースを圧迫していることが明確にわかりました。
運用・改善もしっかりバックログで管理するようにフローを整備し、開発チームが持っている運用・改善のタスクをPOやPdMも把握出来るようにし、施策展開が遅くなる理由が分かるようにしました。
また、運用・改善タスクもバックログの優先順位に適切に反映できるようにスクラムマスターとマネージャーが積極的にPO・PdMとコミュニケーションを取るようにしました。
バックログ最優先だから運用・改善はそこに載せないほうが進められる、という雰囲気から、ちゃんと載せて話して優先順位を上げていくという健全なフローが少しずつ根付いていきました。
スプリントゴールは達成するものにした
大きい施策で肥大化したストーリーや、見えないタスクが多くスプリントゴールが達成できない期間が長かったので、スプリントゴールは必ずしも達成しなくてもいいもの、みたいな意識がありました。
毎回達成することは難しいですが、達成するための追い込みや達成していくんだぞという気概とそのための協力などが失われては困ると思いましたので、絶対達成したい・達成出来る目標を一つだけにしぼり、スプリントゴールとして達成していくことにしました。
そのスプリントにデリバリーしていくものを絞ってフォーカスすることで、チーム全体としてフォーカスするべきものがはっきりしました。
まずそこに集中することで達成もしやすくなり、緊急な優先順位変更が発生しない限りスプリントゴールは達成していくもの、という意識がチームに芽生えて、根付いていきました。
達成が当然と感じるようになり、達成がギリギリのときには個人のタスクよりチームの達成にフォーカスを合わせてみんなでゴールを達成していく動きを取るチームになっていきました。
チーム自らが変化し始めた
スプリントゴールの達成が続き、チームでデリバリーしていくことに徐々に変わっていきながら、スクラムチームとして足りない部分が多いと感じたメンバー自ら、SCRUM BOOT CAMPの読み合わせを行い、自分たちがどう動けばいいか、課題を設定して動くようになりました。
今は毎日チームで議論すべき話題を持ち合わせ、小さいアクションを作ってそのアクションを少しずつ遂行していくことでチームの持続的変化や技術課題・運用改善の遂行を行っています。
既存のルール、開発・技術に関する改善は問いかけから
既存のルールとか、なんとなく暗黙的にやっていることで違和感があるものは「俺はこのルールが出来た理由は分からない、だからこそ疑問なんだけどこれはどういう目的のためにやっていることなのか」と何も分かってないからこそ出来る質問をしました。
それで私に説明する間に、チーム自ら「なんでやっているのか」を再確認し、要らないものは廃止、改善できるものは改善していきました。
終わりに
上記の様々な活動と優秀なチームメンバーに恵まれ、今は安定して成果を出せるようになったと思いますが、課題はキリがないし、常にその課題を解決し、より大きい成果をチーム自らの変化・改善で出していけるようなチームづくりは終わりがないと思います。
今は他チームとの連携が必要な開発の最適なフロー設計、大きくアーキテクチャーを変えていくために少しずつ既存を弱らせていく動き、よりチームメンバー同士の理解度アップと新しいチームメンバーの迎い入れなどをチーム自ら推進しています。決めきれないときや、違う観点でのアドバイスが必要な場面では私が入って話をするような形にとっていますが、まだまだ良くしていきたいところが多いのが事実です。
でも以前と比べると、施策開発中でもチーム自ら様々な課題を解決出来る、改善できるという自信がかなりついているし、成功体験とやっていくことの抽象度を上げていくことでよりよいチームになっていくと思っています。
私のこのような経験がこの記事を読んでいる皆さんに一つのヒントになることを願います。
ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？