「技術参謀(スタッフエンジニア)たちの戦略図〜リーダーシップという選択肢と彼らが選んだ企業の魅力〜」を視聴した

スタッフエンジニアは一般には部下を持たずに技術専門で働くロールにはなりますが、一方でメンバー育成も大事な役割となります。これは、なにか大きなことを行うには1人では無理で、組織で・複数人で行う必要があるため、自分がバリューを出すために必要であれば育成もやる、というスタンスだそうです。ここが「必要なことはすべて」にあたります。

役割の壁を作らずに越境、みたいな考え方は最近スタンダードになっているように思いますが、スタッフエンジニアとしての動き方についても同様のようですね。

また他のポイントとしては単純に技術だけで行くのではなく、あくまでも企業や事業に対してどう技術面で貢献するかが大事だ、というメッセージも多く含まれていたように思います。事業理解や、事業のための適切な技術選定が求めれる。ということでハイレベルロールですね。（当然か

困難を「一般解」で解く/fujiwaraさん

藤原さんは「自分はスタッフエンジニアだ！」と思って働いているわけではないそうですが、スタッフエンジニア4類型

Tech Lead
Architect
Solver
Right hand

のうちどれに当てはまるかで考えると、Solverだという自己認識をされているそうです。

Solverは困難な問題を解決する人で、火消し的な側面もあるそうです。（大変そう

fujiwaraさんのお話（パネルディスカッション含め）で印象的だったのは、あまりキャリアをこうしたい的なことを考えて歩んできたわけではない、という点です。ご本人としては「とにかく現場で出会った敵（技術的困難や課題）を倒す」のを頑張ってきた結果が今、ということでした。

ただ、困難を倒す際にただ解決するのではなく、解決方法にスタッフエンジニアとして求められるレベルがあるそうです。前提となるのが、一般解で解決することです。トーク中では「レバレッジが効く形で」ともおっしゃっていましたが、眼の前の課題にだけ効く方法ではなく他のチームの同じような課題などにも応用できるように一般的な技術や方法でまずやるのが大事、という話だと理解しました。

で、問題解決のレベルとしては

ジュニアエンジニア：自分の困難を解決できる
シニアエンジニア：チームの困難を解決できる
スタッフエンジニア：会社/業界の困難を解決できる

となっていて、スタッフエンジニアは会社や業界の困難を解決できるレベルが求められる、というお話でした。レベルが高い。。

パネルディスカッション

テーマとしては

技術力でリーダーシップを発揮するために
自身の戦略図の描き方
参謀が教える！技術力の上げ方

などが挙げられていました。詳しくは本記事にメモを貼っておくのでそちらをご覧いただくとして、前半のLTパートと被りますが大事だと感じたポイントは以下。

キャリアを作ろうというよりは、眼の前のことを頑張ったし、エンジニアリングが好きで続けてきた
自分たちの事業を理解し、好きになること。ユーザーの気持ちを理解するために、自分も使ったり、Xでエゴサして人々の声を知る。
好きだから頑張れる、はある。そして、どう好きになるか、も大事。自分の興味のある技術に結びつけたり、まずは得意なことで成果を出し、成果が出るから好きになる、という順もある。

感想

スタッフエンジニアは求められるスキルも高いのでスペシャルなロールだと思いますが、一方で特別ななにかをしたらそこに到達できるとかも無いよなと、当たり前のことですが感じました。

fujiwaraさんおっしゃっていた「眼の前の仕事をしっかりやる」というのはどのロールでも通用する心理のように思います。好きを原動力にプライベートの時間も投下しつつ多くを学び、眼の前の課題を倒して成果を出す、というのを続けていった結果到達したところに、あとから「スタッフエンジニア」という呼び名がついてきた、ということですかね。

その場でのメモ

事業を差別化する技術を生み出す技術

