バイセル Tech Blog

バイセル Tech Blogは株式会社BuySell Technologiesのエンジニア達が知見・発見を共有する技術ブログです。

バイセル Tech Blog

生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話

スクラム アドベントカレンダー2022 fujisawa33

はじめに

こちらは バイセルテクノロジーズ Advent Calendar 2022 の 2 日目の記事です。 前日の記事は早瀬さん「ApolloClient から Relay に乗り換えようとして諦めた話」でした。

こんにちは！株式会社バイセルテクノロジーズのテクノロジー戦略本部に所属している藤澤です。最近ではチームのテックリードのロールも担っています。

現在私の所属しているプロジェクトでは、チームの開発手法としてスクラムを採用しており、スクラムを通じて自分達の生産性を改善するための取り組みを続けて来ました。

その一環として、生産性指標を計測し定量的にチームの生産性を観察することを始めたのですが、最近になって指標が急激に改善してきました。

そこで、今回はバイセルアドベントカレンダー 2 日目の記事として、生産性向上のためにチームとしてやってきたことを紹介したいと思います。

背景

生産性指標を計測する以前、スクラムの運用によりなんとなくチーム全体として生産性が上がってきているような肌感覚がありました。しかし、それを示す定量的な指標をチームとして持っていなかったため、本当のところはどうなのかチームの内外から疑問に思われている状態でした。

この点について、スクラムイベントの１つであるスプリントレトロスペクティブ内で議題にあげ、チームとして改善を重ねていくこととなりました。

具体的な改善ポイント

それでは具体的に生産性改善のために、チームとしてやったことをまとめていきます。

内容は全てスクラムイベントのレトロスペクティブでみんなで意見を出し合った上で決めたものです。実験的な内容をいくつかやった上で効果があったと思われるものだけ抜粋しています。

① 生産性の指標を決めた

エンジニアの生産性を測る指標として Google の DevOps Research and Assessment が提唱した Four Keys というものがあります。詳しい内容は割愛しますが、プロジェクトのフェーズが開発中であるということもあるので、私たちのチームは Four Keys の中でも変更のリードタイムに着目することにしました。

変更のリードタイムとは「commit から本番環境稼働までの所要時間」と定義されています。 このリードタイムを改善するための指標として1 日あたりのプルリクエスト(以下 PR)作成数を採用することにしました。

私たちのチームでは、PR を作成しマージすると同時にデプロイされるというワークフローをとっています。 このフローの中で PR 作成数を KPI とすることにより、

作成数を増やすために、PRの変更を小さくする
↓
PR のレビューコストが下がる
↓
PR のマージ速度が上がる

という効果を期待して指標を設定しました。 生産性の指標を決めたことで、生産性改善のために何を目指せば良いかがチーム内で明確となり、その後の改善につなげることができました。

② 指標の計測方法を決めた

次に、上記の指標を計測する方法について検討しました。

当時バイセル社内でFindy Team+というサービスの導入が進められていました。Findy Team+では Github や JIRA との連携により、PR 作成数や PR マージまでの平均時間等、様々なエンジニアの生産性に関わる指標を可視化・分析することができます。

そこで私たちのチームは Findy Team+を利用して、1 日あたりの PR 作成数を計測することにしました。

指標を可視化できたことで、目標の達成度合いや改善施作の効果がわかりやすくなり、確度の高い施策を導入することにつながりました。

Findyの例

③PR に関する目標やルールを設けた

指標の計測を始めた当初は、PR 数を増加させようという大まかな目標しかなくその具体的な方法については議論がなされていませんでした。そして PR 数の増加についても思ったより上昇していないという状態でした。

そこでチームで相談し、

  • 1日1人あたり2PR以上作成する
  • 1PR内の変更行数を100以内にする

といった目標やルールを決めて、運用してみることにしました。

1日1人あたり2PR以上作成する

具体的にどのくらい PR 数が増加すれば生産性が良い状態であるのかを明確にしたいという意見があったため、 1 日あたり各メンバーが提出する PR 数の目標を定めることになりました。 2PR以上という数字は、生産性が高いと言われている他社や他チームの事例を参考にして設定しました。

1PR内の変更行数を100以内にする

当初は、PRを細かく分割しようという話にはなっていましたが、PRの分割の粒度についての意思統一が難しく、なかなか思うようにいきませんでした。 そこで実験的なものとして1PRあたりの変更行数に上限を設けてみてはどうか？という意見がでて試してみることになり100行以内という制限が設定されました。 ルール導入前は１つの PR の変更行数が 1000 行を超えることもザラだったチームの状態からするとかなり挑戦的なルールに思えましたが、 これに関しては実際に導入してみると意外とうまくいきました。

各人が変更行数を抑えて PR を作ることを意識したため、作業のスコープが小さくなりプルリクエスト内での差分がわかりやすくなりました。変更の少ない PR は内容がわかりやすいためレビュー負荷も下がりました。

