SRE実践への道：トップダウンの場合
組織においてSREが設立していく、典型的な流れを紹介します。
従前からシステム運用を事業としてきた、SIer（システムインテグレータ）やMSP（マネージドサービスプロバイダ）でよく見かけるパターンです。
典型的な組織構造は、Devsとは別にOpsがあり、Opsの中にはSysadminアプローチの非定型作業を行うOpsEngチームと、定形作業と24時間365日対応を行うOpsOpsチームがあります。Ops全体やOpsOpsをアウトソーシングに頼っている場合も多くあります。
トップダウンでSREの導入を図る場合はOpsEngやOpsOpsのチームリーダーよりも上の職層（図ではManager、またはそれ以上の職層）が起点になっていることが多いので、このエントリではManager以上がSRE導入の起点となっている前提で書きます。
OpsEngやOpsOpsのチームリーダーはたいてい日々の業務で忙殺されていて実務的な稼働を取ることが出来ません。これはチームリーダーの能力や適正・志の如何に関わらず陥る状況で、中間管理職の辛いところです。
多くの場合Opsのチームリーダーやメンバーの中に現状に課題感を持ち変化の必要性を認識している方が一定数いるので、その方々をとっかかりにしていきます。
SRE本にあるSREの原義に則りソフトウェアエンジニアリングに転換することを前提にすると、業務上必要な水準でソフトウェアエンジニアリングできるようにならなかったメンバーは、できる仕事がなくなります。
いまいるメンバーで・できる範囲の仕事をするという戦術は短期的には実現可能ですが、他社との競争がある状況下では継続性に難があります。
このエントリでは人員の入れ替えを極力行わない前提でコトを進める前提を置きます。前提の背景は、まずSREは（同ジャンルの他職種と比較して）新しいジャンル・考え方の職種であり現時点でSREsの採用難易度が非常に高いこと、法律面・心情面・その他諸般の事情により現実的に配置転換や解雇で人員を入れ替える難易度が非常に高いことがあります。
そこでこのエントリでは”誰もがソフトウェアエンジニアになる適性を持っているわけではない”という点に多少目をつぶり、人員の入れ替えを極力行わない前提でコトを進める前提を置きます。
ファーストチョイスをSysadminアプローチからソフトウェアエンジニアリングに変えるには、自身の立ち位置を “テクノロジの消費者” から、”生産者” に変更する必要があり、このマインドセット&スキルセット&行動様式の変更はメンバーにとって時に大きなハードルになります。
目次
1.まずひとり兼務で始める〜専任になる
まずはトップダウンで、ひとり任命（するよう上位職層からチームリーダーに指示）されます。
（これはSREに限らずプロジェクトワーク全般に言えることですが）ここで現業に精通した遂行能力が高いメンバーを選出し十分な稼働を割り当てられるかが最初の分水嶺です。
最初から専任を出せればそのほうがよいですが、多くの場合はもろもろの調整の結果として兼務ひとりから始まります。
とはいえ兼務だと時間が割けず停滞するのが世の常。ほとんどの場合はさしたる進捗が出ません。多くの場合は、3ヶ月程度やってみてから、専任にするよう上から指示し専任にする過程を経ます。
よく「時期を見て」「準備をして」から実施したいとなるのですが、実は、、、知ってる人は知っている、そのような時期は来ません。なので共感はするものの判断材料にはしません。
ミドルマネジメントが目を逸らしていることが多いのですが、事実としてメンバーは誰であれ常に離職の可能性があります。バス係数の管理はそれはそれでやるとして、メンバーの選出・任命はやるべきときにやらねばなりません。
とはいえ”現場の納得”を引き出すためにここで6ヶ月程度の期間を設けることはあります。
任命したメンバーは、まず状態を計測（できるように）するところから手を付けるのがよくあるパターンです。計測なくして改善はありません。なにに時間がかかっているのか、なにがpainなのか、painがどう影響しているのか、定量・定性両方でみていきます。
2.ツールを変えちゃう
状態をある程度計測できるようになったら、あるいは計測できるようにするために、多くの場合の次の一手は利用ツールの変更です。
ひとりめの専任SREsと前後して利用するツールを変えてしまうことが多いです。ツールありきではないというのは仰るとおりですが、最終形に至る前にまず “頻繁な変化に慣れる” 段階を挟むと比較的スムーズです。
対象となるツールは、モニタリングツール、課題管理ツール、ドキュメントリポジトリ、コミュニケーションツールなど様々です。Sysadminアプローチに適したツールとSREに適したツールは異なることが多いので、SREに適したツールに変更します。SREで必要なのはMeasurableでProgrammableでSimpleなツールです。
“ツールを変更する” という変化は従来のsysadminアプローチの中でもそれなりに行われてきており、多くの場合はOpsメンバーにとって受け入れる障壁が低いです。慣れていることを逆手にとってツールをまずいれて、慣れてもらいます。
ツールを変更する際には、そのツールのSRE観点での利点を台無しにしないよう、統制を設計し・統制を強制する実装が必要です。押さえるべきポイントはMuasurable・Programmable・Simpleです。
ツール入れ替えの際に、既存の実装要件と業務フローをそのまますべて拾うのではなく、払い落とし・正規化・単純化できるとなおよいです。また既存の要件や業務フローを100%再現するのではなく、適切に変化させます。
勘違いしがちなのですが、既存の要件や業務フローを適切に変化させていくのはツールに関わらずサービサーがやらなければならないことでありSRE導入とは直接関係がありません。顧客やシステム利用者から表出した要望を満たすことが自分たちのバリューだと思って一生懸命やった結果、原欲求に対して過度に複雑なことを実現しているケースが多々あります。
このあたりの改善に取り組むという自己変革は、もともと素養があり取り組んでいた人ならできるので任せて良いです。しかしそうでない場合はさじ加減かわからず意思決定に慣れておらずで、単に権限移譲して任せるだけでは達成難易度は高いままなので、一緒に取り組む必要があります。
このような取り組みを通じて、ユーザ志向と継続的改善を経験し、マインドセットを獲得してもらいます。
3.SREsおよびSRE仲間を増やす
SREを他人事にしないために常に全員を巻き込んでいきます。SREs任命やツール変更と並行して、プログラミングなどのソフトウェアエンジニアリング教育を行います。
もともとの習熟状況によりますが、早い人は3〜6ヶ月くらいで考えて手が動かせるようになります。（特にOpsOpsの中には）情報工学の基礎を修めずに就業している方も多くいるため、Ops全体の8割がソフトウェアエンジニアリングに馴染むには2年程度を見込むことが多いです。2年かけて変わらないようであれば、その後の伸び代の期待値はさほど高くないかもしれません。
SREsやSRE仲間を増やすために、スキルセット・マインドセット・行動様式を変革し、困りごとを解決する方法のファーストチョイスをソフトウェアエンジニアリングにする、というのを地道に続けていきます。
最初はEmbeddedスタイルで専任SREsを3人くらいまで増やして、わかりやすい成果を出す。その後は徐々にEnablingスタイルを取り入れてSRE仲間を増やしていくのが典型的な流れです。
当事者の意識が”SREsが主・Opsが従”とならないよう、SREsが積極的に困りごとを見つけ、メンタリングやペアプロで解決策を一緒に考えたり、解決や導入を支援します。
4.ひっくり返す
メンバーの多くや組織がSREにある程度馴染んできたら、多くの場合は主観的に6〜8割を目安に、SREを業務や組織のデフォルト・ファーストチョイスにします。業務内容や業務のやり方だけでなく、人事制度やその運用もSRE前提のものに変更します。
当然ながら改革に伴う軋轢がありますが、ここはトップマネジメント・ミドルマネジメントの腕の見せ所です。ここに至るまでに数年がかりで準備してきているので、あとはやるだけです。
運用を受託しているとき、Sysadminアプローチそのものが必須事項なのであれば、別の部門をたてるかお付き合いを終了するかなど判断する必要があります。
業務や組織の前提条件が変わるため、変革のときにはミドルマネジメントに大きな負担がかかるので、ミドルマネジメントの自己変革や行動変容は特に手厚く支援します。
これでうまくいきますか？
人間が2人いれば、それはもう組織です。組織があり利害が絡んだ状況で “必ずうまくいく方法” はありませんが、納得感を醸成しながらできるだけ穏便に変革を進める方法はあります。
今回は穏便なパターンを紹介しました。このエントリに書いたタイムスパンは長めで、その代わり軋轢は少なめになるパターンです。
穏便な方法のデメリットは時間がかかることです。これは市場においてライバルに台頭する隙を与え自らを貶める行為でもあります。つまり市場で負け始めた状況・趨勢が明確になってから始めると、穏便に進める時間がとれなくなります。変化が必要なのが確定的になってから動き始めた場合は混乱と苦難を乗り越えるのを覚悟しなければなりません。
タイムスパンを短くすることを志向する場合はこの1/4くらいまで短縮できると思います。とはいえタイムスパンを1/4にするのはかなり急激な・過激な変化なので、おそらく現場は大炎上・大混乱します。現実的には、短くしてもタイムスパン1/2くらいがギリギリだと思います。
コトをすすめる上ではチームリーダーより上のレベルの強力なリーダーシップと支援が必要不可欠です。社内的には特に、実際の人事制度運用（評価・報酬決定）における支援が重要です。事業全体を見据えて、という形にはなるものの、持続的経営の観点でおつきあいできるお客様の属性や領域・付き合い方が変化する可能性はおおいにあり、それらを都度決断する必要もあります。
宣伝：X-Tech5ではこのパターン向けに各種サービスをご提供しています
- コンサルティング：コンサルタントとして採用活動・組織整備（制度・実現）を支援する。採用活動支援（マーケティング、Job Description整理など）、組織整備支援（人事制度）、チームビルディング、メンタリング、1on1などを行う
- アドバイザリ：アドバイザー・コンサルタントとして少し引いた立場でチームに参画する。SRE・技術的課題の支援・SRE実現のための施策・組織づくり・人材育成などをテーマに、エンジニアリング・ファシリテーション・ディレクション・メンタリング・1 on 1などを行う
- SREaaS（SRE as a Service）：SREとしてチームに参加する。チームメンバーのSREsとして一緒に動く
- 自動化基盤導入：アラート一次対応などの定形作業を実行する基盤を構築・導入する。シナリオ（実行プログラム）作成も対応可能
