はじめに
これは株式会社マクアケのアドベントカレンダー2023の17日目の記事です。
SREチームに所属する稲村です。
最近は久しぶりにランニングを再開して、よく走るようになったものの体力の衰えを実感しているもうすぐ四十路のおじさんです。
さて、今回はスクラム関連の記事です。
スクラムについては、私は完全なスクラム開発自体はほぼ未経験で、前職でもスクラム風な一部を省略する形でスクラムを実践してきました。
通常、スクラムのプラクティスを省略するのはアンチパターンと言われてスクラムバットと言うそうですが、まずはやってみる精神で進めていた状況でした。
スクラムについては、過去に下記の書籍を読んではいました。
弊社のSREチームには一年ほど前に入社したのですが、もともと完全なスクラムではないもの出来る限り近い形でスクラムイベントを採用しており、今もそれを少しずつ変えながら継続しています。
そんなスクラム風なアジャイル開発を進めながら1年経過して、良い点も悪い点も見えてきたので振り返ってみることにしました。
前提
まず、私の知識の前提は上述した通りで、弊社のスクラム開発（便宜上スクラムとします）は下記のような状況です。
まず、前提としてPOがおらず、また、最近ではスクラムマスターもチームリーダーの私がほぼ兼任しています。
ベストプラクティスとしては、兼任も一時的であれば問題ないができれば分けた方が良いと言われていますがチーム編成上、概ねこの状態で進んでいます。
とは言え、私がスクラム自体が不慣れなため、チームメンバーにフォローしてもらいながら進めています。
弊社SREチームメンバーは、私が入社1年ほど、且つ最近チームリーダーになったばかりの新米チームリーダー兼スクラムマスター、1人は私よりも長い年数在籍しているベテランメンバー、1人は若手の業務委託メンバー、1人は最近入社してきたベテランメンバーという合計4人の構成です。
スクラムイベント
スプリントは2週間で、スクラムイベントは下記を実施しています。
- 毎日のデイリースタンドアップ（朝会）
- 週次のリファインメント（次のスプリント準備）
- 隔週のスプリントレビュー（CTOとエンジニアリングリードメンバーが参加）
- 隔週のスプリントレトロスペクティブ（チームメンバーのみでKPT振り返り）
- スプリントプランニング（スプリント終わりとスプリント開始）
まず、2週間スプリントは概ね問題なく進んでいます。
差し込みが多かったりすると最終アウトプットの進捗が悪いことがあったためスプリントを1週間にする案もでましたが、スクラムイベントの負担等やスクラムの運用調整よりも、差し込みをできるだけ想定して今はプランニングするようになっており大きな課題なくうまくワークしているように感じています。
毎日のデイリースタンドアップ（朝会）
Slackのワークフローで毎朝昨日やったこと、今日やること、参加するMTG、共有相談事項を投稿してから朝会に臨んでいます。
最初に投稿するという仕組みは以前から導入されていましたが、MTGのアジェンダ同様、話すことが整理されるので良い取り組みだと感じています。
また、朝会後は、メンバーの相談事項や共有したいこと、チームリーダー会の共有を行う時間などに充てています。
以前は朝会後の話が長引くことで午前の時間がなくなるという意見もありましたが、今は比較的目的意識を持って取り組んでいることで、むしろ効果的に時間を使えているように感じています。
週次のリファインメント
もともとリファインメントは２週目の木曜日に実施していたのですが、1時間だとリファインメントの時間が不足し実際に走り出してみたら想定と異なっていたということが多くみられてたため、毎週実施するようになりました。
１週目のリファインメントでは、進捗を確認しつつ、下準備に充てています。
2週目にリファインメントを2時間やるよりも、1時間を2回やることで効果が出ていると感じていて下記のメリットがあると感じています。
- 1週目にリファインメントを進めて時間内で終わる範囲で実施することで、2周目のリファインメントでは残りだけ進めれば良い状態になっている（弊社ではJiraを使っていますが、Jiraでリファインメント済みのバックログにラベルをつけて、フィルターで除外して見やすくする工夫をしています）
- 単純に時間が倍になったので、詳細化するための議論が活発になった（メンバーに聞いたわけではないので個人的な感想ですが）
リファインメントに課題を感じている場合、単純に別日にも実施してみるのは結構オススメです。
入社したての頃はリファインメントが1時間で、準備しきれていないことが多くてチケット切ってなかったり、想定と異なることが多かったですが、メンバーからの意見で見直したことで結果良かったと実感できています。
隔週のスプリントレビュー
スプリントエンドで、CTOとエンジニアリングリードのメンバーを交えてレビュー兼デモ会を実施しています。
メンバー全員がレビュー兼デモ会で報告する内容をConfluenceの記事にまとめて、順番に報告しています。
SREではなかなかデモ出来るものがないので、スプリントの報告になることが多く、ここは課題感があります。
とは言え、ドメイン知識の高いリードエンジニアが参加していることや、多忙なCTOがいることでここで話を共有しやすいというメリットは最も大きく働いています。
隔週のスプリントレトロスペクティブ（KPT振り返り）
スプリントレビューのあとに、チームメンバーのみでKPTを実施しています。
普段Miroで実施しつつ、振り返りの中で出てきたチームの課題感などは、隔週で実施しているチーム内のMTG時間で話すネタとしてあげるようにしています。
また、具体的な課題などはチケットを切って対応しています。
これによりワーキングアグリーメントをアップデートしたり、改善できることを反映したり、コンテキストの共有などに充てています。
このあたりは試行錯誤しながらではありますが、ワークしてきつつあるようにも思っています。
スプリントプランニング
プランニングでは、前スプリントの振り返りと新しいスプリントの開始を実施しています。
リファインメントを2回やっているため、最終的に追加タスクがないかなどの微調整を行って、スプリントを開始しています。
前スプリントの振り返りではスプリントの進捗の良し悪しの要因を共有するようにしています。
スプリントの進捗という視点でみるので、それを踏まえて次のスプリントで実施するバックログ数を調整したりしています。
わかりやすいのは、祝祭日や有給の有無等によって変えることを意識しています。
実践して振り返ってみて（個人の観点）
過去にいくつかのSREチームを経験して思うことは、SREチームは直接顧客との接点が持ちづらく、また突発なアラート対応や相談などの差し込み対応も他のチームよりも比較的多い傾向にあるということでした。
前職の際にスクラム研修を受講した際に、SREやインフラエンジニアが中心のようなチームでスクラムイベントを当てはめるのが難しく課題感がある旨をお伝えしたところ、「スクラムがマッチしない可能性がある、スクラムは全てに当てはまるプラクティスではないので、マッチしていないならやめることも検討しましょう」と言われました。
逆に、スクラムによって解決できることもあるのでトライしてみることも提案されました。
そこでスクラム風なアジャイル開発を実践してきてわかったことがあります。
まず、個人的な観点でいうと、不確実性になりえることを理解することと、どの程度バッファをすると良いのかということをトライ＆エラーしながら模索するということです。
配属間もない場合、どういったことが不確実性高い事象になるのかがわかりません。
技術的な部分で言えば、技術のキャッチアップをするのか、メンバーにSlackで相談するのか、ペアプロしてもらうことで解決する可能性があります。
これはドメイン知識も同じで、コードから読み取れるもの読み取れないもの、ドキュメントで読み取れる部分があるのか、Slackで他チームで詳しい人を知るのかなどがあたります。
このあたりは入社直後は、積極的にSlackのtimesを活用して詰まっていることをつぶやくのもいいかもしれません。
Slackのtimesのメリット・ デメリットについて改めて考えてみる
家庭を持っていれば、家族の調整や子供の状況によっても変わるでしょう。
このあたりを踏まえて、タスクの見積もりを進めるのが良さそうだと今は理解しています。
ちなみにですが、以前「不確実性超入門」という書籍を読んだことがありますが、それを読んでから比較的突発的な差し込み対応については考えが変わったように思います。
特に経済の専門家が将来の予測をした際に全く予測から外れてしまっている事例を例に挙げて、
専門家の予測は、いつもほとんど当たらないのである
という不確実性を予測しきることの難しさについて書かれています。
また、
不確実性に対処するとか、あるいはリスクを管理するということは、必ずしも不確実性を除去したり、リスクを抑制したりすることと同一の意味にならない
という点から、もちろん不確実性を下げる行動は大事だが、それよりも不確実性があることを前提に行動や想定をするのが重要であると考えており、普段のリファインメントでも意識するようにしています。
実践して振り返ってみて（チームの観点）
チームという観点からも考えると、最近チームリーダーになってよく思うことは、メンバー間のコンテキスト共有のタイミングを増やすことの重要性が挙げられます。
スクラムに関して言えば、スクラムの理解度の差やスクラムに対する考え方の違いがありますし、採用している技術それぞれの技術の深さもありますし、ドメイン知識や組織に対する考え方の違いもあります。
結果、スクラムそのもののプラクティスに則ることも重要ですが、チーム内コミュニケーションを増やし、コンテキストを共有しながら常に改善を試みることが重要そうだと捉えています。
まとめ
スクラム開発未経験の私が、スクラム風のアジャイル開発を1年経験して感じたことをまとめてみました。
なかなか、アプリケーション開発だけをやっていた経験が少なく、ITエンジニア人生の9割以上がインフラを中心とした業務に携わってきたためかスクラムの知識も経験も少ないことは否めません。
また、必ずしもすべての人にマッチするプラクティスでない以上は、常に評価し続ける必要があるでしょう。
これからもうまく開発効率化につなげていけるように改善に取り組めればと思います。
もしこうするともっと改善するよとか、もっとこうしたほうがワークするよとか自社はこうしているよなどのアドバイスがありましたらぜひ教えてください。
コメントを投稿するにはログインしてください。