WillLarsonのレビュー一覧
-
-
-
-
-
-
Posted by ブクログ
実際に現場で活躍しているスタッフプラスエンジニアのインタビューが多く掲載されている。エンジニアとしてキャリアアップしていきたい気持ちが今あり、スタッフプラスエンジニアに必要なスキルや資質等、参考になる。自身のキャリアがもう少しリーダー寄りに進んだら、この本を読み返したい。
今の自分に響いたのは、ミシェル・ブー氏の以下。
"自分の技術力に隙間があること、携わっているプロジェクトでその隙間を埋める努力をすること、そして今の自分の能力よりも少し高いレベルを要求するプロジェクトに果敢に挑むことの3点をふだんから意識していれば、私は自分の技術スキルを高め、活用することができると信じています。" -
-
Posted by ブクログ
シニアエンジニアの先の、エンジニアリングマネージャーではないエンジニアとしてのキャリアをstaff engineerと呼ぶ。
スタッフエンジニアというキャリアの役割や目指し方について書かれた本だが、構成にまとまりがないため、あまり本題に関する理解は深まらなかった。
・snacking を避けること
仕事を労力とインパクトの二軸で分類した時、労力＝小、インパクト＝小の仕事をsnackingと呼ぶ。スタッフエンジニアが簡単な仕事から学べることは少なく、機会費用が無駄になる。そして、そのような仕事を通じて大きく成長する人もいるはず。
・エンジニアリングマネジメントとの比較
チームを育てたい、成功に導きたいと思えるのなら、マネジメントを経験してみるとよい。自分のためだけにマネジメントを経験してみようとするのは、やめた方が良い。
上司のスケジュール表を見て、それが自分にとって楽しめる予定かを考えてみるとよい。また、業績評価や面接を楽しめるかを考えるとよい。楽しめなければ、優秀なマネージャーになることはできない。
Staff engineer にもたくさんのマネジメントスキルが必要である。マネジメントの書籍がとても役に立つ。
スタッフエンジニアよりもマネジメント路線の方が役割や昇進の仕組みがわかりやすく、手本も多いが、それを第一の動機にすべきではない。 -
-
Posted by ブクログ
最近ではエンジニアのキャリアパスとして、マネジメントだけでなくプレイヤーとしての道も用意されていることが当たり前になってきたが、プレイヤーの道で上位役職者に求められる役割は世間的にはあまり明確に定まっていなかった。
この本では、役割について4つ類型化したり、何十名のスタッフプラスエンジニアの具体的に果たしている役割に関するインタビューを掲載することで、スタッフプラスエンジニアとは何かを解説しようとしている点が良いと感じた。
結局、スタッフエンジニアに関して会社を跨いで共通の明確な定義はなく、「シニアエンジニア以上の何かしらの役割を果たすエンジニア」という役割だと理解した。
自社にスタッフプラスエンジニア職を導入する際の考え方の参考になったので星4。 -
Posted by ブクログ
スタッフエンジニアの役割のアーキタイプ（典型）や、あるべき姿・考え方・行動指針・キャリアステップなどについて語られている。第1部では筆者によるスタッフエンジニアの定義が書かれていて、第2部では18名のスタッフエンジニアへのインタビューが書かれている。
スタッフ（重要/参謀）エンジニアとは、シニア（上級）エンジニアからテクニカルリーダーシップへ進む場合（つまりマネージャーへ進まない場合）の最初のキャリアである。また、スタッフエンジニア以降のキャリアをスタッフプラスと呼ぶ。
本書の想定読者はスタッフエンジニアを目指しているエンジニア、キャリアプランに悩んでいるエンジニア、エンジニアを部下に持つマネージャーや経営者など幅広く、エンジニアの世界観を養うのに役に立つだろう。マネージャーへ進まずにスペシャリストを極める場合のキャリアについて書かれた本は珍しいため、多くの人にとって学びがあるだろう。
私はスピード重視で目次・見出し・太字を中心に流し読みした。スタッフエンジニアについては知らない概念が多く、仮に精読すると時間がかかりすぎてしまうため。キーワードを拾いながら興味のある部分を読むだけでも十分な学びを得られたと満足している。
後半のインタビューにおける各人の仕事内容・立場・経緯はケースが限定的すぎるので目的を持たずに読むとかえって迷子になってしまうかもしれない。しかしキャリアで悩んでいる人にとっては参考にできるものがあるかもしれない。また、インタビューの多くでは最後に学習方法について語られており,この部分は広く参考になり、真似のしがいがあると思う。
また、インタビュアーの質問やインタビュイーの回答・説明が非常に洗練されている。私は仕事でインタビューをされたり、面接をしたりする機会があるのだが、物事を整理して話すことに難しさを感じているため、この点でも本書のレベルの高さに敬意を持っている。
18ページ
多くの人にとって、スタッフエンジニアとして積む最初の経験がテックリードとしての役割だ。
→本書を読む前にはこのイメージができていなかったが、言われてみればそれが良い気はする。
22ページ
ほかのスタッフレベルの役割では組織とのすり合わせに多くの労力を割かなければならないのに対し、ソルバーは組織が優先事項と認めた問題にかかわるため、上層部の説得などを行う必要は少ない。
→この役割定義の分け方はわかりやすくて参考になる。あくまでも問題の解決に対して責任を持つのであり、問題に直接的に関係していない経営層や関係者の考慮はスコープ外にするという考え方。
286ページ
自分の考えを理解するのは半分に過ぎず、それを理解しやすい形で表現するのが本当に難しくて、価値のあることなのだ、という考えです。
→非常に同意できる。難しい概念を難しい表現のままで話すのは簡単だし、聞き手の理解度に頼って説明を省略しすぎるのも健全ではなく再現性がない。会社組織で働くからには、あるいはヒトと働くからには、理解しやすく表現する能力は重要である。 -
-
Posted by ブクログ
第1章：導入
第2章：組織 機能する組織を作り、維持する
6～8人のエンジニアを支援：マネージャー
4人未満のエンジニアを支援：テックリードマネージャー
4人～6人のマネージャを支援：マネージャーのマネージャー
1~2人の小さなチームはチームではない
→抽象化に漏れが多い 個人で動く場合と見分けがつかない
成長するチームの4段階
1.遅延 ハードワークだが進捗が乏しい 士気低い
→新しく人を増やす
2.現状維持 重要な仕事はできている 士気は多少あり
→現在の仕事を減らす
3.負債返済中 技術的負債の解消に取り組み、その恩恵を受けている
→ゆとりをもたせる
4.革新 士気が高い ユーザーニーズを満たす仕事にとりくむ
→さらにゆとりで、イノベーションに取り組む
チームファーストに徹する
チームが結束するには時間がかかる。解体すると結束が初期化される
エンジニアが増えるほど問題も増える
サクセッションプランニング（後継者育成計画）を進める
同僚が何をしているかを理解する
ギャップを埋める
第3章：ツール 変化をマネジメントする手法
システム思考、メトリクス、ビジョン
・システム思考
プロダクトマネジメント：
エンジニアリングとプロダクトそれぞれでリーダシップが必要
プロダクト開発
問題の発見→問題の選定→解決策の検証→実行→問題の発見→・・・
戦略とビジョンの合意形成
戦略：具体的に、実用的
ビジョン：方向性を示す、願望的に長期視点
文書化し、内容を検証する、定期的に更新、シンプルに記載
メトリクス
ゴールの定義
ターゲット：到達場所
ベースライン：現在の場所
トレンド：現在の速度
タイムフレーム：変化の期間
マイグレーション
技術的負債の唯一のスケーラブルな解決法
リーダシップの発揮
モデル：プロセスを繰り返し試行錯誤する
ドキュメント：採用方法を説明する
シェア：ドキュメント送付、プラクティス採用を義務付け
タイムマネジメント
四半期ごとの時間の振り返り
短期的な品質よりも長期的な成功を優先する
学習コミュニティをつくる
簡単なプレゼン、長い議論
経験豊富な人の参加を促す
事前学習を任意にする
少人数のグループに分割する
全体のグループに学びを共有する
第4章：アプローチ 問題解決につなげる
ポリシーに従う、例外に従わない
よいポリシーは制約をもたらす
優先順位の確定
すべての要求を文書化する
タスク選択するための原則を作る
原則に基づいて選択したサブセットを共有する
マネジメントの哲学
強い関係性はどんな問題にも勝る
プロセスよりも人が大事
困難なことからすぐ取り込む
エンジニアリングマネージャーが行き詰まる
部下または上司だけをマネジメントする
関係構築に時間を費やさない、または使いすぎる
局所最適化する
第5章：文化 継続的に取り組んで育成する
機会とメンバーシップを提供する
ルーブリック（評価指標）を持ちいる
定期的に開催されるイベントを設ける
ヒーローを作らない、頑張りすぎをやめる
第6章：キャリア 同僚と自分に対して責任を持つ
キャリアナラティブを紡ぐ
去年の出来事の振り返り
第7章：さらに先へ
他書籍の紹介など -
Posted by ブクログ
ネタバレ概要:
本書は、システム・エンジニアリング分野におけるチーム・マネジメントの教科書として位置づけられる。ヌケモレなく、マネジメントに必要な基本が淡々と述べられており、筆者の主観的な経験談や感情的な記述はほぼ見られない。そのため、良くも悪くも読み物としての面白さは期待できないが、マネジメントの基礎を体系的に学ぶには最適であると言える。逆に言えば、本書の内容がピンと来ないと感じるマネージャーは、その職を再考すべきかもしれない。それほどまでに、基本に忠実で網羅性の高い内容となっている。
特に印象に残った点:
エンジニアのマネジメントも、結局はマネジメントの基本の組み合わせであるという原則は改めて認識させられた。しかし、実務においては、エンジニア一人ひとりの多様性を無視することはできない。それぞれの個性やスキル、興味範囲だけでなく、仕事へのスタンスも大きく異なる。特に、私の経験が異業種のメンバーが混在するプロジェクトが多かったため、その多様性の大きさを痛感している。ソフトウェア開発の現場では、ある程度の役割分担やスキル構成の前提があるかもしれないが、多様なバックグラウンドを持つメンバーをまとめ、成果を出すためには、より個別に向き合う必要性を強く感じる。
本書の内容と自身の経験:
本書に書かれている原則は理解できるものの、それを多様なメンバーに対してどのように適用し、具体的な成果に繋げるのか、という点に大きな課題を感じている。教科書的な知識だけでは解決できない、個々のメンバーとのコミュニケーションや動機づけ、そしてチーム全体の方向性を示すリーダーシップが不可欠であると改めて認識した。特に、異業種のメンバーとの協働経験が多い私にとっては、本書のような普遍的な原則だけでは対応しきれない場面が多いと感じる。
今後の課題と疑問点:
本書で得られた知識を、実際の多様なチームでどのように活かしていくかが今後の大きな課題である。理想としては、本書のような普遍的な原則をベースにしつつ、個々のメンバーの特性や状況に応じた柔軟な対応策が示されていると良かった。具体的なモデルやソリューションが提示されていれば、より実践的な学びになっただろう。
深層心理の反映:
本書の網羅性と客観性は評価しつつも、どこか物足りなさを感じているのは、私がマネジメントにおいて、単なる知識や原則だけでなく、もっと人間味あふれる、泥臭い部分も重要だと考えているからかもしれない。また、教科書的な正しさを求める一方で、現実の複雑さや多様性に対する理解も深く、そのギャップに苦悩している様子が伺える。過去の異業種混合チームでの成功体験から、多様性を活かすマネジメントへの強い願望がある一方で、具体的な方法論を見出せていない現状への焦りも感じられる。普遍的な知識だけでは解決できない問題に対し、具体的な解決策を強く求めている。 -
Posted by ブクログ
シニア（上級）エンジニアまでは個々のパフォーマンスが評価される。スタッフ（重要）エンジニアになると、チームとしてのパフォーマンスが評価される。そのため、チームや他部署、経営層とうまくやる能力が必要となってくる。また戦略的にエンジニアリング組織全体について考える必要もでてくる。本書ではこれらの基本的な考え方を紹介するとともに、実地で活躍しているスタッフエンジニアがどういった業務で何を心がけているのかインタビューをまとめている。子供のころやった「親の仕事について質問する」宿題のようなものだ。
スタッフエンジニアは大きく4つのアーキタイプに分類でき、どのアーキタイプかによって求められる役割は変わるので、自身がどれを志向するかによって、目指すべき形は変わってくる。本書を読んで明日から行動！とはなかなかならないが、「こういう働き方がある」「そのためにはこういう能力が必要」と知り、キャリアを意識する助けにはなると思う。
帯にある「最強のソフトウェアエンジニア」に期待したものと違った、という声も多そうな内容であった。 -
-
-
-
-