なぜ私はリリース頻度を上げたいのか
本記事はIVRyのIVRy Advent Calendar白組の記事です。なぜか紅組と競っています。昨日はsagawaさんの「IVRy開発合宿の中身をお見せしちゃいます」でした。 明日は佐瀬さんの「UX/UIデザイナーの在り方を考えていきたい〜IVRyでの取り組みについて〜」の予定です。
こんにちは。ソフトウェアエンジニアのIgarashiです。 11月に入社してから、誰かと目が合う度に「リリース頻度をあげましょう」と言い続けています。
そろそろエンジニアチームのみんなは洗脳されたと思います。
本記事ではエンジニア以外の方にも分かりやすく、私は「なぜリリース頻度を上げたいのか」について書きたいと思います。
3行まとめ
リリース頻度が上がると価値提供の速度が上がる
リリース頻度が上がるとサービスの安定性が高くなる
それらは市場での優位性や組織のパフォーマンス向上に結びつく
リリース頻度と価値提供
ソフトウェアの変更を適用したコードが本番のプロダクトに反映されることをデプロイまたはリリースと言います。このリリースがどのくらいの頻度で行われているか、これがリリース頻度です。
ではリリースの頻度が上がると何が嬉しいのでしょうか。それは顧客への価値提供が早くできるからです。
リリースを頻繁にするほど顧客への機能を提供するまでの時間が早くなります。機能を追加し、フィードバックをもらい改善するサイクルを素早く回すためには、リリース頻度を高くする必要があります。
一方でリリース頻度を高くすると、頻繁に障害が起こりサービスの安定性を損なうのではないかと思う人も多いと思います。以下では、サービスの安定性について述べていきます。
リリース頻度とサービス安定性
リリースの頻度が上がると、新しいコードのバグによるエラーが頻繁に起こるような気がします。しかし実際にはそうではありません。
リリース頻度と障害回数
例えば以下の二つのチームについて考えてみましょう。
チームA: 週に1回リリースする
チームB: 週に10回リリースする
ここでは簡単に週に10個の機能をリリースしたと考えてみます。開発者がバグを仕込む割合が1機能あたり50%だと仮定します。つまり10個の機能のうち5個で障害が発生します。
チームAは、1回しかリリースしないのでおおよそ週1回の障害が起きます。一方、チームBは週5回障害が起きます。これは大変です。
ではここで、バグを仕込む割合が1機能あたり10%と仮定し直してみましょう。チームAは1週間に10個の機能を同時にリリースするので、その中にはバグが1つあります。よって週に1回の障害が起きます。
チームBは週に10回に分けてリリースし、その中の１つにバグがあるので週に1回障害が起きます。
同じ障害回数になりました。魔法のようです。
つまり重要なのはリリースの頻度よりも機能あたりの障害の発生確率と言えます。バグの混入確率が十分に低ければ障害回数にほとんど差は出ないということです。
また、これらの機能が互いに非依存である場合、顧客がその障害に出会う回数は変わりません。
例えばA, Bという２つの機能がリリースされ、両方で障害が出るとします。例え同時にリリースしたとしても、顧客はそれぞれの機能ごとに障害を経験するからです。
つまり、機能同士の依存関係が少ないほどリリース頻度の影響は少なくなります。
障害の発生確率
上の話からリリース頻度が増えると、必ずしも障害が増えるわけではないことがわかります。一方でコードの変更における障害の発生率が重要なのことがわかりました。
さて、上述の例では1機能あたりの障害発生率を同じと仮定しました。しかし、実際にはチームBの方が障害発生率は低くなります。
なぜなら、複数の機能を1度にリリースした場合、それらの依存関係を確認しバグがないか判断するのが大変だからです。開発者のレビューやQAが複雑になるため、抜け漏れや考慮漏れが発生してしまいます。
高頻度にリリースを行い、確認する機能をできるだけ小さくすることで、障害の発生率を下げることができます。
障害からの復旧時間
さて、障害発生率と同様に重要な指標は障害からの復旧時間です。顧客にとってより重要なのは障害発生回数より、障害によってある機能が使えない時間です。
ここでも、高頻度にリリースを行うチームの方が良い結果を得ます。なぜなら、多くの機能が1度にリリースされた場合、障害の影響範囲は不明であり、原因を把握するまでに時間がかかります。一方、リリースされる機能が少なければ少ないほど、影響範囲は局所的で原因の特定が簡単です。
またリリースした機能を全部取りやめ、元の状態に戻したとします。すると、バグを修正してその機能をユーザが使えるまでにかかる時間は、やはり高頻度でリリースするチームの方が短く済みます。例えば先ほどのチームAであれば、1週間後のリリースとなるのに対し、チームBは遅くても翌日となります。
以上のように、リリースの頻度とサービスの安定性は、トレードオフではなく車の両輪です。障害発生率が高すぎるチーム、1つの機能のバグが全ての機能に影響を及ぼす密結合なリリースでは高頻度のリリースは行えません。
一方で高頻度のリリースはサービスに安定性をもたらし、チーム間、コード間の依存関係を少なくします。それによりさらに高頻度にリリースすることができるようになります。
1日3回リリースするチームは、年に1000回ほどリリースできます。一方で週1回のリリースするチームでは50回です。
どちらのチームのリリースに安定性が出るかを考えるとわかりやすいかもしれません。
Four Keys メトリクス
勘の良い読者ならお気づきの通り、今まで述べてきたことはGoogleのDevOps Research and Assessment（DORA）が提唱したFour Keysを念頭に置いています。
デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間
彼らの研究によると、これらの数値が良いチームほど組織全体のパフォーマスが高くなります。組織全体のパフォーマンスというのは、エンジニアリング組織だけではなく、ビジネス上の成果をも含みます。
チームはこれらの値を測定し、継続的に改善を繰り返すことで、ビジネス成果を大幅に向上させることができます。
私はこの4つの指標の中でで1番測定しやすく、取り組みやすいのがデプロイ頻度と考えています。そして、デプロイ頻度を上げようとする過程で、その他の数値も上がっていくると考えています。
まとめ
以上、リリース頻度とサービスの安定性からFour Keysまで述べてきました。
Four Keysの数値を上げることは、市場での優位性につながります。そのための第一歩としてリリース頻度の向上を進めたいという内容でした。
現在、IVRyではリリース頻度を高めるために様々な取り組みを行っている最中です。一方でまだまだ実装できていない機能もたくさんあり、QA自動化や、CI/CD等に多くの時間が取れていません。これから、開発組織がスケールしていくために、スクラム運営や開発プロセスの改善を一緒にやっていく仲間を募集中です！