「シゴトでココロオドルひとをふやす」をミッションにビジネスSNS「Wantedly」を提供するウォンテッドリー株式会社（以下 Wantedly）。個人向けには会社訪問アプリ「Wantedly Visit」とつながり管理アプリ「Wantedly People」を、企業向けには採用サービスとエンケージメントサービスとしてオンライン社内報「Story」、チームマネジメントサービス「Pulse」、福利厚生「Perk」を提供しています。各プロダクトのプラットフォーム構築やプロダクトの信頼性を高めるSRE領域の業務を担当し、Wantedly全サービスの裏側を支えるInfrastructure Squadリーダー 齋藤悠一さんは、SREにおける2つの課題を抱えていたと語ります。課題解決に向けてSRE as a Serviceを利用した同社で、どのような効果があったかを伺いました。

齋藤：SREは企業によって温度差が激しく、新たなプロダクトを次々と生み出すことが優先されるがあまり信頼性が疎かになってしまう企業や、SREの重要性を理解しているものの実行に移せないという企業も少なくありません。その点、WantedlyはSREの重要性が組織に理解されており、プロダクトの信頼性が損なわれれば開発をいったん止めてでも信頼性の回復のためにエンジニアリングソースを割いたり、また逆に信頼性を満たす範囲で高速にプロダクトのリリースを行ったりと、開発速度と信頼性のトレードオフを考慮しつつプロダクトやシステムの改善を進めることができています。またSREの領域に協力してくれるメンバーも多く、SREを重視する文化が形成されつつある状態です。

齋藤：SREに関しては2つの課題がありました。1つは、人員不足が原因でSREの優先度を高められないという問題です。システムと開発組織の規模の大きさに対してSRE as a Service採用以前はSREの取り組みをメインで行っているInfrastructure Squadのメンバーが3人 （2021年10月現在6名） と少なく、人数が十分に足りていない状態でした。

また私達のチームでは主に組織やサービスが継続的且つ高速で成長できるようにする目的で、高い信頼性と生産性を持つシステムアーキテクチャの構築や開発者から利用されるアプリケーションプラットフォーム、ツールチェインの提供を行っています。一方で社内ネットワークの構築やセキュリティ対策といった情報システムの領域の業務も担当しており、チームとしての業務の領域は多岐に渡ります。これらの理由により、チームのリソースがどうしてもメンテナンス作業やコスト削減といった緊急性の高いタスクに優先されてしまっていました。 そのため繰り返し行われる自動化が可能な業務いわゆる TOIL の解消も十分に行えず、結果として信頼性や開発生産性の向上に対して、先回りして対処することができない状況でした。

齋藤：もう1つは将来的なSREの戦略立案です。SREを重視する社内文化が醸成されている環境でさらにもう一歩、全社的にSREを進めていくうえで欠かせない、方針やビジョンを確立できていない状態でした。

齋藤：もちろん社内のメンバーとのディスカッションや他の企業のSRE担当者、知り合いのエンジニアとのコミュニケーションなどを交えながら、社内外でSREについての情報収集は行っていました。一方で自社のSREのカルチャーをフィードバックした意見を得るのは難しく、方向性はある程度イメージできるものの「自分たちにとってこの方向性は本当に正しいのか？」という確証は持てませんでした。そのため社外のSREの経験者から第三者視点のフィードバックをもらいつつ、社内のSREの活動を着実に前に進めていく方法はないか、と模索していました。

齋藤：採用で人員を増やすのはそうですが、外部のSRE経験が豊富な方に外部講師を依頼やアドバイザーとして加わってもらうことも検討していました。そのタイミングで、TopotalさんがSRE as a Serviceのサービス開始したことをCTOの川崎が知り、私たちが抱えている課題とマッチしそうだったので、話を伺うことになりました。

SREに限った話ではありませんが、あらゆる組織においてその組織内だけで知識を蓄積していくと、組織変革のフェーズではバイアスになってしまい、成長の機会が失われるケースがよくあります。採用や外部の講師を招くことで外部の知識を取り入れながら、「社内文化」として少しずつアップデートしていく必要があると思うのです。

