海外でスタッフエンジニアの募集はかなり多い
スタッフエンジニアという仕事自体が日本であるか調べたんですが、僕が調べた感じでは今のところは募集している会社はなかったです。海外では多いかというと、海外ではかなり多いです。
（スライドを示して）これはスタッフエンジニアという定義の1つです。マスターの定義ではないので、どこかの会社に入って3年目の人をスタッフエンジニアと呼ぶこともあります。
「Indeed」で募集を見てみると、実は一般のシニアエンジニアとスタッフエンジニアの給料が1.3倍ぐらいしか違わなかったんです。1.5倍も違わないぐらいです。ではスタッフエンジニアの給料が低いのかというとそうではなくて、先ほど言ったように会社によって基準が違うからです。本当はスタッフエンジニアをやっている人たちの中にはかなり給料が高い人がいます。
（スライドを示して）活動内容はこういったことになっていて、今日このあとにも話をするんですが、細かく話していくと永遠に時間が過ぎてしまうので。
足し算をするのがエンジニア、かけ算をするのがスタッフエンジニア
普通のエンジニアは、どちらかというと自分の力をチームに対して足し算する、要するにエンジニアの能力を足してできることを増やす役割です。
足し算をするのが普通のエンジニア、シニアエンジニアやIndividual Contributorだとしたら、スタッフエンジニアはかけ算です。要するに、「このチームに入ることで、全体の20パーセント、50パーセント、100パーセント底上げをします」というふうにかけ算をするという意味では、僕はマネージャーに近い、他のピープルマネジメントに近いと考えます。
ピープルマネジメントも、単純にその人が入ることで、いろいろな交通整理をして、場合によっては人を追加したり適材適所で配置をしたり、評価をしたりしてチームの力を底上げをする。要するにかけ算をするわけですね。
同じように、スタッフエンジニアは技術の力を持ってチームの底上げをします。なので、先ほど言った自分の得意分野でチームに対してみんなができない部分を足すところもあれば、メンターとしてメンバーを引き上げたり、逆に今いるメンバーをスタッフエンジニアに引き上げるために「もっとあなたはこういう勉強をしてこういう視点を持ったほうがいいよね」と視点を一段上げる。
上級のエンジニアのことは、この本のいろいろなところで書いてありましたが、その“上級”というのは、できる技術が難しいという意味ではなくて、会社に対してかけ算で貢献できる、要するに自分の力以上のことが貢献できるという意味で上級と考えています。
単純に技術として、例えば「僕は機械学習ができます」とか「インフラがすごくわかって、人の10倍生産性が高いです」というのは、どちらかというと先ほどのIC、Individual Contributorです。（一方でスタッフエンジニアは）「僕がいることでチームが難しいところ、みんなからブロッカーになっているところ、組織のことでも技術のことでも取り除けます」と。みんなのメンタリングをして、みんなの能力を上げられるのが、このスタッフエンジニアに求められることになると思います。
スタッフエンジニア募集はまだ日本では見たことがないのと、もう1つ、スタッフエンジニア募集はけっこう難しいんですね。要するに、メンターになってくれるような人を募集することが難しいなので、会社から少しずつ上っていくことはできても、ある日突然上からポンッと降りてきて「僕はスタッフエンジニアだから、みなさんのメンターをするよ」ということがなかなか難しいです。
スタッフエンジニアになるメリット
逆にスタッフエンジニア側になるとして、なった側のメリットは何なのか。「自分はスタッフエンジニアである」という役職がつくことのメリットです。
先ほど言ったスタッフエンジニアと同じような、メンターをやるエンジニアやEMみたいな人もいますが、スタッフエンジニアという役職がつくメリットは、スタッフエンジニアとして会社が認めたということは、その人の能力がスタッフクラスだと認めたことになります。
なので、例えばエンジニア以外の人に「この人はすごくできるエンジニアなんですよ。いつもお風呂に入っているけどね」みたいなことは言わなくても、「スタッフエンジニアです」と言えば、「この人は会社としてトップクラスの意思決定ができるエンジニアだ」と会社が認める、他の職種の人も認めるということになります。
あとは意思決定の場所に入れます。そういうふうに認められるからこそ会議に出ることができて、それこそReactを使うのか、Vueを使うのか、jQueryで書くのかという意思決定の場所に入ることができます。あとはもちろん給料の交渉ができます。
なのでシニアエンジニアと少し違うのは、スタッフエンジニアはシニアエンジニアの上にあるわけではないんですね。要するに、足し算からかけ算へのシフトがあります。
スタッフエンジニアになるためには経営層から認められる必要がある
かけ算でやるには会社からかけ算ができる人、要するにこの人がいることでチームが底上げされる、こういうふうに会社の上のメンバーから、特に経営層から認められる必要があります。
（スライドを示して）いきなり認めてもらうことはできないので、スポンサー、要するに「自分のことを引き上げてくれる人を見つけましょう」とか、プロモーションパケットといわれるような、社内で上に上がるために「僕はこんなことができます」「こんなことをやってきました」「僕がスタッフエンジニアになった暁には、こんなことをやります」みたいなことを自分で書いて会社に説明をします。
よくあるのは、スタッフプロジェクトといわれるようなすごく難しい状況。先ほど言った火消しがすごくうまくいったケース、お客さんとこじれていた、もしくは技術的にすごく難しくてサーバーが落ちていたのを直したということを実際に実績として出す必要があります。
こういったものをどういうふうに書くのかが書かれているのが、この本です。
技術の中心のキャリアを考える上で、このレベルになると、エンジニアとしてコードは全員書けて当たり前、ある程度のコードが書けて当たり前なので、コードを書くこと自体がすごく評価されることは、正直ICとかシニアエンジニアの段階である程度天井が来ます。
だけどそれ以上に上級職に就きたい、それは別にエンジニアとして上というわけではなくて、会社組織として上のほうのマネジメント層としてです。スタッフエンジニアはピープルマネジメントはしないけど、会社に広くかけ算をして貢献をしていくという意味では、エンジニア職よりもマネジメント職に近いと思っていて、そういったものをエンジニアという役職をしながら自律的に組織に貢献するものと考えます。
スタッフエンジニアになるための明確な指標はない
スタッフエンジニアのような上級職になると、わかりやすいキャリアパスはないんですね。例えば「こういったことができるようになったらスタッフエンジニアです」という明確なものがないんです。なので、インタビューで書かれていることが役に立つかは、人それぞれ、会社によってぜんぜん違います。だからA社でスタッフエンジニアだった人がB社で役に立つかというと、そうではないんですね。
同じ能力があっても上から認められなかったらそういう仕事は振ってもらえないので。そういった中ではキャリアを作っていくのがすごく難しいので、この本を読んだ上で、さらにいろいろな話をしたり、自分でトライをしたりしてみて進めるということが、この本の趣旨になると思います。
この本の勘をなんとなくつかむために、初めに1人か2人適当にインタビューを読んでもらってから、そのあとに「スタッフエンジニアとは」みたいな話を振り返って読んでもらうと納得がしやすいんじゃないかなと思います。
というわけで駆け足でしたが、『Staff Engineer』という本の簡単な説明をしました。どうもありがとうございました。
