Findy Team+ Lab

NEW

ナレッジ

入社3ヶ月でプルリク作成数5倍!!プルリクを小さくたくさん作りさくさくマージするメリットとは?

入社3ヶ月でプルリク作成数5倍!!プルリクを小さくたくさん作りさくさくマージするメリットとは?

22年9月に「開発効率が高いエンジニアを真似することから始める、エンジニア組織の改善サイクル」というオンラインイベントで登壇した、弊社エンジニアのFindy Team+活用事例をご紹介いたします。

この記事では、イベントでお話ししたことのうち「個人の開発パフォーマンスがどのように変化したか?」にフォーカスします。 具体的には、「入社3ヶ月を定量的に振り返る」、「プルリクを分割してさくさくマージするメリット」などをお話させていただきます。

目次

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

【22/05と22/08のプルリク作成数の比較】

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

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

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

【APIを新規作成する場合:1プルリク vs 複数プルリク】

こちらはAPIを新規作成する時のプルリクを図にしています。 上の図は、APIが使えるようになるまでの全ての実装を、1つのプルリクで行っています。 下の図は、例えば、以下のように、プルリクを小さく分割し、実装→マージを繰り返しています。

  1. 入力値を変換する処理を実装してマージ
  2. レスポンスで使うデータ生成処理を実装してマージ
  3. 生成したデータをレスポンス用に整形する処理を実装してマージ
  4. APIの認証を実装してマージ
  5. APIのルーティングを実装してマージ

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

【APIを新規作成する場合:1プルリク vs 複数プルリク(時間軸考慮)】

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

実装者の認知負荷が減る

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

もし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週間の無料トライアルを設けていまして、貴社の開発アクティビティ・パフォーマンスをいつでも計測可能ですので、お気軽にお問い合わせください。

関連記事

【CTO/EM100人に聞いた】約8割がエンジニア採用が難しくなっていると実感。独自性の高い人事制度運用や生産性向上に向けた定量データの利用も増加

【CTO/EM100人に聞いた】約8割がエンジニア採用が難しくなっていると実感。独自性の高い人事制度運用や生産性向上に向けた定量データの利用も増加

ナレッジ
エンジニア組織の生産性の可視化とは? 〜『DevOps指標』を活用しよう〜

エンジニア組織の生産性の可視化とは? 〜『DevOps指標』を活用しよう〜

ナレッジ
開発者体験(Developer eXperience)向上の最前線〜ストレスなく働ける組織づくりとその結果〜

開発者体験(Developer eXperience)向上の最前線〜ストレスなく働ける組織づくりとその結果〜

ナレッジ
Findyの開発スピードが1年で約3倍になった結果、ユーザからの反応は格段に変わり、未知の課題にぶつかった

Findyの開発スピードが1年で約3倍になった結果、ユーザからの反応は格段に変わり、未知の課題にぶつかった

ナレッジ

エンジニアリング組織の
パフォーマンスを最大化

Findy Team+はGitHubやJiraなど
エンジニア向けツールを解析することで、
エンジニアリング組織の生産性を可視化するサービスです。