事業成長に人生をかけてくれるスタッフエンジニアをどう見出し、評価する？3人が活躍中のestieに聞いた

日本でも高度な技術課題に組織横断的にアプローチしようと「スタッフエンジニア」を置く企業が少しずつ増えています。商業用不動産のデータ基盤サービスなどを提供する株式会社estieでは2023年、1人目スタッフエンジニアにkenkooooさんが就任。翌年には、データ領域の山本亮介（Lin）さん、プラットフォーム領域の徳原晋一さんが加わり、3人体制へと拡大しました。

先例が少ないポジションを設置するとき、「その成果をどう測るか」という悩みはつきものです。estieの場合、専門性も得意分野も異なるスタッフエンジニア3人を評価するのは一筋縄ではいかないはず。世の中ではまだ、スタッフエンジニアの成果を適切に評価するモデルケースが十分とは言えないのも事実です。そんな中、取締役CTOの岩成さんは「スタッフエンジニアに特化した評価基準を設けていない」と語ります。特別な基準を設けず、どのように公平性と納得感のある評価を行っているのでしょうか。

岩成さんとkenkooooさんに取材し、そのユニークな評価の仕組みと、そもそも3人にスタッフエンジニアを任せた「決め手」について、お話を聞きました。

• keyboard_arrow_down 3人の「手を動かせるCTO」が複数プロダクトの成長を支える
• keyboard_arrow_down 評価を決めるのは「能力」ではなく「振る舞い」
• keyboard_arrow_down 技術力だけでない。スタッフエンジニアに求める3要素
• keyboard_arrow_down 1領域に1人ずつ増員。スタッフエンジニアは「最後の砦」

――1人目スタッフエンジニアkenkooooさんの就任からわずか1年で3人体制になりました。この背景を教えてください。

岩成：1人目スタッフエンジニアの就任は2023年10月にさかのぼります。当時、estieでは4つのプロダクトの開発が進んでいました。複数のプロダクトを連携させながら事業を伸ばす「コンパウンドスタートアップ」に舵を切った時期で、各プロダクトで迅速な意思決定ができる体制の整備が必要となりました。そこで、プロダクトを事業部に分けた上で、事業部横断の技術的な課題の解決を僕の代わりに担ってくれる「手を動かせるCTO」のようなポジションとして、kenkooooさんをスタッフエンジニアに任命しました。

翌年には、継続して複数の新規事業を立ち上げ、成長させていく上で、「新たなスタッフエンジニアが必要」と考えたデータ領域、プラットフォーム領域に、それぞれLinさんと徳原さんをアサインしました。私たちのビジネスのコアである「データ」のモデリングと、複数プロダクトの基盤となる「プラットフォーム」の開発をそれぞれリードする存在として、2人に事業を伸ばしてほしいと考えました。こうして固まったのが今の3人体制です。

――3人体制になったことでどんな変化がありましたか。

岩成：まずは、データとプラットフォームに特化した高度かつ中長期的な技術課題に着手できるようになりました。

たとえば、Linさんは、データ管理のアーキテクチャを考案し、実装してくれました。新たに導入された「サーキットブレーカー」は、重要なデータで異常を検知した際に自動でプロダクトへのデータ移送を停止する仕組みです。これにより、データが原因で発生する障害の減少につながりました。一方、プラットフォーム領域の徳原さんは、1つしかなかったAWSのアカウントを、本番・ステージング・開発用など、目的別で分割してくれました。これにより権限管理がしやすくなったほか、機密情報が漏洩するリスクも低減できました。失敗が許されない大規模な作業を緻密かつスピーディに進められたのは、徳原さんの実力あってこそです。

さらに、社員数が急増する中で発生しつつあった「トラブルが生じたときに誰に助けを求めればよいか分からなくなる」という問題も解消されました。たとえば徳原さんが「今日からプラットフォーム領域のスタッフエンジニアを務めます」と宣言することで、関連領域におけるインシデント対応においてチームが問題の原因を特定できないときでも、迷わず徳原さんのもとに相談に行けるわけです。

これは、各スタッフエンジニアのパフォーマンスの向上にもつながりました。

——どういうことでしょうか？

岩成：彼らは、常に1〜2年先を見据えた技術戦略の立案が求められています。

相談窓口の明確化により、スタッフエンジニアたちは、事業や技術に関する情報の「ハブ」となっていきました。つまり、様々な問題を抱えた現場のメンバーから、担当領域におけるあらゆる知見が自然と集約されるようになった。すると結果的に、現場の声や事業状況の変化を踏まえた戦略を立てる力が磨かれていったのです。こうして個々のスタッフエンジニアの意思決定の質が上がることは、組織全体の技術レベルと事業成長の底上げにもつながるはずです。

kenkoooo：僕自身は、1つの課題と向き合う時間的・精神的な余裕が生まれました。

