Site icon imageganyariya blog

お仕事で約 1 年間務めたチームリードのふりかえりと今後について

はじめに

お仕事において、2024/12/01 にチームリードを新しい方に交代させていただき、ganyariya はチームのメンバとして戻りました。

今回の記事では

  • チームリードとしてのふりかえり
  • 交代した理由
  • 今後どうしていきたいのか

についてまとめることで、きちんとふりかえりを行って今後のエンジニアとしての方針を将来の ganyariya のために示しておこうと思います。

チームリードの期間

ganyariya は 2022 新卒であり、 2024/12/01 現在においては社会人として 2 年 + 10 ヶ月働いています。

プロダクトのサーバチームのリードとして交代させていただいたのは 2023/10 からです。
そこから約 1 年間チームリードとしての機会をいただき、支えていただきながら多くの経験をさせていただきました。

チームリードにならせていただいた経緯としては

  • 自分がチームリードを経験してみたかった
  • 今後スペシャリストに進むか、マネジメントに進むか、の最初のステップである
    • まずはリードをやってみることで、自分がどの道に進むかがわかること
  • 前リードの方が別の部署に行く必要があった

ためです。

いろいろな方に支えていただきました… ありがとうございます 🐈

チームリードでやったこと

チームリードとしては以下のようなことを行ってきました。

  • 実装面
    • センシティブな箇所の実装
    • 障害対応
      • 方針相談
      • 緊急修正
      • 根本対応
    • コードレビュー(でかい)
    • 実装方針相談
  • 運用面
    • サーバチーム定例の進行
    • その他定例の進行
    • 他チームとの相談の進行(でかい)
    • ドキュメント化・技術共有会(でかい)
  • タスク・スケジュール管理(3ヶ月)
    • タスクアサイン・工数初期見積もり
    • スケジュール調整(でかい)

上記のうち (でかい) と記載した箇所が大変な箇所であり学びの多い箇所でした。

チームリードで得た学び

コードレビュー大変だけど品質を保ちながら運用するうえでとても大事

「技術的に品質・バグの観点から責任を追う」を目標にできるだけすべての PR をレビューさせていただいていました。

すべてを細かくみることはできない、ということに途中から気づき、後半はロジック・バグ・設計の観点を優先して見るようにしました。

どうしても運用しているとコードの品質は下がっていきますが、レビューを通すことでできるだけ既存のコードを壊さない設計・コードの書き方を担保できます。
長期的な運用をするうえで第三者の目を取り入れる・改善するステップとしてレビューは大事だなと改めて気づきました。

レビューしやすいコード・PR の作り方、レビューするときのいろはドキュメントを用意してみんなで相談できたのも個人的には良かったです。

できるだけみんなでレビューすることで特定の人に負担をかけず、かつみんなでドメイン知識を広げていきたいですね。

チームリードは文字通りチームを「リード」する・動かすものであること

チームリードをやってみて思うのは、他チーム・自チームも含めて「ものごと」「チーム」を動かすものである、と感じました。

  • とまっている施策のリマインドを行って議題を動かす
  • 遅れている施策のサポートを行う
  • 間違っていそうな方針のときに相談役となって方向を揃える

とにかくチームの最大限の効率を上げる・プロダクトを成功させることが目的であり、そのために自らいろいろなところに顔を出して相談する・動かす。

チームをリードしてプロダクトを成功させる。

チームリードは上記に尽きるのだなぁ…と個人的に思いました。

この「様々なことを動かす・チームをリードする」ということがとても疲れました。とにかく疲れました。
動いているものに沿ってその通りのフローで実装する、というのは楽しいです。
が、自分から動いてなにか止まっている物事を動かしたり、方針を相談する、というのは精神的負荷がかかります。

「チームリード」という役職によって動かしやすくなっているとはいえ、そこにかかる精神的な疲労はたくさんあって疲れたなぁ…という1年でした。

チームリードが重い実装やることは運用上難しい

チームリードになった 1 年において行った重めの実装としては

  • ランキング機能の実装
  • とある機能のバックエンド実装
  • OpenTelmetry の導入

くらいであり、それ以外は軽い実装や Kubernetes/Jenkins の改善を行っていました。

「大きな機能を1つ設計してリリースする」をチームリードがやろうとするとそちらがメインとなり、チームとしての効率が下がってしまいます。

そのため、マネージャー・チームリードはいつでも緊急時に対応できるときにある程度余暇をもたせておいて、他のメンバの方々がやりやすいようにサポートすることをメインにする、というのが大事だなと気づきました。

マルチタスクが苦手

チームリードになったことで幅広いものごとに関心事を向けることが多くなりました。
障害対応だったり、機能実装だったり、施策相談だったり、タスク管理だったり、いろいろです。

