対象者

エンジニアとして仕事をしているが、マネジャーなどの管理職ではないことに不安を覚えている人
マネジャーではなく社内の手本となる最上級エンジニアを目指している人
最上級エンジニアにどんなスキルや行動を期待すれば良いかわからない管理職の人

スタッフエンジニアとは

本書でいう「スタッフエンジニア」とは "テクニカルリーダーシップ" を発揮する役職のことを指しています。
通常多くの企業ではシニアエンジニア(実務レベルの設計/コーディングをこなせるレベルのエンジニアを定義)以降のメンバーに対してキャリアパスに二つの道を提示しています。
それが以下の2つです。

スタッフプラス(テクニカルリーダーシップ)
エンジニアリングマネジメント(俗に言うマネジャーなど)

テクニカルリーダーシップというと、単純に高い技術力を持っているエンジニアだとイメージする人も多いと思います。ただし本書では 【影響力のあるエンジニアは技術だけでなく模範的なソフトウェアエンジニアとしての振る舞いが重要】 だとしています。

スタッフエンジニアの仕事

テクニカルリーダーシップを発揮するスタッフエンジニアの仕事についてどんなものがあるかを紹介している本書ですが、例が多すぎたため、ここでは私が印象に残った箇所をいくつかピックアップしていきたいと思います。

技術選定、アプローチの役割
- スタッフエンジニアはビジネスと組織に責任を負うため、自分の関心のあるテクノロジーとアプローチよりも組織の現実的な需要を理解した方向性の設定をする方が遥かに重要
- 1人のエンジニアとしてのエゴは優先度を低くする
メンターとしての役割
- 個人的な英雄行為を行う以上にメンバーの育成が会社にとっての長期的な利益になる
- メンターシップとは、メンバーに自らの経験をわけあたえ、助言を授け、そして良好な関係を築きながら相手の状況を理解すること
コードを書き続けることはない
- リーダーになるとたくさんコードを書き続けることはない
- ただし同僚が書いた大量のコードは読むし、コードレビューを頻繁に行うことになる

スタッフエンジニアのメリット

本書では、スタッフエンジニアになることで得られるメリットを3つあげています。

年功序列という制度から逃れられる
- シニアエンジニアまでは自分の実力を証明し高い評価を得るために費やす労力が必要だが、スタッフエンジニアになると肩書きだけで信頼を得られるためその必要がなくなる
上流の意思決定の部屋に同席できる
- 役職が低いうちには意思決定の場に同席できず、言われたことをただこなしていくことになりやすいがスタッフエンジニアはフィードバックを上層部に届けることができるためプロジェクトをコントロールできる
収入が高くなる
- 役職が上がるので給料が高くなりやすい

スタッフエンジニアになる方法

スタッフエンジニアのメリットを挙げましたが、では どうすればスタッフエンジニアの肩書を得ることができるのでしょうか？
本書ではその点についても述べられていましたので、紹介したいと思います。
なお、例が多かったので個人的に印象に残った点を紹介したいと思いました。

会社内で自分の知名度を上げる

会社の上層部に自分の名前を知っているものがいなければスタッフエンジニアになることは難しいため、社内知名度をあげていく必要があります。
その方法を本書では以下のように説明しています。

チャンスは不平等であることを自覚する

昇格しやすい職種などは会社ごとに異なるが存在する
- 自分の今の役割でスタッフエンジニアになることが可能かどうか探り、どの部分に労力を割いていくかを見極めること
- 自分の活動を支持してくれるスポンサーを会社内部から見つける

マネジメントを試してみる

一度マネジメントにチャレンジしてみて、難しければエンジニアリングへ戻っても良い
- マネジメントにチャレンジしてみることで視野が広がり、その時の経験が役に立つかもしれない
  - 注意点は、ピープルマネジメントはスタッフエンジニアの業務の延長上にあるわけではないことをあらかじめ理解しておくこと
  - マネジメントにチャレンジする際にはマネジメントされる側に影響を与えることを自覚しなければならない
    - そうでなければメンバーに不信感を抱かせマネジメントに手を出したことを後悔することになる