組織横断の課題に取り組む際は、関係者全員の主張やその背景を理解することから始めます。1人で全社を見るとなると、どうしても経営メンバー、開発チームの関係者一人一人とじっくり話したり、Slackの会話ログを追ったりすることに追われてしまい、具体的な設計や実装に移るまで時間がかかってしまいます。また、「スタッフエンジニアに求められている仕事は何か」と、自問自答しながら、多くの技術的な意思決定を1人で担うプレッシャーも大きかったです。

その点、データとプラットフォームの領域を2人に任せられるようになったことで、「この領域は一旦意識しなくても大丈夫」と考え、自分のより得意な領域に集中できるのは大きいですね。

――業務においてスタッフエンジニアの3人が連携することはありますか？

kenkoooo：基本的には独立して担当領域の課題解決に動いています。ただ、各自で進める中長期的なプロジェクトの進行状況について、定期的に情報共有しています。週次の定例やオフィスで顔を合わせたときに話すことが多いですね。

情報共有の目的は2つあって、1つ目は組織全体に関わる技術的な意思決定をする際に、3人の認識を揃えておくことです。2つ目は、技術課題は1つの領域に収まらないものが多いので、1人が試行錯誤している課題でも、他の誰かが別の角度から手を打てばすぐに解決できる、という可能性に早めに気づいてリソースの無駄遣いを防ぐことです。

※編注：kenkooooさんが1人目スタッフエンジニアに就任した経緯については過去のインタビュー記事からご覧いただけます。

――3人の評価はどのように行っていますか？

岩成：estieはスタッフエンジニアのための特別な評価基準を設けていません。スタッフエンジニアやテックリード、EMといった「役割」とは完全に分離させる形で、ジョブディスクリプションを用意しているんです。全職種において、評価は、組織で担う役割に影響されず、ジョブディスクリプションに基づいて行います。

岩成：ジョブディスクリプションは5つのレベルに分かれており、それぞれのレベルで期待される「振る舞い」で定義しています。

――「振る舞い」…ですか？

岩成：私たちの言う「振る舞い」とは、「実際の成果につながっていて、かつ客観的なエビデンスで示せる具体的な行動」を指します。

たとえばソフトウェアエンジニアの振る舞いの評価軸は3つあります。1つ目はエンジニアリング、つまりエンジニアとして最も重要な軸足である技術力を持って解法を導いたかという観点。2つ目はデリバリー、これは売上向上などビジネスへの貢献を考えて価値を届けたかという観点。3つ目はグロース、自分や組織、会社を成長させたかといった観点です。

岩成：基本的には3つの軸で迷いなく評価できるのですが、スタッフエンジニアだと事情が異なります。正直、評価者である僕も悩むことが多いです。

――どんな点で悩むのでしょうか？

岩成：スタッフエンジニアは組織でトップクラスの技術力を持ち、常にそれを発揮してあらゆる難易度の課題を解決していることが前提です。課題解決のための「行動」が常に評価者の期待を大きく超えてくるため、正直、私たちの設けた基準では評価できなくなってきます。

そこで、スタッフエンジニアの評価においては、特に行動により生み出される「成果」を重視しています。たとえば、「データ管理のアーキテクチャを実装し、年間でデータ起因のインシデント発生数をN件減少させた」「エラーの原因調査におけるAIの導入を主導し、開発組織全体の工数をN%削減した」など、事業や組織に与えた影響の大きさを見て、評価を決めています。

――では、kenkooooさんにお聞きします。スタッフエンジニア目線で、その「事業や組織に与えた影響」で評価されるために、どんな行動が重要だと考えていますか？

kenkoooo：技術的な最適解を把握したうえで、事業や組織にとって最善は何かを判断し、意思決定することです。

たとえば、データ領域を担うLinさんのケースで説明します。estieではオフィス、物流施設、住居と、特性の異なる不動産データを扱うため、それらを整形・統合し、複数プロダクトで活用できるデータパイプラインが不可欠です。

Linさん自身は、データエンジニアリングの高度な知識を活かした複雑なデータパイプラインを1人で構築することができます。ただ、estieが扱うデータは、デベロッパーや管理会社といったソースごとに形式が異なり、仕様も不安定です。この状況で最初から大規模なパイプラインを構築し、データソースに合わせて都度改修するのは、大きなコストになります。

ここでスタッフエンジニアに求められる振る舞いは、「技術的に可能だから」という理由だけで大規模なパイプラインを構築することではありません。開発コストと事業の要求を天秤にかけ、「事業インパクトを最大化する手段は何か」を判断することです。

極端に言うと、データ仕様を安定化させる前の段階では、アルバイトを1000人雇って全員でデータを整形し、管理画面に入力していったほうが効率的な場合だってあるかもしれませんね。Linさんなら、このように「まずはアルバイトに手打ちしてもらいながら、サービスごとに段階的にパイプラインを構築していく」というような柔軟な判断ができると考えています。

――そもそも、Linさんと徳原さんのどのような点に、スタッフエンジニアとしての適性を見出したのですか？

岩成：適性を判断するにあたって着目したポイントは主に3つあります。1つ目は、estieがこれから注力する領域に専門性を有しているか。その点において2人は、入社時からデータ領域とプラットフォーム領域で卓越した専門性を示していました。

