大企業経営におけるSREについての質問に登壇者が回答、Q&Aセッション公開 | AEON TECH HUB開催レポート Session#3

障害発生によるサービス停止は事業に大きな影響を与えます。
そのため、イオンではSREを経営レベルでも重要視しており、組織としてSREの強化を図っています。

2024年4月に開催された「AEON TECH HUB」では、「大企業経営におけるSREの重要性」をテーマに、SRE界隈の皆さんにご登壇いただきました。
各社のSRE領域における取り組みや運用時に大切にしていること、現場で意識していることを共有する場となりました。

今回は3回に分けてお届けする開催レポートの最終回であり、Q&Aセッションの様子をお伝えします。

▼ Session#1の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-31

▼ Session#2の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-32

▼イベント詳細ページはこちら
https://aeon.connpass.com/event/310105/

【目次】

Q&Aセッション

パネルディスカッション後には、参加者からいただいた質問に答えるQAセッションが行われました。

Q1：SREは人数のスケールが肝になるわけだが、オンボーディングや育成はどのようなことを行っているのか。

山﨑：SREは専門性が目まぐるしく変わる領域だと思っています。だからこそ、あらゆる専門性に精通するSREは存在しないわけで、技術的好奇心が強い若いエンジニアをハンズオンもしくはペアプログラミングを通して育成していくのが一番効率的なのではないでしょうか。加えて、SREのマインド面も必要になりますが、「どういう方向性のSREとして成長していきたいのか」というのを醸成していくのが正しいやり方だと私は考えています。

なので、積極的に未経験の若い人を受け入れて、そういう方向に導いていくのが、SREのスケールだと思っており、外部から優秀なSREを組織に入れていくのはかなり難易度の高いことでしょう。ZOZOさんは採用で充足できたと仰っていたのですごいなと思いつつ、イオンは育成からSRE組織を強化していきたいですね。

池田：完全な未経験でもSREポジションはOKということなのでしょうか。

山﨑：イオンではSREの人数が足りていないので、中核を求めていますが、将来的にはそこまで広げていかないと、人数のスケールはできないと思っています。

池田：SREの人数が充足している瀬尾さんはいかがですか？

瀬尾：SREで特別何か育成をやっているわけではなく、バックエンドやiOS、SREなど職種に限らず共通で、メンターをつけてOJT形式によるオンボーディングを実施しています。

池田：採用時に分母が足りないという感触もないんですか？

瀬尾：インフラエンジニアやバックエンドエンジニアからSREになりたいという人はいますので、分母が足りないという感触はないですね。その人のバックグラウンドに合わせて、何が足りないかをメンターが考えてOJTしていくような流れで補強していますね。

坪内：私の副業先では、ジュニアのSREをどう育成していくかという話をよくしています。そのなかで、生成AIを使ったアプローチを考えているんですね。一般の教育分野における生成AIの活用はかなり研究されていることからも、いろんなドメインに対してジュニアからシニアに引き上げられる可能性があると感じています。

ただ、ノンカスタマイズのChatGPTで実現できるとは思っていなくて、いかにSREの知識を入れ込んでいくかを議論している最中です。

柘植：ロールとしてのSREを増やすよりも、SREのことを理解している人たちを増やしたいという思いを持っています。もちろん、SREの専門性を持ったハイレイヤーの人が信頼性を担保することは重要ですが、それ以外の部分に関してはイネーブルメントを支援するフレームワークを作っています。それを活用することで、事業側のエンジニアやビジネス職の理解を深めたり、ジュニアのSRE自身も学習していく流れから成長できるようにしています。

Q2:インフラチームからSREへリネームする際に、ソフトウェアエンジニアリングの欠如が挙げられる。登壇各社の皆さんが行っているソフトウェアエンジニアリングの状況を知りたい。

瀬尾：弊社の場合、運用のツール化は全員できますが、バックエンドの障害まで見にいって障害やバグを直したりパフォーマンスチューニングしたりできる人は、一部に限られますね。特に新卒でSREへ配属になったメンバーは、バックエンドのキャリアがないので、そこまでは関与するのが難しい状況です。

そういうメンバー向けには、Go研修やJava研修などを受けてもらいながらカバーしていきたいと考えています。