スタッフエンジニアのポテンシャルを秘めた人物だとチームメンバーに思われること

常日頃の行いで、既存のメンバーから信頼を得ていればスタッフエンジニアになることは容易

スタッフエンジニアになりたい旨をアピールする文書を書く

多くの企業では昇進の際に提出する文書があるがそれを書いていこう。

スタッフエンジニアになりたい理由を明確にする
- 誰にでもできる仕事ではないため、スタッフエンジニアの肩書きばかり望んでいる人はいつの間にか望んでいない役回りをすることになり苦しむことになる
期待しすぎない
- 昇進には期間が必要であるためすぐに結果が出ると思わないこと

その他

社外における知名度を上げる

社内だけでなく、社外でも認知度を上げる努力をしていこう
方法は、

カンファレンスに登壇する
書籍を出す…など

転職を決断する

スタッフエンジニアを目指せる環境に身を置くことも検討すること

スタッフエンジニアとして発展するために大切なこと

1. 重要なことに力を注ぐこと

無理して周りの期待に応えようと睡眠時間を削っても仕事はあなたの犠牲に報いることはないので人生とキャリアの歩調を無理なく合わせていくことが重要
楽な仕事はせずに、難しくてインパクトの大きい仕事をやろう
コーチングやメンタリングなど育成に力を注いでいこう
自分にしかできない仕事をしよう
- あなたがやらなければ実行されることのない仕事は最大のチャンス

2. エンジニアリング戦略を立てること

デザイン文書を5つ作成してみよう
- デザイン文書とは、一つの特定の問題を文書化し、そのために必要なソリューション候補を提示、アプローチの詳細までを記載したもの
- 会社によっては「RFC」や「技術仕様」とも呼ばれるもの
- 情報集めとレビューはグループで行い、文書の記述は1人で行う
- 文書は完全なものでなく、最低基準のものができたら終わらせてしまおう
- 最後に5つの文書を1つのエンジニアリング戦略文書にまとめる
エンジニアリング戦略文書を5つ作成してみよう
- エンジニアリング戦略文書とはなぜその方法を採用したのかをトレードオフと一緒に提示した上で採用した理由を合理的に説明されている文書のこと
- 戦略文書はなるべく具体的かつ断定的に記述し、考察を示すこと
エンジニアリング戦略文書を5つ作成してから1つのビジョンを導き出そう
- エンジニアリング戦略が2~3年でどのように発展していくかを見越してビジョンを書く
- ビジネスとユーザーに寄り添って書く
  - 出来の悪いビジョンは技術ありきで成り立っている
- 無謀なビジョンは書かない
- 現実的かつ具体的なビジョンを書く
- 長さは1~2ページ程度に

3. 技術品質を管理すること

品質の低さは危機ではなく、むしろ予想できる正常な状態と捉えること
- 技術品質の実態と理想のギャップは、ミスをなくすことで埋めるのではなくエンジニアリングリーダーシップで埋める
問題の根本原因を見つけ出して修正すること
- 何かシステムに問題があれば根本原因を特定することに力を注ごう
品質の向上に有効なベストプラクティスを採用する
- ベストプラクティスや事例を調査して採用していこう
会社全体の品質均一のための方向性を一致させる
- 品質を均一化するように全体に品質管理のベストプラクティスを浸透させよう
品質を測定しよう
- 品質均一化を進めるためには品質を測定する必要がある
  - 【例】
    - よくプルリクエストで変更対象になっているファイルは何なのか？
    - プライマリデータベースインスタンスに不要なリード操作を行なっていないか？
    - 各エンドポイントはコールドスタート後500ms以内に適切なレスポンスを行なっているのか？
    - 何割のファイルに関連するユニットテストが存在するのか
    - 静的型付けが全体の何割行われているか
