はじめに

シニアエンジニアになった後のキャリアパスは、大きく2つに分かれます。エンジニアリングマネージャー（EM）へ転身するか、Individual Contributor（IC）トラックで**Staff Engineer**以上に成長するかです。韓国ではStaff Engineerという肩書きがまだ馴染みのない組織が多いですが、グローバルテック企業ではすでに確立されたキャリアラダーの重要なステージです。

Staff Engineerはシニアエンジニアと何が違うのでしょうか？一言でまとめると、**影響力の範囲**が異なります。シニアエンジニアがチーム内で卓越したコードを書くのに対し、Staff Engineerは**チームを超えて組織全体の技術方向に影響を与えます**。優れたコードを書くことは依然として重要ですが、それだけでは十分ではありません。

この記事では、Will Larsonの「Staff Engineer」とTanya Reillyの「The Staff Engineer's Path」を基に、Staff Engineerの4つのアーキタイプ、RFC/ADRによる技術意思決定、影響力拡大戦略、メンタリングとスポンサーシップ、技術的負債の戦略的管理、そしてエンジニアリング文化の構築までを実践的に取り上げます。

Staff Engineerの4つのアーキタイプ

Will LarsonはStaff Engineerの役割を4つのアーキタイプに分類しました。ほとんどのStaff Engineerは1つのアーキタイプに近いですが、状況に応じて複数の役割を行き来することもあります。

1. Tech Lead

1つのチームまたは小規模チームクラスターの技術方向を導きます。

- チームの技術意思決定を主導し、コード品質を維持

- プロジェクト計画と実行の技術的側面を管理

- エンジニアリングマネージャーと緊密に連携し、技術と人の両面を橋渡し

- **最も一般的なアーキタイプ**で、Staff Engineerの約50%がこのタイプ

2. Architect

複数のチームにまたがる技術方向と品質に責任を持ちます。

- 組織全体の技術ビジョンと戦略を策定

- システム間インターフェースと統合パターンを定義

- 技術標準とベストプラクティスを確立

- 大規模組織（数百〜数千名）で主に存在

3. Solver

特に困難または緊急な問題を解決する専門家です。

- 組織内で最も困難な技術課題に投入

- プロジェクト完了後、別の問題に移動

- 深い技術的専門性と素早い学習能力が必要

- 高度に専門化された領域（セキュリティ、パフォーマンス、インフラ）で価値を発揮

4. Right Hand

VP/CTOなどシニアリーダーの技術パートナーの役割を担います。

- リーダーの技術的判断を補完し、意思決定の実行を支援

- 組織全体の技術イニシアチブを調整

- 高い組織政治への理解力とコミュニケーション能力が必要

- 最も稀なアーキタイプ

どのアーキタイプが合っているか

自己診断の質問

============================================

1. 私は1つのチームで深く仕事をするのが好きだ

-> Yes: Tech Lead傾向

2. 私は複数チームの技術的一貫性を保つことに関心がある

-> Yes: Architect傾向

3. 私は「不可能に見える」技術的問題を解くことに興奮する

-> Yes: Solver傾向

4. 私は組織全体の方向を理解し、影響を与えたい

-> Yes: Right Hand傾向

注意：アーキタイプは固定ではありません。キャリアの段階や組織の状況によって変わり得ます。

技術意思決定：RFCとADR

なぜ文書化された意思決定が重要か

Staff Engineerの最も重要な役割の1つは、**技術意思決定を透明にすること**です。口頭でのみ伝えられる決定はコンテキストが失われ、後になって「なぜこうしたの？」という質問に答えられなくなります。

RFC（Request for Comments）

RFCは重要な技術変更を提案し、組織からのフィードバックを収集するプロセスです。

RFC：注文サービスへのイベントソーシング導入

メタデータ

- 作成者：キム・ヨンジュ

- 状態：レビュー中

- 作成日：2026-03-01

- レビュアー：パク・ソジュン、イ・ミンハ、チョン・ダユン

- 決定期限：2026-03-14

要約

注文サービスの状態管理を現在のCRUD方式からイベントソーシングに

移行し、注文履歴の追跡と監査ログの要件を満たす。

動機

1. 金融規制対応：注文状態変更履歴の5年間保管義務

2. カスタマーサポート：「なぜ注文がキャンセルされたのですか？」への正確な回答が必要

3. 分析：注文ファネル分析のための詳細なイベントデータが必要