坪内：さくらの場合はあまり当てはまらないので、正確な回答は難しいかもしれません。というのも事業の性質上、アプリケーションとインフラを両方こなせるエンジニアがコンテンツ事業者と比べると多く、なかにはフロントのJavaScriptを書きながらインフラ扱える人もいるんですよ。

柘植：各組織やメンバーによるところもありますね。ソフトウェアエンジニアリングに弱いメンバーもいるわけですが、そのぶん他の領域で強みを持っていたりと、適材適所に考えているのが正直なところです。

ただし、障害を解決するためにソフトウェアエンジニアリングを使う側面もあるので、そこに対して必要なベースラインを満たす支援は今後も引き続きやっていきたいですね。

山﨑：イオンスマートテクノロジーの場合は、インフラチームのリネームではなく、SREチームから組成していったので、スキルトランスファーをする必要はありませんでした。その一方、クラウドインフラが主流になり、Platform Engineeringの概念になっていくなかで、インフラエンジニアやSREがソフトウェアを触れないと厳しい状況になってくると思います。

会社としては当然、ソフトウェアに触れないメンバーへの支援をしていかなければならないと思っていますが、外部環境が変化していることもあり、同時にメンバー自身の意識改革や動機づけも大事になってくるでしょう。

Q3:登壇各社でのSREチームおよびSREエンジニアの人事評価やキャリアパスについて、ご参考までに教えてください。

瀬尾：全社で掲げている「ZOZOらしさ」を体現する人材の育成を目的に、人事制度を全社的に統一しアップデートしました。なので、SREだからと人事評価の仕方を変えているわけではありません。成果や能力、振る舞い（ZOZOらしさ）を総合的に見て評価しています。

また、SREは横断して幅広い業務に携わることのできるポジションなので、アーキテクトやCTOといったキャリアパスが考えられるでしょう。

山﨑：目標に対して評価するやり方をSREに適応するのは難しいと思っています。例えばコストを下げる、速度を上げるといったように定量化しようとすると、未然に障害を防いだなどの活動が評価されにくくなってしまいます。

なので、個々の人と向き合って、どういう活動をしてきたのか。どんなことを頑張ってきたのかを見て評価していくのが正しいやり方になるのではないでしょうか。キャリアパスに関しては、SRE自体が多様性を含んだ職種なので、CTOや専門職など、あらゆる道が考えられるでしょう。

イオンで働くSREの人たちにコミットしたいのは社内のキャリアパスよりも一般的な市場価値を向上させることです。

柘植：弊社もSREの人事評価はエンジニア一律になるので分けていないですね。キャリアパスは「本人が次に何をやりたいか」で決まることが多いです。先ほど、山﨑さんが会社に閉じないキャリアパスのことを話していましたが、そこは弊社でも意識している部分です。

チームとして目標設定するときも、本人のジョブサイズが上がるのかというのを明確化し、そこに対してのバリューや成果に応じて評価を行っているような状況です。

坪内：前職でSREの評価に携わっていた経験から話すと、一般的なエンジニア評価においてコンフリクトが生じやすいのは、エンジニア以外の職種が評価するときだと言われています。それがSREの場合、マネージャーにSREやエンジニアの経験があることが多く、コンフリクトが起きにくい。

そうなれば、SLOとかの数値も達成・未達だけで評価するより、もっと具体的な取り組みを評価しやすくなると思います。

Q4:SREにフォーカスした採用戦略はどのように立てているのか。

山﨑：今現在、SREの採用でメインなのは「人が人を連れてくる」ことです。

先ほども言ったように、技術コミュニティに接している人が多いので、イオンで働くのが面白い、楽しいと思っていれば、コミュニティ内でも話題になって、そこからカジュアル面談につながるケースも増えていますね。

瀬尾：テックブログも大切ですが、「SRE NEXT」に登壇すると非常に引きが良くて採用応募が増えました。

坪内：私は毎回SRE NEXTに登壇していますが、採用応募が増えるといった恩恵は受けていないですね。

柘植：SRE NEXTに出ると、一定効果が出ているという声は聞くので、登壇機会があれば積極的に参加するのが良いと思います。また、外部発信をしないと、そもそも知ってもらえないというのはあると思います。まずはそこから始め、母数を増やすことを意識しています。

