😋

SRE支援の効果的なアプローチについて(SRE NEXT 2024登壇のRecap)

2024/08/08に公開

Google Cloud

sier

SRE

tech

この記事は、SRE NEXT 2024で、株式会社スリーシェイクのスポンサーセッションとして登壇した「内製化を見据えた効果的なSRE支援のアプローチ」をセルフでRecapしたものになります。

はじめに

株式会社スリーシェイクのSreake事業部に所属しています。2024年8月3日、4日に開催された SRE NEXT 2024 に「内製化を見据えた効果的なSRE支援のアプローチ」という題で登壇しました。
20分の枠なのに60枚弱のスライドを作成するという暴挙に出てしまい、端折りながらの説明となってしまったため、Recapとして登壇内容を解説します。

想定読者

本登壇資料は、SRE支援の観点において「どのように知識をクライアントに移転し、クライアントの自走と実行力の強化を促すか」をテーマにしています。
なので、以下の業務内容が含まれるコンサルタント・エンジニアを読者として想定しています。

SRE支援としてクライアントシステムに入り込む
運用ベンダーやクライアントなどに業務を引き継ぐことがゴールである
Embedded　SREsとして他チームにSREを伝導/普及する

SRE支援のロードマップ

早速ですが、私が考えるSRE支援のロードマップです。

#	ステップ	概要
1	SREの導入	SRE支援の始めの一歩として、SREチームの組成や方向性をすり合わせ、 SREを小さく始めるステップ
2	SREの実演	クライアントに引き継ぐことを意識しながら、SREとしての活動を推進するステップ
3	SREの知識移転	SREとして行った内容や知識をクライアントに移転し、SREのハードスキルやソフトスキルを理解してもらうステップ
4	SREの実践	移転した知識をもとにクライアントにSREを実践してもらうステップ
5	SREの発展	クライアントと共にSREとしてシステムを改善していく中で、新たな課題を発見し、整理して対処するステップ
6	SREの伝導	SREとしての心構えを継続的に伝えるステップ
7	SREの内製	内製化に成功し、案件をクロージングするステップ

このロードマップとして３つ特徴的なものがあります。
まず１つ目は、SREの実演→SREの知識移転→SREの実践→SREの発展というフローです。なぜこのようになっているかというと、まずは自分がやってみないとクライアントの知識として根付かないからです。

山本五十六の有名な言葉に、

やってみせ　言って聞かせて　させてみせ　ほめてやらねば　人は動かじ^[1]

がありますが、これと同じで、言うだけ言って自分が体現していなければそれは現実味を帯びず、机上の空論に成り下がってしまいます。したがって、SREとして行動で示し、理解してもらい、実践を通じてSREを体得し、新たな課題へと対処していくという流れがクライアントのSRE体得にはベストなアプローチであると考えます。

二つ目は、上記が循環フローになっていることです。
SREの知識を移転していくためには、理想はウォーターフォールのような線形ではなく、アジャイルのようなサイクルによって移転が促進させることが有効であると考えます。何かしらの引き継ぎを受けた経験がある方は、
（引き継ぎ期間がｘｘ日しかないのか・・・）
（ｘｘさんが半年くらい薄く案件に関わってくれたらなあ・・・）
と感じたことがあるのではないでしょうか。そもそも知識を定着させるためには反復学習が必要^[2]であり、短期間で詰め込んでもすぐに忘れてしまいます。なので、時間をかけて少しずつ反復しながら知識を移転していくことが理想となります。（とはいえ、案件契約の都合上ウォーターフォール型の引き継ぎになってしまうのも致し方ないところではあります。）

三つ目は、SREの伝導ステップが独立して存在していることです。
SREというのは実践が難しく、方向性を見誤ると従来のインフラ保守運用者やインシデント一次受け担当のような役割に陥ってしまうことがあります。SREの本質を伝えるためには、SRE支援が開始した際に一度説明すればいいというものではなく、継続的に意義や価値を伝えていく必要があります。また、SREというロールもPlatform Engineeringやエコシステム整備^[3]など、多岐に渡るようになってきました。SREというロール自体が変化していくため、それに合わせて新しいマインドセットを共有する必要があります。

