貢献に肩書が追い付いた――estie流・スタッフエンジニアの在り方とは

近年、技術の高度化による開発組織の拡大に伴い、「スタッフエンジニア」という職種を耳にする機会が増えました。「スタッフ」と聞くと「一般社員」などが連想されがちですが、この職種では「参謀」の意味合いが強く、技術的な知識やスキルで組織横断の課題解決をけん引する、いわば「技術参謀」と呼べる存在です。一方、マネジメント業務の度合いなど詳細な役割は、企業によって異なります。

商業用不動産データ分析基盤「estie マーケット調査」などを提供するestieでは、kenkoooo氏、山本亮介（Lin）氏、徳原晋一（tokuhara）氏の3人がスタッフエンジニアを務めています。本記事では、彼らがスタッフエンジニアに就任したきっかけや、日々向き合っている技術課題、求められるスキルを聞くとともに、その中で見えてきた「技術で会社を良くしたい」という貢献意識に焦点を当てます。

tokuhara氏（左）、Lin氏。kenkoooo氏はZoomの画面キャプチャーで撮影に応じてくれた

──まずは、皆さんの所属部署と日々の業務を教えてもらえますか。

tokuhara 私はSRE（Site Reliability Engineering）を担当しています。Platform Engineeringチームに所属しており、認証基盤など複数のプロジェクトで横断的に使われる基盤を管理しています。インフラ領域、CI/CD、モニタリングに強みがあり、これらの分野における横断課題の解決に取り組んでいます。

Lin 私はデータマネジメントグループ（DMG）に所属しており、各プロジェクトに共通のデータを提供しています。具体的には、データパイプラインのアーキテクチャ設計やデータの仕入れ方法の検討を行っています。ビジネス提携によるデータ調達に加え、不動産領域のオープンデータ探索も行い、データの仕入れからプロダクトへの提供まで幅広く携わっています。実は、estieに入社して初めてSQLを記述するなど、新しい経験も積んでいます。

kenkoooo 僕もtokuharaさんと同じPlatform Engineeringチームで働いています。tokuharaさんがインフラやネットワークに近い領域に強いのに対し、僕は認証基盤などもう少し上位のレイヤーを担当しています。例えば、多数のプロダクトに対して異なるアカウントを配布するのは非効率なので、一つのアカウントで複数のプロダクトにアクセス可能にするなど、ソフトウェアのプラットフォーム構築を主に行っています。

estieのスタッフエンジニアは“手を動かすCTO”

──estieにおけるスタッフエンジニアの役割はどういったものでしょうか。

kenkoooo estieのスタッフエンジニアは、一言でいうと“手を動かすCTO”です。一般的にCTOは現場で直接手を動かす機会が減っていきますが、ソフトウェアの提供で売り上げを立てている当社では、自ら開発に携わりつつ、全社的な技術の方向性や投資の戦略を決定する存在が必要となります。現在、開発組織の構築はVPoEやマネージャー、技術面の推進はわれわれスタッフエンジニアが中心となって担っています。

──estieのスタッフエンジニア職はピープルマネジメントは担当せず、技術的なリーダーシップに専念する職種設計だと聞きましたが、実際に働く中でどのように感じますか。

Lin ピープルマネジメントは主にマネージャーが担当していますが、かといって人と会話しないわけではありません（笑）。マネジメントの“責任”までは負いませんが、個々のメンバーとは真摯に向き合い、それぞれの課題を一緒に探すことなどは、ジョブディスクリプションにはなくても自発的に行っています。例えば、kenkooooさんはよく、様々なメンバーの“影のサポーター”として、彼らを動かす役割を担っていますよね。

kenkoooo そうですね、マネージャーでなくともチームメンバーと協力したりサポートしたりすることは多々あります。マネージャーと異なるのは、“責任の所在”ですね。企業では、全社員が自社の売り上げに責任を持つ必要がある中で、われわれスタッフエンジニアはより良い技術を最大限に活用し、社員の技術レベルを引き上げることで売り上げに貢献しています。

