「スタッフエンジニア」は受託開発でも役立つ良書でした

「スタッフエンジニア マネジメントを超えるリーダーシップ」の本を読んだので感想を書きます。

書籍について

最初に、この本の概要について書きます。

まず、この本で言われている「スタッフエンジニア」という言葉の定義は以下の図のキャリアパスから来ています。 書籍内では「スタッフエンジニア」または、それ以上を「スタッフプラス」という用語で統一して利用されています。

図は書籍より引用

この図に示されるような多様なキャリアパスは、人事関連の書籍を読んでいるとよく目にする内容で、特に珍しいものではありません。

ただ、この本の序盤に、書籍の目的に関する以下のような文が記されています。

テクニカルリーダーシップのキャリアパス(職歴の道筋)には不明瞭な点が多く、スタッフプラスは何をするのか、という一見シンプルな問いにさえ、答えるのが難しい。スタッフエンジニアになりたいと願うシニアエンジニアは、どんなスキルを身につければいいのだろうか? 技術的な能力さえあればいいのだろうか? 実際にスタッフプラスになった人は、何をしたのだろう? この道を進みたいエンジニアを、マネジャーはどうサポートできる? スタッフエンジニアの仕事を楽しむことができるだろうか? それとも、自分に合わない役職に就いたことに何年も苦しむことになるのだろうか? そうした疑問に答えるのが本書の目的だ。

マネジメント側のキャリアについては様々な書籍が存在し、書籍やウェブだけでなく、周りの同僚などを含めても情報は豊富にあります。しかし、「スタッフプラス」に関する役職の人々が日常的にどのようなことをしているのかについては、一元的な情報が確かに少ないと感じます。

技術寄りの経営職やマネジメント職には、CTOやエンジニアリングマネージャーのような役職がありますが、「スタッフプラス」はそれらとは異なるキャリアとして紹介されています。

私自身、技術を中心としたキャリアを積んできたつもりですが、このキャリアパスにはまだ明確でない点が多いと感じています。知らぬ間にここまで進んできましたが、後輩たちにアドバイスする際、自分の歩んできた道が実際に役立つものなのか確信が持てないのが正直なところです。

絶対的な正解が存在しないとしても、このキャリアを整理し、言語化してくれたことに、まずこの書籍の意味があると個人的には感じます。


書籍の構成としては以下の目次に沿って第一部では「スタッフプラス」としてやっていくために必要とされることが書かれています。第2部は実際の「スタッフプラス」のエンジニア向けのインタビューという内容になっています。

■第1部 スタッフとして活躍するために  
- 第1章 全体像  
- 第2章 スタッフとしての役割  
- 第3章 スタッフプラスの肩書を得る  
- 第4章 転職を決断する  
  
■第2部 スタッフたちの実像  
- 第5章 スタッフエンジニアのストーリー  
- 第6章 最後に  
- 補章  スタッフになるための情報源

自分について

感想書く前に、視点を明らかにするために自分について少し言語化しておきます。

職歴

私の職歴は、受託開発から自社サービス開発を経て、再び受託開発に至るものとなっています。また、副業としてスタートアップでのアプリ開発も経験しました。所謂WEB業界、特に自社サービス開発を経た後に受託開発に戻るというキャリアは、少数派だと思っています。

受託開発のデメリットはWEB上でしばしば指摘されていますが、私の経験としては、ほぼ100%リモートワークで、エンドユーザー向けの案件を中心に、複数のお客様と同時に関わりながら、技術的にも最新のツールや面白いプロジェクトに携わることができています。

今の立ち位置

現在所属している会社にも多様なキャリアパスが存在し、呼称は異なりますが、書籍に記載されているキャリア図と似たマネージャーとスペシャリストの2つのキャリアが設定されています。私は、その中でスペシャリスト側のキャリアの一番上の職位に就いています。

スペシャリスト側にはいますが、3人のチームのラインマネージャーではあり、売上数字の責任も持っています。ただ、チームメンバーも書籍で言う「スタッフプラス」であり独立して動かれているので、私のやっていることと言えば1 on 1でのコーチングがメインとなり、所謂マネジメントとは違うと感じています。(ちょうど、書籍でも同じような立場の人が出ていました。)

読んで良かった点

自分の仕事が言語化されている

自分の仕事は、この書籍の定義で言う「スタッフエンジニア」であると思っています。

自分の仕事とは何なんだろうと思うときがあります。他人に説明する時もありますが、そういう時には相手に合わせて見えやすい断面で説明してきてしまった気がします。経営側には経営側からわかりやすい断面、エンジニアにはエンジニアにわかりやすい断面を説明すると言った感じです。