山下さん　GO株式会社
バックエンド開発
スタッフエンジニアとは
- 部下を持たない技術専門職
- 『スタッフエンジニアの道』は最高の書籍
- pyamaさんは、技術を軸に組織に必要な戦略を立て、それに必要なことはすべて実行し、周囲に影響を与える役割、と理解している
スタッフエンジニア水見式アーキタイプ診断
- スタッフエンジニアの道、1.3.3より
事業を差別化する技術
エンジニアの評価とキャリアパス
- 技術領域での貢献が重視されるように
- GMOペパボ（前職）の特徴
  - マネージャーとスペシャリストのラダーを区別
  - 役割ごとに評価制度を整備
エンジニアリングスペシャリストの役割
- 技術視点で企業や事業の方向性を考える
- 技術を活用し事業を推進
- 高い技術力と事業理解が求められる
- 適切な技術選定と推進力が要る
大事なこと
- 継続するために、自分の興味と企業の向かう方向性を揃えて、自身をモチベートして取り組む必要がある
事業を差別化する技術とは？
- 最新技術導入が目的ではない。最適な技術を選定
技術事例
メンバーとの協業
育成のジレンマ
- 部下もたないけど、メンバー育成は大事
  - 大きいことは複数人でやる必要があるから
  - バリューのために必要なら育成もやるよね
協業の方法
- シャドーイングと逆シャドーイング
まとめ

困難を「一般解」で解く

スタッフエンジニア4つの類型
- 『STAFF ENGINEER』より
- 藤原さんは自分がスタッフエンジニアだと思ったことはないが、どれに当てはまるかなーと考えてみた
- 強いて言えばSolver
  - 全員、かぶる領域はある
Solver＝困難な問題を解決する、火消し
- 困難な問題といえば・・・
  - パフォーマンスチューニング
  - 障害対応
  - セキュリティ胃炎市電と対応
  - などなどなど
- エンジニアリングや運用における困難＝要因が単純でない、複合的なもの
- 困難な状態になってから解決するのは大変
やってきたこと
- あまりキャリアとか考えたことがなかった　
- ともかく現場で出会ったものを倒してきた
- レバレッジの効く形で解決するのがベター
Staff Engineerの役割
- 広い範囲に技術で影響力を及ぼせるのがスタッフエンジニア
- Solver、可能であれば一般解で解くべし
- ジュニアエンジニア：自分の困難を解決できる
- シニアエンジニア：チームの困難を解決できる
- Staff Engineer：会社/業界の困難を解決できる
fujiwaraさんは最強のSREイネイブラー

パネルディスカッション

pyamaさんもとくに狙ったキャリアがあったわけではなかった
- 「あの人みたいになりたい」「あの人みたいに認められたい」と思ってやっていたらこうなった
fujiwaraさん
- いまは若い人がキャリアについて考えているが、昔は牧歌的というか、あまりキャリアの話とかはされていなかった
- 上から下まで眼の前のことをなんでもやってみていたなかで、バックエンド・インフラあたりが好きだった。狙ってこうなったわけではない。
カヤックでは昔から技術力を重視する風土があった
技術者をちゃんと評価する制度、みたいなものがGMOペパボにはあった
直近の転職の判断軸は？
- fujiwaraさん
  - 眼の前の敵を倒し続けていたらこうなった
  - そういうものがあるところ、課題のあるところにいたい
  - カヤックから無くなったわけではないが、自分が長年やってきたサービスが終了したり色々あって、おもしろそうなものがあると思って入った
  - クラウドが今普及しているので、クラウド自体をつくるという経験はなかなかできない
- pyamaさん
  - モビリティ領域に大きなうごきがある
  - １０年前職に居て、評価などが下駄を履いている感覚があった。自分をしらない人が多いところに行こうとおもった
  - タクシーが旅先で来ないとか、昔は文句言ってたけど、自分もなんとかしてやろうと思った
Q：高い技術力と事業理解が必要とありましたが、どのようにして事業理解、経営方針との理解進めるのが良いと思いますか？
- pyamaさん
  - サービスを好きになること
  - 作っている人たちとの単純接触を増やすこと
  - Xでエゴサをしまくる、日常的に
Q：最初はプレイヤー寄りのポジションだったと思いますが、そのようなポジションから事業理解を得るためにどのようなことをされましたでしょうか？
- fujiwaraさん
  - 世間で気に入られているかどうかを気にする