SRE支援のロードマップを踏まえたSRE支援のアプローチ

ここからは、SRE支援のロードマップのステップについて、どのようなアプローチを取れば良いかについて解説します。

SRE支援として主導する際のアプローチ

主導するステップとしてSREの導入(+SREの実演)でのアプローチについてです。

アプローチについては、以下となります。

補足したい箇所として２点あり、1つ目は 「自分たちの信頼性の確保」 についてです。
外部の人間がクライアントの組織やチームに入り込んで作業を行う行為は、成果を出して信頼性を上げないと最悪の場合は契約打ち切りになる可能性があります。まずは自分的の存在をアピールし、期待値をコントロールしながら常にクライアントからの期待値を超えるように調整する必要があるのです。

2つ目は 「SRE支援の在り方」 として、なるべく色々なところに首を突っ込むということです。
一般的にはSREとして幅広く手掛けてしまうと何でも屋となり、本来のSREとしてのロールから逸脱してしまうため、アンチパターンのように思えます。そこのバランスは難しいのですが、ことSRE支援においては、自らタスクの線引きはせずに、なるべく広い範囲に支援する気概でいた方がクライアントからの印象がよかったりします。また、他チームや他組織の案件契約にも繋がる可能性があるため、アンテナは張っておいた方が良いと考えます。

知識を移転しつつ、よりSREを発展させていく際のアプローチ

知識を移転する、というテーマについて、知識創造企業(新装版)^[4]という書籍を参考に二つの知識について先に示します。

要は、形式知はドキュメントに起こせるもの、暗黙知は職人芸的・感覚的なものです。
自分達の暗黙知を形式知に落とし込み、それをどのようにクライアントの暗黙知へと変換させるかが知識移転の鍵となります。

そのような暗黙知から形式知への変換、さらには形式知から暗黙知への変換という知識創造のサイクルとして、
SECIモデル^[5]というプロセスが定義されています。

SECIモデルは4つのステップの英語の頭文字をとっています。

共同化
- 経験を共有することによって、技術やメンタルモデルなどの暗黙知を移転するステップのこと。
- 直接的な経験の共有の他にも、観察や模倣なども含まれる。
表出化
- 個人の暗黙知をドキュメントなどの形式的なものに変換するステップのこと。
- 主観的・直感的な共同化と違い、客観的・論理的に伝えることが可能である。
連結化
- 表出化で生み出した形式知同士を組み合わせ、新たな形式知を創造するステップのこと。
内面化
- 連結化で培われた形式知を自身の暗黙知へと変換させるステップのこと。
- 実践経験を通じて暗黙知を体得する。

SECIモデルは、（無理やりですが）SRE支援のロードマップとマッピングすることが可能です。

つまり、知識を移転するという点において、SRE支援のロードマップの各ステップはSECIモデルに対応しており、SECIモデルの各ステップのアプローチがそのままSRE支援のアプローチとして有効であるということです。

SECIモデルの各ステップで、どのようなSRE支援のアプローチを行えば良いかについて示します。

一つ面白い点として、共同化の箇所で雑談・ランチ会・飲み会など業務と関係ない場についても知識移転に有効だということです。これは、暗黙知がノウハウのような技術的側面と、メンタルモデルのような認知的側面の両方を含んでいるからです。非業務の場、特に飲み会は、個々人のパーソナリティが顕著に現れます。物事の考え方、性格、プライベートの過ごし方、家族への対応など、そのような情報や知識は自分の仕事への価値観をアップデートできる可能性があります。

内面化でクライアントのタスク実践を支援する

SECIモデルの内面化を深掘り、どのようにクライアントにタスクを実施して貰えば良いでしょうか。
ちょうどSRE-NEXT 2023のSREの組織類型におけるリーダーシップの考察^[6]という登壇の中でSL理論^[7]が紹介されており、それをベースに話を展開していきます。

