スタッフエンジニア座談会　〜estieのスタッフエンジニア全員集合〜

こんにちは！スタッフエンジニアの @kenkoooo です。estie は2023年「スタッフエンジニア」という職種を新設し、僕がその1人目として活動していましたが、2024年から新たに Lin と tokuhara の2名がスタッフエンジニアとなりました。この記事では3名のスタッフエンジニアによる対談をお届けします。estie でスタッフエンジニアがどのように活躍しているかをお伝えできれば幸いです。

対談メンバー

Lin (@Ryosuke839):
2023年4月入社。データ領域でスタッフエンジニアを務める。estie 入社以前は SoundHound Inc. にて Staff Software Engineer として音声アシスタントのバックエンド開発に携わっていた。
やりたいことを探していたらestieに入社していた… - estie inside blog

tokuhara (@wh_choco) :
2023年5月入社。プラットフォーム領域でスタッフエンジニアを務める。estie 入社以前はファーストリテイリングにてリードエンジニアとしてCI/CD、監視、セキュリティ改善に携わっていた。
爆速で成長する組織・サービスにSREとしてジョインした - estie inside blog

kenkoooo:
2022年5月入社。プラットフォーム領域でスタッフエンジニアを務める。
Indeedで働き納め、余生はestieで始める - estie inside blog
1人目スタッフエンジニア・kenkoooo氏が語る「技術力」よりも強力な武器 | レバテックラボ（レバテックLAB）

スタッフエンジニアになって変わったこと

kenkoooo: 今日はよろしくお願いします。まず皆さんの仕事と役割について教えてください。estie ではどんな仕事をしていますか？

Lin: 私は普段はデータマネジメントグループ (DMG) という部署で、各プロダクトで使うデータを作っています。データを作ると言っても色んな仕事があるのですが、その中でもデータパイプラインのアーキテクチャを考えたりとか、チームにまたがった部分をどうしていくか考えたりとか、他の人と相談したりするのが多い仕事です。

kenkoooo: スタッフエンジニアっぽいですね。ありがとうございます。tokuhara さんはどうですか？

tokuhara: 私は Platform Engineering チームにいて、CI/CD ワークフローの統一、全プロダクトで Preview 環境を使えるようにしたりと、開発生産性を上げるためのツールを作って、開発効率を上げていくということをやっています。あとは、もともと SRE なので、AWS などのインフラ周りや、システムのモニタリングなど、結構手広く色々やっています。直近は、これからの 3 年間で estie でどういう事業が発展していくかを事業部の方々にヒアリングをしていて、そこから開発組織は何をやっていくのかをマイルストーンに落とし込む、というのをやっています。

kenkoooo: ありがとうございます。estie の中で、スタッフエンジニアとそれ以外のエンジニアで、違いみたいなものはありますか？

Lin: 明確な線引きはない気がしています。ただ、スタッフエンジニアという名前によって勝手に責任範囲が広がっていく感じはしますね。別にスタッフエンジニアでなくてもスタッフエンジニアみたいな働き方をしようとしている人はたくさんいて、スタッフエンジニア任命は、あくまでそこにお墨付きを与えるというだけのことだと思いますね。

tokuhara: そうですね、ほとんど同じ意見です。後からついてくるようなイメージですよね。スタッフエンジニアになるために何かをするというより、会社のために色々やっていると、自然と横断的に動くとか、深い問題を解決することが増えてきて、そこに言葉がついてくるようなイメージです。

kenkoooo: スタッフエンジニアになったことで何か変わったことはありますか？前後で全然変わらないのか、それとも、お墨付きがついたことで何かが変わったみたいな。

tokuhara: 自分はあって、スタッフエンジニアというお墨付きがついたことで、一歩踏み込んで、今までの自分とは違うものを担わないと、という思いがあります。今やっている各事業部へのヒアリングというのも、自分の殻を破る突破口になるかもと思ってやっています。

Lin: 私も義務感は感じていて、やっていることは全然変わってないんですけど、気持ちはだいぶ「やらねば！」となっています。最近は対外的にプレゼンスを高めるためにテックブログを書くとか、仕事をするときも全社的にボトルネックがどこになっているのかを考えることが増えてきた気がしています。

