HRTech領域で「若者の価値を最大化する」事業を展開している株式会社Traimmuというスタートアップで共同創業者・CTOをしている佐野です。

突然ですが「Tech Lead（テックリード）」というポジションをご存知ですか？

Twitterの投票機能でアンケートをとってみたところ、約35%がテックリードになりたい、そして約半数がテックリードについてよく知らないとのことでした。
cf.) https://twitter.com/yppon_s/status/1086106209424306177

現在、弊社で「テックリード」ポジションのエンジニアを絶賛募集中なのですが、自分自身もテックリードとして働いた経験がなく、どういったエンジニアがテックリードとして相応しいのかを考えたり調べたりしている中で、Jason Liszkaさんの記事「Good Tech Lead, Bad Tech Lead」に出会いました。

この記事がとても良記事で、ぜひより多くの日本のエンジニアにも読んでほしいと思ったので、拙い英語力ではありますが翻訳をさせていただきました（本人から翻訳・転載の許可を頂いております）。訳し方やニュアンスに自信がない部分は原文も併せて載せています。

・・・

これは、Ben Horowitz氏の「Good Product Manager, Bad Product Manager」にインスパイアされて書いた、Foursquareでのテックリーダーシップに向けたガイドです。

チームワーク

良いテックリードは、チームメンバーの一員として振る舞い、チームが成功したときにはチームメンバーのおかげで成功したと考える。

テックリードがつまらない汚れ仕事をするのに一役買い、障害をクリアにすることで、チームが100%の力を発揮できるようになる。

テックリードはチームの技術的な能力を広げるために働き、重要なシステムの知識は1人や2人に集約されないように心がける（making sure knowledge of critical systems is not concentrated in one or two minds）。

悪いテックリードは人目を惹くタスクをし、その仕事をやり遂げたという手柄に動機づけされる。悪いテックリードは、概して目の前のことしか考えずにエンジニア組織を犠牲にし、チームに利益をもたらすプロジェクトはチームメンバーにやらせる。

技術的なビジョン

良いテックリードは、プロダクトの技術的な方向性についての総合的なビジョンを持っていて、チームがそれを理解していることを確認する。

良いテックリードは主要な部分を他のチームメンバーに委譲し、メンバーに意思決定を促す（They delegate feature areas to other team members and let them own their decisions）。

彼らは、チームメンバーが賢明であることを認識し、メンバーを信頼し、プロジェクトの重要な部分に取り組む際にメンバーに頼る。

悪いテックリードは、技術的な方向性の説明を嫌がり、意思決定を押し付ける。悪いテックリードは頭の中で重要な組織的な知見を留め、役立つドキュメントを作ったり広めたりすることでレバレッジをかけることに失敗する。

議論

良いテックリードは、議論を聞き入れ、促す。

チームが議論を解決できないときは、解決するのに役立つ思考プロセスやフレームワークを示す。良いテックリードは過去の結論を議論に持ち込むことなく、チームメンバーに素晴らしいアイデアを追い求めることを常に許容する。

悪いテックリードは、チームの生産性を妨げ、解決案のないまま長々と議論するのを許す。ときには「それは既に決まったことだ」と言って新しい議論を途中で止めさせてしまう。悪いテックリードは、チームが正しい意思決定をするよりも自分が議論に勝つことを重要視する。

プロジェクト管理

良いテックリードは先見的である。技術的な進捗が予定通りであることを確かめる。見積もり通りにいくようにチームメンバーとともに働き、マイルストーンを設定する。良いテックリードは懸念事項を予想し、問題が生じる前に対処できるようにする。技術的な障壁を見つけ、チームがそれを避けるのを手助けする。彼らは分担できるのに被っている部分を見つけ、また逆に十分に行き届いていない部分を見つけ、それにリソースを向ける。

悪いテックリードは問題が起きてから対応する。彼らは委譲はするが、上手く進むようにフォローしない。中間目標を定めず、全てが最後まで一気に上手くいくことを望む。複雑なシステムのローンチ直前のエンドツーエンドテストまで待ったままでいる。興味深いが重要ではない仕事にチームが時間を浪費することを許してしまう。

現実主義

良いテックリードは、現実主義で正しいことと出来ることのバランスを取る。

上手く楽をするが、決して怠惰ではない。チームに手っ取り早い方法や進行を妨げる問題を避ける方法を促し、ローンチに必要な最小限のインフラストラクチャを構築する。良いテックリードにとって、コードの品質、コードレビュー、テストは納期通りに完成させるのと同じくらい重要だ。

悪いテックリードは、短期目線で時間を節約するためにショートカットするが、長期的に見るとよりコストをかけており、技術的負債を積み上げてしまう。彼らは、その場しのぎでも良い状況と完璧が求められる状況を区別できていない。

コミュニケーション

良いテックリードは、自分がコードを書くよりも効果的なコミュニケーションの方が自分の大事な役割であることを知っている。

また、チームがより効果的に時間を使えるようにすることに時間を使う。良いテックリードは、チームが機能するためにはコミュニケーションにかかるコストが必要なものだと分かっていて、チームの生産性のために時には個人の生産性を犠牲にする。

悪いテックリードは、自分がコードを書いているときが最も生産性が高いと思い込んでいて、コミュニケーションは気が散るものだと思っている。彼らはチームの生産性のためではなく、自分自身がベストな仕事ができるように最適化する。リードする時間を取らなければならないとフラストレーションを感じる。

プロダクトとの関わり方

良いテックリードは、プロダクトがどう機能すべきかについてプロダクトマネージャーやデザイナーと会話をする。自分が賛成できない決定を押し返すことを恐れないが、プロダクトのゴールを常に意識しており、受け入れるタイミングをわきまえている。

良いテックリードは、技術的により難しくないプロダクト構築の代替案を提案することで、技術的な制約に対するクリエイティブな回避策を見つける。そして、トレードオフを示すことでプロダクトマネージャーやデザイナーが技術的なチャレンジを理解できるように手助けする。

悪いテックリードは、プロダクトに関わる意思決定を「壁の向こう」に放り投げ、プロダクトのオーナーシップを取らない。彼らは技術的な制約のために反対をするが、代替案や説明をしようとしない。

柔軟性

良いテックリードは、プロダクトの仕様変更に柔軟で、予想外の出来事にも落ち着いて対応する。変更が起きることを予め見込んでおり、変更に対応するためコードを設計する。

悪いテックリードは、仕様変更があると動揺する。また、変更が起きそうにない部分の設計を早く一般化しすぎる（prematurely generalize their design in areas where changes are unlikely to occur）。

性格

良いテックリードは、寛大だが自分の意見をはっきりと述べる。悪いテックリードは、対立的ですぐ人につっかかる。良いテックリードは、自然な存在感があり（Good tech leads emerge naturally）、技術的な能力や経験を通して信頼を獲得する。悪いテックリードは、自分の肩書には尊敬と権威が与えられていると思っている。良いテックリードは、常に改善する方法を探している。

悪いテックリードは、フィードバックをもらったときに自己防衛をする。良いテックリードは謙虚で、チーム全員に自信を持たせる。悪いテックリードは傲慢で、チームメンバーに劣等感を感じさせるのを好む。

・・・

株式会社Traimmuでは「Good Tech Lead」を絶賛募集しています！

我こそはGood Tech Leadだ／Good Tech Leadになりたい、という方は是非お気軽にWantedlyやTwitterでご応募/ご連絡ください。

Twitter：@yppon_s
Wantedly：学生向けの次世代キャリアプラットフォームを創るテックリード募集