とあるXの投稿とブログを読んで、Technical leadership and glue workというタイトルの講演動画を見てみた。ブログと似た内容になってしまうかもしれないが、なんとなく思うところがあったので、記事を書いてみる。

まず今の私について述べると、転職してから自分のタイトルが会社都合で明らかにされておらず、自分自身がジュニアなのかシニアなのか未だにわかっていない。ただ、自分がシニアだと思って仕事をするようには入社してから心がけてきた。振り返ると動画で言われているGlue Work、例えばコードレビューやドキュメント作成、ユーザーのサポート対応なども積極的にしてきた。

一方でこの記事を読んでみて、そうした行動は目先の利益、つまり簡単に出る成果を取りに行っているに過ぎないのかもしれない感じた。誰かがやらないといけない仕事ではあるし、こうしたGlue Workを通じてシステムの全体像を把握したり、SREとしてのインシデント対応の質やスピードをあげたりはできている思う。しかし、そもそも自分は何がしたいのだろうか。やはり振り返ると自らコードを書いてモノをリリースした瞬間が一番達成感がある。ICとして続けていきたいのであれば、コードを書いてモノをビルドする経験は自分に足りていないので、これに集中すべきではないのか。文系卒だからこそコミニュケーションやマネジメント寄りの仕事で力を発揮していくべき、みたいな考えが頭の片隅にあって、その結果自分は10年後EMになりたいのかICになりたいのか他の方がしたいのかよくわからずにいた。しかし、自分が文系卒であることはサンクコストとして扱った方がいいのかもしれない。役に立てばラッキー、くらいでいい。自分が一番達成感がある仕事を続けられるように主体的に仕事を選んでいこう、と思った。

自分が明確にジュニアだった3年半の新卒１社目時代を振り返ると、ソフトウェアエンジニアとして伸びたいと思っていたので、自分の技術力が上がるような業務を取るために異動するなど、Glue Workerにならないことを意識できていた。その当時の勢いを思い出せばいいのかもしれない。ただ、会社にはジュニア層の割合が多かったこともあり、結果的には他のジュニアの誰かがBeing Glueだったはずなので、それなりに後ろめたさはあった。今思えばマネジメントや組織構造に問題があったと思う。

少し視野を広げて考えてみると、彼女が定義するGlue Workerはいわゆるブリリアントジャークや、Giver/TakerのTakerの対極にあるとも思った。彼女が言及している条件に合っていない人、つまり十分にシニアなエンジニアなどに適用されると組織としてよろしくないケースもあると思う。ここも深ぼってみたら面白そうだ。 個人レベルでは、ブリリアントジャークやTakerにならないように気をつけながら「技術的」な仕事に集中したいが、それは簡単ではなさそうだ。この塩梅をどうやってうまく取っていればいいのだろうか。紹介されていたようなカレンダーブロックは簡単にできる対応の一つだろう。もしかしたら、満足のいく技術レベルに到達するまでは塩梅は取らない、くらいの気持ちでもいいのかもしれない。

話がまとまらなくなってしまったが、個人レベルでは、短期的な承認欲求に振り回されず、時間がかかってもコードを書く仕事を続けられるように仕事をしていきたい。
社会レベルでは、ジュニア層の働き手が自分の求める専門性を伸ばせる仕事を取れるような環境が増えることが望ましい。やりたいことができない状況にNOをいう働き手側のジュニア層がさらに増えれば組織も変化せざるを得ないかもしれない。ジョブロールやルールを明確にして、Glue Workをやるべきでない人にGlue Workが割り振られない組織が望ましい。