SRE組織作ればSREになる！？

そんなわけあるかぁあああ！！
と言いたい。
あと、SRE = インフラ じゃない。
インフラエンジニア採用したいからってSREエンジニアで募集するのはやめてほしい。
SREチームを作れば　開発パフォーマンスが最大に　なるわけない。
卵が先か鶏が先かって話じゃない。

DXだ！クラウドだ！アジャイルだ！SREだ！
流行りを取り入れる前に自分たちの現在地を確認してほしい。

まずプロダクトに関わる人の構成は？
インセプションデッキした？ペルソナは？
ユーザージャーニーマップはある？
プロダクトマネージャーは？プロダクトオーナーは？
アジャイル？ウォーターフォール？
オンプレミス？クラウド？
VM？コンテナ？
内製？外注？内製+業務委託？
テストは？デプロイは？
リリースとデプロイは同期している？

例えば、オーナーは企画部門、オンプレミスでDeveloperチームと
インフラチームがいるという状態でSREチームを作ったら、おそらくチーム間の板挟みにあって崩壊するんじゃなかろうか。

あと外注しているのに自組織にSREチームなんて作ってたらもっと訳わからん。
内製してるけど、ほとんど業務委託主体なんてチームにSRE入れても訳わからん。

内製主体で、クラウド使ってDeveloperチームが頑張ってるよ　なところには
SREチームを入れてほしい。

それでも厄介なことがある。
それはプロダクトオーナーやプロダクトマネージャーが、開発組織外の人であった場合のその人達のマインド。
オーナーシップを振るう人たちが、SLI/SLO/SLAと決めていくときに
マインドがビッグバンリリースタイプ+SLA100%な旧来型志向だと
コミュニケーションが格段に難しくなる。
根気強く雪解けを待つか、はたまた神の鉄槌か。。

ひとまずSREチームをつくる前に
自分たちの組織の現在地とどういう体制・構成でプロダクト運営をしているのか。
関係者全員のマインドをみて、SREの必要性を説明して理解をもらってから
考えたほうがいい。