ZOZO、サイバーエージェント、さくらインターネット、イオン、大規模サービスにおけるSRE導入で得られた実際の変化とは | AEON TECH HUB 開催レポート Session#2

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

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

今回は3回に分けてお届けする開催レポートの2本目であり、パネルディスカッションの様子をお伝えします。

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

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

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

【目次】

パネルディスカッション

LT終了後、5つのテーマをもとにしたパネルディスカッションが行われました。SRE組織で大切にしていること、現場のリアルな話や経営層とのコミュニケーションなど、各登壇者による有益な議論がなされました。

ディスカッションテーマ1：弊社のSREはこれをモットーにしている

池田（司会）：まず最初のテーマについて、各社それぞれでどのようなことを大切にしているのか。その個性や特徴もお話しいただければと思います。ではイオンの山﨑さんからいかがでしょうか？

山﨑：ご周知の通り、イオンはレガシー企業なので、他の3社と比べてSREの環境は随分異なると思っています。現在、イオンスマートテクノロジーには、幸いにも個性豊かなSREが集まっていますが、「優しさ」を一番大事にしていますね。

レガシー企業ではよくあるのが、社内で内製化が進んでいないゆえに、専門性の高くないエンジニアが在籍していることが多く、外部リソースに依存してしまっていることです。そうした社内のエンジニアたちに、SREのことを説明しても意味が通じなかったり、良さが伝わらなかったりするわけなんですね。

なので、信頼の構築には「自分たちが何者で、開発チームに対してどういう武器を提供したいのか」という寄り添うコミュニケーションが必要になります。イオンのSREは、このような環境づくりに取り組んでおり、徐々に信頼感の醸成につながっているような状況です。

池田：続いてはZOZOの瀬尾さんお願いします。

瀬尾：弊社のSREのモットーはLTでも紹介した「非機能要件の守護者」です。Google社が提唱する「運用のツール化」は、もはや当たり前のように実行しておりまして、私がチームリーダーを務めていたときは、「すべての運用をツール化しましょう」とメンバーに伝えていましたね。

オペレーションミスが発生した場合でも、ツールにバリデーション機能やフールプルーフ設計（誤った操作を行っても重大な事故を招かないよう設計すること）を入れることで、再発防止策を打っていました。

現在ではこの運用が根付いているので、それに追加でリライアビリティエンジニアリングを行っています。リライアビリティエンジニアリングとは、語感的に信頼性や安定性の向上を頑張るという意味合いになるかと思いますが、それを拡大解釈してセキュリティやパフォーマンスなど、非機能要件の全般までやるのがZOZOのSREにおけるモットーです。

池田：ありがとうございます。次はサイバーエージェントの柘植さんからお話いただけますでしょうか。

柘植：LTでも話しましたが、弊社には色々なタイプのSRE組織があるので、一言で伝えにくいというのがありますが、モットーとしているのは「SREとして事業をどう良くするかということに向き合う」ことです。なので、事業に対してSREとして技術を活用することで、事業をどのように良くしていくかという観点を大事にしていますね。

池田：坪内さんは事業との関わり合いは直接ないかもしれませんが、普段近くで見ていてどのように感じていますか？

坪内：SRE室の代理としてお話すると、SRE室にはMVV（ミッション・ビジョン・バリュー）が決められていて、その中のバリューの一つに「決め事を作るのではなく、一緒に“手を動かして”信頼性向上の文化をつくる」というものがあります。SRE室のメンバーだけがSREをやるのではなく、あくまで開発チームと一緒に手を動かすことで、開発チームがセルフサービスとして自立し、うまくSREを実践できるようになることを目指すのがモットーだと言えると思います。

ディスカッションテーマ2：SREを設置してこんな効果・違いを体感

池田：次のテーマでは、SREを設置したことで起きた実際の変化や体験談を語ってもらおうと思います。柘植さんいかがでしょうか？

柘植：私のSRE組織では、初期フェーズにおけるイネーブリングの文化を作るには、SREを引っ張っていくロールを明確にした方が浸透しやすいと感じています。

池田：SREを設置した後に、プロダクトや事業そのものが良くなったという体感は何かありましたか？

柘植：新しく組織を作ったというよりも、元々あったインフラ組織をSRE組織に変えていった側面もあるので、変化の違いが見えづらい部分もありますね。ただ、やっていく自分たちのマインドも変わっていったというのは感じています。

