「CTOの限界」を救う新しいポジション、スタッフエンジニアを組織に実装する方法【estie 岩成達哉】

増井雄一郎氏が監修し、2023年5月に発売された書籍『スタッフエンジニア　マネジメントを超えるリーダーシップ』は大きな注目を集めました。その中で取り上げられているのが、CTOやEngineering Managerのようなマネジメントキャリアパスと異なる役割を担う「スタッフエンジニア」という新しいポジションです。このスタッフエンジニアというポジションは、欧米のテック企業から始まり、日本でも徐々に知られるところとなっています。

拡大期を迎えた多くの企業で、1人のCTOが技術にもプロダクトにも、組織にも満遍なく目配りすることが難しくなる「CTOの限界」に直面しています。今回取材したestieは、この「CTOの限界」を乗り越えるために、2023年10月に「スタッフエンジニア」というポジションを設置したそう。

estieはなぜ、どうやってスタッフエンジニアを組織に実装したのか。業務内容が定義しきれない新しいポジションがゆえに「何でも屋」になってしまうことを防ぐために何をしたのか。就任から約3年を迎えたCTOの岩成達哉さんにお話を伺いました。

• keyboard_arrow_down 事業部CTO×スタッフエンジニアで、技術的な「死角」をなくす
• keyboard_arrow_down 新しいポジションを設けるなら、役割の定義づけから
• keyboard_arrow_down 全社横断での動き方を学ぶ「スタッフエンジニアとしてのオンボーディング」
• keyboard_arrow_down 「何でも屋」でもいいが、目的は見失わないこと
• keyboard_arrow_down マネジメントをしないIndividual Contributorというキャリア

——岩成さんはCTOとしての限界を、いつどのようなタイミングで感じましたか。

岩成：限界を感じたタイミングは、今までに2回あります。

1回目は、estieに2つ目の事業部ができたときです。

事業部が2つに増えてしばらくは、1つ目の事業である不動産データ分析基盤「estie pro（現・estie マーケット調査）」と、2つ目の新規事業の技術面を自分1人で見ていました。特性の異なる2つの事業を兼務しているうち、どうしてもどちらかが中途半端になっていきました。私1人で、2つの事業部の状況をタイムリーに追うことは難しく、1人ができることの限界を迎えてしまったのです。

そこで取ったのが、「事業部CTO制」です。

estieでは、プロダクトごとに事業部を分けてCTOやCPOを置き、意思決定の権限を移譲しています。こうした組織づくりをしているのは、複数のプロダクトをどんどん立ち上げ、共通した1つのデータ基盤をもとに連携させる「コンパウンドスタートアップ」という戦略を採用しているからです。もともとコンパウンドスタートアップを目指していたわけではなく、創業間もない頃から複数プロダクトを提供してきて、後から「この戦略で合っていたんだ」とわかってきて、2023年から本格的にプロダクトをどんどん立ち上げ連携するコンパウンドスタートアップへと舵を切りました。

複数のプロダクトを次々と立ち上げるために、最も重要なのはスピードです。そのため、全体で約80人、エンジニアは約30人程度ですが事業部CTO制を採用して、各事業部を担当するCTOがそれぞれ意思決定できるようにしています。

事業部が1つのときは、CTOとしての経営関連の仕事と現場の状況把握は両立できていました。しかし2つ目の事業部ができると、現状把握のコストは単純に倍になり、気合でぎりぎり両立できるかどうかという状況に。「ぎりぎり両立」では、現場の状況を深く把握しきれなくなり、自分が開発のボトルネックになってしまう。そうした状態に陥らないように、それぞれの事業をもっと伸ばしていくために、事業部CTOを設置したのです。

岩成：2回目は、まさにスタッフエンジニアを設けた2023年の10月頃です。

私は、CTOとしての大切な役割は、経営視点から会社の将来像を描き、それをもとに今やるべきことを決める「バックキャスティング（未来からの逆算）型のアプローチ」を推進することだと思っています。一方、開発を円滑に進めるためには、現場の状況から技術的な課題を吸い上げ、将来起こりそうな問題を予測して対応する「ボトムアップ型のアプローチ」も必要です。この両方の役割を、私一人で担うのは難しい。そのため後者の役割をスタッフエンジニアに任せようと考えたのです。

