## 入社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倍！！プルリクを小さくたくさん作りさくさくマージするメリットとは？

## 約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割がエンジニア採用が難しくなっていると実感。独自性の高い人事制度運用や生産性向上に向けた定量データの利用も増加

## エンジニア組織の生産性はどう測る？

本記事では、ソフトウェアサービスを展開するIT企業を中心に、エンジニア組織の生産性を向上させるために見るべき指標について書いていきます。

結論から言うと、素早く、動くソフトウェアを顧客へ届けるために、エンジニア組織の生産性を測る要素としては以下の2点に集約されます。
 
- **ソフトウェアデリバリの速度**
- **ソフトウェアデリバリの安定性**

それぞれ解説していきますと、**1つ目のソフトウェアデリバリの速度は、ソフトウェアが顧客のもとへ届くまでの時間であり、プロダクトの企画〜運用までのプロセスを速く実行すること**が重要です（今回はプロダクトの企画・仕様作成の時間は除き、エンジニアがコードコミットしてから本番環境へデプロイされるまでの時間として言及いたします）。**2つ目のソフトウェアデリバリの安定性は、コードコミット〜デプロイするまでの障害および障害に対する復旧の時間であり、顧客へきちんと動くソフトウェアを届けること**が重要です。

これら2つの要素は、以下の指標として数値化し、定点観測することが可能です。
 
- **ソフトウェアデリバリの速度**
 - デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
 - 変更のリードタイム - commit から本番環境稼働までの所要時間
- **ソフトウェアデリバリの安定性**
 - 平均復旧時間（MTTR：Mean Time To Restore） - 組織が本番環境での障害から回復するのにかかる時間
 - 変更失敗率 - デプロイが原因で本番環境で障害が発生する割合（%）

上記は、<a href="https://www.amazon.co.jp/Lean%E3%81%A8DevOps%E3%81%AE%E7%A7%91%E5%AD%A6-Accelerate-%E3%83%86%E3%82%AF%E3%83%8E%E3%83%AD%E3%82%B8%E3%83%BC%E3%81%AE%E6%88%A6%E7%95%A5%E7%9A%84%E6%B4%BB%E7%94%A8%E3%81%8C%E7%B5%84%E7%B9%94%E5%A4%89%E9%9D%A9%E3%82%92%E5%8A%A0%E9%80%9F%E3%81%99%E3%82%8B-impress-gear/dp/4295004901" target="_blank" rel="noopener noreferrer">『LeanとDevOpsの科学』</a>という書籍からの引用となりますが、これらソフトウェアデリバリの指標(Four Keys：4つのキーメトリクスとして紹介)は、組織全体のパフォーマンスおよび企業の業績に好影響を与える、という科学的な根拠をもって実証されています。

また、このソフトウェアの速度と安定性は互いにトレードオフの関係性ではなく、両立しうるものである(ソフトウェアデリバリのプロセスの質を上げれば、速度も安定性も向上する)と本書では紹介されています。

実際に、パフォーマンスが良好な組織とそうでない組織では、
 
- **ソフトウェアデリバリの速度**
 - コードでのデプロイ頻度は46倍
 - コミットからのデプロイまでのリードタイムは1/440

- **ソフトウェアデリバリの安定性**
 - 平均復旧時間(稼働停止からの復旧に要する時間)は1/170
 - 変更失敗率は1/5

というほどの差分があり、**パフォーマンスが良好な組織は指標すべてにおいてハイパフォーマンスな成果を上げている**ことが見てとれます。

以下<a href="https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance" target="_blank" rel="noopener noreferrer">Googleが投稿した記事内</a>におけるソフトウェアデリバリのパフォーマンスを分類した表も自社のエンジニア組織の生産性を測る指標として参考になるかと思います。

![Calculating the metrics.max-2800x2800][1]

## エンジニア組織の開発アクティビティを把握しよう

エンジニア組織における生産性指標は理解できた一方で、それらを指標として定量化/可視化する仕組みがない、という企業様は少なくありません。

そのようなケースにおける解決策の一つとして、GitHubのようなソースコード管理ツールによって、まずはソースコードベースでエンジニアの開発アクティビティをログとして残せる仕組みを取り入れる方法があります。

**ソースコード管理ツールを活用することで、エンジニアの開発アクティビティが履歴化されるとともに、共同での開発作業が円滑になり、チームでの開発効率はよくなります**。

## エンジニア組織のソフトウェアデリバリを可視化しよう

次に、Four Keysに関連する指標を定量化する必要があります。

Findy Teamsでは、GitHubやGitLab、Jiraなどのエンジニア向けツールのデータを取得し、エンジニア組織のパフォーマンスを可視化することが可能です（Findy Teamsのサービスに関しては<a href="https://findy-teams.com/service_introduction" target="_blank" rel="noopener noreferrer">こちら</a>をご覧ください）。

お客様からのご要望が強かったこともあり、現在Findy Teamsでは『DevOps指標』として、Four Keysに関連する指標をご覧いただけるようになっておりますので、最後にそちらをご紹介したいと思います。

## Findy Teamsの『DevOps指標』を活用しよう

Findy Teamsでは、『DevOps指標』として、以下の指標を見ることができます。
 
- **デプロイ頻度** - デプロイ設定に応じて算出した期間内のデプロイ回数
- **変更のリードタイム** - 期間内にメインブランチへマージされたプルリクにひもづくcommitからマージまでの所要時間
- **変更障害率** - 期間内にメインブランチにマージされたプルリクのうち、hotfixブランチからのプルリクが占める割合
- **平均修復時間** - 期間内にメインブランチにマージされたプルリクのうち、hotfixブランチまたは、revertブランチに紐づくコミットの最初のコミットからメインブランチへのマージまでの平均時間

