こんにちは、プレックスの種井です。
今回は、2022年Plex開発合宿(秋)シリーズ最後の記事になります。(過去の記事はこちら)
10月の開発合宿で私が取り組んだ内容「開発チームの生産性の可視化」とPlexJob開発チームにおける「振り返り」の取り組みに関してご紹介させていただきます。
開発合宿で扱ったテーマ「振り返り」
私の所属するPlexJob開発チームではスクラム開発を取り入れています。合宿時点では月に一回、その月に取り組んだ各スプリントの振り返りをまとめて行っていました。
振り返りを行うなかで
- 個々人の課題感やその粒度に関してばらつきがある
- 課題に対してのアクションの優先度がつけづらい
という課題感がありました。
開発合宿で取り組んだ内容
振り返りの場では、各メンバー感じている課題を思い思い自由に出してもらいつつも開発チームとして重要視することを明確にしておくことは振り返りの質の向上や、個々人の課題感の洗い出しのしやすさという観点から重要だと考えました。
書籍エッセンシャルスクラムにも振り返り(スプリントレトロスペクティブ)の事前準備として、「フォーカスの定義」や「客観的データの収集」が要素として上げられています。 今回は、取り掛かりとして、「スプリント毎のベロシティ」と「デリバリのパフォーマンス(Four Keys)」の一部を計測することにしました。
上記の指標は
- スプリントごとのベロシティ
- チームの健全性の把握や提供した顧客価値の程度を測るものとして
- デリバリのパフォーマンス(Four Keys)
- 合宿の限られた時間内で試せるもの
という観点で選びました。
また、週次のスプリントにおけるベロシティは開発だけではなく、設計からリリースまでの間に複数の役割や要素が影響します。デリバリのパフォーマンス(Four Keys)も合わせて計測することで、開発者内でボトルネックの発見や改善に向けての意識が向きやすいのではないかと考えました。
Four Keysは4項目ありますが、今回は合宿の時間に限りがあるため比較的計測の容易な「デプロイの頻度」と「変更のリードタイム」の2項目のみをスコープとしました。
スプリントごとのベロシティの計測
PlexJob開発チームでは、スクラムにおけるタスクをNotionのデータベースとBoard viewを使用して管理しています。
- Notion APIを使用し、データベースからスプリント毎の完了タスクを収集
- BigQueryに保存
- Metabaseから集計
という流れで、ダッシュボードを作成することにしました。 1,2はスクリプトを作成し、自分の手元のPCで実行するような簡易的なものにしました。
Four Keysの計測
前述の通り今回「デプロイの頻度」と「変更のリードタイム」の2項目を対象とします。 両指標ともGitHub APIにて提供されているデータを活用しました。 また、
という前提で集計を行いました。
デプロイの頻度
本番環境へのリリース頻度です。 master(main)ブランチへのPRがマージされたタイミングをリリースとして、1日あたりのリリース頻度を月毎の平均として算出してみました。
変更のリードタイム
初回コミットから本番環境へのリリースまでにかかった所要時間です。 master(main)ブランチへマージされたPRの初回コミットからマージまでにかかった時間(日数)を月毎の平均として算出してみました。
合宿時点までの直近3ヶ月の指標を、パフォーマンスレベルに照らし合わせると両項目で「High」にあたることが分かりました。
まとめ
簡易的ではありますが、上記の指標を出してみて改めて個人の負荷状況、開発上のボトルネック、改善点について考える客観的な指標として活用できそうだと実感しました。
実際、合宿の最後の発表の際にも
- さらにリリース頻度を上げるためにはリリース対象を分割していくべきか？
- 逆に分割しすぎてQAやプロセスの最適化をしないと、リリースが遅くなることはないか？
- Four Keysの指標とスプリントのヴェロシティを合わせて計測すると分割の最適化ができるのはないか？
のような議論をすることができました。
PlexJob開発チームでの振り返りの取り組みについて
ここまで、10月の開発合宿で取り組んだ内容の紹介をさせていただきましたが、早いもので気がつけば3ヶ月以上経過しており、開発の体制としてもいくつか変化がありました。
この間、振り返りに関しても新たな取り組みをはじめました。 合宿で取り組んだDevOpsの指標もこの取り組みの中で活用しはじめたこともあり、この場を借りて紹介させていただきます。
前述させていただいた通り、10月時点では月に1回の振り返りを行っていましたが、11月、12月で開発チームに新たなメンバーが計2名ジョインしてくれたこともあり、よりチームとして情報の共有をオープンにし課題や方針に対してのアクションなどに共通認識を持てるようにすべきだと考え、振り返りの場の頻度や内容を再設計することにしました。
振り返りの内容としては、アジャイルなチームをつくる ふりかえりガイドブックなどを参考に以下のようなものにしました。
- 週1回金曜日に1時間程度の定例MTGを設ける
- 事前に振り返りシートを共有し、各メンバーにKPT用のJamboardに今週のアクションや課題と負荷状況を記入してもらう
- 前週のTryの実施状況の確認をする
- Jamboardに各自作成してもらった今週のアクションや課題を発表しながらKeepとProblemに振り分ける
- 全員のKeepとProblemが分類でき次第、Tryを議論して決め、次週のアクションにする
- Tryの中で開発Issueとして扱うべきものはタスク化する
- 各メンバーの調子と一言コメントを発表する
以下は、使用している振り返りシートの一部です。
運用をはじめて1ヶ月程度経ちました、まだまだ試行錯誤の段階ではありますが取り組みの中で、プロダクトチーム全体での勉強会や、問い合わせ対応の当番化などの実際のアクションにつながるものもいくつか出てきています。 引き続きメンバーのフィードバックをもらいながら続けていきたいと思います。
合宿で取り組んだ内容のその後と活用
最後に合宿で取り組んだ内容の活用ですが、Four Keysの2項目を振り返りシートに埋め込んで各自の振り返り時に使用してもらうことにしました。 KPTの洗い出しや次アクションを決める際の観点として活用してもらいたいという意図があります。
- GitHub APIから取得したデータを加工してtsvとして書き出すスクリプトを実行
- tsvをスプレッドシートにインポート
- Google Looker Studioで2.のスプレッドシートをデータソースにしてダッシュボードを作成
- Notionの振り返りシートに埋め込み
おわりに
今回、合宿での振り返りの効率化としてのDevOps指標の検証と、PlexJob開発チームでの「振り返り」の取り組みに関して紹介させていただきました。
効果的な振り返りを継続的に実施することは難しいことです。 なるべく各メンバーの負荷を最低限にしつつも、効果的な振り返りを続けることは重要であると考えています。 事例として少しでもご参考になればと思います。
振り返りの取り組みやFour Keysをはじめとした指標の活用の変化に関しても引き続きアップデートがあれば、本ブログで紹介していきたいです。
最後になりますが、プレックスではソフトウェアエンジニア、フロントエンドエンジニアを募集しています。
上述のような、開発上の取り組みや課題に対してご一緒していただける方、少しでも興味を持っていただけた方は業務委託や副業からでも、ぜひご応募いただけると幸いです。
