Principal Engineerが読む「スタッフエンジニアの道」

オライリーから出ている「スタッフエンジニアの道」を @riywo さんを通じてご恵贈いただき、第1部と3部を読み終えてしずかなインターネットに書評を書いたのがおよそ一年前、そこからさらに1年かけて第2部を読み終えたので感想である。1年前に読んだ文は最後の方に貼っておく。

Amazon.co.jp: スタッフエンジニアの道 ―優れた技術専門職になるためのガイド : Tanya Reilly, 島田 浩二: 本

私は、Principal Engineerとしてコードを書くハンズオンだけではない数々の仕事をこなしてきている。自分はMLを使った製品開発のTech Leadとして、チームメンバーを育てながらロードマップを切り開き、またリーダーシップからのプロジェクトの投資を継続してもらうようにスポンサーになってもらう活動を続けてきている。

この本では、先達たちの「こうしてきた」エピソードや実例、どのような考え方をもとに動くべきかといった試行錯誤を書き連ねた本だ。どのように考えて自分にとってそして会社にとっても重要なプロジェクトを選び、スポンサーを獲得し、メンバーが助けを求めていれば西へ東へ奔走し、求めていなくても助けに行き、プロジェクトが進むためにあらゆることをする、そういったStaff+と呼ばれるエンジニアに向けての、実例集である。

なので、体系立てようとしても厳しい。なんだけど、ふた昔前のEngineering Managerが何をするのかわからん状態のように、Staff+ Engineerが何を期待されているのかわからん問題というのがあるので仕方がない。これは、会社やそのステージによって、Staff+に求められる役割が全然違うのである。本書を読んでいると、「Staff+はコードは書いてもいいがクリティカルパスはお前がやるな」と書いてある。ちゃんとほかの人に委譲できる体制を作らないといけないのである。

この本の見どころは、第2部がプロジェクトをどう進めるか、そして進まないときはどうするか、みたいなことが書いてある。これが良いのである。ただし、胃が痛くなるので心が健康なときしか読めない。なので、読み進めるのに1年かかった。

また、チームメンバーやProduct Leadershipが総入れ替えみたいな出来事が数回ほど起きる中でのチームメンバーの育成はなかなかヒリヒリする仕事であった。そんな時にもこの本は役に立つ。どうやって、チームメンバーに適切な仕事を与えたりモチベーションアップをしたりするのか、そういうことも書いてある。

高機能雑用になりがちなStaff+が、心のよりどころとして使える本である。プロダクトマネージャーが「どうしてあなたは一人月分コードを書かないのですか？」と聞いてきたときに、ちゃんと反論できるようになるわけである。「オライリーの本にも書いてあったけどね、誰かが戦略的な意思決定を進めていかないといけないんです。で、コードも片手間に書いているけど、私がブロッカーになってはいけない、そういうことも書いてあるんです。」天下のオライリー印を使うのだ。

私は社内のPrincipalの中でも、比較的戦略的・政治的な振る舞いが求められることが多く、今はSr Engineering Directorの助けを借りたり、外部からの玉を打ち返せるような支援をするみたいなことをしている。

そういう時に、自分と同じようなことをしている人が少ないこともあり、どうしても孤独になりがちでGeminiと無限に壁打ちをするみたいなことが発生する。しかし、書籍は（ある程度盛っているかもしれないが）生きた人の爪痕であり、大変に支えになるのである。

: そう、どうやったらCTOに投資を継続してもらえるかとか、なぜMLが会社にとって重要なのかを何度も何度も説明する仕事である

そんな迷えるソフトウェア業界のStaff+ Engineerにお勧めの書籍である。

最後に、過去にしずかなインターネットに書いた書評を貼っておく。興味がある方は読んでみてほしい。

終わり

@riywo さんからご恵贈いただいて、前々から積んでいた「スタッフエンジニアの道」を冬休みの課題図書よろしく読み進めている。

本当は、きちんと読み終わってから感想を自分のブログにでも書こうと思っていたのだが、読んでいるうちに色々と思うところが増えてきたので、dumpしておこうと思う。

この本は、いわゆる"Staff+ Engineer"と呼ばれるIndividual Contributor (IC) の上級職にまつわる話である。順番は色々あれど、Junior, Intermediate, Seniorの上に来るものという位置づけであると本には書いてある。

なお、Staff+がSeniorより「偉い」というわけではないのは、以下の本書の脚注で書かれている筆者の好きなSeniorの定義からもわかる。

「昇進するのを止め、現在の生産性、能力、アウトプットのレベルをキャリアの残りの期間継続しても後悔のないレベル」

