スタッフエンジニアのおしごと！

こんにちは！スタッフエンジニアの @kenkoooo です！僕が estie でやっているスタッフエンジニアというのがかなり面白いので、紹介させていただきます！

ミッション

estie のスタッフエンジニアは、全社横断の技術課題の解決をミッションとして負っています。

estie は、複数のプロダクトを同時並行で開発・提供し、顧客の複雑な課題を総合的に解決するコンパウンドスタートアップです。小さなチームが自律的に動くことで高速なリリースを可能にしています。

一方で、チーム間にまたがるような大きな課題や、まだ顕在化していない課題、1チームで解決しても小さなインパクトだが全チームで解決すると大きなインパクトになる課題は、各チームで取り組むよりも全社横断で取り組むのが良いでしょう。こうした課題にスタッフエンジニアが取り組みます。

初期には CTO が担っていた役割の一部を引き受けるというのが僕の理解です。組織が大きくなっていくときに CTO がボトルネックにならないように、CTO の役割の一部を VPoE や VPoT に移譲していくのはよくあることだと思います。estie でも組織面の課題は VPoE が、技術面の課題はスタッフエンジニアが引き受けています。VPoT にしなかったのは、組織の拡大に応じて増えていくと考えたので増えそうな感じにしたかったのと、ソフトウェアエンジニアのキャリアの延長線上にあることを強調したかったのがあります。

高速開発を支える技術

各チームが高速で開発できるよう、認証認可の基盤を統一したり、技術ガイドラインを策定したり、アプリケーションフレームワークを作ったりしています。各チームが、自分たちが本当に作りたい部分に注力できるよう、今後も “それ以外“ の部分をどんどん引き受けていきます。

ソフトウェアを開発する時、予め決められていたり、用意されていたりすると窮屈に感じる部分があります。一方で、そんなにこだわりがないので用意されているものがあればそれを使いたいという部分も少なからず存在します。後者の部分をできるだけ用意しておけば、開発者は自分がこだわりたい部分に集中できるようになり、より速く開発できるようになると考えています。

いわゆる Platform Engineering の領域になるかと思いますが、estie の事業に最も合った形を模索しながらやっていきます。

管理職にならないキャリアパス

estie のスタッフエンジニアは、ピープルマネージメントの責務を負っていません。全社の技術のマネージメントを行い、技術的な課題を解決したり、品質を高めたりすることは求められていますが、メンバーの人生に思いを馳せて、キャリアをいい感じにしたり、評価したりすることは求められていません。

僕個人としてはピープルマネージメントは全く向いていないので、IC (=Individual Contributor) として技術的な事柄に100%集中できるのは非常に良いです。スタッフエンジニアは、人間と会話しなくていいというわけではなく、むしろ全社的に広く会話することを求められるポジションですが、最終的な出力先が人間ではなく技術なので、必要なコミュニケーションも興味を持って楽しんでやれています。

キャリアを進めていくと管理職になるしかない会社もたくさんありますが、僕はマネージャーに求められるスキルを磨くことに興味が持てなかったので、こうした IC のポジションで全力投球できて良かったです。

面白いところ

今までの人生で全社のエンジニアの開発効率を上げるというところに思いを馳せたことが無かったのですが、やってみるとメチャクチャ面白いです。

「コーディングスピードを上げるために全社員に HHKB を配布しよう！」とかでも良いのですが、もう少し踏み込んで、各チームがどのようなプロダクトを作っているのか、そこにどのような技術的課題があるのか、そういった課題はどういう経緯で生まれたのか、というのを調べたり考えたりするのは、知的好奇心を非常に刺激されます。

組織が急成長しているので、問題も源泉かけ流し状態で湧き出しており、解き放題です。