そこが増えないと、いい人と出会えないので。採用のジョブディスクリプションには、具体的にどういうことをやってほしいかを記載して、そこに興味を持った人に来てもらえるように心がけています。

Q5:坪内さんはSRE領域の研究をされていると言う事ですが、研究領域とした動機、面白味について教えていただけますか。

坪内：動機は新卒のころからSREに取り組んできていたからです。面白味は、SREは人間とコンピュータシステムの最も基本的な関係性を築くものだと考えているため、コンピュータシステムの面白さと、エンジニアやサービス利用者といった人間・組織・社会の面白さ、の両者を探究できることです。

Q6:柘植さんの自己紹介の最後のスライドであったSREチームのアウトプットの可視化について、どのようなツール？を使用しているのでしょうか？

柘植：Google Sheetsを使っています。

Q7:柘植さんは、インフラ組織からSRE組織に変革していく中で、どのようなことを意識されましたか？

柘植：SREの関連書籍に書いてあるようなSREプラクティスをただやるのでなく、自分達が目指すSREを言語化し、行動することを意識しました。

Q8:イオンでSREがターゲットにしているのはクラウドのみでしょうか？オンプレ部隊のマインドやジョブチェンジは行っているのでしょうか？（人のシフト）

山﨑：イオン全体においては、特に基幹系などではオンプレも存在しており、そこもSREのスコープとなります。

一方でイオンスマートテクノロジーにおいては全インフラはクラウドとなっておりオンプレはスコープ外です。

オンプレ部隊のSRE化（SRE文化醸成やマインドチェンジ）は積極的に実施していきたいと考えています。

Q9:瀬尾さんが非機能要件の守護者でいるために取り組んでいる活動や仕組み、制度などあれば教えて下さい。

瀬尾：仕組みや制度があるわけではなく、マインドセットの話になります。

ただ、大きな案件の場合は、QAと並行して負荷試験や障害試験（システムの特定部位に障害が発生した場合に、自動復旧するのか、自動機能縮退するのか、アラートを受け取り手動復旧するのか、基準を定め、期待通りの動作となるか確認する試験） をSRE主導で行なうフローにしているので、そこが非機能要件の守護者としての実力を発揮できる環境になっているかもしれません。

Q10:ZOZOではSREの採用が進みプロダクト専属のSREをアサインできるようになったとありますが、専属化したことでSREスキルや知識の分断のようなものは課題になっていないのでしょうか？

瀬尾：知識の分断はあるので、部署をまたいだ勉強会を積極的に行うようにしています。

全社的にはSRE技術共有会というものを毎月開いて、各チームから一人ずつLTしてもらったりしています。草の根的には、輪読会が開かれたりもしていますね。テックブログ執筆も社内の知見共有にも役立っている気がしています。

Q11:ZOZOの福袋セールで事前準備を特にしないとのことでしたが、予めピーク時に合わせた設備投資をしているのか、またはクラウドのオートスケール等で対応するようにしているのでしょうか？

瀬尾：福袋に関しては、アーキテクチャ変更によって、事前の設備投資なしで捌けるようになりました（ジョブキューを導入して後でゆっくり処理）。

スケールに関して話すと、ZOZOTOWNは日曜深夜が毎週のピークになるので、その時間にあわせて自動的に台数追加するような仕組みが1つあります。あとは、ZOZOWEEKや、正月セールのタイミングでさらにトラフィックが増えるのですが、こちらは毎週実施されるようなセールでないので、セールの時期をビジネス部門から共有してもらい、事前に台数を増強しておくようなやり方をとっています。負荷に応じて発動するオートスケールは仕組みとしては入れていますが、あまり頼ってはおらず保険扱いと言えるかもしれません。

Q12:現在の自SRE組織へこれから期待している事はなんですか？

瀬尾：「非機能要件の守護者」として「経営」に貢献してほしいです。

坪内：国内では例がないと言ってもいい、「パブリッククラウド事業者としてのSRE」を確立してほしいあるいは確立したいと思っています。

柘植：経営目線でのSREとしての成果創出です。

