あらすじ
ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します。
「スタッフエンジニア(超上級エンジニア)」になるには
どんなスキルを身につければいいのだろうか?
技術的な能力さえあればいいのだろうか?
なった人は、具体的に何をしたのだろう?
その仕事を楽しむには、どうしたらいいのだろうか?
これらの疑問に答えるのが本書の目的だ。
■「解説」から
本書は2部構成になっており、第1部でスタッフエンジニアの役割とあり方を解説。第2部(おもに第5章)で現役のスタッフエンジニアのインタビューを通してその実像を掘り下げています。
私のおすすめの読み方は、まず第5章のインタビューを2~3人分読んでから、第1部を読み進めることです。とくにある程度経験を積まれたエンジニアの方は、第5章に登場するスタッフエンジニアの具体的なエピソードに大いに共感されることと思います。その共感を胸に第1部を読むことで、スタッフエンジニアに求められる役割が自然と腑に落ちるのではないでしょうか。
感情タグBEST3
Posted by ブクログ
まずインタビューを読んでから頭から読む。自分はもうエンジニアではないが2章と3章は結構刺さる内容。
ストーリーの人たちの言語化力に驚く。ここまで言語化できるように意識しないといけないと感じる。
Posted by ブクログ
シニアエンジニアの先のキャリアパスに関して具体的に書かれている。
Slack, Dropbox, Stripe などのテック企業のスタッフエンジニアのリアルな声が綴られており参考にできることが多かった。
Posted by ブクログ
実際に現場で活躍しているスタッフプラスエンジニアのインタビューが多く掲載されている。エンジニアとしてキャリアアップしていきたい気持ちが今あり、スタッフプラスエンジニアに必要なスキルや資質等、参考になる。自身のキャリアがもう少しリーダー寄りに進んだら、この本を読み返したい。
今の自分に響いたのは、ミシェル・ブー氏の以下。
"自分の技術力に隙間があること、携わっているプロジェクトでその隙間を埋める努力をすること、そして今の自分の能力よりも少し高いレベルを要求するプロジェクトに果敢に挑むことの3点をふだんから意識していれば、私は自分の技術スキルを高め、活用することができると信じています。"
Posted by ブクログ
5章と2章がよかった。5章の実際のスタッフエンジニアへのインタビューでスタッフエンジニアとはどのような役職なのか具体的にイメージできる。2章で役割を抽象的な言葉に落とし込まれている。
Posted by ブクログ
シニアエンジニアの先の、エンジニアリングマネージャーではないエンジニアとしてのキャリアをstaff engineerと呼ぶ。
スタッフエンジニアというキャリアの役割や目指し方について書かれた本だが、構成にまとまりがないため、あまり本題に関する理解は深まらなかった。
・snacking を避けること
仕事を労力とインパクトの二軸で分類した時、労力=小、インパクト=小の仕事をsnackingと呼ぶ。スタッフエンジニアが簡単な仕事から学べることは少なく、機会費用が無駄になる。そして、そのような仕事を通じて大きく成長する人もいるはず。
・エンジニアリングマネジメントとの比較
チームを育てたい、成功に導きたいと思えるのなら、マネジメントを経験してみるとよい。自分のためだけにマネジメントを経験してみようとするのは、やめた方が良い。
上司のスケジュール表を見て、それが自分にとって楽しめる予定かを考えてみるとよい。また、業績評価や面接を楽しめるかを考えるとよい。楽しめなければ、優秀なマネージャーになることはできない。
Staff engineer にもたくさんのマネジメントスキルが必要である。マネジメントの書籍がとても役に立つ。
スタッフエンジニアよりもマネジメント路線の方が役割や昇進の仕組みがわかりやすく、手本も多いが、それを第一の動機にすべきではない。
Posted by ブクログ
最近ではエンジニアのキャリアパスとして、マネジメントだけでなくプレイヤーとしての道も用意されていることが当たり前になってきたが、プレイヤーの道で上位役職者に求められる役割は世間的にはあまり明確に定まっていなかった。
この本では、役割について4つ類型化したり、何十名のスタッフプラスエンジニアの具体的に果たしている役割に関するインタビューを掲載することで、スタッフプラスエンジニアとは何かを解説しようとしている点が良いと感じた。
結局、スタッフエンジニアに関して会社を跨いで共通の明確な定義はなく、「シニアエンジニア以上の何かしらの役割を果たすエンジニア」という役割だと理解した。
自社にスタッフプラスエンジニア職を導入する際の考え方の参考になったので星4。
Posted by ブクログ
スタッフエンジニアの役割のアーキタイプ(典型)や、あるべき姿・考え方・行動指針・キャリアステップなどについて語られている。第1部では筆者によるスタッフエンジニアの定義が書かれていて、第2部では18名のスタッフエンジニアへのインタビューが書かれている。
スタッフ(重要/参謀)エンジニアとは、シニア(上級)エンジニアからテクニカルリーダーシップへ進む場合(つまりマネージャーへ進まない場合)の最初のキャリアである。また、スタッフエンジニア以降のキャリアをスタッフプラスと呼ぶ。
本書の想定読者はスタッフエンジニアを目指しているエンジニア、キャリアプランに悩んでいるエンジニア、エンジニアを部下に持つマネージャーや経営者など幅広く、エンジニアの世界観を養うのに役に立つだろう。マネージャーへ進まずにスペシャリストを極める場合のキャリアについて書かれた本は珍しいため、多くの人にとって学びがあるだろう。
私はスピード重視で目次・見出し・太字を中心に流し読みした。スタッフエンジニアについては知らない概念が多く、仮に精読すると時間がかかりすぎてしまうため。キーワードを拾いながら興味のある部分を読むだけでも十分な学びを得られたと満足している。
後半のインタビューにおける各人の仕事内容・立場・経緯はケースが限定的すぎるので目的を持たずに読むとかえって迷子になってしまうかもしれない。しかしキャリアで悩んでいる人にとっては参考にできるものがあるかもしれない。また、インタビューの多くでは最後に学習方法について語られており,この部分は広く参考になり、真似のしがいがあると思う。
また、インタビュアーの質問やインタビュイーの回答・説明が非常に洗練されている。私は仕事でインタビューをされたり、面接をしたりする機会があるのだが、物事を整理して話すことに難しさを感じているため、この点でも本書のレベルの高さに敬意を持っている。
18ページ
多くの人にとって、スタッフエンジニアとして積む最初の経験がテックリードとしての役割だ。
→本書を読む前にはこのイメージができていなかったが、言われてみればそれが良い気はする。
22ページ
ほかのスタッフレベルの役割では組織とのすり合わせに多くの労力を割かなければならないのに対し、ソルバーは組織が優先事項と認めた問題にかかわるため、上層部の説得などを行う必要は少ない。
→この役割定義の分け方はわかりやすくて参考になる。あくまでも問題の解決に対して責任を持つのであり、問題に直接的に関係していない経営層や関係者の考慮はスコープ外にするという考え方。
286ページ
自分の考えを理解するのは半分に過ぎず、それを理解しやすい形で表現するのが本当に難しくて、価値のあることなのだ、という考えです。
→非常に同意できる。難しい概念を難しい表現のままで話すのは簡単だし、聞き手の理解度に頼って説明を省略しすぎるのも健全ではなく再現性がない。会社組織で働くからには、あるいはヒトと働くからには、理解しやすく表現する能力は重要である。
Posted by ブクログ
シニア(上級)エンジニアまでは個々のパフォーマンスが評価される。スタッフ(重要)エンジニアになると、チームとしてのパフォーマンスが評価される。そのため、チームや他部署、経営層とうまくやる能力が必要となってくる。また戦略的にエンジニアリング組織全体について考える必要もでてくる。本書ではこれらの基本的な考え方を紹介するとともに、実地で活躍しているスタッフエンジニアがどういった業務で何を心がけているのかインタビューをまとめている。子供のころやった「親の仕事について質問する」宿題のようなものだ。
スタッフエンジニアは大きく4つのアーキタイプに分類でき、どのアーキタイプかによって求められる役割は変わるので、自身がどれを志向するかによって、目指すべき形は変わってくる。本書を読んで明日から行動!とはなかなかならないが、「こういう働き方がある」「そのためにはこういう能力が必要」と知り、キャリアを意識する助けにはなると思う。
帯にある「最強のソフトウェアエンジニア」に期待したものと違った、という声も多そうな内容であった。
Posted by ブクログ
技術系のキャリアパス、役職についての話。O'Reillyにも類書があるが、本書は経験談が主体。いろいろな人の経験談(アメリカが多いが日本人の話も)が掲載されている。しかし、どれも「技術的にツヨくなってスゴい製品を作って世の中を変えよう」ではなく「 上の人に気に入られて上の人に求められるような働きをしよう」となっていて、すこし萎える。