第4章：導くことを学ぶ

Overflowを去るのがどれほど辛かったかは、すでに書きました。書かなかったのは、私が誰を置いていくことになったのか、ということです。Keita、Matsun、Fujikawaさん、Tabitoさん — ありがとう。一緒に過ごした年月に、そして、自分の未熟なレベルとたどたどしい日本語であの面接を台無しにしたと思い込んでいた最初の頃から、私を信頼してくれたことに。実際に「行こう」と心を決められるまで、Tabitoさんとの1on1が三回必要でした。そしてようやくチームに伝えたとき、心から寂しさを感じました。同じプロジェクトに2年もいると、そうなるものです。引き抜こうとして初めて、根がどれだけ張っていたかに気づくのです。

転職活動そのものは短いものでした。面接は二つ。一つはフィンテック系のスタートアップで、完全に失敗しました — フロントエンド寄りのフルスタックのポジションで、Overflowで2年間Vue.jsを触っていたとはいえ、私のフロントエンドの知識は自分が望む水準よりも薄かったのです。問題ありません。自分の限界がどこにあるのかは、すぐに分かります。

もう一つがモンスターラボでした。

世界中にオフィスを構える大手コンサルティングファームで、ポジションはシニアバックエンド — こちらはずっと自分向きでした。面接は、しばらく前から密かに望んでいたような会話でした。面接官は当時のEMで、最終的にシステム設計の話に深く入り込みました。CDN、キャッシング、リードレプリカ、ロードバランシングの戦略。提出したコーディング課題 — 小さなRailsアプリケーション — についても話しました。今回は、半分だけ暗記した語彙を必死に探す必要はありませんでした。これらのことを私はOverflowで2年半、実際に生きてきたのです。それがはっきりと感じられました。オファーをもらい、しかも給与の大幅なアップ付きでした。

Seidoが作ることを学んだ場所、Overflowがちゃんと作ることを学んだ場所だとすれば、モンスターラボは他の人と一緒に作ることを学んだ場所であり — そして最終的には、その人たちを導くことを学んだ場所でした。

違う種類の会社

モンスターラボはクライアントから案件を受託します。つまりエンジニアはそれぞれ異なるプロジェクトにアサインされます。だから私はバックエンドチームに所属していたものの、実際に一緒に働くことはあまりありませんでした。それだけは、本当に残念に思っていたことでした。一緒に何かを作りたかった同僚 — むしろ友人 — がたくさんいたのに、いつも別々のクライアントワークの両端にいたせいで、その機会は一度も訪れませんでした。コンサルティングというのはそういうものです。そこは折り合いをつけるしかありません。

それ以外はほとんど、大好きでした。ポジションはリモートで、私はそれを思い切り活用しました。その頃は江ノ島に住んでいました — 美しい場所ですが、東京のオフィスからはかなり遠く、出社するのは月に二、三回くらいでした。出社するときはいつも良い一日でした。（会社のワインパーティーで、フランスについてちょっとしたプレゼンをしたこともあります。ワインのことは聞いてください、人前で話すことについては聞かないでください。）

それから、これほど自分にとって意味を持つとは思っていなかったことがあります。エンジニアのおよそ半分が外国人だったのです。Overflowでは自分一人だけ — 唯一の日本人以外として、仕事の日本語をリアルタイムで習得していました。モンスターラボでは、もう自分が例外ではなくなり、それによって、自分が背負っていたことにすら気づいていなかった、ある種の静かなプレッシャーが消えていきました。

最初のプロジェクト、そして忘れられないクリスマス

最初のプロジェクトは、誰もが知っている大手の日本の自動車会社のものでした。途中から参加したので、土台はすでに出来上がっていました。バックエンドエンジニア、サーバーはRuby。だから初日から快適に、すぐに飛び込んでいくことができました。正直、難しいプロジェクトではありませんでした。だからこそ、これを本当にうまくやろうと決めたのです。

参加して三ヶ月後、何人かのメンバーが抜け、気づけば私がバックエンドリードになっていました。プロジェクトは、大きなトラブルもなく、その約半年後に無事に終わりました。

まあ — 一つだけトラブルがありました。その年、クリスマスに仕事をしたのです。自分の側のコミュニケーションミスで、本番データを上書きしてしまうタスクを実行してしまいました。結局のところ、良いほうのミスでした。なぜなら、そこから抜け出す道が、AuroraのPoint-in-Time Recoveryを徹底的に学ぶことだったからです。しかも、教訓がしっかり身に染みつく、まさにそういう種類のプレッシャーの中で。それ以来、本番タスクを以前と同じ目で見ることは二度となくなりました。Joyeux Noël.

その後、プロジェクトはメンテナンスと後片付け、そして引き継ぎへと落ち着いていきました — 静かでした。だから、その静けさを使いました。