山﨑：自己組織化です。SRE自体は本来は組織ではなくカルチャーなので、カルチャーを浸透させ周囲のDevOpsを推進するには、ミッションや指示の話ではなく、どれだけ能動的に行動出来るかがキーだと考えています。

Q13:SLI/SLO、エラーバジェットの運用などをBiz含めた全社の共通指標とする事がとても難しいと感じています。この辺りの運用状況、運用に乗せるためのアイディアなどを聞いてみたいです。

瀬尾：Biz/経営視点でどれぐらいのシステムダウンまでは許容できるのかを考えてみると良いでしょう。どれぐらいシステムダウンしていたら、どれぐらい売り上げ棄損になるのかを算出してみてください。逆にSLOを例えば99.9%から99.99%に上げるにはどれぐらいのコストがかかるのか算出してみてください。そこから妥当な目標値が導き出せると思います。

柘植：共通指標を持つ為には、SLI/SLO、エラーバジェットについて何故やるのか、そもそもどういったものなのかを共通認識出来ている必要があるので、先ずは相手が理解できる言葉で伝えることが重要になると思います。

なので、泥臭く感じるかもしれませんが、信頼性とコストはトレードオフの関係にあるという話から、ビジネス職の人達にも分かる言葉で説明していくのがいいと思います。その上で、自分達の組織やプロダクト、一機能で許容できるダウンタイムなどについてディスカッションしていくと良いと思います。

山﨑：ビジネスサイドは多くの場合において、品質目標に「最高」を求めます。

よって、SLI/SLOについて「どうしますか？」という問いは自滅するので、「今の私達の水準において、ここを死守したいと思います」という観点で、言われる前にこちらから提示するのが良いと思います。

Q14:SRE本はどれぐらい読みましたか？また、SRE本の中で共感できるところ出来ないところがあれば聞いてみたいです！

瀬尾：GoogleのSRE本を読んだのは大分昔になるので記憶を思い出しながらになりますが、基本的には共感しながら読んだ記憶があります。当時悩ましく思ったのは「エラーバジェット」が枯渇した時の運用です。

(経営層の一人になってより一層ですが) いまだに「エラーバジェット」がなくなったからといって、事業的に重要な（対外的にプレスリリースも出しているような）案件のリリースを止められる気はあまりしないですね。

坪内：GoogleのSRE Bookは英語と日本語でそれぞれ読みました。最も共感したことは、「信頼性」100%を目指すことは現実的ではないことを明示されていたことです。共感できないというわけではないですが、SRE本が後世に残した課題として、1)SREが何であるかが未定義あるいは曖昧な定義のままであること、2)どこからがGoogle固有の話でGoogle以外への適用可能性といった一般化可能性が十分に追求されていないこと、の２点があると思います。ただし、これらの課題を差し引いても、自分にはソフトウェアエンジニアリングの考え方に非常に大きな影響を与えてくれた偉大な書籍です。

柘植：GoogleのSRE本は、英語版、日本語版それぞれ読みました。基本的には、共感できる部分がほとんどの印象でしたが、あくまでGoogleや他社では当てはまるが、自分達の組織や会社では難しい部分もあるので、ナレッジとして参考にしつつ、自分達の組織や会社ではどうするといいかと考えると良いと思います。（SLI/SLOやエラーバジェットの取り決めなどは、事業ドメインによって当てはめるのが難しいケースもあるので）

山﨑：共感出来る部分と出来ない部分があります。それは否定的なものではなく、Googleでの事例が色濃く記載されており、会社のカルチャーや規模、エンジニアリングの深度に多分に依存するので、共感したとしてもそれをそのまま現場に適用出来るものではないという意味です。

エッセンスとして学びつつチューニングを前提として実践するべきものだなと考えているので、教科書は教科書、それを聖書とするのは危険かもなという考えです。

Q15:SRE Center of Excellence 、Embedded SRE、Enabling SRE の役割は重複する部分があるのではと思うが、どのような仕切りになっているか？

柘植：SRE Center of Excellenceは、横断的に展開できるSREプラクティス開発や導入へ取り組むSREsと定義しています。