レビュワーの負荷が下がったため、これまでは放置されがちだった PR がすぐにレビューを終えられるようになり、コードを書いてからデプロイされるまでの時間が大幅に短くなりました。

④PR の通知方法改善した

PR を作成した後のレビューを依頼する方法として slack でレビュワーにメンションをつけて依頼するという運用をしていました。

slackでのやり取りの様子

ところが上記の２つのルールを導入した後、爆発的に PR の数が増えてしまいレビュー依頼が流れてしまう、未レビューの PR が slack 上でどれかわからなくなるといった問題が発生し、１つの PR をレビューしマージするための手間が気になる状況となりました。

そこで、チームとして PR のレビュー依頼や、レビューに対する返答の通知方法の改善を検討しました。

具体的に導入したこととしては、

  • レビュー可能な PR の状態を統一する
  • Github の Schedule reminder で通知の設定を統一する

というものでした。

レビュー可能な PR の状態を統一する

レビュー依頼を出した時の PR の状態が個人によってバラバラであったため、Github 上でレビューして良い PR とまだしてはいけない PR の見分けがつきづらい状態でした。

また、作業中の PR もタイトルに WIP を付けていたり、draft 状態であったり個人によってバラバラでした。

そこで、Github 上の PR の状態が「ready for review」且つ「reviewer に自分が設定されている」状態をレビューして良い状態として定義しチーム内で統一することとしました。

Github の Schedule reminder で通知の設定を統一する

slack での依頼では、

  • そもそも依頼の作業が手間である
  • PR 数が多いと依頼が流れてしまう
  • slack 上でレビュー済みと未レビューな PR の見分けがつかない

という問題がありました。そこで Github の Schedule reminder を利用して、通知を受け取ることにしました。

Schedule reminder 自体は個人に紐づく機能なのでチームで一括での対応はできませんでしたが、Schedule reminder の設定自体をチーム内で統一するようにしました。

以下がその設定です。

Schedule reminder設定例

これによりチーム内全員が自分が reviewer に設定されたり、github 内でメンションをつけられたりすると slack で通知を受け取れるようになりました。

そして、定期的に未レビューの PR がわかるようになったので、slack でのやり取りが劇的に減ることとなりレビュー作業のオーバーヘッドが削減されました。

⑤ 時間がかかった PR の振り返りを行った

最後にこれが一番大事だと個人的に思っていますが、上記のような内容を試した後でそれがうまくいっているのかを確認するための時間を設けました。 具体的にはスプリントレトロスペクティブで振り替えりを行う際に、Findy Team+を使ってみんなで指標の推移を確認するという項目をアジェンダに含めました。

  • 1 日あたりの PR 数の変化をスプリント間で比較する
  • そのスプリントの中でマージするまでに時間のかかった PR を確認し原因について話し合う

といったことを行いました。 これの結果として「1日1人あたり2PR以上作成する」や「1PR内の変更行数を100以内にする」といったものが生まれ、その後の改善に繋がりました。

結果

では以上のような改善を重ねた結果、チームの状態がどのようになったかを紹介します。

まずは定量データとして、Findy Teams+上での生産性指標の推移を紹介します。

PR数推移グラフ

これは PR 等のリードタイム関連の指標をデイリーで追ったグラフです。 棒グラフが PR 数を表しますが、途中から数が大幅に上昇していることがわかります。 また、平均プルリククローズ時間、プルリク作成からレビューまでの平均時間といった PR を処理するのにかかる時間も大幅に少なくなってきています。

サイクルタイム

上記は直近１ヶ月におけるチームのサイクルタイムの平均値です。Findy Team+の分類として最高ランクの Elite に達しています。

また、定性データに対するチーム内の声として、100 行以内ルールが想定外にうまく回ったことに対する驚きの声や、レビュー依頼の手間が削減されたことに対する好意的な声が聞かれました。

結果として上手く指標が改善できた一方で課題もあります。Four Keys の中でも 1 つの指標のみに絞って改善したため、その他の指標に対して影響がないかを注意する必要があると感じました。

具体的には、開発中のプロジェクトであったため今回は考慮しませんでしたが、「変更障害率」という指標があります。これは「デプロイが原因で本番環境で障害が発生する割合」と定義されています。

今回の事例で言うと、PR 数を稼ぐために動作確認やレビューがおざなりになることで変更障害率に悪影響が出るようなリスクがあると感じしました。このあたりは追加で検討・改善していきたいと考えています。

まとめ

いかがでしたでしょうか。 今回は開発中のチームにおいて、PR 数という指標を用いた生産性の改善方法を、バイセル内のプロジェクトの実例を用いて紹介しました。

この記事がエンジニアの生産性について悩んでいる方に、少しでも参考になれば幸いです。

最後に、バイセルではエンジニアを募集しています。少しでも気になった方はぜひご応募お待ちしています。

herp.careers

明日のバイセルテクノロジーズ Advent Calendar 2022は尾沼さんの「リファイメントとプランニングを改善することで、チームの属人化が解消された話」です、そちらもぜひ併せて読んでみてください！