あとはプロダクトに対しての関わり方も、これまでのようにインフラ領域だけに絞っていたのに比べて、事業をより良くするために自分たちの領域を狭めず、「どういった課題があり、それをどのように解決できるか」というのを全員が考えるようになり、できることなら「何でもやる」というマインドにつながりました。なので、SREを設置したことによる開発メンバーの意識変化は実感していますね。

池田：一方でZOZOはどうでしょうか。SRE部署を変えたのも踏まえて、教えていただければ幸いです。

瀬尾：弊社のZOZOTOWNでは、セール時にものすごく大きな負荷がサイトにかかる状況となっています。恥ずかしながら、以前は福袋を販売するタイミングにデータベースが落ちてしまったことがありました。こうしたユーザーに影響が及ぶ障害が発生していたなか、SREのチームを組成したことで障害を防げるようになり、今ではお客さまに福袋のお買い物を快適に楽しんでいただけるようになりました。

X（旧 Twitter）には「ZOZOTOWNが止まった」という書き込みが昔はありましたが、最近はそういったお声をいただくことも減少しています。

また、SREを配置したことで障害の件数も半減したのです。そういう意味では、かなりの良い効果を得られたと言えるでしょう。

池田：それでは山﨑さんもお願いします。

山﨑：イオンは先ほど話したJTC特有の環境なので、SREの人が入社すると、社内のエンジニアたちの技術感度が上がってくるんです。知らないキーワードを自然と学習するようになったりと、元は自分たちもエンジニアであることをもう一度思い出すというか、栄養で満たされて花が開くようになっていますね。最初はわからなかったことも、勉強を重ねていくうちに、半年後には「次はこういうことに挑戦したい」というように、SREと対等に対話できるようになったと実感しています。

また、イオンはあまり外部への情報発信をしていなかったり、コネクションがなかったりしたのですが、SREの人たちは外部との接点が非常に豊富な人たちが多いなと思っています。なので、そういうSREの人種がイオンに入ってきてくれることで、外とのパイプラインができており、自然に広報活動ができるようになったのは、非常に大きな成果だと捉えています。イオンにとってSREは、まさに“変革者”だと言える存在です。

池田：坪内さんは何か効果を感じていることはありますか？

坪内：SREを設置したことで、障害が起きたときの情報流通の経路が結構変わりましたね。元々、さくらインターネットの各サービスは独立した組織になっているので、障害情報の共有も個別単位でしか行われていませんでした。それが全社的な共有に変わり、ポストモーテムでも重要な障害についてはしっかり書かれるようになりました。

サイバーエージェントさんのように、インフラや運用チームがSRE組織に変わったというよりも、 SRE室は新設された横断的な部署になるので、情報流通の経路の違いがわかりやすく表れたのではと考えています。

池田：全体を通して、SREの設置でプロダクトを安定させることはもちろん、既存社員のマインドが変わったりと、SREが「社内を変化させる起爆剤」にもなっていると感じました。

ひとつ気になるのが、インフラエンジニアで始めた人たちが、SREへポジションチェンジする場合、気持ちの変化以外に何かサポートはしているのでしょうか？

山﨑：イオンの場合は資格取得や研修制度を申請することで、技術的なキャッチアップができる環境は整備されています。その一方で、SREは技術感度や技術的好奇心の高い人が自然となっていくポジションだと思うんですよ。最終的にトイルを解決しようとする際には、一人でできないことも多く、自分の周辺にある課題を見つけて改善活動していくところに関しては、技術への興味・関心のある人が担っていくと私は考えています。

「インフラエンジニアからSREになる」というよりかは、SREに興味を持っている人が実際に活躍していくのではないでしょうか。

柘植：明確に何をサポートしているかを明言するのは難しいところですが、SRE組織として現状の課題に対するアプローチの仕方の精度を上げていく支援は行っていますね。

SREはプロジェクト制で運用しているとお伝えしましたが、プロジェクトを立ち上げるのは各メンバーにやってもらうようにしています。その際に「どういった課題があって、どんなアプローチができるのか」というのをプロジェクトメンバー自身が言語化し、それを事業部に提案してOKが出たらプロジェクトを始めるような仕組みを作っています。

課題に対しての的確なアプローチを考えるスキルのほか、技術的に足りないところは、他のチームメンバーが教えたり社内の勉強会に参加したりという形でサポートしています。

瀬尾：弊社の場合、インフラエンジニアからSREにリネームした背景があります。その際にインフラエンジニアのマインドチェンジが必要でした。当時現場のリーダーだった私はSREとインフラエンジニアの違いについて、運用のツール化やパフォーマンスチューニングへの介入など、実際に具体例を示しながらチームメンバーに伝えていました。

