スリーシェイクの代表取締役、吉田と申します。
「多様化するSREのキャリアマップ」というテーマで書かせていただきます。
SREの役割と必要性
SREとは
『SRE サイトリライアビリティエンジニアリング』には、SREとは「ソフトウェアエンジニアに運用チームの設計を依頼した時に出来上がるもの」とあります。解釈によって立ち回りは変わりますが、我々スリーシェイクは、「サービスの信頼性を高めるために、ソフトウェアエンジニアリングで解決していく設計やアプローチ、それを支えていく組織・文化・チーム」をまとめてSREと考えています。
ここで言う”信頼性”とは、一般的には「トイル」（価値のない、繰り返し煩雑に行われる作業）や過度な冗長構成などを減らしつつ、必要な可用性を確保しながら安定したシステムを実現し、さらにDevEx（開発者体験）を最大化してリリースサイクルを上げ、結果としてユーザーに素早く価値を届けられるようにすることです。そうした世界観を目指して取り組むのがSREのアプローチと言えます。
SREの導入で実現したい世界観
例えば、リリースサイクルが年に1回しかないような流動性の低いシステムだと、ユーザーからすると「全然サービスが良くならないな」と思われてしまいます。しかし、SREを導入して1~2日単位でアップデートできるようになると、「100日後には素晴らしいサービスになっているだろう」という信頼を得られ、ユーザーが積極的に使ってくれるようになります。
SREを導入すると可用性が上がる、冗長性が上がる、という話はよく耳にしますが、それだけではありません。サービスを良くしていくサイクルを効率化していくことこそがSREの本質であり、そのスピードアップによってユーザーからの信頼度が高まります。
例えば、東日本大震災時に安否情報の共有にX(当時:Twitter)が使われたのは、SREの原則を体現していたため安全性が高く、信頼できるとみんなが感じたからではないでしょうか。まさにサービスとユーザーの間でエンジニアリングを通じた信頼関係が築かれていたと言えます。
このようにSREはインフラだけではなく抽象度が非常に高い考え方です。サービス全体を見渡し、ユーザーの体験をどう最大化していくかを考えるエンジニアリングの基礎となるアプローチだと、捉えています。
SREに求められるスキル
幅広い知識とソフトウェアエンジニアリング
SREに求められるスキルセットは抽象度が高い分、かなり幅広く求められます。一般的なTCP/IPやOSの知識はもちろん、ソフトウェアエンジニアリングのスキルが不可欠です。
例えば、TerraformなどでAWSやGoogle Cloud上にインフラを構築しても、その上で動いているアプリケーションがどんな構造なのか全然わからない状態だと、正直SREとしてはやりにくい部分があります。アプリケーションのソースコードを読んで「こういうデータの流れだからLambdaやPub/Subを使うんだな」といった背景を理解できる必要があるので、少なくともコードを読める力があったほうが、SREとして動きやすくなります。
サービスへの理解とビジネス視点
また大事なのは、サービスと対峙していかなければいけないという点です。SREは単なる要件定義通りの実装ではなく、信頼を獲得することが目的です。そのためには「サービスが何を目指しているのか」を知ろうとする姿勢が重要です。ビジネスサイドが何を考え、開発サイドがどんな方向を見据えてサービスを作っているのか、そうした部分を理解しようとする能力が求められてきます。
AWSやDatadogなどSREで利用するサービスは複数ありますが、全部習得するのは正直難しく、私たちも最初から全部カバーできるとは思っていません。大事なのは、OSやネットワーク、オブザーバビリティなどのベースラインを押さえつつ、「サービスをどう良くしていくのか？」を考えるためのコミュニケーション力だと思っています。
ただやみくもに知識をため込んで大量にコードを書くのではなく、SREはさまざまなレイヤーのエンジニアリング集団やビジネスレイヤーを巻き込み、一体となってユーザーの信頼を獲得するためには何をすべきかを引き取る存在だと考えています。
そういう意味では、いろいろな人に声をかけて課題を洗い出し、「ここのアーキテクチャに問題があるんだな。じゃあビジネスチームに状況を伝えて、リリースサイクルを遅らせてもらおう」といったコミュニケーションができるかがポイントです。そうしたやりとりを前向きに取り組める方は、SREと相性がいいのではないかなと思います。
SREになるためには
SREを目指す2つのパターン
主にSREになる方は2パターンあると思っていますが、これからSREをやってみたいと思っていらっしゃる方がいたら、ぜひ挑戦していただきたいです。
インフラエンジニアからSREへの道
1つ目はインフラエンジニアやネットワークエンジニアなど、オンプレミス領域で活躍していた方が「SREをやっていきたい」と考えるパターンです。
インフラエンジニアの方がSREを目指すのであれば、ネットワークとOSの知識を強みにして、まずクラウドネイティブな技術やIaC、Kubernetesといったクラウドのデザインパターンを押さえることがいいと思います。同時にプライベートでもいいのでサイトを作る経験をしてみるのがオススメです。最近ならクラウドや生成AIを使えば手軽にWebサイトやAPIを作って、全体のデータフローを把握できます。そうするとSREに転身したときに全体感を理解しやすいです。
また、インフラレイヤーに強い方はデータベースのテーブル設計やネットワーク設計をベースに課題を見つけ、「そもそもインフラのアーキテクチャがボロボロだよね」といったところから改善策を提案できます。これはSREとして大きな強みになると思います。
フロントエンドエンジニア、モバイルエンジニアからSREへ
2つ目はフロントエンドやサーバーサイドのエンジニアの方が、より低レイヤーのSREをやりたいというパターンです。
「モバイルしかやってこなかった」「フロントエンドしかやってない」という方には、まずサーバーサイドの開発をプライベートや実務でやってみるといいと思います。そうするとクラウドやOS、ネットワークの話にも対応しやすくなります。弊社でもフロントエンド出身なのにSREで大いに活躍しているメンバーがおり、「フロントだからインフラやSREは無理」ということは全くありません。
実際、SREを極めている人はまだ世の中に少ないので、サーバーサイドの経験がある方ならパフォーマンスチームとかアプリケーションレイヤーのアーキテクチャに強いですし、インフラエンジニアの方ならアーキテクチャ面で強みを発揮できるはずです。結局は皆さんの強みを活かしたSREが実現できると思います。
実は採用現場での体感としては、後者の上位レイヤーからSREを目指す方が6割以上で、前者のインフラエンジニアからSREを目指す方は意外と少ない印象です。
SREへの最初のステップ
SREという仕事は「全部知らなきゃいけない」というスーパーマン的なイメージを持たれることもあるんですが、そうではなくて、まずは自分の得意分野からSREの役割を果たしていくといいと思います。
また、組織としてSREの立ち上げ段階で「何から始めようか？」となった場合にも、まずはモニタリングやインシデント対応といったところからアプローチしてみるといいかもしれません。やりやすい部分から一歩ずつ進める、あまり身構えずに始める、ということが大事になります。
SREのキャリアパス
多様なキャリアの広がり
SREになった先のキャリアパスとしては、VPoEやCTOなどのマネジメント職はもちろん、SREのなかでも、より専門型に特化していく方もいます。例えば、SREの技術をベースにセキュリティの領域を強みにしていく方、DBRE（データベースのリライアビリティ）を極める方など。
また、「やっぱり開発に戻りたい」と思いバックエンド領域にキャリアチェンジされる方もいらっしゃいます。ほかには、SREのできる方はコミュニケーション力の高い方が多いので、そのまま現場を離れてPMやコンサルタントになる方も多いです。コミュニケーション力やアーキテクチャを俯瞰する力など、そういった能力が活躍しているのではないかと推察しています。
スタートアップからのキャリアパス
また様々な企業のSREを支援しているなかで、スタートアップと大手ではSREのキャリアが違うなと感じていることもあり、その違いについても簡単にご説明したいと思います。
スタートアップのSREの方は、大きく3つに分かれます。
1つ目は社内でキャリアチェンジやキャリアアップをして、どんどん極めていくパターン。いわゆるスタッフエンジニアリングやインディビジュアルコントリビューター路線です。サーバーサイドへキャリアチェンジして開発に染み出す方もいて、その延長でEMやVPoEになるケースもあります。
2つ目は、SREとして転職していくパターンです。経験豊富なSREがスタートアップに参画すると、短期間（おおよそ1年〜1年半）で主要な課題を解決し尽くしてしまい、新たなチャレンジが見つけにくくなるケースもあります。SREは業界によってやるべきことや指摘する内容が全然違うので、業界を変えてリファレンスを増やすことや、大きな会社で役割を成熟させる、あるいはあえて創業メンバーに加わりCTOやVPoEを狙いにいくなど、多様な選択肢があります。
3つ目はSRE以外にキャリアチェンジするパターンです。例えば開発職に移るとか。また、外資系に行く方も多く、プリセールスエンジニアやカスタマーサクセスエンジニア、最近ならDeveloper Advocateのような役割になる方も多いです。開発やインフラにも詳しくないと扱えないプロダクトも多いので、そういう方が活躍されるケースがよくあります。スタートアップやベンチャーは1年半から2年で次を考える方も多く、2年ほどで次の企業に移られるケースも最近はよく見られます。
大手企業からのキャリアパス
大手企業の場合も同じように3つのパターンがあります。
1つ目の社内でのキャリアチェンジやキャリアアップにおいてスタートアップと違うのは役職級（部長、本部長、次長など）への昇進です。SREでの経験がマネジメント力や俯瞰力を養うので、それらを活かして上の役職に行く方が割と多いです。これはインフラエンジニア出身の方でもよく見られます。
2つ目は転職するパターン。大手だと大規模なSREをやる分、全体感をつかみにくい部分があって、「作るところから運用するところまで全部見たい」というモチベーションでスタートアップに転職する方が多く、意思決定のスピードや権限移譲の度合いも違うので、そういう環境を求めてスタートアップを選ぶ人も多いです。
3つ目として実は多いのが、キャリアチェンジで大手から外資系に行くケースです。皆さんが日々使っているような有名なクラウドサービスへ転職する方が増えています。
大手企業に在籍している場合は判断の時間軸を3~5年くらいで考える方が多く、スタートアップとは異なり、1年や2年でころころ変わるケースは新卒以外だとあまり見ません。
まとめ
SREポジションの抽象度と求められる心構え
SREはまだできたてほやほやのポジションで、すごく抽象度が高く、人によって解釈の違う役割が求められます。なので、自然とスキルセットは広がっていきます。そのうえで大事なのは、ブレちゃいけない部分、つまり他のチームとのコミュニケーションや、そのサービスへの愛情だと思います。ユーザーの信頼を獲得していくには、サービスに興味を持って「何が信頼性なんだっけ？」を定義できることが重要なので、そこが肝心だと思っています。
SREキャリアの多様性
SREはどこからでもキャリアを作っていくことが可能だと思っています。「こういうキャリアじゃないとSREになれない」なんてことはなく、SREになった後のキャリアについても、無限大だと感じていて、開発に強みがある場合にはリードエンジニアやEMを経てCTOになるみたいな一般的な道もありますし、SRE領域から外資系に進んだり、マネジメントや経営側に行ったりなど、かなり幅広い選択肢があります。
最終的に一番大事なのは「どこに腰を据えるか」ということです。コロコロとキャリアチェンジを繰り返してしまうと、SREとして活動できる領域が減ってしまうこともあります。長い目で見て、自分が腰を据えて活躍できるポジションはどこなのかを考えていくことが、結果的には自分にとっても組織にとっても良い選択だと思います。
スリーシェイクでは一緒にSRE界隈を盛り上げてくれる仲間を大募集中です。興味のある方はぜひカジュアル面談にお越しください。