Senior Backend Engineer — Tokyo

東京にはシニアbackend engineersの問題がある。才能の問題ではない — 日本のテック業界には才能が溢れている — アライメントの問題だ。一方には、堅牢でスケーラブルなシステムを必要とし、モダンなスタックで構築したい急成長中のFinTech企業がある。もう一方には、経験豊富なエンジニアがいるが、GoやKubernetesがまだバズワードでしかなく、日常的なツールではないレガシー組織に閉じ込められていることが多い。

Abbeal Tokyoでは、日本のFinTechクライアント向けにクリティカルなバックエンドプラットフォームを構築している。PowerPointコンサルティングではない。実際の取引を処理する本番コードで、許されないSLAを持つ。バイリンガルチーム(JLPT N2以上)に参加し、重要なシステムのownershipを取れるSenior Backend Engineerを探している。

この記事では、具体的に何を期待しているか、なぜこのポジションが存在するのか、そして2025年の東京でシニアESNで働くことが実際に何を意味するのかを詳述する — job descriptionの典型的なbullshitなしで。

このポジションが存在する理由

日本のFinTechクライアントには、off-the-shelfソリューションでは解決できない特定のニーズがある。10年前のJavaモノリシックシステムからモダンなmicroservicesアーキテクチャへの移行。トランザクション整合性保証を持つリアルタイムAPIを必要とする新しい金融商品のローンチ。10万から1,000万ユーザーへのスケールで、インフラが追いつかないことに気づく。

日本の文脈には制約が加わる：厳格な金融規制(FSA)、データ主権要件、JIS X 0208でまだ通信しているレガシー銀行システムとのインターフェース。標準的なAWSアーキテクチャをコピペして完成とは呼べない。

この技術的および文化的複雑さをナビゲートできる人材を探している。決済システムがZenginと国際カードで異なるidempotency keysの処理が必要な理由を理解している人。クリティカルサービスのdatabase移行が、4つの異なる部門との調整なしに火曜日の午後には行えないことを知っている人。

技術スタック：何を使い、なぜ使うか

主要言語としてのGo

バックエンドにはGoを標準化している。ドグマではなく、3年間のFinTechプロジェクトの後、ユースケースに最も適しているからだ：予測可能なパフォーマンス、シンプルなデプロイ(静的バイナリ1つ)、金融API典型のI/O-bound workloadsをうまく処理する並行性モデル、分散サービス向けの成熟したツール。

慣用的なGoに習熟していることを期待する、単にJavaを翻訳できるだけではなく。つまり：channelとmutexのトレードオフを理解し、キャンセルにcontext.Contextを使うタイミングを知り、メンテナンスが苦痛でないtable-drivenテストを書ける。

本番環境でのKubernetes

すべてのデプロイメントはKubernetesを経由する。ほとんどのクライアントにGKEを使用し、既存のAWS制約がある場合にはEKSを使う。podをデプロイする方法だけでなく、container内のメモリリークをデバッグし、パフォーマンスを損なわないresource limitsを設定し、実際に問題を検出するhealth checksを設定する方法を理解していることを期待する。

現実：本番FinTechでのKubernetesは、20%のYAML設定と80%のトラブルシューティング。rolling update後にサービスが応答に30秒かかる理由を理解する。負荷下でのみ現れる断続的なタイムアウトを調査する。水平スケール時に2分のcold startが許容できないため、startup timesを最適化する。

PostgreSQLとデータ整合性

PostgreSQLは引き続きリファレンスのリレーショナルdatabaseだ。ACID準拠が必要なトランザクションログ、ダウンタイムなしで進化するスキーマ、5,000万行のfull table scanがSLAを破壊するため最適化が必要なquery plansを扱う。

databaseの真の理解を期待する、基本的なSQLを書けるだけではなく。Isolation levelsとその影響。Index strategies (ケースに応じたB-tree vs GIN vs BRIN)。成長を管理するためのPartitioning。Replication lagとそれがアプリケーションアーキテクチャに与える影響。

