スタッフエンジニアへの道¶
原文¶
Becoming Staff isn't "write more code". It's "make the org faster".
- Pick 1-2 problems per quarter that move a metric: p95, error rate, oncall pages, cloud bill.
- Write the plan first: tradeoffs, failure modes, rollout, observability, owners.
- Lead through others: unblock 3 teams, not just your PR.
- Kill recurring pain: delete flaky jobs, simplify deps, set guardrails.
- Keep receipts: before/after numbers, decisions, wins, learnings.
If your absence slows delivery and increases risk, you're already doing Staff.
要約¶
スタッフエンジニアとは「コードをたくさん書く人」ではなく「組織を速くする人」。四半期ごとにメトリクスを動かす問題を1〜2個選び、計画→他者を通じたリード→再発する痛みの除去→実績の記録という流れで組織全体への影響を最大化する。
解説¶
スタッフエンジニアの定義¶
スタッフエンジニア（Staff Engineer）はシニアエンジニアの次のキャリアステップ。個人の技術力だけでなく、組織・チーム全体のアウトプットを高めることに責任を持つ。
「あなたがいなくなるとデリバリーが遅くなりリスクが上がる」→ それがすでにスタッフの仕事をしている証拠
5つの行動原則¶
| # | 行動 | ポイント |
|---|---|---|
| 1 | メトリクスを動かす問題を選ぶ | 四半期1〜2個: p95レイテンシ、エラーレート、オンコールページ数、クラウドコスト |
| 2 | 先に計画を書く | トレードオフ・障害モード・ロールアウト計画・可観測性・オーナー明記 |
| 3 | 他者を通じてリードする | 自分のPRだけでなく、3チームのブロッカーを解消する |
| 4 | 再発する痛みを潰す | 不安定なジョブの削除、依存の簡素化、ガードレール設置 |
| 5 | 実績を記録する | 改善前後の数値・意思決定・勝利・学びを残す |
シニアとスタッフの違い¶
| 軸 | シニアエンジニア | スタッフエンジニア |
|---|---|---|
| 影響範囲 | 自分のチーム | 複数チーム・組織全体 |
| 主な仕事 | 高品質なコードを書く | 他者を通じて成果を出す |
| 問題選択 | チケットを消化する | 四半期のメトリクス目標から逆算 |
| 計画 | 実装に集中 | トレードオフ・障害モードまで設計 |
| 評価軸 | PR数・実装品質 | 組織速度への貢献 |
Goバックエンドとの接続¶
- p95改善 → DB/API レイテンシの計測と最適化（→APIレイテンシ改善手札）
- 可観測性 → distributed tracing、structured logging の整備
- ガードレール → linter、静的解析、CIチェックの整備でチーム全体のコード品質を底上げ
→ 関連: 中堅エンジニア面接をやめよう