スタッフエンジニアとは（増井 雄一郎氏） 

まずは増井氏より、スタッフエンジニアの考え方についての解説がなされました。

スタッフエンジニアの「スタッフ」とは、もともとは軍事用語で「参謀」のことを指し、軍の指揮官が用兵、作戦などの計画を立て、これを実行するにあたって軍の指揮官を補佐する将校としての意味があります。 

その前提で増井氏は、スタッフエンジニアは大きく以下4つのアーキタイプに分類されると紹介します。 

テックリード	もっともシニアエンジニアに近い役割。チームの技術的なビジョンを決める中心人物。エンジニアリングマネージャやプロダクトマネージャとともにロードマップの策定や技術選定、むずかしいコード、初期コードなどを書く。スプリントのなかでも活動し、スタンドアップミーティングやプランニングにも参加する
アーキテクト	インフラ、データベース、APIなど複数のセクションにまたがる複雑で変化しつづける設計を維持する。単なる技術選定などではなく、ビジネスや顧客ニーズ、会社のビジョンなどに照らしあわせ、技術負債の解消やその実行のタイミングなどを決定する
ソルバー	トップから降りてくる重要かつ複雑な問題を解決する。技術課題の「火消し」としての役割を負うことがある。組織によっては一番数が多いかも
右腕	日本ではCTO室的な名前で存在することがある。CTOなどの上位職の名前を代理して実行する。リーダーとともに会議に出席して、問題を巻きとり解決していく。組織構造の「火消し」としての役割を負うことがある

また、スタッフエンジニアの活動内容としては以下のようなものがあげられ、技術があることは大前提としつつも、シニアエンジニアを卒業するとなれる類の職種ではないと、増井氏は強調します。

「経営層や既存のスタッフエンジニアから、技術組織への広い貢献という観点で認められる必要があるのが、スタッフエンジニアの特徴です。

これは組織構造にすごく依存するので、スタッフエンジニアの採用募集というものはあまりないイメージです。

上級職になるほど『自律的な組織への貢献』というものが求められるわけで、わかりやすいキャリアパスやゲートというものも基本的には存在しないものだと感じています」（増井氏） 

SHIFTの課題と目指したい組織像（池ノ上 倫士）

つづいて池ノ上から、SHIFTでスタッフエンジニアのポジション導入を検討している背景が語られました。 

SHIFTでは従業員の「やりがい」「報酬」「働く仲間」を大事にしており、「エンジニアリングは生涯勉強しつづける仕事だと思うので、SHIFTはそれを楽しめる風土になっている」と池ノ上は自信をもって説明します。

具体的には、定量的な評価プロセスに加えて報酬に直結するような各種研修・検定プログラムを用意しており、また給与テーブルの最高設定額も2,400万円として、年間平均昇給率も2023年8月期まで5年連続10％超えがつづいています。

では、SHIFTの評価はどのように設計されているかというと、大きくは以下のスライドにある通り、「獲得単価や管理売上金額などの定量データを基準とした評価項目」（左側）と、「自社開発のタレントマネジメントツールによる定量把握」（右側）の2つの側面から実施しています。

特に後者に関しては、従業員の現状を450カラムの項目で表現しており、それらの情報を踏まえて個人の状況が「3分」で把握できるようになっています。このような背景のなかで、池ノ上は以下の問題意識を説明しました。

「左側だけで評価できないが、なんとなく『社内で評価されているよね』『会社が変化するときにはこの人が必ずいるよね』といった人は存在するんですよね。

SHIFTにはいま1万人以上の従業員がいて、当然僕は全員と会ったわけではなく、そういう人をもっとたくさん社内で見つけたいですし、社外からも集まってほしいと考えています。

そのための制度設計をどうするべきかと考えたときに、このスタッフエンジニアの考え方を知り、今回増井さんに伺いたいなと思った次第です」（池ノ上） 

SHIFTにスタッフエンジニアを導入するには（ディスカッション） 

ここからは、お二人によるトークが展開されました。ここでは特に重要と感じたポイントをピックアップしてお伝えします。 

池ノ上：スタッフエンジニアの評価って、実際どうなんでしょうか？

増井：アメリカの事例を基に考えると、実際、ソルバーのような役割を担う人たちが一番多いんじゃないかと本にも書かれています。

じゃあ彼らがどう評価されているかというのは、企業次第ですね。SHIFTさんでは、そういう方々は評価されているのでしょうか？

池ノ上：確実に評価されていますし、組織図上高い役職に就いている方も、タイトルはついていないけれどサラリーとして十分に反映されている方もいます。

