SRE組織作ればSREになる!?
そんなわけあるかぁあああ!!
と言いたい。
あと、SRE = インフラ じゃない。
インフラエンジニア採用したいからってSREエンジニアで募集するのはやめてほしい。
SREチームを作れば 開発パフォーマンスが最大に なるわけない。
卵が先か鶏が先かって話じゃない。
DXだ!クラウドだ!アジャイルだ!SREだ!
流行りを取り入れる前に自分たちの現在地を確認してほしい。
まずプロダクトに関わる人の構成は?
インセプションデッキした?ペルソナは?
ユーザージャーニーマップはある?
プロダクトマネージャーは?プロダクトオーナーは?
アジャイル?ウォーターフォール?
オンプレミス?クラウド?
VM?コンテナ?
内製?外注?内製+業務委託?
テストは?デプロイは?
リリースとデプロイは同期している?
例えば、オーナーは企画部門、オンプレミスでDeveloperチームと
インフラチームがいるという状態でSREチームを作ったら、おそらくチーム間の板挟みにあって崩壊するんじゃなかろうか。
あと外注しているのに自組織にSREチームなんて作ってたらもっと訳わからん。
内製してるけど、ほとんど業務委託主体なんてチームにSRE入れても訳わからん。
内製主体で、クラウド使ってDeveloperチームが頑張ってるよ なところには
SREチームを入れてほしい。
それでも厄介なことがある。
それはプロダクトオーナーやプロダクトマネージャーが、開発組織外の人であった場合のその人達のマインド。
オーナーシップを振るう人たちが、SLI/SLO/SLAと決めていくときに
マインドがビッグバンリリースタイプ+SLA100%な旧来型志向だと
コミュニケーションが格段に難しくなる。
根気強く雪解けを待つか、はたまた神の鉄槌か。。
ひとまずSREチームをつくる前に
自分たちの組織の現在地とどういう体制・構成でプロダクト運営をしているのか。
関係者全員のマインドをみて、SREの必要性を説明して理解をもらってから
考えたほうがいい。