Four Keysに基づく リリースプロセスの改善と その成果 2023-10-08 PHP Conference Japan 2023 サイボウズ株式会社 小山晃久（@akihisa1210）

自己紹介 ⚫ 小山晃久（@akihisa1210） ⚫ サイボウズ株式会社 開発本部 Garoon開発チーム ⚫ 品質、テスト、CI/CD、アジャイル ⚫ 読書、コーヒー

No content

発表のゴール ⚫ 誰に ⚫ 現在のリリースプロセスに課題を感じている人 ⚫ 何を伝えたいか ⚫ Garoonチームでのリリースプロセス改善事例を、 改善の参考の一つにしてもらう

リリースに関する課題

Garoonの注力ポイント ⚫ 新規開発 ⚫ 課題解決 ⚫ ライブラリアップデート ⚫ インフラ移行 ⚫ リリース改善（←このチームの話をします） ⚫ ……

リリースに関する課題 ⚫ ビッグバンリリースが常態化している ⚫ 機能がリリースされるまで時間がかかる ⚫ リリース後の障害の改修にも時間がかかる ⚫ 複数チームが利害関係者になっているリリースプロセスが複雑で 制約が多い ⚫ これらの課題を解決したい！

Four Keysに基づく測定

どこから手を付ける？ ⚫ それぞれの課題は大きく、また相互に関係していそう ⚫ いきなり着手する前に、Garoonのリリースの現状を 測定してみよう

Four Keys ⚫ DevOps Research and Assessment（DORA）が特定した、 ソフトウェア開発チームのパフォーマンスを示す 4つの重要なメトリクス ⚫ Are you an Elite DevOps performer? Find out with the Four Keys Project https://cloud.google.com/blog/products/devops-sre/using- the-four-keys-to-measure-your-devops-performance?hl=en ⚫ 2022 Accelerate State of DevOps Report https://cloud.google.com/devops/state-of-devops

Four Keys（各項目・DORA版） デプロイ頻度 Deployment Frequency 本番環境へのデプロイの頻度 変更のリードタイム Lead Time for Changes コミットが本番環境にリリースされるまでの時間 変更障害率 Change Failure Rate デプロイが本番環境に障害をもらたす割合 サービス復元時間 Time to Restore Service 本番環境の障害を復旧させるまでの時間

Four Keys（パフォーマンスの目安） (From “2022 Accelerate State of DevOps Report”) Low Medium High デプロイ頻度 Deployment Frequency 毎月～6か月ごと 毎週～毎月 必要な時に（1日複数回） 変更のリードタイム Lead Time for Changes 1か月～6か月 1週間～1か月 1日～1週間 変更障害率 Change Failure Rate 46%～60% 16%～30% 0%～15% サービス復元時間 Time to Restore Service 1週間～1か月 1日～1週間 1日未満

Four Keys（各項目・Garoonチーム版） デプロイ頻度 本番環境へのデプロイの頻度 変更のリードタイム プルリクの初回コミットから本番環境へのデプロイ日までの日数 変更障害率 緊急性の高い障害の切り戻しまたは修正版のデプロイ回数を 総デプロイ数で割った値 サービス復元時間 緊急性の高い障害の原因となる変更が本番環境に デプロイされてから 切り戻しまたは修正版のデプロイが完了するまでの所要時間

Four Keys + 1 ⚫ 2021年から追加されている「信頼性 Reliability」ではなく…… ⚫ 変更サイズ ⚫ 『LeanとDevOpsの科学』によると、Four Keysに もともと採用しようとしていたのはデプロイ頻度ではなく バッチサイズ（p.26） ⚫ Garoonチームでは、1つのリリースに含まれる プロダクトバックログアイテム（PBI）の数を測定した

測定結果（2020年～2022年） ⚫ デプロイ頻度はそこまで悪い値ではない ⚫ 変更サイズは増加傾向にあった ⚫ 変更サイズが大きいリリースほど、リードタイムと変更障害率が 大きい ⚫ ただし、変更障害率の実際の値自体はあまり高くない ⚫ サービス復元時間はやや長め ⚫ ここから改善を考える！

リリースプロセス改善

何をするとよい？ ⚫ 測定結果から、変更サイズとリードタイムの改善から 着手するのがよさそうだと考えた ⚫ 一度にリリースする内容を減らす ⚫ リリースに必要な作業を減らす ⚫ リリースプロセスに介在する人を減らす ⚫ 変更をリリース用ブランチにマージしたら、 後は待つだけでリリースされるようにしよう！

