マネージメントを超えるスタッフエンジニア備忘録

はじめに

マネージメントを超えるスタッフエンジニアの備忘録

エンジニアのキャリアラダーはシニアから分岐していく

一般的に企業のマネージャーのラダーはよく定義されていていて分かりやすい一方でスタッフプラスのラダーは不透明なことが多い。
本書ではスタッフプラスについて深掘りし、実際にスタッフプラスとして働くエンジニアにインタビューして答え合わせをしている。

スタッフプラスの典型的な４パターン

スタッフプラスの定義が難しいのはその企業によって定義が異なるから。
著者はだいたいこの４パターンに分類できたとしている。

• テックリード
  • タスクの着手と遂行において１つのチーム（複数も）を率いる
  • チームを成功に導くためにチームの置かれた状況を把握し、チームor部署間の関係維持を努める
  • 最も多いタイプ
    • チームにとって最も複雑な技術プロジェクトをやり遂げたものがなるのが多い
    • アジャイルを持ち込む組織においてエンジニアが移行しやすいロール(チームのパフォーマンスという点を重視するため)
  • コーディング量は減りがち
    • チームに任せることがチームの成長につながるインパクトが増えることを理解している
    • 一方でチームのビジョンを決める中心人物であるため、複雑な問題に取り組む役割を担う
• アーキテクト
  • 重要分野において、方向性や質、あるいはアプローチに責任を負う。技術的な制約やユーザーのニーズ、組織レベルのリーダーシップに関する深い知識を組み合わせる任を負う。
  • 単独でシステムをデザインし、その実装を他人に押し付ける人物というものでは決してない点に注意
  • 比較的大きな会社において、複雑だったり結合型のコードベースになるサービスのデザインで力を発揮する
  • 初期のスプリントで生じた技術的負債の返済に苦心する組織においても力を発揮する
• ソルバー（解決者）
  • 任意の複雑な問題を深く掘り下げ、前進する道を切り開く。長期に１つの分野に携わる者もいる。一方で、ホットスポットを転々する者もいる。
  • 組織が高優先と判断した課題に取り掛かるためコミュニケーション障壁がない
  • チームではなく個人として仕事を担うことが多いので、スプリント中心の企業ではソルバーはあまり見かけられない
• 右腕
  • 会社幹部の関心を代表し、幹部の能力と権限を借りて複雑な運営に当たる
  • 大規模組織における経営陣のリーダーシップを社内に広げる仕組みを担う
  • コードレベルで作業することはない。ビジネス、技術、人、文化といった複数の要素を鑑みて最適解を模索し、現場に権限委譲して、次の鎮火に向かうという動きをする
    • 解決のその場に立ち会えないが、かなり複雑な案件の解決を任される

談話気になりメモ

Stripe社

• 毎日必死に仕事をしてテクノロジーの構築とサポートを行っているのは自分ではなくチーム。チームの前進、その前進の方向性、さらに言えば会社の目的とチームの進む方向が一致していることが自分の成功の尺度
• 理想的なアーキテクチャやインターフェイスへの移行は個々のチームが行うべき課題であり、各チームが当事者と実行能力を持たないといけない
• 成長要因
  • Tech成長要因：自分の技術力に隙間があり、携わっているPJでその隙間を埋める努力をすること。今の自分の能力よりも少し高いレベルを要求するPJに果敢に挑戦すること。
  • ソフトスキル成長要因：全社にコネクションを持つ、ユーザーに重点をおく、プロダクトを深く理解する
• スタッフプラスエンジニア要素
  • 何かを作ってリリースするだけでは駄目
  • 後に後悔する点をできるだけ小さくして、スムーズな成長を促し、長続きする成功と成長を可能にする
  • プロダクトと技術を意図的に選び、ユーザー視点から最善の選択を心がけ、未来のエンジニアのために問題を徹底的に文書化するのが努め

MailChimp社

• 自分の業績評価を三人称で書く
  • 他人について評価を書くと批判よりも称賛の方が多くなるから
• 会社全体の人々と友好な関係を築くこと
  • エンジニアリングは人や社会と切っても切り離せいないもの
    • 人間関係こそが仕事を成し遂げる鍵
