チームリーダーになって3ヶ月の振り返り

これは何？

チームリーダーを担当して3ヶ月が経過したので振り返りをまとめました。

前提

• toBインフラ開発チームのチームリーダーをやっている
  • チームは自分を含めて5名
  • チームリーダーという役職があるわけではない
• toBプロダクト開発のために他にアプリケーションチームが3チーム存在する

チームリーダーとして目指していること

以下の理由から個人的には プロダクトに関わる全ての人の生産性を向上させること を目標に掲げています（と言ってもまずはそのために自チームの生産性を向上させることから）。

• プロダクト規模を考慮すると、単に自チーム（インフラチーム）にだけ焦点を当ててもハッピーエンドを迎えるのは難しい
  • インフラは全てのチームと接合点を持つ
  • プロダクトとしての要件があってこそのインフラである
  • 実はインフラチームもプロダクトのドメイン領域への理解が非常に大事
• インフラはシステム領域における大きな権限を持つことが多く、それゆえ他チームとの心理的な障壁ができやすい
  • お願いする側、される側 という構図ができてしまう
  • ここでのやり取りにコストがかかるほどに、組織全体が非効率になっていく（バッドエンドへの入口）

やったこと

チームが働きやすい環境づくり

• 1on1
  • 個々人のやりたいことや困ってることなどについて共通認識を持つ場として開催
    • できる限りチームのやりたいこと・挑戦したいことに沿った仕事を渡せるようにするため
    • もちろん仕事として違うものをお願いする必要もあるので要はバランス
  • 私には人事権限がないので、その手の話はここでは発生しない
• ロードマップ策定や振り返りなどの旗振り
  • 「チームとしてやった方がいいね（でも大変だね）」系のイベントを開催
    • 実際の実施はチームでやる（これは私のためではなく、チームのためのものである）
  • チーム運営していく上でお互いの認識をすり合わせる場として重要
    • チームがふとした時に「自分達は何のためにこれをしていて、どこに向かっているのだろう？」となるのは不穏なサイン
  • 特にインフラは今後の絵を描くのが難しい仕事だと感じており、モチベーションにつながるものをみんなで作ることは大事
    • 「我々はただ既存のインフラの保守をすることだけが仕事ではない」ということを明示的に知ることは大事
• タスクの整備
  • タスクの期限や重要度などによってスケジュール調整したりなど
• 他チームとの交通整備
  • アプリケーションチームとインフラ間での開発・改修依頼の交通整備
  • 各チーム間の開発予定のシェアや調整
    • プロダクトが全体としてどんな速度でどこに向かっているのかをお互いに知ることは大事
    • 特に人的リソースは有限であり、お互いの認識をすり合わせる必要がある
• プロダクト運用のために必要そうなルールの整備
  • 運用に関する業務フローの改善・共通認識の構築など
    • 既存のチームや新規参画者がルールなどで迷わないようにするため
    • 組織全体がより効率的に活動できるようにするため

採用周りの整備

採用活動（主に候補者を探してスカウトを書く）には今までも携わっていましたが、これまでは「どういう人が欲しいんだっけ？」などの話をチーム内で明示的に行っていませんでした。
せっかく面接に繋がっても後になってミスマッチで終わってしまうと候補者も企業側も徒労に終わってしまうため、その辺りの整備を中心に行いました。

• 採用ターゲットの定義や募集要項を更新
• 技術課題の作成
• 面接フローの整備

たたき台を作った上でチーム内全体でレビューをしてもらい、チーム全員が「今はどんな人を探しているのか？」の共通認識を持ってもらえるようにしました。
採用活動に直接関わるか否かに関わらず、自分達が今どんな人を探しているのかの共通認識を持つことは大事です。

(時間の許す範囲で)開発タスク

• 完全に調整業務だけやる人になる気はないので、時間の許す範囲で今まで通り開発タスクもこなしている
• 優先事項はチーム・組織の生産性を最大化させることであり、それの次に自分のやりたいこと（開発業務）をしている

大事にしていること

主に以下の記事に記載したことを大事にしています。
特に 共通認識の構築 や 心理的安全性 については心がけています（が、やはり一朝一夕で身につくものではないので引き続き）。

https://zenn.dev/nameless_gyoza/articles/the-important-idea-for-team-leader

今後のやっていき

ロードマップに対する継続的な見直し

プロダクトの基盤部分をある程度開発してしまうと、「今期はこの開発をやっていく」といった機能要件の観点での目標を立てることが難しいです。もちろん開発業務もありますが、大々的に目標として置くには少し規模が小さかったり、未決定の事項が多すぎるなどして向いていません。
組織全体の効率化に向けて、アプリケーションチームの開発の助けとなる自動化やチーム間の関わり方の改善（howとしての例: Embedded SRE, Enabling SRE）などを行なっていきたいと思っています。

またロードマップは一度決めたら終わりというわけではなく、実際にそのロードマップに沿って歩みを進め、振り返り、さらにロードマップを見直していく必要があります（それもチームで）。短距離走での取り組みではなく、長い道のりを前提として燃え尽きないようにチームでやっていきたいと考えています。

チームに仕事を任せていく

何やかんやで自分が口出ししてしまうことが多いので、よりチームに仕事任せていけるようになりたいと思っています。
チームに仕事を任せることでお互いの信頼関係の向上やチームのリーダーシップ力の向上にもつながるので、より意識的に実施していきたいです（できれば仕組み化したい）。