https://okuzawats.com/categories/%E3%82%AD%E3%83%A3%E3%83%AA%E3%82%A2/Recent content in キャリア on okuzawatsの日記Hugoja© 2019 okuzawatsSat, 11 Mar 2023 22:18:32 +0900https://okuzawats.com/blog/software-engineer-career-path/Sat, 11 Mar 2023 22:18:32 +0900https://okuzawats.com/blog/software-engineer-career-path/ソフトウェアエンジニアには一般にどのようなキャリアパスがあるのか、ということを考えます。組織によっても異なるでしょうが、一般的には以下のようにまとめられそうです（Will (2021), James (2022) より筆者作成） 。“L"はレベル、“IC"はIndividual Contributorです。 注意点です。 ICトラックとマネジメントトラックを行き来する人もいると思いますが、両者は別物と考えた方が良さそうです。 同じ名前で呼ばれていても、組織の規模によってレベル感は異なります。極端な話、CEOとCTOのふたりだけのスタートアップのCTOと、GAFAM的な企業のCTOでは、一般的に後者の方がレベル感が高いとみなされるでしょう。 ジュニアエンジニア〜エンジニア ソフトウェアエンジニアとしての仕事は、ジュニアエンジニアから始まります。組織によって定義は異なるでしょうが、仕事を進めるために手助けが必要な段階です。手助けが不要になり、ひとりで仕事が進められるようになれば、「ジュニア」が外れて「エンジニア」と呼ばれることになるでしょう。 このレベルには、マネジメントトラックは存在しません。 シニアエンジニア エンジニアからレベルが上がって、ICトラックに進んだ場合はシニアエンジニアと呼ばれるようになります。しっかりとした知識を持ち、周囲から頼りにされるようになるレベルです。ジュニアエンジニアやエンジニアにアドバイスができたり、プロジェクトの主力メンバーだったりするでしょう。 スタッフエンジニア シニアエンジニアからさらにレベルが上がると、スタッフエンジニアと呼ばれるようになります。スタッフエンジニア以上のソフトウェアエンジニアには、以下の4つの類型があります（Will (2021) ）。より困難で、答えのない問題に取り組んでいくことになるでしょう。 テックリード（Tech Lead）：チームに対するリーダーシップを発揮する役割。 アーキテクト（Architect）：特定の技術分野の技術的リーダーシップを発揮する役割。 ソルバー（Solver）：難しい技術的課題を解決する役割。 ライトハンド（Right Hand）：エグゼクティブの右腕となる役割。 プリンシパルエンジニア ICとして極まった人です。 エンジニアリングマネージャー エンジニアからレベルが上がって、マネジメントトラックに進んだ場合はエンジニアリングマネージャーと呼ばれるようになります。レベル感としてはシニアエンジニアと同じL3です。 エンジニアリングディレクター エンジニアリングマネージャーからレベルが上がるとエンジニアリングディレクターと呼ばれるようになります。レベル感としてはスタッフエンジニア相当のL4です。 エンジニアリング担当VP（Vice President） エンジニアリングディレクターからさらにレベルが上がるとエンジニアリング担当VPと呼ばれるようになります。VPoEなどでしょうか。レベル感としてはスタッフエンジニアやプリンシパルエンジニアに相当するL5〜L6です。 CTO マネジメントトラックを極めるとCTOと呼ばれるようになるようです。レベルはL7になるので、ソフトウェアエンジニアの最上位職種と言えるかもしれません。 References Will Larson, (2021), Staff Engineer Leadership beyond the management track James Stanier, (2022), エンジニアリングマネージャーのしごと チームが必要とするマネージャーになる方法, オライリー・ジャパン Camille Fournier, (2018), エンジニアのためのマネジメントキャリアパス テックリードからCTOまでマネジメントスキル向上ガイド, オライリー・ジャパンhttps://okuzawats.com/blog/career-ladder-vs-career-path/Fri, 05 Aug 2022 21:26:54 +0900https://okuzawats.com/blog/career-ladder-vs-career-path/リーダーの作法 (Lopp, (2022)) の脚注に面白い考えが書かれてました。この書籍の中で「キャリアラダー」という言葉ではなく「キャリアパス」という言葉を使っている理由です。以下に引用します。 ここで「ラダー（はしご）」という言葉を使いたがる人もいますが、私は「パス（道）」という言葉が好きです。はしごは、上に向かって登らなければなりませんが、パスは旅です。 (Lopp (2022), リーダーの作法, p.133) 自分も筆者の意見に近いです。キャリアを「はしご」と捉える場合、多くの人は組織図でのヒエラルキーの上に行くことをイメージするものと思います。もちろん、組織の統制上、権力関係は必要でしょう。その一方で、プロフェッショナルのキャリアは、この組織図上のヒエラルキーとは切り離して考えるべき、とする立場です。 例えば、テックリードというロールを考えても、「エンジニアの階層におけるランクのひとつではなく、シニアのレベルに達したエンジニアが担うことのできる職責郡である」(Fournier (2018)) と考えています。あくまでロールであって権力ではないと捉えている、という意味です。テックリードの場合は、スキル、知識、リーダーシップでチームをリードするべきで、権力を使って何かを成し遂げるロールではないというのが自分の考えです。 また、エンジニアリングマネージャー、テックリード、インディビジュアルコントリビューターのどのロールを選んでも正解であるし1、キャリアの途中でロールをチェンジすることも正解であると考えているのですが、キャリアを「はしご」と捉えた場合、この考えが成立しなくなってしまうと思うのです。 キャリアを「パス」として捉えれば、どこへ歩いていくのも当人次第である、と愚考する次第です。 References Michael Lopp (著), 和智右桂 (訳), (2022), リーダーの作法, オライリージャパン Camille Fournier (著), 武舎広幸 (訳), 武舎るみ (訳), (2018), エンジニアのためのマネジメントキャリアパス, オライリージャパン 選べる場合は。 ↩︎https://okuzawats.com/blog/techlead/Tue, 02 Aug 2022 22:07:22 +0900https://okuzawats.com/blog/techlead/新興のIT企業を中心に、テックリードという役割が広がっています1。かく言う私もテックリードをやっているわけですが、果たしてこのテックリードとは、一体どんな役割なのでしょうか。翻って考えてみたいと思います。 何冊かの本から、あらかじめ参考になりそうな記述をメモしておきました。 ソフトウェアの開発チームに対する責任を負う役割を持つ、技術面でのリーダー (Kua, (2015)) マネージャーが人員のリーダーであるのに対し、テックリードは技術的取り組みを主導する役割 (Winters他 (2021)) プログラミングの最前線からは退き、技術面での貢献とチーム全体のニーズをバランスさせ、プロジェクトを推進するための大局的な視点を持つ (Fournier (2018)) どうも曖昧然としてはいますが、技術面でのリーダーシップを発揮する役割であることは間違いなさそうです2。いわゆるIndividual Contributor（IC）でも技術面でのリーダーシップを発揮することはありそうですが、違いは「チーム全体の生産性」に対する責任を負うかどうか、という点にありそうです。 面白い記事がありました。初出はWEB+DB PRESS Vol.103とのこと。 第11回　テックリード | gihyo.jp 少し長くなりますが、引用します。 テックリードの仕事は輝かしく見えるかもしれない。ただ実態は、地味である。またそうであるべきだ。技術的にチャレンジだったり、やりがいのある仕事はテックリードのものではない。そういう「おいしい」仕事はお膳立てだけして、チームメートに譲るのだ。 それよりも、誰もやりたがらないものがテックリードの仕事である。ミーティングの進行役、先を見越したプロジェクトマネジメント、コードのクリーンアップなど。とにかくチームの生産性を上げることが使命である。また、表面上は成果として見えないようなものにも取り組むべきだ。たとえばチームの技術スコープが将来的に広がるような技術やデザインの採用を促進するなど。 自分がテックリードになって「自分の仕事は地味だな」と感じたら、うまくいっている証拠なのでがんばってほしい。 (Minowa (2018)) とにかく地味に、チームの生産性を上げることがテックリードの使命であるということ。また、チームメートが活躍するためのお膳立てをして美味しいところは譲ることもテックリードの仕事である、とも書いています。 「テックリード」という響きは何やら格好いいですが、その響きほど格好いい役割ではなさそうだということがわかりました。改めて、自分自身のテックリードとしての仕事を振り返ってみたいと思いました。 追記 Forkwellさんからインタビューを受けて、テックリードをしていた時の仕事の内容や、その難しさ、楽しさについて話しました。以下の記事に掲載されています。 テックリードはキャリアの分岐点。取材でわかった6系統の役割と市場価値のリアル | エンジニアの生き様をウォッチするメディア 自分のコメントが掲載されていることを差し引いても、何人ものテックリードにその仕事内容をヒアリングした、面白い記事であると思います。 References Patrick Kua, (2015), Talking with Tech Leads: From Novices to Practitioners retrieved from https://www.amazon.co.jp/dp/B014Q2C4M4/ (最終アクセス日：2022年8月2日) Titus Winters, Tom Manshreck, Hyrum Wright, (2021), Googleのソフトウェアエンジニアリング, オライリージャパン Camille Fournier, (2018), エンジニアのためのマネジメントキャリアパス テックリードからCTOまでマネジメントスキル向上ガイド, オライリージャパン Taro Minowa, (2018), テックリード, retrieved from https://gihyo.