複数の自社開発WEBサービスを展開するうるるには、組織を横断してサービス品質向上に取り組む「SRE*委員会」という自主プロジェクトが存在します。
今回は委員会メンバーにインタビュー。
ユーザーに常に快適にご利用いただけるサービスを目指して、異なる組織のエンジニア達がどのように連携し、取り組みを推進していったのか。
うるるのカルチャーがぎゅっと濃縮された活動に迫ります！
*Site Reliability Engineeringの略称。
WEBサイトやソフトウェアの信頼性を高めるアプローチの一つ。システム運用に関する観測データを事前に定めた数値内に収めることで障害等を未然に防ぎ、ユーザーが期待通りにサービスを利用できる状態を目指す概念。
インタビュー対象者プロフィール
◆筒井 智也（つつい ともや） ※写真左
・業務推進・管理部 技術戦略課 所属
・クラウドソーシングやSaaSの開発を経験後、技術戦略課へジョイン
・主に開発生産性の向上、セキュリティ対策、技術戦略の策定などを担当
◆蔡 易逹（さい いたつ / Tsai Yita） ※写真中央左
・NJSS事業本部 開発課 所属
・組み込みエンジニアとしてキャリアをスタートし、受託開発やWEBサービス開発を経験後、うるるへ入社
・現在は主にSREを担当
◆莊 亞帆（そう あはん / Chang ya fan） ※写真中央右
・えんフォト事業部 開発課 所属
・受託開発企業のSEとしてキャリアをスタートし、Android App・WEBサービスのバックエンド・IoT・インフラ・DevOps(CI/CD)分野の開発を経験。
・うるるに入社後、現在はえんフォトのエンジニアリングマネジャー兼クラウドソリューションアーキテクトとして活動し、組織の成長に向き合う日々
◆古賀 匠（こが たくみ） ※写真右
・業務推進・管理部 技術戦略課 所属
・新卒でエンジニアのキャリアをスタート後、WEBアプリやスマートフォンアプリの受託や委託で開発・保守運用などを経験後、うるるの技術戦略課へジョイン
各部署の問題意識が委員会発足につながった
SRE委員会はうるるのSREを推進する横断プロジェクトで、各部署からの有志メンバーで運営しています。
現在の基本活動は2週に1回の会議で、SREに関するトピックの共有や社内のSRE導入に関する支援に取り組んでいます。
SREの話題は2019年頃から社内に上がっていました。
うるるでは、古賀さんと僕が所属する「技術戦略課」が全社横断的なサービス品質の管理を統括していますが、当時から各事業のサービス品質をより向上させていきたいと考えていました。
ちょうど蔡さんと莊さんも同じ想いを抱かれていたんですよね。
はい、私は2019年に入社してNJSS（エヌジェス）事業に関わっていました。
当時からサービス品質の評価基準が存在せず共通認識がない点に課題を感じていて。
例えばメンバーに「サービスがどういう状態になったら正常かと言えるか？」と質問すると回答はバラバラで、提供サービスの一定品質が担保されていない状態でした。
私の所属するえんフォト事業では度々、サービス障害が発生していました。その障害対応の中で、どのレベルまで改善すべきなのか、どこまでリソースを割くのかを判断できずに困っていたんです。
もちろんサービスを運営する立場として、エラーが全くない高品質なシステムを構築するに越したことはありませんが、現実はそうはいきません。
完璧なサービスを作るには、膨大な時間とコストが必要になります。
何より「品質」という言葉は曖昧です。曖昧な言葉を使ってサービス品質の向上を目指すのは難しいですよね。
そんな時、SREを知りました。この手法を用いれば、曖昧な言葉である「品質」を定量評価可能な信頼性の高い数値へ変換できます。非常に素晴らしいと感じ、VPoEに「えんフォトの品質課題をSREで解決したい」と伝えました。
そうすると「NJSS事業本部の蔡さんもSRE導入を模索しているみたいだよ」、「シュフティ事業部でも品質のヒアリングを実施しているらしいよ」といった他部署の動きを教えてもらえるようになりました。
そこで情報共有を目的に自主的に声をかけ、みなさんに集まってもらいました。
ミーティングは盛り上がって、各部署でSREを導入したい意見も一致したので「じゃあ一緒にやろうか！」と委員会を立ち上げました。
蔡さんと莊さんの両者が「SREが品質管理に適している」としっかりとかみ合ったんですよね。
技術戦略課として補足するなら、あくまでもSREは品質向上を目的としたアプローチ方法の一つです。よくよく考えれば、各事業部ごとに事業特性に合ったアプローチは違うはずです。
だから品質向上というゴールに対してSREが効果的な手法であるといった視点ではなく、まずは「導入を実施して上手くいかなければ、違う手法を試してもいい」というスタンスで取り組みを始めました。
SRE導入提案に一丸となって挑戦
まずは書籍などで知識を習得し、SREが本当に課題を解消できる手法であるかどうかを再確認しました。
次に導入方法について議論し、モデルケースを構築する目標を掲げました。
一番にわかったのは、事業部にSRE担当者を置いてガッツリと取り組まないと導入は難しいということです。
そのため、SREに意欲を示してくれている莊さんと蔡さんがそれぞれ所属する、えんフォト事業とNJSS事業のいずれかで取り組んでみたいと考えました。
検討の結果、NJSSは大規模プロジェクトの最中だったため、メンバーの満場一致でえんフォトを選びました。
どの事業が導入しやすく、効果測定がわかりやすいかどうかの視点でもしっかりと話し合いができましたよね。
選定後は、モデルケース構築を提案する資料作成に取り組みました。
特に、ビジネス拡大中になぜSREに取り組むのかを言語化するのに苦労しました。限られたリソースやコストを投入する合理性や、どうリソースを捻出するかを踏まえた提案が難しかったです。
またSREの説明には専門用語が多く使われるので、ビジネスサイドに伝わりやすい説明も意識しました。定量的な試算を用いて、何がどう変わるのかを伝えるよう努力しました。
提案書には時間をかけて、一丸となって取り組みました。
ブラッシュアップも何十回やったかわからないぐらいですし、プレゼン練習を何回も繰り返しましたよね。
もちろん本来の業務もあるので、そのクオリティを落とさないようにしながら活動するのも大変でしたね。
そういった努力の甲斐もあり、事業部長からの合意を得られ、えんフォト事業部でのモデルケース構築が認められました。
モデルケース構築で良い影響が
モデルケース構築が決まるとすぐ、指標定義に取り掛かりました。
ユーザーが快適にサービスを利用するためには何が重要かを考え、サーバー継続稼働率やリクエストに対するレイテンシー（遅延時間）、エラー率などを指標に採用しました。特に可用性・パフォーマンス・セキュリティの3つの観点を重要視しています。
指標が決まると、計測を毎日行って数値をダッシュボードにまとめ、推移を追えるようにしました。これには数ヶ月かかりましたね。
SRE運用開始後は、数値が基準値を下回りそうな時には自動的にアラートが出るようになっています。アラート発生時にはその原因を特定し、関係者を集めて改修します。
最初は私とSRE運用経験のあるインフラエンジニアの2人が担当していましたが、半年後にえんフォトSREチームを立ち上げ、主体的に動いてもらっています。
長い道のりでしたよね。
事業部内にSREの担当者がいないと運用がうまく回らないことはこの実践によって強く実感しました。
運用開始から約2年経ちましたが、えんフォト事業部にSREが浸透してきているのを感じます。
昨年には新卒メンバーがSREチームに参加してくれ、ブラッシュアップする動きを精力的に取ってくれていることで、メンバーが自立して仕組みの改善と向上を推進できる体制になっています。
特に変化を感じるのは、指標について事業部長とすり合わせるようになった点です。SREの運用には、開発サイドとビジネスサイドの共通認識が重要です。えんフォト事業部全体でより安心安全なサービスを届けていく雰囲気が醸成されてきました。
直近でも指標の全体的な見直しを行いましたが、特に新卒メンバーが中心でプロジェクトを進めてもらい、えんフォト事業部全体での合意形成に大きく貢献してくれました。
そのおかげで、チーム全体に新しい視点をもたらし、より効果的な指標の確立につながりました。
また以前は大小の障害が発生していましたが、運用後は大規模な障害が1回も起こっていません。えんフォト事業部でのSRE導入モデルケース構築は成功したと感じています。
※Qiita社が開催するエンジニアカンファレンス「QiitaConference2023」にて、莊が登壇し、えんフォトにおけるSRE取り組みを発表いたしました。登壇時の発表資料はこちらからご覧いただけます。※SREの取り組み内容について詳しくまとめた記事はこちら
うるるが真のテックカンパニーになるために
この2年間の活動で、品質管理に対する考え方が大きく変わりました。
品質維持のために曖昧な言葉を使うのではなく、具体性のある数字を使うようになりましたね。メンバーとのコミュニケーション齟齬も少なくなっていると感じています。
将来的には、今回の導入で得た経験やノウハウを他事業部への導入に活かしていきたいです！
目下の課題はNJSS事業でのSRE活動を軌道に乗せていくことです。
NJSSに適応した品質評価基準を定めていきたいと考えています。
一方でSREはあくまでも一つの手法ですから、まずは概要を理解してもらった上で各事業部での取り扱いを判断してもらいたいとも感じています。
そうなんですよね。委員会の本質的な活動意義は、各事業特性に合わせた品質基準を明確にして、安心安全を確保をしていくことです。
現時点で、エビデンスを持って品質を提示できる事業部が少ないのが課題だと感じています。今後は我々が蓄積してきたナレッジを勉強会などで共有し、各事業の品質改善の力になりたいです。
機能開発だけではなく、保守運用に重きを置いた品質向上は非常に重要ですし、エンジニア以外も含めたサービスに関わる全ての人が品質を意識するべきだと考えています。
例えば「ユーザーからこういったお問い合わせがあったけど、この品質数値の低下が原因かな」のように、職種を超えて会話できる環境があれば、うるるが真のテックカンパニーに近づいていくと思います。
ゆくゆくは各プロダクトの運用保守を効果的に行うチームを作っていきたいですね。全社一体になって品質向上を目指す認識にはまだ改善の余地があるので、技術戦略課も力を入れて頑張っていきたいです。
「信頼性を上げたい」というよりも「信頼性を維持したい」という表現が一番しっくりくるかもしれません。
そして、なぜ信頼性を維持したいのか？の原点に立ち返ると、完璧な品質状態を目指すためではなく、常時ユーザーに快適で安全にサービスを利用し続けてほしいからという思いがあります。
ユーザーが喜ぶサービスを今後も提供していきます！
編集後記
品質の定義から実運用に至るまで、試行錯誤を重ねてきたエンジニア達の強い思いが伝わる対談でした。
事業部・横串組織と立場が異なるからこそ複眼的な視点で取り組めたのではないかと思います。
これからも全社一丸となって安心安全なサービスをユーザーに提供し続けていきたいと思います！