結構苦労しましたが、今となってはインフラエンジニアだった人が全員SREをやっていると胸を張って言えるようにはなったと思っています。

坪内：弊社ではSRE室がEnabling SREという形で各エンジニアチームのSRE実践を支援することが業務に組み込まれています。前職ではZOZOさんと同様に、インフラエンジニアからSREへリネームすることを私から提案しました。ただ、そこから数ヶ月で退職してしまったこともあり、自分のブログでSREについての考え方を退職月にまとめたんですよ。https://blog.yuuk.io/entry/2019/thinking-sre 

前職はインフラエンジニアよりもアプリケーションエンジニアが多く、ソフトウェアでやろうという考え方は全員持っていました。信頼性についても、SREにリネームする前から、みんなで輪読会を開いたりしていたので、多くのメンバーがSREについて一定以上わかっている状態でした。このような背景があったので、リネームしてから特別な支援を行いませんでした。

ディスカッションテーマ3：技術職以外の経営層・社員にSREの重要性をどう理解してもらうか

池田：エンジニアであれば、SREのことを何となくでも理解できると思いますが、非エンジニアに対しては意味や役割が伝わらないことも少なくありません。そんななかで、SREをどう根付かせていけばいいのかについて、各社にお聞きできればと思います。

坪内：SRE室が立ち上がる前に、さくらのクラウドの事業責任者へSREに関する相談を受けたことがあります。SREは、信頼性100%の達成を目標としないことが各方法論の実践の大前提となるため、「リスクを受容する」、「エラーを許容する」という考え方が浸透している必要があることを強調しました。

瀬尾：SREというポジションを作った時期は、エンジニアがトップを務めていたZOZOテクノロジーズという会社だったので、説明はスムーズでした。ただ、先ほども触れましたが、以前のZOZOTOWNでは障害により、事業に影響が出てしまうケースがありました。そうした危機を、SREによって解決できたこともあり、ZOZOグループが組織再編し、ZOZOに集約された今でも経営層にとってSREの重要性は浸透していると思います。

山﨑：実は過去の会社でも今でも、困ったことはほとんどありません。イオンの経営層についても、例えば私の直属の上司である副社長の羽生は、何か障害が起きると「なんで自動検知してオートスケールしないの？」と言ってくるんですよ。

オブザーバビリティを高め、自動検知や自動復旧することに対して文句を言うこと自体、そもそもテクノロジーにかなり理解があると感じています。なので、経営層にSREの重要性をどう理解してもらうかを考えたことはあまりないんですよ。

池田：それは社員の人も同様ですか？

山﨑：社員の人も同様じゃないですかね。確かに、新しいことをやっているケースが多いので、「SREは楽しそうで羨ましい」と思われているかもしれません。でも、SREの重要性が理解されないということはないと思います。

柘植：弊社の中で注力する技術領域の一つにSREが入っているので、今となっては経営層に重要性は理解されていると考えています。そういった部分では、「サービスの信頼性は必要だよね」という会話を、経営層と当たり前にすることができていますね。それでもプロダクトによっては、SREを完全に理解しているかというと、まだまだ完璧ではないと思っています。

なので、SREを浸透させる為の取り組みの一環として、ビジネス職や責任者、エンジニアなどの対象者ごとにSREを説明するスライドを別に用意していたりしています。要は、相手が理解できる言語で説明し、SREでどういうことをやりたいかを一つひとつ話をしていくことで、「それは重要だよね」という合意を取り、その上で進めていくことを心がけていますね。

このようなことをやっていくと、エンジニア職ではなくビジネス職の人が「SREが入ったことでこう良くなった」という効果を、他のところに話してもらえるようになりました。そこから「うちのチームでもお願いしたい」という流れになるケースもよくあり、副次効果として感じている部分です。

最近だと、口コミでいろんなところから「うちもSRE領域を強化していきたいので支援してもらえないですか」という相談も増えてきていますね。

池田：例えば、ビジネスサイドとして「この機能を作って事業を伸ばしたい」という思いがあったときに、SREではなくアプリケーションエンジニアを増やすべきという声も出ると思うんですよ。その場合にはどのように説得すればいいとお考えですか？

