組織においてSREが設立していく、典型的な流れを紹介します。

 

スタートアップなどでよくあるパターンです。

開発組織において気になるポイントや役回りが分化し、個々の役割分担が進んだ結果として発生してきます。

 

CTOが1人目の兼務SREsになるパターン（この規模・フェーズの組織では「機能開発以外の技術的課題すべて」を担うことが多いので）や、支援・整備に喜びを感じるメンバーが責任を負っていくパターン、外部から採用できたSREsが頑張っていくパターンをよく見かけます。

1.兼務で始める〜専任になり仲間が増える

小さな組織、開発チームでサービスを継続開発・運営していると、この時期の開発チームに必要なことの多くが “SREを通じて達成したいこと” と共通する点が多く、明確にSRE（あるいはSREs）と呼ばずとも、SREで推奨される取り組みの多くに取り組むようになってくることがあります。

 

• 少人数でサービスを継続開発・運営すること
• 開発チームの心配事と手間を減らし・品質と開発速度（特にアジリティ）を高めること
• サービスの創出価値を計測・可視化しデータをもとに判断すること

 

例えば上記の状態を目指し・実現するうえで、CI/CD機構とモニタリングはあるとないとで大違いです。

 

この状態だと基本的に人事制度（評価・報酬）はSREsとして独立したものはなく、開発チームに準じたものになっていることがほとんどです。

 

この時期の代表的な悩みには

 

• 手数不足（やりたいことが膨大だが手が足りない、手を増やそうにも採用候補者が少なく採用難易度がものすごく高い、Devsからのコンバート希望者が少ない）
• ひとが増えることに対する整備不足（実施回数が少ない・実施機会が少ないことからくる難しさ。オンボーディング、チームビルディング、ドキュメント整備など）
• 異なる職種に同じ評価報酬制度を適用する最適化不足による実体とのギャップ
• 上司や周囲とやっていることが違うことからくるギャップ感や、集団におけるマイノリティという立ち位置からくる孤立感
• 実施施策がしなければならないことよりも現行メンバーのスキルセットで進捗が出せるものに偏りやすい

 

などがあります。

2.チームとして独立する〜チームメンバが増える

組織の中でSRE／SREsの存在が確立されてくると、チームとして独立させ、人事制度（評価・報酬）を最適化しよう、適切にラインマネジメントできるようにしよう、という展開になります。

これは最適化と採用促進の2つの側面があります。

 

チーム化して存在と立ち位置を確立させ、適切な人事制度をあてこむことで、孤独感や最適化不足の解消を狙います。

 

手数不足やメンバーのスキルセットによっては、機能開発ではなくモニタリングやCI/CDなどエコシステムを主眼にするケースも多くあります。

メンバーのスキルセットを鑑みて、エコシステムと実行基盤を”インフラ”という名のもとに切り出すケースがあります。

この時期の代表的な悩みは

 

• 適切な人事制度がわからない（新職種としてどの程度最適化すべきかわからない）
• 部門化に伴い方針策定やKPIなどを負うことになり管理業務が増える
• 部門化に伴いDevsと距離感が生まれてしまう（サイロ化）
• 採用活動激化（逆説的だが “部門であるからには相応の人数がいて然るべき” となる）
• （ひとが増えることに対する整備はだいたいこの頃まで後回しにされがちだが）いよいよひとが増えることに対する整備に向き合う必要が出てくる
• 前段階で抱えていた手数不足などの悩みが解決しないで積み重なる

 

といったものです。

 

このあたりはSRE／SREs特有の事情はなく（現時点では強いて言うなら採用難易度が高い点）、組織構築につきものの悩みがほとんどです。

3.チームが増える

 

採用あるいは職種転換が順調にいくと（あるいはなんとかかんとか達成して）、チームを細分化することになります。

 

取り扱う対象ごとに実行基盤チーム、データ分析基盤チーム、DBA/DBRE（DBA：DataBase Administrator、DBRE：DataBase Reliability Engineering）チームなどを立ち上げていきます。

それぞれのSREsを横断的に支援するSREsという役回りも登場したりします。この図ではDevsに対してコンサルティングしていますが、SREsに対してSREsがコンサルティングするシーンが発生してきます。

この時期の代表的な悩みには

 

