はじめに
この記事について
「Staff Engineer 」Will Larson の日本語訳を読んだのでその感想と、日頃から思っているソフトウェアエンジニアのレベル上げについて言語化しておきたいと思います。
本書が出るまではスタッフエンジニアという役職は聞いたことがなく、日本語でスタッフというと「職員」みたいなニュアンスがあるので、言葉だけではピンときませんでしたが、本書を読んで、ぼんやりと思っていた自分の目指す場所（職位としてのポジションではなく）が明確になったような気もするので、毎度のことながら雑に書いていきます。
スタッフエンジニアとは
このスタッフエンジニアという役職は、そのエンジニアとしてのキャリアの延長線上で、この本はシニアエンジニアを超えた先にどんなキャリアがあるのかを解説している本になります。
スタッフエンジニアとはただの役割ではない。個人の役割と行動とインパクトの、そしてそれらすべてに対する組織の認識の総体なのである。
Will Larson. スタッフエンジニア マネジメントを超えるリーダーシップ (Japanese Edition) (p. 22). 日経BP. Kindle Edition.
英語が苦手でなければ、下記のサイトで本書に書かれているほぼすべてのコンテンツが読めます。
ソフトウェアエンジニアの役割と水準
私はフリーランスなので肩書にはまったく興味はないんですが、肩書と役割は重なる部分が多いですし（役割がこなせない、あるいはこなせそうもなければ肩書もつかないし、役割が果たせれば肩書もついてくるものと思っています）、役割の土台にはスキルがあるはずで、そういった意味では、どんな立場であれ、自分の役割（ロール）と水準（レベル）には常に気を配っていたい、という思いがあります。あまり関係ないですが、私はゲームが好きで、RPG もちょくちょくプレイするので、仕事においてもそういう見方（ロールとレベル）をしてしまいがちです。
冒頭に引用した著者の言葉にもあるとおり、スタッフエンジニアはただの役割ではなく、まずそれを求める組織の組織としての有り様があり、行動のインパクトも含むということなら、業務委託のフリーランスであってもスタッフエンジニアらしきものとして振る舞うのは十分可能なのではないかと思っています。もちろん責任や覚悟みたいなのもセットで。
いまの自分の水準としては、個人の成果として期待された仕事をこなすという点であればほぼ100％満足のいく結果が得られ、チームの成果を向上させるという点では短期的にはうまくいくことのほうが多いが、中長期的にメンバーのマインドセットを変えたり、自分が抜けたあとも自律的に発展させていけるような風土づくりとか制度づくりまではできていない、といった感じです。基本的に1年以内、長くても2年の契約がほとんどなので、そんな短い期間でできることは限られるかもしれませんが、少しでもインパクトを出したいとは思っています。
スタッフエンジニアの職務領域と適正
自分にとってフィットするのはソルバー、アーキテクト、テックリードの順かなと思いました。客観的にみて自分は自主性はそこそこあるほうだとは思いますが、人望はないほうだと思うので、3つの中でもっとも人を巻き込む必要のなさそうな課題解決がいちばんフィットしそうです（自分の人望のなさがどこから来るのか、というのはいずれ解明したいと思いつつ、いまはひとまずそれ前提で生きています）。
といっても、この領域になると人を巻き込む必要のない仕事というのはゼロに近くて、そもそも求められることが個人の成果以上にチームの成果になりますから、自分にとっての最大の課題はそこら辺だな、とぼんやり考えています。
幸い25年もソフトウェアエンジニアをやっているせいか、必要最低限は人とのコミュニケーションも昔よりはうまくできるようになってきているようで、アーキテクト、テックリードあたりもなんとかがんばればこなせるんじゃないかという気もします。RPG 的にいうと MP 高め、HP 低めの魔法使い＋武闘家＋戦士、みたいな感じです1。
Microsoft Copilot とスタッフエンジニアについて会話していた中で面白いことを言っていて、以下のコメントがとくに刺さったので抜粋します（余談ですが、ChatGPT や Microsoft Copilot と会話するときは、英語の学習も兼ねてすべて英語でやりとりするようにしています）。
Staff Engineers often thrive when they have the autonomy to shape their work, contribute meaningfully, and drive technical excellence.
自律的に自らの仕事を定義し、インパクトのある貢献をし、技術的な向上を牽引することが鍵になる、ということです。
前述のとおり、私は業務委託として組織の末端に位置することがほとんどなので、第一に求められることはプロダクトを作り上げることであるのは間違いなくて、自分としてもそこは外したくないというか、口だけ出して手を動かさないのは性に合わないので、そこは前提として確保しつつ、ベテランとしての自分に求められることは個人の成果に加えてチームの成果をどれだけ高められるか、というのもあると思いますし、行く先々の現場で、放置されている問題を分析し解決することに対する喜びもあるので、どんな仕事をするにせよ、スタッフであること、スタッフとして認められることは常に目指していきたいです。
レベル上げ
本書にはスタッフエンジニアに必要なスキルや態度についての提言がたくさんありますが、自分にとってポイントになりそうな部分を箇条書きにしておきます。
- 成長を促す
- 文書化
- 上司を決して驚かせない
- リードするには従うことも必要
- 他人のスペース（余地）を設ける
自分にとっての課題はコミュニケーションで、短期的な成果を求めて、リーダーやメンバーがどのように感じているか疎かにしがちなので、もっと対話する機会はほしいとは思っています。オンラインで働いているのでなかなかそういう時間が取れないのが悩ましいです。立場的には末端兵士なので、トップダウンの手法も使えず、リーダーを立てつつ、さり気なく提案して、うまいことコミュニケーションの機会を増やすような動きができれば、レベル上げへの道が拓けるかもしれません。
避けるべき3つの態度
「第2章 スタッフとしての役割」の中で挙げられていた「前進を阻む一般的な障害」について、自分への戒めも込めて言及しておきます。
- スナッキング: 簡単でインパクトの弱いものを選ぶ態度
- プリーニング: インパクトが弱く、しかも目立つ仕事をすること
- ゴーストチェイシング: 前職での状況というゴーストにとりつかれたまま新しい会社を理解しようとする
3 はちょっと補足が必要かもしれません。
新しくチームに加わったシニアリーダーが冒しがちな間違いとして、入ったばかりなのにこれまでの経験に基づいてそのチームやプロダクトの課題を決めつけ、間違った解決策を早計に適用してしまうことです。主にテックリードやアーキテクトの役割に秀でた人がやりがちかもしれません。
上記3つはどれも回避するのが難しいと感じます。自身を振り返っても、とくに参画した直後は成果を求めがちになるので、簡単かつ目立つ仕事に手を出しがちかもしれません。
ちなみに、「目立つ」とは原文では「high-visibility」となっていて、見た目だけインパクトが大きい、と解釈できそうです。プリーニング（preening）はもともと鳥がくちばしで自身の姿を整えることという意味らしいので、見栄えだけよくて実質が伴わないのはダメですよ、ということだと解釈しました。
個人的には、最初からいきなりインパクトのある成果は出しづらいので、周縁の小さな問題から片付けて、徐々に大きな課題に取り組むのがいいと思っていて、成果を認めてもらい信頼を得ることで、相談してもらえるようになり、相談事を解決することでこちらからも提案できるようになり、さらに大きな成果を上げられる、という良いループに入ることができるんじゃないかと思います（あくまで理想ですが）。
おわりに
本記事で取り上げたもの以外にも示唆に富んだ提言がいくつもあったので、ときどき読み返したい本になりました。
フリーランスである自分にとってキャリアパスというのはほとんど意味がありませんが、組織の中で求められる役割や出せる成果については常に考えているので、こうして新たな道筋が示されるのはありがたいですし、日本のソフトウェア開発組織において昇進や昇給のためにはマネジャーになるしかない、みたいな制度や文化はあまりいいことだとは思っていないので「スタッフエンジニア」が一般的になるといいなと思います。