AWSを深掘りする

OverflowでもAWSはたくさん触っていましたが、そのほとんどはウェブ寄りのものでした。EC2、ECS、RDS、S3、SQS、ALBとVPCを使ったネットワーキング層、CloudFront、WAF、Redshift。役に立つには十分なだけ知っていました。でも私は、危険なほど詳しくなりたかったのです。AWSは本当に触っていて楽しいプラットフォームで、アプリケーション側だけでなく、インフラ側をもっと深く知りたいと思っていました。

そこで、AWSインフラのプロジェクトにアサインしてくれるまで、私は半ばEMに付きまといました。Serigne、ありがとう — これまで一緒に働いた中で最も優しい人の一人で、それを実現してくれました。

次のプロジェクトは、銀行、eコメース、通信 — 思いつくものすべて — あらゆる分野に手を広げている、あの種の日本の巨大コングロマリットのものでした。AIエンジニアと一緒に、RAGを使ったChatGPT搭載のチャットボットを作りました — このブログのために後で作った小さなチャットアシスタントと、そう変わらないものです。そこでAmazon LexやAmazon Connect、そして今ではもう半分忘れてしまったいくつかのサービスに手を触れました。すべてTerraformでプロビジョニングしたものです。プロトタイプを立ち上げるのに数週間かかりました。完全にTerraformで。あの一連の作業は本当に好きでした — システム全体をコードで記述し、それが形になっていくのを見るのには、深く満たされる何かがあります。難点は、結局それがプロトタイプ止まりだったことです。でも、学びは本物でした。

モンスターラボはAWS認定資格に対する金銭的なサポートも提供していたので、私は全力で取り組み、必死に勉強しました。結果として七つほど取得しました。認定資格を少し軽く見る人もいて、その気持ちも分かります — でも、あの理論的な基礎は、その後何度も何度も、当時は予想もしなかった形で役立ってきました。以前は霧の中だった多くのことが、今ではしっくりくるようになったのです。

参加して約1年後、大きな昇進をしました。テックリードへの昇進です。フィードバックは、プロジェクトへの貢献と、前向きで主体的な姿勢についてのものでした — 正確な言葉は覚えていませんが、それがどう感じられたかは覚えています。認められた、と。

一番きついやつ

三つ目のプロジェクトは、在籍中で最も長く、最も難しいものでした。別の大手企業の重要な開発のバックエンドリードを、ゼロから、タイトなスケジュールで、大量にデリバリーしなければならない状態で。振り返ってみると、与えられた時間に対して、本当に多くを要求されるものでした。

アーキテクチャは私にとって初めてのもので、すっかり気に入って終えることになりました。三層構成です。フロントエンドが GraphQL で BFF と話し、その BFF が gRPC で Ruby on Rails のバックエンドと話す。全体がスキーマファーストでした — proto ファイルで契約を定義し、BFF 側もバックエンド側もそのスキーマからコードが生成されるのです。つまり、層同士がこっそり乖離していくことがありません。スキーマを変えて再生成すれば、何を壊したのかをコンパイラが正確に教えてくれる。こういう作り方をしたのは初めてでしたが、本当にうまく機能しました。

特に作れて誇らしかった機能のひとつが、予約システムでした。「枠を予約する」と言うと簡単そうに聞こえますが、そうではありません。空き状況を確認して実際に枠を押さえるために Google Calendar と連携し、その上にアプリケーション側の入り組んだルール — ロール、参加者のスマートな割り当て、選択可能な時間帯の集合 — が載っていて、予約が成立する前にそれらすべてが噛み合っている必要がありました。それらの制約をきれいに揃えること、それは私の好きな種類の問題でした。表面上は小さく、中に入ってみると奥が深い。

もうひとつ、作れて嬉しかった機能が分析機能でした。大量のデータを集計して、日次・週次・三ヶ月といった期間の分析データを見せるものです。ここでは Google BigQuery — この種の処理にぴったりの OLAP データベース — を選びました。Overflow での経験がここで生きました。以前によく似たものを設計して作ったことがあったので、取りかかる前から問題の形が分かっていたのです。集計ジョブは OLAP データベースで一日に一度走り、その結果が OLTP データベースに読み込まれる — そうすることで、集計済みデータへの読み取りリクエストがとても速く保たれました。何の問題もなく動きました。

私はベトナム支社の8人のバックエンドエンジニアをマネジメントしていました。向こう側にもバックエンドリードがいて、大きな助けになってくれました（Tien、君に目配せを）。チームの多くはジュニアでしたが、彼らの中に意欲を感じることができました — 学びたい、ちゃんとやりたいという意志です。それに私は昔から手を動かすのが好きで、特にその頃は、まだ自分の手でコードを書いていた時代でした。だからテックリードの仕事に加えて、彼らと並んでコードの中に入っていくことになりました。