その結果複数のものごとを考慮するようになった結果、コンテキストスイッチが発生して、今自分は何をするべきなのだっけ…?となることが多かったです。

複数のタスクを並行してこなせるように個人的な Slack の運用を工夫することでタスクを漏らさないようにはできましたが、どうしても集中力が下がってしまいました。

人によってはマルチタスクが得意な方もいると思いましたが、 ganyariya はマルチタスクまるで向いていないなぁと気づくことができました。

チームリードを経験した、ということ

一番の学びは「チームリードを経験した」ということです。

チームリードをやるまでは「チームリードってなんだろう〜」という曖昧な理解でした。
しかし、1年やってみてチームリードがやらなければいけないことを理解できました。

また、3ヶ月でしたがタスク管理・スケジュール管理も行えました。
マネージャーはこれらスケジュール管理に加えて、ヒト・モノ・カネの管理もやるのか〜と想像が少しつくようになりました。

チームリード・マネージャーに対する理解が深まった、というのが一番の学びであり経験です。
これによって、今後自分がなにを目指すべきか?について明確に定まった気がします。

チームリードの反省点

メンバの方にタスクをまるっとお渡ししたほうがよかった

ganyariya はいろいろなことをやりたい・経験したいという指向性であり、他の方にお願いするタスクについて丁寧に前提を説明したり、一緒に相談していました。
内容をすべて知っておきたい・自分が安心した状態でお任せしたい、という ganyariya の心配性ならびに物事に対する好奇心がおそらく由来しています

その結果、(比較的)手厚いサポートとなったぶん、新たにジョインされたメンバの方々が自分で進める、という機会を減らしてしまっていたり、ganyariya がタスクを進める時間が減って残業が増えていました。

新たに所属されたメンバの方々の成長の機会をつくる・自分の時間の確保する、という意味で

  • 守っていただきたい納期
  • 守っていただきたい要件

をお伝えしたうえであとはまるっとおまかせすべきだったなと反省しています。

この観点についてはマネージャーの方にもアドバイスを受けたため、もし今度チームリード(or マネージャー)をやらせていただく機会があったら意識しようと思います。

なぜ交代したのか?

チームリードを交代した経緯としては自分観点だと主に3つあります(組織的には別のもありそう🤔)

  1. サーバチームは持ち回りでリードを回している
  2. ganyariya が他職種や他プロに挑戦したいと思ったから
  3. 技術的な挑戦をしたいと思ったから

という理由です。

ganyariya 自身の大きな理由としては2・3です。

チームリードを1年やっていて思ったのは、なかなか自分自身は重い施策・実装だったりが行えず、どちらかといえばサポート・レビュー・タスク管理がメインでした。

そのため、もっと技術的なことに専念したい・新しい技術に挑戦したい、という気持ちが芽生えました。
技術を伸ばすこと・見聞を広めることは若い方が有利である(覚えやすい)と考えており、そのような技術に倒したほうが将来的によいのかも… 🤔 と思うようになりました。

また、 65 才まで働く、を前提にした場合 ganyariya はなんとあと 38 年も働くことになります。
それまでずっとサーバサイドエンジニアのみか?ということを考えると他の分野も経験しておきたい、そのうえで自分の好きなことをやっていきたい、と思いました。

そうなると、このような他の分野をやるのであれば若いときのほうが有利です。
年齢が上がってしまってからだと習得するのにも時間がかかりますし、転職もおそらく大変になります。

そのため、 27 のうちにクライアントやインフラなど別の職種も 3, 4 年経験することで、自分が何が将来でなにをしていきたいのかを見極めながら、経験を増やしていきたいと考えています。

サーバサイドエンジニアをやり続けていく、といううえでもクライアントを経験することやクラウドインフラを経験することもよい糧になる、と自分は捉えています。

今後について

35 才まではスペシャリストならびにチームリードを目指して、技術の習得とその活用、そして経験を増やしていきます。

かつ、 2025 のどこかで別の分野(クライアント・インフラ)に挑戦して、新しい経験をして成長したいです。
そして 30 ぐらいまで、つまり 3 年ぐらいはそのまま挑戦した分野に身をうずめてサーバサイドとどちらが楽しいか、も見極めたいですね。(おそらく志向的にサーバサイド・インフラのほうが好きなのですが…)

マネジメントについては 35 才をすぎてからで問題ないかなと考えています。
それぐらいの年齢になれば酸いも甘いも噛み分けて、人と話すのがもっとうまくなっていればいいな…
技術を伸ばすのは若いほうが有利ですし、なにより楽しいので。

1 年間チームリードを経験させていただき、とても疲れたものの非常にありがたかったですし楽しかったです。

新たなリードの方のサポートをさせていただきつつ、心を入れ替えてクライアントとインフラの勉強を頑張っていこうと思いますー!