PulumiによるInfrastructure as Code

インフラ管理にはPulumi(主にTypeScript)を使用している。Terraformに対する意図的な選択：HCLよりもtype checkingとunit testsを持つ実際のコードを好む。クライアントプロジェクト間で再利用可能な抽象化を構築できる。

Pulumiのエキスパートである必要はない — テンプレートと確立されたパターンがある。ただし、IaCアプローチ全般に習熟している必要がある：すべてバージョン管理、すべてレビュー可能、すべて再現可能。

求める人物像

Seniorは「X年の経験」を意味しない。アーキテクチャから実装詳細まで、完全なシステムのownershipを取る能力を意味する。チームが行き詰まったときに解決する能力。クライアントから来ても、ダメな技術選択にノーと言える能力。

• 実質的なバックエンド経験：本番環境でシステムを構築・維持した5年以上の経験、できれば信頼性が重要な領域(FinTech、healthtech、大量e-commerce)
• Ownershipマインドセット：コードを納品して次に移るのではない。本番環境で追跡し、障害時には夜中に起きて対応し、継続的に改善する
• 明確な技術コミュニケーション：非技術系ステークホルダーに複雑なトレードオフを説明でき、日本語と英語の両方で対応可能
• 実用主義：最適化すべき時と「十分良い」コードを出荷すべき時を知っている。技術的決定のビジネス文脈を理解している
• 技術的好奇心：楽しみでpostmortemsを読み、サイドプロジェクトで新しいアプローチをテストし、ツールについて論拠のある意見を持つ

言語要件：JLPT N2+が必要な理由

JLPT N2以上(または同等の実証可能なレベル)を求める。これは交渉不可だ。なぜか？クライアントは日本企業で、意思決定は日本語で行われ、仕様書は日本語で書かれ、インシデントは現地チームによって日本語で報告されるからだ。

Abbeal内部ではバイリンガルで機能する — Slackはスレッドに応じて英語/日本語が混在し、クライアントとのミーティングは日本語、純粋な技術的議論は英語。ただし、要件を理解したりクライアントとのレトロスペクティブに参加するために翻訳者に依存していては効果的に働けない。

N2で十分。ネイティブレベルの習熟は求めていない。ただし、60分の技術ミーティングを日本語でフォローし、Google Translateを3行ごとに使わずに仕様書を読み、理解可能なインシデントレポートを書ける必要がある。

具体的な業務内容

最初の3ヶ月は、既存のクライアントプロジェクトでramp-upする。具体的には：

1. 1-2週目：環境セットアップ、既存コードベースのcode review、他のシニアとのpair programmingでアーキテクチャとgotchasを理解
2. 3-6週目：中程度の複雑さの機能のownership、on-call rotationsへの参加(バックアップ付き)、オブザーバーとしての初クライアントミーティング
3. 7-12週目：完全な機能の設計と実装、microserviceの技術リード、アーキテクチャ決定への積極的参加

Ramp-up後の日常業務：

• 40% 開発：まだ定期的にコーディングする。シニアがスライドだけ作る会社ではない。
• 30% 設計とアーキテクチャ：新機能の技術的議論をリードし、RFCを作成し、提案されたアプローチに挑戦する
• 20% クライアントとのやり取り：仕様ミーティング、デモ、トレードオフの議論、時にはインシデント中のリアルタイムトラブルシューティング
• 10% 運用と継続的改善：On-call rotation (4-5週間に1週間)、パフォーマンス最適化、技術的負債のリファクタリング、CI/CDの改善

労働環境

柔軟なリモート、時折のクライアント訪問

東京ではremote-firstで機能している。ほとんどの時間を自宅で働ける。渋谷にオフィスがあり、必要に応じて対面ミーティングに使用できるが、週5日必須ではない。