SL理論とは、元々は部下に対してどのようにリーダーシップを発揮してタスクを推進してもらうかを定義したフレームワークです。
縦軸を援助的行動、横軸を指示的行動とし、行動の多い少ないで4象限でリーダーシップの型を定義したものになります。

上記を踏まえ、クライアントのタスク実行への支援を軸にSL理論を再定義します。

まずは、教示型として具体的に手順や方法を示し、クライアントのタスクを管理して実行を支援します。
慣れてきたらコーチ型に移行し、インタラクティブでフランクなコミュニケーションでタスクの解像度を高めます。タスクの中身をかっちりと決めずに、クライアントと一緒にゴール設定からタスク推進までを行います。
さらに慣れてきたら、援助型に移行しクライアント主導でタスクを推進してもらいます。ここでのポイントは、クライアントの自信がつくようにサポートすることで、タスクを主導することに対する抵抗感を減らしきます。
最後に、委任型に移行し、基本はノータッチでクライアントにタスクを推進してもらいます。ただ、何をやろうとしているのかは観察し、何か気になることがあれば連絡します。

クライアントの技術習熟度やタスクの難易度によって柔軟に型を切り替え、クライアントにとって最適な支援を行うことが大切です。

SREとしての心構えを継続して伝える際のアプローチ

SREとして大事な心構えを以下のように示します。

赤字は私が重要だと考える部分であり、それぞれ補足します。

「エンドユーザ目線の信頼性を改善の軸にする」 は、会社仲間の資料^[8]から参考にしています。信頼性を定義する際、エンジニア目線で考えてしまうとどうしてもミクロな目線になりがちです。実際にサービスを利用しているユーザ目線に立って、システムがどういう状態になったら使いづらいかを常に思考することが、ユーザが求める価値に対しての真の信頼性を定義へと繋がります。

「ステークホルダーと協力 / 尊重しながら円滑にコミュニケーションする」 は、SREは常に一人ではなく、多数を巻き込みながらマクロな目線でシステム改善を行う必要があることに起因します。開発チームやビジネスチームとコミュニケーションする中で、人によって共通言語を柔軟に変えながら共通認識を持つことが大事です。技術だけではなく、ソフトスキルも問われるところがSREの難しさです。

「カオスや変化を楽しみ、ワクワクする心を持つ」 は、SREというロールが曖昧であり、また扱っているクラウドインフラや周辺技術も変化していくことに起因します。SREとは、教科書的にはSLO/SLIの定義やCI/CDの整備、インフラ環境の構築などありますが、抽象的に捉えるとエンドユーザ目線の信頼性向上にまつわる全てがタスクとなります。自分の力量次第でいくらでも守備範囲が広くなりますが、しかしそれでこそ見えてくる課題もあります。そこには自分しか認知していないカオスがあり、その状況をどう改善するかをいかに楽しむかがモチベーションに直結します。
技術的な面においても、クラウドインフラでいうとサービスの追加と終了の頻度が凄まじいです。最近だとAWSのCodeCommit^[9]などが新規アカウントでの利用を制限する動きがあったりとイベントが盛りだくさんです。そういった情報に一喜一憂せず、変化を楽しながら信頼性の向上を目指すことが重要です。

内製化が完了し、案件としてクロージングに向かっていく際のアプローチ

いよいよ大詰めです。

SRE支援が完了し、クライアントの自走ができる状態になれば、SREを他組織/チームに波及させていきます。隣の芝は青いと言いますが、SREが上手く機能しているチームが眩しく見えているはずです。有難いことに、他社さんへ紹介してくれるクライアントもいます。SREを一定体現出来ているため、新規の案件よりも解像度が高く話が進むことがあります。
ただ、大事なのはSREの成功パターンをそのまま他組織/チームに持ち込んでも上手くいかない可能性があるということです。失敗パターンはありますが、成功パターンはありません。その組織に合ったSREを正しく定義出来るかが、継続的なSRE支援の成功へと繋がります。

