blog.8-p.info

Quipper に入社して丸4年が経ったを読んで思ったことなど。

マネージャーにレポートするエンジニアと、複数のエンジニアからレポートされるマネージャーだと、前者のほうが忙しくなりがちだと思う。アプリケーションサーバーと、書き込まれる MySQL サーバーの違いに似ていて、前者は予算さえあれば「とりあえずもう一台」みたいなことが出来る一方で、後者は増やすのにも色々と作業が必要だ。

責務を分解する

TPM (Technical Program Manager), Tech/Team Lead や Product Manager といった横文字職種にマネージャーの役割を委譲するのは、負荷軽減策としてよくみられる方法に思う。

たとえば、隣の JIRA 職人では、TPM (Technical Program Manager) という職種について

TPM は「上司」という伝統的な役割を Team Lead や Engineering Manager といった複数の職種に分解するテック企業らしい手口のひとつと言えるのかもしれない。仕事の細分化が良いとは必ずしも思わないけれど、過剰な権力を備えがちな「上司」業を modularize するのは嫌いじゃない。TPM はあまり権力を持っていない。だから頭ごなしに意思決定はできず、関係者を説得しないといけない。このくらいがよさそうじゃん。

と説明している。この「上司を分解する」というのは言い得て妙だ。

ここに出てくる Team Lead というのは、言葉は違うけど、だいたい Tech Lead（TL/テックリード）の役割で説明されているものに近いと思う。ここでも

また Tech Lead を置くことでマネージャの負担がかなり減ることもメリットの1つだ。たいていのチームでは技術的に頼りになるエンジニアがいる。そういう人をマネージャが正式に Tech Lead として任命する。あわせてチームにその役割を共有すると良い。

と、マネージャーの負担を軽減することが、メリットのひとつにあげられている。

Product Manager は、日本だとプランナーとかディレクターとか、企画職と呼ばれている人々に近いと思う。ただ、たとえば「すべてプレスリリースから考えよ」アマゾンジャパンのPMに学ぶ仕事の流儀とキャリア展望のリードには

昨今、日本でも注目度の高まっているプロダクトマネジャーの仕事。しかし、業界内における人数の少なさから、その職責やジョブディスクリプション、どうすればプロダクトマネジャーになれるのかetc…といった部分はまだまだ不明確だ。

なんて書かれているので、もしかすると別の含意があるのかもしれない。

チームを分解する

こうやって職種を増やしてマネージャーの役割を委譲していく代わりに、チームを分割してしまう、というもある。Productivity Hack Of The Week: The Two Pizza Approach To Productive Teamwork ではチームの人数を少なめにすることについて、その利点が説明されている。

チームはどこで分割するべきなのか。複数の小さなサービス (microservices) がすでにあるので、それぞれにチームを割り当てます、というのは平和な分割方法だと思う。たとえば Martin Fowler の Microservices では

The microservice approach to division is different, splitting up into services organized around business capability. Such services take a broad-stack implementation of software for that business area, including user-interface, persistant storage, and any external collaborations. Consequently the teams are cross-functional, including the full range of skills required for the development: user-experience, database, and project management.

と書かれていて、チームもこれに倣って分割するのは良さそうだと思う。一方で、チームを分割するためだけに microservices 化するのは、個人的にはちょっと二の足を踏むところがある。ネットワークがもたらす複雑さを導入するのは最後の手段にしたい。

キャリアのラダーを乗り換えた意識をもつ

ラダーというのは梯子のことで、エンジニアとして偉くなるのがひとつの梯子を上に登っていくことだとしたら、マネージャーになることは横の梯子に乗り換えてしまうことだと思う。結果として、エンジニアあがりのマネージャーでも、自分のチームのコードは書かない人が多い。

良いことなのか、というとよくわからない。ラダーが別れていて、マネージャーにならなくても給料をあげる道があるのは、良いことだと思う。「マネージャーになってもコードは書けますし、それを前提に負荷を調整します」というのは、言えると良いけど、あんまり現実的ではない気がする。

まとめ

上司職、とりわけエンジニアのマネージャーを分解して、その負荷を軽減する方法として

• TPM, Tech Lead, Product Manager といった職種のひとに役割の一部を委譲する
• チームを小さく分ける
• マネージャーなのでコードは書かない

というのを紹介しました。

