ソフトウェアエンジニアの皆さんは、エンジニアがマネージャーにならずにキャリアアップしていくにはどうしたらいいか、と悩んだことがあるかもしれません。マネージャーが中心の組織では、昇格・昇進とは「上位の管理職を担っていくこと」を意味する場合も多く、それにあてはまらない専門職にとってはチャンスがないように見えてしまうこともあるでしょう。
ただ、マネージャーにならずにキャリアアップするには、開発をやっているだけで良いのかという疑問も浮かびます。マネージャーであれば、課長→部長→本部長→役員のように、管掌する範囲が広く大きくなる、つまり責任やインパクトの範囲が広く大きくなっていくことがキャリアアップを意味することが多いですが、専門職の場合はどうなるのでしょうか？
この『スタッフエンジニア マネジメントを超えるリーダーシップ』は、その疑問に対する回答の一つとして、非常に参考になる考えが書かれている本でした。
目次
『スタッフエンジニア マネジメントを超えるリーダーシップ』とは
この本は、エンジニアやエンジニアリーダーとして Stripe や Uber などのビッグテックで働いた後に著述家に転身したウィル・ラーソンによって書かれました。彼がエンジニアリングマネジメントについてまとめた『An Elegant Puzzle』で成功を収めた後に本書を著したようです。本書に関連する形で StaffEng project を運営するなど、精力的に活動しています。なお『An Elegant Puzzle』は『エレガントパズル エンジニアのマネジメントという難問にあなたはどう立ち向かうのか』として2024年5月30日に日本語版が出版されるようです。
まず、スタッフエンジニア（Staff Engineer）とは何か。ここで言うスタッフとはいわゆるオペレーションスタッフではなく、「参謀」といった意味に近い Staff を指します。英語でも同じ単語なので少し紛らわしいですが、ビッグテックや多くのシリコンバレーの企業では、シニアエンジニアよりも上の階級としてスタッフエンジニアという役割や肩書が定義されていると本書では説明されています。スタッフエンジニアよりさらに上は Principal Engineer とか Distinguished Engieer といった役割や肩書があり、本書においてもスタッフエンジニア以上という意味で「スタッフプラス」という言い方が頻出します。
この本は、スタッフプラスのエンジニアが担う役割や肩書の意味を論じた前半部と、実際にスタッフプラス相当のエンジニアにインタビューを行った後半部から構成されており、後半部には日本語版独自のインタビューも追加されています。また、後半部では、各企業におけるスタッフプラス相当の人物の実態が垣間見えますが、これらのインタビューは前半部でもよく引用されていて、実像としてのインタビューとそれを体系化した前半部という立体的な構造になっています。
そして前半部において、スタッフプラスのエンジニアを著者は以下の4つに類型化しています。
-テックリード
-アーキテクト
-ソルバー（解決者）
-右腕（ライトハンド）
ソフトウェア開発チームでしばしば見られるテックリード。これは上級専門職の形として想像しやすいものだと思いますが、著者はそれすらもスタッフプラスの一つの形に過ぎない、と言っているかのようです。事業や組織に大きな貢献をする上級専門職は、テックリードとしてチーム開発を牽引する形だけではないということでしょう。専門職として事業や組織に大きいインパクトを生み出すやり方には、さまざまな可能性があることに気付かされます。
この本をより理解するために
本書には、シリコンバレー企業やグローバルなテック企業の文化を前提にしている部分があります。著者の前作『An Elegant Puzzle』に対する読者からのコメントで、あまりにシリコンバレー中心的だという指摘があり、本書はそれに対する回答として記された側面もあるようですが、とはいえ日本の企業で働く我々には少し馴染みが薄いものも存在するでしょう。
まず「スタッフエンジニア」ですが、本書では組織における肩書である側面と、果たすべき役割の両方が論じられています。そこには肩書と役割は不可分であるという考えがあるように思いますが、それは海外企業に多いしっかりと定義されたキャリアラダー（等級表やグレード表）と、いわゆるジョブ型雇用が前提になっています。
加えて、そういった企業のキャリアラダーは上級職になると Manager と Individual Contributor（ICとよく略される）に分かれることが多いです。Manager はいわゆる管理職で、人や組織の管理に責任を持ちます。一方、IC はスタッフエンジニアのように個人として事業や組織に貢献していく肩書・役割になります。こうした企業においては、マネージャーというものが果たすべき役割も Job Description （求人票）に言語化されているからこそ、そういった分類や役割分担が可能になるのかもしれません。
さらに、プロモーションという文化があります。これは昇進・昇格を望むのであれば、決められた書類などのプロモーションパッケージ（手続き）に従って、自分からそれを会社に提出するという制度です。これは肩書や役割が明確に定義されているからこそ成り立つもので、そのような状況にない組織からすると、自分から昇進・昇格をアピールするという文化的な違いを含め、大きな違いがあるように見えるかもしれません。
とはいえ、日本においてもジョブ型雇用や Manager と IC を分けるなど、海外企業の仕組みを取り入れる動きもありますが、海外企業に比べるとあいまいな部分が多いのも現状かと思います。文化的な違いはもちろん、前提となる法律がそもそも違うのですから、どちらが良いと一概に言えるものではないありません。しかし、書き手と読み手で前提が違っていると、前提の違いに注目してしまい、大事な部分に気付きにくくなってしまうかもしれないので、ここにまとめてみました。
スタッフプラスのエンジニアとして活躍するために
本書の前半部には、他にもスタッフプラスとして果たすべき役割や、肩書としてのスタッフプラスになるための処世術などが書かれています。前提が違うので直接的には参考にしにくい部分は省きつつ、個人的に重要だと思ったポイントを挙げてみます。
誰かのスポンサーになる
スタッフプラスとして果たすべき役割の一つとして繰り返し述べられています。ここで言うスポンサーとは、うしろ盾くらいの意味で、経済的な援助を伴うとは限りません。スタッフプラスはマネージャーではないので、人や組織の管理を職務として持っていません。だからこそ、自身の影響力を、チーム全体、組織全体へと大きくしていくには、自身の成果だけでなく、他者の成果に貢献していくことが必要になります。近い要素として、チームや個人の仲介役として「グルーになる」ことも重要視されています。
他のエンジニアにとってお手本になる
エンジニアは専門職なので、自分自身でその専門性を高めていく存在だと個人的には思っています。だからこそ、技術的にもスタンス的にも率先垂範する存在になれば、他のエンジニアにとっても成長のきっかけになり、事業や組織の成長に大きく貢献できるでしょう。
マネージャーとスタッフプラスを行き来する
私がマネジャーとして有利なのは、ろくに計画されていないプロジェクトでICを努めるのがいかに大変かを知っているからで、私がICとして有利なのは、プロジェクトがまずい方向に進みはじめたとき、どのタイミングで、どのような警鐘を鳴らすべきかを知っているからです。（ダン・ナへのインタビューより）
本文中のこの文章が、Manager と IC のキャリアラダーを行ったり来たりすることの意味を良く表していると思います。むろん、その2つを行き来することは誰でもできることではないかもしれません。ただ、実際にそれぞれの立場を経験せず、互いの立場の視点を想像するだけでも、より創造的な仕事ができると経験的にも思います。
もしマネジメントについてもう少しイメージを持ちたいなら、本書でも触れられている『エンジニアのためのマネジメントキャリアパス―テックリードからCTOまでマネジメントスキル向上ガイド』という本が参考になります。マネージャーに対する指南書的な側面も大きい本ですが、直接的にマネジメントに取り組まなくても、組織での貢献度を段階的に上げていく過程が見える本なので、マネージャーキャリアを志さない方にも参考になると思います。
マネジメントっぽいことをしなくてはスタッフプラスにはなれない？
人によっては、マネジメントをやりたくなくてスタッフプラス的なキャリアを目指しているのに、マネージャーがやっているようなことを IC でもやらないと偉くはなれないのか？と感じてしまったかもしれません。
本書では、マネージャーと IC が役割や肩書として分かれていることが前提とされていますが、これはマネジメントとリーダーシップを区別していることに近いと思います。役割や肩書が曖昧な状況だととくにマネジメントとリーダーシップは混同されがちですが、違いを見出していくなら、リーダーシップとマネジメントは包含関係にあるとも言えます。
事業、というか世の中の物事全般を前に進めるためにはリーダーシップが必要で、ここではマネジメントはその手法に含まれる一形態と捉えています。ただ、本書でスタッフプラスに必要とされているのはリーダーシップです。マネジメントの範疇である人や組織の管理は含まれませんし、ある意味、マネジメントよりもやり方に自由度があると言えそうです。
実際に本書の中でも、スタッフプラスのあり方としてテックリード、アーキテクト、ソルバー、右腕の4類型が示されていました。これは専門職としてのリーダーシップにはさまざまな可能性があり、さまざまな形で発揮するチャンスがあると言えるのではないでしょうか。たとえば、コミュニケーションでリーダーシップを発揮するのが苦手なら、「ソルバー」タイプのように、とにかく技術的に難しい問題に次々にぶつかっていっても良いのです。専門性を強く発揮することは率先垂範すること、つまりリーダーシップにつながります。それが会社や事業、組織にとって、大きなインパクトを持つと認められたとき、スタッフプラスの称号を得られることになるでしょう。
さいごに
私自身、これまでさまざまなソフトウェアエンジニアの方と関わる機会がありました。そのなかには、一歩踏み出すだけで、一つ声を上げるだけで、殻が破れそうなのにと思う方もしばしばいらっしゃいました。リーダーシップとマネジメントが混同されているからなのか、「仕切る」的なことをリーダーシップだと考えている方もいるようです。本書で示されているように、専門職のリーダーシップにはさまざまな形があり、それはマネージャーに求められているようなことだけではありません。一方で、ロールモデルになるような存在が身近にいないと、どんな姿を目指していけばいいのかイメージしにくいことも多いでしょう。そういった意味で、本書『スタッフエンジニア マネジメントを超えるリーダーシップ』と、先程も紹介した『エンジニアのためのマネジメントキャリアパス―テックリードからCTOまでマネジメントスキル向上ガイド』の2つを読めばイメージしやすくなるはずです。
（文：平岩二郎）
