- Authors
- Name
- はじめに
- Staff Engineerの4つのアーキタイプ
- 技術意思決定：RFCとADR
- 影響力の拡大：コードを超えて
- メンタリングとスポンサーシップ
- 技術的負債の戦略的管理
- エンジニアリング文化の構築
- Staff Engineerキャリア成長ロードマップ
- おわりに
- 参考資料
はじめに
シニアエンジニアになった後のキャリアパスは、大きく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運用のベストプラクティス
- RFC/ADRをコードリポジトリで一緒に管理：コードと意思決定を一緒にバージョン管理
- レビュー期限の設定：無期限に開いたままのRFCは決定を遅延させる
- テンプレートの提供：一貫した形式で記述の負担を軽減
- 却下された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の行動：
- ミスを公開的に認める：「この設計で私が見落としていた部分がありました」
- 質問を歓迎する：「良い質問ですね」ではなく、具体的になぜ良い質問なのかを説明
- ポストモーテムで非難しない：「誰が」ではなく「どのようなシステム要因が」障害を引き起こしたかを探求
- 多様な意見を積極的に求める：「別の視点をお持ちの方はいますか？」
技術意思決定の透明性
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レベルの影響力とは言えません。
要点をまとめると以下の通りです。
- 自分のアーキタイプを把握する：Tech Lead、Architect、Solver、Right Handの中から自分に合った役割を見つけ、状況に応じて柔軟に切り替えましょう
- 意思決定を透明にする：RFCとADRで技術決定のコンテキストを記録し、却下された代替案も一緒に保管しましょう
- コードを超えて文章で影響力を広げる：技術ビジョン文書、ポストモーテム、オンボーディングガイドなどで組織全体に価値を届けましょう
- メンタリングからスポンサーシップへ発展する：アドバイスを超えて、成長の機会を作り出すスポンサーになりましょう
- 技術的負債をビジネス言語に翻訳する：「リファクタリングが必要です」の代わりに、ビジネスインパクトとROIで説得しましょう
- 心理的安全性を高める文化を作る：ミスを認め、多様な意見を歓迎し、学習を奨励しましょう
Staff Engineerの旅には「正解」がありません。組織ごと、人ごとに異なる形でこの役割を遂行します。大切なのは、自分なりの方法で影響力を広げながら、エンジニアとしての本質（技術的卓越性と好奇心）を失わないことです。