https://kenzan100.hatenadiary.jp/entry/2020/07/07/071455 と その補足記事の転記。日本語ブログの一本化を考えていて、その一環です。

（日時の文脈は、2020年7月当時のものです。Top Photo by mwangi gatheca Unsplash ）

最後に記事を書いてから（２０１６年１２月）なんと３年半の月日が流れてしまいました。

この度、カナダ・トロントにてShopifyという会社にSenior Software Developerとして転職することになりました。この機会に今までの仕事のふりかえり・棚卸しをしたいと思います。

現時点までで私は８年ほどエンジニアとして働いていますが、今年で「キャリアの半分以上を」海外で過ごしたことになります。なかなか感慨深いものがあります。

この数年何してたの？

最後にブログを更新した２０１６年１２月以降、驚くことに同じ会社で３年半働き続けていました。ウェブ系スタートアップでの平均勤続年数から言うと「３年半は長くいた方」な気がします。

ですので、まずはこの会社で過ごした３年半がどのようなものだったか記しました。

タイトルに「キャリアアップのためにやったこと」と書きましたが、結果としてキャリアアップにつながる経験値をたくさん積ませてもらえました。

実は勤務地も一回変わっており、去年の９月には現職を続けたまま、カナダ・トロントに引っ越しています。その顛末も別の機会に詳しく説明できたらと考えています。

トロントに引っ越しました。

ハイライト

自分が在籍した３年半で、会社が３倍ほどの規模に成長した。

現職はChartMogulという、サブスクリプションビジネス向けに分析ツールを提供している会社です。市場のニーズをタイミングよく捉えており、自分が働き始めたときには既に成長中でした（だから応募しました）。

そこから今までに、会社の人員も、ビジネス規模も約３倍くらいに成長しました（売上の方はどこまで出していいのか分からないので、人数でいうと１５人から５０人ほどになりました）。

３年半順風満帆だったわけではありません。けっこうしんどい時期が何回かありましたが、それを生き延びて、さらに（後述しますが）成長路線にもう一度乗せることに貢献するという、貴重な経験を積ませてもらいました。

成長とその間の紆余曲折で、自分の役割・責務が大きく変化した。

時系列で、自分と会社の関係がどう変化したかふりかえります。

入社したて：与えられた仕事をやりきる。コードを読みまくる。

まずはIndividual Contributor（部下を持たずに個人のタスク遂行で価値を出すことを求められている人。"IC"とかって略されたりします）として認めてもらうまでに、１年くらいかかりました。

入りたての最初のミーティングで、「RustでInMemory DBつくるんだけど、どう設計したらいいと思う？」みたいなトピックを出されて、固まったことを覚えています。ビジネスドメインの理解も入社したてでふわふわ、関連技術の経験もない状態だったので「何が分からないのかも分からない」ような状況でした。

案の定、そのあとはかなりレイヤーの違う仕事に回されました。データ可視化ライブラリd3.jsとビジネスロジックの統合辺りをきれいにして、UIに新しいグラフ描画オプションを追加する仕事を一生懸命にやっていました。とにかく、コードを読みまくることに必死でした。

その後フロントエンドでスピード感よく仕事が終わらせられるようになってきたので、バックエンドの実装が遅れていた部分に、チームメンバーとして参加することに。Golangでマイクロサービスを書くという、そのときの興味分野にマッチしたプロジェクトでした。

大体主要なコードを読み切り、コンポーネント間の構造で物事を捉えられるようになったのは一年くらい経ってからです。

"Be the worst"

組織で自分が一番できていない状態にあることを、プログラマー向けのパターン言語で "Be the worst" というそうです。転職や社内での異動を考えている人は、ぜひ "Be the worst" になれる機会を積極的に取りにいくといいと思います。サバイバルモードで学習意欲が高まる人にはなおさらオススメです。

１年経った頃：チームリードをやらせてもらえないか打診

１年が経って周りに気を配る余裕が出てきたころです。「あれ、今の会社のボトルネックって、技術じゃなくてチームワークだな」と気づく場面がありました。

あるチームに、一人でバリバリとコードを書く、英語が苦手なフルリモート勤務のメンバーがいました。彼が仕事をするとぐっとプロジェクトが前に進むのですが、実はその陰で他のチームメンバーが置いてけぼりを食らってしまう。言語と時差の壁もあり、フィードバックがうまく機能していない状況でした。

そこで、CTOに１on１を申し込んで「今の自分ならチームリードの職務に適性があるはず。やらせてもらえないか」と打診しました。

CTOからすると想定外の申し入れだったらしく驚いていましたが、「You have drive and passion for Product development」と（おそらく）そこまでの仕事を進め方を評価してもらい、チームリードに昇格してもらうことができました。

"Is there any blockers?"

ここからはかなり考え方が変わります。自分の仕事をやりきることは当たり前で、さらにメンバーの仕事の障壁を率先して取り除いていかなければいけません。５、６人のフロントエンド主体のチームで、１on１、新規採用の面接などもやらせてもらいました。