![DevOps分析画面](//images.ctfassets.net/ngrpflsbp3rq/8hEufdU0P48YfKM7Yggai/40e5fdf8327d0dba0904a2df2b32964f/DevOps____________.png)

（Findy Teamsを導入いただいている企業様は<a href="https://findy-teams.com/analytics/teams/?range=last_month" target="_blank" rel="noopener noreferrer">こちら</a>から直接操作画面にアクセスできます）

また、デプロイ頻度の先行指標として、プルリク・レビュー・マージ/クローズごとの開発アクティビティや、開発リードタイムを可視化することができます。

![記事用 スタッツ][3]

自社内でもDevOps指標およびそれに係るプルリクベースでの開発アクティビティや開発リードタイムを把握し、エンジニア組織の生産性改善に繋げています。
結果として、開発効率は3倍上がりました（詳細な取り組みの内容は<a href="https://engineering-org.findy-teams.com/posts/developer-experience-improvement/" target="_blank" rel="noopener noreferrer">こちら</a>からご覧ください）。

そのほか、導入企業様からも<a href="https://engineering-org.findy-teams.com/tech_blog/" target="_blank" rel="noopener noreferrer">Findy Teamsの指標を活用した生産性向上の取り組み</a>は増えてきています。

様々な企業様のエンジニア組織づくりのご支援をさせていただく中で、このようなデータを活用した取り組みには、採用効果があり、改善するエンジニア組織に優秀なエンジニアが集まりやすい、ということもわかりました。

**エンジニアが生産性高く働ける仕組みを取り入れることで、開発者体験の向上および企業業績の向上、また採用効果への影響など、さまざまなメリットがあります**。

貴社は、このようなデータを活用した取り組みはされておりますでしょうか？
この機会に、データを活用したエンジニア組織づくりをしてみてはいかがでしょうか？
本記事が、自社のエンジニア組織改善の参考になりましたら幸いです。

以上、最後までお読みいただき、ありがとうございました！

現在エンジニア組織について悩んでいる、Findy Teamsにご興味があるという方は、<a href="https://findy-teams.com/contact_teams" target="_blank" rel="noopener noreferrer">こちら</a>より資料請求・お問い合わせ頂ければと存じます。
(※2週間の無料トライアルも可能となっております！！)

引き続き、Findy、Findy Teamsをよろしくお願いします！

[1]: //images.ctfassets.net/ngrpflsbp3rq/7nNHkV76CSOnIEV0WRpPFU/fbbe0427b46dadeaa7427393022cbb6f/Calculating_the_metrics.max-2800x2800.jpg
[2]: //images.ctfassets.net/ngrpflsbp3rq/4Orovzob7IX4uArI7Lm7go/4cba0d3db27bf1bf757ee05a1b542a1b/__________devops______.png
[3]: //images.ctfassets.net/ngrpflsbp3rq/1jObvPo1OWN0aLUtFp3pe1/6936428be99a563b1d7e0f1f570af078/______________________.png

devops_metrics

エンジニア組織の生産性の可視化をテーマに、”素早く、動くソフトウェアを顧客へ届けるためには”どのような指標をみればよいのかの一例について書いていこうと思います。

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

## 開発者体験の改善

Findyでは自社で開発者体験向上クラウドFindy Teamsを開発していたこともあり、数字を見ながら開発組織の改善に取り組んできました。
 

- <a href="https://findy-teams.com/service_introduction" target="_blank" rel="noopener noreferrer">Findyの開発スピードが1年で約3倍になった結果、ユーザからの反応は格段に変わり、未知の課題にぶつかった</a>
- <a href="https://engineering-org.findy-teams.com/posts/mbo-2021/" target="_blank" rel="noopener noreferrer">データを活用した目標設計と運用にトライした1年間を振り返ってみた</a>

なかでも大きくは2つのことに取り組んでおり、**1つ目はエンジニアが快適に開発できるための環境づくりへの投資**、**2つ目はエンジニアメンバーがデータを活用したオブジェクト（目標）設定を行なったり、データを活用した1on1や振り返りを行うこと**です。具体的には以下のような内容に取り組んできました。

### 1.快適な開発環境づくり

- テストのカバレッジを上げる
- フロントエンドとバックエンドの分離
- SentryやDatadogなどエラーや障害監視のツールを積極的に導入
- ReactからTypeScriptへの移管
- GraphQLの導入
- エンジニアのMacを50万円まで購入可に変更

など**機能開発にはすぐには繋がらないものの、開発者の生産性を上げるための取り組みでできることを積極的に取り組み、ストレスなく心理的な不安をできる限り減らした開発環境を作る取り組み**をしています。

最初はフロントエンドとバックエンドの分離をやるので3ヶ月は新規機能開発が止まるかもしれない、といった話を聞くと経営者としては「まじで！？それは厳しい」などと考えるものですが、今は改めて投資を決断してよかったと思っています。

### 2.データを活用したマネジメント

- プルリク作成数などデータをもとにオブジェクトを設定
- データをもとに1on1でマネージャーとメンバーが現状の確認を行う
- 個人の振り返りについてもデータをもとに行う

Findyでは、**プルリク作成数やプルリクの平均クローズ時間などを目安として目標設定したり、振り返りを行うデータを活用したマネジメント**にトライしてきました。これを持って評価するのではなく、あくまで日々の個人や組織の改善や成長にデータを使うスタンスです。

例えば1on1などでは、データを通して現状の確認を行うことで、実はその時間が短くなり、エンジニア個人の将来的な成長に対するディスカッションやプロダクト周りで気になる点など、話題の幅が広がるなどの結果に繋がっています。

結果的には普段行っている社内のサーベイなどの数字も右肩上がりでよくなっています。

## アウトプット量が3倍以上に増加

まずは下表を見ていただければと思いますが、マージ済プルリク数やコミット数が全体でも一人当たりでも見ても大幅に増加しています。2020年上期と2021年下期で比較をすると

- 一人当たりのマージ済プルリク数：3.2倍（開発アクティビティ/量の向上）
- 平均プルリク クローズ時間：5.3倍（開発効率/スピードの向上）

などが起きています。またこの間の1プルリクあたりの平均変更行数はそれほど変わっていないので、大きな改善をしている可能性が高いと言えます。

![工数試算](//images.ctfassets.net/ngrpflsbp3rq/2LTt4xJECps2RBZKd9bsnK/77a9599e0296bd6f00bbf9217461e29b/____________________________2022-02-20_23.53.09_2.png)

実は、2021年上期に関してはリファクタリングなどにも時間を使っていたため、1プルリクあたりの平均変更行数などはむしろ長くなってしまっており、これだけで単純なアウトプット量の増加とは断定しにくい部分はもちろんあります。

ただ、プロダクト企画を担当している自分の感覚としては確実に一人当たりの開発ボリュームは増えてきており、**嬉しい悲鳴ですがイシューを作っても作っても解消されていくので企画やデザインが圧倒的に足りていない状況**になってきています。前職からWebの世界に入ってはや12年以上ですが、こういった状況は初めてかもしれません。

## 金額で計算すると1.8億円のアップサイドの効果

上記のアウトプット量の改善に関して、金額ベースでも換算してみました。
すると、**2020年上期ベースで2021年の開発を行っていた場合と改善後で比較をすると実に「1.8億円分」の追加開発ができていることが計算**できました。あくまで机上の計算ではありますが、我々のような小さいスタートアップでこの差分は非常に大きく、開発者体験向上に力を入れてきた意思決定が間違いない点を強く感じました。

- 1マージ済みプルリクあたりのコスト：2020年上期34,804円→2021年下期14,311円/2.4倍（効率の向上）

**2020年上期の水準で開発をしていたら2021年の開発費が3.2億円かかっていたところが1.4億円ベースで本来取り組みたいことができていた計算**になります。これは単純に採用計画を立てていたものにミートできなかったことが大きいのですが、結果的にはプロダクトの進捗に関してそれほど遅れることなく事業目標も達成できた2021年になりました。

2020年から開発上の課題を地道に解決してきた結果ですし、当然機能開発に繋がらない開発も積極的に取り組んでいるため全てが見た目上のプロダクトに反映されているわけではありません。

ただ、確実なプロダクト開発力の向上と進化を実現できており、手応えを感じています。
ちなみに、2020年上期のFindyの水準はFindy Teamsでみているとトライアル企業を含む全企業のデータの中では真ん中かそれより少し低いくらいの位置付けでした。

つまり、上記のような改善を実現、体感できる会社はまだまだたくさんあるのがデータからもわかってきています。

## テックジャイアントも開発者体験や生産性に注目

開発者の体験や生産性を語る際にあくまでデータはその一部に過ぎないと考えています。
例えば、上記で記載したプルリク作成数が多ければ必ずしも良いというわけではないですし、開発しているプロダクトの種類や開発スタイルによって、注力するべきデータも異なります。

例えばアプリを開発しているチームではまとめてリリースする際にマージを行っており、どうしても最初のコミットからプルリク作成までの平均時間は長くなる傾向があるかもしれん。

ただ、以下のリンク先でもGoogleなどが開発ポリシーとして、レビューを1日以内に行うためにプルリクの数を小さくすることに言及しています。

- <a href="https://google.github.io/eng-practices/review/reviewer/speed.html" target="_blank" rel="noopener noreferrer">Googleエンジニアリングプラクティス[コードレビューの速度]</a>

また、先日ヒアリングした海外の企業に所属するエンジニアの友人はコミット単位でマージまでの時間を測定していると話していました。むしろ高いレベルのエンジニアが集まっており、快適に開発を進めるために開発速度やレビュースピードは前提の条件という話もしていました。

グローバルではデータを活用して開発者体験を向上することで、結果的にアウトプットの量も最大化していくアプローチに注目が集まってきています。

## まだまだこれから！という企業の方はぜひデータの可視化から始めてみませんか？

最後までお読みいただきありがとうございました。

Findyでは、Findy Teamsを通して、エンジニア組織の開発者体験向上、生産性の可視化によるパフォーマンスの最大化を支援いたします。

Findy Teamsにご興味ある方は<a href="https://findy-teams.com/contact_teams" target="_blank" rel="noopener noreferrer">こちら</a>からお問い合わせください。

また、Findy Teamsを活用して、開発者体験向上に積極的な企業様も増えております。こちらもぜひご覧頂ければと思います。
<a href="https://findy-code.io/pick-up/articles/developer-experience" target="_blank" rel="noopener noreferrer">開発者体験（Developer eXperience）向上に積極的な企業特集《「Findy Teams」で組織のパフォーマンス改善に取り組み中》</a>

引き続きよろしくお願いいたします！

Findy Teams_開発者体験向上_Findy取り組み

FindyではFindy Teamsの開発を通して、自社の開発者体験(Developer eXperience)向上にも積極的に取り組んできました。そこで開発者体験向上に取り組んでみえた定量的な改善結果について書いていきたいと思います。

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

## 2021年初頭に起きていたこと
2021年初頭、<a href="https://findy-code.io" target="_blank" rel="noopener noreferrer">Findy</a>、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>の開発プロセスは全体的に課題が多く、無数の課題に悩まされていました。

- リリースが毎週1回
- CIが回るのに30分
- ビルドするのに1時間
- ユニットテストカバレッジ30%
- プルリクがコンフリクトしやすい
- ファーストレビューまで3〜5日かかる
- JavaScript + FlowType
…

どれも課題は大きく、数年かけて直しながらプロダクトを作る必要ある…という状態でした。

## 2021年末の実績

2021年、ここで大きな決断をしました。新機能の開発をなるべく減らして、開発者体験を良くし、圧倒的に爆速で顧客価値提供をできるようにする。開発力2倍。

開発スピードを上げることで全てが解決するわけでもないですが、まずは単純に顧客価値提供が1週間で1回は少ないなというのを解消したい。小さな改善でもいいから秒で出していかないともったいない。初期は1人で作っていたのですぐに出せていた。あの感覚をチームでやりたい。

詳しくは過去の記事に書きましたが、

- リリースはフロントエンドで1日1〜2回、バックエンドも1日1回
- CIはフロントエンド最短30秒、バックエンドも最大10分
- リリースビルドは数分
- ユニットテストカバレッジ90%
- レビューは土日のバッファ入れても5時間
- TypeScript化

様々な課題を潰してきました。

プルリクエストが2021年初頭は1人1日平均0.8件のプルリク数でしたが、現在は1人あたり2.2件まで増えました。月間だと、1人あたり44件ほど作成し、99%が対処され放置されているプルリクがほぼない状態になりました。

## よかったこと: ユーザからの反応が圧倒的に良くなった
この開発者体験の向上を行った結果、2021年前半は特に無風でしたが、後半からは「ツイッターで呟いてからバク対応完了まで5時間は早すぎます(笑)」といった声だとか、「カスタマーサクセスの方にフィードバックするとすぐに実装してくれるのでフィードバックしがいがある」とまで言っていただけるようになりました。圧倒的に反応がよくなったなぁと思うことができるようになり、会社内でも「早いｗ」という声が多数出てくるようになりました。ありがたい。

フィードバックしても変わらない体験があるとどうしてもフィードバックしなくていいなと思っちゃいますが、変わるとわかると少しでも声あげやすくなるのかなと思います。実際に僕も反応が早いサービスなどはよくメッセージ送ったりしています。

その他にも、Findy社の採用も進めている中で、「Findyの開発は爆速って仰ってましたが、実際にお問い合わせ連絡してから爆速で修正完了の連絡が来たので受けに来ました」と仰ってもらうこともありました。

一重に、開発に関わってもらっている全てのメンバーの頑張りに感謝です。改めてありがとうございます。

2021年はスピード感ある開発ができるようになり、当初考えていた開発基盤の改修はできてきた、というところではありましたが、最近起きた課題もあります。

## 課題: 圧倒的に企画の量が足りない
2021年は佐藤の企画と仕様作成で回っていた状況でしたが、

- 開発基盤に関する課題が徐々に減ってきた結果、新規で機能が作れるようになった
- 新規で機能が作れるようになった結果、イシューが消化できるようになってきた
- イシューが消化できるようになってきた結果、企画のサイクルがボトルネックになってきた

という状況になりました。1年前には想像もしていなかったような課題が課題になりました。

- PdMの採用よりもエンジニアメンバーの採用に力を入れていた
- 企画メンバーがそこまで増えていなかった(大きな反省)
- かつ僕や代表の山田が企画も兼務していたが、別課題で時間が取られていた

エンジニアの採用も非常に大変ですが、PdMの採用も困っている方多いんじゃないでしょうか。弊社もやはりここは大変なポジションではあります…！ｗ

2022年の前半は企画スピードを上げるために、

- メンバーを育成して企画力を上げる
- メンバーを採用して企画チームを増やす
- 企画が増えるとデザインできるメンバーも必要になるので採用する

というような動き方が必要になりそうです。

この経験でわかったこととして、エンジニアリングの課題が解決すると、プロダクト開発全体の課題のどこかがボトルネックになっていくのだな、ということを身にしみて感じました。開発スピードがいきなり早くなったという経験が初めてだったので、早期に予見できなかったなぁと改めて反省です。

## 創業メンバーと一緒に企画づくりしたい方、PdMやりませんか？
ここからは宣伝ですが、上記のようなプロダクト開発のスピードを挙げていくために、代表の山田や僕と企画をしたいPdMの方いませんか？

- Findyのビジネスドメイン(エンジニア組織づくり、エンジニアのキャリア)に興味のある方
- 事業全体を見ながら企画し、爆速で意思決定したい方
- ユーザの声を聞きながら数値を見てトライアンドエラーしたい方
- Findyのバリューを体現できる方

是非興味ある方は<a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">こちら</a>から！

是非お待ちしてます！

## 「開発スピードを上げる」ことは「爆速で顧客価値提供する」ための必要条件

<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>などで開発スピードを定期的に観測していくと、「数値を良くしないといけない！」となったりする方もいると思います。

開発スピードは早いに越したことはないですが、開発スピードを早くしようとして「ユーザに向けた機能提供や改善が0」「開発が遅くて開発の遅い人を咎める」などの本質からズレた状況になってしまうといくら開発スピードが早くてもユーザから見て価値はゼロです。何も変わってないサービスですよね。

エンジニアリングの範囲は企業によりますが、開発スピードを意識しながらいかにユーザの価値になっているかを考え続けられる組織が一番強いと思います。また、「開発をしない選択肢を取ることで開発スピードも考えなくて良くなる」のが費用的にもスピード的にも最強ですが…ｗ

エンジニアリングをやっているとユーザのことを棚に上げて自己投資を多くしてしまうこともあるかと思いますが、チームでサービスを提供する以上、様々な要素を考慮してユーザファーストのものを作れることがいいかと思います。それが前提での「開発スピードを上げるのももちろん大事で良いことである」というのが僕の答えです。

開発スピードは上がったことでトータルのユーザへの価値提供スピードも上がったのはとてもいいことではありますが、今の所Findyでは他の工程のスピードがボトルネックになっている状況です。つまりは改善が見込まれてくるなら先手を打って別な箇所の改善/全体最適を行うべき、というのが得られた結論でした。

とはいえ、今回の事象を通じて開発スピードを上げることは、全体最適とは必ずしも言えないが、よくボトルネックになりがちな開発スピードを上げることで価値提供スピードのインパクトを十分に上げることができるというのがわかりました。

開発スピードを上げるには、定量的に分析するのが最良だと思うので、是非<a href="https://findy-teams.com/" target="_blank" rel="noopener noreferrer">Findy Teams</a>を使って現状の自社の開発スピードを可視化していくのがおすすめです！

findy-speed-up-img

Findyで開発力を2倍にしていくぞ！と改善を繰り返した結果3倍の成果になったのですが、そこから得られた話を書いてみます。

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

## 前提: 営業ほど簡単に決められない、測りにくい

営業の目標設定ってわりと「売上:XX万円達成」で計測しやすいですよね。

一方で管理部門やデザイナー、そしてエンジニアは目標設定がなかなか難しい職種ではあります。

エンジニアですと、「1行のコードを書いた＝売上XX円」が分かるのであれば簡単なのですが、世の中そんなうまくいきません。

だからこそエンジニアの成長度合いを、目標設定と振り返りを常に実施することで可視化し、「過去の自分と比べてどのくらい成長できたか？」を確認することが大事だと思っています。

今回はプロダクト開発において、[Findy Teams](https://findy-teams.com/dashboard)を活用してどのように目標設計をして、どんな振り返りをやっているのかについてまとめてみました。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## やったこと① Findy Teamsで可能な限り計測できる指標を追う

例えば、「バックエンド開発を頑張る」という一言だけでは、何をどう頑張ったらリーダー・メンバーの双方が納得のいく「頑張り」になるのかが分かりません。

特に良いコードを書いたり、チーム開発ができてる場合に、[Findy Teams](https://findy-teams.com/dashboard)で追うと良さそうな指標としては以下が挙げられます。

### アクティビティ量
 - **プルリク作成数**
 - どれだけ変更提案したか？の数
 - 変更提案数が多ければ多いほど進化している、という前提
 - 1日1プルリクを追うであったり、定常的に毎日コード書けてるかを確認
 - **自分がレビューしたプルリク数**
 - 人のコードをどれくらい読んだか？の数
 - 読めば読むほど時間はかかるが学びにつながる、という前提
 - **1プルリクに対する平均コメント数**
 - 他の人からどれだけツッコミが入るか？の数
 - 提案に対して意見がなければ、コメント数も少なくなりやすい
 - 逆にジュニアなメンバーだとコメント数が多くなりやすい

### リードタイム
 - **1プルリクあたりの平均マージ・クローズ時間**
 - 変更提案してから提案が受け入れられるまでの時間
 - 変更提案したものに物議を醸す場合や修正に手間取る場合、この時間が遅くなる事が多い
 - 優秀な人ほど端的に狭い範囲で良いコードを書くため、この時間が短い傾向にある
 - **最初のコミットからプルリク作成までの平均時間**
 - コードを書き始めてから変更提案するまでの時間
 - 変更提案したいものを作るまでにどれくらいの時間を要しているかが分かるので、力量が把握しやすい
 - 同様に優秀な人はこの時間が短い傾向にある
 - **プルリク作成からレビューまでの平均時間**
 - 他人のレビューをすっぽかして他人の待ち時間を増やしていないか？かが分かる
 - この数値が遅い要因は、①レビュー依頼をできていないか、②依頼はしたがレビュワーが気づいていないのか、③レビュワーは気づいているものの手元のタスク消化等を優先して着手してくれていないのか、のいずれか
 - 爆速でレビューする体制になっているチームほど健全

もっとありますが、ベーシックなところはこんな感じです。

メンバーは、この指標のいずれかで課題がありそうなものや定点観測すべきものをリーダーと相談して選び、自分の目標を作ります。（=メンバーとリーダーの期待値の目線合わせ）

### 目標設計のサンプル
- 目標の方向性:高速開発を実現し、顧客への価値提供スピードを上げる
- 観測する指標: **一ヶ月あたりのプルリク作成数**
- 目標値: 半期終了時点で現状の2倍が最大目標。最低でも1.5倍

- 月別の目標(最小-最大、一ヶ月あたりのプルリク作成数)
 - 1月（前期初）: 40 - 50
 - 2月: 50 - 65
 - 3月: 55 - 70
 - 4月: 65 - 80
 - 5月（前期末）: 70 - 85

- ※昨年参考
 - 9月: 40(リリース込45)
 - 10月: 35(リリース込40)
 - 11月: 45(リリース込50)
 - 12月: 60(リリース込90)

- 評価点（評価分類は各社によって異なりますが､､､）
 - 7:120プルリク以上
 - 6:90プルリク〜120プルリク未満
 - 5:72プルリク〜90プルリク未満
 - 4:60プルリク〜72プルリク未満
 - 3:42プルリク〜60プルリク未満
 - 2:30プルリク〜42プルリク未満
 - 1:30プルリク未満

※数値化しやすいものは定量評価にて数値化し、定性的なもの（新技術提案や外部発信の影響力を上げる、計測が難しいマインド等）は定性評価にするなど、評価方法を分けていました。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## やったこと② 毎月の1on1で定点観測してメンバー自身に振り返ってもらう

メンバーとの1on1は毎週行っていましたが、月初の1on1だけは目標の振り返りを行っていました。

【4月時点での振り返りイメージ】
- 1月: 47　→お問い合わせ対応が多く想定よりプルリク作成数を増やせなかったので、△
- 2月: 62　→細かい改修が多く対応した数が多かったので、◯
- 3月: 59　→差し込みの調査が多い中で、ギリギリ◯
- 4月: 54　→チャレンジしたことないタスクを実施したため、下がった△
- 5月:
- 6月:

【考察】
- 2月の増加要因
 - 確認や調整などが少なかったため
 - 　企画A → マーケ/フロントエンドとの調整を先に実施できたため
 - 　メールの改修 → 想定より簡単に切り出して開発できたため

- 3-4月の減少傾向の要因
 - 　新規のタスクや差し込みが多く開発時間の確保が難しかった
 - 　チャレンジタスクが多かったので難易度が上がった
 - 　一方で不具合対応などによる修正対応PRの増加もあり、極端に減少はしなかった

上記のようにまとめておくと、最後に総括がしやすくなります。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## やったこと③ 振り返って目標を変更・追加する

目標設定から何ヶ月か経過すると、「 目標が無謀すぎる 」「 一瞬であのタスクやらなくなった 」等が発生し、目標が意味を成さなくなる事もあるかと思います。

なので、最初に2つか3つくらいの目標にしておきながら、

1. 既存の目標の100%達成の目標値を上方・下方修正する（下方したら新しい目標を置くことをセットにしていました）
2. やらなくなったタスクの代わりに、3つ目や4つ目の目標として新しく目標を作る

等の運用にすることで、目標を常にアップデートできるようになります。

例えば、「1月にプルリク作成数の目標を60と設定したにもかかわらず、3月にはお問い合わせがチームで課題になり、対応を率先してやっていきたいと思う」となった時に、

- お問い合わせにかかる工数は毎日1時間〜2時間程度
- 現状のプルリク作成1つに対して2時間程度かかるものが多いので、1日1つ減らす
- 期中の4月以降以降は平均40プルリク作成に落とす

と目標をアップデートして、1on1でメンバー・リーダーで目線合わせをすると良いのかなと思っています。

すると期末には以下の様な状況になります。

- 目標は実態に応じて毎月すり合わせてるので、目標と実態のブレとしては最大1ヶ月程度
- メンバーは結果を毎月振り返って記載しているので、半年前の状況を思い出す必要がない（思い出すのは結構大変）
- メンバーは自分の推移がわかるので、次期に向けて目標を定量的に考えやすい
- リーダーは過程を見ているので直近のパフォーマンスだけを見て評価することを回避できる（評価は、往々にして直近のパフォーマンスに引っ張られがちかなと思います）
- リーダーは他の部署とのすり合わせ時に、メンバーの評価結果の妥当性を伝えやすくなる（チームによって、タスク難易度や繁閑度合いは変化するものの、[Findy Teams](https://findy-teams.com/dashboard)の指標を統一指標として用いることができるため）

など。

逆にこのすり合わせを適当に行っているとコミュニケーションに差が出て「リーダーは分かってくれない」「メンバーが頑張ってくれない」という、認識ギャップが減るのではないかなと思います。

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

## まとめ

過去に様々なCTOの方と話してきましたが、この目標設定と振り返りの過程でいちばん大事なのは「 お互いの納得感 」ということであるのがわかったのが2020年で、そこから2021年はどう納得感を作るかにトライしてきました。

これはエンジニアであってもなくても変わらなくて、お互いの期待値を何度もすり合わせ続ける（=期待値合わせ）ことが大事なのではないかと思っています。
この期待値合わせのための定量的な指標として[Findy Teams](https://findy-teams.com/dashboard)をお使いいただくと、客観的な視点で議論してすり合わせができるため、良いのではないかと思います。

- リーダーはどんなことを期待するのかを明確にして伝える
 - ex. まずはこの半年でバックエンド開発においてどんなタスクがきても一定こなせる状況を期待する、等
- メンバーは
 1. 半年後、一年後どうなりたいのかを考える
 - ex. テックリード？新しい領域としてフロントエンド？EM？…
 2. 半年後、一年後になりたい自分になるためにクリアしなきゃいけない課題は何かを考え続ける
 - ex. 簡単な改修含めてレビューの件数を減らしていく
 - ex. アウトプット量（プルリク作成数等）を増やしていく
 - ex. 安定して高パフォーマンスを発揮できるようになる

これをやり続けることで、期末にリーダーから「全然やれてないよね？」vsメンバーの「やってって言われたことやったんだけど全然認識違う」という認識ギャップが発生しにくくなります。

常に自分のなりたい像をリーダーに伝え続けて、どうすべきかを真剣に考えて、それをアップデートし続ける状態がいいなと思っています。

人間だし、特にスタートアップに来てる人なんてやりたいことが変わったりしやすいと思います。

変わった瞬間や変わりそうな瞬間や悩んだ瞬間にリーダーと話したり、周りの信頼できるメンバーと話して常に悩みを解決できる状態を作っていきたいですし、そのための定量的な指標として[Findy Teams](https://findy-teams.com/dashboard)を使ってみてはいかがでしょうか！

※Findy Teamsに関するお問合せはこちら
https://findy-teams.com/contact_teams

※Findy Teamsサービスの詳細は以下よりご覧いただけます。
https://findy-teams.com/service_introduction

※Findy Teamsのサービス画面は以下よりご覧いただけます。
https://findy-teams.com/dashboard

FindyTeams_MBO_2021振り返り

こんにちは、Findy CTO の @ma3tk です。 FindyではFindy Teamsを活用したエンジニアの目標設定に取り組み始めましたので、具体的な活用方法にも触れつつ、お話したいと思います。

データを活用した目標設計と運用にトライした1年間を振り返ってみた

## 技術レベルが高い⇨テックリードのスキル偏差値が高い

エンジニアの多くはハイスキルなエンジニアと働きたいと思っています。すでにハイスキルの人であれば近いレベルの人と一緒に働いた方が共通言語で語り易いですし、まだジュニアやミドル層であればレベルの高い人と一緒に働くことが成長に繋がります。

Findyの転職サービスではGitHub上でのOSS活動をスキル偏差値として算出しています。もちろんOSS活動を一部評価、可視化しているに過ぎないのでこれが全てではありませんが、一方でOSSを真剣に取り組んでいる人でスキルが低い人は少ないのではないでしょうか。

シンプルに先日お話しさせていただいたテックリードのスキル偏差値は高くってOSSに積極的なメンバーですよとお伝えすると刺さります。

![スキル偏差値](//images.contentful.com/ngrpflsbp3rq/4i1RCwfKzrncgG3NfBpWxT/cb85579493a4d8d02f0c3d298630fe64/______________________________UI-1536x738.png)

## 開発プロセスにストレスが少ない→開発リードタイムが短い

次に、「平均プルリク クローズ時間」や「最初のコメントまでの平均時間」（レビューまでの時間）などが早いことをアピールしています。これはエンジニア組織支援クラウドFindy Teamsで見える数字を活用しています。

以下の画像の通りでFindyは一つのプルリクがほとんど当日、また遅くとも翌日にはクローズされる、また毎日リリースできる体制をとっています。

![リードタイム直近](//images.contentful.com/ngrpflsbp3rq/2WGSEu4Wot3q9ydC9IzYPp/e7aa7e31a9919b9f9352462aba3ebaaf/____________________________2021-09-23_11.01.47.png)

また、レビューまでの時間も3〜4時間以内で必ずくる体制を構築しており、プルリクを出したらす半日以内に誰かがレビューをくれるような感覚です。せっかく開発したのにレビューを待たされる、あるいはレビューが遅いので並行で複数のプルリクを対応していたらミスが起こりやすくなるなどを防いでいます。

他にレビューを早くするために、テキストで解決できない場合はすぐにオンラインで話すというスタイルをとっています。そうすることでストレスなく開発を進められる環境を実現しています。

## 改善意欲が高い→リードタイムが1年半で4倍のスピードに

Findyの開発効率は1年でリードタイムで見ると4倍に加速しています。この間、プルリク作成数も増加しているので、もちろんメンバーは増えていますが体感値でも月間の開発ボリュームが数倍になっている感覚です。

これはプルリクを細かくして数を増やし、レビュースピードをあげたり、テスト自動化やマイクロサービス化などを早期にトライしてきた結果です。

詳しくはグラフを見ていただけると幸いです。

2020年1月〜3月だと平均プルリククローズ時間に84.3時間かかっています。

![リードタイム2020/1/1-3/31](//images.contentful.com/ngrpflsbp3rq/3e5zJzk8dJeImW8fIWqtri/9e1f584fc28fd2314f257ce0e4148064/____________________________2021-09-23_11.10.23.png)

それが、2021年4月〜6月だと17.1時間まで下がってきています。スピードアップですね！

![リードタイム2021/4/1-6/30](//images.contentful.com/ngrpflsbp3rq/5gDhmvyEDTuWU8tyXs8k7k/e0c3cc5002e5039594f735cdf67194f8/____________________________2021-09-23_11.10.44.png)

また、同期間に以下の通り1日あたりのプルリク作成数も大幅に増えており、1日数件から30~40件くらいまで実に10倍くらいに増加しています

![タイムライン2020/1/1~2021/6/30](//images.contentful.com/ngrpflsbp3rq/3D3GtM9xctXT6No06wKjnF/9e4484b91d8eb3b155275b79aaec91e9/____________________________2021-09-23_11.11.33.png)

もちろん、プルリクの粒度の問題もありますし、プルリクの数だけで判断できない部分はあると思いますが、改善という意味では確実に進んでいます。

## エンジニア組織のMIPもデータで見える化→エンジニアの頑張りを全社で賞賛

会社表彰やMVPといえば「営業成績No.1」の人が獲得することが多いのではないでしょうか。エンジニア個人の価値はなかなか見える化しにくいため、全社でMVPと言われてもなかなかビジネスサイドまで理解されにくいことが多いのではないかと思います。

ちなみにFindyでは2020年下期の全社MVPはテックリードで、上記の開発リードタイム4倍を推進したメンバーですし、2021年上期もMIP（最も成長した人）という位置付けでエンジニアメンバーが全社表彰されています。

以下がMIPを取ったメンバーの活躍を時系列で現したグラフです。イシュー作成、プルリク作成、レビュー数など全てのアクティビティが大幅に増加しています。本人もFindy Teamsを実際に見ながら、改善を進めてきた結果とのことで、活動量だけではなくアウトカムも増えてますし、本人の自信を持って仕事に取り組んでくれるようになりました。

![メンバー詳細](//images.contentful.com/ngrpflsbp3rq/3MAjeQ0cxUD41lQUifOX0g/eaa49eae439d4ba62bdf7c7eaa5aa1da/_____________________.png)

以上、データで口説くエンジニアの最終面接、いかがでしたでしょうか？
ぜひぜひ、試してみたい企業様がいらっしゃいましたら、[こちら](https://findy-teams.com/service_introduction)問い合わせいただければ幸いです。


data-interview

エンジニアを採用したいけど、内定は出しているけど、なかなか承諾まで進まない。そんなエンジニア採用の悩みは抱えている企業は多いのではないでしょうか。FindyではFindy Teamsのデータを活用して口説くエンジニアの最終面接にチャレンジしており、その事例について書きました。

データで口説くエンジニアの最終面接。ハイスキルな人ほど効率良い組織で集中して働きたい？！

> ## エンジニアリング組織として大事にしたいこと

僕らFindyの開発チームは大きく2つありますが、その中でも開発チームで大事にしたいことは、「爆速顧客価値提供」です。

いかに早く課題を見つけ、その課題を爆速で解決していくか、ということを念頭に置きながら開発業務を行っています。

こちらは7月から変わらず、継続の方針です。

大前提として、数値が全てではありませんが、振り返る上で大きな参考材料となります。数値を見てどう降り返るかを大事にしています。

## 2021年8月の実績

おおまかに、8月は21営業日あった中で、週5稼働しているメンバーは8名でした。
この状況下で、以下のような状態でした。

- リリース頻度 23.75回/month
- 1日あたり週5稼働メンバーで合計30プルリク、1人平均3.75プルリク/day
- 1日あたり週5稼働メンバーで合計117コミット、1人平均14.625コミット/day
- 平均プルリククローズ時間10.5時間
- 最初のコメントまでの平均時間3.2時間
- レビュー後クローズまでの平均時間5.2時間

それぞれいくつかのまとまりで振り返ってみます。

## リリース頻度 23.75回/月

- 開発Aチーム
 - バックエンド: 17リリース
 - フロントエンド: 30リリース
- 開発Bチーム
 - バックエンド: 25リリース
 - フロントエンド: 23リリース

ほぼほぼ毎日リリースできていたかと思います。

リリース自動化なども進めており、日々のQAコストも下がってきている成果が出ているように感じます。
今の所大きな課題もなく順調です。

## 1人 平均3.75プルリク/day、平均14.625コミット/day

7月と比べると、今月はプルリクの作成数とコミット数が少し減少しました。(とはいっても一定数あるので十分な量ではありますが…！)

8月は体調不良のメンバーがいたり、大きめの課題が多発し、課題解決まで時間がかかったケースが多かったと感じています。

体調不良の部分は各自体調を整えていくことが大事ではありますが、今月もワクチン接種などで休む予定のメンバーも居るため7月以上の平均の数を増やしていくのは難しそうです。

また、ユーザ数の増加によりお問い合わせの数も増え、開発メンバーが多少時間を取られたりすることもありました。こちらは企画側でもう少し対応できないかなど方法を検討中です。

課題が大きいものに関しては想定していたものでしたが、会社の成長を進めていく以上、すぐに取り組むべき課題となったので少ないメンバー数の中で対応することにしました。重いタスクをやっているとメンタル的にも苦しくなることがあるため、メンバーに負荷がかかりすぎないか9月は注視していきたいと思います。

## 平均プルリククローズ時間10.5時間、最初のコメントまでの平均時間3.2時間

先月と比べると、プルリクを出してから1.1時間ほど早くなりました。

プルリク作ってから10時間でマージまでいくとなると、月曜朝にプルリクを出して火曜にはマージされている状況です。あくまで平均になるため、ものすごく早いものと、日中の遅い夕方・夜の時間にプルリクを出して次の日にレビューされたり修正されたりなどするとこれくらいの時間がかかってくるのかなと思います。

1on1している限り、全体のレビューまでのスピードも十分なスピードで着手できており、着手後にもコメントを残すところまで行われている体制になっています。

## 総じて大きく変えなくてはいけない状況ではない

どの指標を見てもそこまで大きく課題はなく、十分いいサイクルで回せていると思います。

そこまで課題感のある時間ではないので、このまま継続して高スピードで開発サイクルを回せればと思います。

またメンバーが入ったタイミングなどで課題がまた可視化されるかと思うので、それまでは日々の1on1でメンバーと感覚をシェアしながら、数値ベースでも振り返っていければと思います。

## あなたのチームの平均プルリク作成数はどれくらいですか？

ここまでの情報は、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>で開発をしている部分もあり、簡単にデータが取得できます。継続的に測定できるため、自分の指定する期間でデータが取れるようになっています。

もしご興味があれば、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>までお問い合わせください！！

## 圧倒的なスピードで開発できるFindyで働いてみませんか？

もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でまだまだ成長できる組織です！上記以外にも課題もあります！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

<a href="https://meety.net/ma/matches/MvtiQWbHRQsx" target="_blank" rel="noopener noreferrer">Meetyでのカジュアル面談はこちら</a>

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>

august

こんにちは、Findy CTO の @ma3tk です。 Findy Teams を使ったエンジニアリング組織の分析を8月も実施してみようと思います。

2021年8月 Findy エンジニアリング組織の振り返り

## エンジニアリングマネージャーの不足
エンジニア組織における最大の課題はそもそもマネージャー不足しているということです。
エンジニアとビジネスサイドの差分は何か、それはマネージャーになりたい人の割合が違うということではないでしょうか？

以下の表の通り、Findyのアンケート調査でもエンジニアの将来という意味では約半分がテックリード、スペシャリスト思考であり、マネジメント思考の人は15%弱と少ない結果になりました。
また、データを持っているわけではないですが、ビジネスサイドは専門性というよりは事業数字でコミットする仕事が多いため、結果的にマネージャーを目指す人が多いようです。

![careerpath](//images.contentful.com/ngrpflsbp3rq/4VyAGCtekROC0ecBG0c83W/e7602dd6d54987283c92a533a5a3f207/careerpath.png)

[平均年収は614万円、35%が副業経験あり！2020年のエンジニア転職・キャリアトレンド最前線](https://engineer-lab.findy-code.io/jobchange_trend_2020sp)

## マネージャーのマネジメント対象人数が増加
マネージャーが少ない結果何が起こってしまうのか。シンプルにマネジメント対象の人数が多くなってしまうことです。
スタートアップにおけるエンジニアリングマネージャーの採用は困難を極めており、結果的に社員15~20人くらいまでCTOがマネジメントや評価をしているというケースもあったりします。加えて、フリーランスエンジニアも数人契約しているというケースも。。。

またもう少し組織規模が大きいスタートアップ、メガベンチャーでも配下メンバーの人数が10人以上の組織はあるようです。

結果的に1週間のうち大半の予定が1on1やビジネスサイドとの調整に時間を使ってしまい、エンジニアリングマネージャーになったらコードを書く機会がなくなってしまったという話もよく聞きますね。
一般的にマネジメントの適正対象者は5~8人で、最大で10人と言われているので、エンジニアリングマネージャーは明確な統計は取れていないですが、マネジメント対象人数が多くなりがちです。

## 一人一人と向き合う時間の不足

また、当然ですがマネジメント対象者が増えると一人一人に向き合う時間は減ってしまいます。1on1が1回30分として、その準備や周辺のコミュニケーションで一人当たりミニマムで週1時間かかるとします。
メンバーが5人だと5時間、10人だと10時間、そして前述のスタートアップCTOだと20人で20時間。ここまで来ると一人当たりのサポートの時間を減らさざる得ないでしょう。
その結果、一人当たりのケアと言いますか、向き合う時間は減ってしまいます。

メンバーが技術で悩んでいるのか、社員との関係性で悩んでいるのか、あるいは家族のことで悩んでいるのかについても人数が少なければ記憶してサポートできますが、多くなるとキャパシティ超えを起こします。（自分も創業期に似た経験をしましたが、限界が5人という感覚で、それ以上は中間にマネージャーが必要でした。）

## リモートでマネジメントをすること難しさ

コロナ渦中でリモートワークが加速しています。Slackを利用したコミュニケーションの活性化や分報チャンネルを作ることで発信など工夫はできるものの、リアルと同じだけの情報量を得るのは難しいのも事実です。
コロナ初期は常時オンラインでつなげるという試みもありましたが、deployするタイミングなど含めて圧倒的に開発効率が落ちるので、非現実的ということも分かってきました。

もちろん、仕事の特性上、集中して作業ができるリモートが決して悪いわけではありません。
一方でマネジメントサイドからすると、オフィスにいると自然と入ってきた情報が敢えて聞かないと分からないということが増えるので、マネジメントの難易度は上がります。

また、エンジニアがフルリモートか一部リモートかはさておきリモートを活用していく流れはアフターコロナの世界でも維持されそうなので、リモートにおけるマネジメントにマネージャーが慣れていく必要がありそうです。

## 十分なサポートができないことによる退職者の増加

一番の懸念が十分なマネジメントや、結果的なサポートができないことによる退職者の増加です。採用競争がとにかく激しい昨今、どの会社もエンジニアに長く在籍してほしいと思っている会社が多い状況です。

以前に他社のエンジニアリングマネージャーの方と話している際にリモートが浸透する中で増えている「サブマリン退職」を防ぎたいという言葉を聞きました。
「サブマリン退職」というのは潜水艦の浮上の如く突然「退職」がやってくるという意味合いだそうです。「退職」という言葉を聞くタイミングですでに退職が決まっており、打てる手がもうないとのこと。

オフィスで接している「なんとなく調子悪そう」とか、「悩んでいそう」というのを発見するのはリモートよりは簡単だったりしますし、すぐにちょっと話そうとかランチ行こうなどと向き合う場を作ることができます。
結果的に回避できていた悩みなどが、リモートだと気づけないままに、進行してしまい、向き合って話すときには「退職」が決まっているというケースが増えているという声です。

以上、いかがでしたでしょうか？
エンジニアリングマネージャーの悩みあるあるのほんの一部をご紹介しました。
<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>では直接的に退職を防ぐようなサービスではありませんが、メンバーの日々の活動を可視化することで、早め早めの声がけ、フォローができる機能も実装しています。

ぜひぜひ、ご関心あるCTO、VPoE、エンジニアリングマネージャーの皆様は<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>からお問い合わせください。

submarine

Findy Teamsというサービスを提供する中で、エンジニアリングマネージャーとお話をする機会が多くなっています。その中で、エンジニアリングマネージャーの悩みあるあるを書いてみようと思います。

エンジニアリングマネージャーの悩みあるある①〜マネジメント人数過多とサブマリン退職編〜

## プルリク作成数

GitHubベースに開発を進めている方だと当たり前に認識している部分だと思いますが、プルリクエストをどれだけ作るかで、エンジニアとして、チームとしてどれくらい開発が健全に回っているかがある程度見えてきます。

今回の作成数についてはマージされないものやドラフトのもの含めてすべてのプルリクエストを計測しています。

事前にお伝えすると、プルリク作成数などの数値を見てどう改善するかが大事であって、数値は参考にすべきものであるが絶対に達成しないといけない指標ではありません。数値が全てではなく、数値を見てどう動くかを考えたいという話です。

## Findyにおけるプルリク作成数の実績

Findyにおいて2021年8月は一人あたり78.8件のプルリクを作成していました。これは1日あたり3.94件となり、多くのプルリク数を作っていることがわかります。最も多いメンバーだと1日あたり8.45件のプルリクを作成しています。(計測して本当にびっくりですが…！)

いろいろな課題のあるチームだとプルリクがそもそも1日1件も出ずに業務が終了する、というケースがあったりしますが、Findyではなるべく多くのプルリクを出すようにしています。

8時間の稼働のうち2時間に1件くらいは作成するペースです。

## プルリク作成数を向上することによって得られること

プルリク作成数をただ上げるだけではなく、

1. 小さく分割する
2. レビューを全部同プルリクでやりきらない

ということも大事だったりします。

小さく分割されたプルリクを作り、プルリク作成数を最大化することで大きく5つの大きなメリットがあります。

1. 改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる
2. プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす
3. プルリク肥大化を防ぐことでレビュワーの負荷を減らす
4. コンフリクトのリスクを減らす
5. 「あの人何してるんだろう？」を減らす

一方で、

1. レビューの回数が多くなってしまう
2. 完成イメージがわかりにくくなってしまう

というデメリットも生じます。それぞれ解説してみます。

## 改善や修正などの頻度が増えることで価値提供までのスピードアップにつながる

これも毎日リリースなどをこなっているとしたら、プルリクの範囲を小さくしプルリクの作成数を多くすることで、できている範囲までで価値提供することができるようになります。

もちろんできている範囲が中途半端で価値提供にならないのであればそうとは限りませんが小さな修正などはまとめて他のタスクとやらずに個別に対応するなどで限りなく他の影響を減らして対応ができるようになります。

## プルリク肥大化を防ぐことでプルリク作成者の負荷を減らす

一気に大きな対応を行おうとすると、以下のようなことが起こります。

1. プルリクそのものが不要だったり方針が違うのに作りきるまでかかった時間が無駄になる
2. 複数の内容が入っていたりすると全部直したりしないといけない
3. CI/テストの影響範囲が広くなり修正箇所も多くなる
4. 作成する側に差し戻された内容が多いと精神的に重さを感じる
5. 一旦別のタスクをすると範囲が広いので対応している内容を時間の経過とともに忘れがち

プルリクが大きくなると実は作成者の自分にもダメージが出てきたりします。

## プルリク肥大化を防ぐことでレビュワーの負荷を減らす

これはいろんな方が体験したことがあると思いますが、大きすぎるプルリクを上げられると辛くなりますよね。

1. 大きすぎるプルリクが来ると「あとでレビューしよう」で放置されがち
2. 「いざやるか！」と思っても何を見ていいかわかりにくい
3. プルリク全体に関わるような共通化を同時に依頼するとまたレビュー最初からになりがち
4. ずっと同じことをレビューしているという状態が続く
5. 範囲が広いのでブラウザで全然diffが表示されず困る

たぶん優秀な人であっても大きいプルリクのレビューはしたくないはず…！

これが小さな範囲のプルリクであれば上記のような事は起こりにくくなるはずです。

## コンフリクトのリスクを減らす

コンフリクトしていたり、プルリクの滞留時間が伸びることで先にマージされた内容などを取り込みながら再度修正しないといけなかったりしますよね。

ライブラリのlockファイルや共通ファイルなどにも影響がいくとレビューする側も対応する側も「コンフリクト解消お願いします」と結構面倒なコミュニケーションをせざるを得なくなります。

なるべくコンフリクトを減らすことでコンフリクト解消コミット0化による安全な改修が可能になります。

## 「あの人何してるんだろう？」を減らす

これもリモートワークが推進されている環境だと尚更ですが、「あの人は何してるの？」という状態を減らしにいくことができます。

午前中はAの対応、午後はBとCのタスクの対応をしている状態とわかると進捗がはっきりしやすいため「何やってるかわからない」が減らせます。

これはプルリク作成者もそうですし、レビュワーもお互いにキャッチボールしやすい状態を作るとチームとしてストップしにくい状態になります。

## レビューの回数多くなってしまわない？

確かにデメリットとしてレビューの回数が多くなってしまうということです。

ただレビュワーとしては「ここだけ見ればいい」がはっきりしているため、1分あればレビューも大体完了するような状態にできます。

自分のプルリクも小さく回数を増やすことで「せっかくコード書いてるのにレビューばっかり」という状況も減らし、「ここまで書けたしレビュー依頼も来たし対応しよう」という状況を作ることができます。

全員が小さなプルリクをたくさん作ることでスピード感あるレビュー環境が作れます。

## 全体感がわかりにくくなってしまわない？

これはたしかに全体感がわかりにくくなってしまう可能性はありますが、自分が考えるに、プルリクの範囲が小さい状況のほうが相手の思考の過程を辿りやすくなるので背景やどうしてこういうアーキテクチャにしたのかなどを考えすぎなくて済むのかと思います。

## Findyのプルリク作成のベストプラクティス

- タスク着手時に気をつけること
 - GitHubのイシューにチェックボックス形式でタスクを羅列する
 - 羅列したタスクをエンジニアマネージャーやメンバーと合意する
 - チェックボックス1つにつき1プルリクを作る
- プルリク作成する時に気をつけること
 - なるべく粒度は小さくして最小限の範囲にする
 - 最低限のテストが通ることを保証したプルリクにする
 - リファクタや共通化なども別プルリクで対応する
 - 100行を超えるようなプルリク、ファイル数が10以上のプルリクは分割できないか考える
 - レビューすべきポイントをクリアにする
- レビューする時に気をつけること
 - 着手までの時間をボトルネックにしないためになるべく最速でレビューする
 - リファクタや共通化のコメントは行ってもいいが、同プルリクで対応を必須にしない
 - 設計の段階で大きく違いそうな場合はコメントを増やさずオンラインで相談

今のところ大きく思い浮かぶやり方はこのようなやり方です。

## 例: ユーザ一覧APIの新規作成

僕が過去にやっていた手順はこんな感じです。

1. コントローラーやモデル作成でユーザ一覧データが返るようにするプルリクの作成
2. リファクタや効率の悪い部分を同プルリクで修正し完了

これだと合計1プルリクで、上述したように作成する範囲ややるべきことがあっているか合意が取りにくく、割とやり直しリスクがある状態でちょっと改善が必要です。

なるべく小さくプルリクを分割してプルリク作成数を最大化して進めていくことを意識すると、

1. フロントでも使えるようにエンドポイントの設定と適当なjsonレスポンスのmockの作成プルリク+合意を取る
2. ユーザモデルマイグレーションのプルリク
3. ユーザ一覧取得処理のプルリク
4. mockの置き換えプルリク
5. ソート機能追加のプルリク
6. 絞り込み機能追加のプルリク
7. 共通化のプルリク
8. 非効率な部分解消のための効率化のプルリク

これくらい分割してプルリクを上げていくと数は増えますが、レビュー範囲は圧倒的に減りますし、それぞれ作成するまで短時間でdevelopにマージできるようになります。

イメージしていただけたでしょうか！？

## プルリクの分析機能をFindy Teamsで開発しています

ここまでの情報は、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">Findy Teams</a>で開発をしている部分もあり、簡単にデータが取得できます。継続的に測定できるため、自分の指定する期間でデータが取れるようになっています。

もしご興味があれば、<a href="https://findy-teams.com" target="_blank" rel="noopener noreferrer">こちら</a>までお問い合わせください！！

## 爆速顧客価値提供ができるFindyで働いてみませんか？

もしここまで読んでいただいて、少しでも話してみたいという方は是非一度カジュアル面談しませんか？

まだやりたいことがある中でまだまだ成長できる組織です！上記以外にも課題もあります！

是非興味があれば <a href="https://twitter.com/ma3tk" target="_blank" rel="noopener noreferrer">Twitter</a> でご連絡いただいたり、以下より直接ご応募いただいても大丈夫です👍

<a href="https://meety.net/ma/matches/MvtiQWbHRQsx" target="_blank" rel="noopener noreferrer">Meetyでのカジュアル面談はこちら</a>

エンジニアだけでも20人規模で募集しています。是非お気軽にどうぞ〜！

#### 【エンジニア組織全体】
- <a href="https://herp.careers/v1/findy/MH-u5skw__Ed" target="_blank" rel="noopener noreferrer">CTO候補</a>

#### 【Findy 転職】
- <a href="https://herp.careers/v1/findy/eRbKaEKEE6D6" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/MgtDp5Eh2cYC" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/H5DgEiQpboQ1" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/orzBujKLKmq2" target="_blank" rel="noopener noreferrer">プロダクトマネージャー</a>

#### 【Findy Teams】
- <a href="https://herp.careers/v1/findy/ypgJQ5_ObYex" target="_blank" rel="noopener noreferrer">エンジニアマネージャー</a>
- <a href="https://herp.careers/v1/findy/xOHUsVQEBA9R" target="_blank" rel="noopener noreferrer">バックエンドエンジニア</a>
- <a href="https://herp.careers/v1/findy/n3GYFS0yUnAH" target="_blank" rel="noopener noreferrer">フロントエンドエンジニア</a>

pullrequest

こんにちは、Findy CTO の @ma3tk です。 FindyではFindy社全体として大事にしているいちばん大事な開発指標として、プルリクエストの作成数があり、プルリクエスト作成数をベースに開発がうまくいっているかを議論し続けています。  プルリクエストの作成数とそれに紐づく議論について書いてみようと思います。

ナレッジ

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

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

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

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

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

データを活用した目標設計と運用にトライした1年間を振り返ってみた

データで口説くエンジニアの最終面接。ハイスキルな人ほど効率良い組織で集中して働きたい？！

2021年8月 Findy エンジニアリング組織の振り返り

エンジニアリングマネージャーの悩みあるある①〜マネジメント人数過多とサブマリン退職編〜

プルリクエストを作りまくることで得られたFindyの爆速プロダクト開発術

.css-1uuptc0 svg{width:32px;height:32px;fill:#666666;stroke:#666666;}@media (max-width: 750px){.css-1uuptc0 svg{width:24px;height:24px;}}ナレッジ

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

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

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

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

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

データを活用した目標設計と運用にトライした1年間を振り返ってみた

データで口説くエンジニアの最終面接。ハイスキルな人ほど効率良い組織で集中して働きたい？！

2021年8月 Findy エンジニアリング組織の振り返り

エンジニアリングマネージャーの悩みあるある①〜マネジメント人数過多とサブマリン退職編〜

プルリクエストを作りまくることで得られたFindyの爆速プロダクト開発術

ナレッジ

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