提案する設計

（具体的な技術設計内容）

代替案分析

代替案1：CDC（Change Data Capture）+ 別途履歴テーブル

- 長所：既存コードの変更最小化

- 短所：履歴と現在の状態間の一貫性保証が困難

代替案2：監査ログライブラリの導入

- 長所：実装が単純

- 短所：イベント再生不可、部分的な履歴のみ保管

代替案3：イベントソーシング（選択）

- 長所：完全な履歴、イベント再生、タイムトラベルクエリが可能

- 短所：学習曲線、読み取りモデルの別途構築が必要

実装計画

- Phase 1（2週間）：イベントストアインフラ構築

- Phase 2（3週間）：注文作成/修正のイベントソーシング移行

- Phase 3（2週間）：読み取りモデル（CQRS）構築

- Phase 4（1週間）：既存データの移行

リスク

1. チームの学習曲線（緩和：イベントソーシングワークショップ2回実施）

2. 読み取りパフォーマンス低下の可能性（緩和：CQRSで読み取りモデルを分離）

3. 運用の複雑さ増加（緩和：イベントストアモニタリングダッシュボード構築）

未決定事項

- イベントストア：EventStoreDB vs PostgreSQL + Outboxパターン

- イベントスキーマ進化戦略（upcasting vs versioning）

ADR（Architecture Decision Record）

ADRはRFCよりも軽量な形式で、個別の技術意思決定のコンテキストと結果を記録します。

ADR-042：API認証方式としてJWTを選択

状態

承認済み（2026-03-10）

コンテキスト

マイクロサービス間のAPI認証方式を統一する必要がある。

現在、サービスごとにAPI Key、Session、JWTなどを混用しており、

セキュリティ監査とデバッグが困難な状況。

決定

サービス間通信にJWT（JSON Web Token）を標準認証方式として採用する。

- トークン発行：Authサービス（Keycloakベース）

- トークン検証：各サービスで公開鍵ベースのローカル検証

- トークン有効期限：Access Token 15分、Refresh Token 7日

結果

- 肯定的：統一された認証、サービス間呼び出し時のAuthサービスボトルネック解消

- 否定的：トークンの無効化が即時反映されない（有効期限まで待機）

- 中立的：各サービスにJWT検証ミドルウェアの追加が必要

代替案

- API Key：シンプルだが鍵管理が複雑、きめ細かな権限制御が困難

- mTLS：セキュリティは強力だが証明書管理のオーバーヘッドが大きい

- OAuth2 Opaque Token：Authサービスへの依存度が高い

RFC/ADR運用のベストプラクティス

1. **RFC/ADRをコードリポジトリで一緒に管理**：コードと意思決定を一緒にバージョン管理

2. **レビュー期限の設定**：無期限に開いたままのRFCは決定を遅延させる

3. **テンプレートの提供**：一貫した形式で記述の負担を軽減

4. **却下されたRFCも保管**：「なぜこの方法を選ばなかったか」も重要な知識

影響力の拡大：コードを超えて

文章の力

Staff Engineerにとって文章を書くことは選択ではなく必須です。コードは1つのチームに影響を与えますが、よく書かれた技術ドキュメントは組織全体に影響を与えます。

**効果的な技術文書の種類：**

- **技術ビジョン文書**：6〜12ヶ月後の技術スタックの目標状態を描く

- **ポストモーテム**：インシデントから組織が学べる教訓を抽出

- **オンボーディングガイド**：新しいエンジニアが素早く生産的になれるよう支援

- **技術ブログ**：外部コミュニティとの知識共有、採用ブランディング

コードレビューを通じた技術レベルアップ

Staff Engineerのコードレビューは単純な欠陥検出を超え、**教育的機能**を果たします。

一般的なシニアのコードレビュー：

「この関数名をgetUserからfetchUserByIdに変更してください。」

Staff Engineerのコードレビュー：

「この関数はDB問い合わせをするので、fetchプレフィックスの方が適切だと思います。

私たちのチームでは純粋な計算にはget/compute、I/Oがある場合はfetch/load

プレフィックスを使っていますが、このコンベンションをADRとして文書化しませんか？

関連例：payment-serviceのfetchOrderHistory」

ミーティングでの影響力

Staff Engineerは技術ミーティングで**意思決定を促進する役割**を担うべきです。

- **意思決定前**：選択肢とトレードオフを事前に整理して共有

