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

<figure>
<img src="//images.ctfassets.net/ngrpflsbp3rq/1pMAXutCJkbAbC0Y1J4fSG/128333e5ec2db50cf4773f5d441e2059/3_______________________________________.webp"/>
<figcaption>【22/05と22/08のプルリク作成数の比較】</figcaption>

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

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

<figure>
<img src="//images.ctfassets.net/ngrpflsbp3rq/2SuWFefh3981PlSaANsAYa/7cb8385024f3d3bc312f67a88c796e67/API________________________________________________.webp">
<figcaption>【APIを新規作成する場合：1プルリク　vs　複数プルリク】</figcaption>

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

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

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

<figure>
<img src="//images.ctfassets.net/ngrpflsbp3rq/1EpmzJ9tWri4SwzPRtLstz/75399e6272178eac33455d7e24e6e085/_________________________________________________________________________________.webp"/>
<figcaption>【APIを新規作成する場合：1プルリク　vs　複数プルリク(時間軸考慮)】</figcaption>

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

もし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+](https://findy-team.io/)」を使って、定量的に把握しながら日々開発をおこなっています。

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

入社3ヶ月でプルリク作成数5倍！！さくさくプルリクをマージするメリット

プルリクを小さくたくさん作り、サクサクマージしていく開発スタイルのメリットをお話させていただきます

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

22/10_ココナラ様インタビューのヘッダー画像

技術負債解消とオンボーディング設計が秘訣？ココナラが目指す開発生産性向上と組織拡大の両立

今回は、皆さまから多くのご要望をいただいておりました、サイクルタイム分析ページの機能追加情報をお伝えいたします！😊

## サイクルタイム分析にラベルでの絞り込み機能が追加されました！🎉

この度、「__対象プルリクを絞り込んで、各リードタイムをチェックしたい__」というご期待にお応えして、[サイクルタイム分析ページ](https://findy-teams.com/analytics/cycletime)のフィルターにラベルでの絞り込み機能が追加されました！

### 対象プラン
- 全てのプラン

### 🌟ラベル絞り込み機能の特徴🌟
- リポジトリに紐づくラベルでの絞り込みが可能です
- ラベルは、複数選択可能です
- 本ページに表示されている全てのデータが絞り込まれます

![cycletime_label](//images.ctfassets.net/ngrpflsbp3rq/10KWx5sRBlLQVkkviW3Cn3/e3befde72aaaf00b22306458e81edb12/cycletime_label.png)

※留意点
- ラベルデータは、プルリクデータと同様にデイリーでの更新となります

外れ値となるようなプルリクを除外して、平均リードタイムを集計できるアップデートとなります！
是非、[サイクルタイム分析ページ](https://findy-teams.com/analytics/cycletime)にて、組織のパフォーマンスをチェックしてみてください！🙋


20221003

サイクルタイム分析ページに、ラベル絞り込み機能が追加されました！

【機能追加】サイクルタイム分析ページに、ラベル絞り込み機能が追加されました！

 ZOZOテックブログトップ画像

運用改善によるチームパフォーマンス向上のための取り組み

ユニラボ 小峯さん テックブログトップ画像

アイミツSaaS開発チームの開発生産性を数値でふり返る -Four Keys指標-

今回は、皆さまから多くのご要望をいただいておりました、サイクルタイム分析ページの機能追加情報をお伝えいたします！😊

## サイクルタイム分析のスタッツにランクが表示されるようになりました！🎉

この度、「__自社の開発リードタイムが、他社比較でどのレベルか知りたい__」というご期待にお応えして、[サイクルタイム分析ページ](https://findy-teams.com/analytics/cycletime)の各リードタイムスタッツにランクを表示する機能がリリースされました！

## 対象プラン
- スタンダードプラン
- エンタープライズプラン

### サイクルタイムスタッツランク機能の2つの特徴🌟
1.サイクルタイムの各リードタイムスタッツに、サービス導入企業のデータを基に、以下4段階のランクアイコンが表示されます。

導入企業上位25% ： Elite
導入企業上位50% ： High
導入企業下位50% ： Medium
導入企業下位25% ： Low

![cycletime_rank](//images.ctfassets.net/ngrpflsbp3rq/4aZr364ejm6bXM4ukI48ZG/6089d9385413f8298fbd211f0b11752e/245_-_____________________________-_Findy_Teams_-_findy-teams.com.png)

2.ランクの定義は、アイコンにマウスオーバーすると表示されます。

![cycletime_tooltip](//images.ctfassets.net/ngrpflsbp3rq/3fjRhzYrkRs3XKOCEMX2Vd/b29b3e4ae63cd026f3a6ccf247217b35/246_-_____________________________-_Findy_Teams_-_findy-teams.com.png)

※留意点
- ランクの定義は、四半期毎にアップデートされる予定です。
- 最新の定義は、アイコンにマウスオーバーして、ツールチップをご参照ください。

是非、[サイクルタイム分析ページ](https://findy-teams.com/analytics/cycletime)にて、組織のパフォーマンスをチェックしてみてください！🙋


20220926

サイクルタイム分析ページにランク機能が追加されました！

最新記事

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

技術負債解消とオンボーディング設計が秘訣？ココナラが目指す開発生産性向上と組織拡大の両立 - 株式会社ココナラ

【機能追加】サイクルタイム分析ページに、ラベル絞り込み機能が追加されました！

運用改善によるチームパフォーマンス向上のための取り組み - 株式会社ZOZO

アイミツSaaS開発チームの開発生産性を数値でふり返る -Four Keys指標- - 株式会社ユニラボ

【機能追加】サイクルタイム分析ページにランク機能が追加されました！

カテゴリ

最新記事

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

技術負債解消とオンボーディング設計が秘訣？ココナラが目指す開発生産性向上と組織拡大の両立 - 株式会社ココナラ

【機能追加】サイクルタイム分析ページに、ラベル絞り込み機能が追加されました！

運用改善によるチームパフォーマンス向上のための取り組み - 株式会社ZOZO

アイミツSaaS開発チームの開発生産性を数値でふり返る -Four Keys指標- - 株式会社ユニラボ

【機能追加】サイクルタイム分析ページにランク機能が追加されました！

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}カテゴリ

カテゴリ