- pyamaさん
  - ただ作るだけではなくて、この機能もっとこうしたらいいんじゃないか、といった話をPMなどとするのも大事だと思う
    - 「このボタンもっとこうしたほうがいいと思うんだよね」とプルリク送ってから話しにいったりした
Q：事業部レベルで技術と営業、運用などの部署が縦割りになっている場合、自社の技術と事業それぞれの理解、あるいは双方の部署の相互理解を進めるにはどうしたらよいでしょうか？
- fujiwaraさん
  - 事業部レベルで割れてる組織にいたことがないので正直わからない
  - 過去いたところは基本１事業が１組織になっていて、そこに全職種がいるパターン
  - ひとつのチームで困難を解消したものを他に展開するとき、受け入れてもらえないといけない。ここでの信頼関係をどう構築するか。社歴が長いとこのへんスッと行くんだけど。仲良くなってないところに技術的な提案だけもっていくとうまくいかない。
- pyamaさん
  - 仲良くするのは大事
  - いま転職直後なので、知ってもらうための努力
  - 類まれなる肝臓をもっているので、食事に行くとか
Q：シニア→Staffとなるために必要な能力や知識は低レイヤーなものであることが多いでしょうか？
- fujiwaraさん
  - 突き詰めていくとそうなることも多い
  - 自分は好きでやっていたから（役に立つ回答ではないが
    - 好きだから、プライベートの時間をいっぱい投下した
- pyamaさん
  - 同じく好きだから
  - コミュニティの話になるが、技術力を比べる対象が社内だけではなくコミュニティになると、技術力やなりたい自分の尺度を外に持つことができる。より高いところを目指せる。
- 好きでやり続けるのはすごくよいと思いつつ、仕事が忙しいとか課題が大きすぎるとか、どうやってのりこえてきたか
  - fujiwaraさん
    - 好きなことと得意なことを分けて考える。得意なことをやっていったほうがいい。好きだけど得意じゃないことをやっていても結果が出づらくてつらい。得意なことで少しずつ結果だして評価される、このあたりを好きになれると芽が出やすいかな
    - 得意じゃない課題が出てきたときは得意な人に任せる！
  - pyamaさん
    - 適切な人に任せるのも大事だなと思いつつ、どうしてもやらなきゃいけなくなったら、それを楽しむ技術を身につける。たとえば何かの課題があって、自分がそのとき機械学習に興味があるとしたら、機械学習使ってみるとか。解き方を自分の楽しいものにして、自分の機嫌をとるとか
  - fujiwaraさん
    - うまくいく、結果が出れば楽しくなるので、結果出すのが大事
Q：１人でできないのであれば育成もやるという点について、ピープルマネジメントはEMと役割が被る部分があると思います。EMとスタッフエンジニアでどのように協力して育成をしていくべきでしょうか？
- pyamaさん
  - EMと連携してやる、というだけかなと思っている
  - 育てるにも方向性があると考えていて、いかに当人がやりたいことを組織のやりたいことと方向性合わせてあげられるかが大事だと思っている
- fujiwaraさん
  - SREやってたときはSREがいなくていいようにしよう！とやっていた
  - そうすると自然とSRE領域をエンパワメントしなければならなくなる
  - そっちに興味ある人がいたら育ててあげればいいし、興味ない人は楽にできるようにしてあげたらいい
Q：「自分のことを知っている人がいない」会社に転職したものの、「業界内では有名人」ゆえに「表面的には」みんなに知られている、みたいなところで難しさはあったりするのかな？
- fujiwaraさん
  - 自分でtimesチャンネル作る前に既に作られていて10人くらいワイワイしてたｗ
  - 一方的に認識されているパターンが現状多いけど、ふつうに仲良くしていけばいいんじゃないかな
  - 発言はちょっと気をつけないといけない、とかありますよね。あまり強く聞こえることを言わないとか
- pyamaさん
  - 酩酊したらTwitterやらない。いつも見られていると思って過ごす
  - しかし酩酊したらこのルールを忘れるというバグがある
- fujiwaraさん
  - 偉そうにしなければ大丈夫でしょう