先月の真ん中ぐらいから新天地のLayerX AI・LLM事業部*1でSRE（Site Reliability Engineering）を主とするエンジニアとして新たなキャリアを歩み始めました（報告したブログはこちら）.
「野球エンジニアやってた人」「バックエンドからインフラから機械学習まで割となんでもやってるマン」が大筋な自分のPublic Image（=多くの方の認知）であり, 自分から見てもそれは事実かなぁー, なのですが.
「何故SREというキャリアを選んだの?」っていう話はあまりしていない気がしているので, それを語ろう！というのがこのエントリーの主旨となります.
なお, 「LayerX AI・LLM事業部のSREとして」的な話は一切ありません, その話は会社のテックブログの以下エントリーに綴っているので見てやってください.
TL;DR
今の自分の経験とスキル, スタンスを考えるとSREが最も最適でした&本職のSREとして伸びしろになることを学び直しているやで.
SREを選んだ理由
一応言っておくと, 私の昨年の転職活動にて「SREがやりたい！」と絞ったわけでは決してありませんでした.
複数社のカジュアル面談や選考を通してSREという方向性が定まった, というのが正直なところです.
IC or EMなら何でも良かった転職活動
昨年の転職活動ではIC（Individual Contributor / 個人貢献者）もしくはEM（Engineering Manager）的な方向であれば専門性・ポジションは全く拘っていませんでした.
- 事業会社エンジニアチームのマネージャー/IC(シニアエンジニア)を希望しております.
- エンジニア職の中におけるマネジメント（PdM含む）もしくはシニアエキスパート（ICなど）で活躍できる職を希望しています（兼務も可）
- データエンジニアリング, SRE, クラウドエンジニアリングが得意分野となります.
- フィールドエンジニア（技術コンサル）およびソリューションエンジニアも検討に入れています.
※自分の職務経歴書（CV）におけるポジション希望の一文より引用.
キャリアと実力的にはシニアの領域*2, 「よく行ってるスタバや居酒屋のアルバイトさんの親御さんと同い年前後である*3」ぐらいのおじさんが, 「Pythonやりたい」「XXXは嫌だ」っていう理由だけで職探しをするものではない*4のと,
- 前職はSREとクラウドアーキテクトなコンサル
- その前はデータ基盤エンジニアとPdM
- さらにその前は小さい会社のCTOとしてのフルスタックエンジニア
これらの経験とスキルを持って挑むとどのようなオファーが来るか?というのを楽しみにしながら（探りながら）活動しました.
ちなみにですが,
- Public CloudはできればGoogle Cloud（次点・AWS）を希望. 理由としては即戦力的にすぐ貢献できるものが良かったため*5.
- 経験はあるものの, フロントエンド主体のチームは優先度Sage*6.
- スマホアプリ（iOS/Android）*7, IoTは状況によりにけりで考える*8.
- 英語は自信が無いので(ry
迷ったときの優先度付けは上記に従ってやりました.
SREポジションに対する需要と難しさ
結論から言います.
SREの募集と需要, めちゃくちゃ多かった（そして今も多い）です, 故に選択肢はほとんどがSREでした.
通常のソフトウェアエンジニア（SWE）や機械学習, 生成AI系のポジション*9も選択肢とありましたが, 圧倒的にSREの選択肢が多かったです.
これを思ったのが, 転職活動を始めた昨年夏から秋の話.
ワイ「SREリードとかシニア職の募集, めっちゃ多すぎでは?!」
前述の通り, ICもしくはEM的な方向であれば専門性・ポジションはこだわりゼロ. で考えていたとはいえ, ここまでSRE多いか！という事実には驚きました.
加えて, SREのJob Description（職務要件）は
- 自社で使ってるプロダクトの技術領域を経験あって（未経験でもできそうな可能性があって）
- デプロイやテストの自動化ができて
- 障害対応や報告, 関係各所とのコミュニケーションと運用ができて
- 高負荷対策やセキュリティを考慮したアーキテクチャの選定と設計, 実装ができて
- 何だったらビジネスメンバーとのコミュニケーションも取れて(ry
などなど, 複雑化とカオスの極地（最後のビジネス云々は他のSWEポジションも言われがち*10ですが）だったりしました.
しかし自分はこう思ったりもしました.
ワイ「もしかしてSREって自分の長所を活かせるのでは???」
このブログにある通り, 「10社ほど選考」「20社ほど話を聞いた」中で自分のキャリア・アスピレーションを見直したり内省した結果, 「私, SREがやりたいのでは」と気が付きSREとして40代後半のチャレンジを決意しました.
やりたいことはSREだった
端的に言うと, 「shinyorke流の『フルスタック（フルサイクル）エンジニア』に対する解がSREにありそう！」と感じた, すなわち「今ワイはSREをやりたいんじゃ！」と気が付きました.
先程の「皆さん割と求めがち（でも難しい）SREのJob Description」に当てはめると...
- 自社で使ってるプロダクトの技術領域を経験あって（未経験でもできそうな可能性があって）
すべての技術スタックを抑えてないかもだけど, たいていの場合やったことあるorやれそうで興味あればなおのこと.
- デプロイやテストの自動化ができて
仕事も趣味のプロジェクト（個人開発）両方で導入したり, 環境整備をしているのでなんとかなるだろう
- 障害対応や報告, 関係各所とのコミュニケーションと運用ができて
これは主に前職で散々やってきた. 解決から報告, ポストモーテムまで一気通貫に対応していい感じに解決.
- 高負荷対策やセキュリティを考慮したアーキテクチャの選定と設計, 実装ができて
スタートアップ時代のエンジニアリングで体験しているのと, セキュリティ専門じゃないにしても考慮すべき・議論になりそうなポイントで選定と設計, 実装はいける.
- 何だったらビジネスメンバーとのコミュニケーションも取れて(ry
社内のエンジニア以外のステークホルダーは勿論, クライアントを含めた社外のステークホルダーとも専門家としてコミュニケーションをとり推進できる.
...あれ?割とすべて行けそうじゃない?って思いました.
加えて,
- SRE的なミッションをこなすにもSWEの経験重要*11で幸いにもこの経験は豊富に積まれている.
- ビジネス的な要件...の裏にある法令的なモノ（例えば金融におけるFISCなど*12）といった気をつけるポイントがわかる.
- エンジニア向けの会話と, そうじゃない人向けの会話をいい感じに分けられる*13&双方を理解させるようなブリッジ的なコミュニケーション*14もできる.
という「自分の強みを活かせる」ポイントも多いとも思いました, いずれも前職および前々職以前の経験ですねと.
前々職までのベンチャー時代はフロントエンド, バックエンド, 機械学習にインフラ.
前職ではクラウドインフラとDevOpsのほぼ専任で行ってた自分としてはすべての経験を活かしつつ, 「フルスタックなエンジニア」に対する解を出せると面白いなと思い, SREを選びました*15.
SREとして学び直している事
「事業会社の専任SRE」というキャリアを見事に勝ち取った私ではありますが,
ワイ「そもそもSREって何でしたっけ?」
...という, 基本的な所から見直す必要があるなと思いました.
見直すきっかけはLayerXのオファーを承諾した2024年の年末, 「一ヶ月の休み何をしよう?」と考え始めたときです.
「迷ったらゼロベースで考え直して動く」のが自分のスタンスであり習慣だったりするので,
- 「SREのはじめかた」を学ぶ
- 「SREのチームをどうやって作るか」を考える
- 「クラウドなアーキテクチャ」の戦略と実装をゼロから学び直す
以上をLayerXにJOINするまでの自分の宿題として課すことにしました.
SREをはじめる
SREのはじめかた, の教科書はこちらです.
「SREをはじめよう」は本当に名著だと思います, 2周ほど読みました（暗記はしていないけど）.
この本の内容を自分なりに解釈すると,
- SREとして入門する
- SREとはなにか
- 持つべき心構え
- 醸成すべき文化
- ストーリーと聴衆を明確に
- 個人としてSREになる準備
- スキル
- 採用
- 1日の過ごし方
- 組織としてのはじめかた
- 成功するSRE組織のあるある
- 失敗要因・禁じ手
- ビジネス視点でのSRE
- チームの進化とスケール
みたいなことが網羅的かつ, 実践した事をベースに書かれていて素晴らしかったです.
「SREをはじめよう」という「開いた」タイトルで優しく見える一方, 読むとかなりハードな一冊*16ですが,
- SREをやってる/これからやる人
- SREの組織化をしている人
- SREの採用に困ってるエンジニア組織の責任者
はマストで読むべき一冊だなと改めて思いました.
また, 加えて今はオブザーバビリティの実践やOpenTelemetryもちゃんと学びたいので,
このあたりも読み始めています.
チーム作り
チーム作りの観点では「エンジニアとしてコミュニケーションをどういい感じに取るか?」を改めて考え直しました.
ここはSREというより, 「エンジニアリングマネジャーとしての方法論」を学び直す事に振り切りました.
今は立ち上げ期かつ, SREとしては社員が私だけ, 数名の業務委託さんがいるチーム*17という感じですが,
- 限られた時間とパワーを何処に注力するかを決め
- 決めたことをチーム内外のステークホルダーに宣言し
- 「SREチーム」として幸せとやる気, ケアをしっかりする
この土台作りがめちゃくちゃ重要*18で, チームをスケールするにも必要不可欠と思ったので学び直しました.
クラウドアーキテクチャの戦略と戦術
最後はめっちゃ技術書な書籍です.
このブログでも何度か紹介している「クラウドストラテジー」ってやつです.
SREのステークホルダー, 特にnotエンジニアな方々やクライアントの担当者などが気にするような事柄や論点にたいする考え方がいい感じにまとまっています.
前職で紹介してもらった書籍なのですが, これが本当に良い教科書になっています.
「DevOpsって何」「IaCはやる必要あるのか」「クラウドに対する投資」「組織パターン」等など, 色々載っていて便利な一冊です.
現職でのミッションを踏まえたうえで年末に読み直しましたが新たな気づきもあったので良かったです.
結び - SREとして1年後どうありたいか?
「40代後半戦のキャリアとしてSREを選んだ理由と学び直していること.」というテーマで,
- 「何故SREというキャリアを選んだの?」という問の答えは「今までの経験・スキルの集大成としてSREをやりたかった」でした.
- SREを本気でやるにあたり, はじめかた・マネジメント・クラウドアーキテクチャの戦略と実装を学び直しています.
という話を書きました.
これはあくまで私shinyorkeが置かれている状況がそうだった, というだけでSREを選ぶ理由や魅力, 何を学ぶか?的な事はSREの数だけ答えがあると思っております.
このブログで学びになった・ヒントになった方が一人でもいると嬉しいですし, 「いや私はもっと別の考え方が」なんて意見があったら伺いたいなと思っています（反対意見も含めて）.
また, 詳しく話してみたいなんて方がいたらぜひコンタクトしてください, 興味がある学生さんでも経験者のSREでもSWE的な人でもなんでも.
最後に, 私は1年後の今どうなっていたいか?という所ですが.
- 担当しているプロダクトのSREとして最高のユーザー体験そして開発者的なExperienceに貢献する.
- 生成AIをバディとして, SREの新たなやり方や働き方を形にする.
事で成果が出るといいなと思っています&具体の話が気になる方は...会社のテックブログの方に色々書くのでそちらをご覧ください🙏
最後までお読みいただきありがとうございました.
*1:余談ですが私はかの有名なバクラクとは全く違う事業部なのでバクラクの仕事はしていないです（メンバーとの交流はあって, 早速仲良くやらせてもらってます）. なおバクラクは入社してから初めて使いましたが超絶便利すぎて飛びました（素晴らしい）.
*2:客観的に見てもそう言って怒られないとは思うし, 40歳を超えてからの仕事の期待値ってこれなので.
*3:すべて実話です.
*4:あくまで私がって意味で. 個人的にはこの理由で探しても良いとは思いますが, 自分より若い人のみならず生成AIとの付き合い方が重要な昨今ではすぐ詰むのではと思ってますこの考え方は.
*5:それで言うと現職で使ってるAzureは未経験だったのですが, 選考中にどうにかこうにかした結果「イケる」と判断しAzureな環境を選ぶことを決めました.
*6:がちなフロントエンドエンジニアではないので, 足を引っ張る懸念が.
*7:（そりゃそうだろうって感じですが）これに類するオファーは数件のみで結果的に相手にしませんでした.
*8:ちなみに最終オファーを頂いたもう一社はIoTの会社でした.
*9:ちなみにですが機械学習・生成AI系のデータサイエンティストやエンジニアなポジションは敢えて優先度を落として見ていました. データ系についてはDREなど, SRE要素強めのポジションを応募したりしました.
*10:持論ですがこの文脈は社内のステークホルダーだけなのか, クライアントを含めた社外なのかによって違うはずですが別れてないんですよね...っていうnoteはいずれ書いてみたい.
*11:前職以前の経験で若干辛かったのは「CI/CD組めるけどアプリケーション開発は素人」「アプリケーション開発はできるけどCI/CDわからん」的な奴で「どっちがやるべき」みたいな空中戦がありまして... 私としては両方知るべき・組めるべきであると思ってますし, この悲しみ（と面倒なコミュニケーション）は少しでも減らしたいなと思っています.
*12:他には知財とか. 士業じゃないにしても「作ったものの権利」「ソフトウェア開発的にはセオリーでもドメインによってはセオリーが通じないもの」を見極めながらやることは大事だし, それを教えてくれた前職にはめちゃ感謝しています.
*13:これは喧嘩の仲裁も含める.
*14:私がプロのソフトウェアエンジニアとして提供できる最大のバリューかもぐらいに思っています. 前職以前もこの説明力とコミュニケーション力で難問を切り抜けてきたので.
*15:更に加えると, DRE（Data Reliability Engineering）やSWE寄りの事は既にやってきていることで, 「事業会社の専任SRE」だけ未体験領域だったからというのもあります. 何やかんやでやったこと無いことに魅力を感じるので.
*16:私はすんなり読めましたが, 冷静に考えてみると結構難しい本だよなあ, って思っています.
*17:自分の事業部という意味です, 採用頑張ってます.
*18:余談ですがこの辺は前々職までのベンチャーで学んだことです. チームの士気を上げつつケアする, しっかりストーリーテーリングしてノセる事は大事.
