こんにちは。名刺アプリ「Eight」にてSREエンジニアをしている武井です。1年前にブリーチした髪を黒髪に戻すタイミングを失っております。なんやかんやあって最近染め直してしまったので、また半年後くらいに悩むことになりそうです。あの中途半端に染まってる時期をどうやって乗り越えればいいんでしょうか…
さて、今日はSREエンジニアである私が開発チーム（Product Dev グループ）へ半年間の短期留学（異動）した話をしたいと思います。
目次
きっかけと留学を決めた背景
きっかけは、私が育児休業から復帰する少し前のタイミングで上長から打診されたことです。メンバーの入れ替わりがあるなかでの組織体制の強化という目的もありましたが、私自身の成長も加味した上での提案でした。
私はインフラエンジニアとして2023年5月に中途入社し、今までインフラ領域を中心に業務をしてきておりました。そして、Sansan入社以前の経歴も含め、Webアプリケーションのバックエンド開発は未経験でした。
そうした自分のエンジニアとしてのバックグラウンドから、異動先で成果を出すことができるのか不安ではありました。ですが、後述する「SREとして感じていた課題」への対応と、自分自身の成長機会になると考え留学することを決めました。
今までの個人的な経験として、エンジニアとして一番成長させるのは「業務経験」であったこと、今後の育児に追われる中で新しい知識をつけるには業務経験が一番時間効率が良いと考えていたことも決め手となりました。
余談ですが、このブログでは読者のわかりやすさの観点から「留学」というワードを使っています。ですが、私はこの半年間「留学」というワードを意図的に利用しませんでした。というのも、個人的な意気込みとして、「学ぶ」というよりも「成果を前提とした学び」を意識して活動していたからです。
SREとして感じていた課題
私がSREとして日々の業務を進める中で、「プロダクトの信頼性と向き合い続けるにはインフラ以外の幅広い技術領域が必要」ということを課題として感じていました。
EightのSREチームは、元々Eightのインフラや運用の改善をしていたインフラチームが中心となって、2023年に発足したチームです。このような経緯から、元々インフラ領域を専門としていたメンバーがほとんどを占めており、チームの技術スタックもインフラ寄りに偏っておりました。
SLI / SLOといったSREのプラクティスに沿ってプロダクトの信頼性を可視化し、改善を続けるにはインフラ以外にも、ユーザーの体験やプロダクトが提供する価値、APIの理解などがSREエンジニアにも必要と感じていました。また、運用している中で発報されるアラートや問題に対して「ユーザー影響」という側面で具体的なイメージができておらず、解決までの対応を開発チームに委ねるだけになってしまうシーンもありました。
こうした状況から、インフラを専門としていた私がEightのドメイン知識、開発チームの視点やアプリケーション知識を理解することで、SREエンジニアとして技術領域が広がり、多角的な視点でシステムの信頼性向上に貢献できると前々から考えてました。
そのような考えもあり、実は今回の打診がなくても、将来的に自分から開発チームへの一時的な異動を打診するつもりで、育休中にも育児の合間にRuby on Railsの勉強をコツコツと取り組んでおりました。（ので、上長から打診されたときは、思考が読まれてたのかと思い驚きもありました。笑）
半年間の留学中にやったこと
2024年12月〜2025年5月までの半年間の中で、「最初の3カ月」と「あとの3カ月」では異なるチームに所属しました。最初の3カ月は「Featureチーム」として、Eightの事業活動で走る施策の中で必要となる機能の追加・改善に携わりました。あとの3カ月では「Enhancementチーム」に所属し、中長期的なプロダクトの改善活動に携わってきました。また、両チーム共通して「開発チームとしての運用」があるため、半年間通じてその運用を行ってきました。
以下の記事にてEight開発チームの組織体制や取り組みを詳しく紹介していますので、興味のある方はぜひご覧ください。
jp.corp-sansan.com
最初の3カ月のFeatureチームへの所属時点では、「きっかけと留学を決めた背景」のところでも記載した通り、バックエンド開発の業務経験もなかったため、基本的な知識の習得も行いました。開発チームに落とし込まれるタスクを担当しながら、以下のような基礎となる知識の習得に励みました。
- Ruby、Ruby on Rails、RSpecの基本的な知識
- Eightのドメイン知識
この3カ月間、開発サイクルに身を置くことで、Eightにおけるユーザーへの価値提供までの一連のプロセスを開発者視点で経験できました。
残りの3カ月間では、Enhancementチームとして主に以下のような取り組みに関わりました。
- APIの改修
- バッチ基盤の移行
【APIの改修】
長年Eightがサービス提供してきた中で、追加・削除された名刺の概念によって複雑性が増したAPIを作り直していきました。この作り直しの中で、Eightの中心となるユーザーと名刺の関係性や概念を深く理解できました。また、APIの「改修」であるため、ただ動くものを作るだけではなくパフォーマンス面をより意識したコードの書き方をペアプロを通じて学ぶこともできました。
【バッチ基盤の移行】
Eightが独自で構築しているバッチ基盤を、AWSの仕組みをより活用した基盤へ置き換えていきました。こちらも長年サービス提供してきた中で同じ仕組みを使いつづけることで、現在ではクラウドネイティブなアーキテクチャとは言い難い構成となっていました。そのため運用面やスケーラビリティで課題がありました。私がジョインしたタイミングで既に実装方式が確定しており、残りは移行作業を実施するだけのフェーズでした。しかし私は元々持ち合わせていたインフラ領域の知識を生かし、単なる移行作業だけでなくバッチ基盤自体や監視の仕組みの改善にも取り組みました。
最後に、数字としてわかりやすい成果を示すと、半年間で作成したPull Requestの数は63件でした。この結果から、Eightの価値提供やプロダクト改善にアプリケーション領域から一定の貢献ができたのではないかと考えています。
半年間の留学による変化
半年間の開発チームへの留学によって、アプリケーション領域やEightのドメイン周りの知識が一定身についたことにより、特に以下の効果を感じています。
- アラートへの反応
- 開発チームとのコミュニケーション
【アラートへの反応】
システムアラートに対して、インフラ領域以外の知識が身についたので「自分の守備範囲が広がった」感覚があり、より素早い反応や対応ができる範囲が広がりました。
アラートの内容がアプリケーション領域に起因するような内容でも、コードや例外から原因を探る力がついたので「このアラートは自分でも対応できるのか」と考えることがなくなり、素早い反応に繋がりました。
また、実際にアプリケーション起因のアラートでも開発チームとともに原因を探ることができるようになったため、SREとしてシステムの信頼性向上に向けて多角的な視点から原因追及と改善に動けるようになりました。
【開発チームとのコミュニケーション】
開発チームに加わり、仕様調査から実装・テスト・リリース・運用と一連のサイクルを経験しました。今までは「SREから見た開発」だったものが、「開発の中にいる自分の視点」へと変わったことで、会話の粒度やタイミングが自然と揃うようになったと感じました。例えば、開発者からSRE向けに依頼されるタスクについて、簡単な確認だけでステータスや期日に対する温度感を把握できるようになりました。これによりコミュニケーションが円滑になったと感じています。
また、開発者との共通言語となるアプリケーションコードを読むことができるようになったので、コードベースで会話を進めることができるようになりました。これにより、認識の食い違いが少なくなり、「現在生じている問題を改善するためにはどこを変更すれば良いのか」「このコードを変更することによるリスク」といった内容を具体的に議論できるようになりました。
今後の展望
半年間の短期留学を経て、2025年6月よりSREチームに戻りました。短期留学での経験を生かして、以下を意識していきたいと考えています。
- 自分自身のアプリケーション領域への理解を深める
- Eightのエンジニア組織全体に「自分の専門領域以外へのチャレンジ」を浸透させる
1点目は、この半年間で得た知識を無駄にしたくないという気持ちの現れです。知識は使い続けないとすぐに忘れてしまいます。SREに戻ったあと、今までと同じSRE業務を続けるだけではすぐに元に戻ってしまうと思われます。
2点目は、今回自分の経験をEightのエンジニア全体に広めることで、強い組織になると思ったからです。エンジニアが自分の専門領域だけでなく、他の領域にも興味を持ち、理解を深めることで、チーム間のコミュニケーションがより円滑になります。これにより問題解決のスピード向上に繋がります。また、異なる視点からプロダクトを見ることで、より良い改善案が生まれる可能性も高まります。私の今回の短期留学では、特にバッチ基盤の移行において、インフラとアプリケーションの両方の視点から、より効率的で信頼性の高いシステム設計や運用改善を提案することが出来ました。今後は、この経験を組織全体に共有し「領域を超えた学び」が当たり前になる組織になるようにリードしたいと思います。技術的な垣根を低くすることで、より柔軟で強靭なエンジニアリング組織が構築できるはずです。
この実践として、直近では「SREチームがアプリケーション領域へ活動範囲を広げるための取り組み」を行う予定です。ここでうまくSREチームに浸透させ、私自身も継続的にアプリケーションの理解を深めることができた後に、逆のパターンとして「開発チームがSREの領域へ活動範囲を広げる活動」を考えています。
さいごに
半年間、ほぼ未経験な技術領域にチャレンジしたことは、とても良い成長の機会となったと感じています。この半年間で得た知識と視点を生かし、技術領域を越えた「プロダクト全体を見渡せるエンジニア」として成長し、専門性と広い視野でEightの成長と信頼性の向上に貢献していきます。
この挑戦は、ほぼ未経験なエンジニアを受け入れてくれた開発チームと、人的リソースが減るにもかかわらず送り出してくれたSREチームの協力があってこそ実現できました。また、異動のきっかけを与え、成果が出にくい時期も辛抱強く支援してくれた上長の存在が大きかったです。改めて感謝したいと思います。ありがとうございました。
最後に、Eightでは一緒に働いてくださるエンジニアを募集中です。
専門性を深めながらも領域を越えた成長にチャレンジしたい方、SREとしてアプリケーション領域にも興味を持っている方、または開発者としてインフラにも関わりたい方、ぜひ一緒にEightを作り上げていきましょう！
