こんにちは。虎の穴ラボのT.Hです。 オライリー・ジャパンより出版された「スタッフエンジニアの道」を読了しましたので、内容をご紹介したいと思います。

書籍情報

www.oreilly.co.jp

こんな人にオススメ

• コーディング中心の役割から、もう一段広い影響範囲へ移りたいミドル〜シニアエンジニア: 実装以外でどう価値を出すかの輪郭が見えてきます
• 肩書きや役職に関係なく、プロジェクト推進や育成、調整で価値を出したいエンジニア: 管理職とは違うリードの仕方が具体例つきで見えてきます
• 目標設定やキャリアの棚卸しに悩んでいる人: 今の自分に足りない観点を整理する材料になります

きっかけ

最近はコーディングエージェントが当たり前になってきたことで、コードを書くこと自体の価値は相対的に下がっていくのではないか、という感覚を持つことが増えました。 一方で、ではエンジニアはこれから何で価値を出していくのかと考えると、漠然とした不安ばかりが大きくなって、次に伸ばすべき力は意外とはっきりしません。

そんなタイミングで手に取ったのが本書です。スタッフエンジニアという肩書きの説明にとどまらず、技術者がコードの外側でどう組織に貢献するのかを具体的に考えさせてくれる一冊でした。

どんな本か

本書は、スタッフエンジニアという役割を「管理職ではないが、組織全体の成果に責任を持つ技術専門職」として描いています。ただし、その求められる役割は組織によって形が違い、万能の正解があるわけではありません。

全体は大きく3部構成です。

• 第I部: 大局的な思考
• 第II部: 実行
• 第III部: レベルアップ

構成はシンプルですが、単なる役割説明の本ではありません。 読み進めるうちに「自分は今どこまでできていて、何が足りていないのか」が自然と棚卸しされていく感覚がありました。 ケーススタディや具体的な行動例が多く、自分の仕事に置き換えて読みやすいのも特徴です。

そのため本記事では、全章を均等に追うのではなく、とくに印象に残った「組織全体の成果を意識する視点」「全体像を描くこと」「良い影響力の広げ方」の3つに絞って所感を共有します。

本書で学んだこと

1. 局所最適ではなく、組織全体の成果を取りにいく（第1章より）

第1章でとくに印象に残ったのは、「重要なのは手段ではなく、問題を解決することにある」という主旨の考え方でした。

私もこれまでは、与えられた課題をきれいに実装することにかなり意識が向いていました。ただ、本書を読んで、局所最適な実装が組織全体にとっての最適とは限らないという、「当たり前だが見落としやすい視点」を再認識しました。

スタッフエンジニアに求められるのは、コードを書くことそのものよりも、プロジェクトを進める障壁を見つけて取り除いたり、関係者の認識を揃えたり、仕組みで再発防止したりすることです。 レビューでフィードバックを返すことや、要件のズレを早い段階で見抜くことも、その延長線上にあります。

私にとって大きかったのは、この章を読んで「まだ大局的な見方ができていない」と自覚できたことでした。今後は実装依頼を受けたときに、単に作り方を考えるのではなく、「この要件は何を解決したいのか」だけでなく、「この実装が将来の改修にどう影響するか」まで踏み込んで確認する意識を持ちたいと思っています。

2. 全体像を描く力が、実装の前に必要になる（第3章より）

第3章のSockMatcherのケーススタディは、本書の中でもとくに印象に残りました。SockMatcherは「片方だけになった靴下同士をマッチングするサービス」を提供する架空の会社で、アーキテクチャの変更が必要だと感じたエンジニアが、過去事例の関係者や賛同してくれる仲間を集めて利害関係を調整し、無事リリースにこぎつけるまでがストーリー仕立てで描かれています。スタッフエンジニアがどの段階で何を考え、どう動いていくのかが具体的にイメージできます。

とくに印象的だったのは、技術的な正しさだけでは物事が進まないという点です。関係者を巻き込み、合意を形成し、全体像を共有した上ではじめてプロジェクトが動き出す。これは私自身も実感として持っている部分で、自分の仕事に置き換えやすい内容でした。降りてきた要件を実装するだけでなく、要件を決める段階にもエンジニアとしてもっと入り込んでいきたいと感じており、この章の視点はそのための足がかりになりそうです。

3. 影響力は「個人→グループ→触媒」とスケールさせる（第8章より）

第8章では、良い影響力の広げ方が「個人」「グループ」「触媒」の3つのレイヤーで整理されています。個人レベルは1対1でスキルを伸ばすこと、グループレベルは一度に複数人に届く仕組みを作ること、触媒レベルは自分がその場にいなくても影響が続くフレームワークや文化を育てること。この段階的な整理が、私にとっては納得感がありました。

とくに印象に残ったのは「ガードレール」という考え方です。本書では影響力の形を「アドバイス」「教育」「ガードレール」「機会」の4つに分けていますが、ガードレールはレイヤーごとの具体例がイメージしやすく、今の私の仕事にも当てはめやすいと感じました。

たとえば個人レベルのガードレールはコードレビューです。本書ではレビューの観点として、「この仕事は存在すべきか」「実際に問題を解決するか」「全体像に合っているか」「関係者が変更を把握しているか」といった項目が挙げられています。これは単にコードの品質を見るのではなく、1章で触れた「大局的な見方」をレビューという日常の仕事に落とし込む方法論だとも読めました。

コーディングエージェントが進化する中で、レビューのあり方も変わりつつあると感じています。解法の詳細はテストやAIに任せられる部分が増える一方で、「わかりやすいか」「全体像に合っているか」といった観点はまだ人間が担う領域です。この章の観点をベースに持っておけば、レビューの力点をどこに移していくべきかを判断する軸にもなりそうです。

グループレベルでは、1対1で教える代わりに手順書やルールを整備する手法が紹介されています。ただし、手順書を複雑にしすぎると抜け道を見つけて楽をしようとする力が働く、だから軽量さを重視すべきだという指摘には私も実感がありました。業界を問わず、ルールの複雑化が形骸化を招き、そこから事故が起きるという構造はよく見かけます。

まとめ

本書を読む前は、スタッフエンジニアという言葉に対して「花形の上位職」という印象を持っていました。常に大きなプロジェクトの先頭に立つような人がなるもの、というイメージです。

しかし、本書が描いていたのはもっと地に足のついたエンジニアの姿でした。組織の目標に対して必要なことを柔軟に引き受け、全体像を描いたり、周囲が動きやすくなるように仕組みを整えたりする。コードを書く力の先にそうした価値があるという視点は、読んでよかったと思える部分でした。

本書の内容をそのまま真似するというよりは、自分の組織や状況に合わせて選択し、部分的に取り入れていくのが良さそうです。 読む時期や立場によって刺さる章も変わってくるタイプの本だと思います。目標設定やキャリアの棚卸しのタイミングで、また読み返したい一冊でした。

採用情報

虎の穴ラボでは一緒に働く仲間を募集中です！ この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧ください。 toranoana-lab.co.jp