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

実装者の認知負荷が減る

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

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

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

レビュー速度UP

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

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

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

手戻りが減る

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

コンフリクトが減る

プルリクの変更行数が増えると変更に要する時間も長くなる傾向があるため、プルリクの生存期間も長くなります。プルリクの変更行数が多く、生存期間が長くなるとベースブランチからの乖離がどんどん大きくなりコンフリクトが発生する可能性が高くなります。 一方、変更行数少なくして生存期間を短くすることでコンフリクトする可能性を限りなく小さくすることができます。 コンフリクトのない世界はとても快適です！

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

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

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

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

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

ここまではプルリクを分割して細かくマージしていくことのメリットを紹介しましたが、ここからはプルリクを小さくたくさん作る開発スタイルを実現するための開発組織について書いてみます。

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

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

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

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

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

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

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

1つの機能開発でもプルリクを細かく作成してマージしていくと、まだ本番では使われないコードや中途半端なコード、QAなどのテストが不十分なコードがベースブランチにマージされることになります。 ※中途半端といってもユーザーに提供できる状態になっていないという意味であり、自動テストやLint、レビューはクリアしています。 開発現場によっては、このような中途半端なコードがベースブランチに入ることを許可しないところも多いと思います。 ただ、既存には影響をないように実装されているのであればベースブランチにマージしても問題はなく、前述したメリットが享受できる と思いますので、既存に影響がない場合はガンガンマージしていく文化が広まると良いなと個人的には思っています。

最後までお付き合いいただきありがとうございます！ Findyでは、プルリク作成数やレビュー負荷、デプロイ頻度などのDevOps指標を、「Findy Team+」を使って、定量的に把握しながら日々開発をおこなっています。

少しでもご興味ありましたら、「Findy Team+」は2週間の無料トライアルを設けていまして、貴社の開発アクティビティ･パフォーマンスをいつでも計測可能ですので、お気軽にお問い合わせください。