はじめに
技術リーダーとしての最初の役割を担った頃、もうずいぶん昔のことだが、まるで白紙の地図を渡され、未知の土地への航路を自ら切り開けと言われた気分だった。手引きもなければ、実績のある道もなく、正しい方向に向かっているという確信もなかった。この役職において「良い」とはどういう状態なのか、全く見当がつかなかった。それでも、何らかの形で正しいことをしていたのだろう。数年後、私はThoughtworksの同僚向けに技術リーダートレーニングプログラムを運営するよう依頼され、それはやがてグローバルなプログラムへと発展した。その過程で、私の苦労は決して特別なものではないと気づいた。多くの人が同じ不確実性に直面し、支援となるリソースはほとんどなかった。参考になる書籍を検索したが、発見されたのはわずか3冊。うち2冊はマネジメント中心の書籍『』で、技術的リーダーシップを真に扱っていたのは故ジェラルド・ワインバーグの『Becoming a Technical Leader』(Dorset House)だけだった。10年以上前、私はその空白を埋めるため『Talking with Tech Leads』(CreateSpace)を書いた。
この本の出版以来、私は数千人の技術リーダー、エンジニアリングマネージャー、スタッフエンジニアに対するトレーニングを行い、数十人のCTOを指導してきた。その間、私たちの業界は劇的に変化した。オンプレミスからクラウドベースのソフトウェアへ、デスクトップからウェブ、モバイルへ、そしてビッグバンリリースから継続的デリバリへと移行した。しかしこうした変化にもかかわらず、新たに任命された技術リーダーたちは今も同じ質問を繰り返す。「私に何が求められているのか?」「どこに時間を割くべきか?」「どれくらい自らコードを書くべきか?」といったものだ。
こうした根本的な疑問は変わらない一方で、 役割そのものもはるかに要求が厳しくなった。Java開発者チームのように共通の技術背景を持つチームを率いるテックリードもいれば、ウェブ、モバイル、バックエンド、データサイエンスなど多分野の知識を必要とするクロスファンクショナルチームを率いる者もいる。いわゆる「フルスタック開発者」でさえ、これほど広範な分野の専門家にはなれず、AI駆動ツールの急速な普及が複雑さを増している。エンジニアリングマネージャーやスタッフエンジニアといった新たな役職の登場により、テックリードの役割をめぐる混乱は深まっている。これらの役職と責任範囲が重複することも少なくない。さらに多くのチームが「構築した者が運用する」モデルを採用しているため、テックリードの責任には運用やサポート業務も追加されている。現代のテックリードの役割はかつてないほど多面的だ。
複雑さが進展するにもかかわらず、テックリード向けの専門リソースは依然として少ない。業界からは『The Manager’s Path』( Camille Fournier著)、『The Staff Engineer’s Path』( Tanya Reilly著)、『The Engineering Executive’s Primer』( Will Larson著)(いずれもO’Reilly刊)といった優れた書籍が生まれている。しかしテックリード向けの実践的ガイダンスは依然として不足しており、だからこそ本書に期待しているのだ。
アネマリーがこの序文を依頼してきた時、彼女がバルセロナで開催した私の技術リーダー養成コースに参加し、役職に成長する助けになったことを思い出させてくれた。本書は彼女の継続的な成長の証であり、そのページの中で彼女は成功に導いた教訓、経験、ツールを共有している。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access