読書メモ
-nilog: スタッフエンジニアをざっと読了。スタッフエンジニア、ってそのまま日本語にすると上級エンジニア感がないな(；・∀・) 「ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します」 「第1部でスタッフエンジニアの役割とあり方を解説。第2部（おもに第5章）で現役のスタッフエンジニアのインタビューを通してその実像を掘り下げています」 スタッフエンジニア マネジメントを超えるリーダーシップ | Will Larson, 長谷川 圭, 増井 雄一郎 (2024-08-08)
--http://www.nilab.info/nilog/?type=m01&id=112926491800589479
--
-シニアエンジニア
--「ほとんどのテクノロジー企業で、ソフトウェアエンジニアの役職1の1つとして「シニアソフトウェアエンジニア」 という階級があり、エンジニアは5年から8年でその役職に就けるように設定されている。」
-スタッフエンジニアとは
--「Staffには参謀といった意味もあり、 「エンジニアのリーダー」 および 「幹部の補佐役」 として米国では定着している役職」
-スタッフエンジニアの一般的なアーキタイプ4種
--テックリード
--アーキテクト
--ソルバー (解決者)
--右腕 (ライトハンド)
-テックリード
--「与えられたチームをアプローチや実行へと導く。通常は特定のマネジャーと密接に連携するが、ときには2人もしくは3人のマネジャーと協働することもある。」
--「「テックリード」はスタッフエンジニアとして最も一般的なアーキタイプであり、タスク (課題)の着手と遂行において1つのチームまたは複数のチームを率いる。複雑なタスクを見通し、チームをその解決に導き、その際の障壁を取り除く能力をもつ。多くの場合、チームを成功に導くためにテックリードがチームの置かれた状況を把握し、チーム間の、あるいは部門間の関係の維持に努める。 チームのプロダクトマネジャーと密接に連絡を取り合い、 ロードマップに変更が生じたときに最初に伝えられるのがテックリードだ。」
-アーキテクト
--「アーキテクトは企業内の特定の技術分野、たとえばAPIデザイン、フロントエンドスタック、ストレージ戦略、クラウドインフラストラクチャなどを成功に導く任を負う。」
-ソルバー (解決者)
--「複雑な問題を深く掘り下げ、前進する道を切り開く」
--「長期にわたって1つの領域にのみ携わる者もいる一方で、組織のリーダーシップの導きに応じて、 ホットスポットからホットスポットへと跳び回るソルバーもいる。」
--「会社が信頼を置くエージェントとして困難な問題に深くかかわり、その解決に責任を負うのが「ソルバー」だ。ソルバーの任を受けた者は、会社幹部が重要と認め、かつ明確な解決策が欠けているか、もしくは実行する際のリスクが極めて高いと考えられる問題に取り組む。」
-右腕(ライトハンド)
--「補佐役として会社幹部の関心を代表し、 幹部の能力と権限を借りて複雑な組織の運営にあたる」
--「大規模組織において経営陣のリーダーシップを広げる仕組み」
--「上級の組織リーダーではあるが直接的には経営責任を負わない人物」
--「右腕となった人々はリーダーの会議に同席し、彼らの抱える大きな問題を取り除くことによって、リーダーの影響力をさらに拡大することに努める。 このレベルで懸案となる問題には、ビジネス、 技術、 人、文化、 プロセスなどといった複数の要素が必ず関係していて、純粋に技術的なものはありえない。 通常、右腕は火事場に飛び込み、アプローチを修正し、最も適したチームに実行権を委ね、そして社内で次の火の手が上がった場所へと直行する。」
-「あなたも、特定の肩書きを手に入れることが大きな成果や重要な機会にたどり着く唯一の手段だと信じているエンジニアに出会ったことがあるかもしれない。 そのような人は「スタッフの肩書きさえあれば、チームのためにテクノロジースタックを決めることができるのに」 などと不満を口にする。 確かに、組織内で権限が増えれば、問題解決のために新しい手段を使えるようになるが、良好に運営されている組織において権限を保ちつづけるには、繊細な配慮や自制が多く求められる。あなたが何らかの問題を抱えていて、今の肩書きのせいでその問題を解決できないと考えているのであれば、肩書きなどよりもアプローチやスキルの向上に力を入れたほうがはるかに有益だと知っておいてもらいたい。」
-「フィードバックに反論しない。 重要なフィードバックがあっても、それをいつどのタイミングで伝えればいいのかをよくわかっていない幹部はとても多い。 あなたはフィードバックを求めているのであって、それをため込んで、 最終的には忘れられてしまっては困る。あなたがフィードバックに抵抗する態度を見せれば、幹部はコメントを控えるようになり、 あなたはそのミーティングから何も得ることができない。 つまり、フィードバックを集めることが大事なのであって、その内容にあなたが同意できるかどうかは関係ない。 そんなことはあとで時間ができてから考えればいい。 もし、あなたには同意しかねる決断が下されそうになったら、1つか2つ再考を促すデータを示すべきだろうが、それ以上はやめたほうがいいだろう。 会議中に抵抗を続けるよりも、 フィードバックについてよく考えて、のちに考えを変えるように促すほうが成功する見込みが高い。」
書籍情報
-スタッフエンジニア マネジメントを超えるリーダーシップ | Will Larson, 長谷川 圭, 増井 雄一郎 | 工学 | Kindleストア | Amazon
--https://www.amazon.co.jp/dp/B0C231J7FC?tag=nilabwiki-22&linkCode=osi&th=1&psc=1
-->ソフトウェアエンジニアが、マネジャーやCTOといったマネジメント職に進むのではなく、技術力を武器にテクニカルリーダーシップを発揮して、エンジニアリング職のキャリアパスを登っていくための「指針」と「あり方」を示します。
-->
-->「スタッフエンジニア（超上級エンジニア）」になるには
-->どんなスキルを身につければいいのだろうか？
-->技術的な能力さえあればいいのだろうか？
-->なった人は、具体的に何をしたのだろう？
-->その仕事を楽しむには、どうしたらいいのだろうか？
-->これらの疑問に答えるのが本書の目的だ。
-->
-->■「解説」から
--> 本書は2部構成になっており、第1部でスタッフエンジニアの役割とあり方を解説。第2部（おもに第5章）で現役のスタッフエンジニアのインタビューを通してその実像を掘り下げています。
--> 私のおすすめの読み方は、まず第5章のインタビューを2～3人分読んでから、第1部を読み進めることです。とくにある程度経験を積まれたエンジニアの方は、第5章に登場するスタッフエンジニアの具体的なエピソードに大いに共感されることと思います。その共感を胸に第1部を読むことで、スタッフエンジニアに求められる役割が自然と腑に落ちるのではないでしょうか。
--> 原書では14人のスタッフエンジニアのインタビューが掲載されています。いずれも個人的な経験にもとづいた具体的な内容で、これからスタッフエンジニアを目指す人にとって大いに参考になるでしょう。ただし、これらは米国での話であり、日本周辺での現状も気になるところです。そこで日本語版では、原著のインタビューに加えて、日本人のスタッフエンジニア4人に新たにインタビューし、貴重な経験とそれを支える志を明かしてもらいました。
-->
-->【目次】
-->■第１部 スタッフとして活躍するために
-->・第１章 全体像
-->・第２章 スタッフとしての役割
-->・第３章 スタッフプラスの肩書を得る
-->・第４章 転職を決断する
-->■第２部 スタッフたちの実像
-->・第５章 スタッフエンジニアのストーリー
-->・第６章 最後に
-->・補章 スタッフになるための情報源
-->・解説 by 増井雄一郎