SREの求人は本当に増えている?職種の中身で見る転職の判断軸

「クラウド時代だから、SREは安泰」。求人サイトやSNSでそう言われるのを、よく見かけるようになった人は多いはずだ。転職サイトで「SRE」と検索すると、以前より案件が目に入る。だから「需要が増えている」という話を鵜呑みにして、次の一手を決めてしまいそうになる。

だが、その前に一つだけ確かめてほしい。あなたが目にしている「SRE」という求人は、どれも同じ仕事を指しているだろうか。

この記事の要点（TL;DR）

• 「SRE求人が増えている」という話は、求人の“中身”を見ずに数だけで語られがちだ
• SREという一つの名前の下に、実際は正反対の二種類の仕事が混在している
• 一つは「運用・監視の延長」、もう一つは「コードで信頼性の課題を解く」仕事で、求められる経験が逆向きだ
• 見るべきは求人の増減ではなく、自分の経験がどちらの椅子に効くか

「増えている」という言葉が、中身を素通りさせる

SREという職種名は、もともとGoogleが提唱した考え方から来ている。SRE（Site Reliability Engineering、「信頼性エンジニアリング」）とは、システムの安定稼働という運用課題を、手作業の積み重ねではなくソフトウェアエンジニアリングで解く、という発想だ。壊れたら人が直すのではなく、壊れにくい仕組みや自動復旧のコードを書く。運用の問題を、運用の外から解決する職種として生まれた。

この発想が広く知られるようになり、日本の求人票にも「SRE」の文字が増えた。ここで起きているのは、単純な需要の増加ではない。「SRE」という看板を掲げる求人が増えたという現象であり、看板の中身が一つに揃っているとは限らない。看板の数を数えて「需要が伸びている」と語るのは、中身を素通りした議論だ。

同じ名前の下にある、二つの正反対の仕事

求人票を読み比べると、SREという名前の下に、性格の違う二つの仕事があることに気づく。

一つは、従来の「運用・監視」をそのままSREと呼び換えたタイプだ。業務の中心は障害の一次対応、監視ツールのアラート対応、定型化されたオペレーションの実行。インフラやサーバーの知識、障害対応の経験が重視される。仕事の実態は、名前が変わる前の運用保守とそう遠くない。

もう一つは、Googleの発想に近い、信頼性をソフトウェアで解くタイプだ。繰り返し発生する障害の原因をコードで潰す、手作業の運用をツールとして自動化する、SLO（サービスレベル目標。「このサービスはどこまで落ちてもいいか」をあらかじめ数値で決めておく指標）やエラーバジェットの考え方で改善の優先順位を決める。こちらで重視されるのは、開発経験とコードを書く力だ。

この二つは、求められる経験がほぼ逆を向いている。前者は運用・インフラ側の経験が強みになり、後者は開発側の経験が強みになる。同じ「SRE」という三文字の求人票が、入口の時点でまったく別の椅子を指しているのに、名前だけ見ると一つの職種に見えてしまう。

求人の増減ではなく、「どちらの椅子が増えているか」を見る

ここで「SREの需要は増えているのか」という問いの立て方自体が、あまり意味を持たないことが分かる。看板の数を数えても、二種類の椅子が混在した合計しか分からない。知りたいのは、自分が座れる椅子が増えているかどうかのはずだ。

だから求人票を見るときに確かめるべきは数ではなく、記述の中身になる。「監視・一次対応・インフラ運用」という単語が並ぶ求人は、運用延長型の椅子である可能性が高い。「自動化の開発・SLO設計・ポストモーテム（事後検証、障害の原因と再発防止策を振り返って文書化する文化）の運用」といった単語が並ぶ求人は、信頼性エンジニア型の椅子に近い。同じ会社の求人でも年によって中身が入れ替わることがある。例えば、以前は「監視・一次対応」としか書かれていなかった求人票に、翌年はSLOやオンコール（障害発生時に呼び出されて対応する当番体制）といった語が加わっていることもあれば、逆に減ることもある。「SREだから」と一括りにせず、毎回この二軸で読み直す必要がある。

自分の経験がどちらの椅子に効くかで決める

職種名で迷っている人に伝えたいのは、「どちらが正解か」を決める話ではないということだ。正解はなく、自分の経験がどちらの椅子に効くかで判断すればいい。

開発経験が長く、コードを読み書きすることに抵抗がない人であれば、信頼性エンジニア型の求人の方が、持っている経験をそのまま活かせる。逆に、インフラや運用の現場で障害対応の経験を積んできた人であれば、運用延長型の求人の方が、入口としては自然に通りやすい。

注意したいのは、運用延長型の入口から入ったあと、その会社が信頼性エンジニア型への成長投資をしているかどうかだ。自動化や開発への関与を広げていく道筋がある会社なら、運用延長型の入口も足がかりになる。一方で、名前だけSREに変えて実態は運用保守のまま変わらない会社だと、経験の幅が開発側にはなかなか広がらない。入口の名前より、面接で「このチームは何を自動化してきたか」を聞く方が、数年後の自分の経験を左右する。

今日からできること

1. 今見ている「SRE求人」が、どちらの椅子かを求人票の単語で確かめる。 「監視・一次対応・インフラ運用」寄りか、「自動化・SLO・ポストモーテム」寄りか。
2. 自分の経験が、開発側・運用側のどちらに積まれているかを一度整理する。 どちらの椅子に、今の経験がそのまま効くかを考える。
3. 運用延長型に応募するなら、面接で「このチームは何を自動化してきたか」を聞く。 入口の名前ではなく、成長の道筋があるかで判断する。
4. 信頼性エンジニア型を目指すなら、開発経験の棚卸しを先にする。 コーディング力は報われないのかでは、実装を積んだ経験がどこで効いてくるかを扱っている。

まとめ

「SREの求人は増えているか」という問いは、二種類の違う仕事を一つの名前でまとめて数えてしまう問いだ。求人票の中身を見ると、運用・監視の延長としてのSREと、コードで信頼性を解くSREという、求められる経験が正反対の二つの椅子が同じ名前で並んでいる。

数の増減に煽られず、自分の経験がどちらの椅子に効くかで考えること。それが、名前に振り回されずに次の一手を決める一番確かな方法だ。

実際の求人でどちらの椅子が多いかを確かめたいときは、SREの求人・転職エージェントから求人票を読み比べてみるとよい。どちらの椅子を選ぶか見えたら、次に必要なのは学ぶ中身だ。tasklogは、LinuC（Linux技術者認定）のような基盤系の資格からAWSなど開発寄りの資格まで、合格体験記や技術記事に実際に登場する教材・参考書の引用を集計しているサービスで、自分が目指す椅子に近い現場で、実際に何が読まれているかを確認する手がかりになる。