また、Embedded SREは、2つのフェーズに分けておりそれぞれ、下記の様に定義しています。
・Enablementフェーズは、SREを組織へ浸透し、自立支援に取り組むSREs
・Evangelistフェーズは、SREの強化や改善を行うSREs

山﨑：すいません。イオンではここまでまだ到達出来てないです、、

Q16:SREチームの設置はDevとOpsの分断の再生産だという言説もありますが、この言説についての反論、ご意見等あれば聞いてみたいです！

瀬尾：パフォーマンスチューニングなどはSREが見てくれるから丸投げしよう、というマインドにDevがなりがちとかの話ですかね？

そうならないように、弊社ではDevとOps (SRE) の間に転がるようなボールは、両方が見逃してポテンヒットになるよりも、両方が取りにいって頭をぶつけるぐらいのほうが良い、と伝えています。

坪内：SREチームが担う役割次第だと思います。SREチームがOpsを担うのであれば、DevとOpsは分断されるでしょう。一方で、DevチームがOpsを担えるように、SREチームが支援する役割を担うのであれば、分断は起きないでしょう。

柘植：これはSREチームでなくとも、インフラチームでも起こり得るので、SREチームの役割の定義次第だと思います。

弊チームでいうと、全てのSRE活動をプロジェクト化するようにしているので、プロジェクト化する段階で明確に解決したい課題設定だけでなく、オフボーディングも意識し、なるべくSREチーム依存しない状況になっているかもチェックするようにしています。これによって、SREチーム設置によるDevOpsの分断が起きにくい状況になるように心がけています。

山﨑：そのとおりだと思う一方で「Ops」の部分は解釈によって揺れる部分かなと思います。継続的インテグレーションやデリバリーなどを実現するためのSREチームという物はありますが、企業におけるOpsは「問い合わせ対応」「障害調査」「内部監査対応」など、もっともっと泥臭いものも存在します。

よって、DevOpsを再生産したとして企業内Opsが完全に開発チームと一体化するかでいうと、それも違うかなと思っています。

Q17:SRE = サイトの信頼性を担保・進化させる組織だと思ってます。対外的には障害を未然に防ぐ・迅速に復旧させる事が評価ポイントだと思いますが、それ以外に評価されるポイントはありますか？

瀬尾：ZOZOの場合は「非機能要件の守護者」としているので、以下全般を評価ポイントとしています。

・独立性 (Isolation) - 環境、データの分離
・可用性 (Availability) - エラーが少ない
・拡張性 (Scalability) - 規模の変化に柔軟に対応できる
・信頼性 (Reliability) - 安定して動く
・高速性 (Rapidity) - ユーザーにとって充分に高速
・観測性 (Observability) - 運用に必要なメトリクスが可視化できている
・回復性 (Resiliency) - 障害を検知して可能な限り自動復旧する
・保全性 (Integrity) - データが保持されておりおかしくなっていない
・安全性 (Safety) - 高いセキュリティ
・保守性 (Maintainability) - 運用が楽
・安価 (Cheapness) - 事業売上に対して充分に安い

柘植：組織としては、事業ニーズに対しての貢献度、SRE文化の浸透度、対外的な組織ブランディング、組織活性化への貢献度、技術投資などの評価指標とガイドラインを策定し、それに対してSRE活動がどう貢献したかを評価しています。

またプロダクトに対しては、SRE成熟度評価を活用して、下記項目に対して、3段階で評価しています。

・サービスレベル目標
・監視
・インシデント対応
・ポストモーテム
・トイルの撲滅

山﨑：
・先進的技術の研究と発信
・トイルの解消
・DevOps文化の醸成と定着の活動
・対外的発信
・DevSecOps概念のセキュリティ分野の活動
・Platform Engineering / CCoE的な活動

などなど、多様に評価ポイントは存在すると思います。

Q18:皆様のところのSREチームは何名体制でしょうか？

瀬尾：大体1チーム 4〜8名です。全体で50名ほどです。

柘植：SRE組織によって違いますが、私がマネージャーをするSRGでは10名程度になります。

他のSRE組織については、SRE Technology Mapを参照していただけると幸いです。https://d2utiq8et4vl56.cloudfront.net/files/user/pdf/techinfo/SRETechnologyMap.pdf