新しいリリースプロセスの特徴 従来のリリースプロセス 新しいリリースプロセス リリースする単位 特定のタイミングでまとめて リリースしたい複数のPBI 1つのPBI リリースする頻度 月に1回、または緊急時 いつでも リリースに関わる人 開発チーム、QAチーム、プロダク トマネージャー、基盤チーム、他プ ロダクト開発チームなど 開発チーム リリースに必要な（手動の）作業 リリースする成果物の特定、リリー ス日程の調整、自動化されていな いリグレッションテスト、リリースシ ステムへの情報登録など マージ

これを実現するためにやったこと ⚫ チーム内外の共感を得る ⚫ 従来のリリースプロセスの整理 ⚫ 新しいリリースプロセスの作成・自動化

チーム内外の共感を得る（1） ⚫ オピニオンリーダーを巻き込む & 活動を相手に合わせて伝える ⚫ プロダクトマネージャーに対して ⚫ リリースの調整コストが削減できることをアピール ⚫ テクニカルサポートのメンバーに対して ⚫ 不具合の問い合わせがあっても、すぐに改修してリリースできる ようになることをアピール

チーム内外の共感を得る（2） ⚫ 営業・マーケティングのメンバーに対して ⚫ 社内イベントで改善の内容や狙いを共有 ⚫ 新しいリリースプロセスの対象のすり合わせ ⚫ まずは外部仕様に影響のない小さな変更を対象にする ⚫ 開発チームに対して ⚫ 社内で企画されていたt-wadaさんの講演に参加してもらう ⚫ 実際に新しいリリース方式でリリースしてもらう（モブで実施）

従来のリリースプロセスの整理 ⚫ 関係者で集まり、今のリリースプロセスを可視化した ⚫ 誰が何をしているのか ⚫ 依存関係はどうなっているのか ⚫ 時間がかかっている箇所や負担が大きい箇所に目星をつけた

新しいリリースプロセスの作成・自動化 ⚫ 不要なプロセスを削除する ⚫ ブランチ戦略を整備する ⚫ 従来のリリースプロセスに最適化されたブランチ戦略から、 リリース用ブランチへのマージでリリースが行われる 新しいリリースプロセスに最適化されたブランチ戦略へ ⚫ リリース用のCIジョブを作成する ⚫ リリース用ブランチへのマージ後にやることはすべて自動化

改善の結果

Four Keysの値の変化 ⚫ デプロイ頻度が8倍に増加！ ⚫ 変更のリードタイムが1/10に短縮！ ⚫ 変更障害率が1/8に低下！ ⚫ サービス復元時間が1/8に短縮！

リリースに関する課題の状況 ⚫ ビッグバンリリースが常態化している ⚫ 小さなリリースを可能にするリリースプロセスができ、運用中！ ⚫ 機能がリリースされるまで時間がかかる ⚫ 今のところ変化なし ⚫ リリース後の障害の改修にも時間がかかる ⚫ 障害復旧のためのリリースが簡単にできるようになった！ ⚫ 複数チームが利害関係者になっているリリースプロセスが複雑で制約が多い ⚫ 開発チームだけでリリースができるようになった！

改善を体感！ ⚫ プロダクトマネージャーのリリース調整コストが減っている ⚫ 早くリリースしたい不具合改修などを即リリースできていてよい ⚫ 開発チームの声

改善の振り返り

よかった点（1） ⚫ Four Keysを活用できた ⚫ 現状の測定に ⚫ 改善の方向決定に ⚫ 改善の共感を得るコミュニケーションに ⚫ 測定からアクションまでを一貫して行う上で、 目安にできる客観的な指標があるのはありがたい

よかった点（2） ⚫ 少しずつでも改善に着手した ⚫ 新しいリリース方式でリリースできるものは、最初は少なかった ⚫ それでも新しいリリース方式を実際に導入してみることで ⚫ 新しいプロセスの課題が明確になったり ⚫ 新しいリリース方式の嬉しさが色々な人に伝わったり ⚫ フィードバックを得られてモチベーションが上がったりした ⚫ 始める + 一緒にやる + 応援する

今後の課題

今後やりたいこと ⚫ 新しいリリース方式でリリースできる範囲を広げて、 従来の方式のリリースのサイズを縮小していく ⚫ リードタイムのさらなる短縮 ⚫ 一緒にやっていく仲間を募集中！ ⚫ Webエンジニア ⚫ QAエンジニア