──スタッフエンジニアに共通する役割として、組織横断の技術課題に向き合うことがあると思います。皆さんは、どのような技術課題に取り組んでいますか。

tokuhara 多すぎて、全部話すと日が暮れてしまいますね（笑）。

Lin 例えば現在、マルチプロダクト戦略のもと多くのプロダクトを開発しており、解決したい業務領域も広がりを見せています。不動産のアセットタイプと業務領域の掛け合わせで多数のプロダクトが生まれようとしており、各プロダクトを担当するチームも増加中です。一方、認証基盤や基礎データなど、プロダクト横断で共通利用したい技術基盤もあり、スタッフエンジニアはその整備を担当しています。あるプロダクトで収集されたデータが他のプロダクトでも活用できると分かった時は、その展開にも取り組んでいます。

求められるのは、分野横断の高い技術力

──kenkooooさんは一人目のスタッフエンジニアとして活動しており、その後Linさんとtokuharaさんが加わったそうですね。なぜ、お二方だったのでしょうか。

kenkoooo 以前は社内のエンジニアが少なかったので、僕が中心となって組織横断の技術課題に取り組んでいました。そんな中、Linさんが2023年4月、tokuharaさんが同年5月にestieへ入社し、Linさんはデータマネジメント、tokuharaさんはSREの領域で、それぞれリードするようになりました。技術的なリーダーシップは僕がとっていましたが、各領域においては圧倒的にお二人のほうが詳しかったんです。

当時は明確な肩書がなかったのですが、2023年10月に僕が一人目のスタッフエンジニアになり、2024年11月にお二人が就任しました。組織横断の技術課題に対応できる人材を確保する必要がある中、お二人には「kenkooooみたいにやって」などのあいまいな指示ではなく、「この役割をお願いしたい」と職務をパッケージ化して提示したほうがいいと思い、「スタッフエンジニア」の肩書を設けたという背景があります。他のエンジニアにとって目指すべきマイルストーンになるのではないかという思いもありました。

今後も、各領域でリーダーシップを発揮している人にはスタッフエンジニアに任命することで、社内のメンバーが困った時、誰に頼ればいいのかを明確にしたいです。大きな責任が伴うので向き不向きはありますが、お二人のようにキャパシティのある人には大きな責任を持ってもらい、仕事が集中するようにしています。多くの企業と同様、estieでも「たくさん仕事をする人を増やしたい」と考えています。

──estieのスタッフエンジニアには、どのようなスキルが求められるのでしょうか。

kenkoooo 例えば、特定のプロダクトの機能に関する質問であれば、そのプロダクトの担当者に聞けばよいのですが、実際には“誰の担当ともいえない技術課題”も多く存在します。こうした課題は、データ、セキュリティ、アプリケーション、ドメイン知識などが複雑に絡み合っており、単一の専門性では対応できません。スタッフエンジニアには、こうした“カオス”を楽しめるだけの技術力が求められます。その上で「自分がやる」と引き受けられる当事者意識も大切ですね。

“お墨付き”を得て、もっと頼られる、挑戦できる

──スタッフエンジニアに就任したことで、日々の業務にはどのような変化がありましたか。

Lin 以前から組織横断の技術課題には取り組んでいたので、実はスタッフエンジニアになっても業務に大きな変化はありませんでした。しかし、スタッフエンジニアという肩書を頂いたことで、“お墨付き”を得たと感じるのと同時に、期待されていることを改めて認識しました。実際、「この件はこの人に聞いてみよう」と社内のメンバーに頼られる機会は増えました。

tokuhara Linさんと同様に、業務内容自体に大きな変化はありませんが、周囲から「もう一つ上のレベルを目指してほしい」という期待を感じるようになりました。こうした期待に応えるべく、様々なチャレンジをしています。うまくいかずに落ち込むこともありますが、会社が私に期待し、これまで手を伸ばしていなかった領域にまで挑戦させてくれることはうれしく思います。

