テックリードを過去に3年くらい, まだ「テックリード」という名称が社内で正式に制度化されていない頃も含めると6年くらいやっていて, 今はテックリードを若者に譲っていわゆるエンジニアリングマネージャ(社内での名称はいまのところ「グループチーフエンジニア」)をやっている. 現役テックリードの悩みを経験者として聞くと「そうそう, あるある」と思う一方で, まとめてみるとそれらは実はその先のキャリアパスに綺麗につながっていることに気づいた. 以下, 社内向けに書いたテックリードの抱えるプレッシャのまとめに, キャリアパスの話を加筆したもの.
テックリードの悩み
テックリードとして意思決定していくのはプレッシャだよねという話題が出た. テックリードに限らずあらゆる意思決定者に共通のことだとも思う. ぐいぐい引っぱっていくリーダタイプなのか, みんなの意見をうまいことまとめるサーバントリーダタイプなのかで難しさは異なってくるかもしれないけど, けっきょく意思決定がプレッシャであることには変わりない.
僕はこのプレッシャにはすっかり慣れてしまって最近はあんまり意識してなかったんだけど, めちゃくちゃプレッシャがあると感じていた時期はあった. そういう不安を感じていること自体をあまりリーダ的な立場では言いづらいと思うので, 過去のことと思えるならばこそ言語化しておくとよいんじゃないか.
(プロダクト開発チームの)テックリードとして感じるプレッシャをぱっと思いつくままに類型化してみると以下の4つだろうか. いちおう上から大きい順(僕にとって大きかった順)のつもり.
システムに関するプレッシャ
なんと言ってもこれが一番大きい. リリース前には「自分の設計・技術判断したこのシステムは, 果たして思った通りに動くのだろうか」という不安がある. 何かとんでもない思い違いをしていて, リリースした途端にすべてが崩壊するんじゃないか.
僕が一番プレッシャを感じていたのは, はてなブックマークのシステムリプレースプロジェクトのときだった. 旧システムで自分が把握できていない箇所があって致命的な欠陥につながってしまわないか, 新システムの根本設計をミスっていて実トラフィックでは破綻したり, 開発を進めていったら大幅な設計変更が必要になってしまったりしないか, 寝ても*1覚めてもずっとそんなことを考えていた. 旧システムと新システムのあらゆる仕様と実装を常に脳内メモリに展開していて, そのせいで疲弊していた.
プロジェクトの最初のリリースをしたとき, チームにジョインしたばかりの新卒メンバにリリースコマンドのエンタキーを押してもらって, 彼はそのとき手が震えていたけれど, 僕は案外(見かけには)平然としていた. それはなぜかと言うと手が震えるような気持ちはそれまでの間にさんざん抱え続けてきたからだった. 最初から心中では手が震え続けているので, いまさらリリースする瞬間に手は震えない.
蓋を開けてみると, システムの設計は驚くほどよくできていて, と言うとちょっと言いすぎかもしれないけど, 基本的なところは間違っていなかった. でもリリース後にも不安は続いた. 急に検索botが押し寄せてトラフィックが通常の何倍もやってきても余裕で耐えたりした辺りで, ああ, なんとかうまくいったようだ, とやっと実感できた.
こういった経験が増えてくると, この手の不安は少なくなってくる. 十分に考えてやっているのだから, そうそう致命的なことにはならないだろう, と思えるようになってくる. ただ, どんなに不安を抑えても, それが変に楽観視することにはつながらない程度にはプレッシャはある.
スケジュールに関するプレッシャ
プロジェクトマネジメントを担う人(スクラムマスタ等を含む)がスケジュールを気にするのはわかるが, テックリードもこの不安が大きいのか? 実際のところ, 技術的な意思決定, たとえば大きなプロダクトや機能のどこから実装するか, といった判断は実はスケジュールに大きく影響する. むしろプロジェクトマネジメント手法(戦術)よりもこちら(戦略)の方が影響が大きいかもしれない. だからプレッシャも大きい.
せめてもの救いは, この部分をミスっていてもスケジュールの遅れに対する因果関係はよくわからない(事前にはもちろんわからないし, 事後にもそこまではっきりとはわからない)ことだろうか. 救いがないのは, 理由はどうあれよく失敗しよく反省することでもあるので, 次こそはうまくやるぞという気持ちが新たなプレッシャとなること.
プロダクト価値に関するプレッシャ
テックリードの役割の一つは, プロダクトの価値を高められるような最高の技術的判断を下すことのはず. であれば, 判断を一歩間違えばプロダクトの価値を損う可能性がある. 技術的にこういう理由でそれは現実的ではありません. 技術的にはこうなっているとありがたいのでどちらでもいいならこれでいきませんか. そういう話をする度に, 致命的に価値を毀損してしまうかもしれない不安がよぎる.
プロダクトの価値がなんなのかはっきりしているなら, 間違った判断を下しそうになったら気づくだろうし, もし自分が間違ったことを言っても指摘してもらえるだろう. でもプロダクトの価値がなんなのかはっきりしていなかったら……これは恐怖でしかない. 僕はここのところずっとプロダクトマネジメント方面に注力していて*2, それはこの恐怖心を克服したいから. 自分の関わるチームのテックリードやエンジニアたちが, この恐怖を感じなくていいようにしたいから.
人に関するプレッシャ
テックリードにとってピープルマネジメントはその職責ではないとされる(ことが多いとおもう, たぶん). しかし, チームメンバには最高の仕事をしてほしい. その方がプロダクトのためになるし, 自分の不安も軽減される.
逆に言えば, チームメンバが働きづらさを感じれば, 最高の仕事をしてもらえない. そのくらいだったらまだいいが, 自分のリーダとしてのあり方のせいでメンバが働きづらさを感じ, そして辞めてしまったとしたら. リーダ的な立場であれば誰しもこういう不安はある.
だったら, チームメンバに最高の仕事をしてもらうために, それによって自分の不安も軽減されるように, メンバのためにできることは何でもしよう. 僕がテックリードのときに1on1をやっていたのはこういう気持ちからだった. おかげで, いまではピープルマネジメントも主務の一つになっているけど, 抵抗なくやれている.
キャリアパス
4つのスキル領域
上の4つプレッシャは, 以下のエンジニアリングマネジメントの4つのスキル領域に綺麗に対応している.
- テクノロジマネジメント
- プロジェクトマネジメント
- プロダクトマネジメント
- ピープルマネジメント
逆に言えば, これらのスキル領域に必要とされる専門知識を学んでいけば, 教科書的なやり方でプレッシャを軽減できることを意味する(もちろん学ぶだけでなく経験も必要ではあるが). 各スキル領域の参考書は以下の記事によくまとまっている.
4つのスキル領域で言うと, テックリードはテクノロジマネジメントを主な職責とする役割ということになる. プロジェクトマネージャはもちろんプロジェクトマネジメントを担う. 僕の会社では「シニアエンジニア」の役割を持つ人は他のエンジニアのコーチングをすることになっており, これはピープルマネジメント(の一部)をやっていることになる.
キャリアアップするためには
一方, 「エンジニアリングマネージャ」と呼ばれる人たちは, 一般的にこれらのスキル領域のうちの複数, もしくはすべてをカバーすることが要求される. ということは, いま単一のスキル領域を担当している人は, 他の領域にも手を伸ばすことでエンジニアリングマネージャへの道が開ける. そのとき, 上に挙げた4つのプレッシャのように, 自分の中で「これはなんとかしたい」と思う領域はどれかを考えるといいんじゃないだろうか.
最初は「テックリードだけどプロダクトマネジメントのことも考える」とか「プロジェクトマネージャだけどピープルマネジメントもする」とかから始めて, だんだんできる領域を増やしていくとよい. 僕の場合は, もともとテックリードをやりながらシニアエンジニアを兼務していて, プロダクトマネジメントにも力を入れたくなったのでエンジニアリングマネジメントに軸足を移した*3. スクラムマスタをやっていたけど, テックリードもやれるようになる, みたいにして領域を拡大してもよいだろう.
この辺りのイメージを詳しく書くのがこの記事の主題だったのだけど, 途中まで下書きしてぼーっとしていたら将来有望な若者が綺麗にまとめてくれたので, これを読むとよさそう.
おわりに
けっきょく, 4つのスキル領域のうちの1つを担う仕事を任されたら周辺領域にも目を配るとお得という話. プレッシャはあれど, それを逆手に取って学びに変えよう.
