2023年夏より始まったココネエンジニアの新体制。

開発メンバーのマネジメントを担うエンジニアリングマネージャー（EM）を新たに設けることで、テックリード（TL）と役割を分担させ、グローバル展開に向けた組織強化を図ってきました。

これまで下記の投稿から、EM/TL、そしてCTOそれぞれの視点から新体制で得られたこと、課題や葛藤などについて紹介してきました。

• 「【テックリードインタビュー前編】より技術と向き合うために、マネジメントの役割を分けてみて」
• 「エンジニアリングマネージャー３人に聞いてみた１０の質問」
• 「エンジニアリングマネージャー体制の成功と、生成AIについて考える」

特に役割の分担によって生まれた作業や時間の余裕から、チャレンジングな取り組みを積極的に生み出せる土壌が整いつつあることは、新体制による喜ばしい結果だと考えます。

TLインタビューの後編となる今回は、まさに新体制によって導入を推し進めることとなったSRE（Site Reliability Engineering）についてです。

SREはシステム管理とサービス運用に対するアプローチとして昨今のIT界隈で注目されていますが、エンタメ系のサービスで導入されている事例はそれほど多くないとのこと。

ココネで導入に至った経緯、現時点の手ごたえや課題について、取り組みを担当するTLのふたりから話を聞いてみました。

＜TLメンバープロフィール＞

maruc 【SRE担当】
2022年1月入社。主に新規サービスの立ち上げ開発に携わる。2023年7月よりテックリードに就任し、サーバーTL組織の方向性の策定や汎用モジュール開発にも力を入れている。

とんさん【SRE担当】
2023年2月入社。2023年7月より既存サービスのテックリードに就任。以後、安定した運用のためにCI/CDの整備や負荷分散に力を入れる。2024年よりSRE導入のための試行錯誤中

わかめ
2020年入社以来、既存サービスの開発に携わり、2023年7月よりテックリードに就任。システムの歴史に潜む課題に日々挑戦しながら、チームと協力して品質維持と改善に努めている。

「サービスの信頼性」を高める

ーSREを担当されるmarucさん・とんさんさんにお聞きします。SREの導入目的はどのようなものですか？

maruc
SREの基本的な目的は、「サービスの信頼性」を高めることです。

当社ではサービスの利用者をユーザーと呼ばず「お客様」と呼んでいますが、そういったお客様第一の想いがベースにあります。SREによる徹底したサービスの「信頼性」は必要なものだと考えていますし、積極的に推し進めたいと思っています。

また、SREの導入はエンジニアの業務効率向上にも繋がります。例えば各種APIエラーによるお客様体験への影響を加味した上で、異常検知と通知システムを自動化するため、問題発生時に影響度と合わせて迅速に対応が行えるようになります。

とんさん
目的はもうひとつあります。
当社の事業では将来的に100万DAUを目指していますが、達成しそうになった時に慌てて対応するのではなく、安定して動く環境をあらかじめ構築しておく、ということもSREの導入理由としてあります。

お客様の満足度を見極めるSLOの値

ーどのようにSREを導入されていますか？

とんさん
SREの領域は多岐に渡りますが、ひとまず当社では、「SLO（Service level objective）」という目標を定めてモニタリングすることからスタートしました。

SLOは、SLI（Service level indicator）という定量的な値から、サービスの「信頼性」に関する目標を定義したものです。例えば「お客様からのあるアクセスに対して〇％がエラーになった」というようなことを計測しますが、そこで表示されたパーセンテージは単純なシステムエラーの数ではなく、お客様の満足度に直に影響する値であるところが特徴です。仮にそのパーセンテージが設定したラインを下回ると、お客様にとってよろしくない問題が累積していることが定量的に判明し、優先順位を上げて速やかに対応することができます。

我々の第一歩として、まずは物事を判断するための数字を見える化することができましたが、SREの導入として良い方向に向かっていると考えています。

わかめ
突発的に発生した問題をエンジニア以外の誰かから知らされるのではなく、サーバーチームでいち早く検知できる可能性が上がったことは、エンジニアのメンタルにとても良さそうですね。メンバーの心理的安全性にもつながりそう。

エンタメ系サービスのSRE事例は少ない
上手く設計できれば我々の強みになる

ーSRE導入で苦労していることはありますか？

とんさん
ビジネス系サービスで導入したSREの話はよく見かけますが、エンタメ系の事例となるとあまり出てきません。参考にできそうな見本が少ないことで苦しんでいますが、逆にうまく設計することができたなら我々の強みになると思っています。

ーエンタメ系のSREが出てこない理由はどう思われていますか？

とんさん
エンタメ系はビジネス系に比べてお客様操作に対する、APIレスポンスやクライアント側の挙動が複合して関係しており、どのような指標を取ればお客様体験と一致するのか定義が難しいからではないでしょうか。

また、ビジネス系に比べて新機能の追加ペースが早いのも特徴と思っており、新しいコンテンツの開発に工数捻出と信頼性向上のために使う工数のベストバランスとなるSLO定義も今年の課題と考えています。

maruc
これまではそのバランスを感覚的に取っていたこともありましたが、SREによってこれからは定量的に可視化できるようになります。とはいえまだ0から1を生み出している段階なので、分厚い書籍を見ながらあーでもないこーでもないという話を繰り返しながら少しずつ進めている感じです。

ー同じTLとして、わかめさんからSRE担当のふたりに聞きたいことはありますか？

わかめ
以前、ストア側の障害でアプリ内の課金ができないという現象が発生しました。結果として我々の領域外のトラブルだったため解消を待つしかなかったのですが、そういったのもSLOで検知したほうがいいのでしょうか？

とんさん
その件ではSLOの観点というよりは、SREをちゃんと導入することによって属人化しない対応ができたと思います。

当時、トラブルが発生した際のプロジェクト横断的な情報共有のルールは明文化されていなかったので、エラーの第一報を受け取った後は各プロジェクトでそれぞれ原因を探るようなことになっていました。

SREにはオンコールやインシデント対応という分野もあるので、何かがあったときのフローが明確になるのでサービス全体の安全性が高まると思っています。

maruc
SLOに関して言えば、ココネの各サービスではどういった指標が重要となるのか、見極めていくことも今後の目標としています。

とんさん
そうですね、例えば決済関係のエラーは、他のエラーと比べて心理的負荷がとても高くなると思います。そのためSLO設定は、用途によってアラートされるラインを分ける必要があるのかなと。指標として分けたほうがよい数値、逆に混合したほうがよい数値など、それらを見極めるノウハウも今年は積んでいきたいですね。

SREがもたらす影響や未来を
エンジニア以外にも理解していただく

ー 最後の質問です。SREの導入に必要なことはありますか？

maruc
私も最初はSREのことが本当に分からなくて、オライリーの書籍やWeb記事を調べて、且つとんさんさんと議論していくなかで少しずつ分かり始めたくらいです。エンジニアの方々の中でも、SREについて理解し、伝えていける方はまだまだ多くないと思います。

そして、本格的にSREを導入するためには、各プロジェクトの事業責任者と認識を合わせ、且つ事業メンバーと開発陣で内容をすり合わせながら進めることが重要だと認識しています。

そしてそこにひとつの難しさがあります。

SREの本格導入には、学びも含めてそれなりの工数が必要ですが、お客様から得られる「信頼性」は長期的に培っていくものです。事業成長にはすぐにつながりづらく、見えにくい面もあります。

SREがもたらす影響や未来を、事業責任者や事業メンバーにも理解してもらう。そのための道筋を用意するのも自身の役割のひとつだと思っています。

ココネエンジニアのテックブログも合わせてどうぞ！