kenkoooo 組織横断の技術課題に対して、明確な方向性を示せる存在になれることは、大きなやりがいですね。例えば、全社インフラの再設計であればtokuharaさん、データパイプラインのロードマップであればLinさんなど、それぞれの領域において「この人に聞けば分かる」という信頼感が社内で醸成されています。

──estieのブログでは、スタッフエンジニアを目指す人へのメッセージとして「目の前のことにきちんと取り組んでいれば、信頼が積み重なって肩書はついてくる」といったことが書かれていましたね。

kenkoooo estieには、このような考え方が深く根付いています。エンジニアの等級制度も同様で、例えば「これができたからレベル3に昇格する」というよりは、既にレベル3に相当する貢献をしている人に、レベル3という等級が付与される形です。スタッフエンジニアの場合、既にスタッフエンジニアの役割を担っている人に、その肩書が付与されるといえます。

kenkoooo氏に見る、会社全体の能力を底上げする力

──kenkooooさんは、スタッフエンジニアにLinさんとtokuharaさんが加わり、心強くなったなど、心境の変化はありましたか。

kenkoooo それはすごくありますね。実はtokuharaさんとは以前も同じ職場で働いており、当時僕は社会人1年目、tokuharaさんは6年目と大先輩でした。その頃から尊敬していたので、彼がestieに入社した時から「僕なんかよりもずっとすごい人がいるんだから、皆tokuharaさんを頼ってくれよ」と思っていました（笑）。だからこそ、スタッフエンジニアへの就任はすごく自然な流れだと捉えています。

Linさんについても同様の感覚です。僕は以前の職場でもLinさんと働いており、その頃から彼はスタッフエンジニアに相当する業務を担っていました。Linさんの仕事に対する姿勢から学ぶことは多く、ある意味自分は「なんちゃってスタッフエンジニア」という気持ちすら抱いていました。だからこそ、お二人が加わったことで「ようやく本物が現れた！」という感覚があります。

──スタッフエンジニアとしてのkenkooooさんに対して、リスペクトしている部分を教えてください。

tokuhara 個人的には、フットワークの軽さが最初に思いつき、自分にはなかなか真似できないと思っています。エンジニアだけでなく、事業のオペレーション部門にも臆することなく飛び込み、直接話を聞いて問題解決につなげている印象です。私たちが急に同じことをしたら「何しに来たんだ？」と警戒されてしまうかもしれませんが、kenkooooさんは自然と馴染んでいるので、その人柄やスタンスを尊敬しています。

Lin 人を動かす力やプロモーションする力も素晴らしいと思います。私たちがスタッフエンジニアになった際も、kenkooooさんがマネジメント層に対して熱心に働きかけてくれたと聞いています。スタッフエンジニアだけでなく、estieの様々なメンバーが活躍できるよう、コミュニケーションをとっている印象です。これは個人の能力を超え、“会社全体の能力を底上げする力”だといえるでしょう。

kenkoooo この部分は一番記事にしてほしいです（笑）。

“先頭を走るプレッシャー”は、むしろ楽しみ

──スタッフエンジニア職では技術知識で先頭を走り続けるプレッシャーもあるのではないかと思います。皆さんはどのようにモチベーションを維持していますか。

Lin データ領域ではそこまで大きなプレッシャーは感じていませんが、“常に先頭を走っている”という実感はあります。estieが扱う不動産データは非常にユニークで、その分データの取り扱いでは他社が手をつけていない課題がたくさんあります。こうした課題に挑戦できることに楽しさを感じており、これはスタッフエンジニアというよりも、estieだからこそかもしれません。

tokuhara 私がestieに入社した背景には、組織の拡大に合わせてインフラを作り替えていきたいという思いがありました。ちょうど今、その思いを実現できるフェーズにあるので、非常に楽しく仕事に取り組めています。アプリケーションが稼働している中でインフラを改善する難しさはありますが、やり遂げた時に得られるメリットの大きさを分かっているので、プレッシャーというよりは、大きな価値を実感しながら業務に励んでいます。