kenkoooo: すごい。ちゃんと仕組みが機能している。

tokuhara: 考えてしまうんですよね。これまでと変わらなかったらスタッフエンジニアになった意味がないなと思ってしまって。

Lin: 「こういうときスタッフエンジニアだったらどうするんだろう」と考えますね。もうスタッフエンジニアではあるんですけど、本物のスタッフエンジニアはどうあるべきなんだろう、と。

tokuhara: その一歩が何かっていうのはまだ模索しているところですね。

kenkoooo: いい話。なんかもうブログに書きたい内容終わったな。

tokuhara: ちなみに kenkoooo さんはどうだったんですか？

kenkoooo: 僕がスタッフエンジニアになった 1 年前の当時は、自分で言うのもなんですが結構独特の働き方をしていて「なんでもやる」みたいな感じだったんですけど、それが「kenkoooo だからやっている」みたいになっていたんですよね。でも tokuhara さんと Lin さんもそういう働き方をしつつあったし、これを類型化することができないかというのを思っていて、もっと一般的なラベルを貼ることによって「kenkoooo がやっている」ではなく「スタッフエンジニアがやっている」っていう感じにしたかったんですよね。そうすると再現可能というか、会社が拡大しても色んな人が横断的に働いてくれるようになるんじゃないか、と思ってました。なので、当時は肩書をもらったと言うよりは、tokuhara さんと Lin さんが含まれる肩書を作ろうと思っていました。まあでも、僕も肩書がついたら「やらねば」となりましたね。

Lin: 最初スタッフエンジニアの肩書をもらったときに、もともと kenkoooo さんがスタッフエンジニアだったので、「こういうときスタッフエンジニアだったらどうするか？」というのはパッとは思いつかないですけど、「こういうとき kenkoooo さんだったらどうするか？」というのは結構思いつくので、スタッフエンジニアとしてやりやすいというか、ある意味お手本みたいなのがあったというのはありますね。何がベストかというのはまだ全然分かってはいないんですけど、kenkoooo さんのように前例があるとというのはすごく心強かったです。

tokuhara: すごくわかる。

kenkoooo: いい話だな。これ自分でブログに書くの恥ずかしいですね。

スタッフエンジニアに求められること

kenkoooo: スタッフエンジニアとして、どういうところに影響力が与えられると思いますか？技術的な領域であったり、あとは全社のエンジニアに影響を与えていくわけですが、そのための振る舞いみたいなところで何かありますか？

Lin: やることとしては今までの延長線上にあるので、スタッフエンジニアだからといって大きく変わることはないと思いますが、スタッフエンジニアという名前があることでインパクトを出せるところはある気がしますね。「スタッフエンジニアがこう言ってるんだからそれは良いことなんだろう」みたいな説得力が出ることもありそうですし。自分の腕力にお墨付きがついたことで影響力を出せそうというのは思います。実際のところはどうかまだわからないですが。

tokuhara: 自分は今まで開発組織の中でもエンジニアの中に閉じているような働き方をしていて、エンジニアの開発を支えることを目指していたんですけど、スタッフエンジニアとしてやっていくのであれば、もう少し上の階層、デザイナーやプロダクトマネージャーを含む開発組織だったり、もっと大きく事業部っていうところにも視野を広げていくべきかなっていうのはちょっと思っています。「エンジニアのための」っていうところから「会社のための」って目線が上がったかなと思います。

kenkoooo: 「スタッフエンジニアだから」って明言されることはないけど、あてにされることは増えるかなって気はしますね。

tokuhara: 「そのレベルで動けるでしょ？」みたいな感じですね。

kenkoooo: 以前はできなかったけど、スタッフエンジニアになったことでできるようになったことはありますか？

Lin: 今までスタッフエンジニアという称号がないからできなかったというわけではなく、称号がないときはやる気が起きなかった部分があって、さっきの「やらねば」っていうところにもつながる話なんですが、スタッフエンジニアだからこそ、そういうところに突っ込んでいく気持ちが出てきたっていうのはあると思っています。私の場合はチームに閉じないところをやっていくのは、スタッフエンジニアになったからこそやる気が湧いてきたなと。昔から大事だとは思っていましたし、別にやっちゃいけないことだとは思っていなかったんですけど、スタッフエンジニアになるとやはりそういうところを「やらねば」と…