- **ミーティング中**：議論が脱線した時、核心的な質問で本題に戻す

- **意思決定後**：決定事項とアクションアイテムを明確に文書化

メンタリングとスポンサーシップ

メンタリング vs スポンサーシップ

多くのシニアエンジニアは**メンタリング**はしますが、**スポンサーシップ**はしません。この2つは異なります。

- **メンタリング**：知識と経験を共有し、アドバイスすること（「こうすればいいですよ」）

- **スポンサーシップ**：機会を作り、可視性を高めること（「このプロジェクトのリードを任せてみましょう」）

スポンサーシップがより強力な理由は、**成長の機会そのものを提供**するからです。

効果的なメンタリングフレームワーク

1:1メンタリング構造（隔週、30分）

============================================

5分 - 近況チェック：「最近、最もチャレンジングなことは何ですか？」

10分 - 技術的深堀り：現在の作業での技術的な悩みを議論

10分 - キャリア成長：長期的な目標と現在の位置を確認

5分 - アクションアイテム：次回までにやることを整理

メンターがすべきこと：

- 答えを与えるのではなく、質問で思考を誘導

- 自身の失敗経験を率直に共有

- メンティーの成長に合わせて難易度を調整

メンターがしてはいけないこと：

- メンティーの仕事を代わりにやる

- 自分のキャリアパスを唯一の正解として提示

- メンティーの直属上司にメンタリング内容を共有（信頼の毀損）

技術的負債の戦略的管理

技術的負債をビジネス言語に翻訳する

「技術的負債を返済する必要があります」と言っても、ビジネスリーダーは動きません。Staff Engineerは技術的負債を**ビジネスインパクト**に翻訳できなければなりません。

悪い例：

「テストカバレッジが低いのでリファクタリングが必要です。」

良い例：

「現在の決済モジュールのテストカバレッジは30%です。

前四半期の決済関連の障害3件のうち2件がテストのない

コードパスで発生し、各障害のビジネス影響は

平均2時間のサービス停止と約500万ウォンの売上損失でした。

2週間のテスト強化で予想される障害率を60%削減できます。」

技術的負債の優先順位マトリックス

ビジネス影響 高

|

Q2: 計画的返済 | Q1: 即時返済

(次の四半期ロードマップ)| (スプリントに含める)

|

────────────────────────┼──────────────────────

|

Q4: 受容 | Q3: 段階的改善

(現状を維持) | (ボーイスカウトルール)

|

ビジネス影響 低

左：変更頻度 低 右：変更頻度 高

- **Q1（即時返済）**：ビジネス影響が大きく、頻繁に変更されるコードの技術的負債。最優先で解決

- **Q2（計画的返済）**：ビジネス影響は大きいが、変更頻度が低いコード。ロードマップに含める

- **Q3（段階的改善）**：頻繁に変更されるがビジネス影響が小さいコード。ボーイスカウトルールを適用

- **Q4（受容）**：どちらも低いコード。現状を受け入れる

エンジニアリング文化の構築

心理的安全性（Psychological Safety）

GoogleのProject Aristotle研究が明らかにしたように、最高パフォーマンスチームの最も重要な特性は**心理的安全性**です。Staff Engineerは技術的卓越性だけでなく、チーム文化にも責任があります。

**心理的安全性を高めるStaff Engineerの行動：**

1. **ミスを公開的に認める**：「この設計で私が見落としていた部分がありました」

2. **質問を歓迎する**：「良い質問ですね」ではなく、具体的になぜ良い質問なのかを説明

3. **ポストモーテムで非難しない**：「誰が」ではなく「どのようなシステム要因が」障害を引き起こしたかを探求

4. **多様な意見を積極的に求める**：「別の視点をお持ちの方はいますか？」

技術意思決定の透明性

Staff Engineerが主導する技術意思決定が透明であるほど、組織の信頼は高まります。

- なぜこの技術を選んだのか、どのような代替案を検討したかを公開

- 決定が間違っていたなら率直に認め、方向修正

- 意思決定プロセスに様々なレベルのエンジニアの参加機会を提供

学習文化の醸成

学習文化の実践方法

============================================

週次：

- Tech Talk（30分）：チームメンバーが順番に関心のある技術を発表

- コードレビューパワーアワー：重要なPRをチーム全体で一緒にレビュー

月次：

- 技術書籍の読書会

- インシデントレビューセッション（ポストモーテム共有）

