🌉

SREのすすめ：アプリケーションエンジニアとプロダクションエンジニアの架け橋になろう

2022/03/31に公開

SRE

キャリアパス

エンジニア組織論

idea

前回の記事はこちら

上の記事で、ご指摘をいただきました。曰く、「問題意識は伝わったが、なぜSRE (Site Reliability Engineer）になったのかという繋がりが理解しにくかった」

読み返してみて、その通りだと思いました 🤦
なので、今日はちょっとそこを深堀りしてみたいと思います。

組織が成長するにつれて、「API設計者」と「API利用者」でデベロッパーのピラミッド構造ができるという話をしました。

つくる人と使う人

今日はもう少し視野を広げてみます。

次はどこへ行こう
今自分が見ている地形図

なぜ、直接コア要素の設計側に行けないのか

がむしゃらに設計者にまわろうと思ってもパイは少ないです。現在勤めている会社にも Ruby/Railsのコミッターチームや、MySQLの独自実装を行うチームがあります。少数精鋭のチームで、それぞれ何かしら業績があった上で、チームに加わっているイメージです。

API利用者として新機能をガンガン開発していても、そこに結びつくような成果はなかなか生まれません。

機能開発をすることで成長できる分野

それでは逆に、機能開発に従事することで一番身につくのはなんでしょうか。私はプロダクトマネジメントのスキルだと考えています（プロジェクトマネジメント、プロダクトオーナーなど広い意味で使っています）。

「決められた期間で、現在のチーム編成で」できることを突き詰める「プロダクトスコーピング」が上手くなります。

Product scoping
分野横断の人員・期限で何がどこまでつくれるのか

これはこれでめちゃくちゃインパクトが大きいです。一番長期的に安定してキャリアを築けるのは、実はこの分野だと思っています。ちょっと趣向は違いますが、ピープルマネージャー（人を伸ばすことで自分の価値をレバレッジできる人）になる路線とも相性が良いと思っています。

同僚であるSuzuki Kenta氏が現在のチームで「プロジェクトの立ち上げの百本ノックをやっている気分」というツイートをしていました。厳しい局面を何度もハンドリングすることで培われる力があります。

とはいえ、マネージャーの道はまだ早い

プロダクトマネジメントができるエンジニアになったら良いのではないでしょうか。そうとも言い切れないのは、一度マネジメントのトラックに入ったらそこからは管理職一直線、というイメージがまだ根強いからです。

下記の記事では、「IC（一技術者として貢献するポジション）とマネージャーを行ったり来たりする人」 というキャリアパスが紹介されています。まだこのような考え方は新しいでしょう。

点線の部分がもっと増えてほしい

「マネージャーとは一体入ったら帰ってこれないキャリアパス」という考え方は、そのうち古くなってくると思いますが、それが何年後か分かりません。それまでの身の振り方として今回のSREへの転籍という選択がありました。

第三の道：本番環境だけに特化したチーム、SRE

さて、なぜSREになるやり方が、マネージャーでもなく、コアの設計者でもない第三の道となり得るのでしょうか。

SREとは何をする人たちなのか

さまざまな組織でSREの導入ステージは多様だと思いますが、現在の自分の観測範囲だと、「本番環境でミッションクリティカルなシステムの安定性を高める」 というのがミッションにあります。

面白いことに、これはコア要素を設計する良い準備運動になります。

分散システムを俯瞰して理解すること
ネットワーキングのレイヤーがどのような失敗パターンを生むのか知ること
それぞれの要素で、いかにローカルに失敗を隔離していくか方法を知ること

などなど日々学んでいます。

プログラミング言語やフレームワークの流行り廃りはありますが、大規模なシステムがどのような原理原則で動いているのか、は中々変わりません。

エンジニアとしてのレベルアップに必ず役立つ

ある程度アプリケーションレイヤーで開発がそつなくこなせるようになってきたとします。その時の学習方法の鉄板は、「もう１レイヤー潜り、普遍的なものを身につける」ことだと思います。

SREに鞍替えすることで、この例レイヤーの理解を業務時間のメインタスクとして行うことができるようになりました。 これが、SREが現在の私にとって良いポジションである理由です。

なぜアプリケーション開発上がりのSREが増えた方が良いと思うのか

最後に、なぜこういった選択をする人が会社の中で増えたら良いと思うのか、その理由を書きます。

企業が大きくなることで起きる分離と新陳代謝

会社のビジネスが確立してくると、それに伴いコアとなるドメイン要素も見えてきます。ビジネスの根幹になっているコンセプトが、コードベースの中で徐々に固定化されてくる イメージです。

コアとその周辺サービスが定義されてくる

また、会社の歴史が長くなるにつれ、社員の新陳代謝が生まれます。社員の数が爆発的に増える時期もあるでしょう。

このようにして、専門性が高いコアチームと、流動的なチーム編成に対応できる機能開発のプロジェクトが生まれてきました。

プロジェクトが持つライフサイクルと、本番環境のライフサイクルの違い

新規機能を開発するチームから見据えるライフサイクルと、既存のシステムの質を高めるチームが見定めるライフサイクルは、全く違います。

機能開発チームが持つマインドセットは「早くつくって、早く出す」。既存システムのチームは「壊さず、長期的に守る」。

ここまでを企業の成長に不可欠な深化と考えると、人はどう移ろうのが良いのか

この二つが別々の目標に集中する中で、どうやったら新機能のリリースサイクルを短く保ちつつ、安定性も高い水準で推移できるのでしょうか。

ここで、元SREだったプロダクトエンジニアの人や、元プロダクトエンジニアだったSREの人の価値が出てきます。

お互いの強みを交換する

安定性を高めるための施策（SLO策定、モニタリング・アラートの設計、失敗寺のリスク軽減措置の実装, ...）は、「プロジェクトの開始時」 に準備ができるほど、実装・運用コストが下がります。

最初はいっしょくただった小さなエンジニアチームが、
組織の拡大で機能ごとに分かれ、
それぞれのベストプラクティスを学んだあとに、
もう一度それぞれの役割を超えて人の移動がある

というのが、よい組織の成長モデルだと考えています。Googleが出しているSREの本などで「Embedded SREモデル」などが書いてあるのですが、それに同意します。

移行のタイミングは慎重に！

しかし、それぞれのステップでの文化形成を慎重にやらないと、チームの中でシスアド（システム環境整備などを専任でやる人）が生まれるだけで、SREの希釈が始まってしまいます。それぞれのフェーズ移行のタイミングは慎重に！

まとめ

なぜ、SREは一ソフトウェアエンジニアの次のキャリアとして効果的なのか
なぜ、それは組織全体のためになるのか

の二点について、自分の考えをまとめました。ぜひ皆様のご意見お聞かせください。

例によって、この記事はSuiko、という文章を育てる下書きアプリ上でつくりました。