advent_221205

爆速開発をしていくためのFindyの取り組み 〜2022年編〜

advent_221203

コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips

advent_221202

PR数は開発生産性のセンターピンかもしれない

BuySell Technologies Tech Blog

生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話

## 入社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_ココナラ様インタビューのヘッダー画像

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

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

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

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

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

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

アイミツ開発チームの開発生産性をFindyTeams-DevOps分析してみた

## 約8割が採用難易度が上がっていると実感

昨今ますます難易度が上がっているエンジニア採用ですが、CTO/EMも約8割弱が採用難易度が上がっていることを実感している結果が出ています。逆に簡単になっていると答えている方はわずか4%。背景には、スタートアップの大規模調達やDX企業の内製化、また同時に受託企業も大手からの発注増加など、景気後退期に入っても緩まぬエンジニア採用の需要があります。

![1](//images.ctfassets.net/ngrpflsbp3rq/5VbV75CulZQFvRPlBJBA72/0d7baf7b3a1d1106b3eac63c12f3361a/1.png)

## 悩んでいる比率が多い順に、採用強化（95%)・生産性向上(85%)・人材育成(81%)・マネジメント負荷軽減(79%)

エンジニア採用の難易度が上がる中でCTO/EMの悩みもやはり1位が「エンジニア採用」で実に95%のCTO/EMの悩みになっています。驚異的な数字ですね。

ちなみに、悩んでいる比率が多い順に「生産性向上」⇨「人材育成」⇨「マネジメント負荷軽減」と続きます。

![2](//images.ctfassets.net/ngrpflsbp3rq/5O6UL08t26YFT84C5Vtv2l/0aeb2b02dd9b4e0e6fcc018b38d51b66/2.png)

生産性向上や人材育成についてはFindyではエンジニア組織支援SaaS「[Findy Teams](https://findy-teams.com/login)」も展開しているのでぜひご活用ください。

ちなみに、お悩みランキングにおいて、実に98%のCTOが採用強化に悩んでおり、逆に2%の方が際立つ形になっています。また、CTO目線ではマネジメントの負荷軽減が、EM目線では現場での人材育成の方が、課題感として強いというのは面白い結果になっています。

![3](//images.ctfassets.net/ngrpflsbp3rq/3m54q76WbtOJNAUxbybMlU/87b4297755653fb49f06bc1732ebb9ea/3.png)

## 優秀な人材の採用・活躍には独自の評価制度が効果的

アンケート内でエンジニア独自の評価制度を導入しているかどうか、またその結果がエンジニアの採用や社内での活躍に効果的かどうかもお伺いしています。

その結果、当たり前と言えば当たり前なのですが、エンジニア独自の評価制度を導入している企業が採用や入社後の活躍面でプラスに働いていることが分かりました。

![4](//images.ctfassets.net/ngrpflsbp3rq/3RC2MQDNnV7bFJUE6iFUNr/533731145b539a28aa999bdf16b48cbd/4.png)

ただし、こちらも当たり前と言えば当たり前なのですが、独自の評価制度を実際に運用できている企業は上場ベンチャーに多いようで、スタートアップにとってはまだまだハードルが高い取り組みでもあります。

![5](//images.ctfassets.net/ngrpflsbp3rq/6THYxMkEsFiHKnKiwrV7Yh/5a2784a9497ddc87ff4ef9a847ed0b00/5.png)

また、エンジニア向けの評価制度そのものが難易度の高い制度設計でもあります。先日、Findy Teamsの導入企業数社で自社の評価制度の見せ合いとQ&Aのセッションをやったのですが、大いに盛り上がりました。

## 生産性向上のデータ活用については、「既に活用している」と回答したのは36%、「今後活用したい」との回答が59%

生産性向上のために定量データを活用する機運も上がってきています。

すでに活用している企業が36%に達しているとともに、今後活用したい企業まで含めると実に90%以上の企業が関心を持っている領域と言えそうです。今回のアンケート対象企業がベンチャーやスタートアップなど先進性の高い企業が多いため、偏りはある前提ですが、DevOpsへの取り組みやFour Keysへの関心の高まりを感じます。

![6](//images.ctfassets.net/ngrpflsbp3rq/42ks1p44HfpK5JtRwC0Ad3/50b3c4f6b7f9ae3108064b3976070561/6.png)

## 現状は9割以上がリモートメイン。コロナ収束後はフルリモート企業の3割弱が出社を増やしたい意向も

コロナ以後、進んできたリモートワークですが、現状は7割弱がリモートワークメインで、週1~2日程度出社の半リモートも含めると9割以上がリモートを活用している企業になってきています。

![7](//images.ctfassets.net/ngrpflsbp3rq/5lYehKgbXzFVtKm3djmQnf/5611f8d3ff4ef43568d92c3c51cab6c0/7.png)

一方で、フルリモートはマネジメント難易度が上がっておりマネージャーの負担が上がっているという声もちらほらお伺いしています。特に新卒の育成はフルリモートではなかなかハードルが高いとのこと。

そういった声を反映してか、現在フルリモートの企業をマネジメントするCTO/EMでは3割弱の方が出社を増やしたいという意向も出てきているようです。

![8](//images.ctfassets.net/ngrpflsbp3rq/6RIKM3QRFze3RBGdOxFMPU/7139a3cf7c19a4641b60f7b9f06ac3c6/8.png)

この辺りは企業のフェーズや職種、採用している技術レベルなどによっても異なってくるので、企業毎の最適解を見つけていきたいですね。

## まとめ

以上、「CTO/EM100人に聞いた」アンケートはいかがでしたでしょうか？
エンジニア組織を率いる方の生の声として「エンジニア採用」の難易度が上がっていることや、独自の評価制度の重要性、生産性指標への関心などが見えてきました。

Findyでは採用や組織支援サービスを提供していますので、サービスそのものだけではなく最近のトレンドなど知りたいCTO/EM/人事の方はお気軽にご連絡いただければと思います。

また、本記事でご紹介しているアンケートについては、以下のダウンロードページからホワイトペーパーとしてフルバージョンをダウンロードできますので、ぜひご活用ください。

ホワイトペーパーのダウンロードは[こちら](https://share.hsforms.com/1tV7tJhT0Rqyi7h3Dw6a1HQbymz5)
◆調査対象/方法
・対象者：Findyに過去お問い合わせのあった企業のCTO/EM
・有効回答人数：104名（エンジニア15人以上企業のCTO・EM）
・期間：2022年2月~2022年3月
・方法：ウェブアンケート

## サービスのご紹介
エンジニア採用サービス「Findy」：[https://findy-code.io/](https://findy-code.io/)
エンジニア組織支援SaaS「Findy Teams」：[https://findy-teams.com/](https://findy-teams.com/)
フリーランスエンジニアを探す「Findy Freelance」：[https://freelance.findy-code.io/](https://freelance.findy-code.io/)


CTOアンケートヘッダー画像（22/08）

今回、アンケート結果をまとめましたのでご共有いたします。エンジニア組織の運営を担うCTO/VPoE/EM（エンジニアリングマネージャー）にとって参考になる情報となれば幸いです。

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

記事一覧

爆速開発をしていくためのFindyの取り組み〜2022年編〜 - ファインディ株式会社

コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips - ファインディ株式会社

PR数は開発生産性のセンターピンかもしれない - 株式会社BuySell Technologies

生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話 - 株式会社BuySell Technologies

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

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

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

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

アイミツ開発チームの開発生産性をFindyTeams-DevOps分析してみた - 株式会社ユニラボ

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

記事一覧

爆速開発をしていくためのFindyの取り組み 〜2022年編〜 - ファインディ株式会社

コードレビュープロセスの負荷や時間を減らすために取り組んでいる10のTips - ファインディ株式会社

PR数は開発生産性のセンターピンかもしれない - 株式会社BuySell Technologies

生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話 - 株式会社BuySell Technologies

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

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

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

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

アイミツ開発チームの開発生産性をFindyTeams-DevOps分析してみた - 株式会社ユニラボ

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

爆速開発をしていくためのFindyの取り組み〜2022年編〜 - ファインディ株式会社