Principal と器用貧乏のあいだ
はじめに
Staff+ Engineerは高機能雑用と思いながら仕事をしてきたが、思った以上に多様なこともあり、書評という形では書いてきたけど、なかなかまとまって考えを整理することはできていなかった。
そして、自分の与えたインパクトをレジュメに上手く表現できないことにもしばらく悩んでいた。これは、思ったよりも間に落ちたボールを拾うことが求められており、それをやって価値を出すことが思った以上に重要なんだけど、レジュメではキラキラした成果を求められるからである。
（キラキラした成果＝Promowareとかね）
自分の立ち位置はずっと、「顧客に価値のある製品を届けるために何でもやる」である。その何でもの幅は人によって違うのだと思う。なので、取っ掛かりとしてスタッフエンジニアでおなじみのWill LarsonのStaff Archetypesと比べることで紐解いていこう。
4つのStaff Archetypes
Will Larsonの4つのStaff Archetypeをおさらいとしてまとめてみる（Gemini 3 Thinking modeでブログ記事から要約）。
1. Tech Lead
特定のチーム（あるいは数つのチーム）に深く関わり、技術的な方向性と実行をリードする役割。
特徴: チームの技術的な意思決定に責任を持ち、複雑なタスクの具体化やブロックの解消を行う。
主な活動: 実装よりも、チーム全体の技術的なビジョン策定やメンバーの育成、プロダクトマネージャーとの調整に比重を置く。最も一般的で、シニアエンジニアからの延長線上でなりやすい形態である。
2. Architect
特定の技術ドメイン（API設計、フロントエンド、インフラ戦略など）において、組織横断的な成功と品質に責任を持つ役割。
特徴: 複数のチームにまたがる技術戦略を立案し、長期的な技術的整合性を保つ。
主な活動: ビジネスニーズと技術制約を深く理解し、組織全体のアーキテクチャを導く。大規模な組織や、負債が蓄積した複雑なシステムを持つ企業で必要とされる。
3. Solver
組織にとって重要かつ困難な技術課題を解決するために、特定のチームに留まらず動く「火消し」のような役割。
特徴: 実行リスクが高い問題や、解決策が見えない複雑な課題に投入される。
主な活動: リーダーシップ層からの要請に基づき、問題が発生している現場へ赴き、解決次第次の課題へと移る。組織レベルの調整よりも、純粋な技術的突破力が求められる。
4. Right Hand
CTOやVPといった経営幹部の「右腕」として、その権限を借りて組織の複雑な問題を解決する役割。
特徴: 技術だけでなく、ビジネス、人、プロセスが交差する領域で、経営陣の意図を組織に浸透させる。
主な活動: 幹部の会議に出席し、組織的なボトルネックの解消や戦略の実行を支援する。エンジニアが数百人規模になるような巨大組織で見られる稀な形態である。
とはいえ、Will Larsonはこうも言っている（Staff archetypesより引用。naniで翻訳）。
この分類は網羅性よりも実用性を重視していますが、これまでのところ、話を聞いたスタッフプラスエンジニアは全員、このいずれかのカテゴリに当てはめることができました。もちろん、分類しやすい人もいれば、そうでない人もいますが。
どうにも自分は「そうでもない人」なのではないかと思ってこの記事を書き始めた。
自分の仕事をArchetypeで分解する
自分が今の職場でPrincipal Software Engineer、あるいはTech Leadとしてどのような立ち位置にいたかを簡単に説明しよう。
Tech Leadという正式なタイトルはなく、会社のMLプロダクト開発をエンジニアリング的に全部を引っ張っていくエンジニアの総責任者的な立場として動いていた。組織構造としては、1年ほど前にCTO兼VPoEによって整理がなされ、複数のエンジニアリングチームを統括するSr Engineering Director直下のレポートラインとして、Principalである自分とMLチームのEngineering Managerがピアとして存在する形になった。いわゆるTwo-in-a-boxなどと呼ばれるスタイルである。
ここ3年くらいでやってきた主なことをArchetypeで分解してみよう。
【Tech Lead / Architectとして】
ML学習・予測基盤（Python, FastAPI, AWS Batch）のグランドデザイン設計からPoC、スケール検証、リリースまで一貫して主導し、2人で5ヶ月でリリースした
RFMの予測処理をスケーラブルにして最大100倍高速化し10億ユーザーの処理をサポートした
推薦のMLソリューションのモデルのPoC実装をし、スケーラブルなアルゴリズム選定を行った
【Right Handとして】
CTOやプロダクトリーダーシップに直接エンジニアリングロードマップを説明し、スポンサーを獲得しにいった
- 1年かけてML基盤刷新のスポンサーシップを獲得し、リリースまでこぎつけた
プロダクトロードマップのドラフトも作成し、EngだけでなくProduct ManagerやVPoPへのプロダクトの方向性を提案した
【Solverとして】
PSチームから「お客さんにこの機能が今すぐ必要」とエスカレーションが来た際、遊撃隊として飛び込み、1〜2週間で本番リリースして火消しを行った
実装していたメンバーが急遽いなくなったプロジェクトの未完のコードを、プロダクショングレードになるように書き直した
書いてて気づいたのだが、これ以外にも以下のようなことに気をつけていた。
メンバーのモチベーションを考慮したタスクアサインとキャリアを見据えたプロジェクト計画（例：adminコンソール作りなど退屈な作業は自分が巻き取り、チャレンジングなタスクをメンバーに渡す）
UXデザイナーにデータモデルの複雑さを伝えるためのドラフトUIデザイン案の作成
JDの抜本的な書き直しと面接のgatekeeper
EMへの1:1での間接的な評価インプット
ようするに、やっていたことは高機能雑用 （英語圏だとGlue）なんだけど、注力するところとしてはプロジェクトが失敗しないように＆成功するように必要な隙間に落ちたボールは重要度に応じて全力で拾いに行っていた。それにより、自分の職責ってなんだっけな、などと迷うことも多かったが、世のStaff Engineer本を読んでいると多かれ少なかれ皆やっていることだと思い、歯を食いしばってアンブロックしていた。
なぜStaff+のスコープは広がるのか
一般的には、Two-in-a-boxの形態は役割分担の幅はあれどよく知られている。例えば、Engineering Management: The Pendulum Or The Ladder で Charity MajorsはEMとTLの共同について記している（naniで翻訳）。
技術系エンジニアのリーダーは、需要が供給をはるかに上回るほど圧倒的に不足しています。最も一般的な解決策は、かつてエンジニアだったものの実務からは長く離れており、今はピープルマネージャーとして概念や専門用語を理解している人材と、現役のテックリードを組ませて、協同でチームを率いさせることです。この少しばかり扱いにくいやり方ですが、多くの場合、かなりうまくいっています。
また、Asanaでは全チームにEMがいて、多くのプロジェクトではTLを別途置きEMと協業する、あるいはTLがいない場合はTech Lead Managerとして両方を兼務する。
彼らの場合は、EMとTLの役割分担は以下の通りである（naniで翻訳）
エンジニアリングマネージャーは、主にピープルマネジメント（人員配置、コーチング、成長支援）と組織戦略（組織のリスク、業務効率、チーム憲章、成果）に注力します。
テクニカルリードは、主にテクニカルリーダーシップ（技術的な実行、技術戦略、技術文化、ロードマップの実現可能性と実行）に注力します。
このようにして、様々な領域に注意を払えるように認知負荷を分担していくのがTwo-in-a-boxのメリットである。
だが、MLのような技術的に深い知識を求められるドメインでは、EMとTLの技術的な深さにギャップがある場合、どうしても精度の高い技術的意思決定ができなくなりがちである。その結果、「分担」から広い範囲でTLへの「委譲」になっていき、TL側のスコープは広がってしまう。例えば僕の場合は、タスクアサインやリソース配分までTLとして決定しており、AsanaのEMの役割のいくらかを委譲されていた。
自分の場合は、Two-in-a-boxの体制は思った以上にうまく行ったと感じており、特にお互いの棲み分けがきっちりでき領分が決まってしまった後は、互いに自走するだけであった。基本路線としてPeople ManagementはEM、Technical LeadershipはTLといったように分担すること、共通のSr Engineering Directorにピアとしてレポートすることで、TL側のスコープの広がり自体は組織的には受け入れられる体制になっていた。この体制になる前は、結構お互いの仕事を奪い合うような形の衝突がちょこちょこ起きていたため、組織構造をうまく作るというのは大事なのだと実感した。
結局のところ、EMとTLがお互い信頼しあい、自律的に仕事を進められる体制になっていれば、多少ボーダーがどちらに寄っているかは些細な問題である。
自分のキャリアとしての振り返り、あるいは高機能雑用の再定義
ここまで色々と文章を書いてきたが、自分のやってきた仕事や広げてきたスコープを改めてArchetypeを元に整理すると
Tech Lead/Architectとしての技術的意思決定とデリバリー
Right Handとしてのエグゼクティブへの技術戦略の提案と承認獲得
Solverとしてのクリティカルな問題解決力
- ときにはStaff+以上の範囲（PdM, PjM, UXデザイナー, EMの一部）でもやるときはやる
となる。
Staff+としての高機能雑用業は、ただの雑用ではなく、「組織に必要な複数のStaff+機能を一人で担っている」と言えるのである。
Will Larsonもちょっとびっくりするかもしれない。
でもまあ、こういう動きができる人はスタートアップ色が色濃い企業では重宝されるとは思う。
同じ悩みを持つ人へ
Staff+として働いているときに高機能雑用として何がコアなのかを見失いそうになった場合、まずはArchetypeを振り返ってみて自分が何を成しているのかを言語化してみるのをおすすめする。
AI時代には言語化をすることで深堀りができるようになるため、AIと壁打ちしてでも言語化してみるとよいだろう。自分自身もshiumachiさんにAIと対話して内省すると、より自分への理解が深まり伸ばす方向が見つかる、という旨のことを教えてもらいやってみているが、（半端な仕事より）集中が求められるため疲れはするが得るものも大きい。
後は、自分自身が正気を保つためには、スタッフエンジニアに関する書籍の事例がとても心の支えになった。Will Larsonの本もTanya Reillyの本もどちらも手元においておくとよいだろう。自分がつらい経験をした後に読むと、スルメのように味わい深い読書体験ができる。
高機能雑用は、Staff+として活躍していることの表れなのかもしれない。ただし、やるべきことのビジネスインパクトは考えて優先順位付けをすることは忘れないでほしい。
