「少人数のチームにて、一人からSREを始めるにはどうすればいいのか？」
2021年の10月からHR領域（マネーフォワードクラウド勤怠）でSRE組織を立ち上げているVTRyoです。 もっとサービスをより安定させたい！より向上したいといった話から、SREという役割を設置するケースは増えています。
しかし、SREという概念のなかったチームや部署で始めるにはどこから手をつければよいのでしょう。
SREの基本について記されたSRE サイトリライアビリティエンジニアリング――Googleの信頼性を支えるエンジニアリングチームには多くの原則が書かれていますが、同じことを丸々取り組むには前提や環境が違う部分も出てきます（SREのプラクティスを知るにはよい参考資料であることは間違いありません）。
というわけでこの記事では、以下の部分に答えられるよう進めていきます。
- SRE本を読んだが、実際の組織やチームではどこから手を付けて良いのか悩ましい
- 成熟したSRE組織の事例を見てもリッチすぎる故、ギャップが有って悩ましい
- 実際の初期立ち上げ時、何から手を付けたのか事例が知りたい
これはマネーフォワード全社におけるSREチームの話ですか？
いいえ。会社内でもSREチームの特性は異なります。あくまでマネーフォワードクラウド勤怠におけるSREの始め方としてご参考ください。
環境と前提
タイトルにスモールチームとあります。マネーフォワードって小さくなくね？という認識ズレがあったまま進むと混乱するので、ここでマネーフォワードクラウド勤怠チームの状況について整理しておきます。
SREという役割が配属された頃の状況
- 2019年3月にサービスローンチ
- チームのエンジニアは少数精鋭
- SREという言葉だけ知っている
- ※他部署にはいるが、他部署なのでほとんどわからない状態
インフラに関する作業は、サービスインフラという別部署に依頼するのが流れでした。
はじまり
チームに配属された直後は右も左も分からない状態であり、メンバーの役割やシステムの状況をちょっとずつ知っていくことになります。 （私のように転職してSREを始めるパターンではなく、同じ組織の中で立ち上げるのであればシステムやメンバー構成の知識がある状態である分、アドバンテージになります）
ここからはSREが一人だった場合の、初期にできる取り組みをご紹介します。
観察してから行動を取る
前提として、SRE本にあるプラクティスは（ざっと）理解しているとします。 （経験があればなお良いですが、この記事を読んでいる方のレベル感は様々だと思うので特に問わなくていいでしょう）
なお、ここでいきなりSREプラクティスを声高らかに宣言して実装するという方法は取りませんでした。 まずは、システムやメンバーについてよく知ることにしましょう。焦らない焦らない。
- 開発者のMTGに参加する
- 日々発生しているエラー、運用作業、その他大変そうなことは何かをキャッチアップする
このあたりをじっくり見てました。しかし単に見ていても勿体ない。せっかくなので、「SRE原則と付き合わせてどうか？」という点で、自分なりに「こうなったらSRE的にポイント高い」という状態を考えていきます。
その結果の事例をいくつか見ていきましょう。
メンバーの運用ペインを解消する
日々Slackを見ていると、「四六時中エラーの通知が来ている」ことがわかりました。 開発者はエラーを気にするあまり本来すべき開発から集中力をそがれていました。
また、運用に関してヒアリングをすると「OOMが多くて」「エラーが多くて」という意見があがってきます。
SRE原則に則って言い換えれば「戦術的な対応」を取らされ続けていたわけです。
一時的な対応はいつまでも差し込み作業を発生させることになり、それが続くと気づかぬうちに疲弊します。 ここで、最初にやったほうが良いタスクに目星が付きました。
SREには信頼性と開発速度のバランスを取る責務があると考えると、開発速度を阻害するエラー通知からなんとかしようと意思決定できます。
参画直後は、新しい概念であるSREという役割を知ってもらうためにも、既存メンバーの信頼性向上も同時に目指しましょう。
- メンバーのペインはなにか？
- SRE原則を照らし合わせて、すぐにインパクトを出せそうな課題を解決しに行く
その取り組みの様子です。
メンバーに信頼してもらう
一つペインを解消できた後は、SREについて知ってもらいました。 SREというワードや誤解から生まれてそうな部分を知り、すり合わせます。
信頼してもらう、と言っても大げさなことではなく「お互いのことを知ってもらう」ということです。 特に新規参画してきたばかりの人が、一体何をするのかわかるだけでも違うでしょう。
アンケートとすり合わせ
このときはGoogle Formでアンケートを実施し、SREについてどれくらい知っているのかを確認してました。
その後は時間を取って、SREってなんですか？という共有をスライドを使って実施。事前に伝えるべきポイントを知っているのでそれに合わせた内容にカスタマイズできますね。
その上で、SREの歴史やSREの責任範囲（まずはSRE本にある原則）を共有しました。 何でも屋さんではないし、何でもできるわけではない、と伝えるのは重要です。
メンバーにはどう協力してもらいたいかを伝える
SREとは何か、私の役割は何か、を伝えたら皆さんにはどんなふうに協力してもらいたいかを伝えます。
すべての運用作業を一人しかいないSREが巻き取るのは現実的ではありません（そもそもすべてを巻き取るべきでない）。 そんなわけで開発者自身が自分たちの運用をもっと楽に、もっとサービスを向上するために一緒に前に進みましょうという話をしていきました。
SREの存在によって、変わること（変えていきたいこと）と変わらないことを示しつつ、開発メンバーにとってどんなメリットがあるのかも共有していきました。
また、一部を担ってもらうことで開発者自身のスキルアップや運用面での疲弊削減、単独SREによるリソース不足を補います。
- SRE原則を知ることで、開発者としてのスキル幅も広がること
- あたたかみのある運用作業は積極的に減らせるように動き、より本質的な作業に集中できるようにすること
他にも現場特有の変化はあると思いますので、そのような内容を随時共有していました。 こちらの振る舞いを共有しておくことで、既存のメンバーが大きく混乱したり期待値のズレで不幸になることは防げるでしょう。
弊チームでは、あたたかみのある作業があったら共有して積極的にトイルを自覚していこうというところから始めています。
まずは小さなところからスタートしていきましょう。
それから
ここまでが立ち上げ超初期に取り組んだ内容です。意外と難しいことはしていないことに注目してほしいです。 SRE本にある内容を加味しつつ、すぐにインパクトを出せる部分を拾っていくとスムーズな立ち上がりになるかと思います。
- 現場にある目の前の課題を観察する
- 開発者が疲弊していることはないか
- SRE原則に従い、解消していく
- なぜこの行動をとったのか共有する
- 自分（SRE）を知ってもらう
- アンケートで意識調査してみる
- スライドで勉強会してみる
SREが一人しかいないという点で、メンバーに協力してもらう形にどうしてもなってしまいます。 そのため開発者にとって負荷にならないよう、そして協力してくれた人にとってもいい影響が出るように意識しています。
一通りのペインが解消され落ち着いたら、じわじわとSLO/SLIや、ミッション策定に始まる取り組みを進めていけばよいでしょう。ロードマップ作成、実装、採用、共有など実際に取り組んでいることは盛り沢山です。
※それはまた別の機会に。
これはマネーフォワード全社におけるSREチームの話ですか？
いいえ。会社内でもSREチームの特性は異なります。あくまでマネーフォワードクラウド勤怠におけるSREの始め方としてご参考ください。
マネーフォワードHR領域でSRE立ち上げをやっていきたいITエンジニアを絶賛募集中です！
【SRE】マネーフォワードクラウド（HR）_Embedded SRE
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly ■福岡開発拠点 ■京都開発拠点
【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android
■ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』
■だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』
