“テックリードという役割”のその後 — Will Larson “Staff Engineer”
Will LarsonのStaff Engineerを読んでいます。
この本は大きく前半と後半にわかれていて、著者によるStaff Engineerの職務内容・昇進・会社選びなどに触れた前半、”Stories”と章立てされたStripe・Slack・FastlyといったTech企業で働く14人のインタビューを掲載した後半の構成になっています。私は前半を読みおえ、後半のインタビューを2人目まで読んだ状態です。
本書にかかれているスタッフエンジニアの職務内容や求められるものは良い意味で私のイメージしていものとは違いました。
これまで私が想像していたのは「所属する組織が使うOSSにコントリビュートして技術的な優位性を保る」「社内のツールを開発して組織全体の生産性を上げる」のような一言で言えば凄腕のエンジニアでした。
しかし、本書で紹介されるスタッフクラス以上の職務を自分なりにまとめると「チーム間・全社的な技術面でのマネジメントを行い、経営上のゴール達成に貢献する」でした。本書のサブタイトルが”Leadership beyond the management track”なので、マネジメントよりもリーダーシップという方が適当なのでしょうが、経営層とのコミュニケーションなどの項目が含まれるところを鑑みると、自分にはマネジメントと呼ぶほうがしっくりくるように感じられました。
本書の多くの内容は以下URLからも読めるので気になる章があれば実際に読んでみることをオススメします。
著者 Will Larson について
著者のWill LarsonはこれまでDiggやUber、Stripeでエンジニア職として勤務した後、現在は睡眠管理アプリのCalmのCTOとして仕事をしています。LinkdeinのプロフィールではDirector of Engineering、Senior Engineering Manager、Head of Foundation Engineeringなどエンジニアリングマネジメントや本書で含まれるStaff Engineer系のポジションについてきたことがわかります。
著者は過去に “An Elegant Puzzle: Systems of Engineering Management” という本も書いており、こちらはエンジニアリングマネジメントに関する本です。私は未読ですがこちらもAmazonでの評価も大変高いので読んでみたいと思います。
Staff Engineerの原型(archetype)
Staff Engineerの原型(archetype)として Tech Lead / Architect / Solver / Right Handの4つの役割・職種が紹介されます。ユニークなのはそれぞれの職種に関してイメージしやすいように1週間のカレンダーが添付されている点です。
Tech LeadとArchitectの違いは厳密に定義することは難しく、組織によってケースバイケースなのだろうと思いますが、チームの一員として技術的なチームのリードを行うのがTech Lead、特定の技術領域にフォーカスするのがArchitectというイメージを持ちました。
一方であまり一般的に役割・職種として顕在化してこないのがSolver / Right Handの2つでしょう。
Solverは自分なりに「火消し」の役割と理解するとしっくりきました。炎上しているかは別として、特定の技術課題に高い技術を持った個人として取り組み解決させていくイメージで、チームとして動いたりリーダーシップをふるうというよりも、純粋に技術にフォーカスしているようです。
Right Handはその名の通り、経営層や上位のリーダーの右腕です。Solverとは逆に技術課題に限らずビジネス・人材・カルチャーなどその対象は多岐に渡り、経営層や上位のリーダーの影響力を拡大させるためのサポートをします。
個人的にこのarchetypeの考え方はStaff Engineerについて考える時のみならず有効な考え方・分析方法だと感じました。新しい何かを始めるとき、役割を作るとき、目指すものそのものではなくとも既に存在しているものの中に既に要素が存在している事も多いはずです。そんな時にarchetypeの考え方を導入できれば、0→1を作り出すよりも段階的な移行がスムーズに進むのではないでしょうか。
で、コードは書くの?
ここが多くの人にとっての関心事でしょう、Staff Engineerはコードを書く仕事なのでしょうか? 本書での回答は “of course, it depends!”(もちろん、でも場合によるね)でした。
後半の”Stories”に登場する3人のインタビューが引用されますが、やはりいづれも特定のプロダクトのコードを書くイメージとは違いそうです。EtsyのFrontend ArchitectのKatieの以下の箇所はその性質を特に表しているように思います。
I’m a frontend architect, but by far the main thing I’ve been writing lately is SQL, because I’m doing a lot of data analysis. I’ve been looking at our performance metrics to figure out where the areas for improvement are, and what would be the most impactful issues to fix to improve performance and business metrics.
フロントエンドのアーキテクトという役割ですが、データ分析やパフォーマンスの統計データを見ることで改善が必要な箇所を特定し、チームが取り組めるように働きかける動きをしています。特定の機能や画面のコードを書くのではなく、さらにいうと特定の課題をチームで解決するのでもなく、そもそもチーム・組織が取り組むべきことを決めることが役割になっているようです。
Staff Engineerの職務
本書で触れられるStaff Engineer(本書内ではStaff-plus Engineerと呼ばれています)の職務内容をピックアップしてみます。主に “Operating at Staff”の章の内容です。
この章は以下の8つのトピックに分かれています。
- Work on what matters
- Write an engineering strategy
- Curate technical quality
- Stay aligned with authority
- To lead, you have to follow
- Learn to never be wrong
- Create space for others
この中からStaff Engineerに求められる仕事についての章をいくつかピックアップしてみます。
2. Write an engineering strategy
この章はエンジニアリングに関する戦略を持つこと、特に文書化することの重要性についての章です。冒頭で「エンジニアリングの戦略やビジョンを理解している企業は少なく、一般に書くのが難しいと思われているが、実はありふれた文書に過ぎない」とその敷居を下げようとしています。
戦略を書くための実践として本書ですすめられているのが「5つのDesign Docを書く → その類似点を抜き出し、5つの戦略を書く → ビジョンに展開する」というボトムアップの方法論です。戦略とはトップダウンではなくボトムアップの組織的学習の繰り返しである、とされているのが特徴的だと感じます。
Deisng Docの具体的な書き方として Design Docs, Markdown, and Git などが引用されフォーマットや運用方法についての紹介があり、以下のようにドキュメントを書く基準についても触れられています。
- 将来の多くのプロジェクトでその機能が使用される
- ユーザーに重大な影響を与えるプロジェクト
- エンジニアの時間が1ヶ月以上かかるもの
戦略とビジョンの作り方についても著者のTipsが述べられています。
これはエンジニアに限らない話だと思いますが上位の職種ほど企業内への広い影響力が求められることになる傾向にあると思います。Staff Engineerはマネジメントをしない代わりにエンジニアリングそのものでより強い影響力を発揮することが求められます。そのための一つの手段として戦略やビジョンを作成し、それを文書にして広く周知することが重要になるのだと理解しました。
3. Curate technical quality
技術品質に関するこの章では、技術品質の問題を各エンジニアの問題と押し付けることはリーダーシップをとる人の責任逃れであり、問題解決にもつながらないという提言からはじまります。技術品質はビジネスの成長と共に求められる水準が変化するもので、現状の品質と目標とのギャップを埋めることはリーダーシップの役割であるとされています。
取り組むべきhot spotの発見、ベストプラクティスの導入、品質の測定方法、最後は品質管理プログラムの立ち上げまで、個別の課題の具体的な発見から全社横断的な取り組みまで様々なスコープで紹介されています。
4. Staying aligned with authority
この章は役職につく組織権限(organizational authority)についての章で、組織権限は組織のより上位から部分的にStaff Engineerに貸し出されているものとされています。組織権限は多くの場合直属のマネージャーがスポンサーとなって付与されており、そのためには直属のマネージャーや組織と連携を保つ技術が必要だとされています。
ここまでのスコープは広いものの技術に関する内容から一転、急に上司との関係性・組織での動き方という毛色の違う内容になり、自分自身読みながら戸惑いを感じました
特に以下の箇所などは明確に考え方の転換を求められる箇所だと感じます。
This can be a difficult transition from previous roles where your authority primarily accumulated through your personal actions and impact over time.
ここまで自身の技術力やそして開発チームメンバーとの対話といった個人のスキル・行動によって培った力で進めてきたやり方に加えて、組織から貸し出された組織権限を持ってより大きな成果を出すこへの転換が求められます。そのために自分の価値観と組織の価値観の違いを認識し、方向性を揃えた上で摩擦なくそのギャップを埋めていくことが必要になる、というのがこの章の主張であると捉えました。
以降の章もエンジニアリングそのもの、というよりも組織での立ち居振る舞いについてが主なフォーカスとなっています。
10. Present to executives
組織の重役との接し方についての章です。重役との接し方には特有の難しさがあり、ミスコミュニケーションが発生しやすいとし、そのための効率的な方法が示されています。
重役とのコミュニケーションの難しさの原因を「重役はある特定の方法での情報消費に秀でている傾向にあり、重役にレポートされる前にその方法に前処理されているからだ」と説明しています。重役の情報消費のスタイルに合わないコミュニケーションを行うと、ミスコミュニケーションが生まれるということです。”特定の方法”には様々なパターンがあり、過去の経験に照らし合わせるタイプ、データによるエビデンスが必須なタイプなどが例として紹介されています。
重役と効果的なコミュニケーションを行う方法としてSCQA (Situation: 状況 — Complication: 複雑さ — Question: 疑問 — Answer: 解決方法)のフォーマットが紹介され、文書化・構造化が重要であるとされています。
フィードバックに対して戦わないこと、責任逃れをしないこと、答えのない問いを提示しないこと、アカデミックなプレゼンテーションを避けること、自身が希望する結果に固執しないこと、などのtipsが紹介されます。
感想
興味深いと思う一方で戸惑いを覚え、しかし実践的でもあるという複雑な思いが私の本書への率直な感想です。
4年での変化
私は2017年に “テックリードという役割” というブログを書きました。
ブログを書いた際のモチベーションは当時少なくとも自分の周辺ではソフトウェアエンジニアに関する役割や職種の整理が進んでいない印象を持っていました。自身の経験と調べた内容をシェアすることが何らか他の人に役立つと考えました。そこから4年以上がたち、日本のソフトウェアエンジニア界隈の状況は随分と変化したように思います。
エンジニア採用の募集タイトルにテックリードと書かれているのをよくみかけるようになりましたし、エンジニアリングマネージャーについてもブログやポッドキャストなどで豊富に情報発信がなされ、コミュニティができ、SNS上でも頻繁に言及されるようになったと感じます。
一方で自分自身もキャリアを重ね、この先に目指すべきはどのような姿なのだろうとぼんやりと悩みを抱えていたことも事実で、その一つのヒントを本書から得ることができました。
興味深い点
冒頭で触れましたが本書で提示されているStaff Engineer像は私が持っているイメージとは違うものでした。昨今話題にのぼるようになったIndividual Contributorのイメージも強くあり、コードを書き成果を出すことをメインとした役割だと想像していました。
本書でのStaff Engineerは技術に関するチーム横断・組織横断の役割でした。その性質やスケール感から、Staff Engineerの役職はある程度大きな規模の組織でなければ不要でしょう。
しかし一方で技術戦略を検討する、経営との連携をとることは組織の大小に関わらず必要な要素のはずです。多くの組織で一定規模までは専任のエンジニアリングマネージャーはいないものの、実際は誰かがその役割を担っている状態でしょう。同様に、Staff Engineerの役割についても特別に定義されなくても暗黙のうちに誰かが担当しているのではないでしょうか。
日本でもメガベンチャーには多くのエンジニアが所属していますし、スタートアップの調達額が上がって来ていることからも、今後大規模なエンジニア組織は増えていくでしょう。そのときには本書で提示されるStaff Engineer像に触れておくことは組織作りの参考になるのではなるでしょう。
戸惑いを覚えた点
本ブログではピックアップしませんでしたが、昇進や転職の検討などキャリア戦略の部分に関しては「ここまでキャリアを戦略的に考え、実行することに自分自身は情熱を持てない」と感じました。上位のポジションほどポストは少なく、そこに到達するためには努力が必要であることは頭では理解しつつも、そのために考えるべきことがあまりに多いと思い知りました。
ポジティブに捉えれば自分自身のキャリアに対する考え方・スタンスがクリアになる機会になったと思います。
実践的だと感じた点
本書はエンジニア向けのビジネス書として読める側面もあると思います。例えば Work on what matters > Avoid snacking の章は自分自身、身につまされる思いでした。
ある仕事のインパクトを縦軸、それにかかる時間や労力を横軸にとった四象限の図が提示されています。
当然左上の象限が最も取り組む価値のあるものではあるのですが、成熟した組織では継続的に改善が行われるのでこの象限のものはほとんど残っておらず、結果下のインパクトが小さなものに取り組みがちであるとしています。この傾向を “snacking” と呼び、避けるべきだとされています。
自分自身、そういった判断をしてしまった事もあったと思います。時間がかかりすぎる、などなんらかの言い訳をつけては本質的に取り組むべきことから逃げていた場面があったと思います。
まとめ
想像通りであった部分・違った部分、すぐに役立つ部分・自分からは遠い部分も含めて、本書には新鮮な内容が多くありました。実際にStaff Engineerとして将来働くことがあるかは別として、職務内容の理解やそのためのtipsは現在の日々の仕事にも適用できる部分がありました。
まだ読み切れていない後半のインタビューも最後まで読み切りたいと思います。