• 他部門との距離感がさらに大きくなってしまう（サイロ化が進む）
• 人数が増えてHRMや部門運営が大変になってくる
• チームを統括するチームや組織・職能が求められ、管理のための管理をする人が必要になってくる
• 全体最適化と個別最適化のさじ加減をどうするか

 

などがあります。

 

最後の全体最適化／個別最適化の線引き問題はSREが普及した後に特有の課題です。

 

現代のWebサービスは機能が多く複雑です。継続的に開発・改善し競合に勝ち続ける必要があります。チームを小さくしてコミュニケーションコストを減らす（スモールチーム）、システムを小さく分割しコードの影響範囲を区切りエンジニアの認知負荷を減らす（マイクロサービス）などの取り組みを通して、チームの裁量を大きくし、自由度を高め、システム開発のアジリティと品質を高くする取り組みが多く行われています。チームごとの自由度や裁量はチームごとの個別最適化に繋がります。

 

一方で組織全体に目を向けると、個別最適化によって全体の効率が落ちる場合があります。採用技術がチームごとにあまりに異なるために異動や交流が難しい、ノウハウ流用が難しい、統合管理したい観点の適用の手間がかかる（データ収集分析、セキュリティ基準適用など）、採用・育成の難易度が上がるなどの課題が持ち上がります。この状況で全体最適／個別最適について線を引く（あるいは線を引かないことを決める）のはCTOやVPoEなどボードメンバーの仕事です。

4.普及・浸透させる

これはチームが増えるのと並行して取り組むケースが多いのですが、関係者全員がSREを遂行する体制が一番強いわけで、サービスとしてユーザ価値を高める活動をしていくと最終的に”全員できるようになっていこう”ということになります。

 

となると各開発チームにおいて各開発者自身が教養としてSREに取り組む必要があります。

 

ここを支援・実現するために各開発チームにSREが潜り込み、日々の活動の中でトレーニングや普及活動を行います。

このような役割をエバンジェリスト、アドボケイト、Enabling SREなどと呼びます。

1周回って最初の体制図に戻ってくるのは面白いですね。

SREの究極の形はSREsがいなくなること？

“最終的にはSREsが不要になりSREが浸透するのが望ましい” と言われることがあります。

 

それは美しい姿ではありますが、わたしたちは往々にして “専念しないと・専任にならないと物事が進まない” ということを知っています。要するに兼務の推進力は多くの場合あまりアテにならないことです。

 

というわけで、SREが全員に普及した暁には専任SREsの数は減るでしょうが、一方でSREにまつわるシステム横断的なタスクはなくならないと思われるので、専任SREsは一定数必要なままであろうと考えます。

 

今回は状態を4つにわけて解説しましたが、フェーズの移り変わりの基準は非常に曖昧です。また多くの一般社員は実感が薄いのですが、組織や制度はできるものではなくつくるものなので、経営層の意思や判断のもとで構築されます。組織や制度のエンジニアリングはなんとも複雑で、アンチパターンはあるが正解はない、長期視点のアンチパターンが短期視点では最大の効果を発揮する場合がある、ある人のベストプラクティスが別の人の地雷の場合がある、という、とても不透明でややこしいものです。とはいえ成し遂げたいことのためにはやるしかないので、なんとかかんとかやっていくことになります。X-Tech5ではこのあたりの曖昧な状況での伴走を多く手掛けています。

 

なおSREsの体制について考えるとき、現実的な問題として外せないのが “オンコール対応を誰がどうするか” という点です。このオンコール対応についてはまたの機会に。

 

宣伝：X-Tech5ではこのパターン向けに各種サービスをご提供しています

• コンサルティング：コンサルタントとして採用活動・組織整備（制度・実現）を支援する。採用活動支援（マーケティング、Job Description整理など）、組織整備支援（人事制度）、チームビルディング、メンタリング、1on1などを行う
• アドバイザリ：アドバイザー・コンサルタントとして少し引いた立場でチームに参画する。SRE・技術的課題の支援・SRE実現のための施策・組織づくり・人材育成などをテーマに、エンジニアリング・ファシリテーション・ディレクション・メンタリング・1 on 1などを行う
• SREaaS（SRE as a Service）：SREとしてチームに参加する。チームメンバーのSREsとして一緒に動く

参考

• 7種類のSRE実践パターン
• SRE実践への道：トップダウンの場合