3つの取り組みでリードタイムを1/6にしました！

こんにちは、フロントエンドエンジニアの岡田です。

今Q（7月から9月期）は開発のメトリクスとしてリードタイムの改善に力を入れておりました。

今回取り組んだことをご紹介させていただければなと思います。

最初に結論

今回はリードタイムとデプロイ頻度を測定しました。約2ヶ月の改善活動の結果、以下のような結果を得ることが出来ました。 ※この記事では主にリードタイムに触れたいと思います。

	リードタイム	デプロイ頻度
Before	12日	2回/週
After	2日	4回/週

※リードタイムはfirst commitからdevelopブランチへのマージ時間を計測しております。

開発メトリクスとは？なぜ、開発メトリクスを測定したいのか？

初めに 「開発メトリクス」 とは何かを定義したいです。

メトリクスの定義とは、さまざまな活動を定量化し、その定量化したデータを分かりやすく加工した指標とされており、「開発メトリクス」とは、開発活動を定量化し、そのデータを解釈した指標である　と、解釈出来ます。

では、その開発活動の定量化とは具体的に何を指しているのでしょうか。

僕たちは以下の4つを指標にしています。

リードタイム
デプロイの頻度
平均修復時間
変更失敗率

※4 keysとよく呼ばれているものです。

これらは何となくこれが良さそう、というものではなくDevOps Research and Assessment(DORA)による調査で明らかにされたものです。この4keys Metricsの値と組織としてのパフォーマンス（収益性やマーケットシェア）に因果関係があるという結果がでています。

そのため、このMetricsの改善がビジネス面にポジティブな影響を与えるということです。

詳しくは『LeanとDevOpsの科学』という本にまとめられているので興味がある方はご参照ください。

具体的なメトリクスの数値について

こちらは2021年のDORAのレポートで示された、パフォーマンス別の4Keys Metricsの値の違いです。 ※ この記事を書いた後に、2022年度のものが出ました><

metric	Elite	High	Medium	Low
デプロイ頻度	オンデマンドに1日数回	1週間から月に1回	1ヶ月から6ヶ月に1回	6ヶ月に1回未満
リードタイム	1時間以内	1日から1週間	1ヶ月から6ヶ月	6ヶ月以上
MTTR	1時間以内	1日以内	1日から1週間	6ヶ月以上
変更失敗率	0~15%	16~30%	16~30%	16~30%

※ 2021年のDORAレポートより引用

EliteなグループとLowのグループのものでは

デプロイ頻度は973倍
リードタイムは6570倍
MTTRは6570倍
変更失敗率は3倍

違うと報告されています。この差分は年々開いていっているためエリートとなるために継続的に改善していかねばなりません。

リードタイム向上に向けやったこと

今回リードタイムの向上に向け以下の3つに取り組みました。

環境（本番、開発環境、ローカル）に応じた処理分岐の追加
epicブランチを作った開発からgit flowへ
CIの高速化

環境に応じた処理分岐の追加

function isFeat(): boolean {
  const isStg = VUE_APP_API_BASE_URL === 'https://ステージングのドメイン';
  const isPrd =
    VUE_APP_API_BASE_URL === 'https://本番ドメイン';

  if (isStg || isPrd) {
    return false;
  } else if (
    isFeatHostName(window.location.hostname) ||
    window.location.hostname === 'localhost'
  ) {
    return true;
  } else {
    return false;
  }
}

このような関数で、本番や、ステージング環境で実行したくない関数はisFeat()の分岐の中に入れておくとローカルや開発環境でのみ確認することが出来ます。 isFeatHostNameはテスト環境のドメインをチェックする関数になっており、featと入っているとisFeat()がtrueになるようにしています。

一般的なfeature flagとは異なりますが、本番に反映させないけど、developにはマージしたいを簡単に叶えてくれる機能になりリードタイム削減に大きく寄与しています。

epicブランチを作った開発からgit flowへ

僕たちはこれまで、masterからepicブランチを切って、releaseする際にreleaseブランチをきる運用を取っていました。そこからgit flowと呼ばれるブランチ戦略に変更し、開発者がどんどんdevelopブランチにマージしていけるようにしました。上述の環境により、処理を変更する分岐も導入したことも相まって、顧客に影響が出ない処理をどんどんマージしていけるようになりました。

developブランチがどんどん更新されていくことでコンフリクトも目に見えて減ったのも嬉しかったです。