事業部CTOも、担当事業部の技術課題の吸い上げと解決をする役割を担いますが、全社横断的に存在する技術課題へのアプローチまでは要求していません。もちろん「やりたい」という気持ちは自由ですから、会社としてそういった気持ちにブレーキをかけることはしません。ただ、手を出しすぎてフォーカスを損ないスピードを落とすことがないように、役割への要求を決めているのです。

ならば、横断の技術課題を担うポジションとしてスタッフエンジニアを設置すれば、事業やプロダクトが生まれ続けるスピードはそのままに、全社横断の技術品質を改善し続けることができます。技術面での課題を、事業部単位でも全社横断でも死角なくキャッチして解決できる体制を築けるだろうと考えたのです。

——一般的には、組織横断の技術課題を解決したり、組織全体の技術品質を管理したりすることはCTOの役割だと思われていますが、そこを別のポジションの仕事として切り出せると考えたのですね。

岩成：私も長い間、これらはCTOの役割だと思っていました。しかし経営のことを考えながら、組織を横断した技術課題を詳細に把握して解決するというのは、現実的に私1人でできる量を超えています。

このままではいつか自分がボトルネックになり、会社の成長を阻害してしまうかもしれない。そう考えていたときにちょうど増井雄一郎さんの書籍『スタッフエンジニア　マネジメントを超えるリーダーシップ』を読んで、「技術品質の管理をスタッフエンジニアに任せる」という方法を知ったんです。私が1人で技術品質の向上やエンジニア組織全体のスケールを背負わなくても、スタッフエンジニアに権限や責任を移譲したら、私の果たすべき責務を果たせると思いました。

当たり前ですが、必要な役割というのは会社によって異なりますし、そもそもそのようなポジションは誰かがすでにやり始めているものだと思っています。実際にestieでも、スタッフエンジニアのような働き方を始めている人がいました。そのような人に「ここを任せた」と、必要に応じて新たにポジションをつくっていければ、組織を拡大し続けることができ、会社の成長にもつながるのだと考えています。

——スタッフエンジニアという、国内ではほとんど取り入れられていない新しいポジションを設置するにあたって、何からはじめましたか。

岩成：最初に、estieにおける「スタッフエンジニアの定義」を明確にすることから取り掛かりました。

スタッフエンジニアはまだ日本での前例が少ない新しい概念です。最初に何を任せたくて、何をすべき人なのかを明確にしておかないと、せっかくポジションをつくってもうまくワークしないと考えました。

経営の立場からスタッフエンジニアに期待していることを最も抽象的に言うと「estieの事業戦略に良い影響を与えてほしい」ということです。そこで、1人目のスタッフエンジニアをお任せするメンバーと一緒に、スタッフエンジニアの役割を事業戦略から分解していきました。

——先ほどのお話にもあった「コンパウンドスタートアップ」という事業戦略を踏まえて、estieでのスタッフエンジニアをどう定義されたのですか？

岩成：estieでは、「スタッフエンジニアとは、“産業の真価を、さらに拓く。”というパーパスに基づいて組織横断的に技術課題を解決したり、問題が発生しないように先手を打ったりする役割を担う」と定義しました。いまはまだ事業部が2つ、3つなので、技術負債も実害が出るほど蓄積してはいませんが、プロダクトが増えると後戻りができないくらい負債も大きくなるでしょう。

そこでスタッフエンジニアには「全社横断の技術課題を解決する役割」を一手に担ってもらおうと考えました。

——なるほど。「全社横断の技術課題を解決する」といっても、技術領域を問わず全部ひっくるめて1人に担ってもらうと、それこそ「スタッフエンジニアの限界」がくるのではないかと思ってしまいます。

岩成：もちろん、1人じゃ到底足りません。注力すべき技術領域ごとに1人ずつスタッフエンジニアを置く必要があると感じています。

望ましい形で価値を発揮し続ける開発組織をつくるには、まずは、「その会社に必要な役割」を予測する必要があります。estieではコンパウンドスタートアップ戦略に沿って開発を進めるうえで、全社横断の技術課題が発生しやすい領域を特定する必要があると考え、現段階では以下の4領域に特に注力すべきだと決めました。

①コアとなるデータのモデリング
②APIやミドルウェアのアーキテクチャ設計
③複数プロダクトを立ち上げるインフラ基盤の構築（Platform Engineering）
④プロダクトをどんどんつくる開発力（テックリード）

