はじめに
ソフトウェア開発の生産性を測る指標は多岐にわたりますが、その中でも変更障害率（Change Failure Rate、CFR）は、変更時に発生する障害の割合を示す重要な指標です。
Four Keys を用いた生産性可視化や改善などの業務は、プラットフォームエンジニアが支援する領域となり得ます。この記事は、Four Keys 関連の業務を行うことになったプラットフォームエンジニアや旗振り役のエンジニアに向けて書きました。ぜひ最後までご覧ください。
変更障害率とは
変更障害率（CFR）は、リリースやデプロイ後に発生した障害の割合を示す指標です。これは、システムの安定性とリリースの品質を評価するための重要なメトリクスとなります。CFR が低いほど、リリースの質が高く、安定していることを意味します。
変更障害率を見る理由
CFR に着目したり改善したりすると、以下のようなメリットがあります。
- 品質評価：リリースの品質を評価するための重要な指標として機能する。
- 信頼性向上：CFR の低減は、システムの信頼性が向上していることを意味する。
- 顧客満足度の向上：安定したリリースにより、顧客満足度が高まる。
- 開発効率の向上：問題の発生を減少させ、開発効率が向上する。
変更障害率を改善する方法
改善方法について考える前に以下の疑問にまず答えます。
- そもそも改善する必要があるかどうかどう判断すればいいの？
- 改善する方法の前にまずは原因の話からじゃない？
前者についてはベンチマークがあるのでこのあと紹介します。
後者については以下で触れているので、この記事では割愛します。
改善すべきかどうか判断するためのベンチマーク
それではまずベンチマークから紹介します。
| レベル | MTTR の値 |
|---|---|
| Elite | 5.0%未満 |
| High | 5.0%以上-10.0%未満 |
| Medium | 10.0%以上-15.0%未満 |
| Low | 15.0%以上 |
これをもとに組織で改善すべきかどうか判断しましょう。CFR 以外も生産性を測る指標は色々ありますし、他の案件もあるでしょう。それらの中から適切に優先度を決めていきましょう。
具体的な施策
CFR を改善するための具体的な施策としては、たとえば以下のようなものがあります。「技術者のスキルをあげる」とかは意図的に省いていて、どちらかといえば仕組みで解決する系のものを集めました。
| 施策 | 有効とされる理由 | 具体例 |
|---|---|---|
| コードの品質を高く保つ | 高品質なコードにはバグが混入しづらい | コードレビュー、静的解析ツールの活用 |
| テストを整備する | リリース前に問題が発見できれば、その分リリース後の障害発生数を減少させられる | 単体テスト、結合テスト、E2Eテスト |
| デプロイプロセスを自動化する | 人為的なミスを減らせる | CI/CD ツール導入 |
| フィーチャーフラグを使う | 新機能の影響が限定的になるので、問題の発生確率を下げられる | フィーチャートグル |
| ポストモーテムの実施 | 障害の再発防止策を講じることができる | 障害発生後の振り返り、レビュー、改善策の実施 |
| リリース戦略を整備する | リリースの頻度や粒度などを適切に管理して、リリースの安定性を向上させられる | 段階的リリース、カナリアリリース |
さいごに
CFR については今回紹介した内容を理解することが第一歩です。Four Keys を計測して PDCA サイクルを回していく開発組織は肌感として増えてきた印象です。いきなり完璧にはいかないとは思いますが、少しずつその組織でできることをやっていくことで、着実に強い開発組織になると思います。ので頑張っていきましょう。
コメント