増井氏の自己紹介
増井雄一郎氏：よろしくお願いします。今日これから話をする増井雄一郎と言います。あらためてよろしくお願いします。
僕のアイコンはお風呂に入っている姿のアイコンで、ここ20年ぐらいずっと使っています。16歳ぐらいの時にフリーランスのエンジニアとして仕事を始めたので、そこから考えると30年ぐらいエンジニアをしています。
僕の名前がけっこうよく出ていたのは前職のトレタという名前の会社にいた時で、あとはiPadの受け付けのアプリのハッカソンで作って、それをいろいろとやっているうちに買い取ってくれる会社があって商用化したりしました。
今はBloom&Co.というマーケティングの会社でCTOをしています。仕事以外にオープンソースも昔からけっこう好きで、「PukiWiki」というネットの寄せ書きアプリみたいなものをオープンソースで作りました。
最近はChatGPTが流行っていますが、あれを使ってSlackのまとめを作ってくれるようなツールを作ってオープンソースで配るといったような活動を、もう二十数年やっています。
（スライドを示して）今回は、この『Staff Engineer』という本の監修というかたちで翻訳が上がってきたもの。僕が翻訳したわけではないので、翻訳が上がってきたものと言いますが、それを見て確認をしたり。翻訳の方はエンジニアではないので、そういった技術部分をサポートしたり……。
ちなみに、会場の中でもう読んだことがある方はどれくらいいますか？
（会場挙手）
3分の1ぐらいですね。読んでもらうとわかるんですが、この本のうち、実は後半のほとんどがインタビューなんですね。英語圏の人たちのインタビューが多いと僕らは実感が持てないので、日本版に向けて日本人のインタビューを4件追加しています。
こういった部分のサポートをしています。先ほど言ったように僕は今CTOで、「お前スタッフエンジニアじゃないやんけ」というのがあるんですが、実は僕自身はCTOというよりはスタッフエンジニアじゃないかと考えています。
僕自身が思うことは、CTOというロールしかなかったから僕は結果的にCTOになったんですね。あと、もともと学生の時に1回起業して、その時は社長という名前だけどエンジニアなので、その時はCTO的なロールも両方やってました。
いままでの職歴の中で自分に適切なロールがなかったから僕はCTOとしてやっていることが長かったんですが、今のはエンジニアの会社じゃなく、テクノロジーの会社というよりはマーケティングが強い会社で、その中での僕の働きを見ると、実はけっこうスタッフエンジニアにつながるものがあると思っています。そういった意味で、僕はこの本を監修しながらすごく楽しく読んでいました。
おかげさまで売れ筋ランキングとかに出て、今もかなり順調に売れているようです。
『Staff Engineer』に書かれていること
（スライドを示して）この本は何を書いているかというと、エンジニアのキャリアラダーについてです。要するに、キャリアをどうやって登っていくのかということについて書かれています。
よく言われていることで、ここに来ている方は特にそう思うと思うんですが、エンジニアとしてキャリアを登っていくと、シニアエンジニアの先、次にあるものはCTOやプリンシパルみたいに役職として大きく段階を飛びます。
1つの会社に3人のCTOがいることはないことはないと思いますよね。CTOの人が辞めないと絶対にそこには上がれない。もしくは奪い取る方法もありますが、それはなかなか難しいです。
そういった中でキャリアを登ってどうするかというと、よくあるのはマネジメント方向に向かうことです。要するにVPoEエンジニアリング、エンジニアリングマネージャーといわれる職にいきましょうと考えます。
日本でいうと、もう1つはプロダクトオーナーみたいな役割として、プロダクトをリードしていくほうになりましょうというのもあります。要するに人の管理をするか、プロダクトの管理やプロダクトのリードをするか。こういった2つの大きな道に分かれます。エンジニアとしてはシニアエンジニアから先があまりない状況になっています。
このスタッフエンジニアという役職は、そのエンジニアとしてのキャリアの延長線上で、この本はシニアエンジニアを超えた先にどんなキャリアがあるのかを解説している本になります。
スタッフエンジニアの“スタッフ”の意味
スタッフエンジニアという役職自体は、僕もネットで見てなんとなく名前は知っていたんですがあまり気にしたことがなくて、この本の監修をやるまではあまり考えたことがありませんでした。
“スタッフ”って言葉をたぶんみなさんが聞くと、だいたい一般職員という意味での“スタッフ”ぐらいしか思いつかないと思います。僕も“スタッフ”という単語を聞くと、どちらかというと一般職員のことだと思います。「スタッフの採用をしよう」と言ったら、みなさん「一般的な人を採用しよう」ということだと思うでしょう。
ただ、ここでいう“スタッフ”は軍事用語としての“参謀”という意味らしいんですね。僕もこの本をやるにあたって、調べたり辞書を引いたりを初めてしました。
（スライドを示して）ここに書かれているように、軍の指揮官が作戦などを立てた場合、その作戦を実行するにあたって、その指揮官の補佐をする人たちのことを“参謀”、“スタッフ”と呼ぶ軍事用語になります。
こういった人たちは今まで会社に存在しなかったかというと、もちろんそんなことはないわけですね。例えばCTOがいるところだと、CTO室みたいなものを設置している会社はけっこうあると思うんです。そこの人たちは何をしているかというと、CTO室だからCTOの補佐をしていることが多いですね。その人たちは、言い方を変えれば本当はスタッフエンジニアなわけです。
日本だとCTO室みたいな名前だけど、そうじゃなくて別の見方としてこういったものがあるというものをまとめたのが、スタッフエンジニアという役職になります。
このスタッフエンジニアにはどういった役割があるのか。もちろん技術のことがわかること、コードが書けることはいわゆる基礎としての役割になるんですが、その上でどういった役割があるのかを本の中で大きく4つ挙げています。この4つ以外がないわけではないとこの本でも言っているんですが、概ねこの4つに分解できます。
スタッフエンジニアの役割1 テックリード
1つはみなさんも聞いたことがあるようなテックリードです。これはもう設置している会社がけっこうあると思います。シニアエンジニアに1番近く、シニアエンジニアが一定行くと、テックリードというかたちでチームの中で技術もリードをしていろいろな意思決定をしていきます。
一番簡単なことは、フレームワークは何を使うのかとか、場合によってはリファクタリングはいつ行うのかとか、「このチームでできる技術的なことは何なのか」という、チームの技術的なビジョンを決めます。実際にこの人はコードは書かないかもしれない。
役職としてテックリードが一緒にコードを書くことももちろんあるんですが、テックリードという役割の中でコードを書くことではなく、あくまで技術的なビジョンを持って決める人という役割になります。
まずこれがスタッフエンジニアの1つの役割です。ただ、あとでちょっと話しますが、ここでいうスタッフエンジニアの役割としてのテックリードと、役職としてすでにあるテックリードは少し範囲が異なります。
スタッフエンジニアの役割2 アーキテクト
（スライドを示して）もう1つはアーキテクトです。これもすでに設置している会社はあると思います。
これは要するに、インフラやデータベース、APIなど、アーキテクトといわれるいくつかのセクション。その技術的なセクションの中の意思決定をしたり、複雑な設計をしたりする人という役割になります。
この場合、例えばAPIの設計をする、インフラの設計をする時に単純に技術として選ぶわけじゃなくて、例えばインフラであれば「このサービスはエンタープライズで24時間365日絶対に止められない」ということを選ぶインフラと、ゲームみたいなもので「もちろん基本はダメだけど、最悪止まってもいい。それよりはスケールを優先して、例えばテレビCMを打った時に100倍のトラフィックに耐えられるようなスケールを」と考えながら設計をしていくインフラもあります。
それは「どれくらいスケールするのか」という技術的なことだけじゃなくて、経営としてどれくらい投資をして、例えばCMをどれくらい打って、どれくらい伸ばしていくのかとか、顧客のニーズとしてどれくらいのものが要求されるのか。データベースも含めてインフラとかを決めていくのがアーキテクトという役割になります。
スタッフエンジニアの役割3 ソルバー
ここからあと2つはたぶんみなさんがあまり聞いたことがない、僕もこの本で初めて知った2つの役割があります。1つはソルバーです。“ソルブ”は要するに“解決する”という意味ですが、ソルバーといわれる、問題を解決するような役割です。
先ほどのCTO室であれば、CTOから言われた難しい問題の解決をする人です。それは技術的なこともあれば、社内に説明する政治的なものも含めて、技術を中心とした難しい問題を、どちらかというとトップダウンで解決します。
先ほどのテックリードやアーキテクトは、現場から上がってきたものと一緒に……。ボトムアップで仕事をすることがあるんですが、このソルバーはトップダウンで落ちてきた難しい問題を解決します。
もちろんこれから立ち上げる新しいものであればそれはそれでいいんですが、火消しみたいなかたちで。たぶん各社に火消し担当、担当というのはなんですが、火消しを得意とする人はたぶんいると思います。
何か炎上が起こった、システムが止まったとか、スケールしなくなったという何かが起こった時に、そこに突っ込んで何かを解決する。こういった役割を負うこともあって、こういう人たちをソルバーといいます。
アーキテクトやテックリードと言われる人はそんなに数が多くなかったりするんですが、会社によってはこのソルバーが、例えばジュニアとかが多いところは、火消しの数が多い組織もありえます。
スタッフエンジニアの役割4 ライトハンド
もう1つは右腕、ライトハンドというんですが、これはCTOの右腕として働きます。例えば、今は機械学習みたいなものがすごく流行っていますが、僕が機械学習に詳しいかというと、今勉強をがんばってしているけど、そんなに詳しくないわけですね。そういった時に、CTOの代わりに技術的な意思決定をしたりします。
あと、大きい会社だとCTOがいろいろな全部の会議に出られるわけではありません。その時に、CTOの代理やCTOの補佐みたいな名前で、その人の役職とその人の権限を持って代行する役割を右腕といいます。
今までの役職と一番違うところは、この人たちの主戦場はもしかすると会議室なのかもしれないということです。要するに、CTOという名前を借りて、その人の代わりに意思決定をする。先ほど言ったように、CTOが1人しかいないとなると、全部を意思決定できるわけではないので、その代わりにやる人たちのことをライトハンドといいます。
先ほどのソルバーが技術的な火消しだとすれば、ライトハンドは組織的な構造に対する火消し、組織がこんがらがってしまった時の火消しをするという役割を負うこともあります。
（スライドを示して）それとこれとはまた別に、最近よく言われるIndividual Contributorのような、個人で開発として貢献をしていく……。これは普通のエンジニアとしての能力、自分の個人のスキルを活用してプロダクトに反映させていく役割になります。これはスタッフエンジニアとは違うんですが、今のシニアエンジニアより上位というか、シニアエンジニアたちも含めたエンジニア、手を動かすエンジニアとしての上位職として最近すごく認知されています。
（次回につづく）
