こんにちは。CTOの馬場（@netmarkjp）です。

2024年3月26日に TECH PLAY にて No SRE，No life｜教科書には載っていない！俺たちが考えたSRE推進の道しるべ｜ #SHIFT TECH TALKS#1 が開催されました。 わたしはトップバッターとして『SREsのためのSRE定着ガイド』をお話しました。

ご質問を多数いただきまして、時間内にはすべては扱えず残念でした。ここでフォローアップします。

なんでも屋になりたくない？

個々の質問の前に、ざっと拝見して登壇者の間で（裏で）少し話題になったのが

「なんでも屋」にならないようにしたい

という一節でした。

というのも、（少なくともわたし自身は）なんでも屋にポジティブなのです。 だって、シンプルに「なんでもできたら最強」ですよね。

加えてわたしが知る業界のロックスターのみなさんは、技術的実装力の一点突破ではなく実際には色々と周辺のことをなんでもやって信頼獲得して成果に至ってるように見えるので、そういう意味でも「具体性の高いジャンルから出ないようにすること」にこだわりがないのです。

サービス・システムが大規模化して専門職に細分化したので、誰かがその間を繋いだり、こぼれたものを拾ったりして全体を円滑に回す必要があるわけで、それを誰がやるかというだけの話だと思っています。SREの視野・視座からするとそこを担っていくのは自然に感じます。

「それはCTOの仕事/領分では？」と言われたことがあります。それはそう。現状に大きな課題がないならそのままお任せすればよいと思います。

SRE implements DevOps を標榜しているのですから、 breaking down the invisible wall （The evolution of DevOps – O’Reilly） にまつわるあれこれはSREが手掛けても何らおかしくないと思う次第です。

とはいえ「それをSREがずっと続けるか」「主体的に拾うか受動的に押し付けられるか」「やって感謝されるかやって当然と見なされるか」は持続性の観点で大きなポイントですよね。

登壇者間でも「なんでも屋かどうかというよりも、このあたりがポイントだよねー」という話をしていました。

このような持続性に関わるあれこれの多くは『SREこのへんで苦戦しがちじゃないですか？』でとりあげた「言外の前提条件」でカバーする範囲だと思います。

• You build it, you run itに価値をおいているか
• HRTを重視する（Humility：謙虚、Respect：尊敬、Trust：信頼）
• 建設的な言動に価値を置く
• 心理的安全性を実現することに価値を置く
• 検証し失敗して学ぶことに価値を置く
• システム/サービスの価値構造の認識、あるいは価値観 ＝ 信頼性に価値をおいているか

今回の『SREsのためのSRE定着ガイド』ではこのあたりを刷り込んでいく・持続させるためにあれこれしましょうのあれこれの話をしました。なかなか一筋縄ではいかないですね。そんなもんだと思います。人類にとって自己変革と行動変容は難しいものです。

当日取り上げられなかった質問

SRE導入ついて

既存のプロジェクトにSREの考え方を導入・浸透させたいと考えております コミュニケーションから始めますが、既存プロジェクトメンバーに反発されないようにうまく入り込んでいくのに良い手段やノウハウはありますでしょうか？

社内の開発メンバーをまとめてSREの実践をするところにハードルの高さを感じています。 どんな事から始めたらいいでしょうか。

「失敗する方法はあるけど成功する方法はない」系の話じゃないかなーと思います。

たとえば「SRE的な正しさ」を軸に会話したり主張したりすると反発しがちですよね。 一般に効果的なプラクティスだと「まず共感・肯定」が思いつきます。 べき論の過不足よりも、具体的実践的な、いま現場でおきている困りごとや不足・不満・手間を扱うと打率が高そうです。 併せて嫌味にならない程度に定期的に進捗や成果をアピールして存在感を出すのもよくある方法です。

「あなたがそう言うのなら」と思ってもらえるくらいに、まずみんなの役に立って、信頼貯金と徳を積みたいですね。

SRE実践の戦略・方針について

SREの概念、理念は少しづつ理解出来てきました。 実践するにはまずどういう方針で行くか話し合ってから進めた方が良いですか

運用、開発などの既存チームとの棲み分けで気を付けることはありますか？

（特に上長との握りとしては）ビジョンとかミッションみたいなのを持っておいたほうがよいと思いますが、現場レベルでは「信頼してもらう」「実際に現場レベルで役に立つ」を繰り返すのがスタートだと思います。

欲張らず少しずつ、実践的なquick winを積むのがよいと思います。 とはいえquick winを焦るあまりほとんど成果にならない困りごとの改善（効果があまりに小さい）をquick winとするのはアンチパターンですから、練習（あるいは練習の練習）とquick winはわけて考えましょう。 そのうえで、前述のように成果をアピールしたりしながら信頼貯金と徳を積みたいですね。

チームビルディングについて

自分はSIer内のSREチームに所属しております。 ただ、現状の実態は運用チームといった状態になっています。

インフラ環境だけを保守しているような状況で、Devとコンタクトが取れない状態でもSREを適用することは可能でしょうか？なにかアドバイスがあればいただきたいです。

まだ社内で運用チームの土台が出来ていない状況で、運用チームビルディングに奮闘しています。 SREを導入するにあたって、色々アイディアはありますが、他のメンバーがくいつくにはどんなアイディアが比較的有効的か教えていただけませんか？

Devと完全に離れている状態でもプラクティスの一部を取り入れることはできると思いますが…なんというか、SREがその現場でアンマッチなら、やらなくていいんじゃないかなーと思います。とはいえユーザーのために信頼性を高めていく機運があるのならば、DevやBizと協働できるように取り組んでいきたいですね。SREを軸に考えるのではなく、ユーザーのための信頼性について考えて、いまの自分たちに適用していくべき手法としてSREが出てきたら、それがSREについて言及すべきときなのだろうと思います。

わたしがSRE NEXT 2022で『非ITの事業会社にSREと言わずにSREを持ち込んだ』という話をしていますので、そちらもご参照ください。

非ITの事業会社にSREと言わずにSREを持ち込んだ – Schedule | SRE NEXT 2022

いずれにせよ、現場のメンバーや状況によるので、いまそこにいるみなさんと会話してください！

その他

SREのチーム立ち上げから一緒に手伝ってもらえませんか？

ぜひ！ お問合せフォームからご連絡ください。