品質確保のためのツールやシステムを開発・導入するチームを組む
- 品質向上のための計画を行うチームを作っていこう
  - →本書では人数は3~6人ほどが望ましいとしています
  - 直感ではなく測定結果を重視しよう

4. 権威と歩調を合わせること

上級職の肩書きは万能ではない
- 出世すれば自分のやりたいことをやれるという意味ではない
- スタッフエンジニアなどの上級職の肩書きは、より上位の組織的権威から貸与されるものであり、剥奪される可能性のあるものであると認識しよう
- スタッフエンジニアのような上級職は組織的権威と歩調を合わせ続ける術を身につけなければならない
社長/上司を喜ばせる
- 上司と足並みを揃える術を自分で磨いていくことが重要
- 以下は重点をおくべき要素
  - 上司を驚かせない
    - 複数のプロジェクトや問題に直面した時、それが繰り返されていたり問題が大きかったりすると、「このリーダーは組織に対して責任を感じているのか」という疑問が残る。
    - もし上司を驚かせてしまった場合は、再発を避ける努力をしていくことが重要
  - 上司に驚かない
    - 上司がいつもあなたに重要な情報を流してくれるとは思わないこと
      - 例えば週に一回のアップデートメールを送るとかslackであなたの週間目標を共有するなどを行うことで情報を引き出し合おう
      - 協調を育むためにどのように上司と関わっていけばいいのか検討していこう
摩擦なく影響力を発揮していくこと
- リーダーとして成長するためには、世界はどう機能すべきかという独自の世界観を養う必要がある
- 一方で、さらなるステップへ進むためには自らのビジョンと上司のビジョンを融合させていく必要がある
- 上記のように時間をかけて慎重に行動すればあなたは組織のリーダに対して多大な影響を与えることができるようになる

5. リードするには従うことも重要だと認識すること

リーダーとして長期的な成功を収めるためには「従う」方法を学ばなければならない
- 本当に優秀なリーダーは世界をリーダーとフォロワーという縦割りの構造で考えない
- 完全には納得できないが有望な方法があるのであれば、他の人にリード権を与えて取り組んでもらう
- リード権を与えたメンバーや他のリーダーをサポートする
  - 例え納得していないやり方であっても
  - もしどうしてもプロジェクトの進行に不安があるのであれば、自分のフィードバックが下手だったのか振り返ってみること

6.絶対に間違えない方法を振り返ってみること

他人の意見を受け入れる器を持ちながら、正しくあり続ける
- スタッフエンジニアは、技術やアーキテクチャを全て理解できることはないと自覚し、さらには「自分自身」にも懐疑的であり続けなければならない
  - 一方で、「自分は決して間違っていない」と思い込んでいる人は、メンバーの意見と対立することがあればそれが受け入れられるまで議論を続けようとする。彼らの考えが正しいこともあるが、そのやり方はチームの空気を淀ませ、ほとんどの場合、他の人々は反論するのを諦めチームを機能不全にしてしまう
話を聞き、明らかにし、空気を読もう
- 話を聞く：「アクティブリスニング」を行い、議論の場にいるメンバーの考えを理解すること
  - 自分の考えを述べる前に、メンバーの意見に対する適切な質問を投げかけてみること
- 目的を明確にする：まずチームが何を達成しようとしているのかを問いかける
  - 注意点として、確認の回数は繰り返さないこと。目的の定義に失敗したミーティングはほぼいつも次のミーティングの日時を決めるまでで幕を閉じる
- 空気を読むこと：議論が長期化すると痺れを切らして合意を強制しようとする者が出てきて、空気が悪くなることがあるが、その時は最後まで問題を深ぼってくれそうなメンバーで再構成するか、必要なメンバー以外は議論から席を外させたりしよう
わからず屋への対処方法を身につけよう
- ほとんどの場合上記の方法は有効であるものの、妥協を拒み、チームの方針に同意しようとしない人たちがいることがある。彼らの対処法について本書では以下のアプローチを挙げている
  - わからず屋にとって頑固な態度を取るわけにはいかない人物(彼らの上司やCTO)を会議の場に同席させる
  - MTGに先立ってわからず屋とのすり合わせを多くの時間をかけて行い、彼らの意見も尊重されていることを実感させて議論の際の脱線を防ぐ