例えば、この4領域ごとに1人ずつスタッフエンジニアがいれば、組織横断で発生しがちな技術課題の大半を、取り返しがつかなくなる前に拾って解決したり、今よりもっと改善したりできるでしょう。

これからもっと事業部が増えたら、複数プロダクト間のデータ連携やAPI連携、他社プロダクトとの連携も必要になるはずです。あるいは、estieのAPIを使って他社にプロダクトを開発してもらうこともあるかもしれません。そのとき、私と各事業部のCTO、そして4領域のスタッフエンジニアがうまく連携を取れたら、技術品質を保ちながら、凄まじいスピードで事業戦略を叶えられる開発組織になっていくはずです。

岩成：ちなみに、1人目のスタッフエンジニアをお任せしたkenkooooさんには、複数プロダクトを同時並行で立ち上げるコンパウンドスタートアップにとって欠かせない、②にあたるミドルウェアのアーキテクチャ設計を担当してもらいながら、全社的な課題に対処することをお願いしています。彼は入社前から「実践Rustプログラミング入門」の著者として知られていましたし、社内の人望も厚かった。それに、コードを書いてアイディアを実現していくのがとても速かったんです。

——2023年10月に、晴れてスタッフエンジニアが誕生しました。とはいえいきなり「組織横断での技術課題解決」に取り組むのは、ご本人にも社内にも戸惑いがあったのではないでしょうか。

岩成：そう思います。スタッフエンジニアという新しい概念を本人も理解し、社内に浸透させていくには、段階的なオンボーディングが必要だと考えました。

——段階的なオンボーディングとは、具体的にどのようなことを行ったのですか？

岩成：まず取り組んでもらったのは、プロダクトを横断した「技術ガイドライン」の策定です。

これまで、それぞれのプロダクトに最適な技術スタックを選んできたため、プロダクトごとに技術スタックが異なるケースがありました。新しい機能の開発を始める度に、それぞれのプロダクトチームが「どんなテックスタックを採用しようか」と議論していて、別のプロダクトで議論されていたことをまた議論しているといった「車輪の再発明」みたいなことが時々起きていました。

技術選定に関する知見が組織全体に蓄積できているのに、共有されていないのはもったいない。そこでkenkooooさんに、各現場に蓄積している知見を拾い上げ、全社共通の技術ガイドラインとして整備してもらいました。おかげで技術選定のスピードが上がっただけではなく、全事業部で一貫性を持った技術的意思決定ができるようになりました。

岩成：また、技術ガイドラインの策定と並行して、それぞれのプロダクトに臨時で入ってもらって、最前線で開発してもらいました。例えば、リソース不足の事業部に入って一気にコードを書いてもらったり、設計につまずいている事業部でテックリードのような役割を担ってもらったり。これはkenkooooさんの実装力が凄まじかったからこそ実現できたことでもあります。

こうした動き方は、各部門の困りごとを解決する目的もありますが、どの事業部でどのような開発をしているのか知ることで、全社共通の基盤には何が必要なのかを理解することが大切だからでもあります。

組織横断の基盤をつくる時に陥りやすい失敗が、開発側が「俺たちの考える最強のプラットフォーム」をつくってしまい、社内の誰にも使われないこと。それを避けるためには、各事業部の開発を2～3回経験し、プロダクトをつくるときのパターンをつかんでおくことが有効だと考えました。

——共通基盤をつくる人だからこそ、複数のプロダクト開発に関わり、内部構造を深く知っておく必要があるんですね。

岩成：そう思います。2023年はその次の段階として、組織横断の共通基盤である「誰もがスムーズに新しいプロダクトの開発を始められる基盤の開発」を進めてもらっていました。

新規プロダクトをつくりはじめるとき、いくつかの項目を入力するだけで即座にインフラ構築もできステージング環境にデプロイされるというものです。「5分でリリースを完了させる」というコンセプトから、カップうどんにちなんで「Donbei（どんべい）」と名づけられました。

——お聞きしてきた現状のスタッフエンジニアの動き方は、一見「全社に関わる困りごとなら、何でも頼んでいい人」だと捉えられてしまうような気もします。前例のないポジションを「何でも屋」にしないために重要なことは何でしょうか？