こうやってまとめると我ながら大企業然としていて、こういう普通の人々むけの最適化を無視できるのが、スタートアップや大企業ではない会社の、差別化要因な気もしなくもない。

ただ、最初の刺身さんの話にかぎらず、最近「マネージャーになって忙しくて」というのを読むと、そもそも要求水準が高すぎるのでは、と思うことも無きにしもあらずです。

仕事中にポモドーロテクニック (Pomodoro Technique) を使うようになった。ポモドーロテクニックは25分の集中と数分の休憩を組み合わせる時間管理術的なもので、ライフハッカーの記事 がわかりやすい。

ポモドーロテクニックを試すのは、これが初めてではない。いままでも何回か挑戦しつつ、途中でうやむやに終わっていたんだけど、ここ3週間くらいはちゃんと続いている。

一方で、割込みでのポモドーロのリセットはいまだ出来ずにいる。私にくる割込みは質問が多くて、質問される立場にあるのは個人的に良いことなので (英語だと、そういう質問されがちな人を “go-to person” という)、それを手放したくないのと、チーム内で質問が多いのはチーム的に良いことなので、それを抑えてしまう行動も避けたいというのがあり、割り込みがあった事実はこっそり記録しつつも、タイマーのリセットはせずにいる。

タイマー

25分と休憩時間を管理するタイマーにはいろいろある。実際のキッチンタイマーはうるさいし、Rebuild の higepon さん登場回で紹介されていた Tomato One (旧 Pomodoro One) は、ポモドーロの終わりに気づけないことが多く、いまは JustFocus を使っている。

JustFocus は、ポモドーロの終わりに全画面をおおうウィンドウがでてきて、作業を中断させてしまう。ポモドーロ終了の1分前に通知をだすところもふくめて、Rebuid のおなじ回で紹介されていた Take A Break, Please に似ていると思う。

休憩中にはさらに、Unsplash のきれいな写真と、Quotes on Design からありがたいお言葉を表示する機能もある。後者は自己啓発感が強すぎるかなあと思って、職場ではオフにしている。

月曜日はメモリアルデー (戦没将兵追悼記念日) で会社は休み。Northwest Folklife の帰りに、アパートの郵便受けをのぞいたらグリーンカードが届いていた。

グリーンカードは、アメリカ永住権ならびにそれを証明するための免許証大のカードのことで、これがあるとアメリカで自由に働けるようになる。

「自由に」というのが大事なところで、アメリカで短期間だけ働くのなら労働ビザをとればいい。ただ、ビザには色々と制限がある。例えば、私の持っている L-1 ビザは外国の企業からアメリカの関連企業 (親会社など) に転籍するためのビザで、他の会社に転職したりはできないし、雇用先から解雇されてしまえば帰国するしかない。

去年に書いたことの繰り返しになるけれど、渡米した直後は「グリーンカードをとるのは、今のビザが切れそうになってからでもいいか」ぐらいに考えていた。でもその後に Twitter での大量解雇があって、会社がいつまでも好景気で、私の雇用もグリーンカードのサポートも永遠にある、なんて思うべきではないと考えを改めた。

グリーンカードをとるまでにやったこと

色々なひとが書いていることだろうけど、データポイントをひとつ増やすくらいの意味はあると思うので、何時ごろに何をしたかをまとめてみる。

2015/10 – 手続き開始

というわけで、2015年の10月末にグリーンカードを取るべく社内の手続きをはじめた。サポートする法律事務所は会社が決めてくれるので、そこの人々の指示にしたがって、色々と書類を準備しはじめる。

2016/01 – PERM 申請

書類があつまったので PERM を申請する。

2016/03 – I-140 のための、雇用と能力を証明する書類がそろう

「過去にこういう会社で働いていて、こういう能力がありますよ」というのは自己申告ではだめで、過去の上司に一筆書いてもらわないといけない。

私の場合、当時の上司はみな転職していたので、過去に勤めた会社には在籍を証明する書類を、上司には能力を証明する書類を、それぞれ用意してもらうという形になった。

2016/07 – I-140 申請

プライオリティデートが近づいてますよ、という連絡をうけて、あわてて色々と書類をそろえて法律事務所に送り、I-140 を申請できたとの連絡をうける。

2016/08 – 健康診断

