Spinach Forest

toc
about

May, 2021

/ Links 2020-05-23   / Mentorship   / Nudge Bot Stack   / Staff Engineer   / Teacher Appreciation Week   / ... 

Links 2020-05-23

| #letters

読んだもののリンクをブログにしておく試み。最初は substack にしていたけれどあまりに使い勝手が悪いので諦めて WP に帰ってきました・・・。なお今回は Instapaper に溜め込んで放流してなかった分を含むため、量が多め。

Mentorship

| #letters

ふと、若者のメンターとかしてみたら世間の役にも立つし面白いのかな・・・と想像してみる。まえ karino2 が暇つぶしでプログラミング言語を教えていた。そこまでの時間的コミットは自分には全然ムリだけど、たまにメールとか VC とかでお悩み相談にのってあげるくらいでいいなら、どうなのだろうね。

とおもいそういうメンターコミュニティみたいのないのかなとインターネットを探すと・・・ MENTA といサイトがあり、人々は課金していた！いや、課金とかいいんで・・・もうちょっと low key なやつないのだろうか・・・。よくわかってないが bootcamp 的なやつ周辺に通じるキナ臭さに逃げ出したくなる。

社内にもなんかあるっぽいが、そっちはそっちですごい structured な上にテック企業に入ってくるような人べつにチームの外にメンターとかいらないでしょ・・・という気分もあり、英語はかったるいし、まったくやる気にならない。

プラットフォームはさておいて誰を何故メンターしたいのか・・・と考えると、たぶん業界の歪みみたいなのを矯正する手助けをちょっとくらいできないかと思っているからだろうね。アメリカだとマイノリティを支援するコミュニティとかあるけど、そういうかんじで。日本だと人種的弱者というのは目立つ形ではいないから、女性とかの社会的弱者を支援するのがよいのだろうねえ。となると、何らかの女性向けソフトウェア開発コミュニティの中の人に相談してメンターさせてもらう、とかが良いのかもしれない。なんとなく中年おっさんが女性メンターするとか世間の目がきびしそうだけど、日本相手なら物理的距離のおかげでいかがわしさから守られ、無駄に睨まれることもないでしょう・・・。女性以外の構造的弱者、どういうのがあるかねえ日本。貧困とかはあるな。

しかし女性にしろ貧困者にしろ、そういうコミュニティとかどこにあるのかまったく不明。知り合いのそういうの詳しそうな人とか東京オフィスで仕事でそういう系のをやってる人とかに相談するのが良いのかねえ。あんまし会社と接点のあるところでやりたくないけど、自分の専門性とかどうしても勤務先に紐付きがちなので、避けがたい気もする。

もう一つは普段話しているのとは違う人と話すと発見があるのではないかという期待。ただランダムに話し相手を得るのは難しいのでメンターシップという形でならいいかもなという。しかしいざ文字で書いてみると傲慢な発想だね。おまえはツイッターでもしてろという自己批判が頭をよぎってしまう。

とか具体的に考えると段々腰が引けてくる・・・。お前は人のことをメンターするヒマとかあるのか的な・・・。メンターとか気のせいではないか・・・・。

なんとなく自分がいちおう形式的にメンターっぽいことをした現勤務先のことを思い出してみる・・・と、別にメンターとかいらなかったよねあのひとたち。一人はもはや自分より三段階くらい偉くなっており、もう一人はさっさと会社をやめてスタートアップで CTO とかやってる。

自分がなにをメンターしたのかほとんど思い出せないしたぶんほとんどメンターしていないが、たぶん当時の仕事である WebKit なり Chromium なりの残念エリアで時間や体力を無駄にしないように「それは単に残念なだけだよ」的な指摘をしていたのだろうな。それすら必要だったのか怪しいが、ただ眼の前のコードやプロジェクトの残念さを「それは単に残念なんですよ」と教えてあげるのは、その場所に前からいた人ができる数少ない意味のあることに思える。「残念だからほっといたほうが良いよ」ではなく「残念だからなんとか出来たら良いね」といいたいものだけど。前者を言われてもイラっとするだけだったりするじゃん。実力者であれば特に。