kenkoooo 技術の先頭を走るプレッシャーはあまり感じませんが、「こうしたほうがいい」など、意見がぶつかる場面での自分の発言には神経を使います。僕の発言がきっかけで決まったことが、結果としてうまくいかなかったら困るので、考えた上で発言するようにしています。

一方、社内には自分よりも技術的に優れたエンジニアがもっといると考えており、そうした人材を発掘したいという思いは常にあります。「自分は優れた人材をまだ見つけられていないのではないか」という危惧は常に抱いており、その部分には気を配っています。

Xで、AIで、ソースコードでスキルアップ

──技術課題の解決を主導する存在として、皆さんはどのように技術知識をインプットしていますか。

Lin エンジニアとしては珍しいかもしれませんが、私は書籍を読むのが苦手なんです。その代わりに、自分で手を動かしてコードを書き、ライブラリのソースコードを読むことで知識を習得することに重きを置いています。スタッフエンジニアだからといって全ての技術に精通する必要はなく、例えばAI活用に関しては、1週間ほど先を行っているような他のメンバーから学んでいます。自分の専門外の領域では無理をせず、得意な人に頼ることも多いですね。

kenkoooo Linさんは、まだ知られていないSnowflakeの機能を徹底的に使い込んでいますよね。

Lin Snowflakeの社内関係者しか知らないような情報にも触れ、コードについて同社の社員の方と議論することもあります。

kenkoooo Snowflake本社から「この機能を使っているのは世界中でestieだけなので、ぜひ話を聞かせてほしい」と電話がかかってきたこともありましたね。

tokuhara dbtのPythonモデルでPythonプロファイラを使う方法について書かれたLinさんのブログは、米Snowflakeの開発者ブログで紹介されていました。

私は主にXやRSSフィードを活用して最新情報を収集しています。特に自身の担当領域では、古い情報がすぐに使えなくなるため、常に最新情報を取り入れるようにしています。データやAIといった分野は一人で全てを追うのは難しいので、私も社内の詳しいメンバーの力を借りていますね。

やはり手を動かさないと理解が深まらないことから、時間を見つけてはRustの動作検証などを行っています。インフラの知識は大体ありますが、その上のアプリケーションやデータの流れはコードレベルでは分からないこともあるので、実際に動かして動作を確認し、肌感覚として理解するようにしています。

kenkoooo 僕もtokuharaさんと同じく、手を動かして理解するタイプです。最近素晴らしいと感じるのは、AIが検証作業を代行し、結果だけを教えてくれることですね。これはかなり活用できています。

例えば、新製品のうたい文句として「これを使えば開発効率が劇的に上がります」とあっても、実際に動かしてみると「ここは使いやすいけど、この用途では全く使えない」といったことがよくあります。こうしたライブラリなどを試すことで、使い勝手を掴んでおきたいんです。

その際、AIに「こういう感じで調べておいて」と依頼し、AIが試行錯誤して得られた結果を見て学んでいます。かつては自分で試行錯誤していたことに対し、今ではAIと並行して行えるようになりました。結果として、以前よりも圧倒的に多くの情報を得ることができ、一生暇にならなさそうで楽しいです（笑）。

「全社的には頼られていないかも」で得た発信の機会

──お話を聞いて、組織横断の技術課題解決をけん引するスタッフエンジニアには全社的な視点やコミュニケーション力なども求められるのではないかと感じました。Linさんとtokuharaさんは、こうしたソフトスキルを身につけるために心掛けたことはありますか。

Lin 先日、月に1回開催される全社定例会議でスタッフエンジニアのプロモーションの機会を頂き、「こういうことは私たちに任せてください」と全社員の前で宣言しました。

kenkoooo スタッフエンジニアは技術的な課題の最終防衛ラインのような存在なので、「どんなことでも相談してほしい。最終的にはなんとかする」と話しましたね。

