去年SREチームで合宿に行ってました〜1年後どんな効果が得られたのかレポ〜
はじめに
こんにちは。SREチームの菊地です。昨年の11月にSREチームで初めての合宿に行ったのですが、すぐレポートを書いてしまうと「行ってきました！楽しかったです！」というノリで終わってしまいそうだな〜と思い、しばらく寝かせて合宿の効果が実感できてから執筆しようと思っていました。
というのは完全に嘘で、忙しさにかまけてサボっていただけなのですが、振り返ってみると合宿で話したことが今ちゃんと効いてきているな、と感じることが実際多かったので、寝かせて書く合宿レポートもおすすめです。
合宿の経緯・目的
エンジニアの合宿といえばいわゆる開発合宿、ハッカソンやペアプロなどを短時間集中で行うコーディングメインのものを想像すると思いますが、今回行ってきたのは1行もコードを書かない「ミーティング合宿」です。
（実際の活動は年明けぐらいから始まっていましたが）SREチームが誕生したのが昨年4月。CI/CDが整備されていない、AWSの構成がブラックボックスになってしまっている部分がある、そもそも誰も知らないリソースがある、パフォーマンスが悪化しユーザー体験に影響が出ている・・・というような課題が散在している状態からスタートし、常に優先度の高いタスクに取り組み続けたことで、先送りにしてきた話題が溜まってきていたタイミングでした。
また、6〜10月の間「バックエンドのインフラをElastic BeanstalkからECS on Fargateに移行し、ついでにIaCを導入して、ジョブスケジューラもEventBridgeベースに作り直して、せっかくだからCloudWatchのアラートは全部Datadogに引っ越しちゃいましょう」という一大プロジェクト（バックエンドインフラリアーキと呼んでいました）に全員フルコミットして完遂したところだったので、打ち上げをしたい！という強い気持ちがありました。
宿を決める
合宿やりましょうと決めてからは早いもので、まず宿の候補をみんなでリストアップして、もろもろ総合的に見て千葉の土善旅館という所にしました。
土善旅館で最高の開発合宿をしようなというブログで発見し、圧倒的なコスパと、開発合宿プランがありプロジェクターなどのレンタル品が揃っているところが魅力でした。実際、環境も食事もネットの速さも最高でした。開発合宿の場所としてめちゃめちゃおすすめです。個人的に看板猫に会えることを楽しみにしていたのですが、残念ながら今回は会えませんでした。次回こそは・・・！
議題を決める
開発合宿形式で既存のタスクを集中的にやりましょう、ということならあまり準備もいらないのですが、ミーティング合宿なのでガチガチに準備していきました。1人1〜2トピックのファシリテーターを担当し、ゴールの設定や他社事例の調査などをかなり入念にやりました。
時間割はこんな感じでした。最速チェックイン最遅チェックアウト、食事以外はずっとミーティングというなかなかタフなスケジュールです。
1日目
チェックイン
バスと徒歩で旅館に到着し、通されたのは20畳ほどの大広間。行ったのは5人だったためかなり開放感がありました（笑）
チェックインを済ませて昼食に向かおうとしていると、なんと知人からDMが。彼も開発合宿で来ていたとのことです。他にも何組も開発合宿っぽいお客さんがいました。土善旅館恐るべし。
しっかり腹ごしらえをして、ミーティングに突入していきます。
ミーティング
1日目は
DB負荷対策&Aurora導入検討
監視Ph.2で何をするか/APMの導入検討
Design Docsの導入検討
Terraform・SAMリポジトリのブランチ戦略
について話しました。本当は全ての議題について書きたいのですが、ものすごく長くなってしまうので、「Design Docsの導入検討」をピックアップしてこのあと紹介したいと思います。
宴会
件のバックエンドインフラリアーキの労をねぎらい合いました。コロナ禍に誕生したチームなので、そういえば史上2回目の対面でした。
2日目
2日目になると写真を撮る意識が下がり、朝食の写真を取り忘れました・・・。美味しかったことだけ覚えています。
ミーティング
2日目は
リリース作業の負荷軽減〜Agility/デプロイサイクル向上に向けて〜
信頼性へのコミットに向けたオブザーバビリティの向上
2023年に向けたチームキックオフ
について話しました。こちらも1つだけピックアップし、「2023年に向けたチームキックオフ」についてこのあとのセクションで紹介したいと思います。
チェックアウト
15時チェックアウトなので軽く飲みに行ってしまう選択肢もあったのですが、みんな疲れ切っていましたし、そのまま旅行に突入し翌週はワーケーションするというメンバーもいたので（笑）、そのまま解散としました。
1年後ー合宿の成果を振り返る
さて、普通の合宿レポートならここで終わりでもいいのですが、なにせもう1年経っていますので、合宿で話したことが今どう活きているのかにフォーカスして深掘りしていきたいと思います。
議題① Design Docsの導入検討
まずは1日目に行った「Design Docsの導入検討」についてです。
冒頭で述べたバックエンドインフラリアーキという大プロジェクトですが、完遂はしたものの振り返りで色々課題が見えてきました。メンバーの共通見解としてあったのは「ゴールとゴールでないことが明確じゃなかった、あるいは明確でも忘れてしまう」ということでした。
この課題に対して何らかの設計ドキュメントが必要なことは明らかで、いわゆるDesign Docsの形式がハマるのでは？という意見があり、合宿で議論することになりました。
【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」を参考に、Design Docsとはなにかのインプットを行い、 自分たちのニーズに当てはまるのかを以下のチェック表で確認しました。
さらに3つの他社事例をもとに具体的なテンプレートと運用例のイメージを膨らませ、最終的に導入することを決定しました。
●ちゃんとメンテしていくストック情報系のドキュメント（仕様書、設計書 etc…）すら書いていない我々が書くものなの？そっちの方が先なのでは？
●むしろDesign Docsは、ちゃんとメンテする系のドキュメントを書けていない組織が「せめてこれだけは書こう」という気持ちで導入してもいいものなのかも。
●（Design Docs流行の背景には）Iac化が進んだことで、網羅的な設計ドキュメントを書く意義が薄れ、経緯を残すことの重要性が増してDesign Docsを書くのを優先した、という経緯もあるのかも？
これは議事録からの抜粋ですが、なかなか的を射た話をしていたのではないでしょうか。
合宿から1年経ってどうなったか
しばらくは「ある程度の規模だったらDesign Docs書きましょう」という感じでフワッと運用していたのですが、書いてみたメンバーの感想は上々でした。
特にもともと期待していた「ゴールが明確になる」という効果は大きいようでした。そこでDesign Docsをエピックの受け入れ基準として活用しよう、という取り組みを最近になって始めてみました。
現状SREチームでは、メンバーそれぞれが数ヶ月の開発案件を「エピック」という粒度で持ち、それを「エピック > タスク > サブタスク」という階層で分割し、カンバンで運用しています。スクラム開発だと同じタスクに紐づくサブタスクを複数メンバーで協業して進めるというような感じになると思いますが、我々はあまり他の人のエピックに紐づくタスク・サブタスクを協業することはしないので、どうしても自分が担当していないエピックとは距離ができてしまいます。それもあって、チケットをクローズするときになって初めて「あれ、そのエピック(タスク)のゴールってそれでいいんでしたっけ？」という指摘が出ることがしばしばありました。
それを防止するため、タスクごとに受け入れ基準(とDoD)を明文化して着手前にリファインメントを行い、チケットクローズ前に「受け入れ確認」というステータスでチームの合意を取る、というフローにしていたのですが、全てのタスクの受け入れ確認をする労力が馬鹿にならなくなってきていました。
そこで「エピックのゴールをDesign Docsで表現して先に合意を取っておけば、タスクには受け入れ基準がなくても、方針がぶれることはないのでは？」という話になり、今年の3Q(7〜9月)からお試ししています。
JIRAでエピックを作成したら自動でDesign DocsテンプレートからConfluenceにドキュメント生成されるというJIRA Automationを組んでいるので、作り忘れることもなく、Confluenceのツリー構造としても現在動いているエピックが整然と並ぶので、チーム外の人にとってもSREが今何をやっているかもひと目で分かるようになりました。
まだお試し段階ではありますが、受け入れ確認の時間が削減されて振り返りの時間オーバーが起こりにくくなったなど、すでに効果も出始めています。細かい受け入れ確認で疲弊しているチームにはおすすめの方法です。
現在運用しているテンプレートは以下の通りです。Googleの記事や他社事例をもとになるべくシンプルな構成にしています。
# 概要
- 目的と背景（what, why）を書く。
- 要件定義ではないので簡潔にする。
- 客観的な背景と事実に焦点を当てる。
# ゴール
- システムの目標が何かをまとめる。
- つまりはエピックの受入基準。
- 成果物にフォーカスした項目。「スコープ」と微妙に近いが、ゴールにはHowが入らないようにするとよさそう。
# ノンゴール
- システムの目標ではないことをまとめる。
- 目標ではないこと、というのは「システムがクラッシュしてはならない」などの否定されたものではなく、目標である可能性があるものの、明示的に目標ではないことが選択されていることを意味する。
# 解決策／設計
- 前述の概要（事実）、ゴールとノンゴール(要件)に対して、具体的な解決策を提案し、なぜそれが最適なのかを示す。
- 長期的に価値のあるドキュメントとなるよう作成する。（逆に言うとすぐに古くなったり陳腐化するような内容は書かない）
- 設計の細かい内容は書かない。代わりに付加情報としてトレードオフに焦点を当てる。
- トレードオフの例: スコープ、時間、費用、内部影響、外部影響、法や規約、技術要素 etc...
- 図やサブセクションを用いて分かりやすい内容を記載を心がける。（時間がかからない程度に）
# 外部から受ける制約
- 依存関係にあるものから受ける制約をまとめる。
- 例えば、ホストする環境（OS、プログラム言語、クラウドサービス）だったり、連携システム、その他の外部サービスなどから受ける制約。
- 外部制約を満たせない場合はそもそもやらないという判断をしてもよい。例えば費用面での上限を上回ってしまうなど。
# 採用しなかった解決策／設計
- 同様の結果を合理的に達成したであろう代替の解決策／設計を列挙する。
- ここではそれぞれが採用に至らなかった理由を書く（なぜ採用された解決策／設計が最適なのかということの裏返し）。
- 超簡潔に書く。
# その他
- どのセクションにも当てはまらない事を自由に書く。
議題② 2023年に向けたチームキックオフ
ピックアップする議題の2つ目は2日目に行った「2023年に向けたチームキックオフ」についてです。
冒頭でも述べた通りSREチームは発足から間もないうえ、わりと忙しく手を動かし続けてきました。さらにメンバーにSRE経験者がいないこともあり、「SREとはなにか、どういう状態を目指すのか」といった抽象的な話題を話したことがありませんでした。僕自身もSRE本ぐらいは読んだことがあるものの実践したことがなく、経験も踏まえてメンバーにインプットするということができていませんでした。
これによって生まれた具体的な課題は、以下のようなものでした。
SREチームの責任範囲が不明確で、なんとなく受け持っているものがある
SREとしてこれができていると良いという基準がなく、目指すエンジニア像/チーム像が曖昧
独立したSREチームとして活動を続けていいのか、それともembeddedなど他の実践パターンを取ったほうがいいのか
当時の議論と今日までの経過を振り返っていきます。
合宿から1年経ってどうなったか
課題1:SREチームの責任範囲が不明確で、なんとなく受け持っているものがある
SREあるあるとして、「インフラチームから始まってSREチームに変わっていく」というものがあると思いますが、我々も名前は最初からSREではあったものの同じ道を辿りました。そのため開発部全体に「とりあえずインフラっぽいものはSREへ」という雰囲気がありました。他のチームを攻めるわけではなく、我々のスタンスを提示できていなかったことに責任があります。
合宿では、SREの責任範囲として微妙だと思うことをブレストし、それぞれを今後どうしていくとSREらしくなるのかを議論しました。
今になって議事録を眺めてみると、かなりの割合を解決できたように思います。例えば「クラウドインフラを全部作り、運用してしまうこと」 → 「クラウドインフラの初期設計・構築・IaCのサポート」という部分ですが、現在Park Directにおける一部の架電業務を自動化するシステムの刷新を行っていて、その中で実践しています。
刷新プロジェクトはそのシステムのメンテナーになっているチーム + SREチームから1名が参加しており、一例ですが以下のようにタスクが分担されています。
■メンテナーチーム
・コアとなるAmazon Connect系のリソースの移行
・IaC化されていないLambdaの手動移行
・架電システムのアカウント管理
・DEV環境での動作検証
■SREチーム（1名）
・AWSアカウントの初期設定
・VPCやRDSなど周辺リソースの構築
・Amazon Connectのインスタンス管理
・IaC(SAM, Terraform)のサポート
・アーキテクチャ改善やコスト最適化の提案
1年前ならSREチームが全て担当していてもおかしくないのですが、メンテナーとなっているチームの協力もあり、（まだ曖昧な部分があったり速度重視で例外的に担当することもありつつも）SREの責任範囲を少しずつ定められていると感じています。
課題2:SREとしてこれができていると良いという基準がなく、目指すエンジニア像/チーム像が曖昧
こういうときは巨人の肩に乗るに限ります。SREにおける巨人とはGoogleのことですね。合宿ではSRE チームの評価に役立つレベル別チェック リスト | Google Cloud 公式ブログを埋めてみて、自分たちができていない項目を明確にしました。
1年経過した今、いくつかチェックを付けられるものが増えています。例えば基本レベルのSLOとインシデント管理プロセスは2023年前半から取り組み、現在ではかなり枯れてきています。インシデント管理プロセスはSREではなくQAチーム主導で行ったのですが、ポストモーテムなどSREのエッセンスもしっかり入っています。
SLOという拠り所がない状態から脱却できたのは特に大きい出来事で、優先度やリスクをSLOベースで判断するということができつつあります。個人的にSREチーム立ち上げから今までで最も大きな変化だと思っています。
課題3:独立したSREチームとして活動を続けていいのか、それともembeddedなど他の実践パターンを取ったほうがいいのか
合宿の際は「例えばプロダクトがもっと増えたとき、横断的SREってどうやればできる？」程度の話題で、出向形式（embedded）よりも必要に応じて他プロダクト/チームに首を突っ込んでいきましょう程度の議論しかできなかったので、この1年でどう効果が出たのかというのは言いにくいのですが、現在もっと大きな課題として顕在化しつつあり、チームの重要テーマになっています。
SREチームに集中してしまったインフラ系のスキル/ナレッジを他のチームにどう展開していけばいいのかという課題です。イマ風に（というかチームトポロジー風に）言えばスキルのイネーブルメントでしょうか。SREにイネーブリングチームのエッセンスを入れていく必要があると感じています。
課題1とも関連性がありますが、ある領域のスキルが特定のチームに依存しすぎるのを個人的に非常に危惧しています。特にクラウドインフラやコンテナ、IaC、監視といった今ではソフトウェアエンジニアにとって一般的となったスキルが身に付けづらいのは、率直に言うと離職に繋がる大きな要因になると思っています。今年SREチームにジョインしたメンバーにも、転職の動機はクラウドインフラに触れる機会の少なさだったという方がいて、本当に他人事ではないなと感じています。もちろん離職リスクの問題だけではなく、インフラ領域のスキルイネーブルメントがプロダクトの質やリリース速度に寄与し、ひいてはサービスとしての価値向上に繋がると思っています。
この課題については来年あたりに真面目に向き合うことになると予想しており、今は少しずつ足元から固めようとしているところです。
おわりに
かなり長い記事となりましたが、お付き合いいただきありがとうございました。
ニーリーのSREチームはコロナ禍に発足したチームで、正直リモートでも全然コミュニケーションできていると思っていたのですが、やはり対面でミーティングしてみると普段よりも明らかに円滑に進行できている感覚がありました。もちろん比較はできないですが、オンラインで同じ議題を話してもここまで濃厚な議論はできなかったのではないでしょうか。
入念な事前準備と目的の明確化によってクオリティの高い議論が生まれたと思っていますので、次回以降もそれは継続しつつ、少しラフなセクションも設けて少し緩急を作るのがいいかなと思っています。ずーっとミーティングはさすがに疲れました・・・。
すでに今年もSRE合宿に行こうという話が出ており、ミーティング以外のセクションとしてペアプロ的な取り組み(前述したスキルイネーブリングをまずはチーム内でやっていこうという背景があります)など、新しい試みを取り入れようと考えています。
ぜひ恒例行事にしていきたいですし、他チームにも合宿のノウハウを展開できたらいいなと思っています。次回のレポートもお楽しみに！
株式会社ニーリー プロダクト開発本部 プラットフォーム開発グループ SREチーム/QAチームリーダー
菊地 弘晃 Hiroaki Kikuchi
2017年、DMM.comに新卒入社。動画配信事業部にてVR動画、4K動画のローンチに携わるほか、動画分散エンコードシステムの開発、動画プレイヤーのUI/UX改善などを担当。2021年11月に株式会社ニーリーにジョイン。Park Direct開発部SREチーム/QAチームのリーダーとして従事。