更にさかのぼり新卒で入った会社ではすごいメンタリング行為をしていた気がするが、ひたすら謎の偉そうな説教をしていたやんわりとした記憶が・・・黒歴史フィルターによってぼかされてよく見えないですね。たぶんすごい残念なことをしていた気がするけど、若さということでひとつ・・・。

本題にもどると、自分はコミュニティでのメンターシップみたいなものをまったく理解していないので、やるにしてもそういう話について書いたものを読むとかが最初のステップなのかもしれない。

Nudge Bot Stack

| #letters

Message Passing Blog の GitHub で進捗がない記事 (issue) をみつけてコメントする bot を作った。こういうのをささっと作れるようになっておきたいもんです。使ったものメモ:

  • Python で書いた。好き嫌いではなく慣れの都合。
  • 型がないと辛いので pytype を入れた。他の type checker と比べて特段出来が良いわけではないが、仕事で同じのを使ってるので。
  • Cloud Run に deploy し, Cloud Scheduler で週に一回つつく構成。
  • Dockerfile のことを考えたくないので Buildpack にした。
  • GCP のページをみたら "CICD できるよ" というので設定した。Cloud Build, 前は GitHub から引っ張る支援とか一ミリもなくてすげえ苦労した記憶があるが、今は勝手にやってくれる模様。ポチポチするだけでコミットから deploy されるようになる。

Scheduler の設定に Terraform を使おうかと一瞬おもったが、めんどいので諦めた。次はやります・・・。

こういうのをさくっとできる静的型言語が欲しいが GCP の buildpack は対応言語が限られすぎだわ・・・・。Kotlin を動かしている人がいるので、これを真似するのがいいのかもしれない。ただこんなこまっちい 200 行くらいのコードに IDE 使いたくないなあ。

Staff Engineer

| #letters

最近の人事考課でチームの二人が Staff というレベルに promote された。自分のチームは TLM (TL+manager) になって下に人がつかないとえらくなれないと思っていたが、この二人はピンのまま出世。できたのか！まあ二人とも良い仕事をしている。一人はサーバサイドからきたひとで、ある時期からアプリのコードを書くのをやめてデータエンジニア仕事をするようになり、SQL を書きまくって野ざらしになっていた user stats の立て直しをほぼ一人でやってのけた。めちゃパイプライン持ってる。もう一人は TL"M" ではないがリサーチ部門のアルゴリズムや新機種のカメラ構成をアプリにインテグレートする仕事の TL. 事実上二人ぐらい引き連れている。

なにはともあれ頑張ればこのチームでも部下なしで出世できるのかと感心した。出世というのはチームの勢いとかも関係あるので、勢いあるうちに出世すべく遊んでないで仕事頑張ったほうがいいのかな・・・などと考えつつ Amazon をぶらぶら(悪癖)していたら Staff Engineer: Leadership beyond the management track という本が目についたので読んでみた。

Stripe とかで働いていたテック企業文化圏の著者。割とよく書けており、自分の知っている Staff のイメージに合致しつつ理解を深める役に立った。まず Staff というのがどういう仕事をしているかを俯瞰する章があり、そのあといかに Staff に出世するかの章があり、最後に著者知り合いの現役 Staff (Staff-plus) たちにインタビューしている。インタビューは数が多すぎてダレたが、ほかはそこそこ興味深く読めた。(根本的にダイヤモンド社的な本である点には目をぶつられたし。)

一方で, そんながんばってまで Staff になりたいのだろうかと改めて考えてしまった。

自分がなぜ Staff になりたいのかと考えると、大きな理由は二つある。一番の理由は金銭的なもの: 出世すれば給料があがる。Sony のミラーレスが買えるし家も買える、かもしれない、みたいな。付随的な理由としては人々から認められたいという見栄。つまり「カネと名声のため」みたいな話なわけで、プログラマとしてどうなんだそれは。オンナがないだけマシかもしれないが...

文中では、もうちょっと高尚(?)な動機としてたとえば重要な意思決定に関与したいとか、影響力の大きな仕事をしたいとか、チームや組織の成長や文化に寄与したいとか、そういうのが挙げられている。そういうの・・・あんまし興味ないね・・・。