7.他人のスペース(余地)を設けること

スタッフエンジニアとして活躍する秘訣は会社にとって重要なエンジニアとして貢献しつつも会社があなたに依存しきっていない状態にすること
優れた議論の場を作ろう
- スタッフエンジニアは質問をすることに重点を置こう
  - 適切な質問はミスを防ぐだけでなく、チームの個人個人が貢献しやすい雰囲気を作る
- ミーティングで会議に加われない人がいたら、彼らに発言を促そう
  - 目安としては1回につき1人に絞って行う
- 議事録の執筆を行おう
  - 議事録を書くのは下っ端の仕事だという偏見がなくなり、普段発言をしない人に議論する機会を与えることができる
スポンサーとしてメンバーを支援しよう
- メンバーに、スタッフエンジニアの仕事に関与させるだけでなくその仕事をメンバーのものにさせる。そして自分は仕事を委ねたメンバーのスポンサーに徹することが重要
  - 究極的なことを言えば、自分なら取らないアプローチを仕事を委ねたメンバーが取ろうとしていた場合もそれを認めてみること
  - 結果としてそれが失敗に終わった場合は適切なフィードバックを与えることでメンバーの成長を促すことができるし、成功した場合は新たな学びを得ることができる
- ただしスポンサーシップをメインのアプローチにしてはならない
  - 月に数回程度はスポンサーシップに徹してみること
  - いくつかのプロジェクトでは自ら直接関与してみること
- スポンサーになりたくない場合
  - あなたの限界が組織の限界となるような会社ではあってはならないと認識しよう

8.ネットワークを築くこと

外部ネットワークを築いてみよう
- 社外の同じスタッフエンジニア職の人同士のネットワークを築いてみよう
- 例えばカンファレンスの参加やエンジニアコミュニティに入ってみるなど
  - 外部に自分の名前を認知してもらうことで、キャリア形成において大きな武器となる
内部ネットワークを築いてみよう
- 内部の社員間でのネットワークを築いていくことで、内部の社員たちが外へ散らばった際に自分のキャリア形成に役立つ

まとめ

いかがでしょうか？
以下にこれまでに説明した内容をまとめてみました！

スタッフエンジニアとはテクニカルリーダーシップを発揮する役割のこと
スタッフエンジニアは、技術だけでなく模範的なソフトウェアエンジニアとしての振る舞いが重要
スタッフエンジニアになるメリットは
- 信頼のある肩書きであるため、自分の実力を証明するためのアプローチが必要ない
- 重要な組織の意思決定の場に同席することができる
- 高収入が狙える
スタッフエンジニアになるために必要なアクションは
- 会社の上級職に自分の存在を認知してもらうこと
- 会社の上級職にスタッフエンジニアになりたいアピールをすること
- マネジメントをやってみること
- 他のチームメンバーにスタッフエンジニアのポテンシャルがあると思われること
スタッフエンジニアとして成功を収めるためには
- 難しくてインパクトの大きい仕事に取り組もう
- メンター活動をしてみよう
- エンジニアリング戦略を縦よう
- コアビジネスと同じくらい品質管理を徹底しよう
- 権威と歩調を合わせて組織と摩擦が生じないように、うまく自分のビジョンと組織のビジョンを融合させよう
- 自分の世界観はしっかり持ちつつも謙虚に振る舞い、時にはメンバーに従うことも覚えよう
- 自分の実力を証明するばかりでなく、適度にメンバーに自分の仕事を与えてサポートに徹してみよう
- 外部や内部に情報発信や交流を行い、良好な人間関係をたくさん構築しよう

所感

自分も最近リーダーを最近任されるようになってきて、ゆくゆくはスタッフエンジニアになりたい気持ちがあります。なので本書で学んだことを実践していきたいと思いました！