ここ一年弱、いくつかビジネス的な優先度の高い新規プロダクト立ち上げのヘルプにSREとして駆け回ったり、
組織も大きく変わり、事業部のSREチームからプラットフォーム側のSREチームとなった（チームごと組織再編）。
一つはLYPプレミアムというユーザーにも見えるプロダクトでした。他にも色々。
新規立ち上げのチーム編成については、チーム単位で色々な組織から集められた。そのため、これまでのチームのやり方の共有から始めたり、タイトなスケジュールの中で、どこまで「当たり前に」やるかという会話から始まった。
SREsは信頼性に対して責任を持つことが期待されている以上、スケジュール、アーキテクチャ、ローンチ、ローンチ後の振り返りまで、とにかく口を挟んだ。
SREという言葉を使わず説明するなら、クラウドインフラエンジニア&テックリードみたいな立ち回りだったと思う。
タイトなスケジュールの事業立ち上げについては、基本的に前例踏襲しつつ、ミドルウェアやOSのバージョンなどをすべて最新化する方向で妥協した。
少しゆとりのあるスケジュールの事業立ち上げでは、新しめの技術スタックに挑戦しながら、毎週20分のハンズオン勉強会をSWEsに対して開催した（してる）。
既に数ヶ月間、毎週20分のハンズオン勉強会を続けているけど、これは全Embedded SREsにオススメしたい。
20分のハンズオンであれば、準備は2,3時間で出来ることが多いし、仮についてこれない方がいても、来週のハンズオンまでにフォローアップすることができる。
SWEs視点でも、一回20分のハンズオンならば、多少忙しくても参加に積極的になれるだろう。
また、変化としては事業部のSREからプラットフォーム部のSREに変わったことも大きい。
採用は引き続き頑張ってはいるんだけど、プラットフォーム部になったことで、より多くのサービスにインパクトを与えることを求められ始めた。
ちなみに事業部の頃はただのSREチームだったが、プラットフォーム部に異動するにあたって、Embedded SREと名前も改名した。なんらかのツールをプラットフォームとして運用し始めると、簡単にメンテナンスに手を取られて速攻で詰むことが目に見えてるため、「Platform提供はやらんぞ。EmbeddedしながらEnablingだけを専門にやるぞ」という強い強い意志のためだ。
幸いにもプラットフォーム部の偉い人は、まさにそのEnablingに課題感を持ってくれていたので、プラットフォームが一つ増えるのではなく、Enablingのチームが産まれることを歓迎して二つ返事で了承してもらえた。
やることは変わらず、下記の通り。
フットワーク軽く維持するために、プラットフォームは持たない
ファーストペンギンとして、Embeddedされたチームで手を動かして直接改善する
実際に手を動かした経験を元にハンズオンを開催して、ただの導入で終わらずに、ちゃんとEnablingする
また、私たちのチームのOKRで各KeyResultの評価も三段階にした。
自身のハードスキルだけで達成できるレベル
ハードスキルだけでなく、チーム内でのソフトスキルも必要なレベル
チーム内に留まらず、チーム外（or社外）に影響を与えるレベル
こんな感じで色々忙しかったんです。
今後も「SREsを増やすのではなく、SREのcapabilityを持つ人を増やす」ということを重視していく所存。