こんにちは。プロダクト開発部の 
id:ut61z です。
私は 2022/10 からSRE留学という社内制度を利用して、SREチームに所属しています。弊社のSRE留学制度については以下のliaob88さんの記事に詳しいので興味がある方は御覧ください。
もともとバックエンドエンジニアとしてRailsのアプリケーション開発を行っていましたが、運用の一環でアプリケーション実行環境をEC2からECSへ移管する経験をし、それを皮切りにインフラ、AWS、SRE、DevOps などに興味を持ちました。
あるとき上司にSRE留学をしてみない？と提案されたのをきっかけに、自分でもできるのか？と不安を抱きながらもおもしろそうだなという感情が勝り、SRE留学を希望しました。
この記事では、実際に日々の業務を行っていくなかで感じたプロダクトチームとSREチームの違いや、ソフトウェアエンジニアとSREの業務の性質の違いについてなどを挙げていきたいと思います。
普段プロダクト開発に従事しているけれど、SREはどのようなことをしているのか？興味はあるけど専門知識が必要でハードルが高いのでは？といった疑問に対してなにかヒントになれば幸いです。
日々の仕事の進め方
日々の仕事の進め方は、プロダクトチームとSREチームでほぼ差異はないと言っていいでしょう。
今はカンバンでタスク管理をしていて、毎朝優先度の高いものを確認し、上から順に取り組むというスタイルで進めています。月に一度タスクのリファインメントを行い、優先度の見直しも行います。また、隔週で振り返りを行い、2週間で起こったできごとをベースに次の2週間でトライすることを定めて、業務のカイゼンにつながるように努めています。
タスクの性質
SREチーム特有の性質として、各プロダクトチーム、あるいは他部署からの依頼やシステムアラートなど、リアクティブに反応するようなタスクが比較的多いということが挙げられるでしょう。
- インフラリソースの追加・変更・削除 (Terraform修正) のレビュー
- 各チームから依頼を受けて行うSRE管轄のインフラリソースの操作オペレーション
- システムアラートや障害発生時の対応
- その他インフラに関する相談受付
SREは、サービスの信頼性を維持しつつ、プロダクト開発を行うエンジニアがより安全に素早く開発を行うことをサポートする責務があるため、直接的なフィードバックを得る「顧客」は、サービスのユーザーであると同時に、プロダクト開発を行うエンジニアでもあります。
誰に価値提供を行うか？という点でプロダクトチームがサービスユーザーであるのに対して、SREはプロダクトチームのエンジニア(の比率が高い)という捉え方もできるでしょう。
チームトポロジーでいうところの、ストリームアラインドチームとプラットフォームチームの違いと言い換えることもできそうです。
それ以外にも、トイルになりがちな、利用している各外部サービスとの契約、見積、アカウントの作成、権限付与なども行っています。このあたりの作業は、自動化したり、権限を渡して各チームでできないかというのを模索している最中で、エンジニアリングが求められるところだと感じています。
インフラ知識
言わずもがなですが、SREはインフラ知識が必要で、プロダクトチームのソフトウェアエンジニアより多くのそれを求められます。
しかし、SRE留学をしてみて逆説的に体感したのは、プロダクト開発においてもインフラ知識は必要だということです。
SREとして相談を受ける立場に立ってみると、要求を実現するための要素としてインフラ知識は一定欠かせず、インフラとアプリケーションを総合的に考慮したうえでの意思決定が求められるシーンがあると感じました。
「これを実現したいからインフラについてこうしようと考えている」という相談ができるような知識がプロダクトチームにあると、SREはそれに対する適切なフィードバックをしやすいです。少し話はそれますが、そういったプロダクトチームになるために、SREとプロダクトチームのエンジニアで接点を持つ機会を増やすべく、まさにSRE留学を含めたいくつかの施策をSREとして行っています。
プロダクトの知識
逆にアプリケーションの振る舞いや、ドメイン知識、事業戦略などについてプロダクトチームのみが知っているべきで、SREは知らなくてもよいかといえば、それもNOだと言えます。
インフラ設計や、SREingを実践していくうえで、それらのプロダクトの知識もまた必要不可欠だからです。
とはいえ、各チームが担当するすべてのアプリケーションの振る舞いを詳細に把握するのは現実的ではないでしょう。とくにClassiは、様々な機能を提供しているので全体像を把握するだけでも一苦労です。
ただ、各プロダクトチームから相談を受けることで、俯瞰的にプロダクトを見ることができるのもSREチームの特徴だと感じました。SRE留学前の一プロダクトチームに属しているときの自分では、そこまで解像度が高くなかった別チームの機能についても、インフラ面でのサポートやTerraformのPRレビューを通して理解を深めることができました。
システムアラート
システムアラート対応はSREだけが責任を持って対応しているかというと、弊社の場合はそうではありません。プロダクトチームのエンジニアであっても、即座に気づいた人が反応します。自チーム/他チーム問わず、まずはなにか起きれば反応して有識者を募れる組織だと言えます。
そのような姿勢は以下の記事でも紹介されています。
システムアラートの発生から各チームのエンジニアが協力して最速で解決を目指すという姿勢は、SREの立場に立ってみると改めてとても頼りになります。
そもそもアラートのためのモニタリング設定や、すぐに切り戻しができるようなデプロイパイプラインの構築などがプロダクトチームで当たり前にできているからこそ、そのように反応ができる状態に至っているので、単にシステムアラートに反応するということを超えて、SREingがプロダクトチームに浸透していることを実感します。
システムアラートへの反応及び信頼性への意識については、SREとプロダクトチームで差異はないと言えるんじゃないでしょうか。
違いに注目することで見えてきたもの
いくつかプロダクトチームとSREチームの違いを挙げてみましたが、SRE留学を通じて私が感じたのは、プロダクト開発・運用の一側面を担っているという観点においては、SREチームもプロダクトチーム(の亜種)のような存在ではないかということです。
実はSRE留学をする前は、SREと聞くと特殊な領域で作業する特殊な技術分野に尖った"専門家集団"のような印象があり、少し敷居が高かったのですが、中に入ってみると、プロダクトをよりよいものにするという目的下において、SREチームはプロダクトチームと地続きな存在では？という印象に変わりました。
また、プロダクトをよりよくするには、インフラの知識やSREingのスキルやマインドセットがどうしても必要になってくるという逆の視点からも、プロダクトチームとSREチームは地続きな存在だと言えそうです。
もちろん違いもあり、さきにあげたように、プロダクトチームはストリームアラインドチーム、SREチームはプラットフォームチームという捉え方もできるので、業務の性質として異なる点もあります。たとえば、特定のインフラリソースの取り扱い方のポリシーを定めてそれに則ってもらうように働きかけるなどです。
そういった意味ではSREチームはプラットフォームチームとして、全体最適が図れるような動きが求められ、プロダクトチームはストリームアラインドチームとして、顧客価値を最大化するために、絶えずプラットフォームチームにフィードバックする動きが求められます。
さいごに
SRE留学を通して感じた、プロダクトチームとSREチームの違いを列挙してみました。
しかし、違いについて深堀りしていくと、そこには共通性があり、両チームは断絶されたチームというよりは地続きであるという視点が得られました。
Classiでは仲間を絶賛募集しています！SREをキャリアの選択肢として考えている方や、SRE留学制度のような組織文化に興味を持っていただけた方などなど、ぜひカジュアル面談などでお話しましょう！
