## 信頼性を、運用の頑張りではなく、エンジニアリングで高める。
1年でサービス規模は約3倍になりました。その先に必ず来る壊れ方に、起きる前に手を打つ。繰り返す運用作業はコードに置き換え、障害が起きても原因をすぐに説明できる状態をつくる。
**Bring OutのSREは、AIを活用するプロダクトと開発組織が、速くリリースしながら顧客の信頼を守れるよう、信頼性・Observability・自動化の基盤を設計し、つくるエンジニアです。**
アラートやチケットを処理する役割ではありません。どの信頼性指標を改善し、どの運用作業をなくし、開発者にどんな基盤を提供するのか。それを自分で決め、ソフトウェアで実現していく仕事です。
## なぜ今、このポジションなのか
Bring Outは、商談・社内会議・サービス現場の対話データをAIで解析し、経営判断に使える一次情報に変えるプロダクトを提供しています。エンタープライズ企業を中心に導入が広がり、サービス規模はこの1年で約3倍に成長。SUBARU、日本M&Aセンター、パソナ、NTT西日本など、大手20社以上に利用いただいています。
顧客が預けているのは、社内会議や商談という最も機密性の高いデータです。1社が複数の部門・拠点で使うことが前提のため、顧客が1社増えても負荷は1社分では増えません。可用性とパフォーマンスの毀損は、機能の欠陥以上に信頼を損ないます。
一方で、これまで基盤レイヤーは、組織としてのオーナーシップが明確になっていませんでした。責任の所在が曖昧な領域が生まれ、その制約が機能開発のボトルネックになり、システム原価の改善にも全体を見て手を打つ人がいない状態でした。そこでBring Outは、開発組織を「アプリケーション開発」と「基盤・SRE」の2層に整理し、LLM・課金・対話分析にオーナーシップを持つPlatformチームを新設します。SREはPlatformチームの一員として、LLMを含む基盤全体の信頼性に責任を持ちます。
SREは現在1名が在籍しており、今回の募集で1名を増員し、2名体制にします。
すでに兆候が出ている課題もあります。
- データベースの瞬間的なCPU上昇と、接続数の余裕不足
- ストレージ容量の継続的な増加
- 文字起こし用GPUの調達リスク
- LLMを含むAI処理のレイテンシとコストの増加
「いずれ顕在化する」課題ではなく、すでに見えている課題です。完成した基盤を運用するのではなく、在籍するSREと役割を分担しながら、これからのBring Outの信頼性の土台を設計していただきます。
## お任せしたいこと
まずは、システムの状態を見える化し、守るべき水準を決め、LLMを含む基盤のスケールに先回りすることに集中していただきます。そのうえで、自動化と開発者体験の改善へ領域を広げていきます。
### Observabilityの整備
- 「Monitoring」中心だった運用を、システムの内部状態を説明できる「Observability」へ引き上げる
- ログ・メトリクス・トレースを統合し、障害時に原因を追える状態をつくる
- アラートを見直し、対応が必要なものだけが確実に届く設計にする
「アラートは鳴っているが、何が起きているかは分からない」を終わらせることが、最初のゴールです。
### SLI/SLOの導入
- 可用性・レイテンシ・処理の完了時間など、顧客体験に直結する指標をSLIとして定義する
- 開発チームやビジネスチームと、運用すべき水準をSLOとして合意する
- SLOの状況を、リリースや改善の優先順位を決める判断材料として使える状態にする
数値を決めることより、「この水準で運用する」と組織に納得してもらうプロセスの設計が難所になります。
### キャパシティプランニングとスケーリング
- データベース、ストレージ、文字起こし用GPUの負荷を予測し、増強・調達の計画を立てる
- 特に調達リードタイムのあるGPUについて、需要の予測と発注判断を担う
- データベースのパフォーマンス改善や、接続数・負荷のボトルネック解消を進める
### LLMの運用管理
LLMの運用管理は、SREの担当領域です。プロダクトの中核にあるAI処理を、信頼性とコストの両面から管理します。
- LLM APIや文字起こし処理のレイテンシ、エラー率、レート制限、トークン消費量、コストを可視化し、管理する
- 外部APIの遅延や障害に備えて、リトライ、フォールバック、キューイングを設計・実装する
- モデルやプロバイダの変更を、品質・レイテンシ・コストへの影響を確かめながら安全に進められる仕組みをつくる
- 処理量の増加に対して、品質を保ちながらコストが線形に増えない構成をつくる
### 基盤起因の障害の再発防止
オンコール・インシデント対応のプロセスはTechnical Supportチームが持ちます。SREは、基盤が原因の障害について、技術的な原因究明と再発防止策の実装に責任を持ちます。
- インシデント時に、Technical Supportチームや開発チームと連携して基盤側の調査を担う
- 振り返りで特定した基盤側の課題について、再発防止策を実装まで見届ける
- 調査に必要なダッシュボードやランブックを整え、次の障害で原因に早くたどり着ける状態をつくる
### その先に広げていく領域
基盤の見える化と水準が整い始めたら、次のテーマにも取り組んでいただきます。
- **トイル削減と自動化**：繰り返す運用作業を、コード、セルフサービス、自動修復に置き換える。AIによるアラート要約や調査支援、ランブックの自動化も検証する
- **開発者体験の向上**：IaC、CI/CD、デプロイの仕組みを整え、各チームが自律的に安全にリリース・運用できる基盤を提供する
- **アクセス権限とセキュリティ**：過剰な特権を見直し、一時付与や最小権限、シークレット管理の仕組みを整える
- **コストと非機能要件の意思決定**：システム原価を可視化し、可用性・パフォーマンス・コストのどれをどの順で守るかを決め、その判断を組織に説明する
## 大切にしたい指標
信頼性は、何も起きないことでは測れません。顧客が安心して使い続けられているか、障害から学び、同じ問題を繰り返していないかを重視します。
- **SLO達成率**：定義した水準を、実際に守れているか
- **障害の検知・復旧までの時間**：顧客が気づく前に検知できているか。基盤側の原因特定にどれだけかかっているか
- **原因が分からない障害の比率**：Observabilityが機能しているかの実質的な指標
- **基盤起因の障害の再発率**：再発防止策が実装まで到達しているか
- **システム原価**：処理量や売上の伸びに対して、インフラとAI処理のコストが線形に増えていないか
- **トイルの量**：手作業の運用が、自動化によって減っているか
具体的な目標は、入社後にベースラインを計測したうえで一緒に設定します。
## 向き合う技術
| 領域 | 技術 |
| バックエンド | Node.js / TypeScript / Python / GraphQL |
| データストア | PostgreSQL / AWS S3 / DynamoDB |
| インフラ | AWS / Terraform / Docker / GitHub Actions |
| 可観測性 | Datadog等のObservabilityツール（導入・拡充はこのポジションの担当領域） |
| AI処理 | LLM API、文字起こし用GPU |
すべての技術に最初から精通している必要はありません。本番環境で起きていることを根拠に基づいて説明し、ソフトウェアで改善できることを重視します。
