チームを立ち上げ、自走するチームにするために
はじめに
こんにんは。
Rettyでエンジニアリング部門のマネージャーをやっております、李と申します。
現在複数のチーム・メンバーをサポートし、開発を通じて事業成果につなげることを責務としています。
この記事は、Retty Advent Calendar 2022の12月24日の記事として作成しています。
今回話す内容
今までは既存チームのマネージャー交代という形でしたが、今回は全く新しいチームを立ち上げるため、今までやったことないことが多かったので、その中でマネージャーとしてやったことと、そのチームが落ち着いて自走するまでやったことの一つの事例として見ていただければと思います。
チームを立ち上げることになった
これで2年連続になりますが、また別のチームのマネジメントをやることになりました。去年のお話はこちら！
基本的に課題があれば解決したいし、責任を持って様々な領域で活動することが好きですが、今回は「やったことない」ことが多かったのと、私が自ら「こういうチームを作ってこういうことをやりたい！」という形で立ち上げるわけではなかったため、戸惑いや悩みも、失敗もありました。
チームを立ち上げて軌道に乗せるまで大きく立ち上げ前と立ち上げた直後が大事だと思うので、それぞれのフェーズにフォーカスして話して行きたいと思います。
立ち上げる前に
このフェーズでは私はチームの目的を知り、それをメンバーに分かってもらうことにフォーカスしました。
具体的には以下のようなことを行いました。
チームの役割定義：このチームは何を目的とするチームなのか
自分の役割定義：自分がこのチームのマネジメントをすることで期待されることはなにか
メンバー選定：どんなメンバーが配属できるか
メンバーの役割定義：メンバーにこのチームの目的はどう伝え、どのような役割を当てるか
チームの役割定義
今回は私が課題感を持ってチームを立ち上げたわけではなく、部門として技術課題解決の空白を埋めるべくして、チームの立ち上げは決まった状態でマネージャーとして配属となった形です。
まずチームを立ち上げる理由を確認し、このチームが何をするチームで、何をすればチームの成果と言えるのかを明確にする必要がありました。
チーム立ち上げの指示者である部門長へのヒアリングで以下を確認しました。
チームを立ち上げる背景と成果とはなにか
すでに決まっていることはあるか
今回はメンバーがすでに決まっていた
今後のチームがどうの方向に行くことを期待しているか
このヒアリングで、このチームの会社・部門の中での役割・位置づけができ、チームの生存期間も明確にすることができました。
ここで大体チームの役割と名称が決まっていました。今回作り上げるチームは「生産性改善」チームでした。
自分の役割定義
チームの役割がわかると、自分の役割も定義できます。大きく分けると、リード型かサポート型かを考えました。
短期で数字を作るチームならなりふり構わずリーダーシップを取って目標達成に向けるだろうし、中長期を見据えて全社に技術的底上げを図るチームなら自分がリーダーシップを強力にするよりはチーム自体がチームの定義をしっかり理解して自ら動けるようにするのが大事になるなど、チームの役割・生存期間によってリード型で積極的に指揮を取るか、じっくりサポートして成長を促すかを決めて、チーム・メンバーに接していくことで、メンバーにも意図が伝わりやすいと思います。
今回は全社における手がつけられない技術課題を発見・解決していくという背景を汲み取って、自分の役割をサポート型として定義しました。
チームメンバーと会話する
今回はチームメンバーがすでに決まっていたこともあって、チームメンバーを自ら選定する必要はありませんでした。
その代わりに、すでに決まっている面々に対して以下のようなことを1:1を重ねて把握しました。
どういう強みや興味があるか
社内で達成したいことはなにか
将来的にキャリアをどう考えているか
チーム内での役割をメンバーそれぞれに配分していく中で当然必要な情報になりますが、これからのマネージャーとメンバーの関係性構築のためにも必要な情報です。
今回は私がすでにマネジメントをしていたメンバーが複数人参加する形だったので、割とスムーズにできたと思ってます。
新しいチームを立ち上げる際には関係性がある程度構築できているメンバーを一定割合配置してするのも良い手かもしれません。
その後はチーム全体にはこのチームの目的と全社の中での位置づけを伝達し、各々の役割も伝えました。すでに1:1で合意が取れている内容で、本人はもちろんチーム全体としての納得感も高かったと思います。
注意点は、個人のキャリアや目指すところは1:1でしっかりその人にフォーカスしてヒアリングすることです。個人の心の内側はマネージャーが勝手に公開範囲をチーム全体としてはいけません。
事例をヒアリングする
ここまで来たら立ち上げる準備はある程度できたと思いますが、今回は社内で事例のないチームで、その目的である「生産性改善」はマネージャーもメンバーも理解が浅い状態でした。
そのままでは不安が大きかったので、他社事例を探しました。偶然にもオフィスの隣同士であるatama plusさんの宮原さん(@pandineer)の記事を見つけてはカジュアル面談を申し込み、いろんな話を聞かせていただきました。
この縁から、atama plusさんとは生産性改善をテーマに両社で集まって勉強会を行っています。
また、cybozuさんの宮田さんとのカジュアル面談でお話をすることができ、非常に良い事例を伺うことができました。
やや強引とも見える他社事例・ノウハウのヒアリングにはできるだけチームメンバーも参加してもらい、私から伝えることがなくても今後我々がやっていくこと、その中で大事にすべきこと、課題になりえることなどをメンバー自ら考えられるようにしました。
私もメンバーも分かってないのはお互い様で、マネージャーだけが話を聞いてみんなを引っ張っていくのではなく、メンバー自らが思考し、行動し、成長していくチームにするのが私の役割だからです。
この動きはチームの立ち上げにおいて、
イメージできていなかったチームの形をイメージできるものにしたと思っています。
この記事を借りて、atama plusの宮原さん、cybozuの宮田さんには改めて感謝の言葉をお送りしたいです。本当にありがとうございました！
立ち上げたら
チームの名前が組織図に入り、正式にチームとして立ち上がりました。
ここからは成果を出していくのみです。チームメンバーもやる気が溢れ、私からの指示がなくても様々な行動を起こしています。
他チームにチーム紹介を行う
新しいチームで、社内に事例がなかったチームを立ち上げたため、このチームの発足に関わってなかった他チームの人たちはどんなチームなのかまだ分かっていませんでした。
そのままでは他チームと連携するたびにチームの紹介をしなければいけません！とても面倒なことですし、他チームが相談・お願いをしてほしいものがあっても、このチームと話していいものかも分からない状態になってしまいます。
そのため、チームの窓口役割を任せているメンバーが、Tech Weekendという社内技術イベントでチームを紹介し、チームの定義、役割、主な業務内容、協力してほしいこと、協力できることを伝えました。
この紹介から、他チームのマネージャーも兼任している私の周りから、「この内容は生産性改善チームに相談するのがいいのではないか」などの話が結構出るようになりました。
実際チーム間での業務が活発になり、自然と組織の中に溶け込むまでは時間はかかりますが、始まりとしては分かってもらうことが大事だと思うので良かったと思いますし、これをマネージャーの私からではなく、メンバーから伝えられたこともチームメンバーのこのチームに対する理解と意欲が伝わってよかったと思います。
問題が発生
このような、良い動きが続く中で、本当に良い事だらけだったかというと、そうではありません。
実は生産性改善チームは、発足してから大きな悩みを抱えて、何回も集まって議論していることがありました。
それはこのチームは何をやるチームなのかです。
あれ？チームの定義で決めたのでは？と思われるかもしれません。
でも、決めたからといってそれがそのまま正解・正しいもの・不変なものであるとは限りませんし、間違えることも、考慮できなかったこともあり、それがあとになって問題の火種になることもあります。
生産性改善チームという名前でありながらも、このチームが改善させたい生産性とはなにかが明確に整理されてなかったのが問題でした。
エンジニアの生産性改善にフォーカスするのか、その結果であるRettyのサービス全体の改善にフォーカスするのかが曖昧なままで、「生産性」という言葉が先行してしまっていたのです。
その結果、チームはエンジニアの生産性改善にフォーカスして自らの活動範囲を狭めてしまいました。様々なものに対し、これは我々が取り組むべきことかどうかを悩むようになり、毎週その仕分け作業をやる時間まで発生していました。
私自身もここでかなり混乱していたので、上司で現VPoEの常松と多く話したあと、チームの定義の変更をメンバーに伝えました。
このチームはRettyのサービス全体の改善にフォーカスする、その中でエンジニアの生産性改善が必要ならそれもやる。取り組むべきものの仕分けではなく、優先順位で判断する。
この内容をメンバーに伝えるのに1時間のミーティングを2回ぐらい行ったと覚えています。メンバーにもかなり負荷になったと思いますが、今となってはあのとき転換をちゃんと伝えておいてよかったと思ってます。
定義してきたものは不変でもないし、全てが考慮されているとも限らない。
重要なのは問題を直視し、その解決のために大胆・柔軟に変化を起こし、根気よく伝えていく。
マネージャーとして良い学びがあった場面でした。
自走するチームに
上記のような問題があり、チームの定義に変化があったとしてもすべてがなくなって再スタートなわけではありません。
メンバーのチーム役割定義に関する理解度はむしろ以前より高くなっていましたし、マネージャーがチームの窓口となるのではなくメンバー自らがチームの代表となり、普段のチーム運用・改善を行い、マネージャーは全社・部門レイヤーからくる大きな方向性の伝達と相談、承認に随時応じるといったサポート役に徹するというのはチーム立ち上げ前・立ち上げ直後に行った様々な動きの効果がそのまま出ていました。
以下の内容がマネージャーとメンバーに共通してできていれば、自走可能なチームになるのではないか、と思います。
チームの役割に対してできるだけ深く理解すること
お互いの役割を理解すること
間違いや変化は完全になくすことは難しいので、柔軟に対応すること
これがマネージャーとメンバーで会話を重ねてこそできることは言うまでもないですね。
現在も、チームの四半期の目標を決めるために取り組むテーマ、挑戦したいこと、そこから落とした具体的なチームの目標、その達成のための個人目標を四半期の初めにかなり時間をかけてお互いの理解を深めるようにしています。納得できている部分、モヤモヤが残っている部分などを率直にその場でもあとからでも話してくれる関係性は、私としては誇りに近いものだったりもします。
おわりに
アドベントカレンダーの記事は毎年私自身の振り返りのようなものですが、今年もこうやってまた新たな話が書けるようになって、自分の成長も感じます。過去3年分の記事も改めて貼っておきます。
マネージャーの成長は、どれだけハードなことをやってきたのかに限るという話も聞きますが、これからもいろんな記憶に残る体験を重ね、成長し続けたいと思います。
ここまで読んでいただいたみなさん、ありがとうございました。
良いお年を。