そこで、私は本当に品質と時間のバランスを取ることを学ばなければなりませんでした — スローガンとしてではなく、タイトな締め切りに押されながらの、毎日の判断として。あるとき、PMたちがスピードアップのためにバックエンド開発者を増やそうかと持ちかけてきました。私はそれに反対しました。すでに8人プラス私がいて、人手を増やせばスピードは上がるどころか落ちる、と直感が告げていたのです。（当時はその名前を知りませんでしたが、私はBrooks's Lawを内側から再発見していたのです。）

来る日も来る日も、一日が満ちていました。密という言葉がぴったりです — コンパクトで、ぎゅっと詰まっていて、たるみがない。それを耐えられるものにしてくれたのは、人でした。彼らがとても温かかったので、プレッシャーが惨めさへと変わってしまうことは一度もありませんでした。出張でベトナムに飛んだこともあります。そこでは少しだけベトナム語を練習し、信じられないほど美味しいものを食べ — ベトナムのホスピタリティは別格で、決してあなたを空腹のままにしてはくれません — サッカーをして、ダナンのビーチ沿いを朝走る時間もなんとか捻出しました。同じ砂の上を一緒に走ったとき、人は違う種類のチームスピリットを築くのです。

クライアントは厳格で、非常に高い基準を持っていました。それがどれほどストレスフルになろうとも、まさにそれこそが私を成長させてくれたものでした — 技術面だけでなく、それまで本当に発揮する必要のなかった、ソフトスキルや人をマネジメントする側面においても。そして、私たちはリリースを成し遂げました。最後の一週間は壮絶でした — 最終ビルドを仕上げるためにクライアントのオフィスに直接出向き、何日も連続で深夜まで作業したのを覚えています — でも、私たちは出荷しました。みんな、よくやった。心からそう思います。

また、転機

2年半が過ぎ、そしてまた、あの古い感覚が戻ってきました。自分はまだ自分の落ち着きどころを見つけていない、という感覚です。何かが悪かったわけではありません。モンスターラボには良い思い出しかありません — プロジェクト、ディナー、同僚たち、その何人かとは今でも仕事を離れて定期的に会っています。でも、あの落ち着かなさは正直なもので、私はそれを信じることを学んできました。

そこで私は、今いる場所へと移りました。Spacelyです。LinkedInで見つけて、応募して、入りました。

でも、それは新しいページです — それについては、次の章でお話しします。

主な実績

モンスターラボでの時間を通じて取り組んだことを、もう少し具体的にまとめておきます。

シニアバックエンドエンジニア（Ruby）として入社。 スコープと給与の両方が大きくステップアップし、入社から約1年でテックリードに昇進しました。
大手日本の自動車会社のプロジェクトでバックエンドリードを担当。 チームメンバーが抜けたタイミングで前に出て、約半年かけてデリバリーまでやり遂げました。
デプロイのミスで上書きしてしまった本番データを、Aurora Point-in-Time Recovery を使って復旧。 そして、二度と同じことを起こさないための規律を身につけました。
大手日本のコングロマリット向けに、ChatGPT 搭載の RAG チャットボットのプロトタイプを構築。 AI エンジニアと連携し、Amazon Lex と Amazon Connect を用い、すべてを Terraform でプロビジョニングしました。
モンスターラボの認定資格サポートを活用して、AWS 認定資格を約七つ取得。 その理論的な基礎は、以来ずっと配当をもたらし続けています。
東京とベトナムのオフィスにまたがる8人のバックエンドチームを率いて、 要求水準の高いクライアント向けのゼロからの開発に取り組み、品質とタイトなスケジュールのバランスを取りながら、リリースを予定通り出荷しました。
スキーマファーストな三層アーキテクチャで開発。 フロントエンドとRuby on RailsのgRPCバックエンドの間にGraphQLのBFFを置き、共有のprotoスキーマからBFF側・バックエンド側の両方のコードを生成する構成で — それまで使ったことのない作り方であり、最終的にとても気に入りました。
Google Calendarと連携した予約システムを構築。 空き状況の確認と枠の予約を行い、その上にアプリケーション側の複雑なルール — ロール、参加者のスマートな割り当て、そして予約が成立する前にすべてが噛み合う必要のある、制約付きの選択可能な時間帯の集合 — を載せました。
Google BigQuery（OLAP）上に分析機能を構築。 大量のデータを集計して日次・週次・三ヶ月の各期間の分析を表示するもので、集計ジョブを OLAP データベースで一日一回走らせ、その結果を OLTP に読み込むことで読み取りを高速に保ちました。Overflow で手がけた類似の仕事が下地になっています。