SRE支援とオブザーバビリティ

SRE支援において、オブザーバビリティを導入することは欠かせません。
ここでは、オブザーバビリティがどのような理由で必要かを記載します。

オブザーバビリティと知識移転

会社仲間のブログによると、

オブザーバビリティとは、システムの内部動作と状態を外部から観測し、理解できることを指します。 ^[10]

と定義されています。
では、オブザーバビリティが導入されていない、すなわちシステムの内部動作が把握できない状態の場合、障害に対してどのように対処すれば良いでしょうか。

システムがブラックボックス化しており、シニアエンジニアの長年の経験を勘のみを頼りに真因まで辿り着くしか手段がないことも往々としてあると思います。オブザーバビリティを導入すると。システムの内部動作が観測され明らかになり、システムの形式的な情報を誰でも取得することが可能になります。

これはすなわち、先ほどの形式知と暗黙知の話に繋がり、オブザーバビリティはシステムにおける暗黙知であった熟練の経験と勘を、テレメトリという形で形式的なものに落とし込むことになります。知識移転という観点では、オブザーバビリティは暗黙知から形式知への橋渡しになるのです。

ここで、先ほどのSECIモデルにオブザーバビリティを無理やり当てはめてみます。

若干無理がありますが、この図で伝えたいのは、有用になりそうなテレメトリを洗い出し、それをオブザーバビリティを導入することによってシステムの内部動作を明らかにし、テレメトリを組み合わせてダッシュボードにし、アラート設定とRunbook作成を行い、障害が発生した時にクライアントに効率よく対処してもらい、そしてそのサイクルを何度も繰り返すことにより、システムの内部動作が鮮明に表現され誰でも理解が出来るようになり、知識の創造と移転が起こりやすくなるということです。

オブザーバビリティとエンジニア的知的好奇心

オブザーバビリティは福利厚生と言っても過言ではなく、エンジニアのQOLを向上させるツールでもあります。
エンジニア的な知的好奇心を満たすものであり、SREとして働き続けるためのモチベーションを向上させるのです。

オブザーバビリティとSRE支援

前置きが長くなりましたが。もう一度SRE支援のロードマップを見てみます。

知識を移転するステップや、SREの心構えを伝えるステップにおいて、オブザーバビリティを導入することでより適切にアプローチが出来るようになります。もちろん、オブザーバビリティ導入それ自体を目的としてしまうと、本末転倒になってしまうので、繰り返しクライアントに重要性を訴求していく必要があります。

まとめ

SRE支援のロードマップを紹介すると共に各ステップにおいてどのようにアプローチすれば良いかについて解説しました。その中で特に、知識移転についてはSECIモデルに基づいて暗黙知から形式知へと落とし込み、それをクライアントの暗黙知へと変換するステップを繰り返すのが効果的だと説明しました。また、SRE支援をより効率よく行うためにもオブザーバビリティの導入が有効であると説明しました。

SRE支援というテーマではありますが、知識移転については多くの伴走型支援型案件に関わる方とっては関連するところがあるのではないでしょうか。

資料作成に約一ヶ月かかり、準備がかなり大変でしたが、少しではありますがブースに来て頂いた方がいたりX（旧Twitter）でも反響があったため、登壇者として冥利に尽きる思いです。これからも、一エンジニアとして精進するとともに、自分の知見が役立つようにアウトプットを続けていきたいと思います。

おまけパート(Google Cloudのオブザーバビリティツール)

Google Cloud Partner Top Engineer 2025を狙っており、どうしてもGoogle Cloudを絡めたく無理やり資料を作成したのですが、枠に収まりきらずAppendixとして用意している資料をこちらでも転記します🙏
オブザーバビリティがSRE支援に有効だという話から無理やり繋げ、Google Cloudのオブザーバビリティサービスを何個か紹介します！