こんにちは、マネーフォワード サービス基盤本部 インフラ部に所属している中谷です。 先日、鈴木のブログにもあったように、サービス基盤本部では体制を変えていっている真っ最中です。（今までの組織体制の課題や、これからの本部としての目指す方向の詳細については、是非そちらのブログを参照してみてください。） その新しい体制の中で "Enabling SRE" というチームが生まれるのですが、Enabling SREとはどういうチームなのか？どういう背景で生まれたのか？何をやっていくのか？ということを紹介したいと思います。SREの文化を根付かせたいけど、どうアクションすればいいかわからないといった方の参考になればいいなと思っています。
はじめに
まずは背景を簡単に説明して、なぜEnabling SREが必要になったのかを知ってもらいたいなと思います。
サービス基盤本部の体制変更の背景
マネーフォワードでは、初めは中央のインフラチームのみで全てのプロダクトの運用を行い、プロダクトの開発チームは機能開発に集中するという体制でした。しかしながら、プロダクトの数が増えていくにつれて、インフラチームのリソースが不足し始め、インフラチームがプロダクト開発のボトルネックになってきました。
このままでは中央のインフラチームのスケールに合わせる形でしかプロダクト開発のスピードが出せないということになってしまいます。それを回避するために、プロダクト開発の各プロダクトの開発チームに権限を渡していき、自分たちで開発のサイクルを回せるようにする必要があると考えました。そこで、権限を渡しやすいような新しい基盤を作り、プロダクト開発チームが自分たちで開発のサイクルを一貫してみれるように新しい基盤に移行をすすめていきました。
ただそういった中で、下のような別の課題が出てきました 1. 基盤をまだ作り込めていないということもあり、プロダクトの開発チームで開発サイクルを閉じていくにはまだまだ基盤上でのアプリケーションの開発/運用の技術的な難易度が高い。 2. 各プロダクトの開発チームは、自分たちで開発のサイクルを回し、非機能面も含めて見るべきだと考えている。しかしながら、権限を渡されても非機能面を見ていくための知見がないので、自分たちでみれるようになるまでにGapが存在している。
現在、一部のプロダクトは実際に中にSREチームを作り、自分たちで非機能面まで見ることができるようになってきています。しかしながら、自分たちでSREチームを作ったり、SREを実践できないチームがまだ存在しています。SREチーム立ち上げのための知見がなかったり、リソースが割けなかったり、といった課題が存在しています。
そして、主に上記の2.の課題を解決するためにEnabling SREが必要と考えました。（1.の課題に関してはPlatform SREの内容になってくるので本記事では詳細は割愛します）
こういった背景があってサービス基盤本部は体制を変えていこうと考えています。
これからのSRE/インフラの組織体制
さて、マネーフォワードでのこれからのSRE/インフラの組織としては
- Platform SRE
- Enabling SRE
- Product SREs
の3つに分かれていこうと考えています。このうち、Platform SREとEnabling SREはサービス基盤本部に所属し、Product SREsは各プロダクトが存在する事業部に所属しています。 ぞれぞれの役割を簡単に説明しておくと
- Platform SRE
- サービスを載せるための基盤（EKS）を開発し、その信頼性に責務を持つ。Platformを通して全社の開発体験や開発生産性を高める責務を持つ。
- Enabling SRE
- 各プロダクト開発チームのうち、まだSREチームが立ち上がってないところに対して、Platform SREが開発する基盤を活用し、SREのプラクティスや文化を浸透させ、立ち上がりを支援する。
- Product SREs
- 各プロダクトの開発チームに存在しているSREチーム。所属するプロダクトにおいて、高い開発生産性を保ちつつ、信頼性を高めていく責務を持つ。
です。
Enabling SREで何を達成したいのか？
さて、ようやくここからが本題です。 上でも書いていますが、Enabling SREで達成したいことは
各プロダクトの開発チームが自分たちでSREを実践することができるように、SREのプラクティスや文化を浸透させる
です。自分たちでSREをやっていきたいけど、やり方がわからないとか、そこにリソースを割けない、というプロダクト開発チームに対して最初の立ち上がりをサポートし、自分たちでSREをやっていくことを 可能にする（Enable） ことを目的としたチームです。
Product SREsとEnabling SREの違い
Product SREsは基本的に各プロダクトに固定されます。対して、Enabling SREは各プロダクトに固定されません。 というのもProduct SREsは各プロダクトに対して責務を持っていますが、Enabling SREは各プロダクト開発チームが自分たちでSREが実践可能な状態を作ることに責務を持っているチームだからです。
例えば、あるプロダクト開発チームにEnabling SREとして入っていき、彼ら（プロダクト開発チーム）が自分たちでSREを実践できるようになれば、そのプロダクトチームに対するEnabling SREの役割は終わりということです。そしてEnabling SREチームはまた別のプロダクト開発チームでSREの立ち上げをサポートすることになります。 つまり、Enabling SREとProduct SREsはそれぞれ持っている責務が異なります。
Enabling SREとして、何をやっていくのか？
現時点ではまだ活動を始めたばかりという段階ですが、現時点で決めているアクションをご紹介したいと思います。これからやっていくことなので、やりながら柔軟にアプローチは変えていくつもりです。
各開発チームがSREを実践できるようになるまでのサポート
1.「SREが実践できている状態とはどういう状態なのか」という理想状態を定義する。
まず、各プロダクト開発チームに対して「さぁSREやっていきましょう！」と声をかけても「SREって何するの？」となるチームもあると思います。それに、理想が決まってないと、色々な開発チームでSREができるようになったとしても、それぞれのプロダクト開発チームでできることに差が出てしまいます。細かい要件は各プロダクト開発チームごとに変わってもいいと思いますが、目指すベクトルは合わせたいところです。そういった意味合いも含めて、まずは理想状態を定義します。これは、社内のメンバーでブレストをしたり意見を出し合ったりしながら決めました。
2. 各開発チームにヒアリングをして現状を知る
理想状態が決まったから、さぁやっていきましょう！というわけにもいきません。次の段階として現状を知るというフェーズに入ります。現状を知らないと、SREをやっていくためには何が足りていないのか？ということが見えないためです。そして現状どういったフェーズなのかということに関しては各チームごとに異なっています。そこで各プロダクト開発チームにヒアリングをして現状を知るということを進めていきます。
3. 現状と理想状態のギャップを分析して、アクションを決める
現状と理想状態が明らかになったので、次に現状と理想状態のギャップを分析します。ギャップを分析することができたら、そのギャップを埋めるためにどういうアクションを取る必要があるのかということを議論します。SREといっても責務の範囲がすごく広いので、各アクションについて優先度を決めることも重要です。
4. 実際にアクションしていく
アクションが決まったら、いよいよ各プロダクト開発チームに入っていってSREの立ち上げを支援していきます。ただ支援するとはいっても、ゆくゆくはプロダクト開発チームだけでSREを実践できるようにならないといけないので、あくまでも主体的に動くべきなのはEnabling SREではなく、プロダクト開発チームだと思っています。プロダクト開発チームに主体で動いてもらいつつ、Enabling SREチームはサポートするという形にしていきたいです。ただ、立ち上がりの最初のうちはプロダクト開発チーム側にリソースがないこと等もあると思うので、Enabling SREもある程度動くことになると思っています。例えば、弊社のいつくかのプロダクトはオンプレミス上で動いているのですが、これをプロダクトチームでSREを可能にするために、AWSのEKS環境への移行もサポートをしていこうと思っています！
この1-4のサイクルを各プロダクト開発チームを周りながら進めていく予定です。現状のステータスだと、1.の「SREが実践できている状態とはどういう状態なのか」という理想状態を定義し終えた段階です。
（1-3の過程についてはAs-is To-be分析のフレームワークを活用しています。）
その他の活動
各プロダクト開発チームに実際に入って行ってアクションすることも重要なのですが、それだけではなく、以下のような活動もしていきたいと思っています（まだいずれもアクションはできていないです）。
各開発チームがSREをどれだけ実践できるようになっているかを定量的に分析できるような指標を策定する。
Enabling SREは各プロダクト開発チームに固定されるわけではなく、その役割を終えたと判断したら他のプロダクト開発チームに移る、という話はしましたが、ここの "役割を終えた" という判断の基準を決めておくことはとても重要だと考えています。この基準がないといつまでもそのプロダクト開発チームから抜けられない。ということになってしまいます。なのでその判断の基準を決めておいてプロダクト開発チームに合意を取り、基準を満たしたら一旦自分たちで実践できるようになったものとする、ということが言えるような基準を作成する必要があると思っています。
マネーフォワードにおけるSREをある程度体系化したドキュメントの整備
あまりガチガチにしてしまうと逆効果ではあると思いますが、上でも書いている通り、マネーフォワードにおけるSREとして目指すべきベクトルはみんな同じである方が良いと考えています。ですので、 "マネーフォワードにおけるSRE" を体系化したドキュメントのようなものを作成し、運用していくことで、それぞれのプロダクトチームが同じベクトルを向けると思っています。 これはEnalbing SREだけで決めていくのではなくてProduct SREs含むプロダクト開発メンバーと一緒に作り上げていく必要があると思っているので、githubで管理するなどして、議論したりする場所を作りたいなと思っています。
Enabling SREで活動していく上で課題を解決するためのツールの整備
これはいきなり用意するものではないですが、Enabling SREをやっていく中で複数のプロダクトチームで共通の課題にぶつかることもあると思います。そういった課題はできるだけソフトウェアエンジニアリングで解決していきたいと思っています。
最後に
これから答えがないようなものと戦う難易度の高い取り組みにはなりますが、とてもやりがいのあることですし、これを達成することでより強い組織になり、さらに高いレベルでユーザーに価値を届けることができるようになると思っています。
マネーフォワード、サービス基盤本部では、エンジニアを募集しています。まずは気軽に話を聞いてみたいという形でも良いので、カジュアル面談でまずはお話しましょう！ 下のリンクから、SRE関連の募集ページや、SRE/インフラ関連のエンジニアブログに飛ぶことができます！ MoneyForward/SRE URLs
ご応募お待ちしております！
マネーフォワードでは、エンジニアを募集しています。 ご応募お待ちしています。
【サイトのご案内】 ■マネーフォワード採用サイト ■Wantedly ■福岡開発拠点 ■京都開発拠点
【プロダクトのご紹介】 ■お金の見える化サービス 『マネーフォワード ME』 iPhone,iPad Android
■ビジネス向けバックオフィス向け業務効率化ソリューション 『マネーフォワード クラウド』
■だれでも貯まって増える お金の体質改善サービス 『マネーフォワード おかねせんせい』