2つ目は、実績に裏打ちされた周囲からの信頼があるか。徳原さんもLinさんも、アサインの話が出る前から、いわゆる「スタッフプロジェクト（※）」と呼ばれるような難易度の高い仕事をこなし、成果を出していました。その成果の積み重ねにより、ある日「この領域の技術的な意思決定は私が担います」と宣言したとしても、周りが安心して頼れるような存在となっていました。

この2つの条件を満たした状態で、最後はestieの事業を伸ばそうという「信念」を持っているか。この部分は特に丁寧に見ました。

岩成：estieが挑戦しているのは、商業用不動産データベースの構築という、まさに前人未到のビジネス。

この未知の領域で初めて直面する課題と向き合い、技術的な舵取りを担うのがスタッフエンジニアです。彼らに求められるのは、自ら課題を見つけ出し、組織や事業にとっての最善を考え抜く姿勢。課題解決には、学びを繰り返しながら突き進む強い「信念」が欠かせません。2人からは、その「信念」が確認できたので、データとプラットフォームの領域で「まだ誰も見たことのない未来」へ導いてくれると確信し、技術的な意思決定を任せることができました。

――事業を伸ばせる「信念」を見極めることはかなり難しいと思います。estieではどうやって判断しているのですか？

岩成：おっしゃる通り、スタッフエンジニアの候補者だからといって、いきなり「人生をかけて事業を伸ばしてくれますか？」と聞いて明確な答えをもらうのは難しい。そこでまず、人生をかけて成し遂げたい目標を聞きます。その上で、「目標がestieの事業成長につながり得る内容かどうか」を見定める。2つがつながる道筋が見えてくれば、自然と事業を伸ばすために努力してくれる人だと期待できるからです。

ただ現実問題、私たちが「マイパーパス」と呼ぶ、個人が漠然と有している人生の目標が、そのままestieの事業成長に直結するとは限らないので、その点については、本人との対話を通してすり合わせを図ります。

採用選考の時点で各メンバーのマイパーパスは聞いています。目標とその実現のためにその人が取り組みたいことを深掘りし、 その上で、「その目標は、estieで実現できるか？そうだとしたら、どのような形で実現できそうか？」を自分の言葉で語ってもらう。最初はなかなか答えられないかもしれないですが、仕事をしていく上でだんだんと「これをやりたい」というのが見えてくる。そうして、具体的な業務内容に落とし込める段階にまできたら、ようやく「この人は信念を持って事業を伸ばしてくれるに違いない」と判断しています。

――実際に2人の「マイパーパス」とestieの理想はどうつながったのですか？

岩成：Linさんが語ってくれたマイパーパスは「誰も取り組まなかった課題に取り組んで広く価値が届くようにする」というものでした。estieのビジネスのコアはデータであり、データ基盤を創る道のりには常に新しい課題が溢れています。その二つがつながり、継続して全社のデータエンジニアリングにおいて最先端の技術テーマを発見し、その解決を推進するリーダーシップを期待したいと考えました。

一方、徳原さんには「目の前の人の役に立ちたい」が根底にあり、「組織の拡大に合わせてインフラをつくり替えていきたい」という具体的な思いを持ってestieに入ってくれたため、estieの事業を伸ばしてくれる信念があるとすぐに判断できました。また、アプリケーションの稼働を止めずに既存のインフラ基盤を改善していくという難しさもありましたが、徳原さんは、「むしろ、その難しさを楽しみながら業務に取り組みたい」と実力を示しながら話してくれたので、スタッフエンジニアにふさわしいと確信しました。

※スタッフプロジェクト…完了することでスタッフエンジニア就任にふさわしい実力があると認められるプロジェクト。

――今後、スタッフエンジニアを増やしたい領域はありますか？

kenkoooo：今後はAI領域や、より顧客に近いプロダクト領域でスタッフエンジニアを配置できたらいいなと思います。特にプロダクトは顧客との重要な接点になりますからね。すでにこれらの領域でリーダーシップを発揮しているメンバーが何人かいるので、彼らに正式に役割を任せられるようになると、僕自身もだいぶ安心できます。

スタッフエンジニアを増やす場合、既存の領域を細分化して任せるのではなく、会社の成長に伴って事業領域が広がり、そこに新たなスタッフエンジニアが生まれるイメージです。

岩成：そうですね、原則として1つの領域に複数人は置かないつもりです。オーナーシップを醸成するためには、「後ろを振り返っても誰もいない状態」をつくることが重要です。「この領域はあなたが最後の砦です」と任せられたら、自分が考えるしかないですから。

事業の成長につながる領域を見極め、そこに信念を持った人を見つける。柔軟な制度設計にしているからこそ、そういう自然な流れで今後もスタッフエンジニアを増やしていけると考えていますし、その投資領域を発見することがCTOである自分の仕事でもあると思います。

取材：光松 瞳
執筆：古屋 江美子
編集：王 雨舟、田村 今人、池田 恵実
撮影：赤松 洋太