岩成：「何でも屋」になること自体は、それほど悪いことではないと思います。estieでは「ジブンドリブン」というバリューを掲げていて、チームやプロダクトのためになるなら、役割や管掌領域から染み出していくことを推奨しています。それに、任された業務を責任持って遂行しようとした結果、いつの間にか業務範囲が広がってしまうことはよくありますから。

ただ「何でも屋」になった結果、本当にやるべきことができなくなってしまうのは問題です。

そのような事態を避けるためには、スタッフエンジニアという役割を置いたそもそもの目的を明確にしておくことが大切です。タスクが増え続けて首が回らなくなってしまっても、「目的達成に必要なこと」を基準として取捨選択すれば優先順位を整理できます。

——こうした新しいポジションの役割や、何を頼める人なのかを誤解なく他のメンバーに伝えるために、どんなことをしましたか？

岩成：スタッフエンジニアの就任を発表する前に、ポジションの定義やコンピテンシーをまとめた「スタッフエンジニアとは」という社内wikiをつくっておき、就任する際に公開しました。それを全社に共有して読んでもらい、スタッフエンジニアというポジションについて理解を深めてもらいました。

すると、メンバー自ら増井さんの本の読書会を開いてくれたんです。その過程でスタッフエンジニアというキャリアパスに興味を持ってくれた人も出てきました。

また、私が彼の過去の実績とともに「彼はスタッフエンジニアとして信頼できる人である」と全社に紹介しました。CTOなどトップに近い人が「この人は信頼に足る人だ」と発信することは、新設ポジションに就いた人が活動しやすい環境を整える上で大切なことだと思います。

加えて、本人が自分の役割を正しく理解してくれて、コミュニケーション力が高い部分にも大いに助けられました。彼が今のような解像度でスタッフエンジニアの役割を理解し、社内に表現してくれれば、スタッフエンジニアという役割は適切に浸透していき、2人目・3人目のスタッフエンジニアがどんどん生まれていくのではないかと考えています。

——スタッフエンジニアを配置してから、CTOである岩成さん自身に変化はありましたか？

岩成：全社にまたがるような大きな技術課題でも、CTOがひとりで抱え込むのではなく誰かに任せることができるし、それが組織の成長につながることに気づくことができました。

以前は「全社で一定の技術品質を保つべきであり、それはCTOである私がやるべきことだ」と考えていました。だから2023年6月頃までは、私自身が1つの事業部に入っていってコードを書いていたんです。

そもそも、私はコードを書くのが好きで、自分がしっかりコミットしないとと考えていて。でも、これから続々と事業部が生まれていったときに、自分がコードを書いていたら、組織体制を整えたりスケールしたりする役割を担う人がいなくなるなと思うようになりました。

kenkooooさんにスタッフエンジニアになっていただき、全社の技術品質のマネジメントを任せたことで、私自身も「コードを書かなきゃ」という焦燥感を抑えることができた。そして、会社が成長する上で“ブロッカー”になりそうな「私という要因」を早い段階で一つ排除できたと思います。

また、スタッフエンジニアを設置したおかげで、メンバーに新しいキャリアの選択肢を示すこともできました。キャリアを重ねたエンジニアが、マネジメントではなく技術のスペシャリストとして、Individual Contributor（インディビジュアル・コントリビューター／IC。個人貢献者）という位置づけでキャリアパスを描くのは、国内ではまだまだ少ないように感じます。今回「スタッフエンジニア」というポジションを設けたことで、新しいキャリアの選択肢を提示できたのではないかと考えています。

私は、マネジメントを担う人と、ICの道を進む人は全く対等だと思っていて。次々とスタッフエンジニアが生まれる環境を用意することで、ICの道を歩みたい人が躊躇せず望むキャリアを選べるようになってほしい。スタッフエンジニアはCTOやVPoEと同じくらい重要なポジションなんだ、と示せるといいなと思っています。

ゆくゆくはスタッフエンジニアを経験した人が、新たなCTOや事業部CTOを担うことがあるかもしれません。「次に誰がCTOになっても大丈夫」と言える組織をつくっていくことで、estieが会社としてさらに強くなったら嬉しいですね。

取材：石川香苗子
執筆：一本麻衣
編集：光松瞳、王雨舟、石川香苗子
撮影：曽川拓哉