メインコンテンツへスキップ

「スタッフエンジニアの道 ―優れた技術専門職になるためのガイド」を読んだ

· loading · loading ·
kiitosu
著者
kiitosu
画像処理やデバイスドライバ、データ基盤構築からWebバックエンドまで、多様な領域に携わってきました。地図解析や地図アプリケーションの仕組みにも経験があり、幅広い技術を活かした開発に取り組んでいます。休日は草野球とランニングを楽しんでいます。
目次

はじめに
#

以下の本を読みました。

スタッフエンジニアとはシニアエンジニアの先にあるキャリアパスということのようです。 具体的にはどのような役割で何をすればスタッフエンジニアになれるのでしょうか。

まとめ
#

日本だと最近はテックリードとか呼ばれる役割かも知れません。 テクニカルプログラムマネージャは、プロダクトマネージャと表現することが多いでしょうか。 どちらにしろ会社によって言葉は違うので定義はしっかりしておきたいですね。

書籍ではプリンシパルエンジニアとスタッフエンジニアの職位の上下関係を逆にしたような事例の紹介もあり、混乱しがちです。

手を動かすエンジニアとして生きていくうえで大事な心がけやキャリアの方向性を学ぶことができます。 新入社員の人にも参考になると思いますが、身にしみた理解や得るものは少ないかも知れません。 管理職を打診されるくらいの年齢になったときに、読んでみるとためになると思います。

仕事をする際の心構えもためになるので、定期的に読み返すと良い気がします。

気になった部分を整理します
#

スタッフエンジニアとは
#

個人的な理解は以下です

  • 管理職と並行した「技術専門職」
  • 部下を持たない遊軍的なエンジニア
  • 大局的に物事を見て局所最適化しないようにする
  • テクニカルプログラムマネージャは納品に責任を、スタッフエンジニアはシステムの堅牢性や技術に付いて責任を持つ
  • 誰かがなんとかしないといけないときの「誰か」になることが期待される人

心がけること
#

日々の心がけです

  • 自律的に動くことを心がける
    • 取り組むべきインパクトのある仕事が積まれた魔法のバックログはどこにあるのでしょうか?」。あなたが作り出すのです!
  • 注意点としてスコープが広すぎて、サブクエストばかりに追われる様になってはいけません。スコープを絞る必要があります
  • 高い機械費用がかかるため、あなたの仕事は重要なものでなくてはいけません。一つしか無い樽をプランターに使ってはいけないのです

必要な情報
#

地図を作る

  • トポグラフィックマップ:組織地図を作り、政治的な境界や、皆が避けようとしている気難しい人々などの危険な箇所を明らかにします
  • トレジャーマップ:目的地とそこにたどり着く目印を記します
  • ロケーターマップ:自分のスコープにおける仕事の微細な部分を学び、理解します

注意点
#

注意点に留意して仕事を続ける必要があります

  • 優先順位付けが不当になり、共感性が失われる
    • 周囲が気に掛ける問題が重要で他の問題はそれに比べ単純か重要でないと考えがちです。局所最適化を求めないようにするひつようがあります
  • 問題に麻痺してしまう
    • 何ヶ月も散らかった設定ファイルや壊れたデプロイプロセスを使って作業していると、それに慣れすぎて直すべきだという認識をなくしてしまいます
  • 仕事の目的を忘れてしまう
    • プロジェクトの目標が重要ではなくなったり、他の方法ですでに解決されていてもプロジェクトを止められなくなってしまう場合があります。

判断を下す
#