この頃参考になったのは、スタンドアップのときの"Is there any blockers?"という質問形式と、Enablement・Empowerment（問題を自分で解決するのではなく、権限移譲を念頭に置く）という考え方。そして同じような問題が二度三度と起こったら、それを構造的に解決できないか考える姿勢です。

例えば、あるメンバーがフロントエンドの状態管理で苦言を呈していました。話を聞くとかなり深刻で、今のままで状態管理をアドホックで進めていくと、バグが頻出するだろうとのこと。

そこで、当時はBackbone/Marionetteで構築されたSPAだったのですが、SPAそのものをマイグレーションすることも含めて幅広く検討し、マイグレーションコストを議論し、徐々にライブラリを切り替えていくロードマップを立てました。

このときは下記の点に注力しました。

* 半分のチームメンバーがフルリモート（時差数時間の差含む）だったので、議論をいかに非同期で進めるか考える。
* 英語が不得意なメンバーが一定数いたので、「決まったこと」と「議論中のこと」を明確に分けて、メンバーの理解度に差がないか気を配る。
* 自分の意見の我を通さない。建設的な議論の風通しの良さが、チームの長期的な健全さ・生産性につながることを理解する。
* 計算されたリスクをとって、「決める」責任を負う。

入社２年半〜：テックリードとしてコアプロダクトの設計を担当

チームリードになって半年が経った頃、CTOが自身のスタートアップを起こすということで（円満）退社を迎えました。新しいCTOの採用が難航する中で、他のチームのリードがHead of Engineeringにプロモートされました。

同じ頃、機能開発優先でつくられていたチームの分け方に弊害が生じていました。会社の成長で、処理するデータ量・データそのものの複雑さが増しており、MVP以降修繕を繰り返していた最初の設計そのものに「綻びがではじめていた」と理解しています。

Tech Debt Month

そこで「TechDebt Month」というものが社内で提案されました。「技術負債返済のための集中月間」とでも訳すのでしょうか。この月を境に、既存のチームをいったんリセットし、破綻し始めているサービス・コンポーネントの分析・（必要であれば）再設計をするというプロジェクトが始まりました。

技術負債の洗い出しで、緊急度・重要度がともに高く認識されたのが、マイクロサービスに切り出したデータモデルの見直し。だからといって、マイクロサービスをそのままMonolithに戻すのは問題を先延ばしにしているだけ。

ちょうどこの頃下記のBraintree 元CTOの記事を読み、Modular Monolithを社内で啓蒙し始めていた頃でした。

この二つがうまい具合にはまり、データモデルの再設計のプロジェクトのテックリードをやらせてもらいました。そこから今まで、コアプロダクトであるデータパイプラインを主導するチームのテックリードとして、２年間過ごしています。

最後に渾身の力で仕上げたデータパイプラインは、タイトな締め切りとチームの知識という制限を考慮すれば、そこそこ良い感じで稼働していると思います。（ここは、キチンと技術トークとして一本別記事として仕上げたい。）

おそらく数年後には「クソコード・クソ設計したなー、俺」と恥をかくことになると思いますが。。そんなもんだと腹をくくっています。

３年目に入り、自分の成長速度の鈍化を感じた。

そのテックリードとして担当したデータパイプラインがリリースにいたったのが、今月３月のことです。この時期の自分を分析すると、「疲労がたまっている」「バランスが崩れている」という状態だったと思います。

会社を成長させること、自分が成長すること、価値を出し続けることなどについて「行き詰まっている」感覚がありました。

* 以前と同じ質で物事を提案しているはずなのに、なかなか賛同が得られない。
* チームとしてのスピード感が出ない。
* プロジェクトの完遂と会社の成長のあいだの「変数」が増え、フィードバックがうまく機能しない。

おそらく、会社の規模・構成が変化するにともない、会社の文化が変わったことに気づけなかったのだと思います。

機能を開発し、みんな志高く同じ目標に向かって突き進むことが当たり前だった入社１〜２年。ビジネスが大きくなり、個人からチーム、チームから部署になりはじめ、また入社する人たちのマインドセットも徐々に変わってきた後半の１〜２年。

自分はどちらかというと「働いている姿を見せること」で他の人に影響を与えてきたと思います。そのリーダーシップスタイルは、まだ会社が小さいうちにはいいのですが、より大きな組織になると影響力ががくっと落ちます。

また、テックリードとして「この設計はどこまでスケーラブルなのか」という質問に常に答え続けなければいけません。このときに自分の脳裏をよぎったのは、「今の会社で自分は技術選定をリードする立場だが、自分よりもすぐれた知識やプラクティスが業界には絶対にあるはず」という思いです。

自分が現職に留まりつつキャッチアップするのがいいのか。シニアやリードの新規採用で新陳代謝を起こしたほうがいいのか。「自分が居続けることに弊害もあるのかもしれない」と考え始めるようになりました。

こういう振り返りができたのは最近です。プロジェクト終了直後は、とにかくデータパイプラインの再設計、チームリード、テックリードを並行して進めて、かなり疲労困憊でした。

これからは？

ソフトスキルの目標： "Calm, centered leadership"