ただし、クライアント先への時折の出張を想定してほしい — 通常月1-2回、ワークショップ、プランニングセッション、または現場対応が必要なクリティカルインシデントのため。日本のFinTechクライアントは重要な瞬間に物理的な存在を評価する。

チーム

東京チームは現在12人：8人のエンジニア(backend、DevOps、frontendのミックス)、2人の技術的product manager、2人のビジネス/クライアントマネジメント役割。全員日本語・英語のバイリンガル。バックグラウンドはミックス：海外で働いた経験のある日本人、長期間日本に在住する外国人。

チーム文化：実用的、直接的、無駄なプロセス排除。有用な時にstandupsを実施し、儀式のためではない。重要な決定を文書化し、20分のpair programmingで解決できることに3時間の会議を費やさない。アイデアに挑戦し、人には挑戦しない。

正社員またはフリーランス

希望に応じて正社員(正社員)または長期フリーランスで採用する。正社員は従来の安定性+日本の社会保険を提供。フリーランスはより柔軟性があり、通常は日額レートが高いが、自身の構造を管理する。

いずれの場合も、有効な就労ビザを持つ東京ベースが前提(このポジションではビザスポンサーシップは行わない — すでに日本で働く権利を持っている必要がある)。

シニアESNで働くことの意味

Abbealは典型的なESNではない。body shoppingはしない。クライアント先に単独で席を埋めるために送り込まない。構造的プロジェクトにチームで介入し、端から端までownershipを持つ。

具体的には：

• 他のAbbeal engineersと協働し、クライアントチームに単独で組み込まれない。一緒に構築し、互いをサポートする。
• 技術選択に発言権がある。クライアントはビジネス目標を定義し、技術的にどう達成するかは我々が定義する。クライアントが悪いアーキテクチャを望めば、挑戦する。
• プロジェクトの多様性：ミッションは通常6-18ヶ月。同じlegacy codebaseに5年間留まることはない。異なるFinTech領域、異なるスケール、異なる課題を見る。
• 商業的bullshitなし：6時間働いたのに10時間請求するふりを求めない。見積もりを人為的に膨らませない。クライアントは価値に対して支払い、時間ではない。

トレードオフ：スタートアップのequityも、FAANGで働く威信も、何年も最適化する内部プロダクトの快適さもない。ただし、政治なしのインパクト、不安定さなしの多様性、官僚主義なしの技術的挑戦がある。

応募方法(と評価方法)

長いプロセスはない。あなたの時間を我々の時間と同様に尊重する。

1. 初回コンタクト：履歴書 + GitHub/GitLab リンク(または書いたコードを示す同等のもの)を送付。このポジションに興味がある理由の短い段落。2ページの形式的なcover letterは不要。
2. 技術スクリーニング(60分)：バックエンド経験の議論、解決した具体的ケース、構築したシステムのdeep dive。アルゴリズムの記憶をテストするのではなく、どう考えるかを理解したい。
3. 実践課題(take-homeまたはpair programming)：簡略化されたFinTechユースケース向けbackend APIの設計。アーキテクチャの選択、edge casesの処理方法、テスト方法を見る。whiteboard codingのbullshitはなし。
4. チームとの最終ミーティング：文化、相互の期待、ロジスティクスについてのより非公式な議論。全員が合意すれば、オファーを出す。

全体のタイムライン：2-3週間、スケジュール次第。2ヶ月間引き延ばすことはない。

結論：もし共感したら

このポジションが存在するのは、具体的なプロジェクトがあり、実際の技術的問題を抱えるクライアントがあり、それに対処する確かな人材が必要だからだ。Bullshitなし、偽の約束なし。厳しいFinTech文脈での真剣なbackend engineering、何をしているか知っているチームと共に。

東京にいて、通常の企業的ナンセンスなしに重要なシステムを構築したく、説明されたプロフィールが経験に合致するなら、話すべきだ。Abbealサイトのキャリア東京セクションからプロフィールを送るか、応募前に具体的な技術的質問があれば、エンジニアリングチームに直接連絡を。