この記事はツクリンクアドベントカレンダー2023の12日目の記事になります！
はじめに
現在、弊社ではDevOps Research and Assessment（DORA）が提唱しているFour Keysを元に開発生産性の向上を目指し取り組んでいます。
Four Keysの各指標としては下記になります。
| デプロイの頻度 | 組織による正常な本番環境へのリリースの頻度 |
|---|---|
| 変更のリードタイム | commit から本番環境稼働までの所要時間 |
| 変更障害率 | デプロイが原因となり、本番環境で障害が発生する割合（%） |
| サービス復元時間 | 組織が本番環境での障害から回復するのにかかる時間 |
本記事では、変更のリードタイムを短くする為に行ってきた取り組みを紹介させていただきます。
先にどのような状態からどこまでの変化があったのかをFindy Team+のキャプチャを添付します。
2023年5月の変更のリードタイムの状態
2023年10月の変更のリードタイムの状態
変更のリードタイムが約半年で80%削減できるまでに取り組んできた内容を紹介させていただければと思います。
現状把握
実施前に過去の下記4項目の数値を抜き出し、チーム全体で定量的に可視化する事によって現状を把握するところから始めました。
- First CommitからPull Request作成までの時間
- Pull Request作成からレビュー実施までの時間
- レビュー実施からApproveまでの時間
- Approveからマージまでの時間
弊社としては、「Approveからマージまでの時間」に関しては課題として見える部分がなかったのですが、それ以外の3項目についてはリードタイムが長く課題を感じる状態にありました。
こちらを実施する事でチームとしての課題の意識の共有ができ、方向性の一致が取れるので最初に実施しておいて良かったと感じるポイントです。
Pull Request粒度の分割
こちらはレビュー実施からApproveまでの時間に着目し削減する為の改善策となります。
今までですと、変更行数が多くPull Requestのレビューへの負担が大きい事があり、レビューへのハードルが高い状態にありました。
そのレビューを容易にする為に、実装単位を機能単位の粒度ではなく、意図単位の粒度へと変更し粒度を小さくする取り組みを実施しております。
例えば、データを取得し画面へ描画する機能Aが存在していたとすると、機能Aとして1つのPull Requestにするのではなく、データを取得と画面への描画の2つのPull Requestに分けるように実施しております。
この策の結果、レビュワーへの負担が減り、レビュー時間の削減ができていることが結果として出ています。
さらにまだ数値として定量的には見れてないですが、レビュー範囲が狭まりレビューの質が上がっているように感じております。
Findy Team+で見るとPull Request作成数も約2倍の数字になっている事がわかります。
2023年5月のPull Request作成数
2023年10月のPull Request作成数
レビューを後回しにしない
Pull Requestのレビューが放置される状態が続いている事が数値として明らかになっていたので改善していく必要がありました。
こちらは意識的な部分から取り組み、まずは実装よりもレビューを行うことの方が優先タスクだという意識をチーム全体で統一していくことから始め、さらに、毎日の朝会で現状のレビュー段階のタスクを洗い出し担当者が決まっていないものはその場で担当者を決めレビューの抜けを無くす取り組みを実施しています。
また、Pull Requestを作成したらチーム全員にメンションし、レビューをお願いするという動きを徹底することも実施しています。
ここについては、GitHub Actionsなどを使用し少し自動化にも取り組んでいきたいと考えております。
毎週のふりかえり
弊社ではスクラム開発を取り入れているので、スプリント・レトロスペクティブにて、スプリント内で実施した内容のリードタイムを全て振り返る時間を設けております。
Findy Team+ を取り入れているので、そちらで可視化したデータを確認し課題点の抽出 → 次週改善案を出すまでを毎週実施しています。
これから
今は、変更のリードタイムにフォーカスして追っている部分がありますが、今後はデプロイ頻度や変更障害率についても深ぼっていこうと考えております。
また、取り組んでいく上でこの数値は本質的な改善を行う事を目的として使用し、数値を上げることが目的とならないようには気をつけながら取り組んでいく必要があります。