SREチームの再立ち上げとミッション、ビジョン、バリューを作った話
SREチームの@biosugar0です。
今回は社内外向けに、スマートショッピングのSREチームの再立ち上げと、 最近定義したミッション、ビジョン、バリュー(MVV)について紹介したいと思います。
結論から書くと、Site Reliability Engineeringを先導する組織としてSREチームを再立ち上げし、以下のMVVを作成しました。
- ミッション
- 日常を革新するプロダクトが走り続けるために、整備された道とガードレールを作り改善していく
- ビジョン
- 自律して信頼性の高いプロダクトを作り続けられるスマートな開発組織の実現
- バリュー
- Bold and Flexible
- Automation
- One for All
- Data Driven
- Proactive
では背景などから紹介したいと思います。
これまでのSREチームのミッション
実はこれまでも、SREチームのミッションとして以下のようなものを定義していました。
- 独立したチームとしてSite reliability engineering(SRE)を実践する
- プロダクトの信頼性を社会的および技術的側面から担保する
- 弊社インフラプラットフォームに最適なアーキテクチャの助言やレビューとフィードバックループを持つ
- SREのプラクティスを社内に広げ、信頼性とイノベーションを両立させる文化を作る
- 運用の自動化及び自己修復可能なシステムの開発を継続して行い、少数での運用体制を維持する
- 開発プラットフォームの開発を継続的に行い、イノベーションを最大化する
- インフラのコスト最適化を行い、利益率向上に寄与する
ミッションとしては多いですね。 チームの道標にするミッションとしては覚えづらいという問題がありました。
なぜこのミッションにしたかというと、SREチームの再立ち上げにあたってより具体的な役割を示すことが必要だったからです。
ミッション定義前のSREチーム
この以前のミッションは2022の1月に定義したものなのですが、SREチームにはそれまでミッションは定義されていませんでした。
ミッションが明確になっていなかった以前のSREチームがどういう状態だったかというと、 2020年にシステムの信頼性向上のためのEKS移行を行った後、 SREチームは実質的にはクラウドインフラの構築、運用担当者のようになっており、
ほぼ 運用タスクとインフラ構築依頼、緊急対応のみを受動的に行うチームになっていました。
他の時間は何をしていたかと言うと、プロダクト開発との兼業メンバーのみで回している状態になっていたことからプロダクトの機能開発をしていました。 兼業のSREしかいないこともあり、どうしてもビジネスに直接的に影響する機能開発のロードマップがSREチームのリソースに影響してしまっていました。
組織の信頼性のマインドセット:Google SRE の知見にあるように、 組織の信頼性へのマインドセットには連続的な5つの段階があります。
図1. さまざまなGoogleプロダクトチームが組織の信頼性スペクトラム上に占めている位置を表した単純なグラフ。Google のプロダクトチームの多くがReactiveまたはProactiveな信頼性文化を持っていますが、ほとんどはProactiveです。
図1に示したような連続的な信頼性へのマインドセットのうち、弊社ではおおむねAbsentに位置していました。 このフェーズは、上記のブログでは以下のように説明されています。
- 機能のリリースが組織の主要指標であり、インセンティブの焦点となっています。
- 大多数の問題はユーザーまたはテスターによって発見されます。このような組織は長期的な信頼性リスクに気づいていません。
- 開発速度が信頼性と引き換えられることはほとんどありません。
組織の信頼性の連続的な流れ/組織の信頼性のマインドセット:Google SRE の知見
スタートアップらしく、まずは機能！という感じでプロダクトの信頼性と持続性のための非機能要件タスクよりも常に機能開発を優先してやっていたフェーズですね。
その後、プロダクトの成長と共にシステムの規模が拡大しエンジニアの人数が増えてきたことで、プロダクトの信頼性の維持と向上、そして持続的な開発のためにはSREが受動的な運用をするだけではなく、能動的に働きかけていくことが重要であるということが徐々に見えてきました。
成長期のスタートアップにこそ、運用の課題にソフトウェアエンジニアリングで立ち向かうSREのプラクティスは重要です。
SRE本の第1章には、SREの動き方について以下のように書かれています。
- SREチームはエンジニアリングに注力することが重要です。常にエンジニアリングを行っていなければ、運用にまつわる負荷が増大し続け、負荷についていくためだけでもチームにはさらに多くの人数が必要になります。
1.2 SRE の信条/Site Reliability Engineering
この点に関しては特に、成長に対して人が不足しがちなスタートアップでは重要です。 依頼を受動的に実行するだけのSREでは運用が早晩破綻してしまうでしょう。
また、サイトリライアビリティワークブックでは
SREは仕事のロールであり、私達がうまくいくと見出した一連のプラクティスであり、それらのプラクティスを活気づける信念です。DevOpsを哲学と働き方へのアプローチと考えるなら、SREはDevOpsが掲げている哲学の一部を実施したものと言え、「DevOpsエンジニア」†8よりも明確な仕事やロールの定義と言えるでしょう。したがって、ある意味で class SRE implements interface DevOps なのです。
†8 これは多くの面で間違った呼び方で、最も基本的なこととして単に人々を雇って「DevOpsエンジニア」と呼び、すぐに利益を期待することはできません。利益を得るためには、働き方を変えるという哲学全体を受け入れなければなりません。Andrew Clay Shaferが言うように、「人々はDevOpsを売るが、それを買うことはできない」のです。そしてSeth Vargeが「DevOpsの10の神話」で指摘したように、「組織を修復するためにDevOpsを雇う」ことはできないのです。
1.2 SREの背景/Site Reliability Workbook
とありますが、 機能開発のモチベーションが高いスタートアップではプラクティスとしてのSREを開発組織に定着させるために、
Site Reliability Engineering(SRE)の実践を先導し、信頼性に取り組む文化を開発組織全体に浸透させる役割を持つ職種としてのSite Reliability Engineer(SRE)が必要だと思っています。 実感として、兼業や開発チーム内だけで0からSite Reliability Engineeringに取り組めるようにするのは(機能開発の優先度が高いため)難しいです。
SREチームの再立ち上げ
そこで2022年のはじめから、自分がバックエンドとの兼業からSRE専任に異動したタイミングで、 SREチームが独立したチームとして名実ともにSREとしてプロダクトの信頼性のために動けるようにするためにSREチームの再立ち上げを行いました。 その際、SREチームの実態を受動的な運用担当から能動的なSREに転換することをチーム内外に示すためにミッションを定義しました。
そんな背景があり、これまでのミッションには独立したチームとして依頼以外のSREタスクに取り組めるようにするために、単なる運用担当者ではないことを強調するような言葉が入っていたり、 具体的なタスクに近い文言を入れたりしていました。 SREチームが機能開発のロードマップとは独立、平行に動けるようにすることが特に重要でした。
そこから我々は新生SREチームとしての活動を開始し、2022年6月現在 プロダクト開発チームと連携しながらプロダクトの信頼性の維持と向上のためのタスクに取り組むことができており、 メトリクスの観測からのパフォーマンス改善や運用の自動化など、成果を出し始めています。
また、「トイルの計測とトラッキングを始めました」でも紹介したように、トイルの計測を継続しており 50%以下のトイルを維持し、SREチームがトイル以外のタスクに取り組めるようになっています。 今のところ、50%以上になったことはありません。
ミッションを定義して動きはじめ、SREチームが機能開発の片手間でなく独立したチームとして、 名実ともにSREとしてプロダクトの信頼性のために動けるようにするという再立ち上げの目的は達成できました。 そこで今回、SREの動き方を転換するために定義したこのミッションは役割を終えたと判断し、 新しくシンプルで覚えやすい道標となるようなMVVを作成することにしたのです。
ミッション、ビジョン、バリューの定義
弊社には会社のMVVも設定されており、ミッション、ビジョン、バリューそれぞれの定義については 代表の志賀が書いたMVVを再定義しました〜ミッション編〜という記事にもあるように、
- ミッション(不変/一般的)：会社の存在理由。企業理念・パーパスとも呼ばれる。決して届かないが、道標になる（基本変わらない）
- ビジョン(進化/オリジナル)：10年先の事業のあるべき姿。皆をストレッチさせる。3年レベルで改良。期限が入るとベスト
- バリュー(進化/オリジナル)：組織のあるべき姿
- コアバリュー：組織レベルで持つ価値観。皆にどう意識してほしいか・どう見られたいか。社内外のブランディングで使う
- 行動規範（SS Way）：個人レベルでどう行動すべきか。日々の意思決定・採用・評価で使う
としています。
SREチームでは今回、それを一部引き継ぎ、
- ミッション: SREチームの存在理由。基本変わらず、道標となるシンプルなもの
- ビジョン: 5年先のSREチームの目指す景色
- バリュー: SREチームのあるべき姿、行動指針
として会社のMVVと整合性がとれるように議論して作成しました。 この進め方はSRE NEXT 2022のTopotalの高村さんの発表 「How We Foster Reliability in Diversity」を参考にさせていただきました。
それでは、MVVの紹介に入りましょう。
ミッション: 日常を革新するプロダクトが走り続けるために、整備された道とガードレールを作り改善していく
スマートショッピングの会社としてのミッションは、「日常に永遠のイノベーションを」です。 我々のプロダクトは、日常を革新し続けます。 SREチームでは、そのプロダクトが走り続けられるようにエンジニアリングで支え続けます。
「整備された道とガードレール」としているのは、 SREチームが信頼性をコントロールするのではなく、 プロダクト開発チームが安全に走ることができる道を作ること、 つまりプラットフォームの開発や信頼性の向上に取り組む文化の形成によって プロダクト開発チームが信頼性をコントロールしながら開発し続ける支援を行うことを意味しています。
スマートショッピングのSREチームでは、我々が提供するようなSaaSプロダクトにおいて信頼性とは、
- SLIなどで表されるシステムの安定性
- よりよい開発者体験によるすばやいバグ修正や魅力的な機能改修
によって構成されていると認識しています。
SREチームのみが信頼性をコントロールするやり方では、いずれSREチーム自体が信頼性のボトルネックになってしまいます。 なぜなら、SREのチーム規模はシステムのサイズに比例して大きくなったりはしないからです。 また、プロダクト開発において開発チームが自律的に信頼性について考慮し設計、開発していくことは、プロダクトの質の向上にも繋がります。
SREチームでは、プロダクト開発チームが信頼性の高いプロダクトを作り続けられるようなプラットフォームと文化を作っていきます。
ビジョン: 自律して信頼性の高いプロダクトを作り続けられるスマートな開発組織の実現
スマートショッピングの会社としてのビジョンは、「モノの流れを超スマートに」です。 このビジョンを実現するために、開発組織もスマートに信頼性の高いプロダクトを作り続けられるものにすることをSREチームではビジョンに掲げます。 この「開発組織」とは、Product Managerを含むプロダクト開発チームに加えてSREチーム自身も含みます。
SREチームが目指す景色は、開発組織全体で各チームがプロダクトの信頼性について自律的に取り組むことができるようになることで、 その結果信頼性の高いプロダクトを作り続けられるようになっていることです。
先に述べたとおり、弊社での信頼性は安定性だけでなくよりよい開発者体験によるすばやいバグ修正や魅力的な機能改修も含むので、 安全にすばやくプロダクトを届け続けることが信頼性の維持、向上のために重要です。
そのため、SREチーム単体ではなく開発組織全体で信頼性に取り組むことができる組織をSREチームは目指します。
バリュー
バリューはSREチームの行動指針です。 スマートショッピングの会社としてのコアバリューを元に、SREチームとしてあるべき姿に適した形を議論して5つの行動指針にしました。
Data Driven
- すべての基本は計測から。データ駆動であらゆる課題の解決を目指す。
Bold and Flexible
- 大胆かつ柔軟に。失敗を恐れずチャレンジし、柔軟に対応する。
Automation
- 単に自動化されたものではなく、自動的に動作するシステムを目指す。
One for All
- 組織の垣根なく会社全体でうまくいく方法を模索する。
Proactive
- 学び、考え、積極的に自ら実践する。
終わりに
スマートショッピングのSREチームはインフラ運用担当者からSite Reliability Engineeringを実践するSREへ生まれ変わりました。 さらに今回作ったシンプルなミッション、ビジョン、バリューはチームとしての道標となり、 全員が同じ方向を向いて進みやすくなったと思います。 また、社外の人に向けてはSREチームの解像度が上がるものになったのではないでしょうか？
SREチームの再立ち上げの取り組みや、ミッション、ビジョン、バリューをいいなと思った人はぜひご応募ください！