［補足］海外でエンジニアとしてキャリアアップをするためにやったこと。３年半を詳しく振り返る。
下記の補足記事です。
３年半ベルリンのスタートアップで働いた経験を、時系列で細かくふりかえります。働いた会社の詳細や前後の文脈などは、上記本記事を参照してください。
入社したて：与えられた仕事をやりきる。コードを読みまくる。
まずは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を社内で啓蒙し始めていた頃でした。
この二つがうまい具合にはまり、データモデルの再設計のプロジェクトのテックリードをやらせてもらいました。そこから今まで、コアプロダクトであるデータパイプラインを主導するチームのテックリードとして、２年間過ごしています。
最後に渾身の力で仕上げたデータパイプラインは、タイトな締め切りとチームの知識という制限を考慮すれば、そこそこ良い感じで稼働していると思います。 （ここは、キチンと技術トークとして一本別記事として仕上げたい。）
おそらく数年後には「クソコード・クソ設計したなー、俺」と恥をかくことになると思いますが。。そんなもんだと腹をくくっています。
おわりに
上記のふりかえりの結果で、下記記事をまとめることができました。できるだけ海外っぽいと感じたところをアドバイスにしました。ご興味ある方はぜひ目を通してみてください。
