はんなりと、ゆるやかに

アジャイル、スクラムが好きなITエンジニアが日々から学んだことをアウトプット

Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論! - に参加

Tech Lead Night vol.0 - 各社のテックリードが、気になるテーマを徹底討論! - に参加しました。

legalforce.connpass.com

開催概要のとおり、テックリードというキーワードについて幅広くお話が伺えました。気になった部分についてまとめていきます。

テックリードの役割は企業によって異なる

「テックリードとエンジニアリングマネージャーの違い」というテーマでは「テックリード」という役割を設けていない企業もあり三者三様でした。共通点は「技術でチームやプロジェクトをリードする」という部分です。技術選定や技術に関わるリスクヘッジ、品質の担保などキーワードが上がっていましたが、細かいポイントは企業によって異なりそうです。また、人やタスクの管理は別のポジョンの方が担っていることが多そうでした。

他の方々はテックリードはどう考えているのか調べてみました。
テックリードという役割 | by Shimpei Takamatsu | Medium
良いテックリード、悪いテックリード - 小さなごちそう
「自らを実験台として新たなキャリアを切り拓け」 及川卓也氏が贈るアラサーエンジニア進化論 - エンジニアtype | 転職type
Tech Lead(TL/テックリード)の役割 - サンフランシスコではたらくソフトウェアエンジニア - higepon blog
テックリードになって気をつけていること - Qiita

まとめるとテックリードとは以下のような人物かなっと思いました。

  • 技術的知見とドメイン知識が豊富
  • 技術でチームのアウトプットを最大化する
  • プロダクトマネージャー、デザイナーと対話し、技術面から意見する
  • プロダクトのリリースに対して献身的

あえて役割を分担しないという考え方もある

テックリードとエンジニアリングマネージャーという境界を引くことで、お互いの範囲外に落ちたタスクを拾う人が減ると困りますよねという発言もあり考えさせられました。なんのためにテックリードという役割を設定するのか、どういう期待があるのか、そのあたりを明示しないと悪影響もありそうです。

以下のブログも近いことを言っていて、庭という概念は良いですね。タスクが落ちるという表現だと、野球の守備範囲という概念でも表現できそうです。
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記

思想を伝えてエンジニアの組織文化を作る

文化を広めるには色々なものに宿る思想や考えを発信し、伝えた方が良い。「なぜ」が共有されることで文化が醸成される。

ビジョンを伝えないと人は動かない」という記事でも書きましたが、Howだけ伝えられても人は納得して行動しづらいですね。その状態だと文化もできません。経験豊富なベテランの中では当たり前になっていることも、他のメンバーは共通の暗黙知がなく、ルールだけが存在する状態になりかねません。当たり前のこともWhyから伝えることが大切ですね。

まとめ

  • テックリードの役割は自社で定義したほうが良さそう
  • ムリに仕事を役割に分けると、落とすタスクが出てしまう
  • 文化を醸成するにはWhyを伝え続ける

運営のみなさん、登壇者のみなさん、参加者のみなさん、ありがとうございました。