「自分が働くことで成果をあげる」という意識のままでリーダーシップポジションに入ると、「自分みたいなのが複数人いればいいのに」という危険極まりない思考に入っていきかねません。CEOにフィードバックをお願いする機会があったのですが、その中で自分に刺さったのは「Calm, centered Leadership」という表現です。

今すぐ成果が見えずとも、自分のやったことが長期的・持続的な変化・変革につながっていくという信念をもつ。そのために研鑽を積む。その結果として上述のリーダーシップスタイルが導き出せるのでは、と踏んでいます。

その際、技術スキルは、周囲を「Enable」する、その点で有用になってきます。そのためには、自分の興味分野で深掘りできるポイントをしっかり掘っていき、その中から普遍性を見出すことが大切です。

一方、マネジメントという観点で「Enable」するためには、ビジネス・部署の複雑性を理解しながら技術が「本質的になにを阻害しているのか」「何を変革できるのか」それらを様々な立場の人が「納得するしかない」形でプロジェクトに落とし込んでいくことが重要です。

技術目標： "Deepen the portfolio"

ChartMogulに入社した当初は、「Rails/Full-stack」「Getting things done」「Consistent learner」あたりのコンビネーションで価値を出せていたと思うのですが、経験年数が二桁になるころには、より体系化された知識と専門性がないとキャリアが続かないのではと感じています。

ここらへんのキャリアトラックで悩んでいたときに、下記二つの視点が大変参考になりました。これも解説し始めるときりがないので、また別の機会に。知りたい人はコメント・連絡いただければ幸いです。

Shopifyを選んだ理由

Shopifyでは、マーチャントの海外展開を支援するAPI基盤の開発、というチームに配属される予定です。

転職活動中は、TechLeadとしてやっていたデータパイプライン分野を深掘りすると言う意味で、データエンジニアリングにふったキャリア選択も候補にありました。

しかし、

* まだ一つの専門領域に舵を切っていくには経験値・サンプル数が足りない気がした。
* それよりも先に、大規模かつ既に馴染みがある技術スタックで運営されているシステムの内部を知りたい。そうすることで、幅と深さの両方を知った上で専門領域を考えられると思った。
* Shopifyで働いている人にリファレンスをとったところ、みな口を揃えて「良い会社」といっているので、マネジメントの部分でも学ぶことがありそう。
* 何よりも、最後のチームマネージャーとのマッチング面談で、話が一番弾んだ。

というあたりで、Shopifyからのオファーを受諾することに決めました。

また一からの出直しです。ワクワクしています。

海外でエンジニアとして働き続けるためのアドバイス

１．生活ががらっと変わるときは、職務・スタックは変えない方がいい。

初めて住む国で、職務内容も変えるとなると、相当のパワーが一度に要求されます。一社目では日本でやったエンジニア職務で足がかりをつかむと、「文化・生活に慣れる時期」というバッファがとれるのではないでしょうか。

２．二社目からは、成長をとっていこう。

人は環境に影響されやすいものなので、成長中の会社に身を置くことは自分を成長させる上でよい方法だと思います。こういう考え方を、Growth Mindsetと言うそうです。

３．「がんばって働く」という価値観はマイノリティになりうることを肝に銘じる。

これはニュアンスが難しいのですが、 「みんながんばって働くわけではない」ということをしっかり考えたことがありませんでした。

自分で会社をやったりスタートアップの初期メンバーだったことがあると、つい「まじめに働くのは当たり前でしょ（そうじゃなきゃ会社が潰れる）」と思ってしまいがちです。しかし、会社の成長路線・雇用体制によっては、それが長く続くわけではないですよね。会社のステージが変われば、社員の意識も変わります。

自分が期待する「勤勉さ」というのがなくても、会社に価値を与えられる人はいるのだろうな、それが多様性の意味だろうな、と考えるようになりました。勤勉さがマイノリティになりうることを意識していないと、めっちゃストレスになります。気をつけて。

４．フルリモートと、フルリモート＋フル時差は全然違う。

チームメンバーの時差の最大１０時間という、ハードな状況が何回かありました。今でも、どうやったらその時差でいい感じのエンジニアチームがつくれるか分かっていません。

よりワークフローが非同期に特化した部署（最近のカスタマーサクセスなど）ならうまく回るのかもしれません。クリエイティブな技術設計の話など、私はホワイトボードを引っ張り出して、1時間集中して同僚とガチャガチャ議論したいタイプなので、これを非同期で置き換えるイメージがまったく湧きません。

成功事例があったらぜひ聞いてみたいです。

おわりに

こんな方とお話ししてみたいです。

1. Ruby/Rails界隈でのデータパイプラインの知見、データ処理のライブラリに物足りなさを感じている人。Apache BeamやFlinkをそれ界隈の技術をやっている・やってみたい方。
2. ベルリン、もしくはトロント進出済み・進出予定のエンジニアの方。もしくはそもそもエンジニアとして新規挑戦されたい方。
3. Shopifyにご縁がある方。

９月頭までの１ヶ月半はわりと時間があります。はてなと同じハンドルネーム（kenzan100）で色々なソーシャルメディアにいますので、連絡いただければ幸いです。

それではまた次の機会に！