はじめに
DXテックG SRE チームの小柳津です。
SREチームは2023年度から、SREエンゲージメントモデルのひとつである「Embedded SRE」の取り組みを本格化しています。
今回は Embedded SRE の取り組みについて知ってもらうことを目的とし、活動の概要や方針、実際に Embedded としてAPLチームに参画してみての振り返りをしたいと思います。
Embedded SREとは？
直訳すると「組み込みSRE」。すなわちSREのメンバーが JCB Digital Enablement Platform (JDEP) 上で稼働しているAPLチームのDevとして参画します。
スクラムイベント含めすべてAPLチームの一員として従事するため、APLチームの基盤構築や監視運用の策定など密に関わりながら支援することが可能となります。
以下にEmbedded SREの導入背景やSREチームで定義している活動方針、活動実績をまとめます。
導入背景
APLチームにより近いところで開発速度、リリース成功の確実性の向上支援、およびAPLチームにSREの考えをインストールするため、2022年度下期にトライアルとして2つのチームへSREメンバーが参画しました。
ひとつはインフラ作業計画/アーキテクチャ設計/構築、ひとつは性能試験計画/準備をミッションとし完遂しています。
上記トライアルを経て2023年度からは定期的にEmbedded SREとしてメンバーを派遣。
23年度下期以降はSREの体制をEmbedded SREと、横断的な対応をするPlatform SREとして分離し、Embedded SREのモデルを本格採用しています。
体制変更の大きな理由として、2つのあるプロダクトが新たに動き出したことがあります。
チームビルディング、アーキテクチャ設計など初期からSREが関与することで、最適化した基盤設計と構築を目指し、かつAPLチームとSREチームの相互理解がより深まることを期待できます。
そもそもEmbedded SREはAPLチームの重要課題にスコープを当てた局所的な支援をしていましたが、23年度下期以降はプロダクトが始動するチームもあり初期から関与する方針に変更しています。
JDEPはクラウドネイティブ基盤を採用しており、開発経験が豊富なAPLチームメンバーでも基盤の特性を活かした開発は困難であったためです。
その中でSREの特性とJDEPのプロダクトフェーズの現状が以下であることを鑑み、「プロダクトフェーズの初期からのSREが関与すること」をソリューションとしました。
- SREはPlatform横断的な支援を元から実施していたこともあり、他サービスの実績横展開が容易である
特にプロダクトフェーズ初期段階では他サービスの知見を活かした高い生産性が期待できる。 - サービスインから時間が経ち、リリースや運用の経験を重ねて成熟したAPLチームが存在していること
チームの成熟度によって支援の濃淡をつけることが可能になった。
プロダクトフェーズにおけるAPLチームへの関与方針
SREがAPLチームに関与するプロダクトフェーズは SRE Book の Chapter 18 - SRE Engagement Model, Google SRE Book を参考に分割し、JDEPの実績との対応関係を以下のようにプロットしています。
SREチームでは本フェーズを踏まえ、関与度・必要なミッションを以下のように明示しています。
| フェーズ | JDEPでの定義 | SREの支援方針 |
|---|---|---|
| Ideaフェーズ | サービス検討〜APLチーム立ち上げ | - |
| アーキテクチャデザインフェーズ | アーキテクチャ検討〜Dev環境払い出しまで | Embedded |
| プロダクト開発フェーズ | Dev環境払い出し〜Production環境への資材デプロイ〜システムリリースクライテリア(APL) | Embedded |
| サービスインフェーズ | システムリリースクライテリア(APL)〜サービスイン約1ヶ月後（安定稼働） | Embedded |
| 追加開発フェーズ | サービスイン約1ヶ月後〜開発案件（要クライテリア）終了まで | SREへの個別依頼,オフィスアワー ※ |
| 運用保守フェーズ | 開発案件（クライテリア外の小規模開発）〜サービス終了まで | SREへの個別依頼,オフィスアワー ※ |
| EOL | サービス終了、開発中止 | - |
※運用改善・効率化等フェーズで必要なミッションがある場合は、要望に応じてEmbedded参画
メンバーの選定
SREチームでは半期に1度スクラムマスターとの1on1を通じてスキルマップを作成しています。
その中で今後伸ばしたい領域もヒアリングし、その結果を加味した上でEmbeddedメンバーの選定が行われています。
（筆者もEmbeddedの経験がありますが、"障害試験の支援をやってみたい“と 1on1で伝えたのが選ばれた理由の一因であったかもしれません）
Embeddedの仕組みはSREメンバーのスキル向上も目的に含まれているため、本人の意向を汲んだ選定がなされます。
またスキルやAPLチームの知見の偏り防止、APLチームにSREメンバーが吸収されることを防止するため、Embeddedメンバーは固定化しないよう定期的なローテーションを実施しています。
活動実績
Embeedded SREの活動実績を一覧化してみます。
基本的にはスポットでの参画で期間を1−2ヶ月としていますが、以下表にある通り 長期的に伴走する事例もあります。
| サービス | ミッション | 期間 |
|---|---|---|
| サービスA #1 | インフラ作業計画/設計/構築 | 2023/2 - 2023/4（約1ヶ月） |
| サービスB | 性能試験準備 | 2023/2 - 2023/4（約1ヶ月） |
| サービスC | インフラ作業計画/設計/構築 | 2023/7 - 継続 |
| サービスD | 定期運用作業の整理と自動化 / トイルポリシーの定義 | 2023/8 - 2023/10（約2ヶ月） |
| サービスE #1 | 非機能（性能/障害）試験実施、運用構築 | 2023/10 - 2023/12（約2ヶ月） |
| サービスE #2 | Production環境のリソース確認、運用高度化 | 2024/1 - 2024/2（約1ヶ月） |
| サービスC #2 | 非機能試験 | 2024/1 - 2024/3 |
| サービスA #2 | Stage環境構築、非機能試験準備 | 2024/1 - 2024/3 |
| サービスA #3 | 非機能試験実施、Production環境構築 | 2024/4 - 2024/6 |
| サービスF | アーキテクチャ検討、Dev環境構築 | 2024/2 - 2024/4 |
上記のような期間の違いはAPLチームの以下2点の違いによって決定されます。
- プロダクトフェーズの位置
アーキテクチャデザインフェーズ、プロダクト開発フェーズなどのプロダクトフェーズの位置とSREのリソースを鑑みた費用対効果がチームによって異なるため。 - 特定のAPLチームを担当する外交官SREの存在
旧体制ではSREチームにいながら特定のAPLチームの支援を担当するメンバー（外交官SRE）を設けており、インフラ設計や非機能試験の支援も行っておりSREの知見も浸透しつつあった。
長期的に伴走している2チームは若いプロダクトで外交官が存在していない状態で、現在の方針に則したプロダクトフェーズ初期からのEmbedded参画が可能であったため長期的な支援を実施。
振り返り
Embedded 期間の終了後に、SREとAPLチームで振り返りをKPT法で実施しています。
その振り返りの場で生まれた効果や、今後の課題について一部をご紹介と、合わせて個人的な振り返りもしてみます。
APLチームとSREチームにおける振り返り
Keep
- 期日までに目標としていた課題を完了できた
- SREにインフラにおける不明点をすぐに質問でき、開発のスピード感が上がった
- APLチームが誤った認識をしていた部分が是正できた
- JDEPが推奨する方針を共有してもらい認識できた
- 運用作業の削減ができた（1年で作業時間が5割削減）
Problem
- 作業を任せてしまうことが多く、APLチームへの定着が少ない
- 推奨されているトイルポリシーの策定ができたものの、定着に時間がかかった
- 作業自体に明確な分担が行われてしまい、スキルトランスファーの実施ができなかった
Try
- APLスケジュールを踏まえたミッションの策定
- mustは達成できてもbetter（ペアワークでのノウハウ共有）が二の次となってしまった為、引き継ぎ時期を含め参画時期の調整
- Embedded参画のフェーズを早める
- こちらは本格運用で実現している
- ペアワークをするメンバーのスキルセットについて
- 参画するチームメンバーのスキルセットやペア可能な人数等は事前に把握しておく
個人的なKeep, Problem
Keep
- インフラ設計/構築や非機能試験の知識と経験を得たこと APLチームの要件に従ってタスクをこなすことでスキルの向上はもちろん、APLチームの支援の意識に変化が生まれた。（広く浅く → 広くやや深くのような）
- APLメンバーとロードマップに従った開発を経験できたこと リリースに向け先を見通したスケジュール、タスクの起案を行えたのがよかった。
- ミッションと期間を固定しておくことで以下のよさを感じた
- APLメンバーの意識に変化をもたらすことができる
SREはスポット参画のため、期間中にAPLチームのメンバーにインフラの知見を積極的に取り入れてもらうこと、SREの考えを浸透させることの必要性を感じてもらえる実感があった。 - ゴールに向けて集中的に作業ができる
APLチームに長期参画する事例はほぼないため、意識としてメリハリがつく。 特にSREのイベントの一部や勉強会に参加は必須のため、帰属意識が持てポジティブに作業ができる。
- APLメンバーの意識に変化をもたらすことができる
Problem
- 決まった期間の中でミッションの遂行とスキトラの並行は難しい
APLチームメンバーが何を得意としていて何が不足していると感じているのか、前提知識の理解がないと共有したい情報の選択に時間がかかる。 - APLチームの文化の吸収
アーキテクチャなどは資料を見ればインプットできるが、レビュー、スクラムイベント、ブランチ戦略などチーム独自の文化が色濃い。
SREチームの名残でやっていたことは伝わらず困惑する場面がいくつかあった。
Embedded先のチームにはウェルカムな雰囲気を作ってもらえると仕事もしやすい。 - プロダクト開発フェーズからの参画だと方針や設計に疑問を持つことがある
なぜこの方針にしたのか？なぜこの手段を取ったのか？検討経緯がわからないとAPLチームに確認する時間がかかる。
今後新規にプロダクトが立ち上がった場合はEmbedded SREが参画するため、このような事態は少なくなると思われる。
Try
- APLチームの文化、振り返りの共有までをEmbeddedとする
Embeddedから戻ってきたメンバーからAPLチームの文化を振り返り結果とともに共有するまでをミッションとする。 - APLチームへのスキトラの手段をAPLチームも巻き込み議論する
- Embedded終了後にKPT法で振り返りをしているが、定量的な変化も見れるような手段を考える
まとめ
Embedded SREの活動概要と振り返りについてまとめてみました。
まだ走り出したばかりで課題も多いですが、個人的にはとても有意義な取り組みであると思っているため今後も継続していきSREとAPLチームの相互理解をより深いものにできればと考えています。
定量的な価値を見出すことのできるよう改善も並行して行いますので、また本ブログでご紹介できればと思います。
最後に
JCB では、我々と一緒に働きたいという人材を募集しています。
詳しい募集要項等については採用ページをご覧下さい。
本文および図表中では、「™」、「®」を明記しておりません。 記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。
