ZOZO プラットフォームSREとコロナ禍におけるチームリーディング術
本記事はZOZOテクノロジーズ アドベントカレンダー#2の25日目の記事です。
こんにちは。ZOZOテクノロジーズのそのっつです。ZOZOテクノロジーズではSREスペシャリストという肩書で、プラットフォームSREチームのリーダーとMLOpsチームを兼務で担っています。
約一年前の2020年1月に SRE Next 2020 にて ZOZO MLOps のチームリーディングとSRE (Engineering) というタイトルで私のチームリーディング術についての発表を行いました。それから約一年が経とうとしているので、一年の振り返りの意味も含めて、アップデートしたいと思います。
- チームとしての方向性を定義する
- スムーズなプロジェクト進行
- 心理的安全性
- リーダーがボトルネックにならないようにする
- メンバーがスキルアップできる環境であること
- フェーズによって柔軟に変える
- 技術力でぶん殴る、細部に神は宿る
- 規約とガイドラインを明文化する [TRY]
- チームをユニットに分け、案件を任せる [TRY]
- KPT(A)、1on1
- チーム、ユニット朝会
- Discordで「話しかける」、リモートペアプロ
- 分報(times)チャンネル
- Coffeeチャット
- Nike Training Club
- 他チームとのリモートランチ、リモート飲み会
一年間の変遷
この１年で私にとっての一番大きな変化は、4月にプラットフォームSRE (以下 PF-SRE) チームというものを発足して、MLOpsチームと兼務でチームリーダーをやり始めたことです。それぞれのチームで何をやっているか簡単に言うと以下になります。
- MLOps (2019/04発足): ML案件のインフラ、GCPメイン
- PF-SRE (2020/04発足): ZOZOTOWNのマイクロサービス化リプレイス、AWSメイン
MLOpsチームは４名程度の規模だったのですが、PF-SREチームは当初から8名という大所帯(現在は10名)で、適切なチーム人数と言われる Two Pizza Rule の8人を超えてしまい、チーム運営のやり方を変えていく必要がありました。
また、2020年2月頃からCOVID-19によって週5リモートワークに代わり、その中で如何に効率を落とさずにチームとして働くかを模索していく必要がありました。
本記事では、小さなチームから、大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかを記載していきたいと思います。
チームリーディングで気をつけていること
私がチームをリードするときに気をつけていることは、約一年前に発表したZOZO MLOps のチームリーディングとSRE (Engineering)と大枠は変わっていません。ただし、扱う案件とチームメンバーが増えた結果、変えた方が良いと判断したことがいくつかあります。そのように新しく導入した仕組みについては [TRY] ラベルを付けて共有します。
- チームとしての方向性を定義する
- スムーズなプロジェクト進行
- 心理的安全性
- リーダーがボトルネックにならないようにする
- メンバーがスキルアップできる環境であること
- フェーズによって柔軟に変える
- 技術力でぶん殴る、細部に神は宿る
- 規約とガイドラインを明文化する [TRY]
- チームをユニットに分け、案件を任せる [TRY]
チームとしての方向性を定義する
なぜわざわざチームを作ったのか軸がブレないようミッション（目標）を定義してメンバーに共有しています。メンバーの意思が統一され良い効果があったため、本年度 PF-SRE チーム発足時にも同じことを行いました。
この図は、「 THE TEAM 5つの法則」からの引用ですが、この本では目標には
- 意義目標: 最終的に実現したい抽象的な状態・影響を表す
- 成果目標: チームとして手に入れるべき具体的な成果を示す
- 行動目標: メンバーが取り組むべき具体的な行動の方向性を示す
の3種類があるとしています。行動目標は具体的で分かりやすいという利点がある一方で、手段が目的化されてしまう懸念があります。そこで、ミッション(意義目標)を共有することでチームの方向性を示し、その意義を達成するための手段をメンバーに自発的に考えてもらうことができます。
私のチームでも、これに倣って目標を設定しました。具体的に MLOps チームおよび PF-SRE チームの目標をどのように定義したのかを以下に載せます。
MLOps チームの目標
ミッション (意義目標)
- MLエンジニアが優れたモデルを作ることに注力できるようにする
- 特にプロトタイプからプロダクションレベルへの引き上げフェーズで成果を発揮する
成果目標
- Phase1: ML機能を１つプロダクションに出す
- Phase2: ML機能を複数プロダクションに出す
- Phase3: ML機能の量産体制を整える, e.g., ML基盤 ← イマココ
行動目標
- キーワードは「プロ意識を持つ」
- 期ごとの目標は個人ごとに立ててもらう（もらいたい）
PF-SRE チームの目標
ミッション (意義目標)
- 凄まじい勢いで成長してきたZOZOTOWNは、システム的にもレガシーな部分が存在しています。我々は、ZOZOTOWNがこれからも成長を続けるために、 開発効率・運用性・拡張性・柔軟性・回復性の確保を見据えて、技術面でも環境面でもクラウドネイティブに刷新するための取り組みを進めます。巨大でピーク性のある大規模ECシステムを、最適なアーキテクチャをチームで思い描きながら設計・構築・リリース・運用まで一環して行い ZOZOTOWN の成長を加速させることがミッションです。
成果目標
- Phase1: プラットフォームの型を作る ← イマココ
- Phase2: マイクロサービスを複数プロダクションに出す
- Phase3: 複数マイクロサービスを同時進行でプロダクションに出す
行動目標
- キーワードは「プロ意識を持つ」
- 期ごとの目標は個人ごとに立ててもらう（もらいたい）
プロ意識を持つ
ここで、両チームの行動目標を「プロ意識を持つ」としていますが、私の考えるSREのプロ像とは以下のものだと定義して目線の高さを合わせました。
社内の期待を裏切らない
- 期日を守る (当たり前)
レベルの高いインフラを構築できる
- 技術選定が妥当である
- 安定している
- 十分に高速
- 負債の少ない
- 開発体験の良い
- 運用コストが小さい
スムーズなプロジェクト進行
私が案件を進める時には、以下のように調整してスムーズにプロジェクトが進むように腐心しています。
調整ごとは早めにしておく
- 仮予約 — まだ本決まりしていないが、そんな依頼をするかもとジャブを打っておく
プロジェクト進行上のボトルネック(クリティカルパス)を潰す
- 依存があるタスクをなるべく作らない
- 作業を止めるよりは次善の策を捻り出して進める
- 他のチームに依頼を出さずにすむような業務フローの設計
心理的安全性
界隈でもよく言われる「心理的安全性」には気を付けています。ただ、COVID-19によりフルリモートになり、コミュニケーションを取りにくくなったため難易度が上がったように感じています。フルリモートにおける工夫については、下の章で別途述べたいと思います。
思いついたら即相談
- 朝会や定例を待たずに、(Slackでも良いので)すぐ聞いてと言ってある
仕組み(orコード)を憎んで人を憎まず
- レビューの指摘は、あなたを非難しているわけではない
- ミスがあった時も、仕組みでカバーできないか考える
わからないことは聞ける雰囲気
- 新しい技術やツールをメンバーに先に調査してもらって、むしろリーダーが教わる
- リーダーでもわからんものはわからん → 皆わからんものは質問しやすい（はず？
- あとは、馬鹿な話をするなど(オヤジギャグなど
リーダーがボトルネックにならない
リーダーである私がボトルネックにならないように気をつけています。特に「必須なタスクは握らないようにする」というのは、一年徹底できたと思います。
一方で、扱う案件とチームメンバーが増えて、ミーティングの数が増えたため、タイムリーにメンバーの相談に乗ってあげることが難しくなってきたと感じました。そこで、技術力のあるメンバーに Tech Lead を任せて、技術的な相談先を委譲することで私がボトルネックにならないようにしました。これは、Tech Lead を任せられるメンバーがいたという幸運もあってはじめて取れた手段だと思っていて、大変助かっております。
(特に) コードレビュー
- 最低一人の Approve は必須。リーダーの Approve が必須なわけではないのがミソ
- GitHub Scheduled reminders 機能を利用してレビューワにアサインすると DM が飛ぶようにルール化
リーダーは必須な(実装)タスクを握らない
- ミーティングが多くて進まないことがある
- 自分がボトルネックにならないようにタスクに集中すると、今度はリーダー業が疎かになる
- 急な差し込みがあった場合の余裕も持てる
タイムリーに相談に乗る
- 分報(times)チャンネルでの疑問つぶやきを拾って答える [TRY]
- Tech Lead に技術的な相談先を委譲する [TRY]
メンバーがスキルアップできる環境
主に1on1を通して、どこにモチベーションがあるのか、何にストレスを感じているのか摺り合わせを行い、できるだけ本人のキャリアプランに沿うようにタスクをアサインしています。業務上必ずやらなければいけないこともあるため、そこのバランスを上手く取らなければならず難易度は高いです。
スキルアップできるような機会を与えることも重要だと考えていて、案件ごとのリーディングを委譲することで、リーディング力を鍛える機会を設けるなどの工夫もしています。
モチベーションコントロール
- やりたい仕事とチームの仕事が一致しているか
- 目標 x 報酬
- 1 on 1 でのヒアリング
コーチング
- 当たり前のレベルを引き上げる
フェーズによって柔軟に変える
新チーム発足や、COVID-19によるフルリモートワークが最たるものですが、フェーズによってハマるやり方は異なるので、適切なタイミングで適切にやり方を変えるのが信条です。
- 例) 開発フェーズではスクラムで良かったが、運用フェーズに入ると割り込みが増えてスクラムが機能しなくなってきた
- 例) 小規模の時は、全員が全てを見ることができたが、大規模になってきたら、専門職でチーム分けをしないと上手く回らなくなってきた
挑戦してみてダメならすぐ辞めるようにして、試すコストを小さくしています。
本記事で記載している [TRY] の部分がそのまま、この項目の結果を表していると思うので、引き続きご参照ください。
技術力でぶん殴る、細部に神は宿る
プラクティスも良いけど、とにかく技術力を持てという派です。SREのやり方をなぞっても技術力が伴っておらず問題解決できないのであれば意味がないと考えています。
チーム目標においても「プロ意識を持つ」ことを掲げていて、システムを安定化させるためには、細部を追う技術力をメンバーに身につけて欲しいと思っています。
- SREのプラクティスだけ真似してもダメ
- アーキテクチャだけ良くてもダメ
- 細部を追う技術力も必要
技術力でぶん殴れるレベルにまでメンバー全員を引き上げるのは大変ですが、Tech Lead にアサインしたメンバーと一緒に、この目標は追い続けていきたいと思っています。
規約とガイドラインを明文化する [TRY]
チーム規模が小さい時は、ペアプログラミングしたり、私が書いたコードを読んでもらって、背中を見せながらチームをリーディングできていましたが、人数と抱える案件が増えるに連れて、その時間を確保するのが難しくなってしまいました。SRE Next 2020 の時には「ルールより文化」としていた理想の実現が難しくなってしまいました。
文化として染み付かせるには時間がかかると感じていて、しかし染み付くまで無法地帯にするわけにもいかないので、規約とガイドラインを明文化して、ドキュメントに働いてもらうように整えることをはじめました。2020/12/25現在で、以下のチーム内ガイドラインを用意しており、徐々に増やしていこうと思っています。なお、この他にも全社的な技術ガイドラインを整える動きもあります。
- PRテンプレート
- セール前負荷対策チェックリスト
- 1on1テンプレート
- 負荷試験 虎の巻
- レビュー 虎の巻
- スクリプト規約
- 1password保管庫命名規則
- Slackチャンネル＆グループ命名規則
- k8sマイクロサービス命名規則
- AWSリソース命名規則
チームをユニットに分け、案件を任せる [TRY]
チームで扱っている案件を、チームのメンバー全員が把握していて、お互いに助け合ったりレビューをしあったりできるような状態、を理想としています。ですが、PF-SRE チームで扱う案件の数が増えて、全員が全てを把握できるかというと、実際のところ難易度が高くなってしまいました。
そこで、PF-SREチームをユニットという単位に分けて、ユニット内での理解度は高く持てるように工夫しました。このユニットは、逆コンウェイの法則に則り、マイクロサービスプラットフォームのマイクロサービス単位で構成するようにしています。現在は、PF-SREチーム内に３つのユニットが存在していて、１つのユニットが大体２つの案件（マイクロサービス）を抱えており、ユニットで担当するマイクロサービスと人数規模は徐々に増えていくと想像しています。これは Google の SRE 組織のあり方を模範にしていて、将来的にはユニットがチームとしてスピンアウトする可能性もあると考えています。
案件ごとにメンバーにリーダーを担ってもらうことで機会を与えリーダーとしての育成も進めています。特に、MLOpsチームに関しては、2020年4月時点から @dama_yu に案件リードを担ってもらい、2020年10月時点からチームリーダーを任せることができるようになりました。また前職時代のそのっつチームのメンバーだった @Civitaspo も入社してくれ MLOps チームの Tech Lead としてのロールも委譲することができました。
PF-SRE チームをユニットには分けたものの、理想であるプラットフォーム全体を把握している人間が自分以外にもいて欲しいと思っていて、@yokawasa には PF-SRE の Tech Lead としてその役目を担ってもらっています。
フルリモートにおける工夫
本章ではフルリモートに適合するために、どのような施策を行ってきたのか紹介したいと思います。
PF-SREチームを発足したばかりのタイミングでCOVID-19により週５日のリモートワークになり、コミュニケーション不足になる懸念がありました。今までオフィスで働いていた時は、MTGを減らして作業時間を増やす方向で調整をしていたのですが、今年度はあえてMTGや雑談の時間を設けてコミュニケーションの時間を増やすようにしてきました。
- KPT(A)、1on1
- チーム、ユニット朝会
- Discordで「話しかける」、リモートペアプロ
- 分報(times)チャンネル
- Coffeeチャット
- Nike Training Club
- 他チームとのリモートランチ、リモート飲み会
KPT(A)、1on1
KPT(A) と 1on1 はフルリモート以前から続けています。弊チームにおいては、KPT(A) と 1on1 が肝となるもので、以降で述べている手段はほとんど全て KPT(A) もしくは 1on1 で出てきた Action です。KPT(A)と1on1は大体隔週で交互に開催しています。
特に、COVID-19でフルリモートに切り替わった最初の頃は、フルリモートでの働き方に慣れず体調を崩すメンバーや、チームメンバーとの会話が少なくなり不安を感じるメンバーも出てきたため、KPT(A)や1on1で意見を吸い上げてチーム運営に反映することはとても重要でした。
チーム、ユニット朝会
当初はチームでの朝会のみを行っていたのですが、徐々に人数と抱えている案件が増え、チーム全体の朝会だけでは時間が長い割には情報が希薄であるという問題が発生し始めました。
そこで別途、PF-SREチーム内のユニットごとに朝会（ないしは夕会）を実施するようになりました。なお、こちらの会は、基本的にユニットリーダーに任せており、チームリーダーである私は参加しないことにしています。全てのユニット朝会（夕会)に参加していると時間がいくらあっても足りないためです。
Discord で「話しかける」、リモートペアプロ
弊社ではリモートワークで気軽にメンバーに話しかけることができるようにDiscordが導入されました。
Discordの個人専用ボイスチャンネルに常駐してもらうことで、そのチャンネルに入ればすぐに話しかけることができます。オフィスにいたときの「話しかける」を再現できるのではないかと、当初MLOpsチームと福岡研究所で実験的に導入を始め、その後全社展開されました。
また、フルリモートになった当初はペアプログラミングをどのように実施すべきか悩んだのですが、色々試行錯誤した結果、単純な画面共有や、VSCode の Live Share 機能を使うと上手く出来るというノウハウが溜まってきており、今ではリモートでのペアプログラミングを推奨しています。
WEAR部のメンバーが書いてくれた記事ですが、こちらの記事に詳しく書かれています > DiscordとVSCodeを使ってリモートワークで快適にペアプロをする話
分報(times)チャンネル
一昔前に、分報(times)チャンネルという取り組みが流行りました。
Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ〜Problemが10分で解決するチャットを作ろう
PF-SRE チーム発足時、フルリモートでのスタートとなり、コミュニケーション不足に陥ることが想像できたので、半ば強制的に全メンバーに times チャンネルを開設させ、つぶやきを書いてもらう Try を実施しました。
個人に話しかける場や、作業ログを書く場、ブログ記事を共有する場、としてのコミュニケーション促進に役立っています。特にミーティングばかりで Discord に常駐できないようなリーダーが、メンバーの困りごとを吸い上げる場所としての効果はとても高いと感じています。
Coffee チャット
週2でCoffeeチャットという、雑談する機会を設けた。結果的に、相互理解が深まった。
こちらのメルカリの記事を参考に、弊チームでも Coffee チャットという雑談をする時間を週２回30minずつカレンダーに登録して、意図的にコミュニケーション機会を増やしました。チームを発足したばかりだったというのもあり、相互理解に役立ったと思います。
正直なところ、徐々にマンネリ化しているような気もしていますが、新しいメンバーが入るタイミングでまた活性化してコミュニケーションに役立っているように感じています。ちょっと前は鬼滅の刃の話題で盛り上がっていましたね。
Nike Training Club
MLOpsチームのみでの取り組みとなりますが、フルリモートになり出勤すらしなくなり運動不足が懸念されたため、週に1回 30min で YouTube のトレーニング動画を見ながら運動をする会が設けられました。筋肉はいいぞ 💪
他チームとのリモートランチ、飲み会
以前は、新しいメンバーが入社した場合は、オフィスを巡回して紹介して回ったり、他部署のメンバーをランチに誘ったりしていたのですが、フルリモートになってから案件で関わらない他部署のメンバーと顔を合わせる機会が全くと言ってよいほどなくなってしまいました。
そこで、軽く断りを入れた上で、他部署のメンバーのカレンダーにリモートランチ会を勝手に登録して新メンバーを紹介するということを始めました。今はメンター役のメンバーに調整をしてもらっていますが、そのメンターもフルリモートが始まってから入社したメンバーだったりすると知り合いが少ないという課題を抱えているので、多方面からのお声がけもお待ちしております。
まとめ
大きなチームのリーダーに移り変わるにあたってどのような変化を進めていったのか、またCOVID-19におけるリモートワークにどのように適合していったのかをお伝えしました。
「フェーズによって柔軟に変える」というチームリーディング術を実践できていることを示せたのではないかと思います。また状況が変わったら柔軟に変えて行きます 💪