• 他のエンジニアのための技術的な方向性をしっかりと設定する
  • 次に指導しながら対象者のために構築した仕事の延長として才能を伸ばす
    • チームのスキル拡大、多くを学べる機会を生む

fastly社

• プリンシパルエンジニアという肩書の使い方
  • 信頼があるので自由な時間を持てる。自由な時間の中で何かを試すことができる。
  • 信頼を得るために多くのエネルギーを費やす必要がない
  • 他の人も自分の立場を加味して意見を受け入れやすくなる
• リモートワークは意図的に人間関係を構築する努力をしなければならない
• キャリアのランクが上がるに連れて孤独になるので、社内外で仲間を見つけよう

slack社

• スタッフエンジニアとしての貴重なスキル
  • 一緒に働きたいと思われるエンジニアを目指す
  • 他人を信頼して技術的な決断を下す自由を与えられる
  • 人のモチベーションを理解する
  • 論争するタイミングを見極める
  • 難しいフィードバックを与える方法を学ぶ
• 多くの会社ではマネージャーの昇進プロセスの方がエンジニアよりもはっきりしている
  • それはエンジニアリングのラダーが上がれば上がるほど手本は少なくなり、実現難易度が格段に上がるから
    • プログラミング言語やフレームワークなどの開発実績など
    • だからエンジニアとしての路線を見切るという話ではない。マネージャーのカレンダーを見てそのスケジュールで仕事をしたいか？という目線で確認すると良い。

Dropbox社

• スタッフエンジニアは2種類
  • スペシャリスト
    • 何かの技術に特化した人
  • テックリード
    • チームのために数多くの調整やデザインワークを行いプロジェクトを推し進める人
    • メンバーの成長を促しながらプロジェクトを完了に導くためにチーム内でどう分配するかを考える
    • コミュニケーションを管理
    • 難しい部分を自分でやるのではなくチームに任せる
    • 組織の成長に関与(面接のデザイン、候補者の選別)することが楽しい
    • 自分が正しいと思うことを押し付けず、あくまで誘導する
• スタッフエンジニアになるには、スタッフプロジェクトを完遂する必要がある(組織から認められるために)
• 上司には自分の希望するキャリアをオープンに誠実に伝えること
  • 上司が聞きたがっていることばかり話すのは誤り(なぜなら上司側は部下の成長機会を探っている。自分の可能性を広げてくれるためにはオープンに話すことが大事)

slack社

• 問題でストレスを感じたり、自身をなくしそうになった時は考え方を変えて、今まさに自分は成長しているんだ、成長の機会が沢山あるエリアに足を踏み入れたと理解すること
• ICは成果を出すのは簡単。理由は手を動かして実行することで成果を表面化できるから。難しいのは組織に変化やインパクトを促すこと

Squarespace社

• スポンサーシップの大切さ
  • ランクの低いチームメイトに大規模な会議で自分の仕事について発表する機会を与える
  • 優れた機能を納品したばかりのチームに声をかけて、エンジニアリングブログに記事を投稿させる
  • コーヒータイムで出会ったユニークな経験や考え方を持つ人に社内プレゼンをするように勧める
  • 会議では声の大きい少数派に支配されないように参加者全員から意見を集める
  • 素晴らしい業績を上げたのに誰からも気づかれていない人がいたらたくさん人が集まるところで称賛する

Split社

• ほとんどの会社はマネージャー職とスタッフプラス職が多くの点で重複している
  • どちらも人を指導したり、率先したり、説得したりする力が必要
  • そして地位が増すとこれらの重要度が高くなっていく
• 自分の長所を伸ばすという戦略
  • 人は短所を改善しがち。理由は欠点が改善されると前進したと感じるから。
  • 一方で、短所の改善には多くのエネルギーが必要になる
  • 長所を伸ばすことで短所が小さくなるのであればそちらの方がエネルギー戦略として効率的

Auth0社

• 上級職では仕事の成果が現れるまで時間がかかることを理解する
  • 一度に取り組む仕事の数は増えるが、時間が経たないとそれらの影響は現れない
  • 焦らないこと、長期的に見返りが得られるというマインド
• 物事を書き留めて人に繰り返し伝える
  • 考え、計画、理由、基準を書くことで成長する