こんにちは！ファインディでソフトウェアエンジニアをしているhamです。

9月に「開発効率が高いエンジニアを真似することから始める、エンジニア組織の改善サイクル」というオンラインイベントで登壇しました。

この記事では、イベントでお話ししたことのうち「個人の開発パフォーマンスがどのように変化したか？」にフォーカスして書きます。

この記事で話すこと

• 入社3ヶ月でプルリク作成数が5倍になった理由

• プルリクを分割してさくさくマージするメリット

• プルリクをさくさくマージできる開発組織とは？

入社3ヶ月でプルリク作成数が5倍に！！

こちらのグラフは入社月(5月)と3ヶ月後(8月)の私のプルリク作成数を比較したものです。(このグラフは開発パフォーマンスを可視化できる「Findy Team+」を使って集計・表示しています。ご興味がある方はぜひご確認ください！！)
グラフをパッと見ただけでプルリク作成数が爆増していることがわかると思います。
月間プルリク作成数は5月14件、8月85件です。3ヶ月で5倍以上になりました！！

プルリク数が増えると何が嬉しいのか？

誤解なきようにコメントしておくと、プルリク数5倍=生産性5倍ではありません。
生産性を5倍にするにはプルリクの大きさは変えずに数を5倍にする必要がありますが、今回は1つのプルリクでやっていたことを分割することでプルリク数が5倍になったという話です。
プルリクを分割するイメージは下記図で説明します。

こちらはAPIを新規作成する時のプルリクを図にしています。
前者はAPIが使えるようになるまでの全ての実装を1つのプルリクで行っています。
後者は例えば、①入力値を変換する処理を実装してマージ、②レスポンスで使うデータ生成処理を実装してマージ、③生成したデータをレスポンス用に整形する処理を実装してマージ、④APIの認証を実装してマージ、⑤APIのルーティングを実装してマージというように実装→マージを繰り返しています。

この図を見ると「結局どっちでも同じじゃん？！」「マージするごとにレビューするからレビュー数5倍やん！」などの声が聞こえてきそうですが、おっしゃる通り上記図ではAPIが使えるようになるまでのトータル時間は同じなのであまり意味はありません。
ただ、実際にプルリクを分割して開発してみると1つ1つのプルリクがさくさくマージできて下記図のようにトータル時間が短縮されることが多いと感じています。

なぜトータル時間が短縮できるのか？

実装者の認知負荷が減る

プルリクをマージするまでの間、実装者はプルリクの全ての変更に責任を持つ必要があります。
プルリクの変更行はプルリクがマージされるまでは「実装者のコード」であり、変更内容を把握したり、バグを修正したり、レビュー指摘を修正したり、ベースブランチの変更を取り込んだり、プルリクを正しい状態にする責任を実装者が持っています。
プルリクの変更行がレビューで承認されてベースブランチにマージしたら「みんなのコード」になります。
「みんなのコード」はチームメンバー全員でメンテするコードです。

もし1つのプルリクで全て実装した場合、当然変更行も膨大になります。
変更行が多ければ多いほど実装者の認知負荷が上がり、プルリクを正しい状態に保つための作業が煩雑になり時間がかかるようになります。

一方、プルリクを細かくすることで、実装者が責任を持つ変更行を減らすことができ、プルリクを正しい状態に保つことにかける時間を短くすることができます。

レビュー速度UP

レビューをしている方ならわかる方が多いと思いますが、プルリクの変更行数が増えるとレビューにかかる時間は指数関数的に増加します。
「1,000行変更したプルリク1つ」または「200行変更したプルリク5つ」をレビューする場合、後者の方がレビュー時間が短くなることが多いと思います。

また、レビュー速度と直接関係はないですが、変更行数が多いとレビュアーにかかる認知負荷が上がるためレビュー精度が下がります。
レビュー精度が下がることで、バグをレビューで検出できない確率が高まり、バグ対応などで間接的に時間を消費してしまうことにつながります。

ちなみに、私が所属している開発チームの過去3ヶ月の1プルリクあたりの変更行数を確認したところ約200行でした。200行前後のプルリクはサクサクレビューできます。
また、8月の私のレビュー数は175件でした。1日あたり約7件レビューしています。それでも8月は前述の通り85件プルリクを作成しているのでレビューで圧迫されて開発工数が落ちていないことがわかります。

手戻りが減る