tokuhara: そうそう「やらねば」ってなりますね。

kenkoooo: 誰かがやった方がいいんだろうなっていう仕事があったときに、スタッフエンジニアじゃなかった時は「誰がやるんだろう？」って思ってたんですが、スタッフエンジニアになると、この中で誰がやるかっていうと自分か、ってなることが増えてきますよね。誰がやるのか分からないみたいなフワフワした状態は減ってきて、「これをやるとしたら僕なんだろうな」「Lin さんなんだろうな」「tokuhara さんなんだろうな」みたいな、やった方が良いけど誰もやってないことについて、やるとしたらこの人、みたいになるのは結構ある気がします。

経営層・他のエンジニアとの関係

kenkoooo: 事業責任者とか CTO とか、経営に近い人と話す機会は増えたりしてます？

Lin: そこまで変わってないと思っていて、私のチームだと PM の松田さんが色々キャッチするのがうまいので、そのへんはやってくださっていることに乗っかってる感じですね。整備されてなかったら色々自分で聞きにいく必要があったとは思いますが。

tokuhara: 自分は増えてきましたね。今やっている事業部へのヒアリングもそうですし。上司の VPoE の Keigo さんからも、自分の目線とか解像度も上げるために、事業部や経営層から話を聞く機会を意識して増やしていくことを勧められていて、やっていく気持ちにはなっています。

kenkoooo: ありがとうございます。自分のプログラミングする時間を減らして、他のエンジニアを助ける時間が増えたりとかってあります？

Lin: たしかに、自分がプログラミングをする時間は減っていて、それはちょっと寂しいというか、時間が足りないと感じています。ただ、助けている人々がすごく優秀なので、自分が一人でやるよりも明らかに大きな成果が出ているというのは感じられて、良いなと思っています。ただ、これはスタッフエンジニアだからというよりは、周りに優秀な人が多いというのが大きいと思っているので、スタッフエンジニアになったからこそ、というのはあんまりないかもしれないですね。

tokuhara: 自分はもともと、どちらかと言えばインフラに近い立ち位置なので、色んな人に助けを求められることが多くて、正直変わっていないですね。あと Platform Engineering チームにはベテランの人しかいないので、同じ領域でのヘルプとかはほぼ無いですね。

kenkoooo: ありがとうございます。社内の技術力を底上げしたり、設計を良くしたりすることに時間を使うようになったとかはあります？Lin さんは Snowflake と dbt の技術的に深いところを掘り下げて、リテラシーを上げてくれているような感じがします。

Lin: 自分は新しいことを探しに行くのが苦手だと思っているのですが、今の技術から派生していくのは得意だと自分でも思っていて、dbt をもっと活用するにはどうしたら良いとか、Snowflake をもっと便利に使うにはどうしたら良いとか、常に探っているというのはありますね。新しいテクノロジーを見つけるというのは苦手で、色んな人の times チャンネル*1の投稿とかを眺めて、「へえ〜」って思いながらやってます。

tokuhara: 難しいところですよね。

kenkoooo: まあでも1つの小さい例ですけど、tokuhara さんが実装していた fluentbit を使って各プロダクトで設定無しでログを S3 と Datadog に出せるようにするやつは新しい技術と言えると思いますし、Lin さんの Snowflake の Model Registry を dbt 越しに使えるようにするみたいなのは革新的だと思うので、結構やっていただいていると思います。こういうのは別に誰がやってもいいと思うんですけど、誰もやる人がいなかったときに、そこを掘り進んでいくのは誰かと言うと、お二人なんだろうなと思いますし、実際にやっていただいていると思います。

Lin: 仕組みを用意するのはもちろん大事なんですけど、それを実際に使ってみて便利だよというのを示すところまでやらないといけないとは思っています。fluentbit とかも最初 Design Doc *2で出てきた時は何なのか全く分かってなかったですけど、実際使ってみたらメチャクチャ便利だったので、そういう体験を広めていくというのも我々の仕事のうちかなと思っています。

tokuhara: 最初に手を動かすのが大事ですよね。Design Doc は設計なので、これで動きそうだというのは分かるんですけど、実際使い勝手はどうなのというのは分からないので。そこに一歩踏み込んでやっていかないと結論はずっと出ないので、早めに答え出して、良さそうだったら一気に入れるというのが良いと思います。

