プルリクエストを作りまくることで得られたFindyの爆速プロダクト開発術
こんにちは、Findy CTO の @ma3tk です。 FindyではFindy Teamsを使ったエンジニアリング組織の分析を行っていたりします。
また、Findy社全体として大事にしているいちばん大事な開発指標として、プルリクエストの作成数があり、プルリクエスト作成数をベースに開発がうまくいっているかを議論し続けています。
プルリクエストの作成数とそれに紐づく議論について書いてみようと思います。
目次
- プルリク作成数
- Findyにおけるプルリク作成数の実績
- プルリク作成数を向上することによって得られること
- 改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる
- プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす
- プルリク肥大化を防ぐことでレビュワーの負荷を減らす
- コンフリクトのリスクを減らす
- 「あの人何してるんだろう？」を減らす
- レビューの回数多くなってしまわない？
- 全体感がわかりにくくなってしまわない？
- Findyのプルリク作成のベストプラクティス
- 例: ユーザ一覧APIの新規作成
- プルリクの分析機能をFindy Teamsで開発しています
- 爆速顧客価値提供ができるFindyで働いてみませんか？
プルリク作成数
GitHubベースに開発を進めている方だと当たり前に認識している部分だと思いますが、プルリクエストをどれだけ作るかで、エンジニアとして、チームとしてどれくらい開発が健全に回っているかがある程度見えてきます。
今回の作成数についてはマージされないものやドラフトのもの含めてすべてのプルリクエストを計測しています。
事前にお伝えすると、プルリク作成数などの数値を見てどう改善するかが大事であって、数値は参考にすべきものであるが絶対に達成しないといけない指標ではありません。数値が全てではなく、数値を見てどう動くかを考えたいという話です。
Findyにおけるプルリク作成数の実績
Findyにおいて2021年8月は一人あたり78.8件のプルリクを作成していました。これは1日あたり3.94件となり、多くのプルリク数を作っていることがわかります。最も多いメンバーだと1日あたり8.45件のプルリクを作成しています。(計測して本当にびっくりですが…！)
いろいろな課題のあるチームだとプルリクがそもそも1日1件も出ずに業務が終了する、というケースがあったりしますが、Findyではなるべく多くのプルリクを出すようにしています。
8時間の稼働のうち2時間に1件くらいは作成するペースです。
プルリク作成数を向上することによって得られること
プルリク作成数をただ上げるだけではなく、
- 小さく分割する
- レビューを全部同プルリクでやりきらない
ということも大事だったりします。
小さく分割されたプルリクを作り、プルリク作成数を最大化することで大きく5つの大きなメリットがあります。
- 改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる
- プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす
- プルリク肥大化を防ぐことでレビュワーの負荷を減らす
- コンフリクトのリスクを減らす
- 「あの人何してるんだろう？」を減らす
一方で、
- レビューの回数が多くなってしまう
- 完成イメージがわかりにくくなってしまう
というデメリットも生じます。それぞれ解説してみます。
改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる
これも毎日リリースなどをこなっているとしたら、プルリクの範囲を小さくしプルリクの作成数を多くすることで、できている範囲までで価値提供することができるようになります。
もちろんできている範囲が中途半端で価値提供にならないのであればそうとは限りませんが小さな修正などはまとめて他のタスクとやらずに個別に対応するなどで限りなく他の影響を減らして対応ができるようになります。
プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす
一気に大きな対応を行おうとすると、以下のようなことが起こります。
- プルリクそのものが不要だったり方針が違うのに作りきるまでかかった時間が無駄になる
- 複数の内容が入っていたりすると全部直したりしないといけない
- CI/テストの影響範囲が広くなり修正箇所も多くなる
- 作成する側に差し戻された内容が多いと精神的に重さを感じる
- 一旦別のタスクをすると範囲が広いので対応している内容を時間の経過とともに忘れがち
プルリクが大きくなると実は作成者の自分にもダメージが出てきたりします。
プルリク肥大化を防ぐことでレビュワーの負荷を減らす
これはいろんな方が体験したことがあると思いますが、大きすぎるプルリクを上げられると辛くなりますよね。
- 大きすぎるプルリクが来ると「あとでレビューしよう」で放置されがち
- 「いざやるか！」と思っても何を見ていいかわかりにくい
- プルリク全体に関わるような共通化を同時に依頼するとまたレビュー最初からになりがち
- ずっと同じことをレビューしているという状態が続く
- 範囲が広いのでブラウザで全然diffが表示されず困る
たぶん優秀な人であっても大きいプルリクのレビューはしたくないはず…！
これが小さな範囲のプルリクであれば上記のような事は起こりにくくなるはずです。
コンフリクトのリスクを減らす
コンフリクトしていたり、プルリクの滞留時間が伸びることで先にマージされた内容などを取り込みながら再度修正しないといけなかったりしますよね。
ライブラリのlockファイルや共通ファイルなどにも影響がいくとレビューする側も対応する側も「コンフリクト解消お願いします」と結構面倒なコミュニケーションをせざるを得なくなります。
なるべくコンフリクトを減らすことでコンフリクト解消コミット0化による安全な改修が可能になります。
「あの人何してるんだろう？」を減らす
これもリモートワークが推進されている環境だと尚更ですが、「あの人は何してるの？」という状態を減らしにいくことができます。
午前中はAの対応、午後はBとCのタスクの対応をしている状態とわかると進捗がはっきりしやすいため「何やってるかわからない」が減らせます。
これはプルリク作成者もそうですし、レビュワーもお互いにキャッチボールしやすい状態を作るとチームとしてストップしにくい状態になります。
レビューの回数多くなってしまわない？
確かにデメリットとしてレビューの回数が多くなってしまうということです。
ただレビュワーとしては「ここだけ見ればいい」がはっきりしているため、1分あればレビューも大体完了するような状態にできます。
自分のプルリクも小さく回数を増やすことで「せっかくコード書いてるのにレビューばっかり」という状況も減らし、「ここまで書けたしレビュー依頼も来たし対応しよう」という状況を作ることができます。
全員が小さなプルリクをたくさん作ることでスピード感あるレビュー環境が作れます。
全体感がわかりにくくなってしまわない？
これはたしかに全体感がわかりにくくなってしまう可能性はありますが、自分が考えるに、プルリクの範囲が小さい状況のほうが相手の思考の過程を辿りやすくなるので背景やどうしてこういうアーキテクチャにしたのかなどを考えすぎなくて済むのかと思います。
Findyのプルリク作成のベストプラクティス
- タスク着手時に気をつけること
- GitHubのイシューにチェックボックス形式でタスクを羅列する
- 羅列したタスクをエンジニアマネージャーやメンバーと合意する
- チェックボックス1つにつき1プルリクを作る
- プルリク作成する時に気をつけること
- なるべく粒度は小さくして最小限の範囲にする
- 最低限のテストが通ることを保証したプルリクにする
- リファクタや共通化なども別プルリクで対応する
- 100行を超えるようなプルリク、ファイル数が10以上のプルリクは分割できないか考える
- レビューすべきポイントをクリアにする
- レビューする時に気をつけること
- 着手までの時間をボトルネックにしないためになるべく最速でレビューする
- リファクタや共通化のコメントは行ってもいいが、同プルリクで対応を必須にしない
- 設計の段階で大きく違いそうな場合はコメントを増やさずオンラインで相談
今のところ大きく思い浮かぶやり方はこのようなやり方です。
例: ユーザ一覧APIの新規作成
僕が過去にやっていた手順はこんな感じです。
- コントローラーやモデル作成でユーザ一覧データが返るようにするプルリクの作成
- リファクタや効率の悪い部分を同プルリクで修正し完了
これだと合計1プルリクで、上述したように作成する範囲ややるべきことがあっているか合意が取りにくく、割とやり直しリスクがある状態でちょっと改善が必要です。
なるべく小さくプルリクを分割してプルリク作成数を最大化して進めていくことを意識すると、
- フロントでも使えるようにエンドポイントの設定と適当なjsonレスポンスのmockの作成プルリク+合意を取る
- ユーザモデルマイグレーションのプルリク
- ユーザ一覧取得処理のプルリク
- mockの置き換えプルリク
- ソート機能追加のプルリク
- 絞り込み機能追加のプルリク
- 共通化のプルリク
- 非効率な部分解消のための効率化のプルリク
これくらい分割してプルリクを上げていくと数は増えますが、レビュー範囲は圧倒的に減りますし、それぞれ作成するまで短時間でdevelopにマージできるようになります。
イメージしていただけたでしょうか！？
プルリクの分析機能をFindy Teamsで開発しています
ここまでの情報は、Findy Teamsで開発をしている部分もあり、簡単にデータが取得できます。継続的に測定できるため、自分の指定する期間でデータが取れるようになっています。
もしご興味があれば、こちらまでお問い合わせください！！
爆速顧客価値提供ができるFindyで働いてみませんか？
もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？
まだやりたいことがある中でまだまだ成長できる組織です！上記以外にも課題もあります！
是非興味があれば Twitter でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍
エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！