興味ないというと言い過ぎだが、肩書を通じて仕事したくないじゃん？重要なコードを書けば自然と影響力が増えてしまうというものじゃん？ちがうの？著者は肩書によって呼ばれるミーティングもあるし、周りからの視線も変わるのだよ、と書いている。そうかもしらんけど、別にミーティング呼ばれなくていいですよ・・・そして視線も変わんなくていいですよ・・・こっちくんな・・・。

いまいる部署、ある時期から各種ミーティングの議事録がチームのリストに流れてくるようになった。そして最近も重要性の高そうな緊急プロジェクトのミーティング議事録が流れてきた。そこにはたしかにチームの Staff-plus たちが召喚され意思決定している。が、緊急度高すぎて近づきたくねー。しかも AI (action item) がひたすら stakeholder に話をして合意を得るだとか実際に実装する担当者を探すだとか、そんなのばっかり。やだよ・・・。この本にも "Present to executives" というセクションがあるけど、そんなの上司や PM に押し付けて逃げる以外にどうしろというんだ。

書籍は冒頭の章で 4 つの Staff archetypes を列挙している: TL, Architect, Solver, Right Hand. そしてそれぞれのありがちな一週間のカレンダー(時間割) みたいのが載っている。ミーティングだらけ。そしてこれは自分の知っている Staff-plus のカレンダーとよく似ている。つまり偉くなるとミーティングが増える。ミーティング以外もレビューとかが増える。コードを書く量は減る。でもコードを書かないと肌感覚がなくなってしまうので、無理やり重要じゃないコードを書いたりする。カレンダーに "coding" とかいってミーティング避けのエントリを入れたりしちゃう。そういう TL よくいえるよねー。大変そうだねー。週に4-5 回のミーティングで既にイヤさが上限に達しているわたくし、これ務まるのか。

閑話休題。

出世の章では "Staff-Projects" の重要性 (の真偽) を議論している。Staff-Projects というのはその人の Staff 力を示すような難しくてインパクトのあるプロジェクトで、そういうのを完遂してレジュメに載せることで出世審議会をパスできる、と信じられているもの。

著者は、Staff Project は very nice to have だが会社によっては必須でなく、チーム間の顔を繋ぎつつ意思決定に関与する glue work みたいな成果を評価される場合もあるとしている。そういうのは・・・あるかもしれないけどそこまでして出世してどうすんだ。部下のついてないマネージャみたいなもんじゃん。

Staff-plus は "leadership role" なのでチームを牽引する必要があり、コードよりは対人関係の能力が重要だという。だからそういう code-less な Staff もありうる。とはいえ個人的にはやりたくない仕事の集合に見える。一方で自分はいまなぜか窓口業務を評価されてしまっているので、下手に仕事をがんばるとそういう code-less 路線に近づいてしまう。やばい。コードを書かなければ！

ところでたまにやたらコードを書いてる Staff-plus とかいるけど、なんつうか、明らかに残業してるね。自分も独身若者だったらコード書きつつ出世の一つもしたいところだが、妻子あると課外活動とかできないのだった。ブログとか書いてますがそれはいいのかというと・・・残業に値する仕事というのはなかなかないということです。クビになりそうか、運命の天職か。後者でないのは残念だが、前者でないことへの感謝を強調したい。

Leadership はさておき、自分は日々の firefighting および procrastination に忙殺され (後者は忙殺じゃないですね) 「よく考えてインパクトのでかい成果を出す」というのに失敗しており、これはよくないなと改めて思った。出世はさておき、きちんとデザインして書いたものをバーンとキメないと、なんというか、面白くない。本来は余裕があるはずの年末年始前後も、結局 procrastination と distraction と poor judgement を積み重ねて何も成果を出せないまま過ごしてしまい、また丸腰で火消しに追われる季節に突入してしまった。本来は冬の間に武器を揃え、打ち寄せる火種を瞬殺できるようにしておかないといけなかった。

一年くらい前はそういう火消しインフラの整備とさらなる高速化とどちらを優先すべきか迷いがあったが、その後の経験や、この本のインパクトに関する議論などを照らし合わせ火消しインフラ整備をやる方が明らかに正しいと納得した。そういうインフラが出来てこのクソのような火消しの日々から開放されるならいいじゃん。出世は無関係に。

