スタディサプリ Product Team Blog

株式会社リクルートが開発するスタディサプリのプロダクトチームのブログです

SRE チームを支えるふりかえりの文化

こんにちは。SRE チームの@chaspy です。

本記事では私の所属する SRE チームにおける「ふりかえり」の文化を紹介します。

背景

最近のチームのふりかえり会 *1 で僕自身が以下のようなコメントを"Keep"として出しました。

f:id:quipper-ja:20220221112204p:plain

これは、単にこのふりかえり会が継続している、という意味に留まりません。あらゆる物事に対してふりかえりが行われ、改善サイクルが高速に回っていると感じます。それはチームメンバー全員が以下の価値観で仕事を進められているからだと思います。

  • あらゆる問題、取り組み、事象について「それは本当に必要か?」「それはなぜやるのか?」といったことを問うことができる。いわゆるクリティカルシンキング
  • あらゆる問題に対して、建設的・前向きに、他者や何かを否定することなく、より良い案を言葉にして提案できる。建設的思考。blameless。
  • やることにコストがかからず、やらない理由が見つからないのであればまずはやってみることに前向きである。やってみてダメならすぐにやめる。

これらは SRE チームの 4つの Value の中の Fail smart や Learning も関係していると思います。失敗を良しとするから挑戦できるし、学習する姿勢があるから絶えず批判的であれると思うからです。

「ふりかえり」が見える場面

それでは「ふりかえり」が文化として見られる具体例を紹介します。

Team Retrospective

いわゆるふりかえりです。

隔週金曜日、1時間、miro を使い、KPT 形式で行います。

f:id:quipper-ja:20220221112236p:plain

目的は チーム活動の良いことと問題を共有し、良い点は継続、問題は解決するための意見を集めるため です。

現在は事前に出来事、Keep、Problem を各自記入し、当日はそれらを各自が共有、そして共有された他のコメントに対して思ったことを共有、そして Problem に対する Try を検討します。

ファシリテーターはローテーションになっており、上記のような型が決められ miro の board 上に記載されています。

中でも、「ふりかえりのふりかえり」という枠を途中から導入し、ふりかえり自体のやり方についても意見を交わすようになりました。例えば以前は事前記入ではなく、当日全員で記入していました。参加者は最大8名と少なくないため、コメントを非同期で付箋で行ってはどうか、などの提案がされたりもしました。

ファシリテーターをローテーションすることと、ふりかえり自体を振り返っていることで自分たちのチームに最適なふりかえり会に少しずつですが変わってきているように感じます。

Working Agreements

チームで働く上で「同意」する事項を共有します。現在は3ヶ月に1回の定例会と、トピックに応じて別のミーティングで行ったりしています。

以下が目的です。

  • チームが協力して成果を出すための文化規範を形成する
  • 新しくチームに参画した人の立ち上がりをサポートする
  • Quarter ごとに見直すことでチームが学習する機会を作る

「同意」とあるのがポイントで、ルールとは少しだけニュアンスが異なります。

Atlassian の記事を引用すると、As a team, create a list of expectations of each other so you can work together successfully and avoid misunderstandings that may come up. とあるように、お互いの「期待値」を明文化するのが大切だと思います。

例えば Pull Request Review。仮に30分以内に見てほしい期待値の人と、3日以内に見ればいいという人がいたとして(あえて極端な例を述べています)、それらの期待が暗黙であればチームコラボレーションはうまくいきづらいでしょう。

以下のような分類で話し合われています。

  • 働き方
  • 尊重する文化
  • コミュニケーション
  • ミーティング
  • タスク管理
  • ふりかえり
  • Pull request review
  • Alert handling
  • Developer support
  • Cost review
  • Incident Response
  • Working Agreement 自体のふりかえり

f:id:quipper-ja:20220221112255p:plain

最初はそれぞれが思う期待値を共有しました。そこでこれってどうなっている?と期待値が異なるものについては別の会で議論をし共通認識を作ってきました。

