「エンジニアのためのマネジメントキャリアパス」第3章を読んで、自分の琴線に触れた内容をもくもくとアウトプットしていきます。前回記事はこちら。

3章 テックリード

「テックリード」について、ざっくり掻い摘むと下記のようです。

テックリード とは（ソフトウェアの）開発チームに対する責任を担い、最低でも自身の職務時間の3割はチームと共にコードを書く作業に充てているリーダーのこと。

具体的には、経営陣との連絡や話し合いの場でチームの代表を務める、機能を提供するための計画を練る、プロジェクト管理の大部分を細部まで担当する、といった職務です。

企業によって、また企業内のチームによって、テックリードの役割は多少異なるでしょうが、tech leadという呼称からもわかるように、これは専門のスキルとリーダーシップとか共に求められる役割であり、多くの場合「ひとりが長期にわたって就く職位」というよりはむしろ「複数の人が順次一時的にそのすべてを担う職責群」なのです。

プログラムの作成作業に思う存分没頭したいと望む人はテックリードの適任者ではありません。テックリードがそういう作業に没頭しているとすれば、その人はテックリード の職務を果たしているとは言えないのです。

今私が担っている業務内容では、プロジェクト管理 + 技術的提案の要素が入っていました。本書ではさらに、著者が在籍していたRTR(Rent the Runway)におけるテックリードが具体的にやることとして

• 各メンバーと定期的に（週1回）1対1のミーティングを行う。
• 各メンバーにキャリアアップや作業の進捗状況、改善点、報奨などについて、権限内で定期的なフィードバックを与える
• 各メンバーの研鑽を要する領域を、そのメンバーと共に見きわめ、その領域の能力強化を、プロジェクトでの職務遂行、外部での学習、メンタリングを介して支援する

が挙げられていました。今の私の動きと合致しています。面白いですね、自社だけでなく他社におけるテックリードの定義にも興味が沸きます。

3.1 優秀なテックリードなら必ず知っている、ある奇妙な「コツ」

優秀なテックリードになるための最大のコツ、それは

「実際のプログラミングの作業からあっさり一歩引き、「技術面での貢献」と「チーム全体のニーズへの対応」のバランスを取る努力を惜しまない」というものです。

と本書では紹介されています。

人間誰しも勝手知ったる仕事のほうがやりたいものですから、得意な仕事に使っていた時間を削って新しい仕事を習い覚えなければならないのは、かなり辛いことだと思います。

こちらの内容も今の私の状況によく当てはまります。今までコードを書いてばかりの日々から突然テックリードに相当する職務にスイッチするのは少々大変だと、今まさに感じているところです。

3.2 テックリードの基礎知識

テックリードは、ある作業を自分独りで完遂するべき場合とメンバーに任せるべき場合をきちんと心得た上で、ソフトウェアの開発者としての役割、システムアーキテクトとしての役割、ビジネスアナリストとしての役割、そしてチームリーダーとしての役割のすべてを適宜こなさなければなりません。

こちらもまさに今私がやっています。この内容ができるようになるためには自社のWebサービスで採用している技術スタックを把握できている必要があり(経験上、おおよそ7~8割理解できていれば何とかなりそう)、且つその技術的課題のポイントや打開策案に頭を使っている状態である必要があると感じます。

また、Webの仕組み自体に関する基礎知識もかなり重要です。近年ではフロントエンドとバックエンドを分離させてWebサービスを構築する例が増えてきており、特にフロントエンドエンジニアはブラウザによるWebページの読み込まれ方の仕組み理解が必須となっています。Webもブラウザも年々進化しているため追従は大変ですが、技術系の専門職としては必要な知識です。その上で、ある程度先見の明を持てるところまで来れるのが理想的かと思いました。

3.3 プロジェクトの管理

結局のところ、プロジェクトの計画を練る作業の真価は、完璧な計画を立てることにあるのでもなければ、事前にあらゆる詳細を漏れなく把握することにあるのでも、はたまた今後の予測を立てることにあるのでもなく、実際にプロジェクトを始動させ、どう展開していくかを見届けるよりも前に、プロジェクトをある程度掘り下げて考える努力を惜しまないことにあります。

私自身、2020年に3ヶ月規模の開発プロジェクトに参画したのですが、まさに上記の状態の中で戦っていた記憶があります。新機能追加に伴いプロジェクト計画の見立てを作るのはエンジニアにしかできない仕事だというのをその時改めて感じました。

また、そのプロジェクトは私自身がテックリードの立ち位置で動かしたものでもあったため、基本的に私が設計を考え、時々上司に相談しながら進行したという流れでした。

3.4 プロジェクト管理の実務

プロジェエクト管理実務では

まだまだ不確定な要素の多い状況に対処しつつ未知の要素を見きわめる努力を強いられるだけでなく、最善を尽くしても失敗や見落としと無縁ではいられないことをつくづく思い知らされる任務です。

と書かれていました。その任務を遂行していくためのノウハウがその後に羅列されていましたが、個人的には

2.細部の引っ掛かりや未知の要素にもくじけない

と書かれている点に同意です。プロジェクトの初期段階で全てが明らかになることは殆どない為、仮説を立てながら前に進むしかないという経験は何度かしてきました。仕事に完璧を求めすぎると精神衛生的に良くないと思います。

3.5 決断の時ーー技術職を貫くか、管理職への道を選ぶか

技術職と管理職の理想像と現実がそれぞれ紹介されていました。引用したい箇所は特にありませんでしたが、技術職も管理職もどちらも一喜一憂ありな内容でした。

どちらを選択すべきかは両方とも経験してみて、その上で自分の特性に合わせて選ぶのが良いのだろうと思った次第です。

3.6 すごい上司、ひどい上司ーープロセスの何たるかを心得ている上司と、プロセスツァー

といった内容が書かれていました。

「プロセスは、チームのニーズや、チームが進めている作業のニーズを満たさなければならないという点を深く理解している管理者」

が該当するとのことですが、個人的には上司の立場として様々なプロセスにおいて「こういう時はこれを使おう」を押し付けた経験がなく、その時々のプロジェクト状況を鑑みて適切な手法を用いれれば良いというスタンスです。適切な手法は現場の人が考えて提案・取り入れていただければ良いです（そのほうが本人の成長にも繋がるかと思います）。これ自体はそのままやっていけば良さそうに思いました。

3.7 優秀なテックリードとは

以下の4要素が紹介されていました。

2.の「技術的な意思決定を主導する」に関してですが、チーム内で技術的な議論が活発に行われる状態を作ることが必要だと思いました。まずはお互いが気楽に話できる場づくりが大事になるでしょう。

4.「コミュニケーションの達人である」はなかなか難しいですが、個人的に今後強化すべきコミュニケーション能力としては経営者やステークホルダー向けに話す時だと思いました。短時間で必要最低限、且つ分かりやすく話しつつやりたいことを論理的整合性を担保して提案することが重要です。

3.8 自己診断用の質問リスト

・今までのテックリードの中で最高だと思えるのは誰ですか。その判断の理由となった、その人の言動をいくつかあげてみてください。

2021年現在の自分の上司だと思いました。忖度抜きで率直にそう思います。実際一緒に仕事したことがある人じゃないとなかなか分からないものですね。

今回はこれで以上となります。次回は第4章に続きます。