ただ、Staff+と呼ばれるこのポジションに関する書籍がいろいろと出てきているのは理由がある。この本をいただくきっかけになったriywoさん、wataru さんとのご飯のきっかけにもなったのだが、Staff Engineer以降になると会社によっても何をやってるかばらばらになるし、道を見失いがちになるのである。

かくいう自分も、春(注: 執筆当初2024年)にPrincipal Software Engineerにpromotionしてからというものの、やっていることは変わらないと思いきや、プレッシャーは増えて責任範囲も順調に拡大してきて、道を迷いそうになりながらも踏みとどまっているのが現状である。

Staff+が何をするのかというといろいろと書いてあるのだが、「大局的な思考を持ち、大きなプロジェクトを実行し、よい影響を与えるようなことをする」というのがざっくり良いまとめであると感じる。そのため、

戦略を立てたり、プロジェクトを立て直したり、標準を設定したりしている時間には、コーディングや新しいシステムのアーキテクチャを設計したりといった、ソフトウェアエンジニアとして評価されるような多くの仕事はできません。

という事実にも直面する。自分の与えられる影響を大きくするには、コードを書くことも大事だが、そうではない取り組みも大きい。これは、ステークホルダーが多かったり、重要度の高く困難なプロジェクトを割り当てられるのも大きい。

そう、結局は重要な技術的課題を解決するためになんでもやるのだ。こういうと、「高機能雑用」のある種正統進化だなあともさえ思えてくる。

当然、コミュニケーション力とやらも求められる。ラダーの上の方のエンジニアの機会費用は高いから、ちゃんとVPなどのサポートを得て(得続けて)、やるべきことをやりましょう、という話である。

これはある種の社内政治だなあ、うーんと思っていると、見透かされたように言われる。

エンジニアは時々、組織に関するスキルを「政治的なもの」として軽視することがあります。しかし、システムの一部である人間を考慮し、解決べき問題を明確に理解し、長期的な結果を把握し、優先事項についてトレードオフを行うといったスキルは、優れたエンジニアリングの一部です。自分の組織をどのようにうごかすかをわかっていなければ、あらゆる変革がはるかに困難になります。

そう、ゲームのルールが変わってきているのを直視しないといけないのである。今まではランダムエンカウントのターン制RPGをやっていたと思ったら、リアルタイム性が高くなってきた戦略シミュレーションになっていたのだ。それを示唆するように、本書でも霧のある戦争マップの中でマッピングせよ、みたいな話が出てくる。あー、FEの索敵マップね。社内の色々な関係者のマップ書いたり、プロジェクトのゴールに辿り着くまでのマップ書いたり、それを更新し続けたり。

これらは、ある意味では(大企業で大嫌いだった)社内政治とどう向き合うかという話に他ならない(そしてそれはData ScientistもSoftware Engineerも変わらない！)。結局は、ビジネスの営みはステークホルダーが色々といて、重要度が上がれば(予算がつくつかないは別にして)出てくる口の数は増える。そういう中では、今いるチームのアーキテクトとマネージャーとで週次である種の「現状認識会」をできていたのは、よかったのかもしれない。この間辞めたCXOのプロジェクトへの影響は、隣のプロジェクトにPdMのリソース持ってかれてる、などなど本書で言うところの、トポグラフィーマップを更新し続けていたのだ。

ある種の社内政治は、日本、アメリカ、エンプラ、スタートアップを問わず、どこでも発生しうる、というのは過去の経験でも感じていたし、Will Larsonの本でも言及されていた。

Amazon.co.jp: スタッフエンジニア　マネジメントを超えるリーダーシップ: Will Larson, 増井雄一郎, 長谷川圭: 本

これ以外にも、技術ビジョンや戦略の立て方の話、他のメンバーのロールモデルになる話、どうやってリーダーシップを発揮するのか、みたいな話が本書には書かれており、自分の通ってきた道と過去の失敗の反省をしながら読んでいる。しかし、自著の「仕事ではじめる機械学習」もそう感じていたが、痛い目を見てはじめてわかる書籍に書かれた事の重みというのはあるのだなあ、と痛感する。

また、自分が直接の部下ではないが、MLチームの技術リードをすることになった関係で、色々ともがいた年でもあった。いかにチームを回るようにして、タスクブレイクダウンをし、そして来クオーターの計画を立てるのか。ある種のTLM的な感じでICのモチベーションを最大化するのに心を砕いたり、色々とはじめての挑戦も多く、正直に言って今までの経験があまり生きない一年だった。

そんな中本書を読むと、シニアに対するメンタリングで何ページも書かれていたのは、不要なアドバイスをしてはいけない、何を求められているかを解きほぐすのに労力を割くべきだし、アドバイスをしたくなったら(センシティブな情報は抜きにして)ブログやsocial mediaに書くのがいいだろう、と書かれている。耳が痛いなと思いながら、この文章をdumpしたのであった。