Lin HR部門との定例会議で「スタッフエンジニアになったけど、全社的にはそこまで頼られていないかもしれない」と相談したら、設定してもらえました。スタッフエンジニアの存在はエンジニアには周知されていましたが、会社全体ではそこまで知られていない感覚があったんです。

tokuhara 個人的には社内での大々的な発信はあまりできていないのですが、個々の社員が困っていることに関しては、Slackの分報チャンネルなどで情報を拾うようにしています。

Lin どのチャンネルで困りごとが上がっても、必ずtokuharaさんが反応してくれますよね。

tokuhara 例えば、Slackで「遅い」という投稿を見つけたら、すぐに「何が遅いですか？」と聞いたり、そのメンバーがオフィスにいたら話しかけたりすることで、話しやすい雰囲気を作ることを心掛けています。

“いきなりスタッフエンジニア”は難しい。想定されるキャリアパス

──スタッフエンジニアという肩書は普及しつつありますが、別の企業にスタッフエンジニアとして転職することは考えられるのでしょうか。想定されるキャリアパスを教えてください。

Lin スタッフエンジニア職ではチームメンバーからの信頼や他部署からの認知も重要な要素なので、他社のスタッフエンジニアにすぐ就任するのは難しいですね。転職先で実績を積んで実質的にスタッフエンジニアとして認められるか、あるいは改めて肩書を得るのが現実的だと思います。

tokuhara “信頼があった上でのスタッフエンジニア”だといえます。いきなり転職して「スタッフエンジニアです」と言っても、活躍するのは難しく、既存のエンジニアも受け入れづらいでしょう。まずはテックリードやシニアエンジニアとして入社し、そこで信頼を獲得してから改めてスタッフエンジニアを目指すことが考えられます。

──一つの会社でスタッフエンジニアから別の肩書を得るというキャリアパスもあり得るのでしょうか。

Lin 技術面でのキャリアパスとして、estieでは上位に明確な役職がなかったので、スタッフエンジニアという肩書が誕生した経緯があります。将来的にさらに上のポジションが必要になれば、また新しい肩書が生まれるかもしれません。

kenkoooo 当社では現在、スタッフエンジニアは3人しかいませんが、例えば組織が大規模になり、スタッフエンジニアが10～15人に増えた場合、彼らの意見を集約する「プリンシパルエンジニア」のような役割が生まれる可能性はありますね。

今後注力するのは、潜在的な課題解決や未来の課題予測

──今後解決したい組織横断の技術課題があれば教えてください。

tokuhara 直近では、自分が担当している横断課題はほぼクリアできたと感じています。これからは、意識しないと見えてこないような潜在的な課題に焦点を当てるフェーズです。estieは着実に成長し、多くのお客さまにご利用いただいているので、今後は品質とセキュリティの領域に力を入れていきたいですね。最近ではプロダクト間のAPI連携が増えているので、その品質保証が課題です。estieのプロダクトは品質が高いのですが、重大な脆弱性の見落としを防ぐ体制づくりや開発フローの整備を進める必要があると考えています。

Lin データ領域においては、プロダクトが増えていく中、データを分散的／中央集権的に構築するのかといったデータの管理方法を考える必要があります。最適解は、会社の状況や事業フェーズによって大きく異なるので、現時点での解を模索したいです。

分散型は開発スピードが上がりますが、他のチームが利用する際にプロトコルが異なり、N対Nのコミュニケーションが発生してしまう弊害や、データ開発のノウハウがないチームが取り扱いが困難なデータ構造を作ってしまうリスクがあります。一方、完全に中央集権型にすると、データチームのリソースが不足してしまいます。良いバランスを探りたいです。

kenkoooo 僕個人としては、tokuharaさんやLinさん、そして社内の優秀なエンジニアたちがいるので、当面の会社の状態には安心感を持っています。最近は、3年後のestieがどうなっているかを想像し、その時にどんな課題が浮上しそうか、といった未来の課題予測に時間を使おうとしています。もちろん3年後のことは確実には分かりませんが、ある程度の仮説を立てて取り組んでもいいのかもしれないと思っています。