柘植：売り上げを伸ばすのが目的の場合、事業がどのフェーズかによって優先順位は変わってきます。事業のトップラインを伸ばせるのであれば、機能開発に着手するのもいいでしょう。ただ、足元を整備しないといけないタイミングが来ると思うので、そこをどのフェーズでやった方が、事業インパクトを出せるかを説明することが必要になります。

今後、事業としてさらに成長していくことを見据え、足元を整えた方がいいという提案の仕方をして、そこに対しどのくらいリソースを確保するかといった話はよく現場でしていますね。

池田：他の方で「これは言っておきたいこと」があれば教えてください。

坪内：これまでのディスカッションでは、SREそのものが大事ということが、経営層に理解されないなどの苦労はあまりなかった印象でした。一方で、「SREに経営資源を割くかどうか」ということについては、地道な説明をする必要があったと思うんですが、その辺りは皆さんどうされていますか？

瀬尾：開発組織をどういう配分で作っていくかという点に関しては全ての裁量を持たせてもらいながら取り組んでいますね。

弊社はSREのメンバーが結構多い方だと思いますが、それだけ障害が起きたときの影響が大きいからだと思っていて。SREに経営資源を割くことに対して経営層の理解があるからこそ、メンバーを多く配置し、堅固な組織にできています。

坪内：確かに障害が起きた時の影響が大きければ、理解してもらいやすくなりますよね。あとは、障害が起きないように気を遣って、工数を多くかけた結果として障害が少ない場合は、理解されにくいこともあるかもしれません。

山﨑：それで言うと、うちも一緒かもしれませんね。毎月20日・30日の「お客さま感謝デー」でお買い物代金が5％オフになるときはどうしても障害が起こりやすく、障害が発生した際の売り上げへのインパクトは相当大きいので、そこに対する備えとしての考え方は一定あると思っています。

あとは、SREがいることによって自動化やCI/CD、リリースが簡単になり、ソフトウェアエンジニアがコードに向き合う時間が相対的に増えるというのも、副次的な効果として挙げられるでしょう。もちろん、最終の意思決定はCTOの私ですが、「SREが増えるのは悪」という考えではなく、全体に寄与しているという風に捉えるようにしています。

ディスカッションテーマ4：SRE組織の組成時に気をつけるべきこと

池田：SRE部隊を作ろうと思ったときに、どういう風に組成していけばいいのかについて、登壇者の皆さんからアドバイスをいただきたいです。

柘植：先ほどは「何でもやる」マインドを持つことが大事だと述べましたが、度を超えて何でもやり過ぎると、それこそ“何でも屋”になってしまい、色々なタスクが振られ過ぎることでメンバーが疲弊し、組織縮小の原因になります。なので、自分たちのSRE組織は何を目的にしているのか。どういうことを実現したいのかを立ち上げ時にしっかりと定めておくことが大切です。

池田：目標設定もそこに紐付けますか？

柘植：目標もそうですし、組織の戦略を明確に掲げていた方が、メンバーもやりやすいと思うんですよ。うちとしても、そこは意識しながらやっていきたいとは考えています。

池田：実際にSRE立ち上げに際して苦労したことは何かありますか。

柘植：インフラ組織からSREへリネームすることは、賛否両論あると思いますが、「これからはSREをやっていくぞ」と掲げても、メンバー自身がSREのことが分からずに困るケースは割と多く、うちのチームもまさにそういう状況でした。特にSRE組織の立ち上げ初期は「名前は変わったけど、以前とやっていることはあまり変わっていない」みたいに、自分たちでやっていて苦しいと感じていましたね。

そういう意味でも、SRE組織はどういうことをやるのかをあらかじめ定義した方がいいと考えています。

山﨑：SREという言葉自体、かなり抽象度が高いと思っています。インフラなのか、トイル改善なのか。あるいはDevOpsなのか、Platform Engineeringなのかなど、色々なものが混ざるわけですが、最終的に組織の改善を通じて顧客に価値を提供するのがまず大事になるわけです。そうじゃないと、自由研究組織になりがちで、そこを意識した上での活動内容であれば、イオンの場合は枠組みをそこまで作らなくても実践しています。

最近だと、イオンスマートテクノロジーではオペレーターも交じって、運用をどう改善していくかという取り組みを行っていますね。もうひとつ、私が上長としてSRE組成時に気をつけていることは、SREの人は技術的好奇心への感度が高く、正しい選択をすると思っているので、取り組みの目的やコストの部分はジャッジしますが、「このテクノロジーがいいと思う」という技術選定の部分は極力、自主性に任せることを大事にしています。