この書籍では、「スタッフエンジニア」の仕事を何とか言語化されようとしていると感じました。

わかりやすい箇所としては、以下のスタッフエンジニアの一般的なアーキタイプなどがあります。

テック リード

与えられたチームをアプローチや実行へと導く。通常は特定のマネジャーと密接に連携するが、ときには2人もしくは3人のマネジャーと協働するすることもある。「テックリードマネジャー」という役職を設けている会社もある。テックリードマネジャーはテックリードの典型に似ているが、テクニカルリーダーシップではなくエンジニアリングマネジメントの役職であり、マネジメントの責任を負う者が就く。

アーキテクト

重要分野において方向性や質、あるいはアプローチに責任を負う。技術的な制約やユーザーのニーズ、あるいは組織レベルのリーダーシップに関する深い知識を組み合わせる任を負う。

ソル バー(解決者)

任意の複雑な問題を深く掘り下げ、前進する道を切り開く。長期にわたって1つの領域にのみ携わる者もいる一方で、組織のリーダーシップの導きに応じて、ホットスポットからホットスポットへと跳び回るソルバーもいる。

右腕(ライトハンド)

補佐役として会社幹部の関心を代表し、幹部の能力と権限を借りて複雑な組織の運営にあたる。大規模組織において経営陣のリーダーシップを広げる仕組みだと言える。

※ 書籍より引用

もちろん、世界の全てのパターンを網羅するのは非現実的かと思います。それでも実際の現在の自分の仕事がそれぞれマッピングできて、とても上手く言語化しているなと思いました。

例えば自分の場合は4つのアーキタイプのどの面もバランス良く持っているのかなと感じています。スタッフエンジニアの中ではジェネラリストということでしょうか。きっと人によってはアーキテクトの割合が多い方とか、ソルバー一筋とか特色が出るのではと想像しています。

そういう視点が得られたりするので、上手く言語化されたものを読むことは気付きが多いです。

リアリティがある

技術で食べてる「スタッフエンジニア」ですが、この本では技術だけでは難しいという点についても触れられています。

技術を主軸に置きながらも楽しくインパクトの残せる仕事の選び方、経営やマネージャー側との関わり方、自分の表現の方法など、社内での立ち回り方などについて書かれています。そこには泥臭さというかリアリティがある気がします。

自分を振り返ってみても、好きな技術を主軸にするために、自分なりに色々工夫しているなと頷きながら読みました。

受託開発でも役立つ

上述の通り、今の会社は受託開発を主なビジネスとしています。 その中でも自分は世に言う内製化支援や伴走型みたいな案件を中心に取り組んでいるのですが、目指しているのは顧客のチーム内で「スタッフエンジニア」の役割を担うことです。

自社開発の企業も経験していますが、経営やプロジェクトなどマネジメントで成果を出すのではなく、技術を中心に置いて成果を出すという方向性を採るなら、本質的には必要とされるものは大きくは変わらないなと思っています。

少なくとも自分が普段お客様と接している時に考えていることが多く書かれていました。

最後に

二つの文を引用して締めたいと思います。

スタッフエンジニアは序列としてはシニアエンジニアの上に位置しているが、役割はまったく異なっていて、以前にはほとんど、あるいはまったくやったことのない仕事に多くの時間を費やすことになる。


スタッフエンジニアは、優れたシニアエンジニアという位置づけではない。スタッフのアーキタイプのどれかを満たすために昇進した者がスタッフエンジニアになるのである。

両方とも本当にそうで、自分より技術的に上の人はいくらでもいる。。。それどころか150人程度の小さな会社でも自分が一番のスキルは何も見つからない。

そのくせに、自分としてはコードを書くのが好きだし、新しい技術を追ったり好きなことをする時間を減らしたく無いです。技術を中心に置く仕事を続けたい。そして当然報酬も上げたい。この時点でかなり欲張りだと思っています。受託開発の場合は特に人月ビジネスという観点から、個人の売上数字という成果にはキャップができやすいと思っています。(仮に100万/月の単価のエンジニアの10倍の成果を出せるエンジニアがいたとして、エンジニア個人に1000万/月の単価が出る現場は例外的と思っています。更にエンジニアスキルに関係無い側面から見ても10倍の成果が出せるタスクが継続的に存在するかと言うとそれも難しいと思います。)

だからこそ面白い仕事を選択していくためとして、準備や工夫を惜しまずにやってきて、それなりに評価を受けられるようになったのは確かです。ただ、そこには技術だけでは食べられないという技術者としての大きな劣等感がありました。

この本に出てくるようなエンジニアの人でも、自分と似たようなことを考えたりしているのかなというのが見て取れたので、心のわだかまりや劣等感が和らいだ読書体験でした。