kenkoooo: そういう意味ではスタッフエンジニアって、設計もやるけど、実際に動かしてみる腕力みたいなのも必要だと思っていて、設計と実装をセットで社内のエンジニアに還元できるのが結構重要かなと思いますね。

kenkoooo: 他のエンジニアをスポンサーしたりとかはあります？

Lin: kenkoooo さんにスポンサーしてもらった感じがしてます。自分が他の人をスポンサーできているかというと、まだ手が回ってない状態ではある気がしてます。

kenkoooo: スポンサーされた感あります？

Lin: いろんなところでさりげなくスポンサーされた気がします。

kenkoooo: 本当ですか？僕もあんまり意識してなかったかもしれない。

tokuhara: kenkoooo さんがいてくれて、こういう動きがスタッフエンジニアなんだというのはなんとなく分かった気がします。先ほど kenkoooo さんは「スタッフエンジニアになっても変わってない」って言ってたんですけど、実は傍から見ると結構変わったように見えていて、この動きスタッフエンジニアっぽいなって何度か思ったことがあるので、直接的なスポンサーじゃないですけど、これだっていうのを勉強させてもらってました。

kenkoooo: 恐縮です。自分が知らないことが出てくると、なんか恥ずかしいですね。

スタッフエンジニアになるためには

kenkoooo: スタッフプロジェクト*3みたいなの、何かありました？

Lin: スタッフプロジェクトをやろうという話を CTO とか上司としてましたし、これをやったらスタッフエンジニアですみたいなの言われた気がしたんですけど、実はパッと思い出せなくて…

tokuhara: Lin さんはいろんなことをやっているので、それの積み重ねでスタッフエンジニアになったイメージがあります。1個でっかいのドカンってやったっていうよりかは、すごく良い改善を何個も何個もやっていたっていうイメージです。

kenkoooo: tokuhara さんも CI/CD だったりとか、Preview 環境もそうですし、積み重ねているイメージです。

Lin: スタッフエンジニアになる前から、とりあえずインフラ関係で困ったら tokuhara さんにお願いしたら解決するわっていうのはありましたね。

kenkoooo: たしかに、これをやりきってたからスタッフエンジニアっていう感じはあまりしなくて、でも振り返ってみると、これもあれも Lin さんがやったやつだし、これもあれも tokuhara さんがやったやつで、っていう感じでしたね。

kenkoooo: 他の人へのアドバイスみたいなのありますか？例えば「スタッフエンジニアになりたいです」というジュニアなエンジニアがいたときに、どういう言葉をかけてあげるか。社内でメッチャやってる人は「なってくれ！」っていう感じはするけど、そうじゃなくて例えば面接で「スタッフエンジニアになりたいです」っていう人がいたら？

Lin: かける言葉は難しいですね。全てを貪欲にやってたら勝手になる感じはします。

tokuhara: 目の前のことをきちんとやることですかね。中途半端にやるんじゃなくて、きっちり最後までやり切るという。そうすると信頼が積み重なって、その結果として「スタッフエンジニアとかいいんじゃない」っていう話になったりしそう。

Lin: そうですね。ちゃんと完成品をたくさん作ってますっていうのを示すのが大事なのかなと思います。自分のプロジェクトだけじゃなくて、他の人が困ってたら行ってちゃんと完成させるとか、そういうのがあると良さそう。

tokuhara: そう。多分そういう風になってくると、どんどん規模が大きくなってくるんで、ひたすら繰り返していくと、スタッフエンジニアって感じ。

kenkoooo: 「合格！今日からスタッフエンジニアですよ」っていうよりかは、スタッフエンジニアという看板を背負わされて、それによってより大きな仕事に巻き込まれるようになる感じですよね。

Lin: 全然ゴールではないですよね。

印象に残ったアドバイス

kenkoooo: ここまでのスタッフエンジニアへの道の中で、役に立ったアドバイスとかあります？

Lin: 上司から「ちゃんと全社的な目線を持てるといいですね」とはよく言われていて、いま思うと、それがスタッフエンジニアへの階段だったんだなと思います。

tokuhara: 視野を広く持つってところですよね。

