テックリードを目指したいと思っても、肩書きが付くまでは何を練習すればよいのかが見えにくいものです。
役割の説明を読むほど、決める、そろえる、育てるといった仕事が並び、どれも任されてから始まる仕事に見えてきます。
けれど公開されている一次情報をたどると、その多くは肩書きの前から小さく始められると書かれています。
私もテックリードを目指して学んでいる途中で、足場にしているのは書籍と公開資料です。
たどり着いたのは、役割の一部を先に小さく引き受け、それを上司と共有できる形で残しておくことが準備の芯になる、という整理でした。
その具体的な形として、今日から手を付けられることが 5 つあります。
準備とは、役割の一部を先に引き受けること
『Software Engineering at Google』は、Google のエンジニアリング文化をまとめた本です。
その第 5 章は、リーダーの仕事が正式な任命を待たずに始まることが多いと書いています。
チームの対立を収める、判断を下す、人の動きを調整するといった仕事に巻き込まれ、それはよくあることで、しばしば偶然に起きる、という説明です。
同じ章には、Google では昇進の前に、一段上の仕事を一定期間こなしていることを求めるという記述もあります。
出典は How to Lead a Team（Software Engineering at Google 第5章）です。
役割が先にあり、肩書きは後から付いてくる、という順番になっています。
Pat Kua 氏も 2020 年 10 月の記事で、リーダーシップを「役割」「集団」「能力」「行動」の 4 つの文脈に分けています。
このうち能力と行動は、肩書きがなくても育てられるという立場です。
リーダーシップのスキルは身につくまでに長い時間がかかるので、必要になる前から育て始めるべきだとも書いています。
記事は Anyone Can Be a Leader（Pat Kua）で読めます。
等級より先に役割を取りにいく、という考え方そのものは、Staff エンジニアとの関係を扱った記事でも触れました。
今日からできる5つのこと
Pat Kua 氏は、テックリードの役割を「開発者」「リーダー」「アーキテクト」の 3 つの円が重なる場所として説明しています。
開発者との違いはリーダーシップのスキルの幅と深さにあり、開発者は全体像を考え始めないと視野がコードの外へ広がりにくい、とも書いていました。
モデルの説明は Tech Lead – Circles of Responsibility（Pat Kua）にあります。
以下の 5 つのうち、前の 3 つは開発者の円の外側を練習するもので、後の 2 つは役割を任せてもらうための動きです。
担当の外まで、システムとして説明できるようにする
アーキテクトの円について、Pat Kua 氏は「ソフトウェアではなく、システムを作る」という見方への切り替えを挙げています。
機能のコードだけでなく、性能や可用性といった品質特性や、ソフトウェアが動く環境とのやり取りまで考える、という意味です。
今日できるのは、自分の担当ではない部分も含めて、1 つのリクエストが入口から出口まで通る道筋をたどってみることです。
どこにデプロイされ、どこで監視され、止まったら誰が気づくのかまで説明できるかを確かめます。
全体を説明できることは、あとで技術の判断を任されるときの前提になります。
議論をまとめる役を引き受ける
リーダーの円のうち、肩書きがなくても練習しやすいのが合意づくりです。
Google の同じ章の「Be a Catalyst」の節は、チームの合意をつくることを、正式な立場のないリーダーがよく使うスキルとして挙げています。
権限を持たずにリードできる方法の 1 つだから、というのが理由です。
たとえば次の設計の打ち合わせで、論点と決まったことを最後にまとめる役を申し出るところから始められます。
選択肢を並べ、それぞれを推す理由を聞き、決まったことと決まらなかったことを書き残すまでが 1 回分の練習になります。
新しく来た人の面倒を見る
Camille Fournier 氏の『エンジニアのためのマネジメントキャリアパス』は、原題を The Manager's Path といい、2018 年にオライリー・ジャパンから邦訳が出ています。
出版社の紹介文によると、この本が扱う立場の変化はインターンのメンターから始まります。
第 2 章が「メンタリング」、第 3 章が「テックリード」で、人を助ける経験をテックリードの 1 つ手前に置いた構成です。
書誌と目次はエンジニアのためのマネジメントキャリアパス（オライリー・ジャパン）で確かめられます。
Pat Kua 氏も、肩書きのないリーダーシップの例として、経験の浅いメンバーを指導するシニアエンジニアを挙げていました。
今日からなら、次に入る人のオンボーディング担当に手を挙げる、レビューのコメントに理由を添える、といった形で始められます。
いまのテックリードの仕事を 1 つ分けてもらう
Pat Kua 氏は、正式な役割がないなら、もっと責任を持たせてほしいと頼むことがリーダーとして伸びる良い出発点になると書いています。
同氏によると、プロダクトを作るチームにはテックリード、エンジニアリングマネージャー、プロダクトマネージャーからなる非公式のリーダー陣があることが多いそうです。
その顔ぶれは固定されていないことも多く、同席して学んだり、意見を出したりする機会が生まれます。
分けてもらう仕事の候補として手ごろなのは、小さな機能の段取りでしょう。
先の本は、第 3 章のうち 2 つの節をプロジェクト管理に充てています。
Google の章も、テックリードの責任に全般的なプロジェクト管理を含めていました。
作業を分けて順番を決め、危ないところを先に洗い出し、進み具合を周りに伝えるところまでを、1 つの機能で経験できます。
やったことを書き留め、上司に目標として伝える
最後の 1 つは、ここまでの 4 つを見える形にしておくことです。
Will Larson 氏の StaffEng のガイドは、Staff への昇進を目指す人に、推薦されるずっと前から昇進資料を書き始めるよう勧めています。
空の資料を 1on1 に持っていき、昇進が目標だと上司に伝えて、何が足りないかを一緒に確かめる、という手順です。
ガイドは Promotion packets（StaffEng）で公開されています。
Staff 向けの話ですが、テックリードを目指す場合にも同じ形で使えると私は考えています。
週に 1 行でも、まとめた議論、面倒を見た人、分けてもらった仕事を書き留めていけば、そのまま上司と話すときの材料になります。
下支えを見えない仕事で終わらせない
5 つの準備には、共通の落とし穴があります。
Tanya Reilly 氏は講演「Being Glue」で、チームを成り立たせる下支えの仕事を「グルーワーク」と呼びました。
詰まっている人を助ける、設計文書の食い違いに気づく、新しい人を受け入れる、といった仕事です。
同氏は、グルーワークは意図して扱えば技術リーダーシップを示して育てるが、無自覚なままだとキャリアを狭めると述べています。
講演では、チームを支えてきた人が昇進の場で「技術的な貢献が見えない」と判断される話が出てきました。
書き起こしは Being Glue（Tanya Reilly）で読めます。
同氏は、リードの立場には多くのグルーワークが期待されるので、肩書きがあれば同じ仕事をしても「技術的でない」と見られにくくなる、とも書いています。
手当てとして挙げられているのは、上司とキャリアの話をはっきりすることと、自分の判断で物事が進んだことを示す設計の提案や議事メモを残しておくことです。
それでも評価されないときは、一時的に下支えから手を引き、誰が見ても技術的だと分かる仕事に時間を戻すよう勧めていました。
5 つ目の「書き留めて伝える」を後回しにしないのは、この落とし穴を避けるためでもあります。
最後に
テックリードになるための準備は、肩書きが付く前に役割の一部を小さく引き受けることから始まります。
担当の外まで説明する、議論をまとめる、新しく来た人の面倒を見る、仕事を分けてもらう、書き留めて伝える、の 5 つです。
どれも許可を待たずに始められますが、見える形に残してはじめて準備として数えられます。
Pat Kua 氏の記事は、今日どんなリーダーシップの行動を取れるか、という問いで結ばれていました。
任されたあとの最初の 90 日の進め方は、こちらで整理しています。
以上です。
コメントを残す