坪内：SRE本の第一章に明言されている「願望は戦略にあらず」という言葉が好きで、これの意味するところはSREが運用組織と呼ばれる所以だと捉えています。運用は戦略というよりも、何かイベントが起きてから対処していくことが多いなか、SREをやろうと考えたときに、アドホックにやるのではなく戦略的かつ抜本的に何かを変えたいという意思があると思うんですよ。

そこをいかに具体化し、提示していけるかが求められるでしょう。また、戦略には2種類あって、一つ目は抽象度の高いレベルでSREを定義すること。もうひとつは具体的なレベルにまで落とし込むことです。

後者で過去に実際やってみたことをお伝えすると、SREが関わる変数としては信頼性や開発速度、コスト、セキュリティなどがあるなかで最初の3変数を定義し、それぞれに対して具体的な課題を抽出して、インパクトの大きさを分類しながら優先順位を決めていました。つまり、抽象レベルと具体レベルの2つの戦略を提示することが重要だと考えています。

瀬尾：「ボールがこぼれないようにする」ことには気をつけていますね。SREの役割は「非機能要件の守護者」とお話ししましたが、バックエンドエンジニアからすると「非機能要件はSREが見るから注視しなくていい」と思ってしまうことから、ボールがこぼれてしまう可能性もあります。

それだと、SREを作った本意からずれてしまうので、SREもバックエンドエンジニアも両方がボールを拾いにいけるようなマインドの醸成を意識しています。

池田：SREが見てくれるから、バックエンドエンジニアの人が無関心になるとかは結構ありますよね。

ディスカッションテーマ5：そもそも大企業では信頼性は100%まで上げるもの？

池田：信頼性をどこまで担保すべきかは答えがないことだと思いますが、各社がどういうスタンスのもとで信頼性を追求しているかについて伺いたいです。

坪内：この質問は僕が挙げたので、少し補足させていただくと、大企業は社会に果たす責任が大きく、お客さまや社内からは相応の信頼性を期待されがちだと思うんです。他方で、SRE本にならうと「100%の信頼性担保は難しく、そこは目指さない」という考え方があるわけで、私個人としてはSREと信頼性の相性が気になっています。なので、この辺りの所感を皆さんにお聞きしてみたかった次第です。

池田：信頼性の98%、99%を達成できても「残りの1%まで妥協できない」というような話ですよね。

坪内：そうですね。障害なんて起こしてはならないという考え方にならないかどうかが気になっています。

瀬尾：弊社の場合は、SLOの評価基準のうち、セキュリティの可用性を99.9%に定め、そこを目指していますね。毎月スコアリングし、目標に到達しない可能性がある際は、CTOも入って対応をおこなうような状況です。

山﨑：イオンは他社と比べ、SREが成熟していないので、数字目標を置くよりも障害潰しに奮闘するフェーズではあります。ただ、信頼性100%、59%、69%なのかは数字遊びだと思っていて。やはり、障害は絶対に起きるんですよね。

そういう観点では、起きた時にどれだけ早く復旧できるかの方が大事になるでしょう。なので、信頼性100%を追求するのは現実的ではないと思いますね。過去に在籍していた会社では、信頼性100%を求める人もいましたが、そうなるとコストや体制のトレードオフの話に寄ってきてしまう。私はそういう議論にはしたくないので、信頼性100%を追求しない考えを基本にしています。

池田：セキュリティと一緒ですよね。完全に守るのは無理なので、何かインシデントが起きた時にすぐに復旧できる体制を持つことが重要な気がしますね。

柘植：信頼性100%は現実的に厳しいわけですが、事業ドメインによっては、より高い信頼性を担保しなくてはならないプロダクトもあるので、そういったところは山﨑さんの言うトレードオフの話のように、信頼性100%に向けて資金を投入するケースもあります。ですが、それでも信頼性100%を達成するのは難しいため、弊社のSRE組織ではどのようにグラデーションを作るかをしっかりと設計しています。

池田：LTで紹介されていましたが、現状ではかなりのSRE組織があると思うんですが、グラデーションの付け方の仕組みは何かあるんですか？

柘植：SRE組織として支援する際には、事業を正確に理解することを意識しています。事業のペインになりえる部分を現場と対話していきながら、信頼性を高く担保していく必要性を議論していき、そこからシステムへ落とし込んでいくようにしています。もちろん、信頼性100%は難しいので、落とし所を見定めながら決めていくフローを設計していますね。

イオンが主催する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#3の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-33

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