SRE (Site Reliability Engineer)

必須

• 自ら設計・実装したツールや自動化の仕組みを、自分以外の人が使う形で 継続的に運用・改善した経験 （言語は問いません。手元で完結するスクリプトのみのご経験は該当しません）
• サービスの信頼性や品質を数値で定義し、その数値をもとに チームや組織の意思決定を変えた経験 （SLI/SLO に限りません。独自に定めた指標での改善経験も歓迎します）
• 自チーム以外の開発チームに対して技術標準やプロセスの変更を提案し、 実際に定着させた経験
• AWS 等のパブリッククラウド上でのシステム設計・運用経験

歓迎

• 開発チームに常駐・伴走して信頼性向上を推進した経験
• ポストモーテム文化の導入・定着に関わった経験
• 障害訓練やカオスエンジニアリングの設計・運営経験
• コーディングエージェント（Claude Code、Codex など）を 日常的な開発・運用プロセスに組み込んで使っている
• AIエージェントを CI や運用フローに組み込んだ経験 （自動レビュー、インシデントの一次調査、ドキュメント整備の自動化など）
• AI活用を個人の効率化に留めず、チームや組織に展開した経験
• コンテナ技術（Docker, Kubernetes, ECS など）の経験
• Terraform 等による IaC の設計・運用経験
• 技術ブログでの発信、カンファレンス登壇、OSS への貢献

求める人物像

• 技術的な問題解決に情熱を持ち、継続的な学習意欲のある方
• チームワークを重視し、効果的なコミュニケーション能力を有する方
• 品質と効率性の両立を追求できる方
• 主体的に行動し、新しいアイデアを提案・実行できる方
• 組織の変革を促進し、他チームと協力して目標達成に向けて取り組める方
• 「これは自分の担当ではない」と言わずに、境界のない領域に手を出せる方
• 障害を減らすことと、リリース速度を落とさないことを、 両立すべき課題として考えられる方
• 他チームを説得し、動いてもらうプロセスそのものを面白がれる方
• 整っていない部分を、批判ではなく仕組みで解決したい方

応募について

• 現在SREを名乗っていない方も歓迎します。
• 開発・QA・プラットフォームなど、これまでの職種は問いません。

使用ツール

職務概要

• ニフティのSREチームは、特定のシステムを「守る」チームではありません。 @nifty光、ニフティポイントクラブをはじめとする各サービスの開発チームに入り込み、設計レビューから本番移行、運用の定着までを一緒に進めていくチームです。 技術で解決できることは技術で、プロセスで解決すべきことはプロセスで。 そのどちらも自分たちで手を動かして変えていける環境です。
• AIエージェントを前提とした働き方を推奨しています。 Claude Code、Codex などのコーディングエージェントを業務で利用でき、 SREチームでも GitHub Actions 上でのレビュー自動化やインシデントの一次調査などに組み込んで運用しています。 「AIをどう使うか」ではなく「AIがいる前提で運用をどう設計し直すか」を 一緒に考えていける方を歓迎します。

具体的な業務

• 配属直後からすべてを担当していただくわけではありません。 ご経験と志向に応じて、いずれかを起点にお任せします。

開発チームへの伴走（Embedded SRE）

• 特定のプロダクトチームに数か月単位で入り込み、設計レビューから本番移行まで伴走する
• 例：会員管理システムの FJcloud-V → AWS ECS Fargate / RDS 移行、Chef → Terraform 化 （社外カンファレンスで事例として発表しています。詳細は末尾の参考情報をご覧ください）
• 本番リリース前レビュー（Production Readiness Checklist）の実施と、レビュー観点そのものを開発チームへ移譲していく活動

信頼性の仕組みづくり（Platform / Enabling SRE）

• SLI/SLO の設計と、それに基づくリリース判断プロセスの運用
• New Relic / OpenTelemetry を用いたオブザーバビリティ基盤の設計と全社展開
• PagerDuty を用いたオンコール設計、インシデント対応、ポストモーテムの運用
• GitHub Actions による PRC プロセスの自動化（督促・集計・全社ダッシュボード）
• 障害訓練の内製化と全社展開、SRE研修コンテンツの開発

募集背景

• SREの活動自体は以前から各所で続いていましたが、 専任のSRE組織を立ち上げてから3年。 現在は全社への展開フェーズに入っています。 本番リリース前レビュー（Production Readiness Checklist）は全社プロセスとして定着し、 オブザーバビリティ基盤（New Relic）、オンコール体制（PagerDuty）、 障害訓練も順次整備してきました。 その内容は社外カンファレンスでも継続的に発表しています。 一方で、対象となるサービス・システムの数に対して人数が足りていません。 すでに動いている仕組みを、より多くのチームに届けていく段階で、 一緒に手を動かしていただける方を募集します

新しい技術を、検証で終わらせずに本番へ持ち込める

• Claude Code、Codex などのコーディングエージェントを業務で利用でき、 組織として活用を推奨しています。 SREチームでも、レビュー自動化やインシデントの一次調査に組み込んで運用しています。 「試してみたが結局使われなかった」で終わらないのは、SREが導入と定着の 両方を担うチームだからです。 自分が良いと判断した技術を、自分の手で 全社に届けるところまでやり切れます。 AIエージェントを前提に運用をどう設計し直すかは、まだ誰にとっても 答えが出ていない領域です。 その答えを、実際のサービス運用の中で 自分たちで見つけていけます。

一つのシステムではなく、組織の動き方そのものを変えられる

• SREチームの改善対象は、特定のシステムではなく全社です。 本番リリース前レビュー（Production Readiness Checklist）は、 その代表例です。 仕組みをつくり、開発チームに納得してもらい、 自動化し、最終的にはレビュー観点そのものを各チームへ移していく。 技術で解決する部分と、人と組織を動かす部分の両方があります。 自分の設計した仕組みが、数十のシステムと、そこで働く人たちの 判断の仕方を変えていく。 その手応えを得られる規模と裁量があります。

専門性を、社内でも社外でも伸ばしていける

• スペシャリストとして評価・処遇されるキャリアパス（N1!制度）があり、 マネジメントに進まなくても専門性で立てる環境です。 社外での発信も推奨しています。技術ブログでの発信、カンファレンス登壇、 コミュニティ活動を業務時間内の活動として位置づけており、 実際にメンバーが登壇・執筆を継続しています。 社外に出した内容が社内の評価につながり、社外で得た知見が 次の施策になる——その循環をつくれる環境です。 書籍購入補助、資格取得支援、社外セミナー受講補助のほか、 社内勉強会（SRE、クラウド技術ほか）も継続的に開催しています。