IETFの意思決定に関する原則(https://oreil.ly/x3Bds)です。これはすごくためになりました。

「王、大統領、投票」を否定し、「意見の不一致は合意よりも重要である」として、「ラフ・コンセンサス」と呼ばれるものを支持していることで有名です。つまり、集団の感覚を大切にはしつつも、全員の完璧な同意は目指しません。「選択肢Aで全員OKですか?」と尋ねるのではなく、「選択肢Aで我慢できない人はいますか?」と尋ねるようにしましょう。

今まで「選択肢Aで全員OKですか?」と聞いていました。そんなみんなの意見が揃うわけ無いですよね。

ADR(Architecture Decision Record)大事!

どのような決定を下すにしても、トレードオフを考慮し、最終的にその決定に至った経緯も含めて文書化しましょう。

業務遂行上の留意事項
#

がりがりと仕事をこなしたがって無理をしないと行けないと感じることがありますが、それはよくありません。

  • 限りある時間
    • 何かをはじめたら、その代わりに何をやらないのかを問うことで、優先順位を大事にしましょう。ビンパッキング問題とも言えますね。大きな瓶を入れたら小さな瓶は入りません。
  • どれくらいの忙しさが好み?
    • すべてのタスクをこなそうとするとストレスと疲弊を引き起こします。平均して週に何時間働きたいのか、何時間まで急増しても平気なのか把握しておきましょう。特に若いうちは無理をしがちなので、意識的に自分を観察するようにしたほうが良いですね。
  • 自分のニーズを大切にしましょう
    • チームプレイヤーとして健康で幸せな状態を保ち、スキルを向上させることで、会社もあなたを引き止めやすくなります。win-winです。
  • エネルギー
    • なにか有用なことをするにはエネルギーが必要です。ミーティングばかりの一日の終りにドキュメントを読む時間があっても頭には何も入りません。何が自分にとって高く付くのか、エネルギーを補給できるのか理解しましょう。

スキル
#

身にしみる!特にAI時代の今。すぐ陳腐化する。

スキルというリソースは他のリソースとは異なり、常にゆっくりと減少していきます。これは、知識を忘れるという意味ではなく(長い間使わない技術やテクニックは流暢さを失うでしょうが)、どのような技術スキルセットも徐々に関連性を失い、最終的には時代遅れになるという意味です。私たちの業界は速いペースで変化しています。何も新しいことを学べないプロジェクト(あるいは、希望するプロジェクトや役割に関連するものではないプロジェクト)を引き受けていると、技術が進歩するスピードにはついていけなくなってしまいます。

  • 意図的に何かを学ぼう
  • スキルが高い人と仕事を仕様
  • 実践を通じて学ぼう。磨きたいスキルを必要とするプロジェクトを引き受けるのが簡単な方法です

間食
#

ついつい間食しちゃう・・・

HomebrewのパートナーであるHunter Walkが、労力に対するインパクトをマッピングするために2×2のグラフを描いたことを説明し(図4-13)、労力とインパクトが低い象限に対して警告し、そのような仕事を「間食」と表現しています。このような仕事は手っ取り早く、役に立つ(そして気分がいい)傾向があるため、たくさんやることを正当化するのは簡単かもしれません。しかし、Traynorが指摘しているように、「短期的な問題を解決していると報われる感じがするかもしれませんが、身になるものを一切食べなければ、結局は苦しむことになります」。

プロジェクトについて自問すること
#

  • エネルギー
    • すでにどれくらいのことに取り組んでいるか
    • その仕事はエネルギーを与えるか奪うか
    • 先延ばしにしていないか
    • この戦いにそれだけの勝ちがあるか
  • 人生の質
    • この仕事を楽しんでいるか
    • プロジェクトの目標をどう感じているか
  • 信用
    • 自分の技術力をこのプロジェクトで活かせるか
    • このプロジェクトはあなたのリーダーシップスキルを証明するか
  • 社会関係資本
    • 会社や上司があなたのレベルに期待している仕事か
    • この仕事をすることで尊敬されるか
    • 築いた資本を浪費していないか

技術的な注意点
#

  • 設計する
    • ソリューションが3年後も機能するかを考えて設計しましょう
    • 後で必要になるかも知れない。は十分な正当化ではありません。必要以上に複雑な過剰設計には気をつけましょう
  • 難しい部分を放置しない
    • コスト・工数の関係で難しい問題を回避するために場当たり的な方法で仕事をすることがよくあります。組織が根本的な問題の解決に投資することを拒むのであれば、選択の余地はないかもしれません。しかし、少なくとも設計の中でそれを呼びかけるべきです。大きな問題の解決を妨げない方法で、小さな問題をどう解決できるかを考えましょう。
  • 些細な決定事項の議論をしすぎない
    • 議論が容易なために難しい問題よりも多くの時間をかけがちです。

有能であること
#

  • 知識を持つ
  • 自己認識を得る
    • 自分に何ができるか、それにどれくらい時間がかかるかをしり、「私がそれをやります」といえる能力
    • 知っていることを認める
    • 知らないことを認める
    • 自分のコンテキストを理解する
  • 基準を高く持つ
    • 自分のミスを認める
      • ミスを自分自身で解決するのは、チームの善意と社会関係資本を保持するためにできる最善のことです。うまく対応して問題を解決すれば、同僚からさらに尊敬されることになるかもしれません
      • リーダーが自分の間違いについてオープンにしていれば、他の人も同じことをしやすくなります。それは、チームの心理的安全性を大きく高めることに繋がります
    • 信頼できる
      • 始めたことをやり遂げることでも築かれます。その仕事に対する責任を引き受けたのなら、ゴールまで持っていきましょう。

オーナーシップを持つ
#

  • 決定を下す
    • 意思決定が必要なときは、尻込みしないようにしましょう。選択肢を検討し、決定を下し、その理由を説明してください。トレードオフを検討する際に自分自身と正直に向き合ってください。自分の好みに反してでも、最善とわかっている選択肢を選びましょう。
    • 間違えるリスクを受け入れることも含まれます。決定を間違えた際のコストをできるだけ低くするとともに、もし間違っていることがわかったら、それも自分の責任としましょう。
  • 「明白な」質問をする
    • 誰もが尋ねるのをためらっているような明白な質問をしましょう。(聞きづらいこともちゃんと聞こう)
  • グルーワークを引き受ける
    • ブロッカーの除去、オンボーディング、リマインダー、メンタリング、スケジューリングなどです。

落ち着きを保つ
#

  • 和らげる、増幅させない
    • 大きな問題に対処している場合は、それを小さくしましょう。小さな問題に対処している場合には、それを保ちましょう。誰かがあなたに問題を持ってきても、冷静にいてください。質問しましょう。相手がなぜあなたに話しているのかを理解しましょう。単に愚痴を言いたいだけ? それとも、あなたが行動を起こすことを望んでいるでしょうか。理解していると思っているトピックであっても、興味を示しましょう。問題がある場合は、それを認識してください。同じ情報を持っていても冷静でいるように見えるだけで、同僚の不安を和らげるのには十分かもしれません。
    • 問題があると認めるのは構いません。ですが、それについての心配を下位の人々に流出させないでください。彼らにあなたの懸念を背負わせるのは公平ではありません。彼らを動揺させることで、問題を増幅させてしまいます。
  • 避難をしない
    • 大規模な障害は高価なトレーニングコースです。どうせそのコストを払うのであれば、皆が何かを学んだ方が良いでしょう。誰かが間違いを犯したり、何かを壊すことでエッジケースを発見したりした場合には、その出来事について全員が安心して話せる環境を作りましょう。関心を持ち、非難するのを避けられれば、次のような質問がしやすくなるでしょう。
  • 一貫性を保つ
    • 予測可能な振る舞いをすることで、安全感と落ち着きを作り出しましょう。あなたに助けを求めるとどんなことが期待できるかを、同僚は知っているべきです。変化や困難の時期に、あなたがどのように現れて、仕事で自分をどう表現するかを伝えることで、同僚を安心させられます。変化はもちろん怖いでしょう。ですが、皆がそれを乗り越えている間、あなたが落ち着いていることによって、彼らはあなたを信頼できます。

以上
#

Reply by Email

関連記事

2025 09 14 VSCodeでLocalStack統合を使ってサーバレスとのテストを加速する
· loading · loading
AWS MCP SERVER使ってみた. core-mcp-serverのコンセプトは素晴らしい!が・・・
· loading · loading
AWS MCPサーバー ざっくりまとめ(READMEベース)
· loading · loading