# 開発スピードを向上させる

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

結論から言うと、素早く、動くソフトウェアを顧客へ届けるために、エンジニア組織の生産性を測る要素としては以下の2点に集約されます。
（※ 今回はプロダクトの企画・仕様作成の時間は除き、エンジニアがコードコミットしてから本番環境へデプロイされるまでの時間として言及）

* ソフトウェアデリバリの速度
* ソフトウェアが顧客のもとへ届くまでの時間であり、プロダクトの企画〜運用までのプロセスを速く実行することが重要
* ソフトウェアデリバリの安定性
* コードコミット〜デプロイするまでの障害および障害に対する復旧の時間であり、顧客へきちんと動くソフトウェアを届けることが重要

これら2つの要素は、以下の指標として数値化し、定点観測することが可能

↓↓↓

* ソフトウェアデリバリの速度
* デプロイの頻度
* 組織による正常な本番環境へのリリースの頻度
* 変更のリードタイム
* commit から本番環境稼働までの所要時間
* ソフトウェアデリバリの安定性
* 平均復旧時間（MTTR：Mean Time To Restore）
* 組織が本番環境での障害から回復するのにかかる時間
* 変更失敗率
* デプロイが原因で本番環境で障害が発生する割合（%）

上記は、『LeanとDevOpsの科学』という書籍からの引用となりますが、
これらソフトウェアデリバリの指標(Four Keys：4つのキーメトリクスとして紹介)は、
組織全体のパフォーマンスおよび企業の業績に好影響を与える、
という科学的な根拠をもって実証されています。

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

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

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

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

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

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

Findy Teamsでは、GitHubやGitLab、Jiraなどのエンジニア向けツールのデータを取得し、エンジニア組織のパフォーマンスを可視化することが可能です。

## Findy Teamsの『DevOps指標』とは？

Findy Teamsでは、『DevOps指標』として、以下の指標を見ることができます。

* メインブランチへのマージ回数
* 期間内にメインブランチへプルリクがマージされた回数
* 変更のリードタイム
* 期間内にメインブランチにマージされたプルリクに紐づくすべてのコミットのマージまでの平均時間
* 変更障害率
* 期間内にメインブランチにマージされたプルリクのうち、hotfixブランチからのプルリクが占める割合


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


DevOps指標およびそれに係るプルリクベースでの開発アクティビティや開発リードタイムを把握し、エンジニア組織の生産性改善に繋げることができます。

★ 活用している会社の事例はこちら
https://engineering-org.findy-teams.com/tech_blog/

## Findyでの生産性向上の取り組み

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

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

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

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

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

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


→ アウトプット量の改善に関して、金額ベースでも換算すると1.8億円のアップサイドの効果

## グローバルでもデータ活用に注目

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

* [Googleエンジニアリングプラクティス - コードレビューの速度](https://google.github.io/eng-practices/review/reviewer/speed.html)

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

## 注意点

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

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

## まとめ

この記事に記したのは、下記3点でした。
* 開発スピードを向上させる指標は何なのか？
* その指標を使ってどういう取り組みをするのか？
* 結果、どうなったのか？

この仕組みを取り入れるのは（可視化するのは）とても有効だと思うが、
手っ取り早く試すために**下記の指標に注目して現状に対して考察する**と良いと思いました。

* プルリク
* プルリク作成数
* 多いとよく、どんどん作りたい
* 1プルリクに対する平均コメント数
* 少なく保ちたい
* コードの品質を高め、その修正の前提条件等の説明をキチンと書く
* プルリク作成者のコメント応答率
* 100%を目指したいので、ちゃんと返答する
* 1プルリク辺りの平均マージ・クローズ時間
* 短くしたいので、早く見る
* 1プルリク辺りの平均変更行数
* 多すぎないように注意する
* 1プルリク辺りの平均ファイル変更数
* 多すぎないように注意する
* どうしても多くなってしまう場合
* その旨をレビュワーに伝える
* レビューしやすいように詳細に説明を書く
* レビュー時間が伸びることを許容する
* リードタイム
* プルリク作成からレビューまでの平均時間
* 短くしたいので、早く見る
* レビューからアプルーブまでの平均時間
* 短くしたいので、さっさとマージ（リリース）する

要は、下記をすると開発スピードが上がる。
* プルリクをたくさん作る
* 開発環境とかにフォーカスがいきそう
* プルリクの品質を上げる
* コードの品質を上げる
* われわれの勉強にフォーカスがいきそう
* 素早くレビューする
* タスク整理とか、フリーな時間を作ることにフォーカスがいきそう
* プルリクの変更ファイル・行数を見やすい単位で出す
* われわれの意識の問題？
* マージのブロックになるような障壁を取り除く
* デプロイフローとかにフォーカスがいきそう

それをするために何をチームで行うか？をチーム、組織のみんなで考えよう。

# 参考
↓パクって切り貼りしてます
https://engineering-org.findy-teams.com/posts/engineering_org_devops_metrics/
https://engineering-org.findy-teams.com/posts/developer-experience-improvement/