「テックリード」を比較する
テックリードってなんなの？の比較
ここ2年ほどでテックリードという役割をもつテック系企業が急増しています。
うん、テックリードね、技術のリードでしょ。
...うん。
アーキテクトとは違うのかな。なんか微妙にニュアンス違うよな。リードっていってるからマネジメントっぽいこともするのかな。
実際、テックリードとは何か、を語る資料はいろいろあります。なので記事を引用して比較してみます。
(なんだかもったいぶった導入になってしまいましたが、大した結論がある記事ではありません。。)
まず、いま Google 検索から テックリード でトップでヒットする記事がこちら。
本文で言及されていないので私の推測ですが Takamatsu さんが株式会社アカツキでテックリードを務められていたときの話に基づいているようです。
テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。
強調しておきたいのは、テックリードはマネージャーではない、ということである。
また @higepon さんのトークを取り上げた上で、テックリードの主な責任範囲は以下の3つであるとしています。
- コードの品質
- チームの生産性
- アーキテクチャ・設計
つづいて tech lead で Google 検索して上位にヒットするこちらの記事。
Kakovskyi 氏が Atlassian Stride / Kyiv Polytechnic Institute / Video Internet Technologies Ltd でのテックリードの経験に基づいて述べています。
彼の最初の考えは「テックリードはソフトウェアアーキテクトとチームリーダーを足したようなもの」でしたが、いまの彼の定義では誤りのようです。
最後に挙げられている「チームリーダーとテックリードの違い」「アーキテクトとテックリードの違い」がシンプルに表現されています。
- チームリーダーはプロジェクトではなく人物に責任をもつ。
- チームリーダーはピープルマネジメントを行う。
- チームリーダーは個別の貢献をすることを想定されていない。
- アーキテクトはより実践的かつ多様な経験をもつ。
- アーキテクトはより広範囲で複雑なシステムに対して求められる。
- アーキテクトは、残りのチームメンバーが作業できるようにするためのもっとも面倒な作業を担当する。
また、テックリードに求められるスキルとして以下を挙げています。
- プログラミング言語に対して実践的なスキルをもつ
- データストアに関する一定のスキルをもつ
- マルチタスクを伴うプロジェクトマネジメントのスキルをもつ
- ほかメンバーに技術的な作業をさせるためのコミュニケーションスキルをもつ
ほかにも、本文では具体的な話がいろいろと書かれています。日々の達成感を味わいづらい、というのは世知辛いものですね。
こうしてみると先述の Takamitsu さんの記事で言われていた「テックリードはマネージャーではない」という表現に違和感を覚えます。個人的な感覚ですが「マネージャー」という言葉がだいぶネガティブに響くことが関係しているような気がします。
なぜ「マネージャー」がネガティブに響くか。それは "マネージャー" によるマイクロマネジメントによってもたらされる疲弊、でしょうか。過剰なマネジメントによってメンバーは疲弊する、プロジェクトは結果的になんとかなってしまったため成功体験として "マネージャー" はそれを繰り返す、といった悪循環が世のいろいろなところで起きている。
興味深いことですが、書籍「エンジニアのためのマネジメントキャリアパス」では、時として (ジュニアメンバーに対しては) マイクロマネジメントも仕方ないことがある、と述べられています。そのバランスが難しい。
で、この「エンジニアのためのマネジメントキャリアパス」は「マネージャー (というかマネジメントを行うということ) ってキャリア選択も悪くないよ！！」と語りかけてくれます。残念ながらこの記事を書いているいま私はテックリードとは何かという問いに結論を出せていないのですが、テックリードはメンバーのマネジメントにも責任をもつ、ということは言ってもよさそうです。
消化不良で反省。。。またの機会にリベンジします。
