この記事は JMDC Advent Calendar 2024 16日目の記事です🌲

15日目は川島さんによる「Redshiftのストアドプロシージャで単体試験自動化をやってみた」でした。

株式会社JMDCでヘルスケアプラットフォームサービス【Pep Up】のフロントエンドエンジニアをしている新保です。

この秋からPep Up開発チームに「カイゼンチーム」という新しいチームができ、エンジニアに加えてそのチームリーダー的なこともやることになりました。これはPep Upの各種数値を計測し、こまめな改善施策を打ってその影響を計測するという、いわゆるグロースハック的な役割を期待されているチームです。

今まで以上のスピード感が期待されている中で、どうやったらチームのスピードを維持・加速できるのかな……と考えていたところ、wataponさんの PR数は開発生産性のセンターピンかもしれないという記事を紹介してもらいました。

ざっくり説明すると「PR数をKPIにすると開発の色々な部分がうまく回るかも！」という内容で、これは良さそう！うちもちょうど Findy Team+ 導入したところで計測もできるし！と早速取り入れてみることにしました。

初めて約一ヶ月。その結果がこちらになります！

デプロイ頻度2.4件、変更のリードタイム10.0h、変更障害率0.0%、平均修復時間0.0h

なんと開発チームのパフォーマンスを測る指標である Four Keys がすべていきなり最高判定の Eliteレベル！

サイクルタイム合計値 18.5h

修正がマージされるまでの時間を表したサイクルタイムも合計値で Elite レベル！

(ちなみに、1日1PRを目標にする前はサイクルタイムが70hオーバーとかでした)

まさかここまで結果が出るとは思っていなかったので驚きでした。1日1PRはいいぞ。

はじめの一歩

とはいえ最初は、「どのくらいのPR数を目標にすればいいんだ？」と頭をひねるところからのスタートでした。

ネットで調べても「どうやら1日三つ〜四つ出してると、とてもすごいらしい」ということしかわからず…… 😢

ひとまずわかりやすさ重視で「1PR/日」を掲げて始めてみました。

結果として今までのところ、われわれは一人一日1〜2PRぐらい出せるということがわかりました。まだ月平均で2PR/日を超えている人は出てきていないので、そこが一つの目標になるかもしれません。

個人的には瞬間的に3PR/日ぐらい出せる時もあるのですが、MTG続きでほとんど開発できない一日もあり、ならすとだいたい1〜2PR/日の範囲に収まるようですね。

逆に、1日1PRを目標にすると、「この日はMTGが続いてるから今日のうちにたくさんやっておかなきゃ」とか「午後からMTGだらけだから、午前中のキリのいいところで一回PR出しておきたいな」というモチベーションにもなるということがわかりました。

レビューも楽々

1日に一つ以上PRを出そうとすると、必然的に一つのPRに含まれる内容が少なくなります。

ということは、レビューする負荷も下がるということですね 🎉

場合によっては1行とか2行の修正でPRを出すこともままありますが、以前チーム内でなんとなく合意していたのは「差分が200行とかあるとさすがに読むのが辛い」という基準だったので、「こんなに内容の少ないPRでいいんだろうか？」という不安も最初はありました。

しかし重要なのは、行数よりもその影響度ですよね。

1行2行の修正でも、それがモデルの根幹に関わる修正であれば影響範囲は広く、レビュー時に考えることも多くなります。逆に200行ぐらいある修正でも、新規ページのフロントエンド実装で、9割型テンプレートが決まっているページだったりすると、確認するべき点はそこまで多くありません。

なので意味的にきちんと分割されていれば、行数に囚われず小さいPRをどんどん出していっても問題ないと思います。(もっともこのあたりはチーム内での合意も必要そうですが)

また、1日に一つPRを「マージする」ことを目標にすると、レビュイー側も「早くマージしてもらいたい」という意識が働くので、レビュアーに内容を理解してもらうためPRの説明を手厚くするようになりました。

レビュイーは一人ですがレビュアーは複数いることも多いですし、レビュアーが背景を一から理解するよりも、レビュイーがすでに理解している内容を書くほうが早いと思うので、チーム全体で見ればこれもメリットが大きいと言えるのではないでしょうか。あとからPRを振り返ったときにも事情を把握しやすいというメリットもあります。