目次
■リーダーシップとチームマネジメント
2023.06.13 2023.09.09 約5分
この記事は、2023年5月発売 『スタッフエンジニア マネジメントを超えるリーダーシップ』解説者 増井 雄一郎 氏による connpass勉強会 を再編集し、記事化したものです。 |
発売前からAmazonのベストセラーランキングに登場し、話題の「スタッフエンジニア マネジメントを超えるリーダーシップ」を取り上げ、スタッフエンジニアを目指すメリットや必要スキルなどを解説します。
コードや技術がとにかく好きで、これからもそれをメインの仕事にしたい方が多いはず。「スタッフエンジニア」はそんな方にこそ、知って欲しい職種です!
日本ではまだ馴染みのない“ スタッフエンジニア ” 。主にアメリカのテクノロジー企業やスタートアップで使用される職種で、エンジニアのキャリアパスとして認知されています。スタッフエンジニアは、技術的な専門知識や経験が豊富で、チームやプロジェクトの技術的な方向性をリードする役割を持つことが多く、日本においても今後注目が期待される職種です。
書籍で紹介しているキャリアラダー(キャリアを登るためのはしご)の図です。
通常、エンジニアのキャリアは シニアから スタッフプラス(上)、エンジニアリングマネジメント(下)に分岐します。日本はこれに加え、プロダクト方面(プロダクトオーナー・プロダクトマネージャー)のキャリアも考えられるでしょう。
スタッフと聞くと一般社員・メンバークラスを想像しますよね。実は、Staff == 参謀 という意味。つまり、ITエンジニアの場合はCTOやCxOなどのリーダーを補佐する役割を指します。ちなみに スタッフエンジニア は、ITエンジニアだけでなく、専門職であれば設定されることがある職種のようです。
参謀とは?
|
|
参謀といっても、やり方はさまざま。その中でも今回は4つのスタッフエンジニア(参謀)を紹介します。いずれも、シニアエンジニアの延長というよりは、マネージャーやプロダクトオーナー、プロダクトマネージャーに近い職種に見えるような印象を受けました。*この4つに入らない人もいれば、4つを掛け持ちしている人もいます。
皆さんが最もイメージしやすいでしょう。管理よりも人を引っ張るリーダーの色が強いですよね。
|
では、スタッフエンジニア の中のテックリードは、皆さんの会社のテックリードとどう違うのでしょうか。スタッフエンジニア(参謀)という名のとおり、現場よりも経営層に近い目線を持ち、より上層の期待に添う働きをします。
|
|
これは初めて聞く方が多いと思います。競合と同じ機能を実装して欲しい、この顧客の炎上を沈静化して欲しいなどの要望に応えるために、トップから任命された役割を指します。
|
火消しについてはソルバーと近いのですが、ソルバーが技術的なのに対し、右腕はリーダーとともに会議に出席して問題を巻き取り、組織構造としての火消しを担います。またソルバーは自身の名やチーム名を背負って火消しするのに対し、右腕はCTOや上層部を代理として大きな権限を持って対応します。
これもITエンジニアに限らない役職なのですが、最近よく聞くようになった役割です。
|
IC と スタッフエンジニアとの立ち位置について、外資だと IC(初級〜シニアまで) → Staff Engineer or Manager みたいなキャリアパスになっているところもあると聞きます。 #Forkwell_Library
— 赤川 朗 / Forkwell (@Akira_Akagawa) May 24, 2023
書籍で最も印象に残ったのは「自分のエゴに自覚的になりなさい」という話。その技術の方向性は、自分にとって重要なのか、それとももっと上層の部分で重要なのか。自分のエゴとリードする人の価値観や方向性を考え、折り合いをつけながら、活動していく。これが、スタッフエンジニア の役割です。
|
また、採用や教育は スタッフエンジニア の大きな役割として定義されています。 スタッフエンジニア はピープルマネジメントから外れるんじゃないの?と考えていた僕にとっては、意外ながらも面白く感じた点です。
|
|
実際に スタッフエンジニア になるにはどうすれば良いのでしょうか。実は、かなり難しい問題として捉えられています。というのも スタッフエンジニア = 参謀 の要素が強く、シニアエンジニアを「卒業」すればなれる職種ではないからです。最も大切な要素は、他者から認められることです。
エンジニアなので、技術組織に対して広い貢献もしくは技術組織として他者に伝わる(わかりやすい)貢献が必要です。
1.スポンサー
すでに存在する上級エンジニアからスポンサー(お墨付き)を得る方法 2.プロモーションパケット 自身が実現してきた成果や貢献を文章化し、履歴書のように見せる方法 3.スタップタロジェクト 難易度の高いプロジェクトを成功させた経歴 |
他者から「認められる」方法で、最も大切なのは、プロモーションパケット。僕も実際に過去の同僚たちに話を聞きに行って、それを Web にまとめて掲載しました。自分の仕事を棚卸しして、文章にする作業って意外とやらないですよね。しかし、スタッフエンジニア の場合は、必須だと思ってください。スタッフエンジニアになるとエンジニア職以外の人と交渉をしたり認められる必要が出てきます。そのため自分の経歴や実績を他者にわかりやすく説明することは、とても重要です。今すぐに スタッフエンジニア を目指さずとも、将来的に目指す可能性があるならば、定期的に経歴をアップデートしておきましょう。
|
本書は、非常にインタビュー比率が高く構成されています。(日本人 スタッフエンジニア だけでも4名)エンジニアといっても、企業や職種によって身に付けるべきスキルも身に付ける方法も違います。ぜひインタビューの中から、自分に合う事例を見付けてください。もしあなたが スタッフエンジニア を目指すなら自分のエゴを捨てて「組織への貢献」に重きを置いてみてください。
「インポスター症候群」とは、自分の力で何かを達成し、周囲から高く評価されても、自分にはそのような能力はない、評価されるに値しないと自己を過小評価してしまう傾向のことです。スタッフエンジニア を目指すレベルになると、自分が出してきた結果・会社への貢献度を、自分自身が低く見積もる傾向があります。これは大変もったいないことです。自分が スタッフエンジニア には満たないと考えている人は、ぜひ上司、メンター、スポンサーに相談してみてください。
「上級」は「上の役職」ではなく、視野の広さを指すと考えています。このクラスになると、わかりやすいキャリアパスは存在しません。自ら スタッフエンジニア 職種を作り、スタッフエンジニア の適任者を見出すことが求められるでしょう。
|
増井:日本で「スタッフエンジニア」の募集は見たことがありません。本書インタビューに登場する日本人エンジニアは、外資系勤務や スタッフエンジニア という役職名ではないものの、実態として スタッフエンジニア であるケースがほとんどです。
赤川:Forkwell も10年以上、エンジニア採用に携わっていますが スタッフエンジニア という求人は見たことがありません。
増井:そうですよね。名が付くことって大切だと思うんですよね。過去に SRE という職種が存在しなかったように、スタッフエンジニア も名が付くことで、今後 スタッフエンジニア の権限や役割への認知が広がっていくことを期待します。
増井:技術に関しては複数の強みを持っておくことが大切です。しかし技術力だけがスタッフエンジニアの要件ではありません。一つの技術が通用するのはせいぜい10年程度。長いキャリアを考えると、一つの技術だけでは厳しいでしょう。常に技術を追い求めながら、経営側の視点も持ち合わせていることが重要なのではないでしょうか。
増井:これははっきりしていて、上から信頼されること。結構、評価する側に依存する部分もあります。オープンソース活動で名前が出ていること、個人プロジェクトを実行していること、ブログで名が知れていることなどが信頼獲得に繋がることもあれば、完全に業務の中だけで評価する人もいます。つまり自分が何で評価されたいのか?自分の組織では、それが評価されるのか?を考えると良いでしょう。スタッフエンジニアを目指すのは長いキャリアパスの最後の方です。まずは、ジュニア → ミドル → シニアとステップアップしていくことを忘れずに。上に行くほど、自分のことを自分で説明できる能力(嘘偽りなく誇張せず正しく伝える能力)が大事になってきます。それは技術の話に限りません。いまあなたがジュニアならば、自分はジュニアとして何ができて、ミドルに相応しい能力がどれだけあるかを文章化する能力も大切です。
増井:いまの人口動態で考えると、僕らは70歳過ぎまで働くことになります。遅いということはありません。名の知れたエンジニアもGoogleエンジニアも20代半ばからエンジニアを始めた人なんてザラにいます。僕でさえ、あと30年もキャリアがあるんですよ。誤差の範囲ですよ。
赤川:Forkwell の知見から回答しても、決して遅くはないと思います!
増井:僕もよく考えることがあるのですが、やっぱり健康だなと。 エンジニアのキャリアって、僕らが思うよりずっと長いんですよね。10年先も今と同じようなプログラムの書き方をするか考えてみると、疑問ですよね。どんな変化にも対応できるよう、柔軟性高く健康に過ごすこと、そして前述したように言語化していくこと。これが最も大切なのではと思います。
増井:同僚へのインタビューは、大変有効だと思っています。人の価値は、基本的に相対価値でしかわからない、つまり自分の価値は、自分ではわからないんです。例えば、僕はプログラムを書くことが好きで、そんなに苦にならない。でも、このイベントを見ているほとんどのエンジニアも、プログラムが書けて、そんなに苦ではないはず。そうすると、その軸ではこの中で僕の価値はあまり高くない訳です。でも、エンジニアじゃない人から見れば、パソコンを自在に使えるだけでも「優れた人」となるわけです。このように自分の「価値」はどのようの人に囲まれているかということに左右されます。そのため、自分の価値は周りに人に聞いてみると、意外な「価値」が発見できるかもしれません。もしそれを発見できればそれを中心にレジュメを構成してみるといいと思います。
増井:僕も同じ疑問があったのでindeedで検索してみました。思ったより高くない。シニアより1〜2割高いくらいですね。これは「スタッフエンジニア」という職種が英語圏でも会社により役割が大きく異なるということだと思います。もちろんスタッフエンジニアの中にはシニアの数倍もらっている人もいると思います。
赤川:書籍で書かれる スタッフエンジニア の責任の重さからすると、意外ですね。
増井:そうですね。スタートアップの場合は、SOで調整がかかるんだと思います。あとはアメリカの場合は入社時にかなり細かく給与交渉するので、求人に記載されているとおりにはならないですよね。それとアメリカだと、年収以外の条件も大事になってきますよ。僕の経験談ですが、日本からアメリカへの出張費を事業部の予算ではなく個人の予算に乗せてもらうんです。それも年6回分とか。もしマネージャーから嫌われたときに、現地で話す機会を奪われるじゃないですか。そうなると不利なので、僕個人の予算で行けるようにすると。そういう年収以外の労働条件の部分があるので、一律には高くないとは言えないんですよね。
Forkwell では、この市況下でキャリアに悩むエンジニアのよきパートナーとなれるよう、上級エンジニアに特化したキャリア支援サービスをはじめます。
|
赤川がエンジニアの皆さんとお会いします。