その観点から、さまざまな企業でのSREの経験と知識を持つスペシャリストのような人から知識を受け取れること、さらにSREの改善だけにとどまらずチーム、ひいては開発組織メンバーの成長の機会を作る観点でも、SRE as a Serviceがよさそうだということで採用を決めました。

齋藤：SRE as a Serviceで取り組んでもらった大きなプロジェクトに、障害対応フローの構築があります。現状は障害対応が発生した際、Infrastructure Squadのメンバーが障害を検知してプロダクトチームへとエスカレーションし、障害対応を専門とするチームとプロダクトチームが一緒に障害を解消する体制になっています。この体制では、組織のスケールについていけないと思っていて。

齋藤：すべてのプロダクトにInfrastructure Squadは関わっているものの、個々のプロダクトに対する知識はやはり限定的になります。いろいろなマイクロサービスなどが生まれ、日々変化するシステムをすべて把握するのは難しいものがあります。そのため、障害を素早く解消するには、プロダクトを一から理解しているプロダクトチームが障害に気付いて対応することが重要だと思っています。

単に障害対応のフロントをプロダクトチームが担当するだけではなく開発からリリース、その後の運用までのすべてのサイクル（Software Development Life Cycle：SDLC）を単一のチームで担うのが、プロダクトの信頼性を上げつつ素早くプロダクトを作っていくうえで理想的な構造だと考えています。

障害対応やサービスの信頼性に責任を持つという意識をプロダクトチームに根づかせるためには、エンジニア全体の障害対応スキルを向上させること、誰が担当しても素早く解消できる均一のオペレーションフローを構築することが必要です。そしてその実現にはSREのプラクティスが重要です。

Topotalさんには、目の前の目的にとどまらず、将来像の枠組みについてもディスカッションをしながら、障害対応のフローを明確にしてツールに落とし込んでもらいました。SREの知見も申し分なく、ツールはうまくワークしています。

齋藤：障害対応フローの確立と支援ツールができたことで障害対応の全体像が把握できるようになり、効率よく障害対応を行えるようになりました。改善されたフローや導入したツールは障害対応にあたるエンジニア全体に認知され、障害対応に対するマインドセットも変わり、行動も変わるところが見えたのが大きな変化でした。僕たちが目指していきたい世界に着実に進んでいると実感しています。

また先に話した通り、外部の知見や外部の開発者のナレッジをチームや組織に還元することによって、SREの活動やチーム内外のメンバーの能力を向上させていきたいという狙いもありましたが、これは期待通りに働いています。取り組むタスクについて社内ではなかった視点から意見やアプローチを提案、またそれらを通して技術やエンジニアリング全般など広いフィードバックを得られており、チームやメンバーの成長の機会につながっていると考えています。

齋藤：私はソフトウェアエンジニアとしての歴はWantedlyに入社してからなのでかなり浅く、またSREというコンテキストで仕事をし始めたのもここ2〜3年です。またWantedlyはサービスや組織の規模が拡大していく今まさにその過程にいるのですが、一方でWantedly自体が若いメンバーで形成されている組織ということもあって、他の企業がサービスや組織、システムが成長する過程でどのような問題に遭遇しそれをどのように解決していったかという知識や経験が組織に十分に蓄積されていないと思っています。 そういった状況もあり、自分がWantedlyでSREとしてどのように貢献すべきかという部分で悩みを抱えていました。Topotal さんと一緒に仕事をすることを通して、不足していた情報がかなり補完され、自分がWantedlyで今後やっていくべきことの解像度がかなり上がったと実感しています。

齋藤：私たちが携わっているSRE業務への理解はもとより、社内の状況やSREのカルチャーをより深く浸透させていくことを重視する背景もちゃんと理解したうえで、SREという仕事自体がよりよいものになっていくためにはこういうやり方をしたらいいんじゃないかとか、タスクだったりプロジェクトに対してこういうアプローチで解決するのがよさそう、といったアドバイスをしてもらえるところが、SRE as a Serviceでなかったら得られなかったのではと感じています。

齋藤：私たちは、社内全体にSREの取り組みを拡大して、プロダクトの生産性も信頼性も向上することを実現したいと考えています。そのために、Topotalさんの知識や経験を活かしながらプロダクティブな施策に対しても協力してもらい、SREを社内にいっそう浸透させ、より一歩踏み込んだタスクも一緒に進められたらと思っています。