本来なら7月に健康診断結果も同封するべきだったんだけど、間に合わなかったので、健康診断をうけて、結果を法律事務所に送る。グリーンカードのための健康診断をする医者は “Civil Surgeon” と呼ばれていて、普段とは別の医者を選ばなくてはいけなくて面倒だった。

2016/09 – USCIS Application Support Center で指紋採取と写真撮影

ビザのための指紋採取と写真撮影。携帯電話は持ち込みできないらしく、そんな日に限って妻とはぐれて (私がまちがったバスに乗って) しまい、かなり狼狽した。

2016/10 – Employment Authorization Card が届く

Employment Authorization Card (労働許可証) が届いた。

2017/05 – グリーンカードが届く

グリーンカードが届く。

まとめ

3年弱をかけたというと大仕事だけど、実際の作業は色々と書類を集めたり埋めていくばかりで、ふりかえるとそこまで大変ではなかった。ところどころ忙しい時もあったけど、これは、私の準備が後手にまわりがちだった影響が大きくて、コツコツやっていれば負荷は平滑化できたはず。

いますぐに転職する予定はないけれど、アメリカでも職業選択の自由を得られたのはめでたい。

先月のはなしになるけど、四十九日があるので日本にすこしだけ帰っていた。葬儀に比べると四十九日は家族だけの簡単なもので、あっさりと終わった。

行きの飛行機では “La La Land” をみた。よかった。

最後のオーディションの場面で、なんとなく自分を重ねてしまって、もちろん私は川に飛び込んだりはしないし、大企業でプログラマをするのは

Should’ve been a lawyer. ‘Cause the world needs more lawyers.

という類の、安全側の選択肢だというのはわかっているけど。

でもまあ、飛行機ではるばる自分の国に帰って、日本に残している家族に色々をまかせてアメリカに戻ったりしていると、ちょっと foolish な感じがしなくもない。

課金プラットフォームの Stripe が、なぜだか Increment というオンライン季刊誌 をはじめていた。創刊の辞 いわく

a software engineering magazine dedicated to providing practical and useful insight into what effective teams are doing so that the rest of us can learn from them more quickly.

チームがどうこういわれると、アジャイルとか心理的安全性のはなしを思い浮かべるけど、創刊号の特集はオンコール! ということで読んでみた。

オンコールとは

オンコール (on-call) をカタカナで検索すると医療関係の説明がよく出てくる。たとえば 専門医局 というお医者さん向け転職サイトでは

医師をはじめ、救急担当やオペ室看護師など、医療従事者が患者の急変時や、救急搬送時に勤務時間外であっても呼ばれればいつでも対応できるように待機していること。

と説明されている。

ソフトウェア業界でいうオンコールもこれと同じで、リクエスト数が急増したとか、みたことないエラーがログに出ているとか、API の応答時間がすごく遅くなっていたりとか、そういうときに緊急の対応をする役割のことをいう。ローテーションを組んで当番制にしているチームが多いと思う。

Increment みどころ

Increment のオンコール特集号は、オンコール入門から各企業での事例まで、幅広い話題をカバーしている。

オンコールってなにをすればいいんだろうという人は、入門的な What happens when the pager goes off? と、スタートアップから大企業までどういう仕組みが必要かというのをまとめた On-call at any size あたりから読みはじめるのがいいと思う。

すでにオンコールをしている人は、オンコールと大変さを軽減するための Crafting sustainable on-call rotations と、様々な会社でだれがどうオンコールをしているのかを聞いてまわった Who owns on-call? が参考になるだろう。

この冒頭では

It’s difficult to pinpoint exactly when the industry changed its mind about on-call responsibilities, but the “who”, the “where”, and the “why” are relatively straightforward to uncover and understand. To determine the state of the industry, Increment spoke with over thirty industry leaders about the “who” and the “why”, and what we learned from our conversations about the industry-wide movement to put developers on-call for their software.

開発チームをオンコールにいれるのが業界全体での動きだとされていて、私はちょっとびっくりした。

流行りの SRE (Site Reliability Engineer) 職についても、Google の SRE は大きなサービスだけだとか、Airbnb では SRE だけがオンコールしないとか、いろいろと知らないことがあった。

追記

向井さん曰く、

GoogleのすべてのサービスにSREがいるとは限らないですが、ここで言及されてるよりはずっと広い範囲をカバーしています。

らしいです。