今回意外だったのが、スタッフエンジニアを導入しようと思ってみんなに聞いたら、「いらないんじゃないですかね」ってけっこういわれちゃって。

でも名前をつけることによって、そこを目指す人がいればいいのかなとも思っているんですよね。

増井：会社としてその人たちがちゃんと評価されているのであれば、スタッフエンジニアというラベルをつける必要性は必ずしもないとは思います。一方、大事なのは「ほかの部からどう評価されるか」だと思います。

特に技術がわからない人たちに対しては、役職が信頼性をもたせる手段となりますからね。エンジニアのみなさまに聞いたら「いらない」っていうのは、それはそうだと思うんです。

僕らは技術を知っているから。けど、それを知らない人たちにすすめるためには、やっぱり名前／ラベルって大事だなと僕は思います。

池ノ上：先ほど4つのアーキタイプの説明をされていましたが、なんとなく序列ってあるのかなっていう感じがしました。

増井：序列といいますか、役割は違いますし、会社によっては給料の設定とかテーブルとか評価が違ったりする場合もあると思いますね。じゃあどう評価するかですが、結局定量的な判断ってほぼできないんですよ。

これはもう本当にトップダウンで判断してるケースが多いみたいです。

池ノ上：そうすると、やっぱり立ちまわりがすごいむずかしいなって感じがしました。

増井：あと、ここまでは他人から見たらラベルという話をしましたが、もう一つはやっぱり目標という意味もあると思います。

自分がなんとなく得意だから「火消し」をやっている、よく頼まれるから「火消し」をやっている。そういうのって一回転がりはじめるとずっとそっち側に転がるんですよね。

この本ではそういうのを「スタッフプロジェクト」と呼んだりしていますが、本人が自身のキャリアを振り返って、名前とかラベルをつけることでセンターピンが明確になり今後の目標もたてやすくなるわけです。

池ノ上：キャリア目標やスキル分解については、まだ十分に整理されていないと感じますが、そのあたりはどうなんでしょうか？ 

増井：会社やプロジェクトとかと違って“型化”されにくいんだと思うんですよね。なのでこの本でも、ハードスキルの話がほとんど書かれていなくて、ほとんどソフトスキルの話に寄っています。一般化しづらいんだと思います。

池ノ上：キャリアとして目指そうとなったらすごくデリケートな話だと思っていて、迂闊に「目指しなさい」とかいえない気もしています。少なくとも、僕はそういったピープルマネジメントが苦手なんです。

やはり人の人生である以上、そこに「安定」って必要だなと。

増井：この業界自体がまったくもって不安定なので、その上にある役職が不安定なのは一定仕方がないと思うんですね。

一方で、IT技術のいいところはポータビリティが高いことだと思っています。ポータビリティが高いということは、会社／プロジェクトとしては不安定でも、業界全体としてはすごく強く安定しているということだと思います。

そういったなかで、たとえば「ソルバー」とか「火消し」はけっこうどの会社にもいるものだと思うので、それをやってきましたという経験はほかの会社からも評価されます。

その意味で安定性っていうのも、一定確保できるんじゃないかなとは思いますね。

池ノ上：今後、実際にSHIFTがスタッフエンジニアのポジションを導入するとしたら、具体的にどうするのがよさそうですか？

増井：経営層の方々や上位マネジメント層の人たちが、どういう人たちがほしくて、どういう人たちを評価したいのか、というところに大きく寄ると思います。

例えば「火消し」みたいな人たちって、実際に御社内でどう評価されているのですか？

池ノ上：明確に「火消し」っていう評価タイプがあるんですよ。

ほかにも、例えば450カラムのなかの一つに「フォロワー」っていう項目もあって、この人といっしょに働きたいと思うかみたいな360度評価みたいな定期アンケート結果で評価しています。

うちってエンジニアのスキルを「絶対的な市場価値」で決めようという思想がめちゃくちゃ強いんですよ。

そのためにお客様からの声も参考にするのですが、でもけっこうそれって運みたいなところもあるわけで、公平性を保つ、本人がよかったって納得できる制度ってなかなかむずかしいなと感じています。

増井：ソフトスキルとなると、どうしても人間なので相性とか好き嫌いは避けられないかなと思います。それをどうするかは御社のビジネスによるでしょうし、そこはけっこうチャレンジがあるだろうなって思います。 

池ノ上：よりよいエンジニアのキャリアパスについて引きつづき考えていきたいと思います。本日はお忙しいなか、ありがとうございました！

（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）