SREチームとして持続的に信頼性に向き合うための開発プロセス改善

■イベント
持続可能で柔軟な開発プロセスの実践
https://sansan.connpass.com/event/309010/

■発表者
Eight Engineering Unit SRE グループ 武井 健吾

■Eight エンジニア 採用情報
https://media.sansan-engineering.com/eight-engineer

Transcript

1. Sansan株式会社 部署 名前 SREチームとして 持続的に信頼性に向き合うための 開発プロセス改善 Eight Engineering Unit SREグループ 武井 健吾
2. 武井 健吾 Sansan株式会社 技術本部 Eight Engineering Unit SRE グループ - 2017年4⽉にメーカー企業に新卒⼊社。Windowsデスクト ップアプリの開発2年、Webアプリの開発1年半ほど 経験。 - 2020年9⽉にSES企業へ転職し、AWSエンジニアとして 様々な業種のシステム構築案件に携わる。 - 2023年5⽉にSansan株式会社に、Eightのインフラエンジ ニアとして⼊社し、Eightの運⽤とインフラの改善へ従事。 - 2023年10⽉からはSREグループとして、Eightの 信頼性向上のための活動も⾏う。
3. - Eight の SREグループの基本情報 (前提) - SREグループの状況と開発プロセスにおける課題感 - 開発プロセス改善にむけて実施したこと - 結果 - 今後への展望 アジェンダ 2
4. Eight の SREグループの基本情報
5. Eight の SRE グループの基本情報 2023年10⽉に旧インフラグループから名称変更 - 旧 インフラグループ 5名 + 開発チームから1名 SRE グループの主な役割 1. プロダクトの信頼性向上に向き合う > CUJ (Critical User Journey) の定義、CUJ から派⽣する監視の設定と運⽤ (SLI / SLO) > レガシーを撤廃し、柔軟なシステム構成へ 2. インフラグループ時代からある他チームからの問い合わせへの対応 > DNSレコード登録、IPアドレス追加....など 元々の開発スタイル - スクラム？？ - 問い合わせへの対応も計画に含められるように、スプリントを短め (1週間) に設定 4
6. SREグループの状況と 開発プロセスにおける課題感
7. SREグループの状況① 6 1週間スプリントの⽉曜に1.5時間を使って、以下のイベントを実施 (フリリファプラと呼んでいた) - ふりかえり - リファインメント - プランニング その結果、、、、 - 短いリファインメントの中で、タスクを明確にすることが困難 - プランニングが、各々今週着⼿するタスクを宣⾔をするだけで、 計画するイベントとは⾔い難い (最後の2,3分くらいしか時間が取れていない) ⇒ イベントの時間内でタスクの進め⽅を深く議論できず、作業者のみタスクの内容を 把握している (属⼈化)
8. SREグループの状況② 7 Issue として取り扱うタスクが⼤きかった - 対応者が作業できるように Issue を切り出していたため、1つの Issue に記載する タスクが⼤きくなりがち その結果、、、、 - 起票者 = 対応者となりがち - 起票者だけがタスクの背景を深く理解している - 何週にも渡って Issue が残りつづけることが常だった - ⼀応スプリントという概念はあったが、「スプリントでやり切る」という考えが なかった ⇒ 何週にも渡ってタスクが残っており、1スプリントでチームが提供できた価値がブレる ⇒ 完了できたものが価値となるのではなく、予め計画した価値を届けたい
9. - 状況①: 計画のための時間が短すぎる - タスクを明確にしきれず属⼈化 - 状況②: Issue として切り出すタスクが⼤きすぎる - 1スプリントで消化できず、チームが提供した価値が週によって ブレる 開発プロセスにおける課題感 8 - 課題：SRE のチームとして「システムの信頼性」を持続的に向上させることが 困難 - メンバーの⼊れ替わりや、病⽋などで作業が⽌まる - 1つのタスクが⼤きいと、外部要因(依頼・インシデント対応) で 価値を全く提供できないスプリントが発⽣する
10. 開発プロセス改善に向けて実施したこと
11. 対応 10 対応内容 - タスクの粒度を再定義 - スクラムイベントの分離 前提 - SRE グループへの問い合わせへの対応は、今まで通り対応していく - なるべくストレスなく開発プロセスを移⾏する - ツールなどは変えない
12. 対応：タスクの粒度を再定義 11 Issue として切り出すタスクを以下の2種類で再定義 - PBI (Product Backlog Item)：1週間以内に終えることができ、価値を与えることが できる単位 - タスク量に対してポイントをつけることで開発速度 (=ベロシティ) を可視化 - ベロシティを元にプランニング段階で、今週どこまで価値を提供できるか ⾒積もれる => SRE グループが提供できる価値を安定させる - SBI (Sprint Backlog Item)：PBI を達成するためにタスクを細分化したもの - プランニング時にチーム全体で話し合い、PBI から細分化を⾏う - より細かいタスクとなり、事前にチームと話し合っているため、属⼈的に なりにくくする => 属⼈化の排除
13. 対応：スクラムイベントの分離 12 各イベントの⽬的どおりに機能させる - リファインメント：タスクのゴールを明確に定め、タスク量を⾒積もる - プランニング：スプリント内で提供できる価値の決定、タスクの計画 (PBI から SBI へ切り出す) - ふりかえり：次のスプリントへの改善活動をより重視 => 未来に対する話し合いを⾏う時間を増やす - タスクに対する認識をチームで合わせる - 開発プロセスを継続的に改善させる
14. 対応：SRE ならではの対応 リファインメントの時間を毎朝15分設定 - SRE グループは各⽅⾯ (開発チーム、ビジネスサイド) からの依頼に ⽇々対応が必要 - 依頼も Issue として積まれるが、依頼によっては 週1回のリファインメン トで SRE が明確にしきれず、次のスプリントで計画できない - その⽇のうちに明確にしきれないことがあれば、依頼者に確認を⾏い 次の⽇に再度リファインメントを実施する => 依頼対応と、SRE としての価値提供の両⽴を実現 13
15. 結果&今後への展望
16. 結果 15 安定して、価値を提供することができるようになってきた - PBI を「1週間で完了できるタスク」と定義したため、スプリント終了 時点で「何も Issue がやりきれていない」状態を回避 - プランニング時点で、過去のベロシティを参考にすることで、 事前に提供できる価値を計画 属⼈化排除の⼀歩を踏み出せた - 細かくリファインメントを取ることで対話時間が増え、 知識が全体に共有され始めた - SBI をチームで出し合うことで、⼀つのPBIに対して複数⼈が 取り掛かることができ始めた
17. 今後への展望 16 とはいえ、まだまだ課題はある - ベロシティが安定しない - プランニングで計画したPBIすべてをやりきれないことが多々ある - 属⼈化を完全に排除できたとは⾔い難い - やっぱり個⼈任せなところもでてくる - スクラムイベントと、作業時間のバランスが掴みきれてない - リファインメントの時間まだまだ⾜りないけど、 これ以上作業時間削れない、というジレンマ => 今後の開発プロセスに焦点を当てた”ふりかえり” で、どんどん改善中！
18. さいごに
19. さいごに 18 SRE という少し特殊なポジションの場合、 世間⼀般的なスクラム開発の⼿法に合わない点もあったりします。 私たちも「この⼿法で⼤丈夫なのか」と不安になりつつも ⽇々改善を努めています。 そこで、ぜひとも皆さんの開発プロセスにおける経験、 アドバイスをいただけると幸いです！
20. Eight Engineering Unit 募集ポジション紹介 https://media.sansan-engineering.com/eight-engineer