山﨑：イオンスマートテクノロジーにおいては、社員／業務委託社員含めて、おおよそ10名ぐらいの組織となっています。

Q19:SREエンジニアを社内に維持する、社外から入ってきてもらうために気にしていることはありますか。

瀬尾：会社に貢献できているという実感を得られるように職務設計することですかね。それを「非機能要件の守護者」というひと言に集約して、対外的にも伝えやすいように工夫しました。

柘植：事業に対しての貢献やジョブサイズが上がっている実感を得られるように、目標設定や中長期の育成支援などのピープルマネジメントに力を入れています。

山﨑：自己研鑽出来てかつ、サービスに対する貢献価値が存在する。そしてSREの存在が組織から承認／歓迎されている。という状態を作っていきたい／維持していきたいと考えています。

Q20:古いシステムに対してSREのマインドを注入していくには、 何から取り掛かるのがよいとお考えでしょうか

瀬尾：色々やり方はあるかと思いますが、私がやったのは「実例をみせる」ということでした。

・全面 Infrastrucute as Code・CI/CD 化
・原則、すべての運用をツール化
・リリース前の負荷試験とパフォーマンスチューニング
・オブザーバビリティ製品の導入とSLOの策定

SRE本をサマって、どういう状態を目指すかのビジョンも共有したと思います。

坪内：古いシステムを維持するのか、刷新するのかによって異なるように思います。SREはシステム変更を前提とするため、現状維持するのであればSREのマインドは特に必要ないかもしれません。刷新するのであれば、大きな変更を伴い、それは信頼性のリスクとなります。そのため、SREの信頼性100%を目指さないための合意をステークホルダーと握るようにする必要があります。

柘植：先ずは、現状のシステムにおける運用課題を一緒に整理していくのが良いと思います。弊社では、事業部全体を俯瞰しデータ化するために作成した「SRE成熟度評価」というフレームワークを活用して、一緒に課題整理をしながら、SREの考え方についてのイネーブルメントも同時に行なっています。

山﨑：オブザーバビリティから始めるのが手っ取り早いかもしれません。New RelicもしくはDatadogを導入してAPMを入れて。APMの内容を開発者がモニタリングするように勉強会をして。そしてDevOpsへつなげていく。などはいかがでしょうか？

Q21:Agile やCloud ではなく、Waterfall やOn-Premises の場合のSRE ってまだ確立されていないと思いますが如何ですか？

瀬尾：(現在リプレイスプロジェクトで、技術スタックも変えつつクラウドに載せ替えていっていますが) ZOZOは Windows サーバがオンプレ環境にあります。なかなか全ての運用をソフトウェア化することは正直難しく、苦戦しているところではあるのですが、Ansible を使うなどして頑張っているところです。

前職の DeNA 時代もオンプレ環境がありましたが、サイトの信頼性を高めるという活動自体には、オンプレ・クラウドで垣根はないと思います。むしろ元々提唱していた Google もオンプレ環境を想定しているのではないかと思います（Google Cloud の中もオンプレですし）

Agile・Waterfallといった開発プロセスの違いに関しては、SREの活動に影響はないと思います。

柘植：Waterfall やOn-PremisesだからSREとしての活動ができないということはないですが、開発と運用チームが分離されており、それぞれが別予算で活動している場合は、SREとしての難易度は上がると思っています。

山﨑：回答がずれていたらすいません。WaterFallでも高頻度リリースはCI/CD、テスト自動化などによって可能になりますし、On-PremisesにおいてもIaCやオブザーバビリティは可能です。SRE自体が手法でなく文化なので確かにクラウドの方が実現出来る手段は多いですが、オンプレだと出来ないという前提は無いかなと個人的には考えています。

イオンが主催するAEON TECH HUB #3、今回は大企業経営におけるSREというテーマでした！今後も、様々なテーマを取り上げていきますのでAEON TECH HUBをよろしくお願いします。

AEON TECH HUB #3開催レポートのその他記事もございますので、ぜひご覧ください。

▼ Session#1の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-31

▼ Session#2の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-32

イオングループでは、一緒に変革に挑んでくれる方を募集中です。カジュアル面談も実施しておりますので、少しでも気になった方はお気軽にご連絡ください。まずはざっくばらんにお話しましょう。