火消しインフラはしょぼい気もするが、とにかくプログラマとしてなんらかのまとまった成果をだし、その成果をスケールするために人を巻き込む必要がうまれたら、税金として自分の成果を advocate するのはやぶさかではない（気がする）。そして税金を払った暁には給料に還元していただきたいので、出世を目論んでもいいかもしれない。ただ他人のためにそういうのをやってあげるのは、英語苦手なアジアン中年の仕事じゃねーわ。得意な人に任せたい。

つまり日々の雑事に追われすぎず大局観をもってバーンとクールなコードをキメる。これがプライオリティ。出世に惑わされてはいけない。これは何度も道を外れては立ち戻る同じ結論なわけだが、カネの力は強いのでこうして繰り返し自分に言い聞かせないといけない。

一歩さがって、なぜ自分は重要な意思決定とか影響力とかに興味がないのか考える。

一つは、組織がそこそこまともなおかげで肩書とかなくても行動を通じて影響力を行使できると信じているからかもしれない。自分以外の人手を借りようとすると多少は権力いるかもだが、自分自身の仕事についてはエラくならなくてもそこそこ autonomy がある。むしろいまのチームだと偉くなると duty 発生しまくりで、期待する autonomy があるのか怪しい。すっぱい葡萄ならいいんだけど。

二つ目は、英語できないからだろうね。自然言語を通じて影響力を行使するみたいな自分の不得意分野にわざわざ踏み込んでいく気が起きない。苦痛とフラストレーションしかなさそう。そういうのがパリっとできるならやる気も起きるのかもしれないが。

そういえば東京オフィスを脱出したいと思った動機の一つは、下手に東京に長居していると自分より英語やコミュニケーションが苦手な人（いるのだよこれが・・・）のかわりに窓口業務 TL をやることになりそうな予感があったせいもある。当時の東京にはそういう窓口 TL が多かったのだった。今は知らないけど。

更にさかのぼり、東京の中小零細で働いていた頃はというと、別に特段意識しなくても leadership とか influence とかが発生した。それを taken for granted で生きていた。その傲慢さは反省してしかるべきだがそれは宿題にするとしてなぜ、勝手に発生したのだろうね、権力。日本語のためだけとも思えない。そういえば零細で働く前の中小企業二つでは権力なかったわ・・・と考えると英語のためだけでなく大企業だから権力を志向しづらい面もあるのだろうなあ。大企業、偉くなるの大変。そして下っ端はラク。給料上がらないのは残念だけど、ボンクラのトレードオフとしてはまあまあ妥当。

Caveat として勤務先の Staff は先の本にでてくる Staff-plus ほどエラくはない気がする。バーンのいい仕事を決めた暁に出世できるなら別にそんなに困らないかもしれない。

あーあ、いい仕事をして責任や影響力は据え置きで給料だけ増えないかなー。

Teacher Appreciation Week

| #letters

今週は Teacher Appreciation Week というやつで、一週間かけ teacher に感謝の意を表明することになっているのだった。ようやく終わった。

例年だと room parent という学校指名の TL 的な親が取り仕切るのだが、今年は COVID の混乱のせいで指名がなされておらず、奥様は group gift に contribute いたいが自分で取り仕切るには忙しすぎる・・・とかいうので仕方なく取り仕切りを引き取った。プリスクール同級生の親にメールして、集金やら何やらを募ったりする。

しかし出遅れてしまったのでもう個人的にギフトを買ってしまったという親も多く、集金を締め切った後に「今週忙しくてメール読んでなかったわ間に合う？」という親も数名おり、当然返事のない親もおり、そういうのに色々返事をしたり、group gift の収支などを報告したり、はー。ただでさえ socially awkward な上に cheer する語彙にも乏しく、そのほか fairness などで気を使う判断も多く、メールを一通書くたびに精神力を削られた。親としての図太さを鍛える練習だと思ってやったけど、もう来年はやりたくない。そして一週間とかやめてほしいわ。Teacher Appreciation Day くらいにしてちょ。

集金する側に周ることで、この手の contribution に関する額（のばらつき）を理解できたのはよかった。

なおインターネット調べによると公立学校では一人あたり $50, グループからだと $150 が cap らしいが、一次資料は発見できず。そしていかにも誰も気にしてなさそうである。資本主義よ。