kenkoooo: 我々は結構手を動かすのが得意じゃないですか。それによって素早く影響力を出すことができるんですが、そこに集中すると全社的な視野を持ちづらくて、定期的に言ってくれる人は結構ありがたいとは思います。週 1 ぐらいで CTO の Nari さんと話す機会があるんですけど、そのたびに全社的な目線に引き戻される感じがあります。

tokuhara: 「その仕事に魂はこもっていますか？」はよく言われますね。「仕事をお願いしたら完遂できますか？」ということですけど、そこを見せていかないと安心して任せられないじゃないですか。そういう気概を持ってほしいというのはよく言われてますね。

kenkoooo: 逆にスタッフエンジニアになりたい人へのアドバイスがあれば。

Lin: やっぱりスタッフエンジニアがゴールではないというところですかね。

tokuhara: 通過点ですよね。

Lin: スタッフエンジニアになるような働き方をしている人にしたら、そのお墨付きも責任も心地いいくらいのことだと思います。自然にスタッフエンジニアになれるくらいにのときがちょうどいいんでしょうね。

kenkoooo: スタッフエンジニアになったことによって周りから頼まれることが増えたとか、頼まれるものが変わったとかあったりします？

Lin: 周りから頼まれやすくなった気がします。頼む人の障壁がだいぶ低くなったという感じはしています。「スタッフエンジニアって肩書がついている人だったらやってくれるっしょ」みたいな。それは求めてたことですね。

kenkoooo: たしかに、エンジニアだったらまだいいですけど、そうじゃない人からすると、いま会社にエンジニアが 30 人以上いて、誰に頼めばいいか分かりにくいですよね。そういうときにわかりやすい目印がいたら、その人に頼めるので良さそう。

kenkoooo: スタッフエンジニアになったばかりの人へのアドバイスがあれば。

tokuhara: 空回りするのだけは気をつけた方が良さそう。

Lin: わざわざスタッフエンジニアに任命されたということは、それまでの働きぶりから相応しいと思われたということなので、同じように続けても十分スタッフエンジニアだと思います。なので、落ち着いて。もちろん、そこからどんどん踏み出していくというのが求められていますけど。

kenkoooo: スタッフエンジニアになったから変わっていくというよりは、パフォーマンスに再現性みたいなものがあるからなっている感じですよね。

マネジメントのキャリアパス

kenkoooo: マネジメントのキャリアパスについては考えたことはありますか？

Lin: 私は全くなくて、他の優秀な方々がいるので、自分は実装に集中するぜ、みたいな。

tokuhara: 自分は実は、最近朝電車に乗るときとかマネージャーの本を読んでいます。自分がなりたいというわけではないんですけど、働く上で EM の方々とも一緒に仕事をするので、向こうの責務は何かっていうのは知っておいた方がいいと思っています。本を読んで、EM はこういうことをやらなきゃいけないんだなっていうのを、知識として学んでいます。

kenkoooo: 僕も向いてないなと思って考えてないですね。優秀な EM の方々を見て、こういうマネージャーにはとてもなれんなっていう感じで。

tokuhara: 皆さん話が上手いですよね。

勉強方法

kenkoooo: 勉強するリソースみたいなのはなにかあります？本とかブログとかでも。

Lin: 私は全く本を読まないんですけど、代わりと言っちゃなんですが、コードは無限に読むっていう自信はあります。

kenkoooo: 僕もその魂を受け継いでコード読んでます。

tokuhara: kenkoooo さんもずっとコード書いてますよね。

kenkoooo: Lin さんに影響されてます。「Lin さんは本を読まなくても実装を読めば分かると思ってる」って噂されてますよ。

tokuhara: 自分は本も読みつつ、手も動かしつつ、半々ってところですね。

kenkoooo: どういう本を読みますか？

tokuhara: 自分に関係する本が多くて、SRE 本だったり、最近は Platform Engineering の本がオライリーから出たので、それを読んでいます。英語なので時間かかってるんですけど。自分の得意領域を伸ばしたり、自分の考え方があっているかを確認したりするために本を読んでいます。手を動かす方は、仕事柄 YAML とか Terraform とかばっかり書いているので、プログラム書きたいなって思ったときに勉強する感じですかね。