ソフトウェアエンジニアの業界において、各ロールは責任分界点が曖昧になりがちだ。
プロジェクトによって責任分界点は異なるが、ベースラインとしての標準的なテックリードの責務は考察しておきたい。一般論や持論がなければ責任分界点の議論に乗ることはできないためである。
前提：テックリードとは
テックリードは一言で言うと、「技術的な知識を提供することでチームをサポートし業務を円滑に進める役割」だ。
「技術について最も詳しい人」ではない。つまり、能力の話ではなく役割の話だ。そして、エキスパートではなくリード・マネージメントの役割だ。
参考にできる資料がないか漁ってみた
責務について検討するために一般論をネットから漁ってみる。
すでに賢い人たちが議論し尽くしているはずの命題だから、私がゼロから検討するのは車輪の再開発となる。
共通する部分があれば、おそらくそれがテックリードの責務として一般的だと言えると仮説を立てた。
- GitLab – Tech Lead at GitLab
- GOV.UK – Responsibilities of a Tech Lead
- StaffEng – Staff archetypes
- Dropbox – Engineering Career Framework / Technical Lead Archetype
- Nimble — Technical Lead Handbook
- Thoughtworks — Tech Lead関連資料
- Tech Lead Handbook
良さそうな資料が複数件見つかった。
共通項を拾ってみようと思う。
各参考資料から拾った共通項
各資料を読んで共通項を拾ってみた。
おおよそこんな感じになるだろう。9分類にまとめることができた。
Technical Direction
技術方針・アーキテクチャ・技術判断を導く
Execution
大きな仕事を分解し、優先順位を整理し、チームが継続的にデリバリーできる状態を作る
Engineering Process
イシュー管理・レビュー・開発フローを整え、ブロッカーやボトルネックを除去し、品質と速度を継続的に改善する
Technical Quality
品質・テスト・運用性・信頼性に関する基準や課題を整理し、技術的負債を含む品質上のリスクを可視化する
Risk Management
技術・品質・デリバリー上のリスクを特定し、必要なレビュワーやステークホルダーを巻き込み、リスクと責任の集中を避ける
Team Enablement
自分がすべて実装するのではなく、レビュー・メンタリング・移譲によってチームの技術的な出力と自律性を高める
Alignment
PM・EM・他チーム・ステークホルダーとの間で、技術・ビジネス・スケジュール・リスクについて認識を合わせる
Team Awareness
1on1などの継続的な対話を通じて、メンバーやチームの状態、表面化していない課題・懸念・リスクを把握する
Engineering Culture
速度・品質・顧客価値・ビジネスリスクなど、チームが技術判断を行う際の価値基準を形成する
一般的なテックリードのイメージや仕事と整合しているはずだ。
誤解しそうな点について補足を入れる。
「Technical Quality」について
テックリードは各タスクの品質を担保しない。品質に責任を持つのは作業者。
テックリードは品質を向上させるのが責務であり、テックリードが全タスクに品質責任を持つのは物理的に不可能。
「Alignment」について
これはテックリードがステークホルダーと直接会話するという意味ではない。
メンバーが直接ステークホルダーと会話しても問題ない。結果として情報の認識があっていれば良い。
むしろテックリードだけがステークホルダーと会話できる状態下では、テックリードがボトルネックになりデリバリー速度の低下や、バス係数の低下などのデメリットが支配的になる。
「Risk Management」について
リスクを整理し、情報として管理するのはテックリードであるが、リスクに対して実際の実行を意思決定するのがPMであることは注意が必要。
テックリードの責務は、PMに対して、リスクの対処を判断可能な形式に情報を整えることまでである。
テックリードはリスクの対処に意思決定する権限はない。
リスクを記録し、PMに意思決定を促すことで責務を果たすことができる。
9つの分類は細かいので3層に分けてみる
9つの分類は、3つのレイヤーに分けることができると考えた。
以下のように分けると良いだろう。
（１）成果を作る
- Technical Direction
- Execution
- Technical Quality
（２）成果を出し続ける仕組みを作る
- Engineering Process
- Team Enablement
- Alignment
- Team Awareness
（３）判断基準を作る
- Engineering Culture
改めてテックリードとは
テックリード自身が全部を実行するのではなく、技術的な意思決定・情報・リスク・開発プロセスがチーム内で適切に処理される状態を作る役割を指す。
まとめ
海外ではこういったジョブディスクリプション（Job Description／JD）を書くのが一般的だそうだが、残念ながら日本ではまだそうではない。
テックリードの責務の認識は、会社や個人によってバラバラだ。
この記事はあくまで参考として、自身や自身の所属しているプロジェクトのテックリードが何かを定義して欲しい。
書籍紹介
ウィル・ラーソンのスタッフエンジニアという本はテックリード的な仕事についてより詳細に分類し、それぞれの特徴などがまとめてあります。
また、シニアエンジニアを目指すエンジニアに対して、仕事のコツを伝授する、というのが目的の本です。現在テックリードでこれからシニアエンジニアを目指したい方は読んでみるのも良いかもしれません。
アフィリエイトではありません。
コメントを残す