【65%→11%】変更障害率を大幅改善する過程で、私たちがやったこと

## はじめに
この記事は、[エアークローゼットアドベントカレンダー2024](https://qiita.com/advent-calendar/2024/air-closet)の3日目の記事です:christmas_tree:

https://qiita.com/advent-calendar/2024/air-closet

今回は、エアークローゼットで長年の課題となっていた障害発生率に対して、SREが取り組んできたこととその成果、道のりをシェアできればと思います。

## 開発品質を改善しようとしたきっかけ
2023年6月期、エアークローゼットの開発チームは、ある大きなシステムインシデントにより獲得計画に大きな影響を与えてしまいました。[別の記事](https://note.com/wako_program/n/n8c5db6649f41)で紹介していますが、このインシデントを初めとした連続的なインシデントの発生をきっかけに、エアークローゼットの開発チームは「開発品質の改善」に取り組み始めます。

https://note.com/wako_program/n/n8c5db6649f41

しかし、この時点で開発チームとしては
* 開発品質が低いことはわかっているが、どのくらい低いのかわかっていない
* どうやって改善していくかは見えていない

くらいの認識で、まだ状況を整理し切れてはいませんでした。
ここからSREが開発品質の改善を主導していくことになりました。

:::note info
**なぜSREが開発品質の改善を主導？**
SREというと、運用改善やインフラのイメージが強いと思います。エアークローゼットは所属している全てのエンジニアがフルスタックエンジニアである背景から、SREは運用改善に限らない横串の改善を主導するポジションとして設置されました。
:::

## 目標設定
兎にも角にも、まずは開発品質を計測し、状況を把握する必要がありました。

### 2-1. 目標の定め方
元々、チームはバグの発生数をKPIの一つとして追っていました。
しかし、この指標はリリース数やリリース規模を考慮していないため、リリース数が増えればバグの発生数も増えてしまい、指標としての妥当性は低い状態でした。

そこで、バグの発生数をリリースされた開発ボリュームで割る、**「バグ発生率」** という指標を作成し、これをKPIとすることにしました。

計測の結果、変更障害率は65%と極めて高く、約半数のプロジェクトでバグが発生する計算になる、悲惨な状況であることがわかりました。

### 2-2. より高速にPDCAを回すために
バグ発生率は重要な指標でしたが、この指標にも1つの問題がありました。
それは、1回の改善のサイクルが長いことでした。

リリースされてからバグが見つかるまでには一定の期間が空いてしまう場合があるため、リリースされたプロジェクトの開発品質を評価するにも一定の期間が空くという問題です。

もっと早くPDCAサイクルを回すため、バグ発生率の中間指標として「コードの戻り率」、「結合テスト戻り率」「総合テスト戻り率」を計測するようにしました。

これにより、より短いサイクルで改善を回す環境を整えたのでした。

### 2-3. より効果的にPDCAを回すために
開発プロセスの中でも、どのプロセスに問題があるかは分かりきっていませんでした。
しかし、SREのメンバーは私一人のため、いたずらにリソースを消費することはできません。

対策として、1件1件のバグに対して、改善できる開発プロセスを特定し、より課題の大きい開発プロセスから改善を進めていくことにしました。

当たり前のことではありますが、より大きい課題から着手することで、小さい力でより強力に改善を進めることを常に意識しました。

## 実際のアクション紹介
とにかく1つ1つ、ヒアリングやレビューを通して具体を深掘りながら改善を進めていきました。序盤は特に問題が多く、時には頭がパンクしそうになりましたが、都度抽象化してアクションを打つことで、一つずつ課題を潰していきました。

ここからは、実際にエアークローゼットの開発チームが変更障害率を低下させるためにとったアクションの一部を紹介していきます。

:::note warn
**あくまで一例です**
どんなアクションを取るべきかは、チームの状況や歴史的な背景によっても異なります。下記はあくまでエアークローゼット社の一例としてご覧ください。
:::

### 意識を変える
このアクションだけは定量評価に基づいていませんが、意識を変えることは最も早期に取り組みました。意識は他の全てのアクションの基礎になるため、継続的に、徹底的にアクションを取り続けました。

#### 具体的なアクション例
* エンジニアの評価に、品質の定性評価指標を追加
    * インシデントの大きさに依存しない、エンジニアのミスに対する定性評価を開始
    * これを評価に組み込むことで、各エンジニアが品質を念頭に置く設計へ
    * 最終的にはCTOが評価をレビューすることで、評価の妥当性を担保
* SRE・開発者・レビュアーの振り返りを実施
    * バグ発生 or 総合テストの戻り率が一定以上の全プロジェクトで振り返りMTGを実施
* 重大なインシデントについてはチーム全体で共有会を開催
    * 基本的にはポストモーテムの考え方を踏襲しつつ、再発防止にフォーカス
    * 共有だけでなく、数人のグループでディスカッションすることで、学習効果を高める
* 全社でも変更障害率を毎週共有
    * エンジニアだけでなく、ビジネスサイドのメンバーも品質を意識できるように

### 結合テストを標準化する
このアクションは、バグが発生する都度行なっていたバグの振り返りの中で、何人かのエンジニアからでた「結合テストの書き方がわからない」という意見によりスタートしました。

エアークローゼットの開発チームは、前述の通り全てのエンジニアがフルスタックエンジニアであり、基本的に1プロジェクトに1人のエンジニアがアサインされるため、エンジニア間でナレッジが共有されにくいという構造がありました。

この問題により、結合テストに関しても品質高く書けるメンバーとそうでないメンバーに開きが生じるようになっていたのでした。

#### 具体的なアクション例
* 結合テストの基本的な考え方をドキュメントに集約
    * ガイドラインを策定し、ジュニアメンバーでも理解できるドキュメントに集約
    * ガイドラインをもとに勉強会を開催
* 結合テストのフォーマットを整備し、全員の書き方を標準化
    * ディシジョンテーブルの考え方とシナリオテストの考え方を取り入れたフォーマットを新たに作成
    * フォーマットにGoogle App Scriptを組み込むことで、簡便にディシジョンテーブルが作成できるように
* 全てのプロジェクトで、結合テスト作成レビューをSREがダブルレビュー
    * レビューの基準を統一する意味で、全プロジェクトでSREがダブルレビュー

### プロジェクトを小さくする
このアクションは、バグが発生したプロジェクトの平均ボリュームが、バグが発生していないプロジェクトの開発ボリュームに比べてはるかに大きかったことからスタートしました。

当然といえば当然ですが、開発のスコープが小さければ小さいほど、不確定要素は小さくなるとともに、影響範囲の調査等も漏れにくくなるため、品質は高まります。

#### 具体的なアクション例
* 基本設計段階でプロジェクトを小さく分割する運用
    * プロジェクトが一定以上のボリュームになった場合、なぜそうなったのか振り返りを実施
    * 進行中のプロジェクトでボリュームが増えた場合は、SREが介入してプロジェクトを分割できないか検討
* プロジェクトを分割するための早期アサイン

### 最低限のコード品質を担保する
このアクションは、元々開発チームが抱えていた課題であった「コード品質」に対するアクションの一つです。

エアークローゼットはとにかく機能のリリースを優先して、結果的に品質がないがしろになってしまっていた背景から、リファクタリングができているリポジトリとそうでないリポジトリに大きな差分があります。十分なリファクタリングがなされていないリポジトリでは、コーディングの戻りが多い傾向にあるというデータがありました。

[別の記事](https://qiita.com/Cut_program/items/2ab11d57c7f54b06699b)で一部を紹介していますが、最低限のコーディングルールを生成AIに渡し、それに沿って指摘をしてもらうことで、全てのリポジトリを一次レビューできるような仕組みを整備しました。

#### 具体的なアクション例
* アンチパターン管理
    * インシデントに繋がるコーディングを「アンチパターン集」としてドキュメント化
    * チームMTGで声を集め、都度項目を追加・削除
* 自動コードレビューツールによるダブルレビュー
    * 上記「アンチパターン集」のAIによるチェックをCIに組み込み
    * 人的リソースをかけずにアンチパターンの継続的なチェックができるように

https://qiita.com/Cut_program/items/2ab11d57c7f54b06699b

## 成果
上記のような施策を続けて約1年、徐々に成果が出始めました。
その一部を紹介させていただければと思います。

### 4-1. 低い変更障害率
変更障害率は、当初の65%から11%まで低下させることができました。
これはFour keysでいうと「Elite」に相当しており、元々「Low」だったことを考えると、スピード感を持った改善ができたのではないかと思います。

![変更障害率推移.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/751808/bb6742c3-10f9-210d-8f4d-465c53ef39a3.png)

### 4-2. インシデントによる損失・バグ改修費用の削減
変更障害率が低下したことにより、システムインシデントでの損失や改修にかかるコストを数千万円単位で削減することができました。

横串の改善ができるのはSRE/DevOpsの醍醐味だと思うので、今回のような結果が出せたことは本当に嬉しかったです。

## これから
変更障害率を劇的に改善した開発チームですが、まだまだ課題はたくさんあります。

* ベトナムの開発拠点「AIRCLOSET ENGINEERING COMPANY LIMITED」における品質改善
* より低コストで品質を担保できるようにする仕組みの構築
* 開発効率 (1リリースあたりの工数) の改善

https://prtimes.jp/main/html/rd/p/000000221.000011623.html

これからも、エアークローゼットのSREは組織の課題に発想とITで立ち向かっていきます。

## まとめ
最後までご覧いただきありがとうございました！

[エアークローゼット Advent Calendar 2024](https://qiita.com/advent-calendar/2024/air-closet)はまだまだ続きますので、ぜひ他のエンジニア、デザイナー、PMの記事もご覧いただければと思います

また、エアークローゼットはエンジニア採用活動も行っておりますので、興味のある方はぜひご覧ください！

https://corp.air-closet.com/recruiting/developers/