基本的には1つのプルリクでやろうとしている変更が全て終わった後にレビューしてもらうと思います。
レビューで全体に影響する指摘があった場合、変更行数が多ければ多いほど手戻りが増えてしまいますが、変更行数が少ない場合は全体に影響する指摘があっても影響は少なくすみます。
プルリクを小さくすることで、変更行数が少ない状態でレビューしてもらえるので、常に手戻りが少ない状態で実装を進めることができます。

コンフリクトが減る

プルリクの変更行数が増えると生存期間も長くなります。変更行数が多く、生存期間が長くなるとベースブランチからの乖離がどんどん大きくなりコンフリクトが発生する可能性が高くなります。
コンフリクトの修正は変更行数が多いほどツラい作業になるため、こまめに解消していく必要があります。そのため、プルリクの生存期間が長くなるほどコンフリクトする回数も増えるため、コンフリクト解消に使う時間がどんどん長くなります。
一方、変更行数少なくして生存期間を短くすることでコンフリクトする可能性をほぼ0にすることができます。
コンフリクトのない世界はとても快適です！

別で行われた変更を取り込む手間が省ける

チーム開発をしている場合、複数の開発が並行していると思います。
その中にはライブラリのバージョンアップや全体に関わるリファクタリングが行われることもあります。
1つのプルリクで作業を続けている場合、別で行われた全体的な変更を作業中のプルリクに自分で反映する必要があります。
一方、細かくベースブランチにマージしておくことで、マージ済みの変更は別で行われる全体的な変更の対象となるので自分でやる必要はなくなります。

本番障害時の原因特定が早い

開発をしていると、本番障害を起こしてしまうことがあります。
本番障害が発生した際、リリースしたプルリクの変更行数が多いと障害箇所を見つけるのに時間がかかります。また、変更行数が多い場合は1回のリリースで複数の不具合を埋め込んでしまう可能性も高くなります。
少しずつマージしてリリースしている場合、1回のリリースでの変更行数が少ないので複数の障害を同時に埋め込む可能性は低くなり、障害の原因特定にかかる時間も短くなります。

プルリクをさくさくマージできる開発組織とは？

ここまではプルリクを分割して細かくマージしていくことのメリットを紹介しましたが、ここではそれを実現するための開発組織について書きます。

自動テストやLintなどCIを充実させる

プルリクを細かくマージするには自動テストやLintなどCIを充実させることが必須です。
Lintなど静的コード解析がない場合、コードレビューで機械的に判別できる指摘が増えてレビュー時間が伸びてしまうことがあります。
自動テストがないと、少しの変更でも既存影響の有無がわからないためマージするたびに手動テストが必要になり、さくさくマージすることが困難になります。

開発フローが簡素化＆自動化されている

プルリク数を増やす場合、同じ開発フローのままでも気合いで数を増やすことができます。
ただ、今まで月1回のサイクルで回していた開発フローを週1回にしたり、週1回で回していた開発フローを1日1回にするなど大幅に短縮すると、今までは手動でも気にならかかった作業でも実施回数が増えることで高負荷になることがあります。
まずは回数が増えることで負荷が高くなる作業を自動化するなどして1つずつ潰していき、少しずつフロー全体を高速にしていきましょう。

チーム全員で同じ意識を持つ

プルリクを細かくマージしていくには同じペースでレビューしてくれるレビュアーの存在が欠かせません。
そのため、チームで1人だけプルリク細かくしようとしても、他の方も同じように考えていないとレビューが遅くなり、最終的にはレビューのペースに合わせたプルリクサイズになっていきます。(レビューが1日1回だったらプルリクも1日1件になる)
基本的には遅い方に収束していくことが多いので、実施する場合はチームで意識を合わせるようにしましょう。

途中のコードがベースブランチに混ざることを許容する

1つの機能開発でもプルリクを細かくマージしていくため、まだ本番では使われないコードや中途半端なコード、QAなどのテストが不十分なコードがベースブランチにマージされることになります。
※中途半端といってもユーザーに提供できる状態になっていないという意味であり、自動テストやLintやレビューはクリアしています。

開発現場によってはこのような中途半端なコードがベースブランチに入ることを許可しないところも多いと思っています。
ただ、既存には影響をないように実装されているのであればベースブランチにマージしても問題はなく、前述したメリットが享受できるので、既存に影響がない場合はガンガンマージしていく文化が広まると良いなと思っています。

最後に

最後まで読んでいただきありがとうございます！
ファインディでは、開発チームの開発者体験の最大化にも積極的に取り組んでいます！
興味がある方はTwitterのDMやカジュアル面談もやっていますので、お気軽にご連絡ください！