- ハッカソンまたはInnovation Day

四半期：

- テクノロジーレーダーの更新（Adopt/Trial/Assess/Hold）

- キャリア成長1:1（マネージャー + Staff Engineer）

- 外部カンファレンス参加と社内共有

Staff Engineerキャリア成長ロードマップ

シニアからStaffへの転換

シニアエンジニアからStaff Engineerへの昇進に必要なのは、「より多くのコードを書くこと」ではありません。

シニア → Staff転換に必要な能力変化

============================================

もっとやるべきこと：

+ チームを超えた技術的影響力

+ 文書化された技術意思決定（RFC/ADR）

+ 組織レベルの技術課題解決

+ ジュニア/ミッドレベルエンジニアの成長支援

+ ビジネスコンテキストの理解と技術戦略との接続

減らしてもよいこと：

- すべてのコードを自分で書く

- すべての技術的詳細を把握

- すべてのコードレビューに参加

絶対に失ってはいけないこと：

! コーディング能力の維持（ハンズオン比率30〜50%）

! 技術トレンドの学習

! 謙虚さと好奇心

Impact Logの作成

Staff Engineerレベルでは、自分のインパクトを体系的に記録することが重要です。パフォーマンスレビューの時期に記憶に頼ると、重要な貢献を見逃してしまいます。

Impact Log - 2026 Q1

組織への影響

- [RFC-018] 決済サービスへのイベントソーシング導入を提案・承認 (3/1)

- 影響範囲：決済チーム、注文チーム、精算チーム

- 予想される効果：監査ログ要件の100%充足

技術的負債の返済

- 認証ミドルウェア統合プロジェクトをリード (1/15 - 2/28)

- 5サービスの認証方式をJWTに統一

- セキュリティ監査の指摘事項3件を解消

メンタリング/成長支援

- ジュニアエンジニア2名の定期メンタリング（隔週）

- 1名のシニア昇進を支援（昇進成功）

- 「分散システムの基礎」社内ワークショップを実施 (2/10、参加者25名)

インシデント対応

- 決済ゲートウェイのタイムアウト障害対応をリード (1/22)

- 30分以内に原因を特定しホットフィックスをデプロイ

- ポストモーテムを作成し再発防止策3件を導出

おわりに

Staff Engineerの本質は、**技術的卓越性を組織の成果に転換すること**です。個人のコーディングスキルがどれほど優れていても、それがチームと組織の能力向上につながらなければ、Staffレベルの影響力とは言えません。

要点をまとめると以下の通りです。

1. **自分のアーキタイプを把握する**：Tech Lead、Architect、Solver、Right Handの中から自分に合った役割を見つけ、状況に応じて柔軟に切り替えましょう

2. **意思決定を透明にする**：RFCとADRで技術決定のコンテキストを記録し、却下された代替案も一緒に保管しましょう

3. **コードを超えて文章で影響力を広げる**：技術ビジョン文書、ポストモーテム、オンボーディングガイドなどで組織全体に価値を届けましょう

4. **メンタリングからスポンサーシップへ発展する**：アドバイスを超えて、成長の機会を作り出すスポンサーになりましょう

5. **技術的負債をビジネス言語に翻訳する**：「リファクタリングが必要です」の代わりに、ビジネスインパクトとROIで説得しましょう

6. **心理的安全性を高める文化を作る**：ミスを認め、多様な意見を歓迎し、学習を奨励しましょう

Staff Engineerの旅には「正解」がありません。組織ごと、人ごとに異なる形でこの役割を遂行します。大切なのは、**自分なりの方法で影響力を広げながら、エンジニアとしての本質（技術的卓越性と好奇心）を失わないこと**です。

参考資料

- [Staff Engineer - Will Larson](https://staffeng.com/)

- [The Staff Engineer's Path - Tanya Reilly](https://www.oreilly.com/library/view/the-staff-engineers/9781098118730/)

- [ADR (Architecture Decision Records)](https://adr.github.io/)

- [RFC Process - Oxide Computer Company](https://oxide.computer/blog/rfd-1-requests-for-discussion)

- [Project Aristotle - Google re:Work](https://rework.withgoogle.com/guides/understanding-team-effectiveness/)

- [DORA Metrics](https://dora.dev/)

- [ThoughtWorks Technology Radar](https://www.thoughtworks.com/radar)

- [Engineering Ladders Framework](https://www.engineeringladders.com/)