初めまして、エンペイにSREとして入社しました高木（@tkg_216）です。
2023年4月にエンペイにJoinして1ヶ月ほど経ちましたので、入社エントリ兼SREとしての取り組みについてざっくりと紹介したいと思います。
目次
1. 自己紹介
2. エンペイのSRE
3. 入社してからの1ヶ月間
4. これからの展望SREとは？ と思う方向けに一般的な定義を引用しておきます。
ただ、実際のSREとしての取り組みは各社各様なところが多いのと、この記事内でSREについて深掘りするわけではないのであまり意識しなくても大丈夫です！
SRE（Site Reliability Engineering）とは、元々Googleが提唱したシステム管理とサービス運用に対するアプローチです。SREの特長は、信頼性をシステムの重要な機能の1つと位置づけている点です。SREでは、サイトやサービスの信頼性を向上させるため、コードによって手作業や繰り返し行われる作業（トイル）を減らしたり、システムを自動化して作業量の増大に対応することを重視しています。
自己紹介
- 経歴
- ネットワーク機器のソフトウェア開発
- 約4年(複合機メーカー)
- IoT/Webアプリケーション開発
- 約3年(スタートアップ→電気電子部品メーカーの新規事業部)
- SWE/SRE(半々くらい)
- エンペイ入社経緯
- AWSとかSRE領域への関心が強く、SREに専念してみたかった
- SREとしてのスタンスがマッチしていそうな気がした
- 事業への共感、成長フェーズ
- 働きやすそう
- 趣味
- バスケットボール
- その他
- 2023年 AWS Community Buildersにサーバーレスカテゴリで選ばれました🎉
※成長フェーズが良かったという点を補足すると、これまで、成熟しすぎたフェーズで運用面が固まりすぎていたり、アーリーなフェーズで運用面より新規機能追加を優先している環境にいることが多かったです。その中だと、SRE領域らしき課題が限定的だったり、アプリケーションの実装を優先するケースが多かったので重視していました。
エンペイのSRE
これまで
- 業務委託の方がIaC(CDK)やCI/CDパイプラインをメインで実装
- バックエンドエンジニア数名がCDKの修正などを都度行う
現状
- 専任のSREとしては私が1人目
- それ以外は継続
エンペイでのSREへの期待
アーキテクチャ検討、アプリケーションの信頼性の向上、など一般的なSRE領域の課題解決が望まれていますが、特徴的だと思った部分を抜粋します。
インフラ関連技術の社内への浸透
エンペイでは、SWEとSREが分離された組織体制にしたいとは思っていません。SWEが自分たちでインフラ部分も見ることができるように技術的な啓蒙活動を行うことが期待されます。
エンペイでは、開発者が技術領域を広げていくことに前向きなところがあり、これまで経験していない領域や技術に挑戦することを推奨する風土があります。実際、アプリケーション領域を中心に経験してきた若手エンジニアが今期からAWS/インフラ領域に挑戦し始めたりしています。
このあたりの考え方が、今までアプリケーション開発をしてきた経験や、インフラ領域やSREに専念するとしてもサービス開発に向き合っていきたいという自分の考えと一致していると感じました。(一般的はSREがサービス開発と向き合っていないという意味ではないです)
SWEがSRE領域も行うのと逆で、SREとして入社した私がバックエンドやフロントエンドなどのSWEとしての業務を将来的に行う可能性もあります。
入社してからの1ヶ月間
1. 新規プロダクトの開発
入社と同タイミングで新規プロダクトの開発チームが発足したので、AWSなどのインフラ領域担当者としてチームに加わり、開発をしていたのが1ヶ月間の主な業務内容です。
細かい技術的な説明は省略しますが自分のやったこと(やっていること)としては、アーキテクチャの検討やCDKを使ったインフラ構築、CI/CDパイプラインの構築などを行っています。既存サービスのIaCやCI/CDパイプラインが既にあるので、取り入れられるものは取り入れようという想いと、今までと全然違う構成にしてしまって戸惑いが生じるのを避けるために、キャッチアップしながら検討を進めました。
検討の結果、パイプライン自体に問題があるとは感じなかったのですが、
- パイプラインの各ステージの繋がりが初見で分かりにくく認知コストが高い
- 既存メンバーがパイプラインの修正を行う心理的ハードルが高い
等の課題があると感じたので、無理に既存の仕組みを踏襲しない方針にしました。
ざっくりとした方針としては、
- トランクベースのCI/CDパイプライン(GitHub flowのようなもの)
- GitHub ActionsかCodePipelineをメインで使ってデプロイフローをわかりやすくする
のように決めて、チーム内でシェア、議論、決定しました。これでどうだったのかについては、まだサービスインしていない段階なので追々振り返りたいと思います。
また、この開発プロジェクトでは、若手エンジニアがAWS/インフラ領域への挑戦をしたいという裏テーマ？もあり、分担しながらタスクを進めています。分からないところとか方針について相談事があれば都度相談を受けたりしながら進めてはいる形ですが、普段1人でやっているとあまり気にせず流してしまっていることや、自分がAWSに中途半端に慣れていることで見落としている部分について質問してくれることもあり、答えている立場でありながら勉強になる面もあって良かったです。
特に、トランクベースについて提案した後に自分なりにトランクベースを解釈しようと色々調べた動きがあって、SWEとSREの距離がなくなっていきそうな流れを感じることができて嬉しかったです。
2. 将来に向けた動き
入社してからの業務としては新規プロダクト開発にかける時間がほとんどでしたが、これから先は、既存サービスのenpayについてのSRE業務やサービス横断した課題に取り組んでいくことも増えていく予定です。また、開発組織とAWSの距離を近づけるような取り組みもしていく必要があると思って、いくつかの取り組みを実施したり、開始しました。
- AWS関連
- SAとの打ち合わせの実施 | 継続的に相談できる体制作り
- AWS Summitへの参加
- 外部の人との交流
- 弊社担当AWS営業の方と雑談
- 週刊AWSの内容の共有
- ピックアップして紹介したら反応が良さそうだったので継続
- 方法については試行錯誤中
- 既存サービス(enpay)のキャッチアップ
- enpay開発チームとの打ち合わせ/ヒアリング
- BIツールの現状キャッチアップ
- SRE関連課題のチケット化
→社内向けワークショップ開催に繋がりそう
3. 入社1ヶ月を通しての所感
まずは、新規のプロダクト開発開始時に入社し、チームの立ち上げを一緒にしていくことができて良かったと思います。同じ会社の中で色々なフェーズを経験できるのはエンペイの特徴の1つだと感じたのと、入社経緯としては成長フェーズを選んだと書きましたが、新規の開発は開発で好きなことを再認識しました。
入社直後はいろいろな不安があったりしましたが、多少成果も出すことができたり、チームや会社にも徐々に慣れてきました。抽象的な表現ですが、「やさしい」人が多く、フルリモートでもコミュニケーション面で困ることがあまりないと感じています。
これからの展望
先日開催された Pepabo Tech Conference #20 春のSREまつりや、Bill One SREチームのブログ で、「自分たちの事業におけるSREの取り組みと面白さについて」や「SRE組織のビジョンとミッション」を明文化している例を目にする機会があり、刺激を受けました。
組織によって多種多様なSREのあり方について、エンペイでも明文化していき、社内外で正しく認知される状態を目指していきたいと思います。
とはいえ、現実的には理想を掲げすぎず、
- 着手できていない優先度の高い課題の解決
- コスト削減やIAMの管理
- Datadogを最大限活用する
- SRE領域のバックログの整理
- 社内でAWSの認知コストを下げるための動き
等を地道にやっていくことになるかと思います。
また、個人的な話ですが、AWS Community Buildersに選ばれたので、技術ブログの執筆やイベントの参加なども併せてやっていけたらと思います。
最後に
いかがだったでしょうか。
個人的な振り返りが中心になってしまいましたが、エンペイにSREとして入社した入社エントリ兼1ヶ月のSRE活動振り返りになります。
少しでもエンペイのSRE、開発組織について解像度が上がれば幸いです。
この記事を読んで弊社に興味を持たれた方がいらっしゃれば、以下からエントリーしていただけると嬉しいです。エンジニア以外にも事業開発や営業なども募集しています。カジュアル面談も受け付けていますのでお気軽にご連絡ください。
