シニアSRE

必須

• Kubernetes を本番で運用し、設計・改善まで踏み込んだ経験（監視の一次対応のみは該当しません）
• Terraform 等による Infrastructure as Code の設計・運用経験
• クラウド（Google Cloud または AWS）での本番サービスの運用経験
• Linux / ネットワークについて、障害時に原因をレイヤまで降りて特定できる知識
• システム上の問題（例: パフォーマンス上のボトルネック等）を根本的に解決する姿勢
• 自分の担当範囲を越えて、他チームを巻き込んで改善を進めた経験

歓迎

• Envoy Proxy や Istio など Service Mesh の運用経験
• Google Cloud 上でのサービスの構築・開発・運用経験
• 大規模サービス・分散システムの開発、運用経験
• Go を使用したソフトウェア開発経験
• エッジ（CDN / WAF）まで含めたパフォーマンス改善の経験
• クラウドコスト最適化を主導した経験（コミット購入の設計、コスト配賦、ベンダー交渉など）
• 可観測性基盤（Honeycomb / Datadog / OpenTelemetry 等）の設計・導入経験
• SLO / エラーバジェット / ポストモーテムを組織に導入した経験
• LLM / 生成AI を使うプロダクトの基盤運用経験（推論基盤、レート制限、コスト管理）
• 医療・金融など規制産業でのインフラ運用経験
• データパイプラインの構築経験
• サーバーレスアプリケーションの経験
• AIエージェント / LLM を運用業務そのものに組み込んだ経験
• 複数チームにまたがるプラットフォーム戦略を描き、実行まで持っていった経験

求める人物像

• 他のチームも巻き込みながら、重要なところを進められる人を求めています。
• これからのインフラがどうあるべきかを描き、自分も手を動かしながらそこへチームでどう到達するかまで考えられる
• 全社に効く仕組みを、他チームを巻き込んで着地させられる
• 信頼性・コスト・開発速度をトレードオフとして諦めるのではなく、信頼性が高いからこそ速く動ける状態を設計できる
• 障害の一次対応者ではなく、障害が起きにくい構造と、起きたときに学習が回る仕組み（SLO / ポストモーテム）を組織に入れられる
• プロダクトチームに SRE プラクティスを浸透させ、Platform を「使われる基盤」にできる
• 私たちを広げる（Expand “WE”）**：所属・契約・職種・参画の深さなどの違いを越えて、同じ目的に向かい価値をともにつくる人を仲間として向き合う姿勢。立場の違いを超えて共に価値をつくり、医療エコシステムを動かしていく
• 世界を変える（Impact, Impact, Impact）**：問うべきは、どれだけ手を動かしたかではなく、どれだけ世界を動かしたか。「これは誰の何を変えるのか」という本質を深く理解し、必要な打ち手を着実に積み上げて、変わるまでやり抜く
• エースカードで勝負する（Play Your Ace）**：並の能力は、もはや価値にならない。自分の「好き×得意」を見極め、その一点で誰よりも深く考え、世界最高レベルの強みへ育てる。苦手を埋めるより、強みのレバレッジを最大化する

使用ツール

Description

• Ubie の SRE は「サービスを落とさない人」ではなく、医療産業で、生成AIを使うプロダクトを安全かつ経済的に動かし続けながら開発速度を最大化する仕組みをつくります。
• 少人数のプラットフォームチームが、全社のプロダクトのインフラを設計・開発・運用しています。CDN / WAF を含むエッジ層、Kubernetes + Istio(Envoy) のサービスメッシュ、マネージドDBまでを一つのチームで担当しており、ボトルネックがどの層にあっても、そこまで降りて直せる（直せる権限がある）環境です。
• 担当領域は自分で広げることができます。
• セキュリティと可用性を高めながら、開発速度を制約しない。むしろ最大化する。 ここがこのポジションで最も重要なことで、下に挙げた課題はすべてそのための手段です。
• 特に生成AIが出てきたことで、開発のあり方そのものが変わりつつあります。これからの開発速度を最大化するインフラの形は何なのか。 その答えを、これから作っていくフェーズです。

このポジションで解く課題

• 1. 開発速度を最大化するインフラの形をつくる
• セキュリティと可用性を高めることが、開発速度の制約になってはいけない。トレードオフとして諦めるのではなく、信頼性が高いからこそ速く動ける状態をつくる
• 生成AIの登場で、開発の速度も進め方も変わりつつある。これからの開発速度を最大化するインフラの形は何か、を問い直しながら作る
• 以下の課題は、すべてこの目的につながっている
• 2. 生成AIプロダクトを支えるプラットフォーム
• モデル単価・レート制限（TPM）・レイテンシがプロダクト設計を直接縛る世界でのキャパシティプランニング
• LLM 利用量がそのまま原価に出るため、機能・信頼性とコストを同じテーブルで議論する必要がある
• 3. マルチリージョン・規制対応
• 日本と米国でプロダクトを展開しており、国ごとに医療関連のレギュレーションが異なる
• 「準拠しているから遅い」ではなく、準拠したまま開発速度を落とさないインフラを設計する
• 4. エッジからデータストアまでを一気通貫で見る
• CDN / WAF を含むエッジ層、Kubernetes + Istio(Envoy) のサービスメッシュ、マネージドDBまでを一つのチームで担当する
• ボトルネックがどの層にあっても、そこまで降りて直せる
• 5. FinOps — コストを経営の言葉に翻訳する
• クラウド費用に対して、コミット購入（CUD）の設計、環境ごとの spot 化、不要リソースの撤去までエンジニア側で意思決定している
• 「誰がいくら使い、どの機能が儲かっているか」を出すコスト配賦・原価接続の議論まで踏み込む
• ベンダーとの契約交渉・相見積もりもエンジニアが主導する
• 6. AIエージェントを運用に組み込む
• 社内向けの Infra Agent が、調査・問い合わせ対応・コスト分析の一部をすでに担っている
• 人間の SRE は「エージェントに任せる範囲を設計し、任せられない部分に集中する」働き方へ移行しつつある
• この移行そのものを設計したい人にとっては、かなり珍しい実験場
• オンコール体制はこれから整備するフェーズ。どこまでを自動化とエージェントに寄せ、どこからを人が持つのかを、ゼロから設計できる

想定される主な業務

• 各国やプロダクトごとのレギュレーションに準拠したインフラ環境の開発と運用
• Infrastructure as Code の実践と普及による適切なプラットフォームの管理
• パフォーマンスの可視化や可観測性を実現する仕組みの提供
• SRE のプラクティスの社内浸透を通じたサービスレベルの向上
• コストの最適化
• トイルの継続的な削減

このポジションで期待すること

• 他のチームも巻き込みながら、重要なところを進められる人を求めています。
• これからのインフラがどうあるべきかを描き、自分も手を動かしながらそこへチームでどう到達するかまで考えられる
• 全社に効く仕組みを、他チームを巻き込んで着地させられる
• 信頼性・コスト・開発速度をトレードオフとして諦めるのではなく、信頼性が高いからこそ速く動ける状態を設計できる
• 障害の一次対応者ではなく、障害が起きにくい構造と、起きたときに学習が回る仕組み（SLO / ポストモーテム）を組織に入れられる
• プロダクトチームに SRE プラクティスを浸透させ、Platform を「使われる基盤」にできる

チームと働き方

• 少人数のプラットフォームチームが全社のインフラを見ています。担当領域は自分で広げられます
• Terraform / GitHub Actions / Design Doc レビューの文化