一定期間が経過した後に再実施して、変化がないものについては「期待値の同意事項」として、ストック的に issue に添付しています。

f:id:quipper-ja:20220221112309p:plain

「文化」とはある規模のコミュニティにおける、1人1人の行動の積み重ねです。そしてその行動は思考に左右されます。メンバーの期待値を共有することで、お互いが気持ちよくコラボレーションできる行動をそれぞれができるようになります。

この会をはじめてから、定例の会以外にも「ミーティングの頻度や目的を見直したい」「コーディング面接の採用言語について議論したい」という個別のトピックの提案がなされ、議論を深めることができています。

Monthly Issue Planning

毎月、今月フォーカスすることを話す場です。

目的は チームが同じ方向を向くために現在感じている課題を共有する です。

以下のようなトピックが話されます。

  • 先月の課題で解決されたこと、されなかったこと
  • 最近課題に思ってること / チームとして取り組んだほうが良いと思うこと
  • 今月フォーカスすることと、そのためのタスクリスト

Team Retrospective と一部話題は重複しますが、こちらは「大玉」と呼ばれる規模・期間が長い、各自がフォーカスして解決するタスクにより重きを置いて話されます。

SRE チームは問い合わせやアラート対応などの差し込みが多く、扱う業務領域も広いため、一定期間何にフォーカスして、何にフォーカスしないかを共有し、解決すべき課題の期待値をお互いに合わせることはチームとしての成果を大きくすることに繋がっていると思います。

もちろん、この会自体で話される内容も常に見直され、改善されています。

Daily Standup

毎日、17時半から30分間、各自がやったことを共有する場所です。また、チームとして見落としてはならないもの *2 を一緒に見る場所でもあります。

目的は以下です。

  • 各メンバーが何をやっているのかを知ることで、業務をより円滑に進めるため
  • チームとして確認すべきものを見落とさないように確認し、対応方針を話すため

ファシリテーターはローテーションされており、Spreadsheet に基づいて自動で Slack に通知されます。

f:id:quipper-ja:20220221112325p:plain

f:id:quipper-ja:20220221112335p:plain

流れは以下です。

  1. GitHub Project board を asssign ごとに check
  2. 新規の Issue を共有、必要であれば assignee を決める
  3. Alert check on dashboard
  4. #sre-ask-sre *3 を見て本日の問い合わせを共有する
  5. (Tuesday) Datadog Monitor Trends を眺める

Alert や問い合わせは通常「気づいた人がやる」ことになり、業務知識が偏り属人化したり、業務負荷が偏ったりする恐れがあります。

全員が同じものを、同じ時に見ることで、適切な割り振りを行いつつ、必要な知識の共有ができているように感じます。

Monitor Trends を週次で見ることで、多くきているアラートにフォーカスして対応することができるようになり、以前に比べて最小限の労力で対応できているように感じます。

おわりに

私たち一人一人は扱う領域も、業務の種類も、経験してきたバックグラウンドも、そして価値観も異なります。そして周囲の環境も、私たち自身の価値観も少しずつ変化し続けます。

こういった状況でも安定してチームのパフォーマンスを出し続けるには、お互いの期待値を確認し合い、起きた物事に対して向き合い、改善し続けることが重要です。

柔軟に変化に対応し続けられる反脆弱性*4 のようなものがチームを強く、持続可能にしていると感じます。ふりかえりの文化はそれを表していると思います。

スタディサプリでは世界の果てまで学びを届けたい仲間を募集しています。

SRE

brand.studysapuri.jp

Product Security Engineer

brand.studysapuri.jp

宣伝

3/12 のイベントで登壇します。

blog.studysapuri.jp

*1:Team Retrospective と呼んでいる

*2:アラートや他チームからの依頼

*3:問い合わせがあったら特定の reaction をして、reacji を設定しているチャンネル

*4:詳しくは https://www.diamond.co.jp/book/9784478023211.html を参照